DigiCert-Symantec Announcement

[Jeremy Rowley]

Hi everyone,



Today, DigiCert and Symantec announced that DigiCert is acquiring the
Symantec CA assets, including the infrastructure, personnel, roots, and
platforms. At the same time, DigiCert signed a Sub CA agreement wherein we
will validate and issue all Symantec certs as of Dec 1, 2017. We are
committed to meeting the Mozilla and Google plans in transitioning away from
the Symantec infrastructure. The deal is expected to close near the end of
the year, after which we will be solely responsible for operation of the CA.
>From there, we will migrate customers and systems as necessary to
consolidate platforms and operations while continuing to run all issuance
and validation through DigiCert. We will post updates and plans to the
community as things change and progress.



I wanted to post to the Mozilla dev list to:

1. Inform the public,
2. Get community feedback about the transition and concerns, and
3. Get an update from the browsers on what this means for the plan,
noting that we fully commit to the stated deadlines. We're hoping that any
changes



Two things I can say we plan on doing (following closing) to address
concerns are:

a. We plan to segregate certs by type on each root. Going forward, we
will issue all SSL certs from a root while client and email come from
different roots. We also plan on limiting the number of organizations on
each issuing CA. We hope this will help address the "too big to fail" issue
seen with Symantec. By segregating end entities into roots and sub CAs, the
browsers can add affected Sub CAs to their CRL lists quickly and without
impacting the entire ecosystem. This plan is very much in flux, and we'd
love to hear additional recommendations.
b. Another thing we are doing is adding a validation OID to all of our
certificates that identifies which of the BR methods were used to issue the
cert. This way the entire community can readily identify which method was
used when issuing a cert and take action if a method is deemed weak or
insufficient. We think this is a huge improvement over the existing
landscape, and I'm very excited to see that OID rolled out.



Thanks a ton for any thoughts you offer.



Jeremy

[Kathleen Wilson]

On Wednesday, August 2, 2017 at 2:13:40 PM UTC-7, Jeremy Rowley wrote:
> Today, DigiCert and Symantec announced that DigiCert is acquiring the
> Symantec CA assets, including the infrastructure, personnel, roots, and
> platforms. At the same time, DigiCert signed a Sub CA agreement wherein we
> will validate and issue all Symantec certs as of Dec 1, 2017.

Thanks for posting this information here.

Pointer to DigiCert's blog:

https://www.digicert.com/blog/digicert-to-acquire-symantec-website-security-business/

> Two things I can say we plan on doing (following closing) to address
> concerns are:
>
> a. We plan to segregate certs by type on each root. Going forward, we
> will issue all SSL certs from a root while client and email come from
> different roots.

I would like to see all CAs move in this direction.

> We also plan on limiting the number of organizations on
> each issuing CA. We hope this will help address the "too big to fail" issue
> seen with Symantec. By segregating end entities into roots and sub CAs, the
> browsers can add affected Sub CAs to their CRL lists quickly and without
> impacting the entire ecosystem. This plan is very much in flux, and we'd
> love to hear additional recommendations.

I greatly appreciate your consideration in this area!

Perhaps there can be different subCAs for large organizations versus smaller/individual site operators (that might be covered as different brands). Of course, I'm always in favor of technically-constrained subCAs for the large organizations.

And perhaps one (or more) of the subCAs can be dedicated to short-lived SSL certs, similar to Let's Encrypt?

> b. Another thing we are doing is adding a validation OID to all of our
> certificates that identifies which of the BR methods were used to issue the
> cert. This way the entire community can readily identify which method was
> used when issuing a cert and take action if a method is deemed weak or
> insufficient. We think this is a huge improvement over the existing
> landscape, and I'm very excited to see that OID rolled out.

I would like to see all CAs move in this direction as well.


Looks like you are going to be very busy! :-)

Thanks, and good luck!

Kathleen

[Nick Lamb]

On the use of OIDs to signify the Blessed Method used for validation I thought it can't hurt to mention the first obstacle for this idea which occurred to me in respect of Let's Encrypt (and more generally any CA importing ACME I think)

Suppose an applicant asks for www.example.com, images.example.com and www.example.org. They demonstrate control over www.example.com using files in .well-known/ (sorry I'm writing this on my phone in a hotel room, don't have BR section numbers in front of me) but use DNS to show control over www.example.org...

Which OID goes in this certificate? Both of them? There are arbitrarily more complicated examples along these lines, all worth a bit of thought before setting off I think.

[Jeremy Rowley]

Thanks Kathleen. We already offer short-lived certs (anywhere from 8 hours
up), but they are not issued off a dedicated intermediate. It's a great
suggestion, and we'll add it to the DigiCert plan.

Jeremy

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Kathleen Wilson via dev-security-policy
Sent: Wednesday, August 2, 2017 4:07 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: DigiCert-Symantec Announcement

On Wednesday, August 2, 2017 at 2:13:40 PM UTC-7, Jeremy Rowley wrote:

> Today, DigiCert and Symantec announced that DigiCert is acquiring the
> Symantec CA assets, including the infrastructure, personnel, roots,
> and platforms. At the same time, DigiCert signed a Sub CA agreement
> wherein we will validate and issue all Symantec certs as of Dec 1, 2017.

Thanks for posting this information here.

Pointer to DigiCert's blog:

https://www.digicert.com/blog/digicert-to-acquire-symantec-website-security-
business/

> Two things I can say we plan on doing (following closing) to address
> concerns are:
>
> a. We plan to segregate certs by type on each root. Going forward, we
> will issue all SSL certs from a root while client and email come from
> different roots.

I would like to see all CAs move in this direction.

> We also plan on limiting the number of organizations on each issuing
> CA. We hope this will help address the "too big to fail" issue seen
> with Symantec. By segregating end entities into roots and sub CAs,
> the browsers can add affected Sub CAs to their CRL lists quickly and
> without impacting the entire ecosystem. This plan is very much in
> flux, and we'd love to hear additional recommendations.

I greatly appreciate your consideration in this area!

Perhaps there can be different subCAs for large organizations versus
smaller/individual site operators (that might be covered as different
brands). Of course, I'm always in favor of technically-constrained subCAs
for the large organizations.

And perhaps one (or more) of the subCAs can be dedicated to short-lived SSL
certs, similar to Let's Encrypt?

> b. Another thing we are doing is adding a validation OID to all of our
> certificates that identifies which of the BR methods were used to
> issue the cert. This way the entire community can readily identify
> which method was used when issuing a cert and take action if a method
> is deemed weak or insufficient. We think this is a huge improvement
> over the existing landscape, and I'm very excited to see that OID rolled
out.

I would like to see all CAs move in this direction as well.


Looks like you are going to be very busy! :-)

Thanks, and good luck!

Kathleen

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

[Jeremy Rowley]

Hey Nick - I plan to include all relevant OIDs in the cert. I figured that
way relying parties understand the total risk associated with verification
of the certificate, even if they don't know exactly the methods tied to each
listed domain. If a method is eventually deemed less desirable (*cough*
domain authorization letters *cough*), then the entire cert would need to be
replaced anyway to reflect deprecation of that method.

Jeremy

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Nick Lamb via dev-security-policy
Sent: Wednesday, August 2, 2017 4:57 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: DigiCert-Symantec Announcement

[Peter Bowen]

On Wed, Aug 2, 2017 at 2:12 PM, Jeremy Rowley via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> Today, DigiCert and Symantec announced that DigiCert is acquiring the
> Symantec CA assets, including the infrastructure, personnel, roots, and
> platforms. At the same time, DigiCert signed a Sub CA agreement wherein we

> will validate and issue all Symantec certs as of Dec 1, 2017. We are
> committed to meeting the Mozilla and Google plans in transitioning away from
> the Symantec infrastructure. The deal is expected to close near the end of
> the year, after which we will be solely responsible for operation of the CA.
> From there, we will migrate customers and systems as necessary to
> consolidate platforms and operations while continuing to run all issuance
> and validation through DigiCert. We will post updates and plans to the
> community as things change and progress.
>

> Thanks a ton for any thoughts you offer.

Jeremy,

A while ago I put together a list of all the certificates that are or
were included in trust stores that were known to be owned by Symantec
or companies that Symantec acquired. The list is in Google Sheets at
https://docs.google.com/spreadsheets/d/1piCTtgMz1Uf3SHXoNEFYZKAjKGPJdRDGFuGehdzcvo8/edit?usp=sharing

Can you confirm that DigiCert will be "solely responsible for
operation" of all of these CAs once the deal closes?

Thanks,
Peter

[Peter Kurrasch]

This certainly shakes things up! I've had my concerns that Symantec's plan was complicated and risky, but now I'm wondering if this new path will be somewhat simpler--yet even more risky? I'm not suggesting we shouldn't take this path but I am hoping we make smart, well-thought-out decisions along the way.

Some thoughts:

* Will there be other players in Symantec's SubCA plan or is DigiCert the only one?

* ‎Is DigiCert prepared (yet?) to commit to a "first day of issuance" under the SubCA plan? That is, when is the earliest date that members of the general public may purchase certs that chain up through the new "DigiCert SubCA" to any of the Symantec roots? I hope that, for issues that may arise under the new system, there is sufficient time to identify and resolve them prior to the 2017-12-01 deadline.

* I think the idea of a smart segregation plan for the roots and intermediates is a must-have. Such a plan should factor in the clientele who are using the different roots and the environments in which they operate. Given how important the "ubiquitous roots" are, I would hope to see community involvement and "sign-off", if you will.

* I think it's appropriate to re-think some of the deadlines, given that we're talking less about a carrots-and-sticks model and more of one based on smart decision-making, good risk management, and sticks.

Finally, when I went to read the DigiCert blog post, I noticed that John Merrill's link for the agreement announcement was a dud. I don't know why but I really don't care either. I think it serves as a reminder ‎that mistakes are going to be made during this process so it's best to make allowances for that in the plans going forward. That, and attention to detail is important.

Thanks.

[Jeremy Rowley]

* Will there be other players in Symantec's SubCA plan or is DigiCert the only one?

[DC] Only DigiCert.

* ‎Is DigiCert prepared (yet?) to commit to a "first day of issuance" under the SubCA plan? That is, when is the earliest date that members of the general public may purchase certs that chain up through the new "DigiCert SubCA" to any of the Symantec roots? I hope that, for issues that may arise under the new system, there is sufficient time to identify and resolve them prior to the 2017-12-01 deadline.

