601950 - Turn on the code signing trust bit for the Thawte Primary Root CA

Status: RESOLVED FIXED

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

Description

[Tony Berman]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; InfoPath.1; MS-RTC LM 8)
Build Identifier: 

When this root was added to the Mozilla root store, the code signing trust bit was not turned on for the thawte Primary Root CA.


Reproducible: Always

Steps to Reproduce:
When encountering a Code in Firefox that chains to the Thawte Primary Root CA a  message is displayed indicating that the root is not recognized for recognizing software makers

Comment 1

[Kathleen Wilson]

I see that only the websites trust bit was turned on for the G1 root:
https://bugzilla.mozilla.org/show_bug.cgi?id=407163#c28

Both the code signing and websites trust bits were enabled for the G2 an G3 roots:
http://www.mozilla.org/projects/security/certs/included/#thawte

Enabling a trust bit follows the same process as doing a new root inclusion request:
https://wiki.mozilla.org/CA:How_to_apply#Frequently_Asked_Questions

I'll begin the Information Gathering and Verification process soon.

https://wiki.mozilla.org/CA:How_to_apply#Timeline

Comment 3

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

The attached document summarizes the information that has been gathered and
verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 4

[Tony Berman]

Attachment: Response to request for more information

Response to requst for more information is being loaded as an attachment

Comment 5

[Kathleen Wilson]

Thanks for the information.

In regards to DV, please point me to the documentation stating which email addresses may be used for verification (e.g. the email challenge-response to confirm ownership of the domain name).
https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs

Also, what is the status of this action item:
https://bugzilla.mozilla.org/show_bug.cgi?id=484903#c16

Comment 6

[Kathleen Wilson]

Also, please note that we view long-lived DV certs as problematic. I expect that within the next year the Mozilla CA Certificate Policy will be updated to limit the maximum validity of DV certs. I expect that the maximum will be quite a bit less than 5 years.
https://wiki.mozilla.org/CA:CertPolicyUpdates#First_Phase

Comment 7

[Tony Berman]

(In reply to comment #5)
VeriSign Response: Bug 484903: I updated to advise that the required updates were made in July 2010
The following article describes the acceptable e-mail aliases: https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO5555&actp=search&viewlocale=en_US&searchid=1287593215908 
> Thanks for the information.
> In regards to DV, please point me to the documentation stating which email
> addresses may be used for verification (e.g. the email challenge-response to
> confirm ownership of the domain name).
> https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs
> Also, what is the status of this action item:
> https://bugzilla.mozilla.org/show_bug.cgi?id=484903#c16

Comment 8

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 9

[Kathleen Wilson]

This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Now that you have a request in the Queue for Public Discussion, you are
directly impacted by the time it takes to work through the queue. The goal is
to have each discussion take about one to two weeks. However, that time varies
dramatically depending on the number of reviewers contributing to the
discussion, and the types of concerns that are raised. If no one reviews and
contributes to a discussion, then a request may be in the discussion for
several weeks. When there are not enough people contributing to the discussions
ahead of yours, then your request will sit in the queue longer.

How can you help reduce the time that your request sits in the queue?

You can help by reviewing and providing your feedback in the public discussions
of root inclusion requests, or by asking a knowledgeable colleague to do so.

Participating in other discussions is a great way to learn the expectations and
be prepared for the discussion of your request.

Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Comment 10

[Miroslav Pavleski]

We encountered this bug today when we tried to use a newly obtained code-signing certificate for packing Firefox extensions. As of Firefox 3.6.13 this bug has not been resolved. Is there any schedule when this will be fixed ?

Comment 11

[Ivan A. Shmakov]

https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO16126

Comment 12

[Ivan A. Shmakov]

1) Save own certificate without parrent certificate tree.
2) Thawte send updated "Thawte Code Signing CA - G2 - Thawte Consulting cc”,
certificate that change root certificate from "thawte Primary Root CA" to
"Thawte Primary Server CA", that I add to *.db before signing XPI.
(https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO16126)

Now FF install XPI till "thawte Primary Root CA" will allows to install XPI
with out any manipulation (bug 601950).

Comment 13

