DigiCert Request to Include Renewed Roots

[Kathleen Wilson]

DigiCert has applied to include 5 new root certificates that will
eventually replace the 3 DigiCert root certificates that were included
in NSS via bug #364568. The request is to turn on all 3 trust bits and
enable EV for all of the new root certs.

1) DigiCert Assured ID Root G2 -- This SHA-256 root will eventually
replace the SHA-1 “DigiCert Assured ID Root CA” certificate.

2) DigiCert Assured ID Root G3 -- The ECC version of the Assured ID root.

3) DigiCert Global Root G2 -- This SHA-256 root will eventually replace
the SHA-1 “DigiCert Global Root CA” certificate.

4) DigiCert Global Root G3 -- The ECC version of the Global root.

5) DigiCert Trusted Root G4 -- This SHA-384 root will eventually replace
the SHA-1 “DigiCert High Assurance EV Root CA” certificate.

DigiCert is a US-based commercial CA with headquarters in Utah. DigiCert
provides digital certification and identity assurance services
internationally to a variety of sectors including business, education,
and government.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=908827

And in the pending certificates list:
http://www.mozilla.org/about/governance/policies/security-group/certs/pending/

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8359954

Noteworthy points:

* The primary documents, the CP and CPS, are in English.

DigiCert Legal Repository: http://www.digicert.com/ssl-cps-repository.htm

CP: http://www.digicert.com/docs/cps/DigiCert_CP_v405-May-2-2013.pdf

CPS: http://www.digicert.com/docs/cps/DigiCert_CPS_v405-May-2-2013.pdf

* CA Hierarchy: All of the new root certs will have internally-operated
intermediate certificates for issuing SSL, email, and code-signing
certificates

* The request is to turn on all 3 trust bits and enable EV for all of
the new root certs.

** CPS section 3.2.2 -- DV SSL Server Certificates: DigiCert validates
the Applicant’s right to use or control the domain names that will be
listed in the certificate using one or more of the following procedures:
1. Relying on publicly available records from the Domain Name Registrar,
such as WHOIS or other DNS record information;
2. Communicating with one of the following email addresses:
webm...@domain.com, admini...@domain.com, ad...@domain.com,
hostmaster@domain, postmaster@domain, or any address listed in the
technical, registrant, or administrative contact field of the domain’s
Registrar record;
3. Requiring a practical demonstration of domain control (e.g.,
requiring the Applicant to make a specified change to a live page on the
given domain); and/or
4. A domain authorization letter, provided the letter contains the
signature of an authorized representative of the domain holder, a date
that is on or after the certificate request, a list of the approved
fully‐qualified domain name(s), and a statement granting the Applicant
the right to use the domain names in the certificate. DigiCert also
contacts the domain name holder using a reliable third‐party data source
to confirm the authenticity of the domain authorization letter; and/or
5. A similar procedure that offers an equivalent level of assurance in
the Applicant’s ownership, control, or right to use the Domain Name.
DigiCert verifies an included country code using (a) the IP Address
range assignment by country for either (i) the web site’s IP address, as
indicated by the DNS record for the web site or (ii) the Applicant’s IP
address; (b) the ccTLD of the requested Domain Name; or (c) information
provided by the Domain Name Registrar.

** CPS section 3.2.2
*** OV SSL Server Certificates: DigiCert validates the Applicant’s right
to use or control the Domain Name(s) that will be listed in the
Certificate using the DV SSL Server Certificate validation procedures above.
** EV SSL and EV Code Signing Certificates: Information concerning
organization identity related to the issuance of EV Certificates is
validated in accordance with the EV Guidelines.
** Level 1 Client Certificates - Enterprise: DigiCert verifies
organizational control over the email domain using authentication
procedures similar to those used by DigiCert when establishing domain
ownership by an organization before issuance of a DV or OV SSL Server
Certificate.
*** Level 2, 3, and 4 Client Certificates: If the certificate contains
organization information, DigiCert obtains documentation from the
organization sufficient to confirm that the individual has an
affiliation with the organization named in the certificate.