[DC] Not yet. That’s an ongoing discussion.

* I think the idea of a smart segregation plan for the roots and intermediates is a must-have. Such a plan should factor in the clientele who are using the different roots and the environments in which they operate. Given how important the "ubiquitous roots" are, I would hope to see community involvement and "sign-off", if you will.

[DC] Okay. We plan to update the community as things solidify.

* I think it's appropriate to re-think some of the deadlines, given that we're talking less about a carrots-and-sticks model and more of one based on smart decision-making, good risk management, and sticks.

[DC] I’ll leave that open to the community discussion, although anything sooner than the current deadlines might not have as satisfactory results as the current proposal.

Finally, when I went to read the DigiCert blog post, I noticed that John Merrill's link for the agreement announcement was a dud. I don't know why but I really don't care either. I think it serves as a reminder ‎that mistakes are going to be made during this process so it's best to make allowances for that in the plans going forward. That, and attention to detail is important.

[DC] Egg on my face there. Thanks for finding that. We’re getting it updated.

[Peter Gutmann]

Jeremy Rowley via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>Today, DigiCert and Symantec announced that DigiCert is acquiring the
>Symantec CA assets, including the infrastructure, personnel, roots, and
>platforms.

I realise this is a bit off-topic for the list but someone has to bring up the
elephant in the room: How does this affect the Google vs. Symantec situation?
Is it pure coincidence that Symantec now re-emerges as DigiCert, presumably
avoiding the sanctions since now things will chain up to DigiCert roots?

Just curious here, this seems like a bit too much of a coincidence.

Peter.

[Peter Bowen]

On Wed, Aug 2, 2017 at 8:10 PM, Peter Gutmann via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> Jeremy Rowley via dev-security-policy <dev-secur...@lists.mozilla.org> writes:
>
>>Today, DigiCert and Symantec announced that DigiCert is acquiring the
>>Symantec CA assets, including the infrastructure, personnel, roots, and
>>platforms.
>
> I realise this is a bit off-topic for the list but someone has to bring up the
> elephant in the room: How does this affect the Google vs. Symantec situation?
> Is it pure coincidence that Symantec now re-emerges as DigiCert, presumably
> avoiding the sanctions since now things will chain up to DigiCert roots?

Peter,

On topic for this list is Mozilla policy. Gerv's email was clear that
sale to DigiCert will not impact the plan, saying: "any change of
control of some or all of Symantec's roots
would not be grounds for a renegotiation of these dates."

So the sanctions are still intact.

Thanks,
Peter

[Peter Gutmann]

Peter Bowen <pzb...@gmail.com> writes:

>Gerv's email was clear that sale to DigiCert will not impact the plan,
>saying: "any change of control of some or all of Symantec's roots would not
>be grounds for a renegotiation of these dates."
>
>So the sanctions are still intact.

Ah, I phrased my question a bit unclearly, what I meant was that the existing
certs, which now chain up to to-be-untrusted Symantec roots, can be moved
across to trusted DigiCert roots and continue as before. I'm assuming that
was the intent of exercise, that it's business as usual, just the name has
changed.

Peter.

[Alex Gaynor]

Hi Jeremy,

Will the certificates being issued for Symantec starting December 1st be
issued under the existing DC roots, or under new roots?

Alex

On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Hi everyone,

>
>
>
> Today, DigiCert and Symantec announced that DigiCert is acquiring the
> Symantec CA assets, including the infrastructure, personnel, roots, and

> platforms. At the same time, DigiCert signed a Sub CA agreement wherein we
> will validate and issue all Symantec certs as of Dec 1, 2017. We are
> committed to meeting the Mozilla and Google plans in transitioning away
> from
> the Symantec infrastructure. The deal is expected to close near the end of
> the year, after which we will be solely responsible for operation of the
> CA.
> From there, we will migrate customers and systems as necessary to
> consolidate platforms and operations while continuing to run all issuance
> and validation through DigiCert. We will post updates and plans to the
> community as things change and progress.
>
>
>

> I wanted to post to the Mozilla dev list to:
>
> 1. Inform the public,
> 2. Get community feedback about the transition and concerns, and
> 3. Get an update from the browsers on what this means for the plan,
> noting that we fully commit to the stated deadlines. We're hoping that any
> changes
>
>
>

> Two things I can say we plan on doing (following closing) to address
> concerns are:
>
> a. We plan to segregate certs by type on each root. Going forward, we
> will issue all SSL certs from a root while client and email come from

> different roots. We also plan on limiting the number of organizations on

> each issuing CA. We hope this will help address the "too big to fail"
> issue
> seen with Symantec. By segregating end entities into roots and sub CAs,
> the
> browsers can add affected Sub CAs to their CRL lists quickly and without
> impacting the entire ecosystem. This plan is very much in flux, and we'd
> love to hear additional recommendations.

> b. Another thing we are doing is adding a validation OID to all of our
> certificates that identifies which of the BR methods were used to issue the
> cert. This way the entire community can readily identify which method was
> used when issuing a cert and take action if a method is deemed weak or
> insufficient. We think this is a huge improvement over the existing
> landscape, and I'm very excited to see that OID rolled out.
>
>
>

> Thanks a ton for any thoughts you offer.
>
>
>
> Jeremy
>
>

[Santhan Raj]

Hi Jeremy,

A similar question regarding Symantec's CT log infrastructure. Are they part of the deal and do you plan to continue hosting them?

Thanks,
Santhan

[Doug Beattie]

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-

> bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of
> Jeremy Rowley via dev-security-policy
> Sent: Wednesday, August 2, 2017 10:54 PM
> To: Peter Kurrasch <fhw...@gmail.com>; mozilla-dev-security-policy
> <mozilla-dev-s...@lists.mozilla.org>
> Subject: RE: DigiCert-Symantec Announcement
> * Will there be other players in Symantec's SubCA plan or is DigiCert the only
> one?
>
>
>
> [DC] Only DigiCert.

Jeremy - It's my understanding that as of December 1st every certificate issued by Symantec or a Managed CA must have the domains validated by the Managed CA (in this case only DigiCert). Is it feasible that DigiCert revalidate every domain in use by Symantec Enterprise customs between now and then, and to keep up with all reissues/renewals and new Retail and Partner orders? It seems like a huge challenge, especially given that you are not able to use Symantec employees or systems for this. Maybe my assumptions are not accurate.

[Jeremy Rowley]

I believe all of the non expired CAs listed are in scope.

[Jakob Bohm]

On 02/08/2017 23:12, Jeremy Rowley wrote:
> Hi everyone,
>
>
>
> Today, DigiCert and Symantec announced that DigiCert is acquiring the
> Symantec CA assets, including the infrastructure, personnel, roots, and
> platforms. At the same time, DigiCert signed a Sub CA agreement wherein we
> will validate and issue all Symantec certs as of Dec 1, 2017. We are
> committed to meeting the Mozilla and Google plans in transitioning away from
> the Symantec infrastructure. The deal is expected to close near the end of
> the year, after which we will be solely responsible for operation of the CA.
>>From there, we will migrate customers and systems as necessary to
> consolidate platforms and operations while continuing to run all issuance
> and validation through DigiCert. We will post updates and plans to the
> community as things change and progress.
>
>

Wasn't the whole outsourced SubCA plan predicated on the outsourcing
being done to someone else. But with this, DigiCert (as successor to
Symantec) would be outsourcing to itself?

>
> I wanted to post to the Mozilla dev list to:
>
> 1. Inform the public,
> 2. Get community feedback about the transition and concerns, and
> 3. Get an update from the browsers on what this means for the plan,
> noting that we fully commit to the stated deadlines. We're hoping that any
> changes
>
>
>
> Two things I can say we plan on doing (following closing) to address
> concerns are:
>
> a. We plan to segregate certs by type on each root. Going forward, we
> will issue all SSL certs from a root while client and email come from
> different roots. We also plan on limiting the number of organizations on
> each issuing CA. We hope this will help address the "too big to fail" issue
> seen with Symantec. By segregating end entities into roots and sub CAs, the
> browsers can add affected Sub CAs to their CRL lists quickly and without
> impacting the entire ecosystem. This plan is very much in flux, and we'd
> love to hear additional recommendations.
> b. Another thing we are doing is adding a validation OID to all of our
> certificates that identifies which of the BR methods were used to issue the
> cert. This way the entire community can readily identify which method was
> used when issuing a cert and take action if a method is deemed weak or
> insufficient. We think this is a huge improvement over the existing
> landscape, and I'm very excited to see that OID rolled out.
>

If you take over the roots, why continue to keep separate roots for the
former Symantec brands (except as an "old hierarchy used mostly for
their own CRLs and historic relying parties such as certain Microsoft
products")?


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Jeremy Rowley]

Hi Doug,

We are confident in our ability to hit the deadlines set by both Mozilla and
Google. Our understanding is that all new validations will be done by DigiCert
on Dec 1, 2017. We plan to start re-validating information as soon as
practical under the Sub CA agreement. Our mutual goal is to avoid Symantec
validation data reuse, avoiding the shorter validity periods required by
Google. Both companies believe this will provide the best customer experience
and give customers the service they are used to.

Jeremy

[Jeremy Rowley]

We aren't sure at this point. DigiCert already runs two (almost three) logs.
Symantec runs two logs. Although CT plans are still under discussion, I
don't think the ecosystem needs four CT logs operated by a single CA.
Regardless, we'll do whatever is best to support CT and the DigiCert and
Symantec customer-base. Likely, we'll compare infrastructure and keep the
best performing logs. We'll definitely run a differential between the logs
and consult with the community before anything is done with existing logs.

Jeremy

-----Original Message-----
From: dev-security-policy

