Jean-Marc Desperrier wrote:
So if you do CRL checking at all, there are good reasons to report this check as failed if you only have access to a CRL whose nextUpdate is in the past. Except of course if you have an date argument in the check that says "Check validity for *this* date" and the date predates the nextUpdate of the available CRL.
First, let me point out that the RFC only recommends an algorithm to verify certificates and signatures on the current date, but not at dates in the past.
Second, a certificate may be retroactively revoked, such as in the case where a private key was compromised, but the fact wasn't noticed until a week later. Thus, even if you have a CRL which nextUpdate is after the date you are trying to verify, this may not be sufficient. The latest CRL may still contain that certificate with a prior revocation date.
There are even more intricate issues for certificates with retroactive start dates. This is again a case that RFCs do not preclude, and is impossible to detect, due to the lack of an "issuanceDate" field in the certificate.
The point is, to do a truly accurate check according to RFCs, you can only verify a signature or certificate at the current date, with the latest currently available CRL. Anything else is "best effort" with unspecified behavior. Which NSS does try to attempt, but there is no guarantee on the results.
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