** CPS section 3.2.2: Before issuing an SSL certificate with a domain
name that has not been previously verified as within the scope of an
RA’s or other Delegated Third Party’s allowed domain names, DigiCert
establishes that the RA or Delegated Third Party has the right to use
the Domain Name by independently verifying the authorization with the
domain owner, as described above, or by using other reliable means, such
as performing a DNS lookup to determine whether there is a matching DNS
record that points to the Delegated Third Party’s IP address or domain
namespace.

** For Authentication of Individual Identity see CPS section 3.2.3 for
details, because this depends on the usage and verification level of the
certificate.

** CPS section 3.2.3 - Level 1 Client Certificates – Personal (email
certificates): DigiCert or an RA verifies Applicant's control of the
email address or website listed in the certificate.

** CPS section 3.2.3 - OV SSL Server Certificates and Object Signing
Certificates (issued to an individual):
1. DigiCert or the RA obtains a legible copy, which discernibly shows
the Applicant’s face, of at least one currently valid government‐issued
photo ID (passport, driver’s license, military ID, national ID, or
equivalent document type). DigiCert or the RA inspects the copy for any
indication of alteration or falsification.
2. DigiCert may additionally cross‐check the Applicant’s name and
address for consistency with available third party data sources.
3. If further assurance is required, then the Applicant must provide an
additional form of identification, such as recent utility bills,
financial account statements, credit card, an additional ID credential,
or equivalent document type.
4. DigiCert or the RA confirms that the Applicant is able to receive
communication by telephone, postal mail/courier, or fax.
If DigiCert cannot verify the Applicant’s identity using the procedures
described above, then the Applicant must submit a Declaration of
Identity that is witnessed and signed by a Registration Authority,
Trusted Agent, notary, lawyer, accountant,
postal carrier, or any entity certified by a State or National
Government as authorized to confirm identities.

** For Validation of Authority see CPS section 3.2.5 for details,
because this depends on the usage and verification level of the certificate.

CPS section 3.2.5 – Object Signing Certificates: The requester’s contact
information is verified with an authoritative source within the
applicant’s organization (e.g. corporate, legal, IT, HR, or other
appropriate organizational sources) using a reliable method of
communication. The contact information is then used to confirm the
authenticity of the certificate request.

* EV Policy OID: 2.16.840.1.114412.2.1
EV treatment is requested for all of the new root certs.

* Root Cert URLs
https://www.digicert.com/digicert-root-certificates.htm
https://www.digicert.com/CACerts/DigiCertAssuredIDRootG2.crt
https://www.digicert.com/CACerts/DigiCertAssuredIDRootG3.crt
https://www.digicert.com/CACerts/DigiCertGlobalRootG2.crt
https://www.digicert.com/CACerts/DigiCertGlobalRootG3.crt
https://www.digicert.com/CACerts/DigiCertTrustedRootG4.crt

* Test Websites
https://assured-id-root-g2.digicert.com
https://assured-id-root-g3.digicert.com
https://global-root-g2.digicert.com/
https://global-root-g3.digicert.com/
https://trusted-root-g4.digicert.com/

* OCSP
http://ocsp.digicert.com

* Audit: Annual audits are performed by KPMG according to the WebTrust
CA and WebTrust EV criteria.
https://cert.webtrust.org/SealFile?seal=1527&file=pdf (2013.07.12)
https://cert.webtrust.org/SealFile?seal=1527&file=pdf (2013.07.12)

* Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices)

** Certificates referencing hostnames or private IP addresses:
DigiCert is currently issuing certificates with private/internal names.
Per the BRs and Section 3.1.1 of our CPS, we plan to halt this process
and revoke all existing certificates by the deadline. All such
certificates currently being issued have an expiration date before
October 1, 2016. DigiCert is also actively working with ICANN to ensure
these names do not impact the release of the new gTLDs.

