Frank Hecker wrote:
Option 4: Hongkong Post makes no changes to either its CRLs or its end
entity certs, and NSS ignores partitioned CRLs encountered in CRL DP
processing. In this option Hongkong Post would make no changes
whatsoever to its current practices. NSS would fetch the partitioned CRL
located at the URL referenced in the CRL DP extension, find that it had
a CRL IDP extension marked as critical, and then simply ignore the CRL,
treating the revocation status of the certificate as unknown.
Here I'm following RFC 5280, section 5.2.5 ("Issuing Distribution
Point"): "... implementations that do not support this extension MUST
either treat the status of any certificate not listed on this CRL as
unknown or locate another CRL that does not contain any unrecognized
critical extensions." As I read it, this allows NSS to not throw an
error but instead to simply act as if no CRL were present -- in other
words, as would happen today by default in the absence of CRL DP support.
Now that I've reread this I think what I wrote here is incorrect: If I'm
reading RFC 5280 correctly, if NSS found a critical IDP extension on a
CRL, and if this were the only CRL it knew about, then it could (and
should) check the cert against the CRL. If the cert were on the CRL then
it would be treated as revoked; however if the cert were not on the CRL
then its revocation status would be treated as unknown by NSS. What
happened then would be up to PSM or whatever other higher-level code
were calling NSS.
Do I have this right?
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
