Frank Hecker wrote, On 2009-02-20 11:15:
> 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.
Here is some info that should help with understanding all this.
1) NSS has a "CRL cache" in memory, and a CRL Store (part of the cert DB)
on disk. Any CRL that is actually used must be in the CRL cache. ALL
CRL based revocation checking is done by using the info in the CRL cache
only.
2) the act of importing a CRL into the CRL cache (and/or the Store) is
a separate act, independent of the act of checking a cert's revocation.
A failure that occurs while trying to import a CRL is separate from any
result that may come from trying to check a cert's revocation against
the set of cached CRLs.
3) NSS presently does not allow CRLs with critical CIDP extensions to be
imported into the CRL cache. It reports an error to an attempt to do so.
4) When doing CRL revocation checking, NSS will always check the CRL cache
first. If it finds no answer there (or the answer found there is too old)
then (and only then) it might (some day) go and attempt to fetch a CRL
from the URL in a cert's CDP extension (or from the URL from which it had
previously fetched an older copy of the CRL). That attempt might succeed
or might fail, but either way, afterwords, the code will again check the
CRL cache.
5) Ultimately, the answer to a revocation test depends only on the results
found (or not found) in the CRL cache, and do NOT depend directly on the
results of any attempt to fetch or import a CRL. This means that, if an
attempt to import a CRL fails, and no earlier CRL from that same issuer
has been imported, then the results of a revocation test for a cert that
might have been in that CRL will be exactly the results expected for the
case where we have no CRL for that issuer. In that case, the revocation
status is unknown.
6) When PSM asks NSS (through libPKIX) to do revocation checking, PSM
tells NSS exactly (in GREAT detail) how to handle the case where no
revocation information for the cert is available (e.g. whether to treat
unknown revocation status as success or failure).
> 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. (snip)
> Do I have this right?
No, the passage you quoted from the RFC above is quite specific about that.
Unless NSS understands CIDP (which implies that it understands
partitioned CRLs), it must either find another CRL that it does understand
or else treat the cert as having no revocation information available
(status unknown). PSM tells NSS how to handle certs with unknown revocation
status.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
