Re: Mozilla’s Plan for Symantec Roots

[Wayne Thayer via dev-security-policy]

On Fri, Mar 2, 2018 at 11:58 AM, Doug Beattie 
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
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Mozilla’s Plan for Symantec Roots

[Doug Beattie via dev-security-policy]

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=globalsign@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-security-pol...@lists.mozilla.org>
> Subject: Re: Mozilla’s Plan for Symantec Roots
> 
> 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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Wayne Thayer via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Ryan Hurst via dev-security-policy]

> >
> > 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Ryan Sleevi via dev-security-policy]

On Thu, Mar 1, 2018 at 4:45 PM, Kai Engert via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

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


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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Kai Engert via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Kai Engert via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Ryan Sleevi via dev-security-policy]

On Thu, Feb 15, 2018 at 9:37 AM, Kai Engert via dev-security-policy <
dev-security-policy@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, 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, 

Re: Mozilla’s Plan for Symantec Roots

[Kai Engert via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Mozilla’s Plan for Symantec Roots

[Tim Hollebeek via dev-security-policy]

> 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




smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Ryan Sleevi via dev-security-policy]

On Tue, Feb 13, 2018 at 4:40 PM, Kai Engert via dev-security-policy <
dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Kai Engert via dev-security-policy]

On 13.02.2018 18:10, Ryan Sleevi wrote:
> 
> On Tue, Feb 13, 2018 at 11:30 AM, Kai Engert  > 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
> 
> 
> > ? 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Ryan Sleevi via dev-security-policy]

On Tue, Feb 13, 2018 at 11:30 AM, Kai Engert  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 

Re: Mozilla’s Plan for Symantec Roots

[Kai Engert via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Ryan Sleevi via dev-security-policy]

On Mon, Feb 12, 2018 at 11:36 AM, Kai Engert  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 

Re: Mozilla’s Plan for Symantec Roots

[Piotr Kucharski via dev-security-policy]

On Mon, Feb 12, 2018 at 5:36 PM, Kai Engert  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Kai Engert via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Ryan Sleevi via dev-security-policy]

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 <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Feb 8, 2018 at 7:26 AM, Kai Engert via dev-security-policy <
> dev-security-policy@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
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Wayne Thayer via dev-security-policy]

On Thu, Feb 8, 2018 at 7:26 AM, Kai Engert via dev-security-policy <
dev-security-policy@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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[westmail24--- via dev-security-policy]

Also, it should be understood that on Linux OS no transitional periods will be 
made, but simply to removes all Symantec certificates from a certain date.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Kai Engert via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Kai Engert via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Kai Engert via dev-security-policy]

On 16.10.2017 19:33, Gervase Markham via dev-security-policy 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):
> 
> * 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.

My understanding is, this will be done without making any changes to the
Mozilla CA list. Firefox will implement these initial phases by changing
its certificate validation code.

It seems likely that many other consumers of the Mozilla CA list, which
use their own implementation for certificate validation, will likely not
implement these initial phases. I'm probably stating the obvious.

I'd like to thank the developers who can implement this initial distrust
phase in their software, as it will clear the way for the later phase of
distrust, benefitting other TLS client software which cannot easily
implement the initial phases.


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

This is the milestone that will affect also the secondary consumers of
the Mozilla CA list. I assume the updated CA list with the removed
Symantec roots will be published as part of NSS 3.39 around mid October.


> However, there are some subCAs of the Symantec roots that are
> independently operated by companies ... [snip] ...> There are two ways that 
> we can provide a smoother transition for these
> subCAs.

I haven't seen a follow up message with a decision on this detail. I
assume it's still open for discussion.


> Option 1)
> Temporarily treat these subCAs as directly-included trust-anchors.
> ... [snip]
> 
> 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. ... [snip]

I assume that these subCAs are used on the public web. IIUC, after
secondary consumers of the Mozilla CA list update to the newer version,
they will also require a solution that allows them to continue to trust
these subCAs.

Option 2 solves the issue for Firefox, but it isn't a practical solution
for secondary consumers of the Mozilla CA list.

There are too many implementations of certificate validation, and I
think it's unrealistic that each implementation can implement Option 2.

Without implementing option 2, but to keep compatibility with the public
web, those secondary consumers would have to modify the Mozilla CA list.
There's risk they might decide to continue to trust the Symantec CAs, as
that would be the easiest and most compatible approach. I think we
should avoid that secondary consumers might consider this solution, as
it would be counterproductive to this initiative.

I understand that secondary consumers of the Mozilla CA list aren't the
primary focus of Mozilla and of this policy list, but in the interest of
applying the Symantec distrust initiative to the majority of the open
source software ecosystem, it might be prererable to implement Option 1
in the Mozilla CA list.

Gerv mentioned the following concerns on Option 1:

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

If consumers of the Mozilla CA list usually followed Mozilla's removal
decisions, why would they not follow Mozilla's removal of these CAs at a
later time?

Why would this be more risky than Option 2? Couldn't we similarly argue,
if a secondary consumer of the Mozilla CA list decided to implement
whitelisting of these subCAs in their certificate validation code, isn't
there similar risk that they wouldn't remove such whitelisting from
their code? I'd even argue that a code implementation has a higher risk
of surviving for a longer amount of time, because changing code is more
difficult than changing configuration files that contain a list of
trusted CAs.


> Additionally, it could become very complicated to remove
> such subCAs in the future, especially if they have not performed the
> recommended transitions.

This message was sent in October 2017. By the time we reach October
2018, the owners of the subCAs will have known about the need to
transition away from the classic Symantec PKI for one year. In the 

Re: Mozilla’s Plan for Symantec Roots

[Gervase Markham via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Ryan Sleevi via dev-security-policy]

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-security-policy@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  w...@gmail.com>> wrote:
>
> On Fri, Oct 27, 2017 at 9:21 AM, Jeremy Rowley
> > 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=
> digicert.com@lists.mozilla
> .org] On Behalf Of Peter Bowen via dev-security-policy
> Sent: Friday, October 27, 2017 9:52 AM
> To: Gervase Markham >
> Cc: mozilla-dev-security-pol...@lists.mozilla.org la-dev-security-pol...@lists.mozilla.org>; Kathleen Wilson
> >
> Subject: Re: Mozilla's Plan for Symantec Roots
>
> On Tue, Oct 17, 2017 at 2:06 AM, Gervase Markham > 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 

Re: Mozilla’s Plan for Symantec Roots

[Peter Bowen via dev-security-policy]

On Tue, Oct 17, 2017 at 2:06 AM, Gervase Markham  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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Gervase Markham via dev-security-policy]

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

As have Google.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Kai Engert via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Gervase Markham via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Gervase Markham via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Gervase Markham via dev-security-policy]

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/0011J17aa6MQAQ
 |  https://crt.sh/?id=142951186
 |
 |_ Google Internet Authority G2 (2015-04-01 -> 2017-12-31)
https://ccadb.my.salesforce.com/001o00utwbKAAQ
https://crt.sh/?id=23635000

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

GeoTrust Primary Certification Authority - G2
 |
 |_ Apple IST CA 4 - G1
 |  https://ccadb.my.salesforce.com/001o00p4ScIAAU
 |  https://crt.sh/?id=19602712
 |
 |_ Apple IST CA 7 - G1
 |  https://ccadb.my.salesforce.com/001o00p4ScIAAU
 |  https://crt.sh/?id=19602724
 |
 |_ Apple IST CA 8 - G1
https://ccadb.my.salesforce.com/001o00qRJHFAA4
https://crt.sh/?id=21760447

GeoTrust Primary Certification Authority - G3
 |
 |_ Apple IST CA 3 - G1
 |  https://ccadb.my.salesforce.com/001o00p4SciAAE
 |  https://crt.sh/?id=19602706
 |
 |_ Apple IST CA 6 - G1
https://ccadb.my.salesforce.com/001o00p4ScoAAE
https://crt.sh/?id=19602741

I will get Google and Apple to validate this data.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Peter Bowen via dev-security-policy]

On Mon, Oct 16, 2017 at 10:32 AM, Gervase Markham via
dev-security-policy  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Daniel Cater via dev-security-policy]

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?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Eric Mill via dev-security-policy]

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

On Mon, Oct 16, 2017 at 1:32 PM, Gervase Markham via dev-security-policy <
dev-security-policy@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):
>
> * 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
>