Re: Public trust of VISA's CA

[Paul Kehrer via dev-security-policy]

On February 14, 2018 at 4:17:16 AM, Wayne Thayer via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:

> The most recent BR audit report for the Visa eCommerce Root contains 3
qualifications: http://enroll.visaca.com/WTBR%20eComm.pdf

Does Mozilla have any guidelines or official position on what constitutes
sufficient audit issues to result in sanctions? Frankly I'm stunned that
any CA in the Mozilla root program can apparently ignore the baseline
requirements for approximately 4 years after their effective date, get an
initial BR audit with multiple qualifications, and see no penalty from this
behavior. And this is disregarding several other BR violations found in the
wild by independent researchers. I realize I'm banging the same drum as in
my other thread, but without consistent enforcement of escalating penalties
I don't believe we're teaching CAs anything other than that Mozilla will
ultimately forgive almost any transgression. Unless you catch them on a bad
day, in which case you might get distrusted entirely.

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

Re: Japan GPKI Root Renewal Request

[Ryan Sleevi via dev-security-policy]

On Mon, Feb 12, 2018 at 6:31 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> All of my questions regarding the CP/CPS and audits have been answered to
> my satisfaction. I am left with two concerns:
>
> 1. This root was signed on 12-March 2013. The first end-entity certificate
> that I'm aware of was signed later in 2013. Mozilla began requiring BR
> audits in 2014, but the first BR assessment for this root was on
> 30-September 2015. [1] The assessment shows 22 issues. [2] A PITRA was
> finally performed on January 31, 2017 [3] and no qualifications were noted.
> This was followed by a clean period-of-time audit. It is clear that
> hundreds of certificates were issued in this certificate hierarchy while it
> was not BR compliant, some of which have not yet expired.
>
> 2. A number of misissued certificates under this hierarchy have been logged
> [4], some of which are still valid. Some of these contain significant
> compatibility problems such as the lack of a SAN and the lack of an OCSP
> URL. The good news is that all of the bad certificates were issued prior to
> 2017.
>
> At a minimum, the unexpired misissued certificates should be revoked, just
> as has been done by other CAs in the Mozilla program. However, given the
> demonstrated lack of BR compliance from 2013-2016, we should consider
> rejecting this request and requiring that a new root using a new key pair
> be generated and submitted for inclusion.


Given the situations with the audits - which effectively prevent the
community from having any assurances of its operation from 2013 until 2017
- I wholly support rejecting the request to include this root.

To avoid ambiguity, I mean rejecting the request completely, and requiring
that any future request for inclusion be done as a new request, with new
key material, and with unblemished audits, as it would any other new CA.

Despite the proposed set of constraints, I do not think it is in the
interests of the Internet community to knowingly support some domains being
intentionally “less secure” than others, which is what the effect of the
proposed constraints would mean.


