Nelson B Bolyard wrote:
Here is some info that should help with understanding all this.
Thanks, this is very useful. So to sum up my understanding:
If NSS had support for CRL DP, but no support for CIDP, then what would
happen with Hongkong Post (assuming no changes to its current practices,
and no manual loading of the full CRL) is that the partitioned CRL would
be fetched from the URL in the CRL DP extension, NSS would fail to
import the CRL, there would be no Hongkong Post CRL in the CRL cache,
NSS would treat the Hongkong Post end entity certs as having an unknown
revocation status, and based on PSM's instructions this would be treated
as either a success or failure. I presume that today PSM is having NSS
treat unknown revocation status as a success, at least for non-EV certs
(which is the case here) and in the future PSM could continue to do this
(again, at least for non-EV certs).
Is this correct?
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.
One open question is whether an error message should be displayed to the
user if NSS fails to import a CRL with critical CIDP extension that it
got via the CRL DP mechanism. I guess this is analogous to, e.g.,
failure to get a proper OCSP response from an OCSP server, but I don't
happen to know what is done in that case in Firefox and other
Mozilla-based clients.
Another question is about the idea of having two CRLs referenced in the
CRP DP extension, a full CRL referenced by one URL and a partitioned CRL
referenced by another URL. At first glance this seems to be allowed by
RFC 5280 (based on my reading of section 4.2.1.13), but I'm no expert on
the subject. If NSS did support this scheme then presumably it would
cycle through the URLs in the CRP DP extension, fail to load the
partitioned CRL, but succeed in loading the full CRL, so that it would
then have a valid CRL in the CRL cache.
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).
OK, I'm still confused a bit here. To quote RFC 5280 again: "Although
the [CIDP] extension is critical, conforming implementations are not
required to support this extension. However, 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." [emphasis
added]
The key phrase to me is "not listed on this CRL": Suppose the
"conforming implementation" does not support CIDP, and also does not
have another CRL that doesn't use CIDP. Then the RFC says that
certificates not listed on the CRL with CIDP extension should be treated
as having unknown status. However, what happens if the certificate *is*
on the CRL with the CIDP extension? The RFC is silent on this point, but
the implication seems to be that if the certificate is on the list then
the implementation *could* treat it as being revoked.
Now, the implementation could instead take the approach that *all* certs
would be treated as having unknown revocation status, whether they are
listed the CRL with CIDP extension or not -- in other words, the
implementation could just treat the CRL as if it were not present at
all. That seems to be the approach you've taken. That would seem to be
consistent with the strict wording of the RFC, unless there's something
else in the RFC to the contrary.
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
