Hi Frank, On Nov 20, 9:21 pm, Frank Hecker <[EMAIL PROTECTED]> wrote: > Eddy Nigg wrote: > > The Wisekey case could be where we might draw the line. > > I'm not sure exactly which message (of mine or someone else's) you're > responding to. > > In any case I don't think there's a "bright line" between the various > scenarios involving independently-operated subordinate CAs. However in > general I would look at the extent to which the subordinates are > operating within a restricted context. E.g., they're associated with a > single enterprise, they're technically and contractually constrained to > operate within a relatively small set of domains, etc. At the other end > of the spectrum the subordinates are essentially general-purpose public > CAs, issuing certs to multiple customers, for arbitrary domains, etc. > > Based on the information available to us, WISeKey's subordinate CAs seem > to be at the restricted context end of the spectrum. >
Correct. We are at the extremely restricted context end of the spectrum. > > Provided that > > > - there is a *good compelling reason* for using sub-ordinate > > certificates in first place, limited to the domains under the control of > > the owner (via name-constraints) and with reasonable controls in place > > (like annual site visits, proper CA key generation, distribution and > > storage); > We implement all of the above mentioned controls. > Based on what Kevin Blackman wrote, one major reason for the approach > taken by WISeKey is the desire of customers to keep subscriber > information within enterprise boundaries and/or national borders. Given > the complexities of, e.g., privacy regulations in the US vs. the EU vs. > other jurisdictions, this seems to me a good reason for an enterprise to > operate its own subordinate CA as opposed to, for example, just acting > as a Registration Authority for a subordinate CA operated elsewhere. > This is exactly right. In fact several clients sensitive to this issue (Government Central Bank, Judicial Court, etc.) chose specifically the BlackBox system for this purpose. In some instances they also use managed PKI for issuing certificates to external collaborators. MPKI uses a CA in our data center and WISeKey performs the the email verification as it is not within the BB's client's domain. > > - name constraints in certificates are working as expected with NSS and > > Mozilla software *; > > Whether certificate-based name constraints are properly working or not, > I think this is more our problem than the CA's problem, provided that > the CA's cert don't cause actual technical errors in NSS/Mozilla. If a > CA is implementing technical measures we consider sound, then I think > they have done what we expect and require. > Frank, I agree with you. Our CA controls, audits, etc. are designed to ensure that all identities are validated appropriately prior to certificate issuance. BlackBox CAs are an extremely restricted CA context where certificates issued at the CA are restricted to domains owned by the organisation. It is not necessary for domain constraints to work in NSS software for our Root to be accepted, as the control's primary point of operation is PRIOR to certificate issuance. Even if domain constraints are not interpreted properly by NSS today, they will be in the future, and the certificates issued by our MPKI system using CAs in our DCs will be perfectly unaffected. I am sure that the name constraints implementation process will be much further along, and our Root still will not have propogated very far through the typical update mechanisms. On our behalf, I thus submit that it would be a fairly extreme and an unfair penalty to wait an additional year (the first discussion period was in January of this year) to be embedded, whereas the primary controls and practices we use have not changed significantly from that point in time. > (And I should add that if there problems in NSS that need additional > work to fix them, the Mozilla Foundation does have the ability to fund > such work.) > Mozilla will have our complete support, especially with QA. Regards, Kevin > Frank > > -- > Frank Hecker > [EMAIL PROTECTED] _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
