So. If I understand correctly: (I'll abbreviate Hongkong Post as HKP)
1) HKP issued certs currently do not cause problems. 2) HKP has been notified how their system may cause problems in the future. 3) HKP is not requesting EV status, so any EV-specific discussion is irrelevant at this time. 4) HKP meets all other requirements to be included in the root program. There is only one last question that I'm going to ask, since it is relevant here: Which version of PKIX (3280 or 5280) does HKP issue certificates to be conformant to? My understanding is that NSS supports 3280 (and not 5280); if there are certificates issued to 5280-not-3280 standards, this might cause issues and need to be readdressed. If they issue certificates to the 3280 profile, I have no problems with their inclusion. If they issue certificates to the 5280 profile, I withhold my assent pending additional technical evaluation. (not that my assent matters all that much anyway, but hey, if I've got a voice, I might as well use it, eh?) -Kyle H On Mon, Feb 23, 2009 at 8:00 PM, Frank Hecker <hec...@mozillafoundation.org> wrote: > Nelson B Bolyard wrote: >> >> Frank Hecker wrote, On 2009-02-20 16:53: > > <snip> >>> >>> "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. > > I thought this was weird, and am glad someone more knowledgeable than I > agrees. Thanks for the detailed explanation. > >> 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. > > If that were the case prior to CRL DP support being implemented then that > would cause a problem for every non-EV CA not supporting OCSP. Assuming CRL > DP support were implemented by that point then it would cause a problem for > every CA that didn't include a CRL DP extension in EE certs at all (are > there any of these in our root list?), or for whom the CRL DP extension > referenced (only) a partial CRL. > >> 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? > > We can certainly take the position that if we did need to force revocation > by default (which I think would require implementation of CRL DP support as > a prerequisite) and revocation checking of Hongkong Post certificates could > not be done by default (because their CRL DP extension referenced only a > partial CRL), then Firefox et.al. are going to throw errors on Hongkong > Post-issued SSL certs (and not display the associated sites) until/unless > Hongkong Post re-issues the certs with a CRL DP extension referencing a full > CRL. > > This is really up to Hongkong Post: Would they rather have their root cert > included now, knowing that certs they issue may stop working in future, or > would they rather wait to have the root included until such time as either > we implement CIDP support or they reissue all their certs to include a URL > for a full CRL? They can start adding the URL for the full CRL to the CRL DP > extension (along with the URL for the partial URL) when issuing new certs, > and this would minimize the likelihood of their certs causing problems in > future. > > To sum up: > > 1. Hongkong Post is not doing anything today contrary to our policy: Their > certs work as is in Firefox et.al., by default, and people who want > revocation checking can import the full CRL to enable it. In this respect > they're no different than any other non-EV CA not supporting OCSP. > > 2. We can imagine a scenario in which Hongkong Post-issued certificates > could cause technical problems. However at this point this is merely a > hypothetical scenario; we have no idea whether it will come to pass or not. > > 3. If the hypothetical scenario were to come to pass, we don't need to do > anything ourselves to fix the problem. Hongkong Post could fix the problem > itself, by reissuing certs with the URL for the full CRL included. (Or even > more simply, it could simply publish the full CRL at the URL previously used > for the partial CRL.) I think Hongkong Post would be strongly motivated to > fix the problem one way or the other. > > So I don't think including the Hongkong Post root would cause problems for > either us or our users. It would just mean that Hongkong Post will need to > do some work of its own in order to minimize chances of its certs having > problems in future. > > 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 > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
