Re: Revocation publishing lifecycle

I'd say it SHOULD, in the RFC2119 way.
But really, it's usage dependent.

If the certificates issued by CA1 are web-server certs, a client will
receive an expired certificate. Looking at RFC5280 section 6.1, the
condition (d) is not satisfied because the "time in question" is "right
now". It therefore doesn't care if the CRL is also expired.

If the certificates issued by CA1 are signing certs, and you're validating
a signed object with a timestamp (that you have validated, trusted, etc),
then you need to have a CRL with a nextUpdate later than the current time
(not the time expressed in the timestamp) or without a nextUpdate, and
check if the certificate was valid at the date expressed in the timestamp.
This can fail if you don't have a valid CRL, and you may have a non
conclusive answer if the CA doesn't notify you that the CRL includes
expired certificates (either by local policy, or by inclusion of the
expiredCertsOnCRL extension).

And of course, if the CA is asked to follow
constraints/requirements/policies, those may express that the CA MUST have
a valid CRL for its entire lifetime (and even after).

2016-07-27 18:11 GMT+02:00 daniel bryan <[email protected]>:

> Hello, Should a CA provide a CRL for it's entire lifetime?
>
> For example, CA1 is good for 4 years, and the first year it issues 1 year
> certs and provides revocation status via CRLs. Year 2, CA1 stops issuing,
> and a new issuing CA2 is stood up. Year 3, all the certificates from CA1
> have expired.
>
> Should CA1 make revocation data available until CA1 expires, so that users
> can be informed of the revocation status of expired certificates. (EG:
> opening an old email from a revoked user).
>
> Thanks,
>
> --Dan
>



-- 
Erwann.

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix