On 13.02.2018 18:10, Ryan Sleevi wrote:
> On Tue, Feb 13, 2018 at 11:30 AM, Kai Engert <k...@kuix.de
> <mailto:k...@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
> > ? 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
> 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?
dev-security-policy mailing list