This begins the discussion of the request from DigiCert to include 5 new
root certificates that will eventually replace the 3 DigiCert root
certificates that are currently included in NSS. The new root certs are
“DigiCert Assured ID Root G2” (SHA-256), “DigiCert Assured ID Root G3”
(ECC), “DigiCert Global Root G2” (SHA-256), “DigiCert Global Root G3”
(ECC), and “DigiCert Trusted Root G4” (SHA-384). The request is to turn
on all 3 trust bits and enable EV for all of the new root certs.

At the conclusion of this discussion I will provide a summary of issues
noted and action items. If there are outstanding issues, then an
additional discussion may be needed as follow-up. If there are no
outstanding issues, then I will recommend approval of this request in
the bug.

Kathleen

[Brian Smith]

On Tue, Jan 28, 2014 at 4:25 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> DigiCert has applied to include 5 new root certificates that will eventually
> replace the 3 DigiCert root certificates that were included in NSS via bug
> #364568. The request is to turn on all 3 trust bits and enable EV for all of
> the new root certs.
>
> 1) DigiCert Assured ID Root G2 -- This SHA-256 root will eventually replace
> the SHA-1 “DigiCert Assured ID Root CA” certificate.
>
> 2) DigiCert Assured ID Root G3 -- The ECC version of the Assured ID root.
>
> 3) DigiCert Global Root G2 -- This SHA-256 root will eventually replace the
> SHA-1 “DigiCert Global Root CA” certificate.
>
> 4) DigiCert Global Root G3 -- The ECC version of the Global root.
>
> 5) DigiCert Trusted Root G4 -- This SHA-384 root will eventually replace the
> SHA-1 “DigiCert High Assurance EV Root CA” certificate.

I object, only on the grounds that there is no technical need to have
more than one root. I have a counter-proposal:

1. Add DigiCert Trusted Root G4 with all three trust bits set.
2. Ask DigiCert to issue versions of their intermediates that are
signed/issued by "DigiCert Trusted Root G4".
3. Remove the existing DigiCert roots.
4. Preload all the intermediates signed by DigiCert Trusted Root G4
(with no trust bits, so they inherit trust from DigiCert Trusted Root
G4) into NSS.

Benefits of my counter-proposal:
1. Fewer roots for us to manage.
2. Sites that forget to include their intermediates in their TLS cert
chain are more likely to work in Firefox, without us having to do AIA
caIssuers, because of us preloading the intermediates.
3. Because of #1, there is potential for us to design a simpler root
certificate management UI.
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.)

This would set a good precedent for us to follow with all other CAs.
By working with all CAs to do something similar, we would end up with
one root per CA, and with a bunch of preloaded intermediates. Then we
can separate the view of intermediates from the view of roots in the
UI, and the UI will become much simpler.

Cheers,
Brian

[David E. Ross]

I do not consider "Benefit #2" to be a benefit. This would mean that
Mozilla is enabling poor security practices by allowing server
administrators to be lazy and incompetent -- allowing them to tell users
their browsing session is secure while the server is incompletely
configured.

--

David E. Ross
<http://www.rossde.com/>

On occasion, I filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam, flames, and trolling from that source.

[Brian Smith]

On Tue, Jan 28, 2014 at 8:45 PM, David E. Ross <nob...@nowhere.invalid> wrote:
> On 1/28/2014 4:37 PM, Brian Smith wrote :

>> Benefits of my counter-proposal:
>> 1. Fewer roots for us to manage.
>> 2. Sites that forget to include their intermediates in their TLS cert
>> chain are more likely to work in Firefox, without us having to do AIA
>> caIssuers, because of us preloading the intermediates.
>> 3. Because of #1, there is potential for us to design a simpler root
>> certificate management UI.
>> 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.)
>

