Mozilla’s Plan for Symantec Roots

[Gervase Markham]

As per previous discussions and
https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was
reached among multiple browser makers for a graduated distrust of
Symantec roots.

Here is Mozilla’s planned timeline for the graduated distrust of
Symantec roots (subject to change):

* January 2018 (Firefox 58): Notices in the Developer Console will warn
about Symantec certificates issued before 2016-06-01, to encourage site
owners to migrate their TLS certs.

* May 2018 (Firefox 60): Websites will show an untrusted connection
error if they have a TLS cert issued before 2016-06-01 that chains up to
a Symantec root.

* October 2018 (Firefox 63): Removal/distrust of Symantec roots, with
caveats described below.

Mozilla’s release calendar is here:
https://wiki.mozilla.org/RapidRelease/Calendar

However, there are some subCAs of the Symantec roots that are
independently operated by companies whose operations have not been
called into question, and they will experience significant hardship if
we do not provide a longer transition period for them. For both
technical and non-technical reasons, a year is an extremely unrealistic
timeframe for these subCAs to transition to having their certificates
cross-signed by another CA. For example, the subCA may have implemented
a host of pinning solutions in their products that would fail with
non-Symantec-chaining certificates, or the subCA may have large numbers
of devices that would need to be tested for interoperability with any
potential future vendor. And, of course contractual negotiations may
take a significant amount of time.

The subCAs that we know of that fall into this category belong to Google
and Apple. If there are any other subCAs that fall into this category,
please let us know immediately. Google has one such subCA; Apple has seven.

There are two ways that we can provide a smoother transition for these
subCAs.

Option 1)
Temporarily treat these subCAs as directly-included trust-anchors.
Mozilla prefers *not* to take this approach, because even if clearly
explained up front that it is a temporary solution with deadlines, it
would be very easy for people to start treating such a subCA as a
regular trust anchor, and thereby have that subCA become a de facto
included CA. Additionally, it could become very complicated to remove
such subCAs in the future, especially if they have not performed the
recommended transitions.

Option 2)
Add code to Firefox to disable the root such that only certain subCAs
will continue to function. So, the final dis-trust of Symantec roots may
actually involve letting one or two of the root certs remain in
Mozilla’s trust store, but having special code to distrust all but
specified subCAs. We would document the information here:
https://wiki.mozilla.org/CA/Additional_Trust_Changes
And Mozilla would add tooling to the CCADB to track these special subCAs
to ensure proper CP/CPS/audits until they have been migrated and
disabled, and the root certs removed. Mozilla will need to also follow
up with these subCAs to ensure they are moving away from these root
certificates and are getting cross-signed by more than one CA in order
to avoid repeating this situation.

According to option 2 and the plan listed above, here is how the
currently-included Symantec root certs will be treated in Firefox 63:

= Symantec roots to be disabled via code, *not* removed from NSS =

GeoTrust Global CA
GeoTrust Primary Certification Authority - G2
GeoTrust Primary Certification Authority - G3

= Symantec roots that will be fully removed from NSS =

GeoTrust Primary Certification Authority
GeoTrust Universal CA
GeoTrust Universal CA 2
Symantec Class 1 Public Primary Certification Authority - G4
Symantec Class 1 Public Primary Certification Authority - G6
Symantec Class 2 Public Primary Certification Authority - G4
Symantec Class 2 Public Primary Certification Authority - G6
thawte Primary Root CA
thawte Primary Root CA - G2
thawte Primary Root CA - G3
VeriSign Class 1 Public PCA - G3
VeriSign Class 2 Public PCA - G3
VeriSign Class 3 Public Primary Certification Authority - G3
VeriSign Class 3 Public Primary Certification Authority - G4
VeriSign Class 3 Public Primary Certification Authority - G5
VeriSign Universal Root Certification Authority

As always, we appreciate your thoughtful and constructive feedback on this.

Gerv

[0]
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs%5B251-275%5D

[Gervase Markham]

[Eric Mill]

Adding code to Firefox to support the distrust of specified subCAs seems
like it would be a good long-term investment for Mozilla, as it would give
Mozilla a lot more flexibility during future distrust events.

-- Eric

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
konklone.com | @konklone <https://twitter.com/konklone>

[Daniel Cater]

On Monday, 16 October 2017 18:32:54 UTC+1, Gervase Markham wrote:
> = Symantec roots to be disabled via code, *not* removed from NSS =
>
> GeoTrust Global CA
> GeoTrust Primary Certification Authority - G2
> GeoTrust Primary Certification Authority - G3
>
> = Symantec roots that will be fully removed from NSS =
>
> GeoTrust Primary Certification Authority
> GeoTrust Universal CA
> GeoTrust Universal CA 2
> Symantec Class 1 Public Primary Certification Authority - G4
> Symantec Class 1 Public Primary Certification Authority - G6
> Symantec Class 2 Public Primary Certification Authority - G4
> Symantec Class 2 Public Primary Certification Authority - G6
> thawte Primary Root CA
> thawte Primary Root CA - G2
> thawte Primary Root CA - G3
> VeriSign Class 1 Public PCA - G3
> VeriSign Class 2 Public PCA - G3
> VeriSign Class 3 Public Primary Certification Authority - G3
> VeriSign Class 3 Public Primary Certification Authority - G4
> VeriSign Class 3 Public Primary Certification Authority - G5
> VeriSign Universal Root Certification Authority

Could we have a list of the subCAs that are being considered for exemption for the distrust?

[Peter Bowen]

On Mon, Oct 16, 2017 at 10:32 AM, Gervase Markham via

dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
> As per previous discussions and
> https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was
> reached among multiple browser makers for a graduated distrust of
> Symantec roots.
>
> Here is Mozilla’s planned timeline for the graduated distrust of
> Symantec roots (subject to change):
>

> * October 2018 (Firefox 63): Removal/distrust of Symantec roots, with
> caveats described below.
>