>
> Please be aware that trust in this root will be constrained to .go.jp
> domains, significantly reducing the risk it presents to Mozilla users.
>
> I would appreciate everyone's constructive feedback on these issues, and
> any others that are relevant to this inclusion request.
>
> - Wayne
>
> [1] https://bug870185.bmoattachments.org/attachment.cgi?id=8667814
> [2] https://bug870185.bmoattachments.org/attachment.cgi?id=8667815
> [3] https://bug870185.bmoattachments.org/attachment.cgi?id=8852738
> [4]
>
> https://crt.sh/?caid=1419=cablint,zlint,x509lint=2013-01-01
>
> On Mon, Feb 5, 2018 at 10:05 PM, apca2.2013--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Below is the answer to the pointed out earlier.
> >
> > == Bad ==
> > * CPS docs are not assigned a version number (Mozilla policy 3.3)
> >
> > We had set up CP / CPS version number assignment rules. Based on this, at
> > present CP / CPS Root version is Ver. 1.05 and CP / CPS Sub version is
> > 1.07. We attached CP / CPS with version number.
> >
> >
> > * I can’t find a current WebTrust for CAs audit statement - I've
> requested
> > a translated copy in the bug. There may be confusion over the fact that
> two
> > audits are required.
> >
> > Since the audit reports were posted on WebTrust's website as follows, we
> > will report those URLs.
> > WebTrust: https://cert.webtrust.org/ViewSeal?id=2385
> > SSLBR: https://cert.webtrust.org/ViewSeal?id=2386
> >
> >
> > * The translated WebTrust BR audit report does not include all the
> > information required by Mozilla policy 3.1.4. Based on information in the
> > bug I believe this meant to be a period-of-time audit, but it looks like
> a
> > point-in time readiness audit.
> >
> > (Same as the above answer）
> > Since the audit reports were posted on WebTrust's website as follows, we
> > will report those URLs.
> > WebTrust: https://cert.webtrust.org/ViewSeal?id=2385
> > SSLBR: https://cert.webtrust.org/ViewSeal?id=2386
> >
> >
> > == Meh ==
> > * Full name of the BRs is cut off in section 1: “CA/Browser  Forum,
> > Baseline Requirements for the Issuance and Management of Publicly.”
> >
> > At the next revision, we will modify the corresponding part of CP / CPS
> > section 1 of application CA 2 (Root) and application CA 2 (Sub) as
> follows.
> > Application CA 2 (Root / Sub) conforms to the Baseline Requirements of CA
> > / Browser Forum published at https://www.cabforum.org/.
> >
> >
> > * Revision history doesn’t state what was changed (Mozilla policy 3.3
> > requires a “dated changelog” but doesn’t explicitly require a description
> > of changes to be included)
> >
> > At the next revision, we will add a change history of application CA 2
> > (Root) and application CA 2 (Sub).
> >
> >
> > * Neither the CPS or the BR Self Assessment explain how 

Re: Public trust of VISA's CA

[Jonathan Rudenberg via dev-security-policy]

> On Feb 13, 2018, at 19:16, Wayne Thayer via dev-security-policy 
>  wrote:
> 
> On Tue, Feb 13, 2018 at 10:49 AM, Jonathan Rudenberg 
> wrote:
> 
>> 
>>> On Sep 19, 2017, at 11:12, Gervase Markham via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>> 
>>> In the light of this, I believe it is reasonable to discuss the question
>>> of whether Visa's PKI (and, specifically, the VISA eCommerce Root,
>>> https://crt.sh/?id=896972 , which is the one includes in our store)
>>> meets the criteria for inclusion in Mozilla's Root Store Policy, and
>>> whether it is appropriate for them to continue to hold public trust.
>>> Your comments are welcome.
>> 
>> I don’t think this issue ever got a conclusion. It is clear to me that
>> Visa should be removed from the Mozilla root program immediately.
>> 
> We did reach a conclusion on the original question that Gerv raised in
> this thread: does Visa meet the following requirement from section 2.1 of
> the Mozilla root store policy:
> 
> CAs whose certificates are included in Mozilla's root program MUST provide
> some service relevant to typical users of our software products.

This is an answer to the first question, the second part is “whether it is 
appropriate for them to continue to hold public trust.”

> In the thread on this list titled "Updating Root Inclusion Criteria" it was
> decided that we will not attempt to restrict organizations from
> participating in the Mozilla CA program based on a judgement of their value
> to our users.

Right, but a judgement based on risk to users seems prudent.

> The most recent BR audit report for the Visa eCommerce Root contains 3
> qualifications: http://enroll.visaca.com/WTBR%20eComm.pdf

And one of these qualifications is for a critical component of the job:

> We were unable to obtain evidence of the domain validation documentation for 
> a certificate issued.

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

Re: Public trust of VISA's CA

[Wayne Thayer via dev-security-policy]

On Tue, Feb 13, 2018 at 10:49 AM, Jonathan Rudenberg 
wrote:

>
> > On Sep 19, 2017, at 11:12, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > In the light of this, I believe it is reasonable to discuss the question
> > of whether Visa's PKI (and, specifically, the VISA eCommerce Root,
> > https://crt.sh/?id=896972 , which is the one includes in our store)
> > meets the criteria for inclusion in Mozilla's Root Store Policy, and
> > whether it is appropriate for them to continue to hold public trust.
> > Your comments are welcome.
>
> I don’t think this issue ever got a conclusion. It is clear to me that
> Visa should be removed from the Mozilla root program immediately.
>
> We did reach a conclusion on the original question that Gerv raised in
this thread: does Visa meet the following requirement from section 2.1 of
the Mozilla root store policy:

CAs whose certificates are included in Mozilla's root program MUST provide
some service relevant to typical users of our software products.

In the thread on this list titled "Updating Root Inclusion Criteria" it was
decided that we will not attempt to restrict organizations from
participating in the Mozilla CA program based on a judgement of their value
to our users.

Visa has been extremely unresponsive in general. The most recent case was
> their non-compliant OCSP responder: https://bugzilla.mozilla.org/s
> how_bug.cgi?id=1398261
>
> It took them five months to fix the problem, and there is still no
> incident report.
>
> Correct. Would a representative from Visa care to comment on this?

In their response to January CA Communication Action 2 (about insecure
> domain validation methods), they did not provide a comment response, but
> selected the option indicating they were using these vulnerable methods and
> required a date for an update in the comment field:
>
> > We have active (not expired or revoked) certificates issued using these
> methods. We will review our implementation for vulnerabilities and report
> our findings on the mozilla.dev.security.policy list by the date specified
> in the comments section below.
>
> Good point. I would appreciate a response from a Visa representative with
the date by which these findings will be reported.


> There are currently only 90 unexpired certificates issued by this CA known
> to CT: https://crt.sh/?Identity=%25=1414=expired (last time
> we looked, there were only 27 and two were revoked)
>
> Additionally, the telemetry shows an extremely small number of validations.
>
> It’s not clear to me from their responses whether they are even currently
> BR-compliant, and as of September 13, 2017 it seems like they weren’t:
>
> > Regarding BR compliance, we completed our initial BR audit in September
> of 2016.  Since that time, we have been addressing the observations noted
> by our external auditors.  This also would encompass any certificate issues
> that have been publically reported.  Understanding that such changes in
> adopting a new process will have business impact, it is difficult to
> provide an accurate timeline of complete compliance as we are required to
> assess the impact to our client and payment systems to avoid any
> operational impact.  We are committed to aligning with BR and Mozilla
> requirements as we have continuously move forward in making the necessary
> changes .
>
> The most recent BR audit report for the Visa eCommerce Root contains 3
qualifications: http://enroll.visaca.com/WTBR%20eComm.pdf