> I do not consider "Benefit #2" to be a benefit. This would mean that
> Mozilla is enabling poor security practices by allowing server
> administrators to be lazy and incompetent -- allowing them to tell users
> their browsing session is secure while the server is incompletely
> configured.

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. But, since four of those certificates wouldn't be roots,
then DigiCert could issue certificates directly off of them without
doing the thing that is perceived to be bad. if they did so, then
because those intermediates would be preloaded into NSS, then we would
be able to tolerate the failure of a website to send the intermediate
certificate.

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. And, we've helped make
the problem bad by caching intermediates collected from surfing the
internet; the consequence of this is that when a website admin is
testing his broken configuration in Firefox, he/she often won't notice
the missing intermediate because Firefox has papered over the issue by
having cached the needed intermediate from the CA's website. I'd like
us to stop doing that, and it is likely that doing so will require us
to preload quite a few intermediates to maintain compatibility.

Cheers,
Brian

[Gervase Markham]

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

[Jeremy Rowley]

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=digice...@lists.mozilla
.org] On Behalf Of Gervase Markham
Sent: Wednesday, January 29, 2014 4:31 AM
To: Brian Smith; mozilla-dev-s...@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-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Ryan Sleevi]

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=digice...@lists.mozilla
> .org] On Behalf Of Gervase Markham
> Sent: Wednesday, January 29, 2014 4:31 AM
> To: Brian Smith; mozilla-dev-s...@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.
>

[Kathleen Wilson]

On 1/29/14 11:22 AM, Ryan Sleevi wrote:
> On Wed, January 29, 2014 10:50 am, Jeremy Rowley wrote:
>> 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.
>>
>

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

I am in favor of improving things and having fewer root certificates to
manage, but I think there first needs to be a separate discussion about
what root/intermediate cert inclusion model we want to move to, how to
do that, and the corresponding code changes (or tools) need to be
implemented. Then I would be happy to move all new inclusions to the new
model, and work with CAs to migrate existing root/intermediate certs as
appropriate.

The discussion to figure out a new way forward needs to happen
separately, so that it doesn't get lost in a discussion about a
particular root renewal/inclusion request.

Brian, please post your proposal in a separate discussion -- and maybe
it actually belongs in m.d.security or m.d.t.crypto?

All, In this particular discussion thread, please review and comment
about DigiCert's root renewal/inclusion request in regards to if it
meets Mozilla's current policy and practices, and if you have other
related recommendations for this CA.

Also, note that Microsoft recently included these roots:
http://social.technet.microsoft.com/wiki/contents/articles/20897.windows-and-windows-phone-8-ssl-root-certificate-program-november-2013.aspx

Thanks,
Kathleen

[Eddy Nigg]

On 01/29/2014 08:50 PM, From Jeremy Rowley:

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

Jeremy, not that I overly care, but are you saying that all these roots
plus the existing roots were accepted in the Microsoft roots program? I
thought there is a hard limit of three roots these days and if correct
and enforced by Microsoft your argument doesn't hold.

I'd say that you probably should have not more than three roots, maybe
each with a particular algo and hash. From those you can and should
issue intermediate CA certificates according to the various purposes you
outlined in your mail.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[Eddy Nigg]

On 01/29/2014 08:50 PM, From Jeremy Rowley:

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

[Jeremy Rowley]

All of these roots were already accepted in the Microsoft root store. Microsoft recently relaxed their three root policy provided that the CA can show a need for additional roots or that the CA has a root migration program in place to keep the limit to three. Because of the communities we support, they permitted us to include five roots.

Jeremy

-----Original Message-----
From: Eddy Nigg [mailto:eddy...@startcom.org]
Sent: Wednesday, January 29, 2014 2:34 PM
To: Jeremy Rowley; mozilla-dev-s...@lists.mozilla.org
Cc: 'Gervase Markham'; 'Brian Smith'; mozilla-dev-s...@lists.mozilla.org
Subject: Re: DigiCert Request to Include Renewed Roots

