Jean-Marc,
Jean-Marc Desperrier wrote:
Julien R Pierre - Sun Microsystems wrote:
[...]
I think many CAs will keep the serial numbers of expired certs on
their CRLs for a few years after expiration. But I don't think most
do that indefinitely. One big problem is that there is currently no
way to tell which CAs do and do not.
[...]
The policy could *strongly suggest* for CA to include the
expiredCertsOnCRL extension ?
http://www.imc.org/ietf-pkix/mail-archive/msg01962.html
It's quite unfortunate that efforts to include the description of
expiredCertsOnCRL inside RFC5280 from X.509 were not successful ("it has
already too many things" like if it didn't have a lot of things that are
massively less useful than expiredCertsOnCRL), but I don't think it a
good enough reason to deter any effort to use this simple but effective
extension to document which certs are and aren't removed from the CRL.
Thanks for that link.
NSS is still trying to catch up to RFC 3280, let alone 5280.
I agree it's unfortunate that this extension didn't make it into RFC
5280 . I don't have the time to particpate in ietf-pkix discussions,
though. Is this extension defined in any other RFC perhaps ?
Note this extension is pretty much irrelevant for SSL which is a
real-time protocol, but it is relevant to S/MIME where things may be
verified at dates other than the current date. But this opens another
can of worms since RFC 3280 / 5280 don't define an algorithm that works
well for dates other than the current date. I think such an algorithm
would require the use of an extension like expiredCertsOnCRL.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
