602107 - Turn on the code signing and email trust bits for the VeriSign Class 3 Public Primary Certification Authority - G5

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 VeriSign Class 3 Public Primary Certification Authority - G5




Reproducible: Always

Steps to Reproduce:
VeriSign CodeSigning is migrating very soon to the VeriSign Class 3 Public Primary Certification Authority - G5 root. When encountering a Code in Firefox that chains to this Root CA a
 message would be displayed indicating that the root is not recognized for
recognizing software makers.

Comment 1

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

[Tony Berman]

Attachment: Additional information

VeriSign answers hoighlighted in green attached

Comment 3

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 4

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

[Tony Berman]

Please can you also enable the e-mail trust bit for this root too. I refer you the VeriSign CPS for our policies http://www.verisign.com/repository/CPSv3.8.4_final.pdf 

Thanks
Tony

Comment 6

[Stefan Baebler]

Would it (as a temporary workaround until this bug is fixed and fix released) help to include intermediate CAs into the code signing certificate?

More precisely: If I include the "VeriSign Class 3 Public Primary Certification Authority - G5" (which is signed by "VeriSign Class 3 Public Primary Certification Authority", which has code signing bit set in Mozilla) into certificate trust chain of my signing certificate - would Mozilla respect the code signing bit from the first or the later certificate?

VefriSign's Intermediate code signing CAs: 
http://www.verisign.com/support/verisign-intermediate-ca/code-signing-intermediate/index.html

Comment 7

[Stefan Baebler]

Pinpointing the source code that should be changed:
http://hg.mozilla.org/mozilla-central/file/f2a2adaaacba/security/nss/lib/ckfw/builtins/certdata.txt#l12081
http://hg.mozilla.org/mozilla-central/file/f2a2adaaacba/security/nss/lib/ckfw/builtins/certdata.c#l12182

I noticed that in the source it is not explicitly untrusted, but "unknown trust". Now that information gathering is complete (according to current whiteboard status of the bug) couldn't this be changed either to untrusted or (more likely) to trusted?

Comment 8

[Stefan Baebler]

