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?

[Kai Engert]

On 13.02.2018 18:10, Ryan Sleevi wrote:
>
> On Tue, Feb 13, 2018 at 11:30 AM, Kai Engert <ka...@kuix.de
> <mailto:ka...@kuix.de>> wrote:
>
> A couple more comments below:
>
> On 12.02.2018 19:13, Ryan Sleevi wrote:
> >
> > 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

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

OK. I'm researching what approach should be used for the Fedora Linux
distribution, where a single CA trust list (based on Mozilla's CA trust
list) is used for the whole system, including Firefox, and other
applications that use other certificate validation logic, like the ones
built into the GnuTLS, NSS and OpenSSL libraries.

Based on the past and recent information exchanged on this list, my
current thinking is:

For the initial distrust phase in Spring 2018, ship the Mozilla CA list
as it is released with Firefox 60 and the respective NSS version. As a
consequence, the distrust of certificates issued by Symantec prior to
2016-06-01 would be limited to the Firefox and Chromium browsers (and
potentially including Thunderbird). All other SSL/TLS client software on
Fedora Linux would continue to allow the unlimited set of Symantec
issued certificates, as allowed by the Mozilla CA list.

For the second distrust phase in Autumn 2018, assume that all Symantec
customers (excluding the managed CAs that are covered by the whitelisted
subCA SPKIs) have been fully migrated off of the old CA hierarchies.
This assumption isn't limited to SSL/TLS server certificates used for
services intended to be consumed by web browsers, but includes all
SSL/TLS server certificates, including those used for non-https services
(e.g. email or LDAP servers).

Based on this assumption, follow Mozilla's plan to fully remove all
SSL/TLS trust flags from most Symantec Roots. The exception are the
three GeoTrust Roots, that have been used to issue the subCAs that
require special whitelisting in browsers. Because I don't expect such
whitelisting to get implemented broadly in non-browser software on
Fedora Linux, use the following approach: Continue to fully trust these
three GeoTrust Roots for SSL/TLS, for as long as Mozilla continues to
keep the subCA whitelisting active.

My understanding is, by continuing to trust these three GeoTrust Roots,
all the subCAs that get whitelisting in browsers will be trusted by the
non-browser software in Fedora Linux, too. A side effect is that the
remaining certificates issued by those Roots, which the browsers intend
to distrust by the whitelist implementation, will continue to be trusted
in other SSL/TLS client software on Fedora Linux, too, which is
derivating from Mozilla's intentions. However, given the inability to
implement the whitelisting in all SSL/TLS client software on Fedora
Linux, this approach seems to be the closest possible implementation,
which is realistic to get done, and which also assures full
compatibility with the public web.

Does this sound like a reasonable stragegy?

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

Ryan, thanks again for your very detailed explanations.

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

Does this mean, there are additional organizations (besides Apple,
Google and DigiCert) that have been assigned subCAs, that are operated
by DigiCert, which were previously depending on the Symantec Roots, and
which are now being migrated by DigiCert to DigiCert Roots?

Thanks
Kai

[Ryan Sleevi]

On Tue, Feb 13, 2018 at 4:40 PM, Kai Engert via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> For the second distrust phase in Autumn 2018, assume that all Symantec
> customers (excluding the managed CAs that are covered by the whitelisted
> subCA SPKIs) have been fully migrated off of the old CA hierarchies.
> This assumption isn't limited to SSL/TLS server certificates used for
> services intended to be consumed by web browsers, but includes all
> SSL/TLS server certificates, including those used for non-https services
> (e.g. email or LDAP servers).
>

I think this sounds pretty risky.

> Based on this assumption, follow Mozilla's plan to fully remove all
> SSL/TLS trust flags from most Symantec Roots. The exception are the
> three GeoTrust Roots, that have been used to issue the subCAs that
> require special whitelisting in browsers. Because I don't expect such
> whitelisting to get implemented broadly in non-browser software on
> Fedora Linux, use the following approach: Continue to fully trust these
> three GeoTrust Roots for SSL/TLS, for as long as Mozilla continues to
> keep the subCA whitelisting active.
>

So, I think this is conflating the "Independently Operated Sub-CAs" (of
Google and Apple) with the "Managed Partner Infrastructure" of DigiCert.

Using your proposed plan, you are also proposing to distrust the Managed
Partner Infrastructure at that date (by not maintaining any of the other
roots). That is a very different plan than I think what others have
publicly commented on to date. It's unclear to me whether 100% of
DigiCert's Managed Partner Infrastructure issued certificates will have
transitioned at this time, and what impact that may have.

> Does this sound like a reasonable stragegy?
>

Given the above concerns, I think that sounds rather substantially
different than what's been announced as part of the Managed Partner
Infrastructure transition document, and may be riskier.

> > 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.
>
> Does this mean, there are additional organizations (besides Apple,
> Google and DigiCert) that have been assigned subCAs, that are operated
> by DigiCert, which were previously depending on the Symantec Roots, and
> which are now being migrated by DigiCert to DigiCert Roots?
>

No, but it means that there are DigiCert-operated Intermediates under
non-GeoTrust roots that are being used to actively issue certificates which
are trusted in Chrome today, as part of the Managed Partner Infrastructure,
and which do not chain to DigiCert roots, but Symantec roots.

[Tim Hollebeek]

> OK. I'm researching what approach should be used for the Fedora Linux
> distribution, where a single CA trust list (based on Mozilla's CA trust
> list) is used for the whole system, including Firefox, and other
> applications that
> use other certificate validation logic, like the ones built into the GnuTLS,
> NSS
> and OpenSSL libraries.

FWIW, I realize we are where we are, but it's high time people started
migrating
away from the concept of a single operating system trust list that is consumed
by all applications on the platform. It just doesn't work very well since
each
application type has its own unique security considerations, risks, and
challenges.
And threat model, risk tolerance, value of data being protected, necessary
assurance level, etc etc etc.

It's ok to rely heavily on other trust stores to assist with bootstrapping or
maintaining a trust store, and this can even be codified directly into the new
trust store's policy. For example, this is the approach taken by Cisco whose
trust store policy is basically the union of what's trusted by other major
trust
stores. It's a good baby step towards establishing an independent and well
maintained trust store.

Major trust stores have taken various actions nudging certificate authorities
to
use a combination of technical constraints and/or EKUs and/or different
intermediate CAs in order to better segregate certificates by use case, and
I'd
encourage them to continue with those efforts. The current situation is a bit
of a mess, and it will take us years to get it all untangled.

-Tim

[Kai Engert]

Ryan,

thanks for highlighting that I missed a few Roots.

So originally, the October 2017 announcemend had mentioned:
- GeoTrust Global CA
- GeoTrust Primary Certification Authority - G2
- GeoTrust Primary Certification Authority - G3

Looking at the data available at
https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec
more closely, I see a total of 5 Roots that, which issued subCAs that
are listed in the "excluded" and "managed" directories (3 GeoTrust, 2
VeriSign):
- VeriSign Class 3 Public Primary Certification Authority - G4
- VeriSign Class 3 Public Primary Certification Authority - G5

Now I looked again at your recent example
https://crt.sh/?spkisha256=ac50b5fb738aed6cb781cc35fbfff7786f77109ada7c08867c04a573fd5cf9ee
where you mentioned, that additional root CAs had to be created on
December 8.

In that list, I see several self-signed roots and several additional
subCAs. The subCAs chain to these additional Roots:
- GeoTrust Primary Certification Authority
- thawte Primary Root CA
- thawte Primary Root CA - G3
- VeriSign Class 3 Public Primary Certification Authority - G3
- VeriSign Universal Root Certification Authority

You also said, at this time it's unknown if creation of additional
subCAs might be necessary.

What does that mean for non-browser SSL/TLS client software, which
cannot do whitelisting based on SPKI, but which wants to ensure
compatibility with non-migrated certificates?

Does it mean that such software should continue to keep trusting all
Symantec Roots from the Symantec Legacy infrastructure, beyond October
2018, for an currently unknown period of time?


Furthermore, in the above list at crt.sh I see that several self-signed
Roots were created. I don't understand why that was necessary. At
https://bugzilla.mozilla.org/show_bug.cgi?id=1401384#c13 Jeremy
commented that including additional Roots won't be necessary for the
migration.

What was the purpose of creating those new self-signed Roots?
Thanks
Kai

[Ryan Sleevi]

On Thu, Feb 15, 2018 at 9:37 AM, Kai Engert via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> What does that mean for non-browser SSL/TLS client software, which
> cannot do whitelisting based on SPKI, but which wants to ensure
> compatibility with non-migrated certificates?
>

There are, effectively, two migrations at play.

The Managed Partner Infrastructure plan was designed around a first
migration, which was a migration from Symantec's Legacy Infrastructure onto
that of Managed Sub-CAs. The intent of the design, and as attempted to be
publicly communicated as best possible, was that existing Symantec trusted
roots would have a Managed Sub-CA created under each one (as/if necessary).
As part of the distrust, existing Symantec customers would be able to
freely choose any publicly trusted CA as a replacement CA. If they had
systemic need for trust to chain to Symantec's roots (for example, due to
supporting legacy devices), they could obtain certificates from that
Managed Partner Infrastructure. Similarly, if they had systems that were
integrated with Symantec's issuance systems, and those transitions required
time, the transition to the Managed Partner Infrastructure could allow for
uninterrupted issuance during the phased distrust, providing those
customers time to re-examine their issuance integration, potentially
looking at standards-based approaches (such as ACME) that would provide
greater flexibility and choice in CAs in the future.

This is the first migration - from Symantec issuance to the Managed Partner
Infrastructure.

Following the announcement and finalization of that plan, Symantec
announced they were selling their PKI business to DigiCert/Thoma Bravo.
This transitioned control of the Legacy Infrastructure (which was to be
distrusted) to DigiCert, who also happened to be the operator of the
Managed Partner Infrastructure.

As part of this transition, DigiCert integrated Symantec's legacy APIs to
support cases where issuance was directed to DigiCert roots, rather than
the Managed Partner Infrastructure, or to the Managed Partner
Infrastructure itself. Further, while it was repeatedly highlighted as
unadvisable, they also cross-signed existing DigiCert roots with Legacy
Symantec Roots, allowing new, nominally DigiCert certificates, to chain
either to existing DigiCert roots or, for systems that did not support
them, to a limited number of Symantec roots.

This is the second migration - from Symantec issuance to DigiCert-chaining
certificates.

Not all customers' software support the second migration - for example,
cross-signing with multiple roots is a very risky (for compatibility)
option, and so the DigiCert-roots-cross-signed-by-Symantec only go to one
Symantec root each, effectively. When they support a single root that
hasn't cross-signed DigiCert, such as "VeriSign Universal Root
Certification Authority", they can instead leverage the first migration -
the Managed Partner Infrastructure - to maintain support.

Further, not all customers' software supports the first migration - for
example, some embedded software may have assumptions about the length of
the chain or the issuing intermediate embedded within the software. This
was a poor design choice on the device manufacturer/software manufacturers
support, but this reality exists. So some customers find it necessary to
opt out of the migration entirely. If you look at crt.sh for issuance
underneath the Legacy Symantec Infrastructure, you can see entities like
AT&T, TD Bank, VIP providers, and others using it. One can presume this is
to support things such as desktop phones and payment terminals, which
Symantec had raised in the past as part of their customer base.

So what does that mean for non-browser client software? It depends.

If your client software has to support and interoperate with the same
endpoints being used for those ultra-legacy devices (phones and payment
terminals), then that software still needs to trust the Legacy Symantec
Infrastructure. Those operating such endpoints should work to try and
extricate the endpoints, such that there are two endpoints, for 'modern'
and 'legacy', at a minimum. A better design is to ensure that when working
with partner devices that may not be updatable, a unique
hostname-per-device is given (e.g. foo-device.example.com,
bar-device.example.com, where Foo and Bar are different device
manufacturers), to ensure that future trust migrations can be done in a
more calculated way.

If your client software has to support and interoperate with endpoints that
are using the Managed Partner Infrastructure (those that chain to Symantec
roots, but operated by DigiCert, and do not chain to DigiCert roots), then
the design of the Managed Partner Infrastructure plan was such that you can
remove the Legacy Symantec roots, but introduce the Managed Partner
Infrastructure as 'new' roots. For your clients, the path will be seen as
going from Symantec to going to a (shorter) path, but still trusted. Legacy
devices would see the longer path to Legacy Symantec roots, while your
clients would see the shorter path to the Managed Partner Infrastructure.
You would also need to, at a minimum, add the Independently Operated
Sub-CAs as Roots as well, to avoid further disruption to your users.
Unfortunately, on this last point, it does put certain limits on those
Sub-CA operators for transitioning, depending on your client software.
Whitelisting by SPKI is a much better option, but that's dependent upon
your client libraries. This is why it's dangerous irresponsible to ship a
root store that is not bound to a specific set of validation software -
treating validation independently versioned of trust is a recipe for
long-term disaster.

Assuming your clients cannot whitelist by SPKI, then the other option is to
continue trusting those Legacy Symantec Roots while your customers/clients
use the additional time to migrate from the Managed Partner Infrastructure
onto any other publicly trusted CA, including that of DigiCert's roots
(which have the cross-signs to some of the Legacy Symantec Roots). This
means trusting longer, but reflects that clients other than webservers may
have additional time requirements.


Finally, it's anticipated there will be a third migration, which will be
from the Managed Partner Infrastructure onto DigiCert's roots, at least in
terms of API integration and endpoints. DigiCert would need to share their
timelines for when they see that migration going from the MPI to DC, and
whether there are any other API migrations planned, such as deprecating
some of the legacy APIs (some of which date back to nearly 20 years ago)

[Kai Engert]

Hello Ryan,

thanks again for this response. The situation appears very complex. I
might follow up with a couple of clarification questions, that are
hopefully simple to answer. Let me start with this one:

Chromium will whitelist the SPKIs of a "CN=DigiCert Transition ECC Root"
and a "CN=DigiCert Transition RSA Root" certificate, as found in this
directory:
https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/managed

Are there any Apple systems, servers, infrastructure, devices, that rely
on any of these DigiCert transition Root CAs?

Are there any Google systems, servers, infrastructure, devices, that
rely on any of these DigiCert transition Root CAs?

The point of my question is to clarify, if the DigiCert transition Roots
are completely separate from the Apple/Google subCA whitelisting
requirements.

Thanks
Kai

[Ryan Sleevi]

I'm not sure how to interpret the Apple/Google question, but yes, they are
treated as completely separate.

The distinction here between the "Managed Sub-CA" and "Independently
Operated Sub-CA" goes back to the announced Managed Partner Infrastructure
plan. The Managed Sub-CAs have requirements imposed on them (such as CT or
audit frequency), as part of the risk-mitigation for the Managed Partner
Infrastructure plan, that the IOSCs did not.

[Kai Engert]

On 01.03.2018 18:45, Ryan Sleevi via dev-security-policy wrote:
>>
>> The point of my question is to clarify, if the DigiCert transition Roots
>> are completely separate from the Apple/Google subCA whitelisting
>> requirements.
>>
>
> I'm not sure how to interpret the Apple/Google question, but yes, they are
> treated as completely separate.

I'm trying to have a clearer understanding about "who needs what".

Let me reword it.

Google requests that certain subCA SPKIs are whitelisted, to ensure
continued trust of Symantec-issued certificates that are used by
infrastructure that is operated by Google.

Is whitelisting the SPKI found in the Google subCA sufficient to achieve
the need of trusting Google's server infrastructure?

I assume the answer is yes. If I'm right, and the answer is "yes", then
it means that whitelisting the SPKIs from the DigiCert transition Roots
isn't required for Google's servers. It's required for continued trust
of other, non-Google server systems.