[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Santhan Raj via dev-security-policy
Sent: Thursday, August 3, 2017 1:36 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: DigiCert-Symantec Announcement

On Wednesday, August 2, 2017 at 6:44:51 PM UTC-7, Peter Bowen wrote:

Hi Jeremy,

A similar question regarding Symantec's CT log infrastructure. Are they part
of the deal and do you plan to continue hosting them?

Thanks,
Santhan

[Jeremy Rowley]

Hey Peter,



I think the Mozilla and Google plans both stand as-is, although probably need an updated based on this announcement. I'm hoping that the high-level concepts remain unchanged:

- Migrate to a new infrastructure

- Audit the migration and performance to ensure compliance

- Improve operational transparency so the community has assurances on what is happening.



Jeremy

From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Peter Kurrasch via dev-security-policy
Sent: Wednesday, August 2, 2017 8:01 PM
To: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: DigiCert-Symantec Announcement

This certainly shakes things up! I've had my concerns that Symantec's plan was complicated and risky, but now I'm wondering if this new path will be somewhat simpler--yet even more risky? I'm not suggesting we shouldn't take this path but I am hoping we make smart, well-thought-out decisions along the way.



Some thoughts:

* Will there be other players in Symantec's SubCA plan or is DigiCert the only one?

* ‎Is DigiCert prepared (yet?) to commit to a "first day of issuance" under the SubCA plan? That is, when is the earliest date that members of the general public may purchase certs that chain up through the new "DigiCert SubCA" to any of the Symantec roots? I hope that, for issues that may arise under the new system, there is sufficient time to identify and resolve them prior to the 2017-12-01 deadline.

* I think the idea of a smart segregation plan for the roots and intermediates is a must-have. Such a plan should factor in the clientele who are using the different roots and the environments in which they operate. Given how important the "ubiquitous roots" are, I would hope to see community involvement and "sign-off", if you will.

* I think it's appropriate to re-think some of the deadlines, given that we're talking less about a carrots-and-sticks model and more of one based on smart decision-making, good risk management, and sticks.

Finally, when I went to read the DigiCert blog post, I noticed that John Merrill's link for the agreement announcement was a dud. I don't know why but I really don't care either. I think it serves as a reminder ‎that mistakes are going to be made during this process so it's best to make allowances for that in the plans going forward. That, and attention to detail is important.

Thanks.

[Peter Kurrasch]

I agree with the high-level concepts, although I would probably like to add something about "being good stewards of technologies that play a critical role in the global economy." (Feel free to use your own words!)

Regarding the current Mozilla/Google plans, I don't necessarily have a problem with them but I do think we should give ourselves permission to make adjustments (if needed) because the circumstances have changed since those plans were developed. Consider:

* Because the acquisition is now in the picture, legal issues might impede progress in certain areas. The most notable example is the fact that DigiCert will have limited authority over Symantec until the deal actually closes. For example, what will happen in the period between Dec 1 and the closing (assuming it's after the first)?

* Once the deal does close, personnel and management issues could present various challenges in meeting certain deadlines. For example, if subject matter experts decide to leave Symantec prior to the closing, how might that hinder DigiCert?

* A lot of churn is about to be introduced in the global PKI. Times of chaos create moments of opportunity for those who wish to do bad things. Should something happen, corrections may be necessary which can impact delivery dates, and so on.

Let me be clear that these are just hypothetical situations and rhetorical questions. I don't expect answers and my only intention is to get people to start thinking about these matters (if they haven't already begun).

Hopefully this better explains where I was coming from in my initial reply.

From: Jeremy Rowley Sent: Thursday, August 3, 2017 8:13 PM‎

Hey Peter,

    

 I think the Mozilla and Google plans both stand as-is, although probably need an updated based on this announcement.  I'm hoping that the high-level concepts remain unchanged:

    - Migrate to a new infrastructure

    - Audit the migration and performance to ensure compliance

    - Improve operational transparency so the community has assurances on what is happening.

        

 Jeremy

 

 

This certainly shakes things up! I've had my concerns that Symantec's plan was complicated and risky, but now I'm wondering if this new path will be somewhat simpler--yet even more risky? I'm not suggesting we shouldn't take this path but I am hoping we make smart, well-thought-out decisions along the way.

...snip...

[Jeremy Rowley]

Hi everyone,



We’re still progressing towards close and transition. One of the items we are heavily evaluating is the root structure and cross-signings post close. Although the plan is still being finalized, I wanted to provide a community update on the current proposal.



Right now, Mozilla post stated that they plan to deprecate Symantec roots for TLS by the end of 2018. We continue to work on a plan to transition all customers using the roots for TLS to another root, likely the DigiCert High Assurance root. We will not cross-sign any Symantec roots, however we will continue using those roots for code signing and client/email certs post close (non-TLS use cases). We also plan on using Symantec roots to cross-sign some of the DigiCert roots to provide ubiquity in non-Mozilla systems and processes. However, this sign will only provide one-way trust, with the ultimate chain in Mozilla being EE-> Issuing CA -> DigiCert root in all cases.



DigiCert currently has four operational roots in the Mozilla trust store: Baltimore, Global, Assured ID, and High Assurance. The other roots are some permutation of these four roots that were established for future use cases/rollover (ECC vs. RSA). We already separate operations by Sub CA, with TLS, email, and code signing using different issuing CAs. As mentioned in my previous post, we plan on using multiple Sub CAs chained to the DigiCert roots to further control the population trusted by each Sub CA but have not decided on exact numbers. OV and EV will be limited by Alexa distribution and/or number of customers. DV isn’t readily identifiable by customer and will use a common sub CA.



Root separation proves a difficult, yet achievable, task as there are only four operational roots: Baltimore, High Assurance, Global, and Assured ID. Global and High Assurance issue mostly OV/EV certs but do include code signing and client certificates. High Assurance is our EV root and used for both EV code signing certificates and TLS certs. Baltimore is our cross-signed root and used primarily by older Verizon customers. Assured ID is used mostly for code signing and client. However, Assured ID is also our FBCA root, meaning government-issued TLS certificates chain to it. Of course, all TLS certs are issued in accordance with the BRs regardless of root.



Looking at the current customer base, our current plan is to issue EV (code and TLS) from High Assurance, OV (code and TLS) from Global. Assured ID will continue as our client certificate and government root. We plan to continue using Symantec roots for code signing and client. We’re still looking into this though. We’d love to separate out the roots more than this, but that’s not likely possible given the current root architecture. If there is a non-cross-signed Symantec root that the browsers are not planning to remove, we’d like to continue using the root to issue high volume DV and device certificates. If this is not possible and Mozilla is still planning on distrusting all Symantec roots, we’ll likely migrate DV certs to a Sub CA chained to the Baltimore root.



Of course, this is only an initial proposal. We’ll revise as things progress and based on the community feedback. We appreciate your thoughts.



Jeremy

From: Peter Kurrasch [mailto:fhw...@gmail.com]
Sent: Thursday, August 3, 2017 11:21 PM
To: Jeremy Rowley <jeremy...@digicert.com>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: DigiCert-Symantec Announcement

[Adrian R.]

a small question:
what's going to happen with https://www.freessl.com/ ?

under Symantec's leadership it was intended for the site to become a free alternative to StartCom and LetsEncrypt, but it was not quite opened for issuance except for non-profits.

Now with the transition of the CA activities to DigiCert i haven't seen anything about it, not even the site blog over there says anything about it. https://www.freessl.com/freessl/blog/

Any news about it?

Thanks,
~~~~

[Steve Medin]

We are not making any changes at this time.

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-

> bounces+steve_medin=symant...@lists.mozilla.org] On Behalf Of
> Adrian R. via dev-security-policy
> Sent: Friday, September 01, 2017 4:09 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: [EXT] Re: DigiCert-Symantec Announcement
>
> a small question:

> what's going to happen with [freessl.com]

>
> under Symantec's leadership it was intended for the site to become a free
> alternative to StartCom and LetsEncrypt, but it was not quite opened for
> issuance except for non-profits.
>
> Now with the transition of the CA activities to DigiCert i haven't seen
> anything about it, not even the site blog over there says anything about it.
> https://www.freessl.com/freessl/blog/
>
> Any news about it?
>
> Thanks,
> ~~~~

[Peter Kurrasch]

I think the plan at the root level makes sense and is reasonable, at least as far as I think I understand it. (A diagram would be nice.)‎ At the intermediate level, however, I think more detail is needed. I'm especially interested in learning how resilient the cert hierarchy will be should it become necessary to alter the hierarchy in response to an adversarial act or management mishap or PKI community sanction or perhaps even future standards work.

I also wonder about the plan to allocate the "economically critical" customer base across the various intermediates. For example, should soda companies, banks, shipping companies, and media sites all be given the same consideration? What about main web sites vs static content servers (CDNs)? What about sites that are important to the economy but aren't necessarily the most popular?

‎My hope is that there will be enough fault tolerance, redundancy, resiliency--call it whatever you like--built in to the system so that we know we have options available should we need them. The extent to which DigiCert can flesh out some of these details will be of benefit to the whole community.

[Ryan Sleevi]

On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Hi everyone,

>
>
>
> Today, DigiCert and Symantec announced that DigiCert is acquiring the
> Symantec CA assets, including the infrastructure, personnel, roots, and
> platforms. At the same time, DigiCert signed a Sub CA agreement wherein we
> will validate and issue all Symantec certs as of Dec 1, 2017. We are
> committed to meeting the Mozilla and Google plans in transitioning away
> from
> the Symantec infrastructure. The deal is expected to close near the end of
> the year, after which we will be solely responsible for operation of the
> CA.
> From there, we will migrate customers and systems as necessary to
> consolidate platforms and operations while continuing to run all issuance
> and validation through DigiCert. We will post updates and plans to the
> community as things change and progress.
>
>
>

> I wanted to post to the Mozilla dev list to:
>
> 1. Inform the public,
> 2. Get community feedback about the transition and concerns, and
> 3. Get an update from the browsers on what this means for the plan,
> noting that we fully commit to the stated deadlines. We're hoping that any
> changes
>
>
>
> Two things I can say we plan on doing (following closing) to address
> concerns are:
>
> a. We plan to segregate certs by type on each root. Going forward, we
> will issue all SSL certs from a root while client and email come from
> different roots. We also plan on limiting the number of organizations on
> each issuing CA. We hope this will help address the "too big to fail"
> issue
> seen with Symantec. By segregating end entities into roots and sub CAs,
> the
> browsers can add affected Sub CAs to their CRL lists quickly and without
> impacting the entire ecosystem. This plan is very much in flux, and we'd
> love to hear additional recommendations.
> b. Another thing we are doing is adding a validation OID to all of our
> certificates that identifies which of the BR methods were used to issue the
> cert. This way the entire community can readily identify which method was
> used when issuing a cert and take action if a method is deemed weak or
> insufficient. We think this is a huge improvement over the existing
> landscape, and I'm very excited to see that OID rolled out.
>
>
>