[Miroslav Pavleski]

Thank you very much Ivan. Your guidelines solved the problem !

Comment 14

[Mike Kaply [:mkaply]]

For other people seeing this problem and reading this bug, I want to provide more detail.

I use IE to do my initial creation of the PFX file since that's what Thawte says to do.

After importing your cert into IE, export the PFX file but do NOT check the box to include all the certificates in the certification path.

Create a new cert database using

certutil -N -d .

use pk12util to import your certificate

pk12util -i {filename}.pfx -d .

Download the new thawte cert from here and save it 

https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO16126

Then import it into the database:

certutil -t "c,c,C" -n "thawte" -A -d .< new_thawte.cer

You should now be able to sign your XPI

Comment 15

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 16

[Kathleen Wilson]

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

Bug #539257: Enable EV for the “thawte Primary Root CA - G3” root certificate.

Bug #601950: Turn on the code signing trust bit for the “thawte Primary Root CA” root certificate.

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 “Symantec/Thawte EV and Trust Bit Change Request”

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

Comment 17

[Kathleen Wilson]

The public comment period for this request is now over. 

This request has been evaluated as per Mozilla’s CA Certificate 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 turn on the code signing bit for the “thawte Primary Root CA” root certificate.

Section 4 [Technical]. I am not aware of instances where Symantec has 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].  Symantec appears to provide a service relevant to Mozilla users; it is a commercial CA serving customers worldwide, and operates various thawte-branded CAs.

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

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

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

* Email: Thawte has not requested that the email trust bit be turned on for the thawte Primary Root CA.

* SSL: Thawte has two levels of verification for SSL certificates, High Assurance (both the Organization and the domain are verified) and Medium Assurance (only the domain is verified, not the organization). According to CPS Section 3.1.8.1, For High Assurance certificates, where a domain name is included in the certificate thawte authenticates the Organization’s right to use that domain name. For DV SSL certificates, thawte validates the Certificate Applicants control of a domain by requiring the person to answer an e-mail sent to the e-mail address listed or predetermined for that domain.  As outlined in CPS Appendix A1,  verification procedures for EV SSL certificates are in accordance with the EV guidelines.

* Code:  According to CPS Section 3.1.8.1: Thawte confirms the identity and authority of a Certificate Applicant for Code Signing Certificate. Thawte verifies that the organization exists through the use of at least one third party identity proofing service or database, or alternatively, organizational documentation issued by or filed with the applicable government that confirms the existence of the organization. Thawte also confirms with an appropriate Organizational contact by telephone, postal mail, or a comparable procedure certain information about the organization, that the organization has authorized the Certificate Application, and that the person submitting the Certificate Application on behalf of the Organization is authorized to do so.

EV Policy OID: 2.16.840.1.113733.1.7.23.6

Section 15 [Certificate Hierarchy]. 
The “thawte Primary Root CA” root certificate has the following internally-operated intermediate certificates, which issue end-entity certs: thawte Extended Validation SSL CA, thawte Extended Validation SSL SGC CA, Thawte SSL CA, Thawte DV SSL CA, Thawte Code Signing CA – G2

* Both CRL and OCSP are provided 
** CPS 4.4.9 CRL Issuance Frequency: For end-entity certs, the CRLs are issued “At Least Daily”
** CPS Appendix A1: For EV Certificates … (OCSP) is updated at least every four (4) days, and with a maximum expiration time of ten (10) days.

Sections 9-11 [Audit]. Thawte’s audits are performed annually by KPMG and posted on the webtrust.org website: https://cert.webtrust.org/SealFile?seal=527&file=pdf 
This document contains two audit reports, one for WebTrust for CA and one for WebTrust for EV.

Based on this assessment I intend to approve this request to turn on the code signing bit for the “thawte Primary Root CA” root certificate.

Comment 18

[Kathleen Wilson]

To the representatives of Symantec: 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 in Comment #17, and on behalf of Mozilla I approve this request from Symantec to turn on the code signing trust bit for the “thawte Primary Root CA” root certificate.

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

Comment 19

[Kathleen Wilson]

I have filed bug #722843 for the actual changes in NSS.