> However, there are some subCAs of the Symantec roots that are
> independently operated by companies whose operations have not been
> called into question, and they will experience significant hardship if
> we do not provide a longer transition period for them. For both
> technical and non-technical reasons, a year is an extremely unrealistic
> timeframe for these subCAs to transition to having their certificates
> cross-signed by another CA. For example, the subCA may have implemented
> a host of pinning solutions in their products that would fail with
> non-Symantec-chaining certificates, or the subCA may have large numbers
> of devices that would need to be tested for interoperability with any
> potential future vendor. And, of course contractual negotiations may
> take a significant amount of time.

This pattern also exists for companies that have endpoints which have
clients which are pinned to the Symantec-owned roots. These endpoints
may also be used by browser clients. It was my understanding that the
intent was existing roots would cross sign new managed CAs that would
be used for transition.

> Add code to Firefox to disable the root such that only certain subCAs
> will continue to function. So, the final dis-trust of Symantec roots may
> actually involve letting one or two of the root certs remain in
> Mozilla’s trust store, but having special code to distrust all but
> specified subCAs. We would document the information here:
> https://wiki.mozilla.org/CA/Additional_Trust_Changes
> And Mozilla would add tooling to the CCADB to track these special subCAs
> to ensure proper CP/CPS/audits until they have been migrated and
> disabled, and the root certs removed. Mozilla will need to also follow
> up with these subCAs to ensure they are moving away from these root
> certificates and are getting cross-signed by more than one CA in order
> to avoid repeating this situation.

Will the new managed CAs, which will operated by DigiCert under
CP/CPS/Audit independent from the current Symantec ones, also be
included on the list of subCAs that will continue to function?

Thanks,
Peter

[Gervase Markham]

On 16/10/17 20:19, Daniel Cater wrote:
> Could we have a list of the subCAs that are being considered for exemption for the distrust?

Here's an informal list created by me examining the CCADB. Note that the
CCADB links won't work for anyone except Root Store operators.


GeoTrust Global CA
|
|_ Google Internet Authority G2 (2017-05-22 -> 2018-12-31)
| https://ccadb.my.salesforce.com/0011J000017aa6MQAQ
| https://crt.sh/?id=142951186
|
|_ Google Internet Authority G2 (2015-04-01 -> 2017-12-31)
https://ccadb.my.salesforce.com/001o000000utwbKAAQ
https://crt.sh/?id=23635000

GeoTrust Global CA
|
|_ Apple IST CA 2 - G1
| https://ccadb.my.salesforce.com/001o000000p4ScGAAU
| https://crt.sh/?id=5250464
|
|_ Apple IST CA 5 - G1
https://ccadb.my.salesforce.com/001o000000p4ScnAAE
https://crt.sh/?id=12716200

GeoTrust Primary Certification Authority - G2
|

|_ Apple IST CA 4 - G1
| https://ccadb.my.salesforce.com/001o000000p4ScIAAU
| https://crt.sh/?id=19602712
|
|_ Apple IST CA 7 - G1
| https://ccadb.my.salesforce.com/001o000000p4ScIAAU
| https://crt.sh/?id=19602724
|
|_ Apple IST CA 8 - G1
https://ccadb.my.salesforce.com/001o000000qRJHFAA4
https://crt.sh/?id=21760447

GeoTrust Primary Certification Authority - G3
|

|_ Apple IST CA 3 - G1
| https://ccadb.my.salesforce.com/001o000000p4SciAAE
| https://crt.sh/?id=19602706
|
|_ Apple IST CA 6 - G1
https://ccadb.my.salesforce.com/001o000000p4ScoAAE
https://crt.sh/?id=19602741

I will get Google and Apple to validate this data.

Gerv

[Gervase Markham]

On 16/10/17 20:22, Peter Bowen wrote:
> Will the new managed CAs, which will operated by DigiCert under
> CP/CPS/Audit independent from the current Symantec ones, also be
> included on the list of subCAs that will continue to function?

AIUI we are still working out the exact configuration of the new PKI but
my understanding is that the new managed CAs will be issued by DigiCert
roots and cross-signed by old Symantec roots. Therefore, they will be
trusted in Firefox using a chain up to the DigiCert roots.

Gerv

[Ryan Sleevi]

On Tue, Oct 17, 2017 at 5:06 AM, Gervase Markham via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 16/10/17 20:22, Peter Bowen wrote:

> > Will the new managed CAs, which will operated by DigiCert under
> > CP/CPS/Audit independent from the current Symantec ones, also be
> > included on the list of subCAs that will continue to function?
>

> AIUI we are still working out the exact configuration of the new PKI but
> my understanding is that the new managed CAs will be issued by DigiCert
> roots and cross-signed by old Symantec roots. Therefore, they will be
> trusted in Firefox using a chain up to the DigiCert roots.

Hi Gerv,

That doesn't seem to line up with the discussion in
https://groups.google.com/d/topic/mozilla.dev.security.policy/_EnH2IeuZtw/discussion
to date. Do you have any additional information to share?

Note that the path you just described is the one that poses non-trivial
risk to the ecosystem, from an interoperability standpoint, and thus may
not be desirable.

See
https://groups.google.com/d/msg/mozilla.dev.security.policy/_EnH2IeuZtw/yr2vSBdhAAAJ
and
https://groups.google.com/d/msg/mozilla.dev.security.policy/_EnH2IeuZtw/BNR6gJHCBgAJ
for further technical details.

[Gervase Markham]

On 17/10/17 15:50, Ryan Sleevi wrote:
> That doesn't seem to line up with the discussion in
> https://groups.google.com/d/topic/mozilla.dev.security.policy/_EnH2IeuZtw/discussion
> to date. Do you have any additional information to share?
>
> Note that the path you just described is the one that poses non-trivial
> risk to the ecosystem, from an interoperability standpoint, and thus may
> not be desirable.

This seems to be because I'm not following closely enough. The exact
design of complex PKIs is not my area :-) I'm sure the people who are
experts will work it all out.