> Thanks a ton for any thoughts you offer.
>
>
>
> Jeremy
>

eremy,

Thanks for sharing details about your rough plans. There’s a lot at play
here, particularly when trying to fully visualize DigiCert’s existing and
proposed hierarchy, so I’m wondering if it might be easier to explore what
the ‘ideal PKI’ may look like, and then try to work backwards to figure out
how this acquisition can help that.

At the core, we can imagine there is a root CA for each major long-term
cryptographic configuration - which, in today’s world, generally means
RSA/2048, RSA/4096, ECC/256, and ECC/384. In tomorrow’s world, this may
also accommodate additional curves Ed25519 and Ed448, such as via
https://tools.ietf.org/id/draft-ietf-curdle-pkix . In total, this means the
ideal PKI only needs four to six root certificates.

Within each root, you can build out the appropriate segmentation. For
performance reasons, it’s likely preferable to have a ‘wide’ PKI (many
sub-CAs off the root, each constrained in capability and used for a limited
amount of time) versus a ‘deep’ PKI (hierarchically reducing the
capabilities at each level in the trust graph- for example, “All TLS” ->
“All DV” -> “All first party DV” -> “All first party DV in Q12017”), even
if a deep PKI can provide better compartmentalization for some use cases.

It isn’t clear that compartmentalizing on root provides any obvious
benefits to users, especially as it’s the same infrastructure and audits,
but it does seem that it increases the management overhead (for root
stores), the configuration challenges (for site operators), not to mention
the management (and, occasionally, network & memory) challenges for users
to support all of those roots.

It would be ideal to see DigiCert streamline its PKI to better align with
that vision, and to understand what challenges might prevent that. For
example, is there a path to transition all new DigiCert issuance to a
single root? If it can’t be done for all certs, can it be done for TLS?
Understanding if there are challenges to that goal can provide invaluable
insight into how the Managed CA transition can look.

A significant reason for the Managed CA plan was to provide a temporary
bridge for those TLS servers who had made risky and fragile technical
decisions - such as pinning to a single CA or only supporting a single CA
on a device - while minimizing the risk to the broader TLS ecosystem. As
Symantec, like other organizations wishing to operate a trusted CA, would
be permitted to apply to have new roots (and a new infrastructure)
included, once it had met the minimum required security standards, the
Managed CA only needed to serve as a transition point until either Symantec
had implemented new infrastructure or the community had migrated away.

Conceptually, this bridge concept is somewhat similar to how SHA-1 was
handled. In the lead-up to SHA-1’s deprecation, CAs self-removed a number
of roots, on the basis that they planned these legacy roots to be used for
SHA-1 issuance, and thus no longer be BR audited. Customers, both existing
and new, were given SHA-256 certificates by default, but, should there be a
demonstrated technical need for the legacy solution, a SHA-1 certificate
could be provided that would work with older devices.

The main difference between that SHA-1 transition and the proposal here is
that the community recognizes that an immediate migration away from
Symantec’s old infrastructure could present challenges, and thus a path was
provided that allowed a limited degree of public trust for those
compatibility certificates, with the assumption and expectation that it
would be an interim solution towards either an eventual reapplication for
trust or an ultimate sunset of this managed infrastructure.

How does this all practically play out? One way to effectively manage this
as follows: Identify the existing Symantec hierarchy, mapping out every
logical CA (same name and key) and all the permutations of certificates for
those names and keys - including cross-signs. Graphing this out is strongly
recommended, given the sheer amount of information here. From there, look
to identify what paths are currently, actively issuing TLS certificates
that are trusted in the Web PKI - I suspect this will be a much smaller
subset, based on Symantec’s past public disclosures. Some of these paths
may transition multiple roots; such as having an older root sign a newer
root sign the active intermediate. For each of the ‘newest’ roots,
establish a new DigiCert-managed private key and issuance infrastructure on
DigiCert’s existing infrastructure, name it in a way that ideally clearly
identifies it, and cross-sign it with that ‘newer’ Symantec root. This
serves as the Managed CA “root”, and in a way that provides the greatest
similarity to Symantec’s existing issuance practices.

Once you have that ‘emergency Managed CA’ infrastructure in place, work to
migrate all existing Symantec customers to DigiCert issuance as quickly as
possible. I know you suggested your goal was 2018, but one way you may be
able to do this quicker is, for every existing Symantec customer, as a new
certificate request comes in, issue them a DigiCert-chaining certificate.
If they identify a compatibility issue - such as a client that only
supports certain Symantec certificates - issue them a certificate off the
Managed CA infrastructure - much like CAs handled the SHA-1/SHA-256
transition in the lead-up to the SHA-1 sunset. This reduces the use of the
Managed CA infrastructure to just those who absolutely need it, and in a
way that helps DigiCert identify the concrete challenges customers may
face, which can facilitate community discussion on how to solve these
challenges. I would further encourage the limiting the validity period of
these Managed CA certificates to something 13 months or less, to help
ensure that this bridge doesn’t become a crutch, and seems to align with
your stated goal of helping these customers move to an existing DigiCert
root by 2018.

On the Root Program side, this helps greatly simplify the transition
overhead and compatibility risk. If a Root Program takes no action, new
(DigiCert-issued) certificates from the Managed CA infrastructure continue
to work as-is, because they chain to the old Symantec roots. For Root
Programs that are taking steps to reduce trust in Symantec certificates,
they can whitelist those intermediates you identify from such reductions of
trust - by adding the new Managed CA certificates as ‘new’ roots or by
action in code. When steps are taken to fully remove the Symantec
infrastructure (in 2018, as proposed), Root Programs can fully remove the
legacy Symantec roots, and all of the certificates it has issued previously
- while the new certificates issued under the Managed CAs will continue to
work, as the Managed CAs were added as roots (or whitelisted from distrust).

This plan helps transition from “legacy Symantec” to “new DigiCert”, which
reduces the immediate risks to the ecosystem. Unfortunately, this has the
side-effect that it means that DigiCert will now be operating a significant
number of roots - the existing DigiCert roots, the ones it acquired from
Verizon, the new “Symantec” roots (for those that did the
swap-and-replace), and/or the old Symantec roots (for those that did not).
This is not a problem unique to DigiCert - it arises in any form of CA
acquisition or merger, such as Entrust/TrendMicro or WoSign/StartCom - but
is truly special in the sheer number of combined-entity roots that will
exist. Thus, it’s also incredibly useful if, in parallel, DigiCert can look
for ways to harmonize and streamline that PKI towards that longer-goal of
having just four to six roots - one for each cryptographic algorithm.

In thinking about what actions may present compatibility issues - either to
existing certificates or to new ones - I would suggest that signing any
existing DigiCert root or subordinate CAs, or anything other than these few
identified Managed CAs, with the legacy Symantec certificates, would likely
be a recipe for interoperability issues for TLS clients. I’m not saying
it’s expressly forbidden - just that, if done with existing roots, it may
cause those current roots and everything they’ve signed to be rejected.
This would happen for applications which don’t support the notion of trust
anchors (e.g. when the intermediate in the chain presented is the same as a
trusted root, which includes legacy OpenSSL-based products in addition to a
number of macOS and iOS versions) to those that impose policies based on
the root (whether EV recognition or, as a result of past misissuances,
policies that limit trust in Symantec-issued certificates). Avoiding that
for, at a minimum, TLS, is the best success strategy I can recommend,
although I would honestly recommend avoiding that across the board, given
the client issues I’ve seen over the years.

If there are challenges with this outline, it might be useful to diagram a
bit of the existing Symantec and DigiCert infrastructure - both by logical
CA (same name and key) and the actual certificates - so that we can easily
visualize and discuss what paths may be impacted by DigiCert’s proposed
plan or those plans of Root Programs. This would allow easier collaboration
on how best to achieve that integration with minimal risk to the ecosystem
or to DigiCert or Symantec customers, which is a goal I’m certain we all
share.

[Jeremy Rowley]

Hey Ryan – Thanks a ton for this post. I’m working on a reply and should have something next week, but I wanted to acknowledge that we saw the post and are working on providing the information requested.



Jeremy

From: Ryan Sleevi [mailto:ry...@sleevi.com]
Sent: Thursday, September 14, 2017 1:28 PM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: DigiCert-Symantec Announcement

[Jeremy Rowley]

Thanks a ton, Ryan! This was very helpful, and we really appreciate the feedback and suggestions. Here’s what we currently use as publicly-trusted roots and how we use them:



1. Baltimore CyberTrust Root – Expires in 2025. Currently only used to support Verizon customers who have not transitioned to DigiCert’s roots for whatever reason (SubCAs, Pinned keys, etc)
2. CyberTrust Global Root – Expires in 2021 (I think) and used primarily in Japan. This is our EV root for customers who need trust in Japanese systems.
3. DigiCert Assured ID Root CA – RSA root that issues primarily client certs and code signing certificates. The root is trusted in Adobe and cross-signed by the FBCA (one-way trust). Although it issues some TLS certs, these TLS are only issued when a special cross-certification is required that is no available under the other roots.
4. DigiCert Assured ID Root G2 – RSA rollover root for the Assured ID root. Once sufficient ubiquity exists, the plan is to retire the Assured ID Root in favor of this one.
5. DigiCert Assured ID Root G3 – ECC version of the G2 root. This root is for entities who want a complete ECC chain.
6. DigiCert Global Root CA – RSA root that is used for OV and code signing certificates. This is our primary issuing root and is cross-signed by Baltimore for additional ubiquity.
7. DigiCert Global Root G2 – RSA rollover root intended to replace the Global Root CA.
8. DigiCert Global Root G3 – ECC version of the G2 root used to support entities who want a complete ECC chain
9. DigiCert High Assurance EV Root CA – Our only EV root until this bug is complete: https://bugzilla.mozilla.org/show_bug.cgi?id=1165472. This root is primarily used for entities who want one or more EV certificates and is cross-signed by the Baltimore root for ubiquity.
10. DigiCert Trusted Root CA – A 4096 bit root in case 2048 is no longer sufficient. This is cross-signed by the Global Root.



Symantec has the following roots according to CCADB. Symantec would have to comment on how these are used.