On 01/29/2014 08:50 PM, From Jeremy Rowley:

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

[Erwann Abalea]

Le mercredi 29 janvier 2014 01:25:28 UTC+1, Kathleen Wilson a écrit :
> DigiCert has applied to include 5 new root certificates that will
> eventually replace the 3 DigiCert root certificates that were included
> in NSS via bug #364568. The request is to turn on all 3 trust bits and
> enable EV for all of the new root certs.
>
> 1) DigiCert Assured ID Root G2 -- This SHA-256 root will eventually
> replace the SHA-1 "DigiCert Assured ID Root CA" certificate.
>
> 2) DigiCert Assured ID Root G3 -- The ECC version of the Assured ID root.
>
> 3) DigiCert Global Root G2 -- This SHA-256 root will eventually replace
> the SHA-1 "DigiCert Global Root CA" certificate.
>
> 4) DigiCert Global Root G3 -- The ECC version of the Global root.
>
> 5) DigiCert Trusted Root G4 -- This SHA-384 root will eventually replace
> the SHA-1 "DigiCert High Assurance EV Root CA" certificate.

There's some minor points:
- the CRLs include a revoked certificate with a reason "unspecified", RFC5280 states that it SHOULD be absent (instead of using this reason code); SHOULD isn't a MUST
- the OCSP responders, when asked about the only revoked certificate so far (serial 01000000000000000000000000000001), reply as if it was non existent (unauthorized); this is strange, as this certificate should exist, if it's revoked
- the ECC certificates have a keyUsage set to digitalSignature and keyAgreement; keyAgreement is correct wrt the public key (id-ecPublicKey covers both ECDSA and ECDH keys), but is useless in TLS (not a security problem at all)

The first and third points are only remarks and can be ignored, but could you reply on the second point, Jeremy?

Other than that, everything's clean.

[Rob Stradling]

On 17/02/14 11:49, Erwann Abalea wrote:
<snip>

> - the ECC certificates have a keyUsage set to digitalSignature and keyAgreement;
> keyAgreement is correct wrt the public key (id-ecPublicKey covers both ECDSA and
> ECDH keys), but is useless in TLS (not a security problem at all)

RFC5820 4.2.1.12 seems to say it's _not_ entirely useless in TLS:
"id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment _or keyAgreement_"

IINM, the keyAgreement bit is required to use the ECDH_ECDSA ciphers.
(However, hopefully everyone would prefer to use the ECDHE_ECDSA ciphers
instead).

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Peter Gutmann]

Rob Stradling <rob.st...@comodo.com> writes:

>RFC5820 4.2.1.12 seems to say it's _not_ entirely useless in TLS:
> "id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
> -- TLS WWW server authentication
> -- Key usage bits that may be consistent: digitalSignature,
> -- keyEncipherment _or keyAgreement_"

It is in theory possible, but IIRC every time I've ever seen the kA bit(s) set
they've been set in error. Also, CAs always set kA, never encipherOnly or
decipherOnly, it's so predictable that one version of dumpasn1 warned if it
saw kA set and de/encipherOnly not set.

Peter.

[Erwann Abalea]

Le lundi 17 février 2014 13:09:49 UTC+1, Rob Stradling a écrit :
> On 17/02/14 11:49, Erwann Abalea wrote:
> <snip>
> > - the ECC certificates have a keyUsage set to digitalSignature and keyAgreement;
> > keyAgreement is correct wrt the public key (id-ecPublicKey covers both ECDSA and
> > ECDH keys), but is useless in TLS (not a security problem at all)
>
> RFC5820 4.2.1.12 seems to say it's _not_ entirely useless in TLS:
> "id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
> -- TLS WWW server authentication
> -- Key usage bits that may be consistent: digitalSignature,
> -- keyEncipherment _or keyAgreement_"

DH certificates can exist, according to the standards. So yes, a (EC)DH certificate with a keyAgreement KeyUsage used for TLS is possible. I've never encountered any, and I don't know how it works in TLS without relying on an anonDH ciphersuite.

