Kyle Hamilton wrote:
How did the language in 5280 change the behavior of critical CRL
extensions?
Briefly, RFC 5280 allows (and implicitly endorses) a scenario where the
implementation might not fully support a critical CIDP extension and all
that it entailed (i.e., handling partitioned CRLs in a proper way), but
nonetheless could (and, as implied by the RFC 5280 language, should)
check the CRL to see if the cert was revoked according to that CRL.
In other words, there are three possible scenarios:
1. No support of CIDP. The implementation does not recognize the CIDP
extension, and just ignores any CRL with that extension marked as
critical. In this scenario the implementation cannot determine at all
whether the certificate in question is revoked or not. (We're assuming
here and below that the implementation has no alternative means to check
revocation status.)
2. Full support of CIDP and partitioned CRLs. The implementation
recognizes the CIDP extension, and can do all the processing required to
handle partitioned CRLs. In this scenario the implementation can
determine definitively that either the certificate in question is
revoked or that it is not revoked.
3. Partial support. If it sees a CIDP extension the implementation
checks the CRL to see if the certificate is revoked, but doesn't do
anything else in terms of handling partitioned CRLs in the proper way.
In this scenario, if the certificate appears on this particular CRL then
the implementation can determine that the certificate in question is
revoked, but if the certificate does not appear on the CRL then the
implementation cannot conclude that it is not revoked, since the CRL in
question is not the full story.
RFC 3280 provided only for the full two scenarios (no support/unknown
status or full support/known status). The third scenario was introduced
by RFC 5280.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
