409237 - add new Thawte root CA certificate

Status: RESOLVED FIXED

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

Description

[Jay Schiavo]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Build Identifier: 

Please accept the attached thawte root certificate for inclusion in Firefox. 

This CA will be used to sign certificates for SSL-enabled servers, and may
in the future be used to sign certificates for digitally-signed executable code
objects.

Name of the CA certificate is thawte Primary Root - G2

The CPS is at http://www.thawte.com/cps/index.html

Attestation of our conformance to the stated verification requirements can be
found here: http://www.thawte.com/repository/index.html (Click on the
"AICPA/CICA WebTrust for Certification Authorities Audit Report" link)


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Jay Schiavo]

Attachment: thawte root certificate for inclusion in FireFox

The attached file contains a thawte root certificate for inclusion in FireFox.

Comment 2

[David E. Ross]

Please note that certificates go into Mozilla's NSS database, which is used by a number of Mozilla products and such derived products as SeaMonkey.  A reference to Firefox is incorrect.  I'll leave this to Hecker to correct the Summary.  

Comment 3

[Jay Schiavo]

Attachment: Letter from KPMG regarding thawte's ECC roots

Letter from KPMG stating that our annual WebTrust for CAs reports for the VeriSign, Thawte and GeoTrust brands (most recently covering the period ending November 30, 2007) cover the effectiveness of CA controls including the CA key generation process based on the WebTrust for CAs criteria.

Comment 4

[Jay Schiavo]

The thawte CPS has been updated to include this root:
 
https://www.thawte.com/ssl-digital-certificates/free-guides-whitepapers/pdf/Thawte_CPS_3_6.pdf 
Section 1.3.1 , 4.4.9

thawte Primary Root CA – G2 was added

Comment 5

[Frank Hecker]

Accepting this bug and putting it into the queue with the other CA requests. At present I cannot say for certain exactly when we will be able to process this.

Comment 6

[Rick Andrews]

I have set up a public-facing web server with this root and an SSL cert signed by it (also with an ECC key). The url is https://ecc-test-valid.thawte.com. I'm not sure if the name is in DNS yet, so you can also hit it at https://205.180.234.252.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

FYI, If I add the following entries to my etc/hosts file:

205.180.234.250 ecc-test-valid.verisign.com
205.180.234.252 ecc-test-valid.thawte.com
205.180.234.253 ecc-test-valid.geotrust.com

and then download and import the root CA cert which is attached to this bug 
into my cert DB and mark it trusted for SSL, and then visit the test URL 
given above in this bug (https://ecc-test-valid... ),
it works for me.  :)

If I view the server and root CA certs in the cert viewer (by click on the 
browser's lock icon in the lower right hand corner of the window chrome),
the browser has no trouble displaying them.

Comment 8

[Kathleen Wilson]

Attachment: Root CA as a .cer file

Comment 9

[Frank Hecker]

Reassigning to Kathleen Wilson to do information gathering.

Comment 10

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

I have been asked to do the information gathering and verification for this request as per http://wiki.mozilla.org/CA:Information_checklist.  The attached document provides a summary of the information that has been gathered and verified so far. I have the following questions and request for further information:

1) Can you provide a public URL to the CRL for this root?

2) If applicable, please provide OCSP responder URL. (I don’t think this is applicable)

3) The requested Trust Bits for this root are Websites (SSL/TLS) and Code Signing.  Not email.  Correct?

4) Please provide a certificate hierarchy diagram and/or description for the sub-CA’s (current or planned) for this root.

a) List or description of subordinate CAs operated by the CA organization associated with the root CA. (For example, this might include subordinate CAs created to issue different classes or types of end entity certificates: Class 1 vs. class 2 certificates, qualified vs. non-qualified certificates, SSL certificates vs. email certificates, and so on.)
For internally-operated subordinate CAs the key is to confirm that their operation is addressed by the relevant CPS, and that any audit covers them as well as the root.

b) For subordinate CAs operated by third parties, if any: 
General description of the types of third-party subordinates that exist, and what the general legal/technical arrangements are by which those subordinates are authorized, controlled, and audited.
(For example, contractual arrangements should require third-party subordinates to operate in accordance with some CPS/CP. Technical arrangements might include name constraints, not allowing them to create their own subordinates, etc.) 

c) List any other root CAs that have issued cross-signing certificates for this root CA


Also, Will SSL123 or WildCard certs be able to chain up to this root?

Thanks,
Kathleen