1. Symantec Class 1 G4
2. Symantec Class 1 G6
3. Symantec Class 2 G4
4. Symantec Class 2 G6
5. Symantec Class 3 G4
6. Symantec Class G6
7. Symantec Enterprises Mobile
8. Equifax Secure Certificate Authority
9. Equifax Secure eBusiness CA-1
10. Equifax Secure Global eBusiness CA-1
11. GeoTrust Global CA
12. GeoTrust Global CA 2
13. GeoTrust Primary Certificate Authority
14. GeoTrust Primary Certificate Authority – G2
15. GeoTrust Primary Certificate Authority – G3
16. GeoTrust Universal CA
17. GeoTrust Universal CA 2
18. Thawte Premium Server CA
19. Thawte Primary Root CA
20. Thawte Primary Root CA – G2
21. Thawte Primary Root CA – G3
22. Thawte Server CA
23. Thawte Timestamping CA
24. UTN-Userfirst-Network Applications
25. Verisign Class 1 Public PCA
26. Verisign Class 3 Public Primary Certificate Authority – G4
27. Verisign Class 3 Public Primary Certificate Authority – G5
28. Verisign Class 4 Public Primary Certificate Authority – G3
29. Verisign Time Stamping CA
30. Verisign Universal Root Certificate Authority
31. Verisign4
32. Verisign Class 1 Public PCA – G3
33. Verisign Class 1 Public PCA – G2
34. Verisign Class 2 Public PCA – G3
35. Verisign Class 2 Public PCA – G2
36. Verisign Class 3 Public PCA
37. Verisign Class 3 Public PCA – MD2
38. Verisign Class 3 Public PCA – G2
39. Verisign Class 2 Public Primary Certification Authority – G3



The current end-state plan for root cross-signing is provided at https://bugzilla.mozilla.org/show_bug.cgi?id=1401384. The diagrams there show all of the existing sub CAs along with the new Sub CAs and root signings planned for post-close. Some of these don’t have names so they are lumped in a general “Intermediate” box.



We reached the same conclusion as you about segmentation by root (that compartmentalization by root won’t work), not to mention that compartmentalization will be near impossible considering what we’ve previously issued and how the roots are trusted in various root programs. Instead, we plan on creating sub CAs based on the number of entities using the intermediate. For example, every 2000 or so entities will use another Sub CA. This will roughly segment customers based on excepted volumes. We also plan on providing a lot more unique intermediates on a per customer basis. Permitting large companies to have a dedicated intermediate will help shield them from being revoked if another Sub CA needs to be revoked and allow browsers to selectively whitelist/blacklist entities. Of course, not every company will want this, but it’ll be available for anyone who wants it.



The plan, based on your suggestions, is to cross-sign the DigiCert Global G2 root with the four Symantec roots:



1. GeoTrust Global CA
2. GeoTrust Global CA 2
3. Verisign Class 3 Public Primary Certificate Authority – G5
4. Thawte Primary Root CA



The exact roots cross-signing the DigiCert root is very much in flux. Until close, we aren’t reaching out to current Symantec customers for, I think, obvious reasons. However, we do plan on communicating with these customers immediately post close to determine which roots are pinned in applications and what roots are required for custom applications. We are trying to limit the number of primary roots to six (three ECC, three RSA) plus one transition root to keep the chains and use manageable.



The Global G2 root will become the transition root to DigiCert for customers who can’t move fully to an operational DigiCert roots prior to September 2018. Any customers that require a specific root can use the transition root for as long as they want, realizing that path validation may be an issue as Symantec roots are removed by platform operators. Although we cannot currently move to a single root because of the lack of EV support and trust in non-Mozilla platforms, we can move to the existing three roots in an orderly fashion.



If the agreement closes prior to Dec 1, the Managed CA will never exist. Instead, all issuance will occur through one of the three primary DigiCert roots mentioned above with the exception of customers required to use a Symantec root for certain platforms or pinning. The cross-signed Global root will be only transitory, meaning we’d hope customers would migrate to the DigiCert roots once the systems requiring a specific Symantec roots are deprecated or as path validation errors arise.

[James Burton]

Hi Jeremy,

Is DigiCert planning on continuing selling DV certificates after the transition? As DigiCert has previously been vocal on the fact that the drawbacks of issuing DV certificates outweigh the benefits as stated here: https://www.digicert.com/dv-ssl-certificate.htm. If DigiCert is going to issue DV certificates which root or roots are you going to dedicated for the certificates?

James

[Jeremy Rowley]

Post-close, all products and offerings will stay the same as pre-close
except that DigiCert will do the validation and issuance. This does mean
DigiCert is offering a DV product post close. We agreed with Ryan that
separation by root for DV, OV, and EV doesn't make much sense, meaning all
TSL certs will issue from the generally the same roots. Right now, the
Global Trust CA root will be our primary root for issuing TLS certs, but the
High Assurance root will remain dedicated to OV and EV certs.

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla

.org] On Behalf Of James Burton via dev-security-policy
Sent: Wednesday, September 20, 2017 4:33 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: DigiCert-Symantec Announcement

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

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

[Peter Bowen]

On Tue, Sep 19, 2017 at 8:39 PM, Jeremy Rowley via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
>
> The current end-state plan for root cross-signing is provided at https://bugzilla.mozilla.org/show_bug.cgi?id=1401384. The diagrams there show all of the existing sub CAs along with the new Sub CAs and root signings planned for post-close. Some of these don’t have names so they are lumped in a general “Intermediate” box.
>

> The Global G2 root will become the transition root to DigiCert for customers who can’t move fully to an operational DigiCert roots prior to September 2018. Any customers that require a specific root can use the transition root for as long as they want, realizing that path validation may be an issue as Symantec roots are removed by platform operators. Although we cannot currently move to a single root because of the lack of EV support and trust in non-Mozilla platforms, we can move to the existing three roots in an orderly fashion.
>
> If the agreement closes prior to Dec 1, the Managed CA will never exist. Instead, all issuance will occur through one of the three primary DigiCert roots mentioned above with the exception of customers required to use a Symantec root for certain platforms or pinning. The cross-signed Global root will be only transitory, meaning we’d hope customers would migrate to the DigiCert roots once the systems requiring a specific Symantec roots are deprecated or as path validation errors arise.

Jeremy,

Am I correct that a key input into this plan was the Mozilla plan to
fully remove the Symantec roots from the trust store before then end
of 2018? Google seemed to suggest they would keep trusting them for a
longer period with a restriction on which subordinate CAs are trusted.

Thanks,
Peter

[Jeremy Rowley]

The original Mozilla plan was to distrust around Sep 2018. We're still planning for that date, but would appreciate it if trust was permitted around a single intermediate (say the DigiCert Global Trust G2 root?). If we need to use a separate root with no other certs as the transition, we could create one. I know my team would prefer it as the Global Trust G2 root is our primary SHA2 root.

-----Original Message-----
From: Peter Bowen [mailto:pzb...@gmail.com]
Sent: Wednesday, September 20, 2017 10:21 AM
To: Jeremy Rowley <jeremy...@digicert.com>

Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: DigiCert-Symantec Announcement

[Ryan Sleevi]

Jeremy,

Thanks for attaching the diagrams - this is very useful in helping
visualize out the graph! Special thanks for detailing out the validation
flow DigiCert both practices and plans to practice - this level of
transparency goes a long way to helping assess and understand both risks
and mitigations.

I think we can divide the discussion into two parts, similar to the
previous mail: How to effectively transition Symantec customers with
minimum disruption, whether acting as the Managed CA or as the future
operator of Symantec’s PKI, and how to effectively transition DigiCert’s
infrastructure. This is a slightly different order than your e-mail
message, but given the time sensitivity of the Symantec transition, it
seems more effective to discuss that first.

I think there may have been some confusion on the Managed CA side. It’s
excellent that DigiCert plans to transition Symantec customers to DigiCert
roots, as that helps with an expedient reduction in risk, but the plan
outlined may create some of the compatibility risks that I was trying to
highlight. In the discussions of the proposed remediations, one of the big
concerns we heard raised by both Symantec and site operators was related to
pinning - both in the Web and in mobile applications. We also heard about
embedded or legacy devices, and their needs for particular chains.

The plan you’ve outlined doesn’t seem to clearly account for this, which
was a key factor in the “Managed CA” design. In the previous reply, I tried
to highlight a bit more of at least one technically viable way to
accomplish that - what we might call the “Managed CA Lookalike”
infrastructure, in that it follows the structural outline and requirements
of the Managed CA plan, even if DigiCert may be performing all the
validation themselves and not relying on any previous data or documents
(which I assume is what you mean by “Transitioned to DigiCert”).

To make sure we’re on the same page, when you say “DigiCert Global Root
G2”, you mean the certificate at
https://crt.sh/?q=DF3C24F9BFD666761B268073FE06D1CC8D4F82A4, right? This CA,
in turn, has signed “DigiCert Global CA G2”, https://crt.sh/?caid=5886 ,
which in turn has signed a number of end entity certificates -
https://crt.sh/?Identity=%25&iCAID=5886 . While it does not appear to be a
large number of certificates (looks like roughly 84, with some
compatibility testing certificates issued), these certificates may stop
working - and would need to migrate.

However, this doesn’t address the main concern that informed the
requirements of the “Managed CA,” in response to community feedback. You
propose signing the Root G2 with Verisign Class 3 Public Primary
Certificate Authority – G5, https://crt.sh/?id=93 . This could reduce the
risk if someone pinned to that root, or https://crt.sh/?caid=443 (because
of https://crt.sh/?id=21606053 ), or https://crt.sh/?caid=25 ( because of
https://crt.sh/?id=2503596 ), which is fantastic, but wouldn’t address
situations like https://crt.sh/?caid=808 (which issued
https://crt.sh/?caid=1212 which is actively issuing certs -
https://crt.sh/?Identity=%25&iCAID=1212 ). Any of those customers who
pinned would potentially be negatively impacted, as no other cross-signs
exist for this path.

The Managed CA process was meant to address these concerns, by allowing at
least a 1:1 transition of the existing roots to new roots without the same
risk - by taking the existing roots, signing a new (DigiCert-operated)
“Managed CA”, and then transitioning online issuance to a hierarchy within
that new “Managed CA”. This doesn’t address situations where applications
pinned to intermediates - but unfortunately, I don’t have any suggestions
on how to effectively address that use case while also achieving the
necessary reduction in risk.