Or rephrasing again: There are no Google servers that use certificates
from DigiCert's Managed Partner Infrastructure.

I further assume that it's possible to replace the word Google with the
word Apple in all previous paragraphs, and the statements are still correct.

Thanks
Kai

[Ryan Sleevi]

Gotcha.

I can't personally speak to that, then - that's up to Apple and Google's
PKI teams - but:
1) I'm not aware of it
2) But it's also not prohibited. The solution was designed to accommodate
that case if they should need.

[Ryan Hurst]

> >
> > Google requests that certain subCA SPKIs are whitelisted, to ensure
> > continued trust of Symantec-issued certificates that are used by
> > infrastructure that is operated by Google.
> >
> > Is whitelisting the SPKI found in the Google subCA sufficient to achieve
> > the need of trusting Google's server infrastructure?

Kai,

I will do my best to answer this question.

Alphabet has a policy that all of its companies should be getting certificates from the Google PKI infrastructure. Right now in the context of certificate chains you see that manifested as certificates issued under GIAG2 and GIAG3.

We are actively migrating from GIAG2 (issued under a Symantec owned Root) to GIAG3 (issued under a root we own and operate). This transition will be complete in August 2018.

Given the size and nature of the Google organization sometimes other CAs are used either on accident because the team did not know any better, because the organization is part of an acquisition that is not yet integrated or there may be some sort of exceptional requirement/situation that necessitates it.

For this, and other reasons, we tell partners that we reserve the right to use other roots should the need arise and we publish a list of root certificates we may use (https://pki.goog/faq.html see what roots to trust).

As for the use of the With that background nearly all certificates for Alphabet (and Google) properties will be issued by a Google operated CA.

In the context of the whitelist, we believe the SPKI approach should be sufficient for those applications who also need to whitelist associated CA(s).

I am also not aware of any Alphabet properties utilizing the DigiCert's Managed Partner Infrastructure (beyond one subca they operate that is not in use).

In summary while a SPKI whitelist should work for the current situation applications communicating with Alphabet properties should still trust (and periodically update to) the more complete list of roots listed in the FAQ.

Ryan Hurst
Google

[Wayne Thayer]

Update:

Mozilla is moving forward with our implementation of the consensus plan for
Symantec roots [1]. With the exception of whitelisted subordinate CAs using
the keys listed on the wiki [2], Symantec certificates are now blocked by
default on Nightly builds of Firefox. The preference
"security.pki.distrust_ca_policy" can be used to override these changes. A
custom error message is also being implemented [3]. These changes are part
of Firefox 60, which is scheduled to be released in May [4].

There are still a lot of websites using Symantec certificates, but the
number are declining rapidly. Lists of affected sites and regularly updated
metrics are available via bug 1434300 [5].

- Wayne

[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/FLHRT79e3XE/
90qkf8jsAQAJ
[2] https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1441223
[4] https://wiki.mozilla.org/RapidRelease/Calendar
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1434300

[Doug Beattie]

Hi Wayne,

Is the Firefox 60 update in May the same as the combination of the April and October Chrome updates, in that all Symantec certificates will be untrusted on this date (5 months before Chrome)?

Doug

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of Wayne
> Thayer via dev-security-policy
> Sent: Friday, March 2, 2018 1:12 PM
> Cc: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
> Subject: Re: Mozilla’s Plan for Symantec Roots
>

[Wayne Thayer]

On Fri, Mar 2, 2018 at 11:58 AM, Doug Beattie <doug.b...@globalsign.com>
wrote:

> Hi Wayne,
>
> Is the Firefox 60 update in May the same as the combination of the April
> and October Chrome updates, in that all Symantec certificates will be
> untrusted on this date (5 months before Chrome)?
>

> Sorry for not making that clear Doug. Firefox is implementing the
consensus plan as originally described, meaning that Firefox 60 only blocks
Symantec certificates issued prior to 1-June 2016. We plan to remove that
restriction in Firefox 63.

Doug
>
>