484903 - Add thawte's SHA2 root

Status: RESOLVED FIXED

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

Description

[Jay Schiavo]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Build Identifier: 

Please accept the attached thawte root certificate for inclusion into Mozilla's NSS database. 

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 CA – G3

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

Comment 1

[Jay Schiavo]

Attachment: thawte's SHA2 root

The attached file contains thawte's 256 root CA.

Comment 2

[Kathleen Wilson]

Accepting this bug.

I will begin the Information Gathering and Verification phase soon as described in https://wiki.mozilla.org/CA:How_to_apply

In the meantime, please provide the information listed in
https://wiki.mozilla.org/CA:Information_checklist

Comment 3

[Kathleen Wilson]

Hi Jay,

There is another Thawte request in the queue for public discussion at
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
http://www.mozilla.org/projects/security/certs/pending/#thawte
https://bugzilla.mozilla.org/show_bug.cgi?id=409237

Does it make sense to combine these two requests into one public discussion? 
Or are they sufficiently different that they should be discussed separately?

For this request, please provide the information for this root as was provided for the other root in the Information Gathering Document. Note that the potentially problematic practices list has grown, so please review the new list
at http://wiki.mozilla.org/CA:Problematic_Practices

Thanks,
Kathleen

Comment 4

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

Attaching the initial information gathering document, which summarizes the data from both this request and from bug 409237.  The same CPS and audit cover both roots, so it’ll be more efficient to have one public discussion which covers both requests.

Please review the attached document and respond to the items that are highlighted in yellow. Please also review the rest of the information in the document for accuracy and completeness.

Please review the updated list of potentially problematic practices
http://wiki.mozilla.org/CA:Problematic_Practices
to indicate which of them are relevant for each root, and provide more information when relevant.

Comment 5

[Jay Schiavo]

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

- test URL: https://ptnr-thawte256.bbtest.net

- 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.

- 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 6

[Kathleen Wilson]

Thank you for the information.

> https://ptnr-thawte256.bbtest.net

I am unable to connect to this test site: Firefox can't establish a connection to the server at ptnr-thawte256.bbtest.net.

> We do plan to issue SSL123 certs off a Sub CA chained to this root.

CPS footnote to table 22: At a minimum, the Distinguished Name of 4 and 5 year validity SSL certificates is reverified after three years from date of issuance. There is no requirement to reverify the Distinguished Name of 4 and 5 year SSL123 certificates during the validity period of the certificate.

Please see/comment on 
https://wiki.mozilla.org/CA:Problematic_Practices#Long-lived_DV_certificates

Comment 7

[Jay Schiavo]

We checked with our network team and https://ptnr-thawte256.bbtest.net should be back up.

Long lived DV certs are an item that is being addressed in the CAB Forum with the creation of SSL minimum guidelines. We will certainly restrict the validity period offered with these certs based on those requirements.

Comment 8

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 9

[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 10

[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 - G3” 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 this bug, 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 - G3” root certificate to NSS and enable the Websites and Code Signing trust bits.

Comment 11

[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 #10, 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 - G3 (web sites, code signing)

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

Comment 12

[Kathleen Wilson]

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

Comment 13

[Kathleen Wilson]

Calling out the remaining action items, so this bug doesn't get closed until
the action items have also completed.

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.

Thawte, please post updates on the progress of these action items here, in
this bug.

Comment 14

[Kathleen Wilson]

I have confirmed that this root is now a Builtin Object Token in Firefox 3.6. However, this bug will remain open until Thawte has completed their action items as per Comment #13.

Jay, Please update this bug when Thawte has completed the action items.

Comment 15

[Kathleen Wilson]

Tony, Do you have an update on the first action item in Comment #13?

Comment 16

[Tony Berman]

(In reply to comment #13)

> 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.
> VeriSign: Thawte has started removing the specified aliases from different enrollment paths and expect to be be completed before the end of 2010.

Comment 17

[Tony Berman]

(In reply to comment #16)
> (In reply to comment #13)
> > 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.
> > VeriSign: Thawte has started removing the specified aliases from different enrollment paths and expect to be be completed before the end of 2010.


Thawte: These e-mail aliases have were removed for SSL123 certificates in JUly 2010