But yes, in general, the point of the managed CAs is that they will
continue to be trusted, somehow, for some additional period of time.

Gerv

[Jeremy Rowley]

The current plan is to create a new root that is cross-signed by each of the
four roots we've identified as critical for customers
(https://bugzilla.mozilla.org/show_bug.cgi?id=1401384). If Mozilla
whitelisted this sub CA, the same as Google's and Apple's, the entire issue
around rapid root inclusion would be resolved. Alternatively, we can
continue down the embedment path and try to get the new root ubiquitous
before the Symantec distrust dates.

I think one outstanding issue is whether we create separate issuing CAs for
each of the four major roots or create one new root that is cross-signed by
the four roots (delivering the appropriate cross-sign as needed). My
preference is to create four sub CAs to simplify the cross-signing and
distribution.

Jeremy

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Gervase Markham via dev-security-policy
Sent: Tuesday, October 17, 2017 9:01 AM
To: ry...@sleevi.com; mozilla-dev-s...@lists.mozilla.org
Cc: Peter Bowen <pzb...@gmail.com>; Kathleen Wilson <kwi...@mozilla.com>
Subject: Re: Mozilla's Plan for Symantec Roots

On 17/10/17 15:50, Ryan Sleevi wrote:

> That doesn't seem to line up with the discussion in
> https://groups.google.com/d/topic/mozilla.dev.security.policy/_EnH2Ieu
> Ztw/discussion to date. Do you have any additional information to
> share?
>
> Note that the path you just described is the one that poses
> non-trivial risk to the ecosystem, from an interoperability
> standpoint, and thus may not be desirable.

This seems to be because I'm not following closely enough. The exact design
of complex PKIs is not my area :-) I'm sure the people who are experts will
work it all out.

But yes, in general, the point of the managed CAs is that they will continue
to be trusted, somehow, for some additional period of time.

Gerv

[David Illsley]

A couple of thoughts:
1) I'm not sure why you believe Option 2 is likely to result in a quicker transition?
2) Option 2 starts "Add code to Firefox..". What's the plan for non-firefox users of the Mozilla root list? Isn't there a pretty substantial risk that others users don't correctly implement the partial distrust, resulting in a trust/security risk?

David

[Gervase Markham]

On 17/10/17 10:01, Gervase Markham wrote:
> Here's an informal list created by me examining the CCADB. Note that the
> CCADB links won't work for anyone except Root Store operators.

Apple have confirmed that their list is complete and correct.

Gerv

[Gervase Markham]

On 16/10/17 18:32, Gervase Markham wrote:
> Here is Mozilla’s planned timeline for the graduated distrust of
> Symantec roots (subject to change):

This is now https://bugzilla.mozilla.org/show_bug.cgi?id=1409257 .

Gerv

[Kai Engert]

On 16.10.2017 19:32, Gervase Markham via dev-security-policy wrote:
>
> Here is Mozilla’s planned timeline for the graduated distrust of
> Symantec roots (subject to change):
>

> * January 2018 (Firefox 58): Notices in the Developer Console will warn
> about Symantec certificates issued before 2016-06-01, to encourage site
> owners to migrate their TLS certs.
>
> * May 2018 (Firefox 60): Websites will show an untrusted connection
> error if they have a TLS cert issued before 2016-06-01 that chains up to
> a Symantec root.
>
> * October 2018 (Firefox 63): Removal/distrust of Symantec roots, with
> caveats described below.
>
> Mozilla’s release calendar is here:
> https://wiki.mozilla.org/RapidRelease/Calendar

Will these changes be implemented in the ESR 59.x releases, which will
be released in parallel to the above releases?

Thanks
Kai

[Gervase Markham]

On 25/10/17 12:15, Kai Engert wrote:
> Will these changes be implemented in the ESR 59.x releases, which will
> be released in parallel to the above releases?

That's a really good question.

I am told that the code implementing the console warning is going to be
there before ESR branches, so we should expect the ESR to carry that. JC
suggests we should plan to uplift the disablement patch (which may not
be simply a root store change) at one of the planned ESR dot releases.

Gerv

[Gervase Markham]

On 18/10/17 13:49, Gervase Markham wrote:
> Apple have confirmed that their list is complete and correct.

As have Google.

Gerv

[Peter Bowen]

On Tue, Oct 17, 2017 at 2:06 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 16/10/17 20:22, Peter Bowen wrote:

>> Will the new managed CAs, which will operated by DigiCert under
>> CP/CPS/Audit independent from the current Symantec ones, also be
>> included on the list of subCAs that will continue to function?
>

> AIUI we are still working out the exact configuration of the new PKI but
> my understanding is that the new managed CAs will be issued by DigiCert
> roots and cross-signed by old Symantec roots. Therefore, they will be
> trusted in Firefox using a chain up to the DigiCert roots.

Gerv,

I'm hoping you can clarify the Mozilla position a little, given a hypothetical.

For this, please assume that DigiCert is the owner and operator of the
VeriSign, Thawte, and GeoTrust branded roots currently included in NSS
and that they became the owner and operator on 15 November 2017 (i.e.
unquestionably before 1 December 2017).

If DigiCert generates a new online issuing CA on 20 March 2018 and
cross-signs it using their VeriSign Class 3 Public Primary
Certification Authority - G5 offline root CA, will certificates from
this new issuing CA be trusted by Firefox? If so, what are the
parameters of trust, for example not trusted until the new CA is
whitelisted by Mozilla or only trusted until a certain date?

What about the same scenario except the new issuing CA is generated on
30 June 2019?

Thanks,
Peter

[Jeremy Rowley]

I'm also very interested in this scenario.

I'm also interested in what happens if a trusted DigiCert root is signed by
a Symantec root. I assume this wouldn't impact trust since the chain
building would stop at a DigiCert root, but I wanted to be sure.

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Peter Bowen via dev-security-policy
Sent: Friday, October 27, 2017 9:52 AM
To: Gervase Markham <ge...@mozilla.org>
Cc: mozilla-dev-s...@lists.mozilla.org; Kathleen Wilson
<kwi...@mozilla.com>
Subject: Re: Mozilla's Plan for Symantec Roots