(In reply to Stefan Baebler from comment #6)
> Would it (as a temporary workaround until this bug is fixed and fix
> released) help to include intermediate CAs into the code signing certificate?
Confirming that YES, this workaround works fine, which makes this bug just a huge annoyance for software developers, who must jump hoops to get their jars and xpis signed the right way.

From a different point of view: not having the code signing trust bit set on this CA is NOT preventing code from execution, which could be a security issue.

Comment 9

[Kathleen Wilson]

(In reply to Tony Berman from comment #5)
> Please can you also enable the e-mail trust bit for this root too. I refer
> you the VeriSign CPS for our policies
> http://www.verisign.com/repository/CPSv3.8.4_final.pdf 
> 
> Thanks
> Tony


http://www.verisign.com/repository/CPS/ 
is still pointing to
http://www.verisign.com/repository/CPSv3.8.1_final.pdf

Comment 10

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #9)

Never mind -- I must have had the page cached. It reloaded and now points to the correct version.

Comment 11

[Kathleen Wilson]

(In reply to Tony Berman from comment #5)
> Please can you also enable the e-mail trust bit for this root too. 

Where is it described how Symantec verifies that the subscriber of a class 1 s/mime certificate owns/controls the email address to be included in the certificate?

Comment 12

[Rick Andrews]

Kathleen, look in the CPS under section 3.2.3, Authentication of Individual Identity. It says for Class 1 certs: "There is a limited confirmation of the Subscriber's email address by requiring the Subscriber to be able to answer an email to that address." Does that answer your question?

Comment 13

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 14

[Kathleen Wilson]

I am now opening the first public discussion period for two requests from Symantec/VeriSign:

#536318 - EV enable VeriSign SHA256 root certificate

#602107 - Turn on the code signing and email trust bits for the VeriSign Class 3 Public Primary Certification Authority - G5

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

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

Comment 15

[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 and email trust bits for the “VeriSign Class 3 Public Primary Certification Authority - G5” 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. Symantec acquired the VeriSign Authentication Services and root certificates, and is a major commercial CA with worldwide operations and customer base.

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

CP: http://www.verisign.com/repository/vtnCp.html
CPS: http://www.verisign.com/repository/CPS/

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

* Email: From CPS section 3.2.2: “Where a domain name or e-mail address is included in the certificate Symantec authenticates the Organization’s right to use that domain name either as a fully qualified Domain name or an e-mail domain.” Email certificates may be Class 1, 2, or 3. All must at least meet the requirements of Class 1. For Class 1 certs CPS section 3.2.3 says: “No identity authentication. There is a limited confirmation of the Subscriber’s e-mail address by requiring the Subscriber to be able to answer an e-mail to that address.”

* SSL: According to CPS section 1.4.1 only Class 3 certificates issued to organizations can be used for SSL and Code Signing. Additionally high assurance with extended validation certificates are Class 3 certificates issued by Symantec in conformance with the Guidelines for Extended Validation Certificates. According to CPS section 3.2.2 Symantec verifies that the organization has the right to use the domain name to be included in the certificate.

* Code: According to CPS section 1.4.1 Organizational Certificates are issued to organizations after authentication that the Organization legally exists and that other Organization attributes included in the certificate are authenticated e.g. ownership of an Internet or e-mail domain. Further information is provided in CPS section 3.2.2 regarding the use of third party identity proofing services and other methods to confirm organizational existence, and the use of telephone or postal mail to confirm the authorization of the certificate subscriber to submit the application on behalf of the organization.

EV Policy OID: 2.16.840.1.113733.1.7.23.6

Section 15 [Certificate Hierarchy]. 
CA Hierarchy Diagram: http://www.verisign.com/repository/hierarchy/hierarchy.pdf
This root has the following internally-operated sub-CAs:
- VeriSign Extended Validation SSL CA
- VeriSign Extended Validation SSL SGC CA
- VeriSign Secure Server CA – G3
- VeriSign Class 3 Code Signing 2010 CA
- VeriSign Class 3 International Server CA – G3
- Thawte SGC CA - G2

* Both CRL and OCSP are provided 
** CPS section 4.9.7: CRLs for end-user Subscriber Certificates are issued at least once per day.
** CPS Appendix B1, For EV Certificates: Symantec’s Online Certificate Status Protocol (OCSP) is updated at least every four (4) days, and with a maximum expiration time of ten (10) days

Sections 9-11 [Audit]. Annual audits are performed by KPMG and posted on the webtrust.org website.
https://cert.webtrust.org/SealFile?seal=304&file=pdf
This document contains audit reports for both the WebTrust CA criteria and the WebTrust EV criteria.

Based on this assessment I intend to approve this request to turn on the code signing and email trust bits for the “VeriSign Class 3 Public Primary Certification Authority - G5” root certificate.

Comment 16

[Spike McLarty]

(In reply to Stefan Baebler from comment #8)
> (In reply to Stefan Baebler from comment #6)
> > Would it (as a temporary workaround until this bug is fixed and fix
> > released) help to include intermediate CAs into the code signing certificate?
> Confirming that YES, this workaround works fine, which makes this bug just a
> huge annoyance for software developers, who must jump hoops to get their
> jars and xpis signed the right way.
Stefan!  I was very happy to find this thread & see your comments. I have a binary plugin ready to deploy and I'd like to sign it, but I'm hung up on exactly this issue.
http://stackoverflow.com/questions/8790819
Do you feel signing is worthwhile for xpis? If so, can I trouble you for some details about those xpi-signing hoops, which I would like to jump?  I'm used to code-signing, but haven't been 'inside' certificates much.
> 
> From a different point of view: not having the code signing trust bit set on
> this CA is NOT preventing code from execution, which could be a security
> issue.

Comment 17

[Stefan Baebler]

(In reply to Spike McLarty from comment #16)
> http://stackoverflow.com/questions/8790819
> Do you feel signing is worthwhile for xpis? If so, can I trouble you for
It really depends how wide your user base is and what risks are acceptable to you for your users to take. Eg MITM during installation could result in users installing rogue addon instead of legitimate one.

> some details about those xpi-signing hoops, which I would like to jump?  I'm
> used to code-signing, but haven't been 'inside' certificates much.
Provided some tips there: http://stackoverflow.com/a/8849048

Hope it helps.

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 #15, and on behalf of Mozilla I approve this request from Symantec to turn on the code signing and email trust bits for the “VeriSign Class 3 Public Primary Certification Authority - G5” root certificate.

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

Comment 19

[Kathleen Wilson]

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