It sounds like this plan may have been based on a concern that I’d tried to
address in the previous message. That is, the removal of the existing
Symantec roots defines a policy goal - the elimination in trust in these
legacy roots, due to the unknown scope of issues. However, that goal could
be achieved by a number of technical means - for example, ‘whitelisting’ a
set of Managed CAs (as proposed by Chrome), or replacing the existing
Symantec roots with these new Managed CA roots in a 1:1 swap. Both of these
approaches achieve the same policy objective, while reducing the
compatibility risk.

Note that another part of the Managed CA proposal was to allow for the
(limited) reuse of information, due to Symantec’s assertions that no
partner could be found that could match the volume of issuance necessary to
avoid customer disruption. Based on your description of the plan, it sounds
like you intend to transition all of the Symantec customers over on Dec 1
to DigiCert roots - but that seems like it may result in an overload of
your support team if path building or pinning issues are discovered, and
your policy and compliance team as solutions have to be explored. As
communicated in the past, an acquisition of Symantec’s PKI doesn’t change
the requirement that the transition certificates be identified and
established by Dec 1 - so it would not be possible to address any of these
concerns after that point. By using this intermediate "Managed CA" step,
and balancing with a reduced certificate lifetime to help limit how long
DigiCert would need to operate this infrastructure, would offer a way to
smooth out support load and work through any support issues.

This is particularly useful when considering what DigiCert’s plans will be
for the future and it’s PKI. It’s really great to hear that DigiCert
realizes that root segmentation isn’t an effective mitigation strategy, and
it’s encouraging to hear there are plans to address that. Hopefully, by
looking at the complexity of Symantec’s PKI, you can see how some of these
risks can manifest, and why creating a large number of intermediates may
also be undesirable. A potentially better way to shard is arguably not by
organization or purpose - since they all run on DigiCert’s infrastructure,
they would all be treated the same for any matters (like revocation or
systemic issues) - but to shard by date. The reason to shard by date allows
root programs to effectively respond to any incidents - only having to
examine the certificates under the ‘problem period’. It also has a
side-benefit to your customers - by the periodic rotation of intermediates,
it discourages pinning by intermediate (since they regularly rotate), thus
reducing the impact to customers if an intermediate ever does have to be
revoked.

Hopefully these suggestions help work on a solid transition plan - first,
for DigiCert as Symantec’s Managed CA, second, for DigiCert looking to
acquire Symantec’s PKI business with minimal disruption to the ecosystem,
and third, for DigiCert’s long-term operations.

> The current end-state plan for root cross-signing is provided at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1401384. The diagrams there
> show all of the existing sub CAs along with the new Sub CAs and root
> signings planned for post-close. Some of these don’t have names so they are
> lumped in a general “Intermediate” box.
>
>
>

> The Global G2 root will become the transition root to DigiCert for
> customers who can’t move fully to an operational DigiCert roots prior to
> September 2018. Any customers that require a specific root can use the
> transition root for as long as they want, realizing that path validation
> may be an issue as Symantec roots are removed by platform operators.
> Although we cannot currently move to a single root because of the lack of
> EV support and trust in non-Mozilla platforms, we can move to the existing
> three roots in an orderly fashion.
>
>
>
> If the agreement closes prior to Dec 1, the Managed CA will never exist.
> Instead, all issuance will occur through one of the three primary DigiCert
> roots mentioned above with the exception of customers required to use a
> Symantec root for certain platforms or pinning. The cross-signed Global
> root will be only transitory, meaning we’d hope customers would migrate to
> the DigiCert roots once the systems requiring a specific Symantec roots are
> deprecated or as path validation errors arise.
>
>
>

> Jeremy
>
>
>
>
>
> From: Ryan Sleevi [mailto:ry...@sleevi.com]
> Sent: Thursday, September 14, 2017 1:28 PM

> To: Jeremy Rowley <jeremy...@digicert.com>
> Cc: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: DigiCert-Symantec Announcement
>
>
>
>
>
>
>

> On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy <
> dev-secur...@lists.mozilla.org <mailto:dev-security-policy@

[Peter Bowen]

On Thu, Sep 21, 2017 at 7:17 PM, Ryan Sleevi via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> I think we can divide the discussion into two parts, similar to the
> previous mail: How to effectively transition Symantec customers with
> minimum disruption, whether acting as the Managed CA or as the future
> operator of Symantec’s PKI, and how to effectively transition DigiCert’s
> infrastructure. This is a slightly different order than your e-mail
> message, but given the time sensitivity of the Symantec transition, it
> seems more effective to discuss that first.
>
> I think there may have been some confusion on the Managed CA side. It’s
> excellent that DigiCert plans to transition Symantec customers to DigiCert
> roots, as that helps with an expedient reduction in risk, but the plan
> outlined may create some of the compatibility risks that I was trying to
> highlight. In the discussions of the proposed remediations, one of the big
> concerns we heard raised by both Symantec and site operators was related to
> pinning - both in the Web and in mobile applications. We also heard about
> embedded or legacy devices, and their needs for particular chains.
>

> It sounds like this plan may have been based on a concern that I’d tried to
> address in the previous message. That is, the removal of the existing
> Symantec roots defines a policy goal - the elimination in trust in these
> legacy roots, due to the unknown scope of issues. However, that goal could
> be achieved by a number of technical means - for example, ‘whitelisting’ a
> set of Managed CAs (as proposed by Chrome), or replacing the existing
> Symantec roots with these new Managed CA roots in a 1:1 swap. Both of these
> approaches achieve the same policy objective, while reducing the
> compatibility risk.

Ryan,

As an existing Symantec customer, I'm not clear that this really
addresses the challenges we face.

So far we have found several different failure modes. We hope that
any solution deployed will assure that these don't trigger.

First, we found that some clients have a limited set of roots in their
trust store. The "VeriSign Class 3 Public Primary Certification
Authority - G5" root with SPKI SHA-256 hash of
25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384df058 is
the only root trusted by some clients. They do, somewhat
unfortunately, check the certificate issuer, issuer key id, and
signature, so they changing any will break things. However they don't
update their trust store. So the (DN, key id, public key) tuple needs
to be in the chain for years to come.

Second, we have found that some applications use the system trust
store but implement additional checks on the built and validated
chain. The most common case is checking that at least one public key
in the chain matches a list of keys the application has internally.

As there is an assumption that the current root (DN, public key)
tuples will be replaced relatively soon by some trust store
maintainers, there needs to be a way that that both of these cases can
work. The only way I can see this working long term on both devices
with updated trust stores as well as devices that have not updated the
trust store is to do a little bit of hackery and create new (DN,
public key) tuples with the existing public key. This way apps with
pinning will work on systems with old trust stores and one systems
with updated trust stores.

As a specific example, again using the Class 3 G5 root, today a chain
looks like:

1) End-entity info
2) spkisha256:f67d22cd39d2445f96e16e094eae756af49791685007c76e4b66f154b7f35ec6,KeyID:5F:60:CF:61:90:55:DF:84:43:14:8A:60:2A:B2:F5:7A:F4:43:18:EF,
DN:CN=Symantec Class 3 Secure Server CA - G4, OU=Symantec Trust
Network, O=Symantec Corporation, C=US,
3) spkisha256:25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384df058,
KeyID:7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33,
DN:CN=VeriSign Class 3 Public Primary Certification Authority - G5,
OU=(c) 2006 VeriSign, Inc. - For authorized use only, OU=VeriSign
Trust Network, O=VeriSign\, Inc., C=US

If there is a desire to (a) remove the Class 3 G5 root and (b) keep
the pin to its key working, the only solution I can see is to create a
new root that uses the same key. This would result in a chain that
looks something like:

1) End-entity info
2b) spkisha256:<tbd>,KeyID:<tbd>, DN:CN=New Server Issuing CA, O=DigiCert, C=US,
3b) spkisha256:25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384df058,
KeyID:6c:e5:3f:7b:45:1f:66:b4:e6:7c:70:05:86:19:79:4f:a6,
DN:CN=VeriSign Class 3 Public Primary Certification Authority - G5,
OU=DigiCert Compatibility Root, OU=(c) 2006 VeriSign, Inc. - For
authorized use only, OU=VeriSign Trust Network, O=VeriSign\, Inc.,
C=US
3) spkisha256:25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384df058,
KeyID:7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33,
DN:CN=VeriSign Class 3 Public Primary Certification Authority - G5,
OU=(c) 2006 VeriSign, Inc. - For authorized use only, OU=VeriSign
Trust Network, O=VeriSign\, Inc., C=US

Note that 3b and 3 have the same public key and intersecting sets of
attributes in the DN, but have different key IDs and different DNs.

In order for this to work, 3b would have to be included in new trust
stores. This likely implies that 3b is created under new controls
(e.g. by DigiCert), but presumably this cannot happen until the deal
closes. If this doesn't happen prior to December 1, then there will
likely need to be an interim phase where a different issuing CA is
created by DigiCert that is signed by #3 -- something like
"CN=Symantec Class 3 Secure Server CA - GD1, OU=Symantec Trust
Network, O=Symantec Corporation, C=US". This would be the "Managed
CA".

I realize this is somewhat more complex than what you, Ryan, or Jeremy
proposed, but it the only way I see root pins working across both
"old" and "new" trust stores.

Thanks,
Peter

[Nick Lamb]

On Friday, 22 September 2017 05:01:03 UTC+1, Peter Bowen wrote:
> I realize this is somewhat more complex than what you, Ryan, or Jeremy
> proposed, but it the only way I see root pins working across both
> "old" and "new" trust stores.

I would suggest that a better way to spend the remaining time would be remedial work so that your business isn't dependant on a single third party happening to make choices that are compatible with your existing processes. Trust agility should be built into existing processes and systems, where it doesn't exist today it must be retro-fitted, systems which can't be retrofitted are an ongoing risk to the company's ability to deliver.

Trust agility doesn't have to mean you give up all control, but if you were in a situation where the business trusted roots from Symantec, Comodo and say, GlobalSign then you would have an obvious path forwards in today's scenario without also needing to trust dozens of organisations you've no contact with.