On Tue, Oct 17, 2017 at 2:06 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 16/10/17 20:22, Peter Bowen wrote:

>> Will the new managed CAs, which will operated by DigiCert under
>> CP/CPS/Audit independent from the current Symantec ones, also be
>> included on the list of subCAs that will continue to function?
>

> AIUI we are still working out the exact configuration of the new PKI
> but my understanding is that the new managed CAs will be issued by
> DigiCert roots and cross-signed by old Symantec roots. Therefore, they
> will be trusted in Firefox using a chain up to the DigiCert roots.

Gerv,

I'm hoping you can clarify the Mozilla position a little, given a
hypothetical.

For this, please assume that DigiCert is the owner and operator of the
VeriSign, Thawte, and GeoTrust branded roots currently included in NSS and
that they became the owner and operator on 15 November 2017 (i.e.
unquestionably before 1 December 2017).

If DigiCert generates a new online issuing CA on 20 March 2018 and
cross-signs it using their VeriSign Class 3 Public Primary Certification
Authority - G5 offline root CA, will certificates from this new issuing CA
be trusted by Firefox? If so, what are the parameters of trust, for example
not trusted until the new CA is whitelisted by Mozilla or only trusted until
a certain date?

What about the same scenario except the new issuing CA is generated on
30 June 2019?

Thanks,
Peter

[Peter Bowen]

On Fri, Oct 27, 2017 at 9:21 AM, Jeremy Rowley
<jeremy...@digicert.com> wrote:
> I'm also very interested in this scenario.
>
> I'm also interested in what happens if a trusted DigiCert root is signed by
> a Symantec root. I assume this wouldn't impact trust since the chain
> building would stop at a DigiCert root, but I wanted to be sure.

Jeremy,

To clarify your scenario, do you mean what happens if a DigiCert owned
and operated CyberTrust or DigiCert branded root is cross-signed by a
DigiCert owned and operated VeriSign, Thawte, or GeoTrust branded
root? (Assuming all the roots are roots currently listed at
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport)

Thanks,
Peter

> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
> .org] On Behalf Of Peter Bowen via dev-security-policy
> Sent: Friday, October 27, 2017 9:52 AM
> To: Gervase Markham <ge...@mozilla.org>
> Cc: mozilla-dev-s...@lists.mozilla.org; Kathleen Wilson
> <kwi...@mozilla.com>
> Subject: Re: Mozilla's Plan for Symantec Roots
>
> On Tue, Oct 17, 2017 at 2:06 AM, Gervase Markham <ge...@mozilla.org> wrote:
>> On 16/10/17 20:22, Peter Bowen wrote:

>>> Will the new managed CAs, which will operated by DigiCert under
>>> CP/CPS/Audit independent from the current Symantec ones, also be
>>> included on the list of subCAs that will continue to function?
>>

[Jeremy Rowley]

Yes. Or any root that is cross signed by the Symantec sub cas. I assume there would be zero impact as the chain building should stop with the trustees root and not look at the Symantec roots, but it’s definitely good to double check.

On Oct 27, 2017, at 10:32 AM, Peter Bowen <pzb...@gmail.com<mailto:pzb...@gmail.com>> wrote:

On Fri, Oct 27, 2017 at 9:21 AM, Jeremy Rowley
<jeremy...@digicert.com<mailto:jeremy...@digicert.com>> wrote:
I'm also very interested in this scenario.

I'm also interested in what happens if a trusted DigiCert root is signed by
a Symantec root. I assume this wouldn't impact trust since the chain
building would stop at a DigiCert root, but I wanted to be sure.

Jeremy,

To clarify your scenario, do you mean what happens if a DigiCert owned
and operated CyberTrust or DigiCert branded root is cross-signed by a
DigiCert owned and operated VeriSign, Thawte, or GeoTrust branded
root? (Assuming all the roots are roots currently listed at
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport)

Thanks,
Peter


-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Peter Bowen via dev-security-policy
Sent: Friday, October 27, 2017 9:52 AM
To: Gervase Markham <ge...@mozilla.org<mailto:ge...@mozilla.org>>
Cc: mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>; Kathleen Wilson
<kwi...@mozilla.com<mailto:kwi...@mozilla.com>>
Subject: Re: Mozilla's Plan for Symantec Roots

On Tue, Oct 17, 2017 at 2:06 AM, Gervase Markham <ge...@mozilla.org<mailto:ge...@mozilla.org>> wrote:
On 16/10/17 20:22, Peter Bowen wrote:

Will the new managed CAs, which will operated by DigiCert under
CP/CPS/Audit independent from the current Symantec ones, also be
included on the list of subCAs that will continue to function?

AIUI we are still working out the exact configuration of the new PKI
but my understanding is that the new managed CAs will be issued by
DigiCert roots and cross-signed by old Symantec roots. Therefore, they
will be trusted in Firefox using a chain up to the DigiCert roots.

Gerv,

I'm hoping you can clarify the Mozilla position a little, given a
hypothetical.

For this, please assume that DigiCert is the owner and operator of the
VeriSign, Thawte, and GeoTrust branded roots currently included in NSS and
that they became the owner and operator on 15 November 2017 (i.e.
unquestionably before 1 December 2017).

If DigiCert generates a new online issuing CA on 20 March 2018 and
cross-signs it using their VeriSign Class 3 Public Primary Certification
Authority - G5 offline root CA, will certificates from this new issuing CA
be trusted by Firefox? If so, what are the parameters of trust, for example
not trusted until the new CA is whitelisted by Mozilla or only trusted until
a certain date?

What about the same scenario except the new issuing CA is generated on
30 June 2019?

Thanks,
Peter
_______________________________________________
dev-security-policy mailing list

dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Ryan Sleevi]