Comment 11

[Rick Andrews]

1) Can you provide a public URL to the CRL for this root?
Not at this time, since we do not actively issue certificates from this root. We're trying to get this root in Firefox in anticipation of a market in the near future.

2) If applicable, please provide OCSP responder URL. (I don’t think this is
applicable)
This is not applicable since this is a root certificate. We will provide OCSP Responder URLs for certificates signed by this root.

3) The requested Trust Bits for this root are Websites (SSL/TLS) and Code
Signing.  Not email.  Correct?
Correct.

Comment 12

[Rick Andrews]

4) Please provide a certificate hierarchy diagram and/or description for the
sub-CA’s (current or planned) for this root.

a) List or description of subordinate CAs operated by the CA organization
associated with the root CA. (For example, this might include subordinate CAs
created to issue different classes or types of end entity certificates: Class 1
vs. class 2 certificates, qualified vs. non-qualified certificates, SSL
certificates vs. email certificates, and so on.)
For internally-operated subordinate CAs the key is to confirm that their
operation is addressed by the relevant CPS, and that any audit covers them as
well as the root.
Planned sub-CAs:
  Class 3 Secure Server CA (standard SSL certificates)
  Class 3 Secure Intranet Server CA (intranet SSL certificates)
  Class 3 Extended Validation SSL CA (EV SSL certificates)
  Class 3 Code Signing (EV and non-EV Code Signing certificates)
  OnSite Administrator CA - Class 3 (Enterprise portal Admin certificates)
  Class 3 Open Financial Exchange CA - G2 (OFX SSL certificates)
  Time Stamping Authority CA (time stamping certificates)
  Class 3 Mobile CA (authentication of servers in the mobile space)
  Class 3 WLAN CA (for Microsoft RADIUS/IAS servers)
  Class 3 Organizational CA (S/MIME certs for organizations)

b) For subordinate CAs operated by third parties, if any: 
General description of the types of third-party subordinates that exist, and
what the general legal/technical arrangements are by which those subordinates
are authorized, controlled, and audited.
(For example, contractual arrangements should require third-party subordinates
to operate in accordance with some CPS/CP. Technical arrangements might include
name constraints, not allowing them to create their own subordinates, etc.) 
This is n/a for this root.

c) List any other root CAs that have issued cross-signing certificates for this
root CA
This is n/a for this root.

Comment 13

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 14

[Kathleen Wilson]

The information gathering phase of this request is complete. Assigning bug to
Frank so he can proceed with the next phase.

I will update the pending list to include this root. There will be a slight
delay before the changes are visible.

Thanks,
Kathleen

Comment 15

[Frank Hecker]

Re-assigning this bug to Kathleen Wilson, since she'll be the person actively working on it.

Comment 16

[Jay Schiavo]

Here are Verisign's responses to the questions in the information gathering
document:

- test URL: ecc-test-valid.thawte.com

- CRLs for the EE certs issued off these roots?
[Verisign] We do not have any CRLs at this time because we're not issuing off
these roots yet.

- Can SSL123 be issued under this root?
[Verisign] We do plan to issue SSL123 certs off a Sub CA chained to this root.

- Will we support OCSP for certs issued off these roots?
[Verisign] Yes, certs issued off this root will support OCSP.

- Are you requesting EV support for this root?
[Verisign] Not at this time. We will open up separate requests for that.

- Provide hierarchy for these roots. 
[Verisign]We will have these roots offline and create sub CAs that issue the EE
certs. See comment #12 from Rick Andrews.

- Do we allow 3rd parties to operate sub CAs for thawte?
[Verisign] We do not allow 3rd party to operate sub CAs for thawte.

- Have these roots been involved in cross signing?
[Verisign] No, because we haven't begun using them yet.

- Does thawte use CRLs with critical CIDP extensions?
[Verisign] The Thawte CRLs do not use extensions at all.

- Do we use OCSP responses signed by a cert under a different root for thawte?
[Verisign] We don't use these roots yet, but our practice is to sign OCSP
responses with a cert signed by the same root (the one that signed the
end-entity cert in question).

- Does thawte allow external entities to operate an unconstrained sub CA
[Verisign] No.

Comment 17

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 18

[Kathleen Wilson]

I am now opening the first public discussion period for two requests from Thawte:

Bug #409237: Add Thawte's ECC root (thawte Primary Root CA - G2) and enable the Websites and Code trust bit.

