[xmlsec] Verify signature after certificate expired
Roman Bouchner
bouchner at aipsafe.cz
Thu Oct 10 00:55:59 PDT 2002
The main problem as I understand is to have sign date which I can
trust. For example if you try to sign exe file in Windows, you have to
add datetime stamp from datetime cert authority. Then the code is
valid after certificate expire.
It could be very useful when I use function xmlSecDSigValidate to know the
reason why validation fails(expired certificate) and also to know that
data weren't changed.
Roman
9. øíjna 2002, 19:28:04, bylo napsano:
MFI> Aleksey:
MFI> I'll have to check the spec also -- but it simply *can't* work this
MFI> way. If I sign e-mail today and it can't be verified tomorrow even
MFI> though nothing has changed, that's *wrong*. I do know that signing of
MFI> certs works this way but that's handled by ensuring that the root cert
MFI> is valid as of the expiration of the child cert. While you are likely
MFI> correct about CRLs .. none of the other signing schemes other than certs
MFI> behave this way (i.e., code signing (JAVA and Authenticode) and S/Mime
MFI> e-mail don't behave this way).
MFI> Depending on what the spec says about this and whether it's MUST,
MFI> SHOULD or MAY, will determine how to proceed here. If it's SHOULD or MAY
MFI> and you feel strongly that the current behavior is correct, what about
MFI> an option for applications where the data must be proved authentic
MFI> essentially forever and the only desired restriction is that the cert
MFI> must have been valid when the data was signed?
MFI> One way to look at this is that I'm giving my customers a perpetual
MFI> license to my application -- if it suddenly stops working in 9 months
MFI> when my cert expires, they aren't going to be happy. The commercial CA's
MFI> won't even give you a cert greater than 12 (maybe 24 if you press hard)
MFI> months. There's no way to validate code and other application meta-data
MFI> (the XML issue at hand) for a greater period of time if your assumption
MFI> is correct. That just won't work ...
MFI> Please check on this and reconsider if it's at all an optional
MFI> behavior (which I strongly believe it is).
MFI> Thanks!
MFI> Ferrell
MFI> -----Original Message-----
MFI> From: Aleksey Sanin [mailto:aleksey at aleksey.com]
MFI> Sent: Wednesday, October 09, 2002 11:48 AM
MFI> To: Moultrie, Ferrell (ISSAtlanta)
MFI> Cc: Roman Bouchner; xmlsec at aleksey.com
MFI> Subject: Re: [xmlsec] Verify signature after certificate expired
MFI> I believe you are wrong here. The certificate must be valid when
MFI> signature is verified.
MFI> Where "valid" includes:
MFI> 1) certificate is signed by another "valid" cert or trusted root
MFI> cert
MFI> 2) certificate is not in the CRL
MFI> 3) the certificate purpose matches the action you are going to do
MFI> (sign, verify, etc.)
MFI> 4) the certificate is not expired
MFI> All 4 items are important. I do not have an X509 spec around so I could
MFI> not prove my point.
MFI> However, RFC 2560 ( http://rfc.sunsite.dk/rfc/rfc2560.html
MFI> <http://rfc.sunsite.dk/rfc/rfc2560.html> ):
MFI> An OCSP responder MAY choose to retain revocation information beyond
MFI> a certificate's expiration. The date obtained by subtracting this
MFI> retention interval value from the producedAt time in a response is
MFI> defined as the certificate's "archive cutoff" date.
MFI> Please note that when certificate is expired the OSCP may remove the CRL
MFI> from memory!
MFI> Aleksey
MFI> Moultrie, Ferrell (ISSAtlanta) wrote:
MFI> Aleksey:
MFI> Very important question here -- I want to make sure I understand your
MFI> reply. In general, it is not permitted to *sign* data after the signing
MFI> certificate has expired but it is allowed to *verify* data after
MFI> expiration. An example:
MFI> I sign my code today allowing the user to verify that it is uncorrupted
MFI> when he installs/runs it. My certificate expires in three months. If you
MFI> don't honor the signature any more at that point, then his code stops
MFI> working -- a very bad thing.
MFI> Another example:
MFI> I sign an e-mail to you today. Three months later my cert expires. Six
MFI> months later you try to read my e-mail and you're told the signature is
MFI> invalid. A bad thing.
MFI> As these two examples illustrate, it is *not* standard practice to
MFI> invalidate signatures because the signer's cert has expired. The only
MFI> date restrictions should be:
MFI> 1) Signers cert *must* be valid as of the date the data was signed;
MFI> 2) Root cert(s) *must* be valid as of the date they signed the
MFI> subsidiary cert (in fact, I believe proper practice is that CA's
MFI> shouldn't sign certs that extend beyond their own validity date).
MFI> The key concept is that user signing's *don't*, *shouldn't*, *mustn't*
MFI> expire just because the user's cert has expired. At that point, he can't
MFI> sign anything else until he renews his cert but everything he signed
MFI> still remains valid forever because it was valid when he signed it and
MFI> it hasn't changed.
MFI> Is there a problem here or did I just misunderstand something?
MFI> Thanks!
MFI> Ferrell
MFI> -----Original Message-----
MFI> From: Aleksey Sanin [ mailto:aleksey at aleksey.com
MFI> <mailto:aleksey at aleksey.com> ]
MFI> Sent: Wednesday, October 09, 2002 11:05 AM
MFI> To: Roman Bouchner
MFI> Cc: xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
MFI> Subject: Re: [xmlsec] Verify signature after certificate expired
MFI> From the general security point of view the data are *not valid* if the
MFI> cert is expired.
MFI> If you really want to do this then you should take a look at the OpenSSL
MFI> cert
MFI> verification function and remove date check. However, this is
MFI> DANGEROUSE!
MFI> Aleksey.
MFI> Roman Bouchner wrote:
MFI> Hello
MFI> I would like to verify signed data however signer's certificate has
MFI> already expired. I want only verify data integrity.
MFI> If I use function xmlSecDSigValidate, it returns negative value, so I
MFI> cannot determine if data was changed or not.
MFI> If I change local date it does work, however it is not right way I
MFI> think..
MFI> How I can solve this problems?
MFI> Thanks:)
MFI> Roman Bouchner
MFI> _______________________________________________
MFI> xmlsec mailing list
MFI> xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
MFI> http://www.aleksey.com/mailman/listinfo/xmlsec
MFI> <http://www.aleksey.com/mailman/listinfo/xmlsec>
MFI> _______________________________________________
MFI> xmlsec mailing list
MFI> xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
MFI> http://www.aleksey.com/mailman/listinfo/xmlsec
MFI> <http://www.aleksey.com/mailman/listinfo/xmlsec>
More information about the xmlsec
mailing list