Frank Hecker wrote, On 2009-02-23 14:42 PST: > Based on the discussion so far, my understand is as follows: In the near > term Hongkong Post's certificates will work OK in Firefox et.al. with > the default settings (i.e., no CRL checking), and users wanting to do > revocation checking can manually import the full CRL.
Yes, i think that's right. > In the longer term, when CRL DP support gets implemented in NSS, it > appears that this situation won't change: NSS will ignore the CRL with > the CIDP extension when trying to auto-fetch a CRL based on the CRL DP > extension in Hongkong Post certificates, and (assuming PSM doesn't throw > an error based on this) the certificates will work with default Firefox > et.al. settings (with no revocation checking being done, of course). > Again, users wanting to do revocation checking can manually import the > full CRL. A few comments: 1. As you may know, the EV spec says that a client should not give a cert the full EV treatment unless/until it has done some successful revocation check (CRL or OCSP, this year) at least on the EE cert. Beginning with FF 3.1 (IINM) FF will enforce that rule. This will mean that certs whose revocation cannot be checked may be OK for non-EV SSL but won't be recognized as EV certs. 2. FF has a periodic CRL fetcher that historically has fetched no CRLs until the user loads the first one, and requests that FF automatically fetch additional ones from the same thereafter. Work is underway to pre-load FF 3.1's periodic CRL fetcher with the URLs of the EV CAs who use only CRLs, so that FF 3.1 will attempt to fetch them, as if the user had manually downloaded those CRLs. Details are still being worked out. See https://bugzilla.mozilla.org/show_bug.cgi?id=477244 and the other bugs to which it links. 3. Once CRLDP-based fetching comes into play, there will be a lot of wasted fetching of useless CRLs from HongKong Post's server, done by browsers that visit servers whose certs were issued by HK Post. I say "a lot" because those certs, which are discarded due to presence of an unsupported critical extension, won't get cached. Therefore, every time the browser gets one of those certs, it will see if it has a CRL for that CA in its cache, will not find one, and will initiate a fetch. This is my BIG concern for the HK Post CA. In anticipation of that, I've suggested that our CRL cache should be able to cache failed fetch attempts, and avoid retries more frequently than once every N minutes (where N may be very large). This might be OK if the HK Post's certs listed both partitioned and full CRLs in the cert's CDP extension, because the automatic CDP-based fetcher would eventually fetch a full CRL, and then cache it. But as long as the HK Post certs list ONLY the partial CRL, it's a pain. > Based on this, my conclusion is that Hongkong Post's use of CRLs with > the CIDP extension is not an issue that would prevent our including the > root. I'll wait on Kathleen's recommendation and then make a final decision. I have some more thoughts which I'll post as a followup to your earlier post about RFC 5280. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
