On Wed, January 29, 2014 10:50 am, Jeremy Rowley wrote: > As outlined in the root inclusion request, we need to embed all five for > fully support our community. Here's why: > > 1) These root certificates are used in many different systems, not just > Mozilla. If Mozilla doesn't embed all of them, the ones not embedded will > essentially be untrusted. The roots proposed are simply replacements for > our existing root certificates, and our plan is to phase out the current > DigiCert root certificates once there is sufficient ubiquity in the new > roots.
For other PKIs, the transition is handled through cross-certification. That said, I'm a little curious about the inclusion of both the SHA-256 version and the ECC version, since the signatures will be incompatible (that is, G2 uses RSA-2048, G3 uses ECC). It doesn't seem that the ECC cert will "replace" the Assured ID root so much as be used as a compliment to it. If it was intended to replace, why not replace ubiqutiously? That is, have the SHA-256 root for systems that don't support ECC, and have a cross-signed SHA-256 intermediate signed by the ECC root (for systems that do). That seems to reflect the plan to "replace" > > 2) Each root has a different purpose. Assured ID is the root we use to > provide specialized certificates in the government and education space. > Many of these entities use Mozilla to access resources. The Global Root > CA > is our current SSL root. This root is intended to provide optimum > performance without sacrificing security. This root will emphasize the > results of the CAB Forum performance working group. The proposed high > assurance root is going to be our 4096 high security root. May customers > are more concerned a compromise of 2048 than browser speed, making a > bigger > key size perfect in meeting their needs. In each case, not embedding the > root will force the user to either adopt a different browser or accept a > non-ideal operating environment. > > 3) Requiring a single root certificate forces a CA to put their entire > trust > on either ECC or RSA (depending on the root selected). If a security risk > is detected with the selected algorithm, the CA is left unable to support > its customers. But with cross-certifications, how is this a problem? If you cross-signed your SHA-256 root with ECDSA on the ECC root (G3), and then later it was determined that ECDSA is weak and you need to use some post-quantum-crypto alg, why couldn't you just cross-sign the SHA-256 root and continue operating? > > 4) By embedding one root certificate, NSS users are disadvantaged in SSL > performance. If we have to add another intermediate to the architecture > then > the SSL handshake gets even more bogged down. Define "we"? Brian's proposal was that the additional intermediate is added within NSS itself - that is, it does not affect the SSL/TLS handshake. > > 5) Having only one root with multiple sub CAs emphasizes the "Too Big To > Fail" issue. At DigiCert, and in the spirit of the Microsoft root policy, > we try to segregate the type of certificates issued off a single > intermediate. Relying on a single root consolidates everyone into a single > point of shared trust, forcing users to trust every kind of DigiCert > certificate. Having multiple roots allows a root operator to trust only > part of what DigiCert issues. > > Thanks, > > Jeremy > This is, I think, the most compelling argument. I strongly believe that users are better protected NOT by adding a meta-CA (as Brian Smith proposed), but instead by having *fewer* "root" CAs and more intermediates-that-are-roots, segregated by policy flags. That is, a single root for issuing SSL/TLS certificates. If a CA also wishes to do things like code-signing or e-mail signing, they create additional roots for these. This strengthens the Mozilla Root CA policy by allowing Mozilla to say that "All certificates issued at-or-below this root must conform". The current Baseline Requirements, which are referenced by Mozilla, are ambiguous in this respect, because they apply to certificates which are "intended" to be used for SSL/TLS - thus creating a loophole for certificates that aren't "intended" to be used, but which are technically capable, being exempted from the BRs. I do think DigiCert should *not* be "punished" (eg: by waiting for the features Brian Smith has suggested but which are not implemented yet), especially when part of the complexity is due to them offering ECC certs, which offers better performance for everyone. > -----Original Message----- > From: dev-security-policy > [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla > .org] On Behalf Of Gervase Markham > Sent: Wednesday, January 29, 2014 4:31 AM > To: Brian Smith; mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: DigiCert Request to Include Renewed Roots > > On 29/01/14 05:08, Brian Smith wrote: > >>> Benefits of my counter-proposal: > >>> 1. Fewer roots for us to manage. > > Only for a very narrow definition of the word "root". There's the same > number of embedded trust anchor points. > > >>> 3. Because of #1, there is potential for us to design a simpler root > >>> certificate management UI. > > I'm not sure we should let our UI concerns shape other people's PKIs. > > >>> 4. We can do optimizations with the preloading of intermediates to > >>> avoid building the whole chain every time. (That is, we can > >>> precalculate the trust of the intermediates.) > > Have you measured the time saving of such an optimization? > > > First, let me split my proposal into two parts: > > > > Part 1: > > I'm proposing that we add five certs that are equivalent to the five > > certs that DigiCert wants to add, EXCEPT that only one of them would > > be a trusted root, and the other four would be intermediates of that > > root. So, as far as what I'm proposing here is concerned, there would > > be no change as to what websites would be required or not required to > > send in their SSL handshakes, if DigiCert continues to require an > > intermediate between the end-entity cert and any of those five certs. > > > > Part 2: > > It is considered bad practice by some to issue certificates directly > > from a root. > > While people often put it like that, your comment has made me realise that > it's actually a shorthand. What's actually bad practice is issuing > certificates directly from a certificate which is embedded in a browser. > That's because, in practice, it requires a browser update to revoke such a > certificate. (Or would that not be the case for the DigiCert > root/intermediate things in your plan?) > > Having an intermediate between the embedded trust anchor and the EE cert > means that you can rotate online intermediates regularly, and the > compromise > or failure of one online root doesn't kill your entire cert ecosystem. > It's > hard to enforce all of these good practices in code, so we instead say > "don't issue directly off embedded roots" and hope they do the rest as > well. > (With mixed success.) > > > I understand that it is not 100% great to do things that encourage > > websites to skip the inclusion of intermediates in their certificate > > chains, but we're currently on the losing side of this compatibility > > issue since we also do not implement caIssuers. > > If you think this is bad, why don't you propose we do so? > > Gerv > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