Without commenting on the Symantec aspect of this, there is a rather
substantial correction to the behaviour of client software - including
Firefox.

Unfortunately, very few libraries and path validators support chain
building terminating at trust anchors in the way you describe. Recent
changes in Firefox itself have resulted in it preferring longer chains
(validating to the cross-signed root), rather than terminating at the trust
anchor, thus affecting measurements of per-root usage.

Examples:
- macOS versions prior to 10.11 were biased to use the presented chain -
meaning if cross-certified trust anchors were presented, they may result in
a longer chain (DigiCert should recall the effect of this). 10.11+ has a
weighting scale for certificate chains, but this is somewhat opaque
- OpenSSL versions prior to 1.0.2 were biased to prefer the presented chain
and try to build to a self-signed root. Thus if intermediates had explicit
trust settings (including if it was because a self-signed version was
trusted), these settings would be ignored. As noted in the 1.0.2 changelog,
this feature is still 'experimental'
- Firefox recently regressed with this behaviour -
https://bugzilla.mozilla.org/show_bug.cgi?id=1364159 introduced the bug
(Firefox 55), and https://bugzilla.mozilla.org/show_bug.cgi?id=1400913
(Firefox 57) tried to resolve it.
- Windows bases its path-preferences on a complex set of signals, some
internal (such as the order of store creation and the ordering of MD5/SHA-1
hashes of the certs), some external (such as the notBefore date of the
certificate). This can be further compounded by whether or not users have
AuthRoot updates disabled and/or misconfigured (e.g. improper proxy
settings). For example, if your new roots were added in a subsequent root
update, there's no guarantee that Windows users would consistently build
paths to that new root, because they may not yet know that the new root is
trusted, or the configuration of intermediates may result in a longer path
being preferred.

In short, you cannot reliably assume that in the case of cross-signing, the
shorter path to a trust anchor will be build or preferred. For this reason,
cross-signing to existing roots is complex.

On Fri, Oct 27, 2017 at 12:37 PM, Jeremy Rowley via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Yes. Or any root that is cross signed by the Symantec sub cas. I assume
> there would be zero impact as the chain building should stop with the
> trustees root and not look at the Symantec roots, but it’s definitely good
> to double check.
>

> On Oct 27, 2017, at 10:32 AM, Peter Bowen <pzb...@gmail.com<mailto:pzbo

> Will the new managed CAs, which will operated by DigiCert under
> CP/CPS/Audit independent from the current Symantec ones, also be
> included on the list of subCAs that will continue to function?
>

> securit...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Gervase Markham]

Hi Peter,

Ryan is the chain-building expert, and others have deeper knowledge of
how the new Symantec/DigiCert PKI is going to work than I do, but here's
an attempt to answer your question.

On 27/10/17 16:51, Peter Bowen wrote:
> If DigiCert generates a new online issuing CA on 20 March 2018 and
> cross-signs it using their VeriSign Class 3 Public Primary
> Certification Authority - G5 offline root CA, will certificates from
> this new issuing CA be trusted by Firefox? If so, what are the
> parameters of trust, for example not trusted until the new CA is
> whitelisted by Mozilla or only trusted until a certain date?

Certificates chaining up to Symantec roots, so including that Verisign
one, which have notBefore dates after June 2016 (which I assume these
would) will continue to be trusted until the full removal of trust in
Symantec in October 2018.

They may be trusted beyond that if this new issuing CA is one of the
ones DigiCert asks us to whitelist for Symantec continuity (the "Managed
Partner Infrastructure"). Although I'm generally expecting DigiCert to
create and submit a single list of such CAs at one time, rather than
submitting them in dribs and drabs.

> What about the same scenario except the new issuing CA is generated on
> 30 June 2019?

As the Verisign root would no longer be in our root store, certs issued
by such an issuing CA would no longer ordinarily be trusted. If this
were a whitelisted continuity issuing CA, it might still be trusted. If
I recall correctly, the future trust parameters for those continuity CAs
is undefined by the consensus plan. It says that they will continue to
work until any new Symantec hierarchy is in all the root stores, but
that was defined before the purchase was mooted. So it seems to me like
there is now a question mark here.

Gerv

[Kai Engert]

On 16.10.2017 20:26, Eric Mill via dev-security-policy wrote:
> Adding code to Firefox to support the distrust of specified subCAs seems
> like it would be a good long-term investment for Mozilla, as it would give
> Mozilla a lot more flexibility during future distrust events.

I think this isn't about distrust of specified subCAs, but rather about
keeping subCAs actively trusted, despite their issueing roots being no
longer trusted.

Kai

[Kai Engert]

On 16.10.2017 19:32, Gervase Markham via dev-security-policy wrote:

> The subCAs that we know of that fall into this category belong to Google
> and Apple. If there are any other subCAs that fall into this category,
> please let us know immediately. Google has one such subCA; Apple has seven.

Besides the informal list of 9 subCAs (8 unexpired) that Gerv has posted
on 2017-10-17, has Mozilla learned about any additional subCAs that will
require a similar treatment?

I assume that the end of the primary development phase for Firefox 60,
which is early March 2018, will be the deadline to add whitelisting for
any such subCAs.

Kai

[Wayne Thayer]

On Thu, Feb 8, 2018 at 7:26 AM, Kai Engert via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 16.10.2017 19:32, Gervase Markham via dev-security-policy wrote:
> > The subCAs that we know of that fall into this category belong to Google
> > and Apple. If there are any other subCAs that fall into this category,
> > please let us know immediately. Google has one such subCA; Apple has
> seven.
>
> Besides the informal list of 9 subCAs (8 unexpired) that Gerv has posted
> on 2017-10-17, has Mozilla learned about any additional subCAs that will
> require a similar treatment?
>

> The Chrome team has posted a set of subordinate CAs to whitelist [1] that
contains some differences from the list that Gerv posted. I will ask Apple,
Google, and DigiCert to confirm which subordinates need to be whitelisted.

[1]
https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/README.md

I assume that the end of the primary development phase for Firefox 60,
> which is early March 2018, will be the deadline to add whitelisting for
> any such subCAs.
>
> Kai

[Ryan Sleevi]

Hi Wayne,

As a small clarification - while Chrome has included the certificates, as
noted in the readme, the whitelist is based on SPKI. This was intentional,
to avoid situations of interoperability issues.

Whitelisting by certificate, rather than either SPKI or SPKI-Tuple, brings
with it significant compatibility risks to the ecosystem in terms of being
able to respond to issues. We've already seen this born out with respect to
DigiCert and their Managed PKI intermediates, and wanted to avoid
disruption to both Apple and Google that would otherwise destablize the
ecosystem.

For example, if you note, there are two Google certificates, but they share
the same SPKI and Subject Name - which is why the Chromium whitelist only
has one certificate listed, as it extracts the SPKI from that resource as
part of the whitelist.

Apologies if the README didn't make that clearer, and happy if there are
suggestions or corrections based on that :)