Given all this, I don’t think there is a lot of risk to Mozilla’s users
> with no benefit if Visa continues to be included in the root program.
>
> Jonathan
___
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: Public trust of VISA's CA

[Jonathan Rudenberg via dev-security-policy]

> On Sep 19, 2017, at 11:12, Gervase Markham via dev-security-policy 
>  wrote:
> 
> In the light of this, I believe it is reasonable to discuss the question
> of whether Visa's PKI (and, specifically, the VISA eCommerce Root,
> https://crt.sh/?id=896972 , which is the one includes in our store)
> meets the criteria for inclusion in Mozilla's Root Store Policy, and
> whether it is appropriate for them to continue to hold public trust.
> Your comments are welcome.

I don’t think this issue ever got a conclusion. It is clear to me that Visa 
should be removed from the Mozilla root program immediately.

Visa has been extremely unresponsive in general. The most recent case was their 
non-compliant OCSP responder: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1398261

It took them five months to fix the problem, and there is still no incident 
report.

In their response to January CA Communication Action 2 (about insecure domain 
validation methods), they did not provide a comment response, but selected the 
option indicating they were using these vulnerable methods and required a date 
for an update in the comment field:

> We have active (not expired or revoked) certificates issued using these 
> methods. We will review our implementation for vulnerabilities and report our 
> findings on the mozilla.dev.security.policy list by the date specified in the 
> comments section below.

There are currently only 90 unexpired certificates issued by this CA known to 
CT: https://crt.sh/?Identity=%25=1414=expired (last time we 
looked, there were only 27 and two were revoked)

Additionally, the telemetry shows an extremely small number of validations.

It’s not clear to me from their responses whether they are even currently 
BR-compliant, and as of September 13, 2017 it seems like they weren’t:

> Regarding BR compliance, we completed our initial BR audit in September of 
> 2016.  Since that time, we have been addressing the observations noted by our 
> external auditors.  This also would encompass any certificate issues that 
> have been publically reported.  Understanding that such changes in adopting a 
> new process will have business impact, it is difficult to provide an accurate 
> timeline of complete compliance as we are required to assess the impact to 
> our client and payment systems to avoid any operational impact.  We are 
> committed to aligning with BR and Mozilla requirements as we have 
> continuously move forward in making the necessary changes .

Given all this, I don’t think there is a lot of risk to Mozilla’s users with no 
benefit if Visa continues to be included in the root program.

Jonathan
___
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