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. 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. 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. 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 -----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