On Fri, Feb 9, 2018 at 1:55 PM, Wayne Thayer via dev-security-policy <

[Kai Engert]

On 09.02.2018 22:20, Ryan Sleevi wrote:
> As a small clarification - while Chrome has included the certificates,
> as noted in the readme, the whitelist is based on SPKI. This was
> intentional, to avoid situations of interoperability issues.

Hi Ryan,

IIUC, the current implementation in Firefox (for the early console
warnings) is based on distinguished named (DN), not SPKI:

https://hg.mozilla.org/integration/autoland/rev/d3acb68f73c4

> Whitelisting by certificate, rather than either SPKI or SPKI-Tuple,
> brings with it significant compatibility risks to the ecosystem in terms
> of being able to respond to issues.

Can these risks be avoided, too, by using the DN matching strategy that
the Firefox code uses?

If not, it would be helpful to list these risks, and why they can only
be addressed by using SPKI matching.

Is your worry that alternative subCAs (already existing, or potentially
being introduced in the future) could be used in server configurations,
and that path building code might fail to match unexpected subCAs
against the whitelist?

I hope we shouldn't have to worry about alternative, already existing
subCAs. There shouldn't be alternative subCAs, because it would have
been required to request their whitelisting already, right?

Also, I hope we shouldn't have to worry about alternative, future
subCAs. It's not allowed to use the old Symantec CA infrastructure to
issue alternative subCAs that might require whitelisting, right?

Maybe the compatibility risks aren't about alternative subCAs?


A separate question which would be good to clarified: What about
environments, which want to distrust all old Symantec roots in October
2018, but cannot add whitelisting to their cert validation code, and
choose to explicitly trust each of the subCAs. Such an environment
should be able to find a chain to one of the explicitly trusted subCAs,
right?

> We've already seen this born out
> with respect to DigiCert and their Managed PKI intermediates, and wanted
> to avoid disruption to both Apple and Google that would otherwise
> destablize the ecosystem.

What is the relationship between the distrust of Symantec CAs and
intermediates managed by DigiCert? Did DigiCert already run managed
intermediates, before the Symantec-to-DigiCert migration efforts begun,
that still depend on Symantec CAs to be trusted?

What is the potential disruption, and how are you avoiding it?

Are you avoiding it by including the two DigiCert Transition RSA/ECC
Root certificates in the whitelist?

Why is it necessary to refer to them by SPKI, e.g. do you expect there
might be future, alternative intermediates for transition roots those?


Also, I noticed that Gerv's post from 2017-10-17 had mentioned 7 Apple
subCAs,

https://crt.sh/?id=19602712
https://crt.sh/?id=19602724
https://crt.sh/?id=21760447
https://crt.sh/?id=5250464
https://crt.sh/?id=12716200
https://crt.sh/?id=19602706
https://crt.sh/?id=19602741

but the chromium "excluded" subdirectory contains only 6 Apple subCAs.

Based on your message, I just looked at them, but I see that all of them
have different SPKI. Do you know why the Chromium excluded directory
only lists 6 Apple subCAs?

> For example, if you note, there are two Google certificates, but they
> share the same SPKI and Subject Name - which is why the Chromium
> whitelist only has one certificate listed, as it extracts the SPKI from
> that resource as part of the whitelist.

Are you referring to these two subCAs?
https://crt.sh/?id=23635000
https://crt.sh/?id=142951186

It seems the first one has already expired, and it might no longer be
necessary to worry about it?

Thanks
Kai

[Piotr Kucharski]

On Mon, Feb 12, 2018 at 5:36 PM, Kai Engert <ka...@kuix.de> wrote:

> > For example, if you note, there are two Google certificates, but they
> > share the same SPKI and Subject Name - which is why the Chromium
> > whitelist only has one certificate listed, as it extracts the SPKI from
> > that resource as part of the whitelist.
>
> Are you referring to these two subCAs?
> https://crt.sh/?id=23635000
> https://crt.sh/?id=142951186
>
> It seems the first one has already expired, and it might no longer be
> necessary to worry about it?
>

While nothing is certain, it is likely that Google might have another subCA
certificate issued with the same SPKI and Subject.

[Ryan Sleevi]

On Mon, Feb 12, 2018 at 11:36 AM, Kai Engert <ka...@kuix.de> wrote:

> On 09.02.2018 22:20, Ryan Sleevi wrote:
> > As a small clarification - while Chrome has included the certificates,
> > as noted in the readme, the whitelist is based on SPKI. This was
> > intentional, to avoid situations of interoperability issues.
>
> Hi Ryan,
>
> IIUC, the current implementation in Firefox (for the early console
> warnings) is based on distinguished named (DN), not SPKI:
>
> https://hg.mozilla.org/integration/autoland/rev/d3acb68f73c4
>
>
> > Whitelisting by certificate, rather than either SPKI or SPKI-Tuple,
> > brings with it significant compatibility risks to the ecosystem in terms
> > of being able to respond to issues.
>
> Can these risks be avoided, too, by using the DN matching strategy that
> the Firefox code uses?
>

