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:[EMAIL PROTECTED]] MFI> Sent: Wednesday, October 09, 2002 11:48 AM MFI> To: Moultrie, Ferrell (ISSAtlanta) MFI> Cc: Roman Bouchner; [EMAIL PROTECTED] 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:[EMAIL PROTECTED] MFI> <mailto:[EMAIL PROTECTED]> ] MFI> Sent: Wednesday, October 09, 2002 11:05 AM MFI> To: Roman Bouchner MFI> Cc: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 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> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> MFI> http://www.aleksey.com/mailman/listinfo/xmlsec MFI> <http://www.aleksey.com/mailman/listinfo/xmlsec> MFI> _______________________________________________ MFI> xmlsec mailing list MFI> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> MFI> http://www.aleksey.com/mailman/listinfo/xmlsec MFI> <http://www.aleksey.com/mailman/listinfo/xmlsec> _______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec