1099311 - Add Symantec-branded Class 3 roots

Status: RESOLVED WONTFIX

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

Description

[Rashmi Tabada]

+++ This bug was initially created as a clone of Bug #833986 +++

Per request on the original bug, breaking up the original bug into 3 bugs; this is 2nd of 3.

Please add the following roots to the Mozilla root store. The audit requirements have been provided. 

Symantec Class 2 Public Primary Certification Authority - G4 (SHA384WithECCp384)
Symantec Class 3 Public Primary Certification Authority - G4 (SHA384WithECCp384)
Symantec Class 3 Public Primary Certification Authority - G6 (SHA384WithRSA4096)

Thank you,
Rashmi

Comment 1

[Kathleen Wilson]

The Symantec-branded Class 1 and Class 2 roots will be handled in Bug #833986.

This bug is for the Symantec-branded Class 3 roots.
Symantec Class 3 Public Primary Certification Authority - G4 (SHA384WithECCp384)
Symantec Class 3 Public Primary Certification Authority - G6 (SHA384WithRSA4096)

Comment 2

[Kathleen Wilson]

Please point me to the website where I can download these roots and find their test websites.

Also, please confirm that 
https://www.symantec.com/content/en/us/about/media/repository/stn-cp.pdf
and
https://www.symantec.com/content/en/us/about/media/repository/stn-cps.pdf
cover these two roots and their CA hierarchies.

Please also describe the current and future/allowed CA hierarchy for each of these roots.

Comment 3

[Kathleen Wilson]

Suhasini, please also update this bug with the information requested in Comment #2.

Comment 4

[Paul Rubin]

Google is dropping a Symantec class 3 certificate from Chrome and Android.  I hope it's not the same one being added here.  More info:

https://googleonlinesecurity.blogspot.com/2015/12/proactive-measures-in-digital.html

Comment 5

[Kathleen Wilson]