I know the Mozilla organisation has made this mistake itself in the past, and I'm sure Google has too, but I don't want too much sympathy here to get in the way of actually making us safer.

[Peter Bowen]

On Fri, Sep 22, 2017 at 6:22 AM, Nick Lamb via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> On Friday, 22 September 2017 05:01:03 UTC+1, Peter Bowen wrote:

>> I realize this is somewhat more complex than what you, Ryan, or Jeremy
>> proposed, but it the only way I see root pins working across both
>> "old" and "new" trust stores.
>

> I would suggest that a better way to spend the remaining time would be remedial work so that your business isn't dependant on a single third party happening to make choices that are compatible with your existing processes. Trust agility should be built into existing processes and systems, where it doesn't exist today it must be retro-fitted, systems which can't be retrofitted are an ongoing risk to the company's ability to deliver.
>
> Trust agility doesn't have to mean you give up all control, but if you were in a situation where the business trusted roots from Symantec, Comodo and say, GlobalSign then you would have an obvious path forwards in today's scenario without also needing to trust dozens of organisations you've no contact with.
>
> I know the Mozilla organisation has made this mistake itself in the past, and I'm sure Google has too, but I don't want too much sympathy here to get in the way of actually making us safer.

Nick,

I agree with pretty much everything you said :)

However, as you point out, many organisations have run into problems
in this area. As a community, we saw similar issues come up during
the SHA-1 deprecation phase and seemed surprised. I want to try to
make sure there is not surprise, especially when it comes to
configurations that are not obvious.

For example, on some mobile platforms it is common to have the app
enforce pinning but the OS handle chain building and validation. This
can have poor interaction if the OS were to update the trust store as
the returned chain may no longer have the pinned CA.

Consider what Jeremy drew:

GeoTrust Primary Certification Authority -> DigiCert Global G2 -> (new
issuing CA) -> (end entity)

If the platform trusts DigiCert Global G2, then the chain that is
returned to the application will be:

DigiCert Global G2 -> (new issuing CA) -> (end entity)

In this case, any application pinned to GeoTrust will fail.

Even if it was a new Root:

GeoTrust Primary Certification Authority -> DigiCert GeoTrust G2 ->
(new issuing CA) -> (end entity)

The same problem will occur if the OS updates the trust store but the
application does not update.

One notable thing is that the server operator, application vendor, OS
vendor, and CA may be four unrelated parties. If the application is
expected to work with "new" and "old" OS versions, this will take some
careful work if the keys in the built chain change over time.

Thanks,
Peter

[Ryan Sleevi]

> I realize this is somewhat more complex than what you, Ryan, or Jeremy
> proposed, but it the only way I see root pins working across both
> "old" and "new" trust stores.
>

> Thanks,
> Peter


Peter,

Thanks a ton for sharing the challenges some customers face. It’s unclear,
however, why it’s necessary to re-use the existing key, particularly in
browser-based applications, so hopefully that can be expanded upon.

If we take the existing path:

1) End-entity info
2)
spkisha256:f67d22cd39d2445f96e16e094eae756af49791685007c76e4b66f154b7f35ec6,KeyID:5F:60:CF:61:90:55:DF:84:43:14:8A:60:2A:B2:F5:7A:F4:43:18:EF,
DN:CN=Symantec Class 3 Secure Server CA - G4, OU=Symantec Trust
Network, O=Symantec Corporation, C=US,
3)
spkisha256:25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384df058,
KeyID:7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33,
DN:CN=VeriSign Class 3 Public Primary Certification Authority - G5,
OU=(c) 2006 VeriSign, Inc. - For authorized use only, OU=VeriSign
Trust Network, O=VeriSign\, Inc., C=US

Then the proposal I was suggesting was to instead consider the following:
1) End-entity info
2z) spkisha256:<TBD>,KeyID:<TBD>,

DN:CN=New Server Issuing CA, O=DigiCert, C=US,

3z) spkisha256:<TBD>,KeyID:<TBD>,
DN:CN=Managed CA, O=DigiCert, C=US,

3)
spkisha256:25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384df058,
KeyID:7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33,
DN:CN=VeriSign Class 3 Public Primary Certification Authority - G5,
OU=(c) 2006 VeriSign, Inc. - For authorized use only, OU=VeriSign
Trust Network, O=VeriSign\, Inc., C=US

Where both 2z and 3z are operated by the Managed CA, wholly on the Managed
CA’s infrastructure.

Based on the public discussions to date, the actual implementation of the
transition begins to look like:
Any certificate that chains to 3 with a notBefore > 2017/12/01 is not
trusted, unless it transits 3z. This is landed in code around 2017/12/01.
Any certificate that chains to 3 with a notBefore < 2016/06/01 is not
trusted, beginning sometime early in 2018 (e.g. Chrome 66)
3 is removed from the root store, while 3z is added, sometime in late 2018
(e.g. Chrome 70)

This provides a transition path for those implementing something similar to
what Google Chrome and Mozilla Firefox have announced. Other vendors that
have not commented to date on their plans could implement something
similar, or they could adopt a plan of:
At some point in the future, 3 is removed from the root store, while 3z is
added.

Finally, for devices and applications that do not update their limited
trust stores, 3 remains present in the chain to support them, thus
supporting both modern and legacy clients equally effectively.

For browsers, this allows sites until late 2018 to fully complete a
migration of any HPKP-pinned websites, representing a substantially long
transition window. For operating systems and platforms, they can evaluate
both the compatibility risks to their overall platforms and applications,
as well as look at similar or alternative mitigations.

The important difference in this plan between your proposed 3b and my
suggested 3z is that 3z has greater assurances with respect to the
protection and generation of the key material, which addresses some of the
concerns raised with the existing infrastructure. Adding 3b to the root
stores still leaves the risk of trusting the legacy infrastructure, while
3z would be starting from a known-good point and continuing to work forward.

I don’t think there’s an intent of a ‘relatively soon’ replacement of the
root - as outlined, that’s proposed for 2018 with the full distrust.
Programmatic enforcement, for those that wish to mitigate the risk during
the transition period, can be done soon, while the replacement of the root
- which represents distrusting all existing certificates - is deferred
until 2018.

Do you think that addresses your concerns? As I tried to highlight, the one
notable downside to this is that applications or sites that exclusively
pinned to 2
(spkisha256:f67d22cd39d2445f96e16e094eae756af49791685007c76e4b66f154b7f35ec6)
will be affected, but so far, there hasn’t been a solution identified that
could allow that key to still be used without still trusting the legacy
infrastructure, which doesn’t work.

[Peter Bowen]

>> spkisha256:f67d22cd39d2445f96e16e094eae756af49791685007c76e4b66f154b7f35ec6,KeyID:5F:60:CF:61:90:55:DF:84:43:14:8A:60:2A:B2:F5:7A:F4:43:18:EF,
>> DN:CN=Symantec Class 3 Secure Server CA - G4, OU=Symantec Trust
>> Network, O=Symantec Corporation, C=US,
>> 3)
>> spkisha256:25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384df058,
>> KeyID:7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33,
>> DN:CN=VeriSign Class 3 Public Primary Certification Authority - G5,
>> OU=(c) 2006 VeriSign, Inc. - For authorized use only, OU=VeriSign
>> Trust Network, O=VeriSign\, Inc., C=US
>>

>> If there is a desire to (a) remove the Class 3 G5 root and (b) keep
>> the pin to its key working, the only solution I can see is to create a
>> new root that uses the same key. This would result in a chain that
>> looks something like:
>>
>> 1) End-entity info
>> 2b) spkisha256:<tbd>,KeyID:<tbd>, DN:CN=New Server Issuing CA, O=DigiCert,
>> C=US,
>> 3b)
>> spkisha256:25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384df058,
>> KeyID:6c:e5:3f:7b:45:1f:66:b4:e6:7c:70:05:86:19:79:4f:a6,
>> DN:CN=VeriSign Class 3 Public Primary Certification Authority - G5,
>> OU=DigiCert Compatibility Root, OU=(c) 2006 VeriSign, Inc. - For
>> authorized use only, OU=VeriSign Trust Network, O=VeriSign\, Inc.,
>> C=US
>> 3)

I agree that 3b potentially has a higher risk than 3z, but it has a
higher reward. 3b allows pins to continue to work even if the trust
store removes 3. It comes down to the level of protection of the root
key. If it is secure, then this provides continued compatibility
while removing the original root. The 3z option means that all pins
to the existing root break.

This isn't really a risk for browser-based applications, after all the
browser can implement a "known bad pins" list and not enforce pinning
if all the pins are on that list or can choose to not enforce pins if
older than a certain date. However in a situation where the
application is distinct from the browser, this does not work. I
realize this isn't Mozilla (or Chrome's) problem, but it is important
to consider in the broader Internet PKI view.

Thanks,
Peter

[Ryan Sleevi]

On Sun, Sep 24, 2017 at 12:40 PM, Peter Bowen <pzb...@gmail.com> wrote:
>
> I agree that 3b potentially has a higher risk than 3z, but it has a
> higher reward. 3b allows pins to continue to work even if the trust
> store removes 3. It comes down to the level of protection of the root
> key. If it is secure, then this provides continued compatibility
> while removing the original root. The 3z option means that all pins
> to the existing root break.
>
> This isn't really a risk for browser-based applications, after all the
> browser can implement a "known bad pins" list and not enforce pinning
> if all the pins are on that list or can choose to not enforce pins if
> older than a certain date. However in a situation where the
> application is distinct from the browser, this does not work. I
> realize this isn't Mozilla (or Chrome's) problem, but it is important
> to consider in the broader Internet PKI view.
>
> Thanks,
> Peter
>

Peter,

Thanks for confirming that this isn’t a concern for browser-based
applications. While not to suggest they are the only participant that
matters in the Web PKI, I think it would be fair to say that many of the
concessions and workarounds have been heretofore focused on the
browser-based case.

That said, I’m not sure it’s as dire as you suspect. As noted in the
previous message, an adoption of 3z wouldn’t break applications pinned to 3
unless and until a root store took steps to remove. We’ve seen some
platforms, such as macOS and iOS, take steps for manual whitelisting of
pre-existing certs. We’ve seen other platforms, such as Windows, take steps
based on timestamping or date issued. Most importantly, however, the only
public discussions regarding removal have suggested a timeframe of
late-2018. Applications that pinned certificates, without the ability to
update in a year, are arguably outside of the scope of ‘reasonable’ use
cases - the ecosystem itself has shown itself to change on at least that
frequency.