Bug #484903: Add Thawte's SHA256, 2048-bit root (thawte Primary Root CA - G3) and enable the Websites and Code trust bit.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding [e-mail] mailing list.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “Thawte Root Inclusion Request”

Please actively review, respond, and contribute to the discussion.

Comment 19

[Kathleen Wilson]

The public comment period for this request is now over. 

This request has been evaluated as per sections 1, 5 and 15 of the official CA policy at

 http://www.mozilla.org/projects/security/certs/policy/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request to add the “thawte Primary Root CA - G2” root certificate to NSS and enable the Websites and Code Signing trust bits.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by Thawte, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy]. Thawte appears to provide a service relevant to Mozilla users:  It is a commercial CA with worldwide operations. Thawte is a subsidiary of VeriSign.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list; the main document of interest is the CPS, which is provided in English.

http://www.thawte.com/cps/index.html

Section 7 [Validation]. Thawte appears to meet the minimum requirements for subscriber verification, as follows:

* Email: Not applicable -- not requesting the email trust bit.

* SSL:  Domain Name Verification is described in sections 1.1 and 3.1.8 of the CPS. For High Assurance certificates (both domain and organization validated), thawte authenticates the Organization’s right to use that domain name. For Medium Assurance certificates (only domain validated) Thawte sends an email to either one of the contact email addresses on the whois db or one of the pre-approved generic options. The user must follow a link in the email and either approve or reject the cert request.

* Code: Verification procedures for Code Signing certificates are described in section 3.1.8 of the CPS. Thawte confirms the identity of a Certificate Applicant for a Code Signing Certificate by verifying that the organization exists through the use of at least one third party identity proofing service or database. Thawte confirms with an appropriate Organizational contact that the person submitting the Certificate Application on behalf of the Organization is authorized to do so.

Section 8-10 [Audit]. Section 8-10 [Audit]. Thawte’s audits have been performed within the past year by KPMG, and the audit reports are posted on cert.webtrust.org.  The WebTrust CA audit report covers this root. 

Section 13 [Certificate Hierarchy]. Thawte will have this root offline and create sub CAs that issue end-entity certificates for SSL and Code Signing.

Other: 
* CRL: According to section 4.4.9 of Thawte’s CPS, For end-entity certs, the CRLs are issued “At Least Daily”
** Thawte is not yet actively issuing certs from this root, so no CRL exists yet.
* OCSP: not provided , but in plan.

Potentially Problematic Practices:

* Long-lived DV SSL certs: CPS footnote to table 22: There is no requirement to reverify the Distinguished Name of 4 and 5 year SSL123 certificates during the validity period of the certificate.
** Thawte has committed to updating this practice to meet the CAB/Forum guidelines when they are provided.

* Certificates referencing host names or private IP address: SSL123 for Intranet Certificate: thawte validates that the Server or Intranet name or IP are not publicly accessible via the World Wide Web. When an IP address is used thawte validates that the IP address is within the private range for intranets as specified by RFC 1597
** Thawte has committed to updating this practice to meet the CAB/Forum guidelines when they are provided.

There are two Action Items that resulted from the discussion. These will be tracked separately in bug #484903, and approval/inclusion may proceed in parallel.

ACTION: Thawte will remove the following email addresses from their list of options for domain validated certs: is, it, mis, ssladministrator, sslwebmaster. Thawte has committed to notifying their customers according to their 6-month SLAs, and then complete the changes in the February/March 2010 timeframe.

ACTION: Thawte will update their list to meet the CAB/Forum guidelines of acceptable email addresses for domain validated certs, when the CAB/Forum guidelines are provided.

Based on this assessment I intend to approve this request to add the “thawte Primary Root CA - G2” root certificate to NSS and enable the Websites and Code Signing trust bits.

Comment 20

[Kathleen Wilson]

To the representatives of Thawte: Thank you for your cooperation and your
patience.

To all others who have commented on this bug or participated in the public
discussion: Thank you for volunteering your time to assist in reviewing this CA
request.

As per the summary and recommendation in Comment #19, and on behalf of the
Mozilla project I approve this request from Thawte to include the following
root certificate in Mozilla, with trust bits set as indicated:

* thawte Primary Root CA - G2 (web sites, code signing)

I will file the NSS bug to effect the approved changes.

Comment 21

[Kathleen Wilson]

I have filed bug 521869 against NSS for the actual changes.

Comment 22

[Kathleen Wilson]

Confirmed that this root is a Builtin Object Token in Firefox 3.6.