(In reply to Paul Rubin from comment #4)
> Google is dropping a Symantec class 3 certificate from Chrome and Android. 
> I hope it's not the same one being added here.  More info:
> 
> https://googleonlinesecurity.blogspot.com/2015/12/proactive-measures-in-
> digital.html

Correct, it's not the same root. Firefox already does not trust that root certificate for SSL certificate validation.  

Here's the details...

> Further Technical Details of Affected Root:
> Friendly Name: Class 3 Public Primary Certification Authority
> Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
> Public Key Hash (SHA-1): E2:7F:7B:D8:77:D5:DF:9E:0A:3F:9E:B4:CB:0E:2E:A9:EF:DB:69:77
> Public Key Hash (SHA-256):
> B1:12:41:42:A5:A1:A5:A2:88:19:C7:35:34:0E:FF:8C:9E:2F:81:68:FE:E3:BA:18:7F:25:3B:C1:A3:92:D7:E2
>
I cannot find record of this root. It's possible that we removed it a while ago, or never directly included it.


> MD2 Version
> Fingerprint (SHA-1): 74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2
> Fingerprint (SHA-256): E7:68:56:34:EF:AC:F6:9A:CE:93:9A:6B:25:5B:7B:4F:AB:EF:42:93:5B:50:A2:65:AC:B5:CB:60:27:E4:4E:70
>
1024-bit root -- Websites trust bit turned off in Firefox 32.
Reference: https://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/

> SHA1 Version
> Fingerprint (SHA-1): A1:DB:63:93:91:6F:17:E4:18:55:09:40:04:15:C7:02:40:B0:AE:6B
> Fingerprint (SHA-256): A4:B6:B3:99:6F:C2:F3:06:B3:FD:86:81:BD:63:41:3D:8C:50:09:CC:4F:A3:29:C2:CC:F0:E2:FA:1B:14:03:05
1024-bit root -- Websites trust bit turned off in Firefox 32.
Reference: https://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/

Comment 6

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #1)
> The Symantec-branded Class 1 and Class 2 roots will be handled in Bug
> #833986.
> 
> This bug is for the Symantec-branded Class 3 roots.
> Symantec Class 3 Public Primary Certification Authority - G4
> (SHA384WithECCp384)
> Symantec Class 3 Public Primary Certification Authority - G6
> (SHA384WithRSA4096)

The status of this request is that we are waiting for a representative of Symantec to provide the information requested in Comment #2.

Comment 7

[Rick Andrews]

> Please point me to the website where I can download these roots and find their test websites.
Please note that the roots are available to download from the Symantec roots page at https://www.symantec.com/page.jsp?id=roots
Test Sites:
o Symantec Class 3 Public Primary Certification Authority - G4 (SHA384WithECCp384) - https://ssltest36.ssl.symclab.com
o Symantec Class 3 Public Primary Certification Authority - G6 (SHA384WithRSA4096) - https://ssltest38.ssl.symclab.com

> Also, please confirm that 
> https://www.symantec.com/content/en/us/about/media/repository/stn-cp.pdf
> and
> https://www.symantec.com/content/en/us/about/media/repository/stn-cps.pdf
> cover these two roots and their CA hierarchies.
Yes, the Symantec CP and CPS docs at the links you provided cover these two roots and their CA hierarchies. Note that these are new roots and will be covered in our next audit.

> Please also describe the current and future/allowed CA hierarchy for each of these roots.
We intend to issue TLS and Code Signing certs from these roots.

Comment 8

[Kathleen Wilson]

Attachment: 1099311-CAInformation.pdf

I have entered the information for this request into Salesforce.

Please review the attached document to make sure it is accurate and complete, and comment in this bug to provide corrections and the additional requested information (search for NEED in the attached document).

Comment 9

[Rick Andrews]

Kathleen, one of the requests in  the CAInformation document is "NEED all errors resolved for
https://certificate.revocationcheck.com/ssltest38.ssl.symclab.com".

When I visit that site, I can't easily see the difference between errors and warnings. It appears that they are color-coded, and I'm red-green deficient. I often have difficulty with user interfaces that convey information solely by color differences. Are the differences conveyed by the color of the text, or the color of the background? Can someone please tell me what errors are reported on the page, or (long term) modify the page to not rely only on color?

Comment 10

[Kathleen Wilson]

(In reply to Rick Andrews from comment #9)
> Kathleen, one of the requests in  the CAInformation document is "NEED all
> errors resolved for
> https://certificate.revocationcheck.com/ssltest38.ssl.symclab.com".
> 
> When I visit that site, I can't easily see the difference between errors and
> warnings. It appears that they are color-coded, and I'm red-green deficient.
> I often have difficulty with user interfaces that convey information solely
> by color differences. Are the differences conveyed by the color of the text,
> or the color of the background? Can someone please tell me what errors are
> reported on the page, or (long term) modify the page to not rely only on
> color?

Usually the errors on this page begin with "X", but this one is different...

Scroll down to the last part of
https://certificate.revocationcheck.com/ssltest38.ssl.symclab.com

It says:
""
Symantec Class 3 EV SSL CA - G4 (CA Certificate)
This certificate was cached at Monday, 11 July 2016 20:38 UTC
Certificate details for Symantec Class 3 EV SSL CA - G4
(At position 1 in certificate chain)
Serial number:
hex: 5398d1998c7cbf2310c0f999a0051833
int: 111119403961640049927576911692601563187
Issued by: Symantec Class 3 Public Primary Certification Authority - G6
Public Key Algorithm: RSA
Not valid before: Thursday, 7 January 2016 00:00 UTC
Not valid after: Tuesday, 6 January 2026 23:59 UTC
Organization: Symantec Corporation
Organization unit: Symantec Trust Network
Country: US

We could not identify the issuer for this certificate <-- *** THIS IS THE ERROR ***

    This certificate does not contain any links to an LDAP server
    This certificate does not contain any internal server links
    This certificate does not contain any links with an unknown format

This certificate contains no information about authoritative CRL(s) or OCSP servers
""

Comment 11

[Rick Andrews]

Kathleen, is that page unable to identify the issuer of the certificate because it's not yet in your trust store? The point of this bug is to add this and other roots to Mozilla's trust store.

Comment 12

[Kathleen Wilson]

(In reply to Rick Andrews from comment #11)
> Kathleen, is that page unable to identify the issuer of the certificate
> because it's not yet in your trust store? 

I have manually imported the root cert, so that shouldn't be the problem. Also, I think the website does the checks independent of the browser.

I will ask the creator of the revocationcheck website about this error.

Comment 13

[Steven Medin]

(In reply to Kathleen Wilson from comment #8)
> Created attachment 8710755 [details]
> 1099311-CAInformation.pdf
> 
> I have entered the information for this request into Salesforce.
> 
> Please review the attached document to make sure it is accurate and
> complete, and comment in this bug to provide corrections and the additional
> requested information (search for NEED in the attached document).

Root Case Record # 1 - Symantec Class 3 Public Primary Certification Authority – G4 – ECC – ECC P-384
CA Hierarchy

NEED CA to confirm if this is accurate: This root will be used to sign internally-operated Class 3 SubCAs that will issue TLS/SSL certificates
>>> CA response: Yes, confirmed.
 
Externally Operated SubCAs
NEED CA to confirm if this is accurate: This root does not and will not have any subCAs that are operated by external third parties.
>>> CA response: Yes, confirmed.
 
Cross Signing
NEED CA to confirm this is accurate: None, and none planned.
>>> CA response: Yes, confirmed.
 
Technical Constraint on 3rd party Issuer
 
NEED: If external RAs or subCAs may directly cause
the issuance of certificates in this CA Hierarchy, then
need CP/CPS documentation describing the technical
and contractual controls over any 3rd party who may
issue certs in this CA Hierarchy.
References:
- section 7.1.5 of version 1.3 of the CA/Browser Forum's
Baseline Requirements
- https://www.mozilla.org/en-US/about/governance
/policies/security-group/certs/policy/inclusion/
- https://wiki.mozilla.org
/CA:CertificatePolicyV2.1#Frequently_Asked_Questions
 
>>> CA response: NA
 
Root Case Record # 2 - Symantec Class 3 Public Primary Certification Authority - G6 - SHA-384 - 4096
CA Hierarchy

NEED CA to confirm if this is accurate: This root will be used to sign internally-operated Class 3 SubCAs that will issue TLS/SSL certificates
>>> CA response: Yes, confirmed.
 
Externally Operated SubCAs
NEED CA to confirm if this is accurate: This root does not and will not have any subCAs that are operated by external third parties.
>>> CA response: Yes, confirmed.
 
Cross Signing
NEED CA to confirm this is accurate: None, and none planned.
>>> CA response: Yes, confirmed.
 
Technical Constraint on 3rd party Issuer
 
NEED: If external RAs or subCAs may directly cause
the issuance of certificates in this CA Hierarchy, then
need CP/CPS documentation describing the technical
and contractual controls over any 3rd party who may
issue certs in this CA Hierarchy.
References:
- section 7.1.5 of version 1.3 of the CA/Browser Forum's
Baseline Requirements
- https://www.mozilla.org/en-US/about/governance
/policies/security-group/certs/policy/inclusion/
- https://wiki.mozilla.org
/CA:CertificatePolicyV2.1#Frequently_Asked_Questions
 
>>> CA response: NA
 
Revocation Tested
NEED all errors resolved for
https://certificate.revocationcheck.com/ssltest38.ssl.symclab.com

>>> CA response: this issue is pending resolution in progress discussed in comment #12

Comment 14

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #10)
> Usually the errors on this page begin with "X", but this one is different...
> 
> Scroll down to the last part of
> https://certificate.revocationcheck.com/ssltest38.ssl.symclab.com
> 
> We could not identify the issuer for this certificate <-- *** THIS IS THE
> ERROR ***
> 

In this case, have to test as follows.

https://certificate.revocationcheck.com/ -> Certificate Upload 
Copy the PEM for the root cert into the "Certificate" box.
Copy the OCSP url into the "OCSP Server (* optional)" box.

Now I've done that with the two Symantec certs, but I get errors like the following in Get and POST. 
x  The Cache-Control max-age header outlives NextUpdate with 1m29s
x  The Cache-Control max-age header outlives NextUpdate with 3m43s

Root Certificate Download URL   
https://www.symantec.com/content/en/us/enterprise/verisign/roots/VeriSign-Class-3-Public-Primary-Certification-Authority-G4.pem
OCSP URL(s)   
http://s.symcd.com  -- don't get the error with this one
http://rf.symcd.com -- Do get the errors with this one***
Test website: https://ssltest36.ssl.symclab.com/

Root Certificate Download URL   
https://www.symantec.com/content/en/us/enterprise/verisign/roots/Symantec_Class_3_Public_Primary_Certification_Authority_G6.pem
OCSP URL(s)   
http://s.symcd.com - don't get the errors with this one
http://rg.symcd.com -- Do get the errors with this one***
Test website: https://ssltest38.ssl.symclab.com/

I asked Paul what this means, and here's his response:
"That means that the cache instructions in the cache-control header exceed the validity of the response.
Say that a repose is still valid for 9.5 hours, but it’s intrusted to cache for 10 hours, users will get an expired (cached) response for an half hour.
In this case it’s only a few minutes but the challenge is that the value is often set by the origin while the request is served by a CDN who is not recalculating the value based on the expires value of the response. In this case it’s just a few minutes, but in an hour you could have a value of an hour. This also depends on the CDN cache times. Often it’s easier to remove the max-age value from the cache control header and rely on the expires and last-modified headers for caching."

Comment 15

[Aaron Wu]

Attachment: Symantec_Class3.pdf

Comment 16

[Aaron Wu]

Hi,

We've done of information verification, please check comment #15 and feedback if any question.


There is one error in CA/Browser Forum Baseline Test
ERROR : Subject with organizationName but without stateOrProvince or localityName

his requirement applies to all CA certs that are created after the first BR Effective Date of 01-Jul-2012. In general, CAs should not be requesting inclusion of CA certs created before that date. 
Note: It is not clear if all of section 7.1.4.2.2 is meant to apply to root certificates. It definitely applies to intermediate and end-entity certificates.

BR : https://cabforum.org/baseline-requirements-documents/

Please clarify this error, thank you!

Comment 17

[Rick Andrews]

Aaron, I disagree with you. Section 7.1.4.2.2 (and all subsections of 7.1.4.2) apply only to end-entity certificates, not roots or intermediates. I agree that it could be more clear. Here's my reasoning: Section 7.1.4.2.1 says that SANs are Required, and roots and ICAs never contain SANs.

Also, roots are covered in Section 7.1.2.1, and intermediates are covered in 7.1.2.2. Section 7.1.2.1 ("Root CA Certificate") says:
 Certificate Subject MUST contain the following:
‐ countryName (OID 2.5.4.6). This field MUST contain the two‐letter ISO 3166‐1 country code for the country in which the CA’s place of business is located.
‐ organizationName (OID 2.5.4.10): This field MUST be present and the contents MUST contain either the Subject CA’s name or DBA as verified under Section 3.2.2.2. The CA may include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows “Company Name Incorporated”, the CA MAY use “Company Name Inc.” or “Company Name”.

There's no requirement for State or Locality to be included in a root's Subject DN.

Comment 18

[Kathleen Wilson]

(In reply to Rick Andrews from comment #17)
> Aaron, I disagree with you. Section 7.1.4.2.2 (and all subsections of
> 7.1.4.2) apply only to end-entity certificates, not roots or intermediates.


That is not clear to me, so I posted the question in the mozilla.dev.security.policy forum.
https://groups.google.com/d/msg/mozilla.dev.security.policy/yV84X0xkkEo/cPyt4G7YCQAJ

Comment 19

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #18)
> (In reply to Rick Andrews from comment #17)
> > Aaron, I disagree with you. Section 7.1.4.2.2 (and all subsections of
> > 7.1.4.2) apply only to end-entity certificates, not roots or intermediates.
> 
> 
> That is not clear to me, so I posted the question in the
> mozilla.dev.security.policy forum.
> https://groups.google.com/d/msg/mozilla.dev.security.policy/yV84X0xkkEo/
> cPyt4G7YCQAJ


There is consensus in m.d.s.policy that section 7.1.4.2 of the BRs only applies to end-entity certificates.

I have updated the wiki page to reflect this:
https://wiki.mozilla.org/CA:TestErrors#CA.2FBrowser_Forum_Baseline_Requirements_Errors

And I filed a request to update the x509lint tool:
https://github.com/kroeckx/x509lint/issues/18

Comment 20

[Aaron Wu]

Attachment: Symantec_Class3_final.pdf

Comment 21

[Aaron Wu]

Hi Rick,

Please see the final verified CA document as Comment#20 and see if all information are correct. 

Once you have no problem with Final document, we are ready for public discussion.

Thanks,
Aaron

Comment 22

[Steven Medin]

Hi Aaron,

The only change I would suggest is to update the audit references to match the information in the CA Community in Salesforce.

Thanks,
Steve

Comment 23

[Aaron Wu]

Hi Steve,

https://cert.webtrust.org/SealFile?seal=1565&file=pdf
Note: This new root will be covered in the next audit.

Is the new audit for Standard/BR/EV available?

Thanks,
Aaron

Comment 24

[Steven Medin]

Per https://mozillacacommunity.force.com/001o000000rGWTF and https://mozillacacommunity.force.com/001o000000rGWSv:

https://www.symantec.com/content/en/us/about/media/repository/1_symantec_stn_wtca_6-15-2016.pdf
https://www.symantec.com/content/en/us/about/media/repository/4_symantec_stn_wtbr_6-15-2016.pdf
https://www.symantec.com/content/en/us/about/media/repository/7_symantec_stn_wtev_6-15-2016.pdf

Comment 25

[Aaron Wu]

Thanks Steve!

All information are verified and updated in Salesforce, ready for Public Discussion.

Comment 26

[Peter Gervai]

Bug 1334377 may be interesting (popped up here by searching for symantec)

Comment 27

[Kathleen Wilson]

Steven,

Please perform the BR Self Assessment, and attach the resulting BR-self-assessment document to this bug.

Note:
Current version of the BRs: https://cabforum.org/baseline-requirements-documents/
Until a version of the BRs is published that describes all of the allowed methods of domain validation, use version 1.4.1 for section 3.2.2.4 (Domain validation): https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

= Background = 

We are adding a BR-self-assessment step to Mozilla's root inclusion/change process.

Description of this new step is here:
https://wiki.mozilla.org/CA:BRs-Self-Assessment

It includes a link to a template for CA's BR Self Assessment, which is a Google Doc:
https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing

Phase-in plan is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y-PxWRCIcck/Fi9y6vOACQAJ
In particular, note:
+ For the CAs currently in the queue for discussion, I would ask them to perform this BR Self Assessment before I would start their discussion.

Comment 28

[Kathleen Wilson]

Closing as WONTFIX, per https://wiki.mozilla.org/CA:Symantec_Issues etc.

Symantec will need to create a new Bugzilla Bug when they are ready to request inclusion of their new root certs.
https://wiki.mozilla.org/CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request