1401384 - DigiCert-Symantec Root Transition Information

Status: RESOLVED WORKSFORME

(CA Program :: CA Certificate Root Program, task)

Description

[Jeremy Rowley]

Attachment: DigiCert root diagram

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36

Steps to reproduce:

This bug is to share files and information related to the DigiCert-Symantec announcement (files are stripped from the mailing list)

Comment 1

[Jeremy Rowley]

Attachment: Diagram of DIgiCert roots, existing sub CAs, and proposed chaining

Comment 2

[Jeremy Rowley]

Attachment: Diagram of Geotrust roots

Geotrust root certs (only per CCADB)

Comment 3

[Jeremy Rowley]

Attachment: Diagram of Symantec roots from CCADB

This diagram was created solely based on the public information found in CCADB

Comment 4

[Jeremy Rowley]

Attachment: Diagram of Thawte roots based on CCADB

This diagram of Thawte intermediates is based solely on the public information in CCADB

Comment 5

[Jeremy Rowley]

Attachment: Diagram of Verisign roots based on CCADB

Diagram of Verisign root chaining based solely on public information in CCADB

Comment 6

[Jeremy Rowley]

Attachment: DigiCert Issuance Process Flow.pdf

This is a flow for DigiCert issuance post close along with some of the features planned. Although very high level, I thought the community might find it interesting to see what we're doing, the validation we support, and the plans for near-term improvements.

Comment 7

[Gervase Markham [:gerv]]

Interesting that the profile gets selected so late in the process. Don't you need to know what it is quite early on so you can know what information you actually need to get and validate?

Gerv

Comment 8

[Jeremy Rowley]

Validation is specified as part of the initial request. The profile selection is to choose what profiled based on key pair, customer ID, type, etc.  The reason for this is the validation is decoupled from issuance so we can validate without issuance and update validation without impacting profiles.

Comment 9

[Jeremy Rowley]

Attachment: The root plan we plan on going with

This is the hierarchy we plan on using. Note, that we still want to cross-sign the Global Root just in case the new root cannot be embedded in time.

Comment 10

[Jeremy Rowley]

Attachment: Final Root Plan - The one we actually went with

This is the root plan we actually went with. Where possible, the ICAs were added to  CCDAB. There's some confusion on how we add the cross certs though. Ben's working on that.  The root distribution plan is:

1) Issue everyone off the DigiCert Global Root CA or High Assurance CA whenever possible. Note that neither of these chain to a Symantec CA which will shield migrating entities from the future distrust of the Symantec roots.

2) Whenever issuance from the Global Root CA is not permitted because of pinning or custom root stores, we plan on issuing from the non-publicly trusted DigiCert Transition Root CA. We don't plan on embedding this root with the browsers so all certs chained to it will lose trust with the root.  This root is intended for entities that must use the G5 root but do not need browser trust in Chrome or Mozilla.

3) If public trust is required, we are issuing certs from the DigiCert Global G2/G3 roots. These roots are cross-signed by their Symantec counterparts. We are strongly advising subscribers not to use the cross-sign and, if used, remove the cross-sign prior to September 2018 as we're not sure how the distrust will impact the cross-sign. 

4) There are a large class of subscribers that cannot transition to the DigiCert hierarchy.  The common obstacles are a) the cert updating tools were not built with intermediate replacement capabilities, meaning only the end entity cert is downloaded and installed, b) the system requires a path length of three and the Symantec G5 root is the only permitted root, and c) the customer pinned the ICA. In the calls I've had so far, none of these customers really need trust in browsers for these particular platforms. In this case, we are permitting continued issuance from the hierarchy until early next year. At that point, probably the end of January, everyone will need to complete the migration to DigiCert's infrastructure. We're still working on the date.

On a good note, DigiCert is already validating and issuing certificates used by the Symantec infrastructure. We're on track to do all issuance and validation of TLS certs by Dec 1.

Comment 11

[Jeremy Rowley]

The policy OID we plan on using where DigiCert did the validation is 2.16.840.1.114412.43. There currently isn't an OID for validation reuse as we don't plan on reusing validation information for TLS certs

Comment 12

[Jeremy Rowley]

Scratch that - I think we'll just use our existing OIDs to indicate validation is done by Digicert. After all, except the transition root, they all chain through a DigiCert root CA.

dv_ssl: 2.16.840.1.114412.1.2
ov_ssl: 2.16.840.1.114412.1.1
ev_ssl: 2.16.840.1.114412.2.1

Comment 13

[Wayne Thayer]

(In reply to Jeremy Rowley from comment #10)
> Created attachment 8928824 [details]
> Final Root Plan - The one we actually went with
> 
Jeremy: does this plan require any new roots to be embedded in user agents? I haven't seen an inclusion request so I assume not, but want to confirm.

Comment 14

[Jeremy Rowley]

Nope - no new roots required. Thanks Wayne!

Comment 15

[Brenda Bernal]

Hi Wayne - Is there anything further on this bug or can this be marked as resolved?

Comment 16

[Jeremy Rowley]

We want to share the latest update on the Symantec distrust plan and seek input from the community.  Below is a high level summary:

The majority of root program operators plan to either partially or fully distrust Symantec roots by Q3 CY 2018, and no later than Q2 CY 2019.  All TLS certificates issued from these roots will be impacted.  Please see list of roots below.

Key Dates
•	March 2018 – Beginning of phased removal of trust by root program operators for Symantec TLS certificates issued prior to June 1, 2016.
•	October 2018 – Full removal of trust of Symantec-issued TLS certificates by root program operators.
•	By no later than Q2 CY 2019 – Full removal of Symantec-issued TLS certificates from all major root program operators.

We have been aggressively transitioning our customers and their certificates to be issued off DigiCert roots in meeting the requirements of the browser community, key stakeholders, and our partners, while minimizing disruption. This transition extends beyond TLS certificates, and we plan to migrate most publicly-trusted non-TLS certificate issuance to DigiCert roots on October 1st. However, the exception list of customers unable to migrate s/MIME certificates will be larger than the TLS-side as these certificates are often used with government ID cards or in facilities without ready access. We'll work with these customers to replace their issuing CAs with DigiCert issuing CAs so all certificates going forward will chain to one of the ten DigiCert root certificates. 

I'd definitely love the feedback on the above and public comments.

Impacted Roots and Usage:
Root	EKU
GeoTrust Global CA	Server Authentication; Client Authentication; Secure Email; Code Signing; Time Stamping
GeoTrust Global CA 2	Server Authentication; Client Authentication; Code Signing; Secure Email; Time Stamping
GeoTrust Primary Certification Authority	Server Authentication; Client Authentication; Secure Email; Code Signing
GeoTrust Primary Certification Authority - G2	Server Authentication; Client Authentication; Secure Email; Code Signing; Time Stamping
GeoTrust Primary Certification Authority - G3	Server Authentication; Client Authentication; Secure Email; Code Signing; Time Stamping
GeoTrust Universal CA	Server Authentication; Client Authentication; Secure Email; Code Signing; Time Stamping
GeoTrust Universal CA 2	Server Authentication; Client Authentication; Code Signing; Secure Email; Time Stamping
Symantec Class 1 Public Primary Certification Authority - G4 	Client Authentication; Secure Email
Symantec Class 1 Public Primary Certification Authority - G6 	Client Authentication; Secure Email
Symantec Class 2 Public Primary Certification Authority - G4 	Client Authentication; Secure Email
Symantec Class 2 Public Primary Certification Authority - G6 	Client Authentication; Secure Email
Symantec Class 3 Public Primary Certification Authority - G4	Server Authentication; Client Authentication; Secure Email; Code Signing; Time Stamping
Symantec Class 3 Public Primary Certification Authority - G6	Server Authentication; Client Authentication; Secure Email; Code Signing; Time Stamping
thawte Primary Root CA	Server Authentication; Client Authentication; Secure Email; Code Signing
thawte Primary Root CA - G2	Server Authentication; Client Authentication; Secure Email; Code Signing; Time Stamping
thawte Primary Root CA - G3	Server Authentication; Client Authentication; Secure Email; Code Signing; Time Stamping
VeriSign Class 1 Public Primary Certification Authority - G3 	Client Authentication; Secure Email
VeriSign Class 2 Public Primary Certification Authority - G3 	Client Authentication; Code Signing; Secure Email
VeriSign Class 3 Public Primary Certification Authority - G3	Code Signing; Server Authentication; Client Authentication; Secure Email
VeriSign Class 3 Public Primary Certification Authority - G4	Server Authentication; Client Authentication; Secure Email; Code Signing; Time Stamping
VeriSign Class 3 Public Primary Certification Authority - G5	Server Authentication; Client Authentication; Secure Email; Code Signing
VeriSign Universal Root Certification Authority	Server Authentication; Client Authentication; Secure Email; Code Signing; Time Stamping

Comment 17

[Ryan Sleevi]

(In reply to Jeremy Rowley from comment #16)
> Key Dates
> •	March 2018 – Beginning of phased removal of trust by root program
> operators for Symantec TLS certificates issued prior to June 1, 2016.
> •	October 2018 – Full removal of trust of Symantec-issued TLS certificates
> by root program operators.

Jeremy: One slight clarification to your dates: The removal is expected to _start_ late June/early July 2018.

Thus, by July 2018, all Symantec-issued TLS certificate consumers should have begun transitioning, with the majority having completed the transition. This ensures that, should there be any unforeseen issues, they can have a small window of time to remove those issues.

In particular, releases of both Firefox and Chrome are expected, no later than July, which begin distrusting these certificates, with the overall population of versions increasing to 100% by October. Thus, rather than October being a transition date from 0% to 100%, it should be seen as the transition from, say, 50% to 100%. Thus, to avoid breaking 50% of users, sites should be transitionining *now*.

> •	By no later than Q2 CY 2019 – Full removal of Symantec-issued TLS
> certificates from all major root program operators.

Comment 18

[Brenda Bernal]

Hi Wayne, Is there anything else needed to close this bug since we are past the distrust dates? Please advise.

Comment 19

[Wayne Thayer]

I've gone ahead and assigned this to myself. I would like to keep it open because the Symantec roots are still in the Mozilla root store and I need to publish and discuss a plan that leads to their eventual removal.

Comment 20

[Brenda Bernal]

Thanks Wayne. Would that plan align to what we discussed for S/MIME towards the end of last year, or something totally separate for TLS?

Comment 21

[Wayne Thayer]

(In reply to Brenda Bernal from comment #20)

Thanks Wayne. Would that plan align to what we discussed for S/MIME towards the end of last year, or something totally separate for TLS?

Yes, the plan will consider both TLS and S/MIME.

Comment 22

[Kathleen Wilson]

Discussed further transition and filed corresponding bugs.

https://groups.google.com/d/msg/mozilla.dev.security.policy/WpJiD14tiXc/2Waf17XCFQAJ

=== Bug #1: Root Removal and Disable Email Trust Bit ===
https://bugzilla.mozilla.org/show_bug.cgi?id=1618402
Symantec root certs - removal and turning off Email trust bit

=== Bug #2: Set CKA_NSS_SERVER_DISTRUST_AFTER ===
https://bugzilla.mozilla.org/show_bug.cgi?id=1618404
Symantec root certs - Set CKA_NSS_SERVER_DISTRUST_AFTER

=== Bug #3: Set CKA_NSS_EMAIL_DISTRUST_AFTER ===
https://bugzilla.mozilla.org/show_bug.cgi?id=1618407
Symantec root certs - Set CKA_NSS_EMAIL_DISTRUST_AFTER

Comment 23

[Ben Wilson]

Resolving this. However, this bug can act as a repository, if needed, if any additional documents need to be uploaded or shared.