On Feb 24, 7:57 am, Frank Hecker <hec...@mozillafoundation.org> wrote: > Nelson B Bolyard wrote: > > 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. > > Yes, I should have mentioned this: My comments were with reference to > the non-EV case; IIRC Hongkong Post is not asking for EV treatment. If > and when Hongkong Post does ask for EV treatment then it's going to have > to support some mechanism by which Firefox et.al. can do revocation > checking without manual loading of CRLs. > > > 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. > > Seehttps://bugzilla.mozilla.org/show_bug.cgi?id=477244and the other > > bugs to which it links. > > Yes, I'm familar with this. > > A note for representatives of Hongkong Post: What's being implemented in > bug 477244 is a temporary measure only. If you want to support EV > certificates then I recommend that you support OCSP for revocation > checking of those certificates. Hongkong Post will definitely consider supporting OCSP for revocation checking if we decide to support EV certificates in future. BTW, recently we're studying a major upgrade to our systems and such consideration has already been put in place. > > > 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. > > For Hongkong Post: I think the suggestion to include URLs for both the > full and partial CRLs in your CRL DP extension is a good one. You could > do this for new certificates issued in the future. Hongkong Post is seriously looking into this suggestion right now. However, I can imagine that the decision will be very tough because, you know, traditionally revocation checking is done by the application developer or none. I have doubt whether most of application developers who rely on Hongkong Post certificate can support both CRLs in the CRLDP extension. > > For Nelson: What would be the recommended behavior of NSS for > certificates that have two different HTTP URLs in the CRL DP extension? > Would it just try to fetch each CRL in turn until it found one it liked? > (Obviously it couldn't tell in advance which was the full CRL and which > the partial.) > > > I have some more thoughts which I'll post as a followup to your earlier > > post about RFC 5280. > > I'm looking forward to reading your comments on this. As I wrote, I > don't yet fully understand this particular section of RFC 5280. > > 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
