[xmlsec] Verify signature after certificate expired
Moultrie, Ferrell (ISSAtlanta)
FMoultrie@iss.net
Wed, 9 Oct 2002 13:28:04 -0400
This is a multi-part message in MIME format.
------_=_NextPart_001_01C26FB9.394AC2BA
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Aleksey:
I'll have to check the spec also -- but it simply *can't* work this
way. If I sign e-mail today and it can't be verified tomorrow even
though nothing has changed, that's *wrong*. I do know that signing of
certs works this way but that's handled by ensuring that the root cert
is valid as of the expiration of the child cert. While you are likely
correct about CRLs .. none of the other signing schemes other than certs
behave this way (i.e., code signing (JAVA and Authenticode) and S/Mime
e-mail don't behave this way).
Depending on what the spec says about this and whether it's MUST,
SHOULD or MAY, will determine how to proceed here. If it's SHOULD or MAY
and you feel strongly that the current behavior is correct, what about
an option for applications where the data must be proved authentic
essentially forever and the only desired restriction is that the cert
must have been valid when the data was signed?
One way to look at this is that I'm giving my customers a perpetual
license to my application -- if it suddenly stops working in 9 months
when my cert expires, they aren't going to be happy. The commercial CA's
won't even give you a cert greater than 12 (maybe 24 if you press hard)
months. There's no way to validate code and other application meta-data
(the XML issue at hand) for a greater period of time if your assumption
is correct. That just won't work ...
Please check on this and reconsider if it's at all an optional
behavior (which I strongly believe it is).
Thanks!
Ferrell
-----Original Message-----
From: Aleksey Sanin [mailto:aleksey@aleksey.com]=20
Sent: Wednesday, October 09, 2002 11:48 AM
To: Moultrie, Ferrell (ISSAtlanta)
Cc: Roman Bouchner; xmlsec@aleksey.com
Subject: Re: [xmlsec] Verify signature after certificate expired
=09
=09
I believe you are wrong here. The certificate must be valid when
signature is verified.
Where "valid" includes:
1) certificate is signed by another "valid" cert or trusted
root cert
2) certificate is not in the CRL=20
3) the certificate purpose matches the action you are going
to do (sign, verify, etc.)
4) the certificate is not expired
All 4 items are important. I do not have an X509 spec around so
I could not prove my point.
However, RFC 2560 (http://rfc.sunsite.dk/rfc/rfc2560.html):
=09
An OCSP responder MAY choose to retain revocation information
beyond
a certificate's expiration. The date obtained by subtracting
this
retention interval value from the producedAt time in a
response is
defined as the certificate's "archive cutoff" date.
Please note that when certificate is expired the OSCP may remove
the CRL from memory!
=09
Aleksey
=09
=09
=09
=09
Moultrie, Ferrell (ISSAtlanta) wrote:
=09
Aleksey:
Very important question here -- I want to make sure I
understand your
reply. In general, it is not permitted to *sign* data
after the signing
certificate has expired but it is allowed to *verify*
data after
expiration. An example:
=09
I sign my code today allowing the user to verify that it
is uncorrupted
when he installs/runs it. My certificate expires in
three months. If you
don't honor the signature any more at that point, then
his code stops
working -- a very bad thing.=20
=09
Another example:
I sign an e-mail to you today. Three months later my
cert expires. Six
months later you try to read my e-mail and you're told
the signature is
invalid. A bad thing.
=09
As these two examples illustrate, it is *not* standard
practice to
invalidate signatures because the signer's cert has
expired. The only
date restrictions should be:
1) Signers cert *must* be valid as of the date the data
was signed;
2) Root cert(s) *must* be valid as of the date they
signed the
subsidiary cert (in fact, I believe proper practice is
that CA's
shouldn't sign certs that extend beyond their own
validity date).
=09
The key concept is that user signing's *don't*,
*shouldn't*, *mustn't*
expire just because the user's cert has expired. At that
point, he can't
sign anything else until he renews his cert but
everything he signed
still remains valid forever because it was valid when he
signed it and
it hasn't changed.=20
=09
Is there a problem here or did I just misunderstand
something?
Thanks!
Ferrell
=09
-----Original Message-----
From: Aleksey Sanin [mailto:aleksey@aleksey.com]=20
Sent: Wednesday, October 09, 2002 11:05 AM
To: Roman Bouchner
Cc: xmlsec@aleksey.com
Subject: Re: [xmlsec] Verify signature after certificate
expired
=09
=09
From the general security point of view the data are
*not valid* if the
=09
cert is expired.
If you really want to do this then you should take a
look at the OpenSSL
=09
cert
verification function and remove date check. However,
this is
DANGEROUSE!
=09
Aleksey.
=09
Roman Bouchner wrote:
=09
=20
Hello
I would like to verify signed data however
signer's certificate has
already expired. I want only verify data
integrity.
If I use function xmlSecDSigValidate, it returns
negative value, so I
cannot determine if data was changed or not.
If I change local date it does work, however it
is not right way I
think..
How I can solve this problems?
Thanks:)
Roman Bouchner
=09
=09
_______________________________________________
xmlsec mailing list
xmlsec@aleksey.com
http://www.aleksey.com/mailman/listinfo/xmlsec
=20
=09
=20
=09
=09
_______________________________________________
xmlsec mailing list
xmlsec@aleksey.com
http://www.aleksey.com/mailman/listinfo/xmlsec
=20
------_=_NextPart_001_01C26FB9.394AC2BA
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D372472017-09102002><FONT face=3DArial color=3D#0000ff =
size=3D2>Aleksey:</FONT></SPAN></DIV>
<DIV><SPAN class=3D372472017-09102002><FONT face=3DArial color=3D#0000ff =
size=3D2> =20
I'll have to check the spec also -- but it simply *can't* work this =
way. If=20
I sign e-mail today and it can't be verified tomorrow even though =
nothing has=20
changed, that's *wrong*. I do know that signing of certs works this way =
but=20
that's handled by ensuring that the root cert is valid as of the =
expiration of=20
the child cert. While you are likely correct about CRLs .. none of the =
other=20
signing schemes other than certs behave this way (i.e., code signing =
(JAVA and=20
Authenticode) and S/Mime e-mail don't behave this =
way).</FONT></SPAN></DIV>
<DIV><SPAN class=3D372472017-09102002><FONT face=3DArial color=3D#0000ff =
size=3D2> =20
Depending on what the spec says about this and whether it's MUST, SHOULD =
or MAY,=20
will determine how to proceed here. If it's SHOULD or MAY and you feel =
strongly=20
that the current behavior is correct, what about an option for =
applications=20
where the data must be proved authentic essentially forever and the only =
desired=20
restriction is that the cert must have been valid when the data was=20
signed?</FONT></SPAN></DIV>
<DIV><SPAN class=3D372472017-09102002><FONT face=3DArial color=3D#0000ff =
size=3D2> =20
One way to look at this is that I'm giving my customers a perpetual =
license to=20
my application -- if it suddenly stops working in 9 months when my cert =
expires,=20
they aren't going to be happy. The commercial CA's won't even give you a =
cert=20
greater than 12 (maybe 24 if you press hard) months. There's no way to =
validate=20
code and other application meta-data (the XML issue at hand) for a =
greater=20
period of time if your assumption is correct. That just won't work=20
...</FONT></SPAN></DIV>
<DIV><SPAN class=3D372472017-09102002><FONT face=3DArial color=3D#0000ff =
size=3D2> =20
Please check on this and reconsider if it's at all an optional behavior =
(which I=20
strongly believe it is).</FONT></SPAN></DIV>
<DIV><SPAN class=3D372472017-09102002><FONT face=3DArial color=3D#0000ff =
size=3D2>Thanks!</FONT></SPAN></DIV>
<DIV><SPAN class=3D372472017-09102002><FONT face=3DArial color=3D#0000ff =
size=3D2> =20
Ferrell</FONT></SPAN></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Aleksey Sanin=20
[mailto:aleksey@aleksey.com] <BR><B>Sent:</B> Wednesday, October 09, =
2002=20
11:48 AM<BR><B>To:</B> Moultrie, Ferrell (ISSAtlanta)<BR><B>Cc:</B> =
Roman=20
Bouchner; xmlsec@aleksey.com<BR><B>Subject:</B> Re: [xmlsec] Verify =
signature=20
after certificate expired<BR><BR></FONT></DIV>I believe you are wrong =
here.=20
The certificate must be valid when signature is verified.<BR>Where =
"valid"=20
includes:<BR> 1) certificate is signed by another =
"valid"=20
cert or trusted root cert<BR> 2) certificate is not =
in the=20
CRL <BR> 3) the certificate purpose matches the =
action you=20
are going to do (sign, verify, etc.)<BR> 4) the =
certificate=20
is not expired<BR>All 4 items are important. I do not have an X509 =
spec around=20
so I could not prove my point.<BR>However, RFC 2560 (<A=20
class=3Dmoz-txt-link-freetext=20
=
href=3D"http://rfc.sunsite.dk/rfc/rfc2560.html">http://rfc.sunsite.dk/rfc=
/rfc2560.html</A>):<BR><PRE style=3D"PAGE-BREAK-AFTER: always"> An =
OCSP responder MAY choose to retain revocation information beyond
a certificate's expiration. The date obtained by subtracting this
retention interval value from the producedAt time in a response is
defined as the certificate's "archive cutoff" date.</PRE>Please note =
that=20
when certificate is expired the OSCP may remove the CRL from=20
memory!<BR><BR>Aleksey<BR><BR><BR><BR><BR>Moultrie, Ferrell =
(ISSAtlanta)=20
wrote:<BR>
<BLOCKQUOTE=20
=
cite=3Dmid121184A7DB1F9143BB5E3FACCB548757599CA6@atlmaiexcp02.iss.local=20
type=3D"cite"><PRE wrap=3D"">Aleksey:
Very important question here -- I want to make sure I understand your
reply. In general, it is not permitted to *sign* data after the signing
certificate has expired but it is allowed to *verify* data after
expiration. An example:
I sign my code today allowing the user to verify that it is uncorrupted
when he installs/runs it. My certificate expires in three months. If you
don't honor the signature any more at that point, then his code stops
working -- a very bad thing.=20
Another example:
I sign an e-mail to you today. Three months later my cert expires. Six
months later you try to read my e-mail and you're told the signature is
invalid. A bad thing.
As these two examples illustrate, it is *not* standard practice to
invalidate signatures because the signer's cert has expired. The only
date restrictions should be:
1) Signers cert *must* be valid as of the date the data was signed;
2) Root cert(s) *must* be valid as of the date they signed the
subsidiary cert (in fact, I believe proper practice is that CA's
shouldn't sign certs that extend beyond their own validity date).
The key concept is that user signing's *don't*, *shouldn't*, *mustn't*
expire just because the user's cert has expired. At that point, he can't
sign anything else until he renews his cert but everything he signed
still remains valid forever because it was valid when he signed it and
it hasn't changed.=20
Is there a problem here or did I just misunderstand something?
Thanks!
Ferrell
-----Original Message-----
From: Aleksey Sanin [<A class=3Dmoz-txt-link-freetext =
href=3D"mailto:aleksey@aleksey.com">mailto:aleksey@aleksey.com</A>]=20
Sent: Wednesday, October 09, 2002 11:05 AM
To: Roman Bouchner
Cc: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</A>
Subject: Re: [xmlsec] Verify signature after certificate expired
From the general security point of view the data are *not valid* if the
cert is expired.
If you really want to do this then you should take a look at the OpenSSL
cert
verification function and remove date check. However, this is
DANGEROUSE!
Aleksey.
Roman Bouchner wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hello
I would like to verify signed data however signer's certificate has
already expired. I want only verify data integrity.
If I use function xmlSecDSigValidate, it returns negative value, so I
cannot determine if data was changed or not.
If I change local date it does work, however it is not right way I
think..
How I can solve this problems?
Thanks:)
Roman Bouchner
_______________________________________________
xmlsec mailing list
<A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</A>
<A class=3Dmoz-txt-link-freetext =
href=3D"http://www.aleksey.com/mailman/listinfo/xmlsec">http://www.alekse=
y.com/mailman/listinfo/xmlsec</A>
=20
</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
_______________________________________________
xmlsec mailing list
<A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</A>
<A class=3Dmoz-txt-link-freetext =
href=3D"http://www.aleksey.com/mailman/listinfo/xmlsec">http://www.alekse=
y.com/mailman/listinfo/xmlsec</A>
</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>
=00
------_=_NextPart_001_01C26FB9.394AC2BA--