As such, hopefully it’s persuasive that the reward for 3b compared to 3z is
not actually significant, especially for browsers, and the risk is arguably
much greater. Repeating the pattern of 2z & 3z, for every root with active
issuance, provides the greatest way to reduce risk for applications that
have pinned and need additional migration time. Note that the plan would
still suggest that all users should be moved to DigiCert-by-default, should
the Symantec deal close, and 2z/3z used merely to support those cases that
can concretely identify compatibility issues and need additional time to
migrate. Should the Symantec/DigiCert deal fail to close, then 2z/3z,
operated by DigiCert as a Managed CA, can serve to support those users who
cannot migrate to other CAs/PKIs and have the critical compatibility
dependency.

If 3z is adopted, both sites and applications would have until late-2018 to
update their pinning code, and potentially have (depending on use cases
identified) as much as several years to identify and mitigate the
interoperability concerns between ‘truly legacy’ (but not pinned) devices
and actively-maintained clients, while the risk to users from the legacy
infrastructure will be eliminated by the end of 2018.

[Gervase Markham]

On 26/09/17 03:17, Ryan Sleevi wrote:
> update in a year, are arguably outside of the scope of ‘reasonable’ use
> cases - the ecosystem itself has shown itself to change on at least that
> frequency.

Is "1 year" not a relatively common (for some value of "common") setting
for HPKP timeouts for sites which think they have now mastered HPKP?

Does anyone have stats on HPKP prevalence and duration distribution?
Ideally combined with whether the longer time periods are pinning to
roots, intermediates or EE certs?

Gerv

[Quirin Scheitle]

Hi Gerv,

> On 28. Sep 2017, at 19:06, Gervase Markham via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> Is "1 year" not a relatively common (for some value of "common") setting
> for HPKP timeouts for sites which think they have now mastered HPKP?

We did a large-scale scan of about 200M domains for HPKP in April 2017.
We found a max-age median duration of 1 month and about 10% of domains that set max-age values to 1 year or more.
I am attaching the plot. HPKP it missing, as it is very similar to HPKP|HSTS.
The associated paper will be camera-ready tomorrow, happy to share it then.

>
> Does anyone have stats on HPKP prevalence and duration distribution?
> Ideally combined with whether the longer time periods are pinning to
> roots, intermediates or EE certs?

We did not look into that, but it should be doable from the data.

Kind regards
Quirin

[Patrick Figel]

On 28.09.17 19:06, Gervase Markham via dev-security-policy wrote:
> On 26/09/17 03:17, Ryan Sleevi wrote:

>> update in a year, are arguably outside of the scope of ‘reasonable’ use
>> cases - the ecosystem itself has shown itself to change on at least that
>> frequency.
>

> Is "1 year" not a relatively common (for some value of "common") setting
> for HPKP timeouts for sites which think they have now mastered HPKP?

IIRC both Chrome and Firefox cap the max-age value of HPKP at 60 days.

[April King]

On Thursday, September 28, 2017 at 12:06:50 PM UTC-5, Gervase Markham wrote:

> Does anyone have stats on HPKP prevalence and duration distribution?
> Ideally combined with whether the longer time periods are pinning to
> roots, intermediates or EE certs?
>
> Gerv

Of the 1.97M unique domains scanned by the Mozilla Observatory, 10559 of them utilize HTTP Public Key Pinning with at least two pins. Here are the twenty most common max-age settings for those domains:

Number of Domains max-age
5480 2592000
2060 5184000
724 31536000
314 15768000
168 86400
144 7776000
138 604800
129 1296000
127 10
122 15552000
112 3600
83 300
73 63072000
70 51840000
64 60
42 600
30 0
30 1209600
27 259200
20 864000

30 days in the most common setting, followed by 60 days. If you cap max-age at 1 year to limit outliers, the average max-age normalized by the number of domains is 70.83 days. You can see the entirety of the data here, if you want to play around with it:

https://docs.google.com/spreadsheets/d/1zZp76ZOWSXe8W346oa1tFbdVH1KH_XhaM_07a6Ej_b8/edit?usp=sharing

Please let me know if there's anything else I can get you!

[Jeremy Rowley]

Is this a correct summary?



There’s four categories of customers that require trust in existing Symantec roots being address:

1. Those that can migrate to a new trusted root because they use the certs in a standard TLS-configuration
2. Those that require a certain Symantec root for various applications but can use a DigiCert root for standard browser-based TLS
3. Those that require a non-trusted intermediate because they have pinned a Symantec root in the application and using a trusted DigiCert root, even if cross-signed would cause the application to fail.
4. Those that pinned a specific intermediate’s keys, resulting in a failure unless the issuing CA had the same keys as used by Symantec.



Category 1 customers are straight-forward. They will be migrated to a DigiCert root.



Category 2 customers are potentially straight forward but could have validation issues. If we cross-sign the DigiCert global root with the required Symantec root, then the customer can migrate but might experience issues when the root is actually removed. However, this could cause issues for the 84 certificates already using the DigiCert root.



Category 3 customers are potentially straight forward but will lose trust in Sep 2018 unless the new root is embedded prior to that date. If we create a new root, sign it with the Symantec roots, and embed the new roots as necessary, we avoid the problems with a previously trusted root. Wouldn’t this have the same validation issues as Category 2?



Category 4 is under discussion. Sounds like Google would prefer not to see a reuse of keys. Pinning times are sufficiently short that customers could migrate to the new infrastructure prior to total distrust of the roots under certain circumstances. If the cert was issued prior to June 2016, and the key expires after March 2018, anyone using the pin could be locked out until the pin expires. If pins last up to a year, customers issuing a cert after June 2016 should have time to migrate prior to root removal. One issue is that these customers won’t be able to get a new cert that functions off the old intermediate post Dec 1, 2017, effectively meaning key compromises cannot be addressed.



=

Jeremy





From: Ryan Sleevi [mailto:ry...@sleevi.com]

Sent: Monday, September 25, 2017 8:18 PM
To: Peter Bowen <pzb...@gmail.com>
Cc: Ryan Sleevi <ry...@sleevi.com>; mozilla-dev-s...@lists.mozilla.org; Jeremy Rowley <jeremy...@digicert.com>
Subject: Re: DigiCert-Symantec Announcement

[Ryan Sleevi]

Jeremy,

I think the grouping may mix a bit of the solutions in with the problem
definitions, so I tried to reword a little. Does this capture the mix of
what’s been discussed?

1) Clients that support a ‘common’ root store of various CAs, including
DigiCert, and do not use pinning.

2) Browser clients that support a ‘common’ root store of various CAs,
including DigiCert, but have exclusively pinned to Symantec legacy roots.

3) Non-browser clients (e.g. native applications) that support a ‘common’
root store of various CAs, including DigiCert, but have exclusively pinned
to Symantec roots.

4) Non-browser clients (e.g. native applications, payment terminals) that
only support Symantec legacy roots.

5) Browser clients that support a ‘common’ root store of various CAs,
including DigiCert, but have exclusively pinned to Symantec legacy
intermediates.

Sites that exclusively serve clients in Case 1 can migrate to DigiCert’s
existing roots, or to any other supported CA, without any disruption.

Sites that serve clients in Cases 2 - 4 would all be met by the “Managed
CA” case I gave you. Cases 2 and 3 would encounter compatibility problems
with path-building if you sign DigiCert roots.

Sites that serve clients in Case 5 do not have an readily identified
solution that meets the security objectives. Browsers can take steps here,
but there's not something from the path building side.

This is why I advocate for sticking to the original “Managed CA” plan
outlined, as this minimizes the compatibility risk isolated. It also
separates out the transition to a “Managed CA,” scheduled for Dec 1, and
any other transitions between Symantec and DigiCert, such as the intent to
acquire Symantec’s assets.


On Sun, Oct 1, 2017 at 12:54 PM, Jeremy Rowley <jeremy...@digicert.com>
wrote:

> *From:* Ryan Sleevi [mailto:ry...@sleevi.com]
> *Sent:* Monday, September 25, 2017 8:18 PM
> *To:* Peter Bowen <pzb...@gmail.com>
> *Cc:* Ryan Sleevi <ry...@sleevi.com>; mozilla-dev-security-policy@
> lists.mozilla.org; Jeremy Rowley <jeremy...@digicert.com>
> *Subject:* Re: DigiCert-Symantec Announcement

[Amus]

Thanks! This was useful. Case 2-3 (and 4 where there is a need to support their app plus browsers) are only supported if the Symantec roots are trusted in time prior to removal and embedding the new roots is greater or equal to all browser versions that remove the old roots. The proposal to cross-sign the DigiCert root was intended as contingency so we can stick to the Sep 2018 timeline for root deprecation if the embedding process takes too long.

Assuming the transaction completes, what does this mean for the audit plan? How would that audit plan apply to these new roots? Does it apply until after everything is transferred to the DigiCert CPS?

[Peter Kurrasch]

Clearly there has to be a way for key compromises to be remedied. If I've been following this pinning discussion correctly it seems unavoidable that we will have cases requiring certs to be issued on the soon-to-be old Symantec infrastructure...? for the foreseeable future (i.e. post-Dec 1)?

Also it's not totally clear to me what will be delivered on Dec 1, 2017 in terms of infrastructure as well as issuance policies.

From: Jeremy Rowley via dev-security-policy

Sent: Sunday, October 1, 2017 2:55 PM‎

Is this a correct summary?

There’s four categories of customers that require trust in existing Symantec roots being address:

...

4. Those that pinned a specific intermediate’s keys, resulting in a failure unless the issuing CA had the same keys as used by Symantec.

...‎

[Jeremy Rowley]

Hi everyone,



We met the December 1 deadline of integrating with Symantec systems, and all validation and issuance of TLS certificates is currently flowing through DigiCert’s backend. Initial results appear generally positive, with the validation staff processing orders and delivering certificates. Symantec customers are using their existing Symantec front-end ordering systems. As expected with any migration of this scale, we are working directly with customers in the instances that require additional customer support.



Thought I’d let everyone here know we are live with the operations. I plan to post an update with more information about how things went after we have some run-rate data. Let me know if you have questions.



Jeremy