No.

> If not, it would be helpful to list these risks, and why they can only
> be addressed by using SPKI matching.
>

These risks were previously extensively discussed during the finalization
of the plan, and are expanded upon below.

Is your worry that alternative subCAs (already existing, or potentially
> being introduced in the future) could be used in server configurations,
> and that path building code might fail to match unexpected subCAs
> against the whitelist?
>

Yes.

> I hope we shouldn't have to worry about alternative, already existing
> subCAs. There shouldn't be alternative subCAs, because it would have
> been required to request their whitelisting already, right?
>

No, not if done by SPKI.

> Also, I hope we shouldn't have to worry about alternative, future
> subCAs. It's not allowed to use the old Symantec CA infrastructure to
> issue alternative subCAs that might require whitelisting, right?
>

No, it's not, provided they use the same SPKI.

https://crt.sh/?spkisha256=ac50b5fb738aed6cb781cc35fbfff7786f77109ada7c08867c04a573fd5cf9ee
is a concrete example of this.

The initial Transition RSA Root was cut, then issued under the VeriSign
Class 3 G5 root - https://crt.sh/?id=250864698

This was all done prior to 2017-12-01.

However, this was insufficient for a number of customers, who needed
certificates chaining to other roots. Several DigiCert/Symantec customers
reached out with examples of this, such as requiring chains to the VeriSign
Universal Root Certification Authority ( https://crt.sh/?caid=1110 ). There
is no path from G5 to UCA.

To accommodate such customers, DigiCert performed another signing ceremony,
on December 8, in which they issued several additional certificates which
chain to other Symantec roots (other than G5), while sharing the same SPKI.
To avoid causing path building issues on clients, each of these new
certificates varies by DN, but all share the same SPKI, providing assurance
that it's the same key material with the same audited controls as the
managed PKI.

When thinking about what assurances are desired by the Managed CA, the
security assurance is tied to the key, not to the name. This is why
Chrome's whitelist is based on SPKI - if the key is adequately secured and
audited, we have assurance, but the name can be associated with any key,
and is not.

It's not unreasonable to predict that, as the transition continues, and
more customers look to transition (particularly those with certificates
issued after 2016-06-01), we may see further managed CAs cut. In a DN-based
whitelist, all of these would fail to work in browsers unless code changes
were made, whereas in an SPKI whitelist, all of these would work just fine.

> A separate question which would be good to clarified: What about
> environments, which want to distrust all old Symantec roots in October
> 2018, but cannot add whitelisting to their cert validation code, and
> choose to explicitly trust each of the subCAs. Such an environment
> should be able to find a chain to one of the explicitly trusted subCAs,
> right?
>

You're asking about non-browser environments that cannot implemented
https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F
? I thought we'd ruled that out of scope rather comprehensively.

Explicitly trusting by sub-CAs is, in effect, a DN whitelist with added
restrictions, and thus runs the risk I mentioned.

> > We've already seen this born out
> > with respect to DigiCert and their Managed PKI intermediates, and wanted
> > to avoid disruption to both Apple and Google that would otherwise
> > destablize the ecosystem.
>
> What is the relationship between the distrust of Symantec CAs and
> intermediates managed by DigiCert? Did DigiCert already run managed
> intermediates, before the Symantec-to-DigiCert migration efforts begun,
> that still depend on Symantec CAs to be trusted?
>

I'm not sure I understand this question?

> What is the potential disruption, and how are you avoiding it?
>

See above.

> Are you avoiding it by including the two DigiCert Transition RSA/ECC
> Root certificates in the whitelist?


> Why is it necessary to refer to them by SPKI, e.g. do you expect there
> might be future, alternative intermediates for transition roots those?
>

Yes. For DigiCert (as we've already seen), potentially for Apple (as we've
had discussions with them), and potentially for Google (as Piotr has
mentioned below).

Based on your message, I just looked at them, but I see that all of them
> have different SPKI. Do you know why the Chromium excluded directory
> only lists 6 Apple subCAs?
>

Audit scope.

> Are you referring to these two subCAs?
> https://crt.sh/?id=23635000
> https://crt.sh/?id=142951186
>
> It seems the first one has already expired, and it might no longer be
> necessary to worry about it?
>

See Piotr's reply, and my restatement of what was already discussed above :)

[Kai Engert]

Hello Ryan,

thanks a lot for your very helpfull response!

A couple more comments below:

On 12.02.2018 19:13, Ryan Sleevi wrote:
> A separate question which would be good to clarified: What about
> environments, which want to distrust all old Symantec roots in October
> 2018, but cannot add whitelisting to their cert validation code, and
> choose to explicitly trust each of the subCAs. Such an environment
> should be able to find a chain to one of the explicitly trusted subCAs,
> right?
>
> You're asking about non-browser environments that cannot
> implemented https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F
> ? I thought we'd ruled that out of scope rather comprehensively.

Do you mean out of scope for this discussion on this list? I understand.

I wonder if we should have a separate mailing list, where secondary
consumers of the Mozilla CA list could exchange thoughts on how to
implement the changes intended by Mozilla as closely as possible.

> > We've already seen this born out
> > with respect to DigiCert and their Managed PKI intermediates, and wanted
> > to avoid disruption to both Apple and Google that would otherwise
> > destablize the ecosystem.
>
> What is the relationship between the distrust of Symantec CAs and
> intermediates managed by DigiCert? Did DigiCert already run managed
> intermediates, before the Symantec-to-DigiCert migration efforts begun,
> that still depend on Symantec CAs to be trusted?
>
> I'm not sure I understand this question?

I was trying to understand the origin of the additional subCAs, which
need to be covered using transitional intermediates. Who created those
managed CAs initially, and why are they related to the Symantec to
DigiCert transition? If they were originall issued by Symantec Root CAs,
why weren't they included in the initial list of subCAs that need to be
excluded?

This is just out of curiosity.

Kai

[Ryan Sleevi]

On Tue, Feb 13, 2018 at 11:30 AM, Kai Engert <ka...@kuix.de> wrote:

> Hello Ryan,
>
> thanks a lot for your very helpfull response!
>
> A couple more comments below:
>
> On 12.02.2018 19:13, Ryan Sleevi wrote:
> > A separate question which would be good to clarified: What about
> > environments, which want to distrust all old Symantec roots in
> October
> > 2018, but cannot add whitelisting to their cert validation code, and
> > choose to explicitly trust each of the subCAs. Such an environment
> > should be able to find a chain to one of the explicitly trusted
> subCAs,
> > right?
> >
> > You're asking about non-browser environments that cannot
> > implemented https://wiki.mozilla.org/CA:FAQ#Can_I_use_
> Mozilla.27s_set_of_CA_certificates.3F
> > ? I thought we'd ruled that out of scope rather comprehensively.
>
> Do you mean out of scope for this discussion on this list? I understand.
>

Not out of scope of discussion - I think it's good to have that discussion.
Personally, I view it more as a Tier-1 vs Tier-3 conversation, but I
realize others may see it as Tier-1 vs Tier-2, to use the
https://developer.mozilla.org/en-US/docs/Mozilla/Supported_build_configurations
terminology.

As it relates to the question you posed, I don't think we can reason about
the abstract "environments", but if there's a concrete environment you
maintain and can speak to, I think it's good to have that conversation.

Put differently yet again, I suppose I took the framing of the question as
"What if this change breaks platforms that don't have 8-bit bytes", and I'd
push back and say "If they're not here and able to engage, then so what".
If the question is "I support DEC-10 and this will break me", then I'm more
inclined to say "Let's try and find a solution that works, if you can speak
to your constraints and help debug, but this won't necessarily be a blocker
to landing"

Does that make it more palatable? :)