> IINM, the keyAgreement bit is required to use the ECDH_ECDSA ciphers.
> (However, hopefully everyone would prefer to use the ECDHE_ECDSA ciphers
> instead).

What is certified is a key used (with ECDSA) to sign ECDH parameters and a corresponding ECDH(E) public key. Strictly speaking, the certified key is only used to perform signatures, not DH key agreement. Firefox correctly checks how the key is used (at least for RSA).

But having keyAgreement in these certificates isn't really a problem; it complies with the sacred scriptures. Whether TLS supports ECDSA+ECDH with the same key or not isn't Digicert's problem.

[Paul Tiemann]

On Feb 17, 2014, at 4:49 AM, Erwann Abalea <eab...@gmail.com> wrote:

> There's some minor points:
> - the CRLs include a revoked certificate with a reason "unspecified", RFC5280 states that it SHOULD be absent (instead of using this reason code); SHOULD isn't a MUST
> - the OCSP responders, when asked about the only revoked certificate so far (serial 01000000000000000000000000000001), reply as if it was non existent (unauthorized); this is strange, as this certificate should exist, if it's revoked

The 01000000000000000000000000000001 serial number is just a "placeholder" non-existent serial number we put in our CRL files if there are no revoked certificates under the CA certificate. We added it around 2007 or 2008 to work around a problem that existed in a Novell server software (now I can't remember the name of it) which would throw an exception and fail to assign a certificate if the CRL had zero revoked entries.

Thanks for reviewing Erwann!

Cheers,
Paul Tiemann
(DigiCert)

[Paul Tiemann]

(Sorry -- I must have posted this from an non-member email address so it didn't get onto the list earlier.)

On Feb 17, 2014, at 4:49 AM, Erwann Abalea <eab...@gmail.com> wrote:

> There's some minor points:
> - the CRLs include a revoked certificate with a reason "unspecified", RFC5280 states that it SHOULD be absent (instead of using this reason code); SHOULD isn't a MUST
> - the OCSP responders, when asked about the only revoked certificate so far (serial 01000000000000000000000000000001), reply as if it was non existent (unauthorized); this is strange, as this certificate should exist, if it's revoked

[Paul Tiemann]

(Sorry -- I must have posted this from an non-member email address so it didn't get onto the list earlier.)

On Feb 17, 2014, at 4:49 AM, Erwann Abalea <eab...@gmail.com> wrote:

> There's some minor points:
> - the CRLs include a revoked certificate with a reason "unspecified", RFC5280 states that it SHOULD be absent (instead of using this reason code); SHOULD isn't a MUST
> - the OCSP responders, when asked about the only revoked certificate so far (serial 01000000000000000000000000000001), reply as if it was non existent (unauthorized); this is strange, as this certificate should exist, if it's revoked

[Paul Tiemann]

(Sorry -- I must have posted this from an non-member email address so it didn't get onto the list earlier.)

On Feb 17, 2014, at 4:49 AM, Erwann Abalea <eab...@gmail.com> wrote:

> There's some minor points:
> - the CRLs include a revoked certificate with a reason "unspecified", RFC5280 states that it SHOULD be absent (instead of using this reason code); SHOULD isn't a MUST
> - the OCSP responders, when asked about the only revoked certificate so far (serial 01000000000000000000000000000001), reply as if it was non existent (unauthorized); this is strange, as this certificate should exist, if it's revoked

[David E. Ross]

Please post either to the mozilla.dev.security.policy newsgroup OR to
the dev-secur...@lists.mozilla.org mailing list, BUT NOT BOTH.
Each feeds into the other.

[Paul Tiemann]

On Feb 19, 2014, at 11:03 AM, David E. Ross <nob...@nowhere.invalid> wrote:

> On 2/18/2014 9:42 PM, Paul Tiemann wrote:

> Please post either to the mozilla.dev.security.policy newsgroup OR to
> the dev-secur...@lists.mozilla.org mailing list, BUT NOT BOTH.
> Each feeds into the other.

Did you get this message more than once, David? I only ever sent this to the mozilla-dev-s...@lists.mozilla.org email as far as I can tell (partly because I don't use a newsgroup reader)

I simply resent this from another email address which is subscribed to the list so it would post. The first time I sent it, I never saw it appear on the list, and Erwann asked if I'd send it again. (Sorry everyone for list chatter like this, I couldn't email David back because I don't have a real email for him.)

Cheers,
Paul Tiemann
CTO, DigiCert

[David E. Ross]

On 2/20/2014 6:45 AM, Paul Tiemann wrote:

> On Feb 19, 2014, at 11:03 AM, I previously wrote:
>>
>> Please post either to the mozilla.dev.security.policy newsgroup OR to
>> the dev-secur...@lists.mozilla.org mailing list, BUT NOT BOTH.
>> Each feeds into the other.
>
> Did you get this message more than once, David? I only ever sent
> this to the mozilla-dev-s...@lists.mozilla.org email as
> far as I can tell (partly because I don't use a newsgroup reader)
>
> I simply resent this from another email address which is subscribed
> to the list so it would post. The first time I sent it, I never saw
> it appear on the list, and Erwann asked if I'd send it again. (Sorry
> everyone for list chatter like this, I couldn't email David back
> because I don't have a real email for him.)
>
> Cheers,
> Paul Tiemann
> CTO, DigiCert
>

Your message sent Tue, 18 Feb 2014 22:42:40 -0700, appeared twice in the
mozilla.dev.security.policy newsgroup. It was sent both to the
newsgroup and to the E-mail address
<dev-secur...@lists.mozilla.org>.

[Kathleen Wilson]

On 1/28/14, 4:25 PM, Kathleen Wilson wrote:
> DigiCert has applied to include 5 new root certificates that will
> eventually replace the 3 DigiCert root certificates that were included
> in NSS via bug #364568. The request is to turn on all 3 trust bits and
> enable EV for all of the new root certs.
>
> 1) DigiCert Assured ID Root G2 -- This SHA-256 root will eventually
> replace the SHA-1 “DigiCert Assured ID Root CA” certificate.
>
> 2) DigiCert Assured ID Root G3 -- The ECC version of the Assured ID root.
>
> 3) DigiCert Global Root G2 -- This SHA-256 root will eventually replace
> the SHA-1 “DigiCert Global Root CA” certificate.
>
> 4) DigiCert Global Root G3 -- The ECC version of the Global root.
>
> 5) DigiCert Trusted Root G4 -- This SHA-384 root will eventually replace
> the SHA-1 “DigiCert High Assurance EV Root CA” certificate.
>
> DigiCert is a US-based commercial CA with headquarters in Utah. DigiCert
> provides digital certification and identity assurance services
> internationally to a variety of sectors including business, education,
> and government.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=908827
>

Thank you to those of you who have reviewed and commented on this
request from DigiCert.

Does anyone have any further questions about this request, or feel that
there is anything left to resolve from this discussion (regarding this
specific request)?

If not, I will close this discussion, and recommend that this request be
approved after I have confirmed receipt of DigiCert's BR audit statement.

Thanks,
Kathleen

[Kathleen Wilson]

Thank you to those of you who reviewed and contributed to this
discussion about the request from DigiCert to include 5 new root

certificates that will eventually replace the 3 DigiCert root

certificates that are currently included in NSS. The request is to turn

on all 3 trust bits and enable EV for all of the new root certs.

I believe that the concerns about this request that were raised during
this discussion have been addressed.

I am closing this discussion, and I will recommend approval in the bug,
with actual inclusion on hold pending confirmation of the upcoming BR
audit statement.

https://bugzilla.mozilla.org/show_bug.cgi?id=908827

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen