Frank Hecker wrote, On 2009-02-20 16:53: > 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.
Yes. The only major concern there is frequency with which it fetches and discards those CRLs. > 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). I believe that's correct for non-EV certs. If HK Post is not requesting to be an EV CA, then maybe the EV discussion is moot for this thread. >> 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. I wish there was a short answer to that. I've been wishing that for several days now instead of replying to this email. :( Yes, I think it is mostly analogous. Maybe some of the other contributors to this thread can speak to what FF does when OCSP itself fails. One important difference between CRLs and OCSP is that an OCSP check is NEVER made unless the cert has the AIA extension that says "OCSP works for this cert". But CRL checks are done for all certs at all times. The presence of a CDP extension in a cert has never been a prerequisite to checking to see if we have a CRL for the issuer of that cert, and if so, checking that CRL for the presence of this cert's serial number. That works well with full CRLs. > 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. Yes, probably not in that order. > 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. Yes, I think it probably it. > 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. That matches my own expectation. :) > 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." RFC 3280 stopped there. The next sentence is found only in RFC 5280. > "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] That is a rather strange statement, IMO. In RFC 3280, each extension was either supported or not. There was no third state. And when a Cert or CRL contained an unsupported critical extension, there was only one permitted behavior for the implementation that does not support the extension: reject that cert or CRL. That means: don't honor it. This sentence suggests a third state for extensions, one which we might call "Recognized but not fully supported". It suggests that if a CRL has only ONE unsupported critical extension, and the implementation recognizes that unsupported extension as being CIDP, then it may choose to honor the CRL, at least for the purpose of positively identifying the cert as revoked, but the implementation may not conclude affirmatively that the cert was good merely because the cert is not listed in that CRL. Implementing that complicates the logic. In some sense, to do that, an implementation would have to understand and mostly support partial CRLs. An implementation would need to implement all aspects of partial CRLs (meaning, multiple concurrent CRLs for one issuer) except for their CIDP extension contents. Interpreting the extension is the easy part. The reason for not supporting CIDP extensions in CRLs isn't that you cannot parse them. It's because your storage and processing of CRLs doesn't have all it needs to fully handle multiple CRLs per issuer. If an implementer is going to develop all that partial CRL capability, he certainly would not then stop and say "oh, I won't support the CIDP extension." Indeed, the CIDP contents are NECESSARY to properly organize multiple CRLs per issuer, and know which of the existing partial CRLs for that issuer to replace (if any) when a newer partial CRL arrives. So, in short, I think NSS will not attempt to honor partial CRLs until it can fully handle partial CRLs. The caching and searching implications of partial CRLs are huge. For me, the bottom line is that RFC 5280 does not require conforming implementations to implement partial CRLs, and certs whose CDP extensions list only partial CRLs (and no OCSP) can never be affirmatively known to be good (to be not revoked) unless the user has some other out-of-band method of finding a full CRL for that issuer. Now, imagine with me that some short time down the road, because of some new attack, we conclude that it's no longer safe to treat non-EV SSL server certs as OK by default in the absence of revocation information that affirmatively identifies the cert as unrevoked. It would force a choice of either implementing full support for partial CRLs or (effectively) distrusting HK Post's certs. I think that's a high price to pay. Is the ability to support HK Post's certs worth all that investment? > 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. Right. The implementation treats the CRL as if it is not in the cache, because it is not in the cache. :) > That would seem to be consistent with the strict wording of the RFC, > unless there's something else in the RFC to the contrary. That's the only mode of operation that meets the requirements of RFC 3280. RFC 5280 attempts to be more permissive, but it smacks of a design idea from someone who thinks it might be a good idea, but has never implemented any of it. (Aside: I fear the IETF has forgotten the lessons from Michael Padlipsky's book, http://www.iuniverse.com/Bookstore/BookDetail.aspx?BookId=SKU-000002499 first published in 1985.) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