I wonder if we should have a separate mailing list, where secondary
> consumers of the Mozilla CA list could exchange thoughts on how to
> implement the changes intended by Mozilla as closely as possible.
>
>
> > > We've already seen this born out
> > > with respect to DigiCert and their Managed PKI intermediates, and
> wanted
> > > to avoid disruption to both Apple and Google that would otherwise
> > > destablize the ecosystem.
> >
> > What is the relationship between the distrust of Symantec CAs and
> > intermediates managed by DigiCert? Did DigiCert already run managed
> > intermediates, before the Symantec-to-DigiCert migration efforts
> begun,
> > that still depend on Symantec CAs to be trusted?
> >
> > I'm not sure I understand this question?
>
> I was trying to understand the origin of the additional subCAs, which
> need to be covered using transitional intermediates. Who created those
> managed CAs initially, and why are they related to the Symantec to
> DigiCert transition? If they were originall issued by Symantec Root CAs,
> why weren't they included in the initial list of subCAs that need to be
> excluded?
>

I'm still having trouble understanding your question.

There are two organizations operating externally-operated sub-CAs (e.g.
fully independent infrastructure, independently audited). That's Apple and
Google. They each have several certificates underneath the GeoTrust
hierarchy, and Apple at least has several keys as well. These are
organizations that, looking at a long-term view, should transition off
GeoTrust, just like every other Symantec customer should do. Yet they're
also organizations that are, for all available information, fully isolated
and independent from every known issue - that is, unlike server
operators/existing customers, none of their certificates are suspect due to
the issues.

Now, for various reasons, Symantec operated some of these CAs as requiring
annual renewal/review, based on contractual obligations. Solutions that
prevent that, in effect, are equivalent to distrusting those independent
operators - by preventing new certs. Both of these organizations have
substantial dependence on the GeoTrust root, although for different
reasons, and while both organizations are in the process of transitioning
those dependencies away, we don't want to create a situation where this
transition is suddenly interrupted. Is this ideal? No. Could this happen
with any other sub-CA operation? Unfortunately. Do we want to guarantee
this is how all future situations will be handled? Not necessarily.
However, it happened that the audits are comprehensive enough, and the risk
significant enough, to require consideration of these events. A whitelist
of SPKI doesn't allow new keys to be introduced (not ideal from risk
management), but does allow new certs to be issued to assist that
transition (if necessary).

Separate from this, DigiCert was selected as the Managed Partner
Infrastructure for Symantec. Setting aside the acquisition of Symantec's
PKI business, DigiCert is running sub-CAs underneath Symantec roots, to
issue certificates for customers to enable them to make a smooth and
orderly transition to other CAs - including DigiCert's own roots. The keys
were created by DigiCert (as per the Managed Partner Infrastructure plan),
while the certificates were signed by "Symantec" (ignoring, again, that it
was DigiCert-operating-Symantec's-PKI signing
DigiCert-as-Symantec's-Managed-Partner). It was expected (and has been
borne out) that not all of the necessary transitional paths would be
identified - despite significant discussion trying to find those paths. The
whitelist by SPKI allows the flexibility that, as additional transitional
paths and compatibility issues are discovered, new certificates (with new
DNs) can be identified and cut, to aid in those transitional paths.

Are these necessary for the Firefox or Chrome case, or more generally, the
browser case? Not as much, because in the browser case, you know what the
root set is, you know what the transitional paths are, generally speaking.
It largely matters for pinning, at least from the browser functionality
case.

Are they necessary for a "system" root store to consider, or more
abstractly, "systems" of root stores? Yes. That's why I'm saying it's risky
to bake it in for something like a list.

Further, if/as those paths have to be explored to support legacy systems,
you don't want the browser to choke on those, because then you're again
forcing it into the "either break in the browser, or break in the system" -
which is precisely the problem we're trying to mitigate. If we didn't care
about breaking those systems, baking in a DN whitelist, or even baking in
the cert themselves, would be fine. But the Managed Partner Infrastructure
transition plan was designed to find a way to meet browsers' security needs
*without* breaking those legacy systems, which is why a browser solution
that can lead to either/or choices is not ideal.

Does that make more sense?