833974 - Enable EV for existing VeriSign ECC root

Status: RESOLVED FIXED

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

Description

[Rick Andrews]

Attachment: CAInformationTemplate_SymantecExisting.docx

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130116073211

Steps to reproduce:

I would like to update the trust bits of a Symantec (VeriSign) root that is already in Mozilla's trust list:
VeriSign Class 3 Public Primary Certification Authority - G4 (SHA384withECC)
Turn on WebSites and Code Signing trust bits, along with EV trust bit

Comment 1

[Kathleen Wilson]

I apologize for the delay in my response. My work on root inclusion requests was postponed for a while.

I am accepting this bug, and will work on it as soon as possible, but I have a large backlog.
https://wiki.mozilla.org/CA:Schedule#Requests_in_the_Information_Gathering_and_Verification_Phase

I will update this bug when I begin the Information Verification phase.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

Comment 2

[Kathleen Wilson]

All three trust bits are already enabled for this root.
http://tinyurl.com/MozillaBuiltInCAs

So I think this request is for EV enablement of an ECC root.
VeriSign Class 3 Public Primary Certification Authority - G4 (SHA384withECC)

Comment 3

[Kathleen Wilson]

Attachment: Initial CA Information Document

The attached document summarizes the information that has been 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

[Kathleen Wilson]

Request is to EV-enable an already included root cert.

CA needs to complete EV testing before we can continue with this request.
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

Comment 5

[Rick Andrews]

We've performed EV testing, but unfortunately we don't see the green bar. Here's what we did:

1. Downloaded the latest nightly build for debug as mentioned in doc (The build was 24.6.0esrpre)
2. Set the environment variable for ENABLE_TEST_EV_ROOTS_FILE=1
3. Imported the root CA to the browser
4. Created the file test_ev_roots.txt under the profile for Firefox, issuer is in one line in the file:

	1_fingerprint 22:D5:D8:DF:8F:02:31:D1:8D:F7:9D:B7:CF:8A:2D:64:C9:3F:6C:3A
	2_readable_oid 2.16.840.1.113733.1.7.23.6
	3_issuer 	MIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAyMDA3IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDMgUHVibGljIFBy	aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHNA==
4_serial L4D+I4wOIg9IZxIokYessw==

4. We believe we generated the issuer name and serial values correctly as per the instructions.

5. After completion of all these steps we hit the test web server at https://ssltest35.ssl.symclab.com

6. We also checked the ocsp response and it returned ok.

Please advise if we've done something wrong.

Comment 6

[Kathleen Wilson]

Attachment: test_ev_roots.txt

Comment 7

[Kathleen Wilson]

Attachment: Screen shot showing successful test of EV

Comment 8

[Dhara]

Attachment: Screenshot showing success_QA_Test

Comment 9

[Dhara]

Tested after Kathleen's response and now it looks good.
Attached the screenshot from QA.

Kathleen,
  Please can you let us know when will this go live or which version of Firefox will have this in effect ?

Thanks,
Dhara

Comment 10

[Kathleen Wilson]

Where is the BR audit statement for the VeriSign roots?

Which of the CP/CPS documents in https://www.symantec.com/about/profile/policies/repository.jsp?tab=Tab2 apply to the VeriSign roots?

Comment 11

[Rashmi Tabada]

Hi Kathleen,

For the VeriSign roots, use the "Symantec Trust Network Certification Practice Statement" in the repository at https://www.symantec.com/about/profile/policies/repository.jsp?tab=Tab2

Comment 12

[Kathleen Wilson]

(In reply to Rashmi Tabada from comment #11)
> For the VeriSign roots, use the "Symantec Trust Network Certification
> Practice Statement" in the repository at
> https://www.symantec.com/about/profile/policies/repository.jsp?tab=Tab2

Thanks.

STN-CPS section 3.2.2.1 says: EV SSL Certificates, EV Code Signing, and domain-validated and organization-validated SSL Certificates conform to the CA / Browser Forum requirements as set forth in the STN Supplemental Procedures, in section 11 of Appendix B1, Appendix C and Appendix D, respectively.

Which document is "STN Supplemental Procedures" referring to?

Comment 13

[Rashmi Tabada]

they are just the supplementatl requirements in the appendix.

Comment 14

[Kathleen Wilson]

STN-CP Appendix B1:  The current version of the CA/Browser Forum Guidelines for the Issuance and Management of Extended Validation (EV) SSL Certificates can be accessed at https://cabforum.org/extended validation/

STN-CP Appendix C: The current version of the CA/Browser Forum Guidelines for the Issuance and Management of Extended Validation (EV) Code Signing Certificates can be accessed at https://cabforum.org/ev-code-signing-certificate-guidelines/

STN-CP Appendix D: The current version of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates can be accessed at https://cabforum.org/baseline-requirements-documents/

So, STN-CPS section 3.2.2.1 just says that section 11 of each of these CAB Forum documents is followed?

So, the STN-CPS says nothing about what Symantec actually does to confirm that the domain name and email addresses to be included in the certificate are actually owned/controlled by the certificate subscriber. The STN-CPS just says that the CAB Forum documents are followed.  
Correct?

Comment 15

[Kathleen Wilson]

Please see
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Email_Address_Control
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Identity_of_Code_Signing_Certificate_Subscriber

Comment 16

[Rashmi Tabada]

yes, we do follow CAB Forum guidelines.

Comment 17

[Kathleen Wilson]

https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
"The CA's public documentation needs to provide sufficient information describing the steps taken by the CA to confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the domain name."

https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Email_Address_Control
"The CA's public documentation needs to provide sufficient information describing how the email address is verified to be owned/controlled by the certificate subscriber. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the email address."

https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Identity_of_Code_Signing_Certificate_Subscriber
"The CA's public (and audited) documentation must provide sufficient information describing the process to permit us to form an opinion. The documentation needs to be clear about the checks that are performed to confirm the identity of the certificate subscriber as well as establish that the certificate subscriber is authorized by the organization to be referenced in the certificate."


It's not sufficient to just say "we follow the BRs". That doesn't tell us what steps are actually taken/used by Symantec.

Comment 18

[Rashmi Tabada]

Hi Kathleen,

The CPS was written in accordance to the BR guidelines. Section 11 states the options we have to validate/authenticate cert requests.  Annual audits confirm that we do follow the set guidelines.

I read the latest request from Mozilla to update the CPS with specifics. We are happy to consider and work on it. However, can we please grandfather the current outstanding root requests while this is decided and acted upon?

Please note that the outstanding root requests (in priority order mentioned in a different thread) are on the critical path for acting on certain industry mandates. We appreciate your consideration in helping us meet these different mandates/requests.

Thanks,
Rashmi

Comment 19

[Kathleen Wilson]

(In reply to Rashmi Tabada from comment #18)
> The CPS was written in accordance to the BR guidelines. 

BR section 8.2.1: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements." 


> Section 11 states the options we have to validate/authenticate cert requests.  

I am not finding anything in the STN-CP or STN-CPS that tells me what Symantec actually *does* to validate/authenticate cert requests. The CP/CPS does not appear to say which of the options in section 11 of the BRs Symantec chooses to use, and how Symantec does them.


> Annual audits confirm that we do follow the set guidelines.

That's one part of Mozilla's requirements.
Section 6 of Mozilla's CA Certificate Inclusion Policy (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ ): "We require that all CAs whose certificates are distributed with our software products: 
... publicly disclose information about their policies and business practices (e.g., in a Certificate Policy and Certification Practice Statement);
... provide *public attestation* of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties with access to details of the CA’s internal operations." 


> 
> I read the latest request from Mozilla to update the CPS with specifics. We
> are happy to consider and work on it. However, can we please grandfather the
> current outstanding root requests while this is decided and acted upon?


Mozilla's process is public facing, and includes a public discussion phase.
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Unless I'm missing something, I do not see the necessary information in the current version of the STN-CP and STN-CPS, so this request wold not make it through the discussion phase. We would end up with an action item for Symantec to update the CP/CPS and try again. I don't see the point in going through that.

Please familiarize yourself with the mozilla.dev.security.policy discussion forum.
https://groups.google.com/forum/#!forum/mozilla.dev.security.policy

Comment 20

[Rashmi Tabada]

(In reply to Kathleen Wilson from comment #10)
> Where is the BR audit statement for the VeriSign roots?

BR audit statement for all our roots are here:
http://www.symantec.com/about/profile/policies/repository.jsp

Comment 22

[Kathleen Wilson]

Status of this request:

Need updated CP/CPS as per
https://wiki.mozilla.org/CA:BaselineRequirements#CA_Conformance_to_the_BRs
"It is not sufficient to simply reference section 11 of the CA/Browser Forum's Baseline Requirements (BR). BR #11.1.1 lists several ways in which the CA may confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. Simply referencing section 11 of the BRs does not specify which of those options the CA uses, and is insufficient for describing how the CA conforms to the BRs. The CA's CP/CPS must include a reasonable description of the ways the CA can verify that the certificate subscriber owns/controls the domain name(s) to be included in the certificate."

Comment 23

[Kathleen Wilson]

Attachment: 833974-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.

Comment 24

[David E. Ross]

Does this really block bug #1017550?  Or is it the other way around?

Comment 25

[Kathleen Wilson]

Attachment: 833974-CAInformation.pdf

Please review the full attached document to make sure it is current and accurate, and comment in this bug to confirm it is correct or to provide corrections/updates.

Comment 26

[Kathleen Wilson]

We recently added two tests that CAs must perform and resolve errors for...

Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for the root certificate. Then click on the 'Search' button. Then click on the 'Run cablint' link. All errors must be resolved/fixed. Warnings should also be either resolved or explained.

Output for Test1:
no errors

Test 2) Browse to http://cert-checker.allizom.org:3001/ and enter the test website and click on the 'Browse' button to provide the PEM file for the root certificate. Then click on 'run certlint'. All errors must be resolved/fixed. Warnings should also be either resolved or explained. 

Output for Test 2:
Using certificate chain from 'https://ssltest35.ssl.symclab.com/'

Using certificate from local file 'VeriSignClass3PublicPrimaryCertificationAuthority-G4'

    /1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private Organization/serialNumber=2158113/C=US/postalCode=94043/ST=California/L=Mountain View/street=487 E. Middelfield Rd/O=Symantec Corporation/OU=FOR TESTING - DEMO PURPOSES ONLY/CN=ssltest35.ssl.symclab.com
        Notice
            1.3.6.1.4.1.311.60.2.1.2 could be encoded as PrintableString
            postalCode could be encoded as PrintableString
            ST could be encoded as PrintableString
            L could be encoded as PrintableString
            street could be encoded as PrintableString
            O could be encoded as PrintableString
            OU could be encoded as PrintableString
            CN could be encoded as PrintableString
            Some python versions will not see SAN extension if it is the first extension
        Error
            Certificate Policy explict text must not be VisibleString or BMPString



~~

Please add a comment in this bug when the error has been resolved.

Comment 27

[Rick Andrews]

Kathleen, from my corporate machine I cannot reach http://cert-checker.allizom.org:3001/. I suspect it's because it's on a non-standard port. Can you please host that on port 443? I suspect others will have the same problem.

Looking at the Output for Test 2, though, it looks like certlint is complaining about the policy extension in the end-entity cert. I can run cablint against it in crt.sh at https://crt.sh/?id=3444251&opt=cablint, and it shows no Errors. I recently logged an issue with Peter about this (https://github.com/awslabs/certlint/issues/7), and he fixed it in certlint. I suspect crt.sh is using the latest version of certlint, and allizon.org is using an older buggy version. Can you please confirm?

Comment 28

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

I updated certlint and moved the site to https/443. Thanks for bearing with us in the early stages of using this, and let me know if there are any further issues.

Comment 29

[Kathleen Wilson]

Retested with the updated site (https://cert-checker.allizom.org/), and no more errors.  Thanks!

Comment 30

[Rick Andrews]

Thanks, David and Kathleen. The tests all work now.

Following up on https://bugzilla.mozilla.org/show_bug.cgi?id=833974#c25:
We have reviewed the CA Information doc. Except for the comments/changes below, we agree that the document is accurate and current:

1. Delegation of Domain/Email Validation to third parties - Some of our Registration Authorities (RA) do perform domain validation functions. They are covered as part of our WebTrust audits.

2. Distributing generated private keys in PKCS#12 files – We do not generate key pairs for signer or SSL certificates. We do provide a utility for some of our customers so they can generate their own key pairs. In any case, we do not have visibility to their private keys and do not distribute them in a PKCS#12 file.

3. Regarding https://certificate.revocationcheck.com/ssltest35.ssl.symclab.com, we see intermittent issues and we are investigating them currently.

4. Under EV Policy OID(s), please note that we have or are in the process of adding the CABF OID 2.23.140.1.1, i.e. we will have both our policy OID as well as the CABF Policy OID in our EV certs.

5. Under ‘CA Hierarchy Information’, it currently reads “This root signs internally-operated SubCAs which issue OV and EV SSL certificates, as well as S/MIME and Code Signing certificates.” Please update that to “This root signs internally-operated SubCAs which issue OV and EV SSL certificates, as well as Code Signing certificates.”

Comment 31

[Kathleen Wilson]

(In reply to Rick Andrews from comment #30)
> Thanks, David and Kathleen. The tests all work now.
> 
> Following up on https://bugzilla.mozilla.org/show_bug.cgi?id=833974#c25:
> We have reviewed the CA Information doc. Except for the comments/changes
> below, we agree that the document is accurate and current:
> 
> 1. Delegation of Domain/Email Validation to third parties - Some of our
> Registration Authorities (RA) do perform domain validation functions. They
> are covered as part of our WebTrust audits.
> 

OK

> 2. Distributing generated private keys in PKCS#12 files – We do not generate
> key pairs for signer or SSL certificates. We do provide a utility for some
> of our customers so they can generate their own key pairs. In any case, we
> do not have visibility to their private keys and do not distribute them in a
> PKCS#12 file.
> 

OK

> 3. Regarding
> https://certificate.revocationcheck.com/ssltest35.ssl.symclab.com, we see
> intermittent issues and we are investigating them currently.
> 

I tested again, and it seems to be working for me. No errors.

> 4. Under EV Policy OID(s), please note that we have or are in the process of
> adding the CABF OID 2.23.140.1.1, i.e. we will have both our policy OID as
> well as the CABF Policy OID in our EV certs.
> 

I only need to list the EV Policy OID that we need to have in 
https://mxr.mozilla.org/mozilla-central/source/security/certverifier/ExtendedValidation.cpp
So I don't need to list the CABF OID.


> 5. Under ‘CA Hierarchy Information’, it currently reads “This root signs
> internally-operated SubCAs which issue OV and EV SSL certificates, as well
> as S/MIME and Code Signing certificates.” Please update that to “This root
> signs internally-operated SubCAs which issue OV and EV SSL certificates, as
> well as Code Signing certificates.”

Should we turn off the Email trust bit for this root cert?

Comment 32

[Kathleen Wilson]

Note that I started a discussion about these certlint tests in mozilla.dev.security.policy:
https://groups.google.com/d/msg/mozilla.dev.security.policy/3avqmSF4MVU/yzbAbgjvAAAJ
Issues that require further discussion should be moved there, so that others may contribute to the discussion/decision, I will be able to refer people to the decisions later, and the results will benefit everyone who is now required to run these tests.

I will move the 00 serial number discussion there.

Comment 33

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #32)
> Note that I started a discussion about these certlint tests in
> mozilla.dev.security.policy:
> https://groups.google.com/d/msg/mozilla.dev.security.policy/3avqmSF4MVU/
> yzbAbgjvAAAJ
> Issues that require further discussion should be moved there, so that others
> may contribute to the discussion/decision, I will be able to refer people to
> the decisions later, and the results will benefit everyone who is now
> required to run these tests.
> 
> I will move the 00 serial number discussion there.

Sorry. Wrong bug. Please ignore.

Comment 34

[Rick Andrews]

> > 4. Under EV Policy OID(s), please note that we have or are in the process of
> > adding the CABF OID 2.23.140.1.1, i.e. we will have both our policy OID as
> > well as the CABF Policy OID in our EV certs.
> > 
> 
> I only need to list the EV Policy OID that we need to have in 
> https://mxr.mozilla.org/mozilla-central/source/security/certverifier/
> ExtendedValidation.cpp
> So I don't need to list the CABF OID.

Eventually, we'll drop our own OID and use the CABF OID exclusively (since that is mandated by Microsoft's root policy). When we do that, Firefox will break if it's not also expecting the CABF OID. That's why we'd like to you add both OIDs.
 
> > 5. Under ‘CA Hierarchy Information’, it currently reads “This root signs
> > internally-operated SubCAs which issue OV and EV SSL certificates, as well
> > as S/MIME and Code Signing certificates.” Please update that to “This root
> > signs internally-operated SubCAs which issue OV and EV SSL certificates, as
> > well as Code Signing certificates.”
> 
> Should we turn off the Email trust bit for this root cert?

We allow the issuance of S/MIME certs from this root, so please keep the Email trust bit enabled.

Comment 35

[Kathleen Wilson]

Attachment: 833974-CAInformation-Complete.pdf

Comment 36

[Kathleen Wilson]

This request was previously added to the queue for public discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
I will update this bug when I start the discussion.

Comment 37

[Kathleen Wilson]

I am now opening the public discussion period for this request from Symantec to enable EV treatment for the "VeriSign Class 3 Public Primary Certification Authority - G4" root certificate that was included via bug #409235, and has all three trust bits enabled. 

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 forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called "Request to enable EV for VeriSign Class 3 G4 ECC root".

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

A representative of this CA must promptly respond directly in the discussion thread to all questions that are posted.

Comment 38

[Kathleen Wilson]

The public comment period for this request is now over.

This request has been evaluated as per Mozilla’s CA Certificate Inclusion Policy at

https://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/

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

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

Inclusion Policy Section 6 [Relevance and Policy].
	 
Symantec appears to provide a service relevant to Mozilla users. It is a major commercial CA with worldwide operations and customer base.
	 
Root Certificate Name: VeriSign Class 3 Public Primary Certification Authority - G4
O From Issuer Field: VeriSign, Inc.
Trust Bits Already enabled: Code; Email; Websites

EV Policy OIDs: 	2.16.840.1.113733.1.7.23.6 and 2.23.140.1.1

This request is to enable EV treatment for the “VeriSign Class 3 Public Primary Certification Authority - G4” root certificate that was included via bug #409235. Root is offline. Used only to issue internally-operated SubCAs, CRLs, OCSP certs.

CA Document Repository: 	https://www.symantec.com/about/profile/policies/repository.jsp
CPS: https://www.symantec.com/content/en/us/about/media/repository/stn-cps.pdf

Certificate Revocation
CRL URLs: http://crl.ws.symantec.com/pca3-g4.crl
http://EV256SecureECC-crl.ws.symantec.com/EV256SecureECC.crl
OCSP URLs: http://ocsp.ws.symantec.com
http://EV256SecureECC-ocsp.ws.symantec.com

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

* SSL Verification Procedures: As per CPS section 3.2.2.3: Symantec uses the following methods of vetting a domain name, with option 1 being the primary method:
1. Confirm the Applicant as the Domain Name Registrant directly with the Domain Name Registrar by performing a whois look up.
2. Communicate directly with the Domain Name Registrant using an address, email, or telephone number provided by the Domain Name Registrar;
3. Rely upon a Domain Authorization Document;
4. Communicate directly with the Domain Name Registrant using the contact information listed in the WHOIS record’s “registrant”, “technical”, or “administrative” field;
5. Communicate with the Domain’s administrator using an email address created by pre-pending ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ in the local part, followed by the at-sign (“@”), followed by the Domain Name, which may be formed by pruning zero or more components from the requested FQDN;
6. Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN.

* EV SSL Verification Procedures: As per CPS, EV SSL Certificates conform to the CA / Browser Forum requirements.

* Email Verification Procedures: According to CPS section 3.2.3, Symantec performs a challenge-response type of procedure in which Symantec 
sends email to the email address to be included in the certificate, containing unpredictable information such as a randomly generated PIN/Password unique to the owner of the email address. The owner of the email address (the subscriber of the certificate) demonstrates control over the email address by using the information  within the email, to then proceed with accessing a portal with the unique information  sent in the email, to download and install the certificate.

Inclusion Policy Sections 11-14 [Audit]. 
Annual audits are performed by KPMG, according to the WebTrust criteria.
Standard Audit: https://www.symantec.com/content/en/us/about/media/repository/Symantec-STN-WTCA-2015.pdf
BR Audit: https://www.symantec.com/content/en/us/about/media/repository/Symantec-Thawte-WTBR-2015.pdf
EV Audit: https://www.symantec.com/content/en/us/about/media/repository/Symantec-STN-WTEV-2015.pdf

Inclusion Policy Section 18 [Certificate Hierarchy]
This root signs internally-operated SubCAs which issue OV and EV SSL certificates, as well as Code Signing certificates. S/MIME certs may also be issued in this CA hierarchy.

Based on this assessment I intend to approve this request from Symantec to enable EV treatment for the "VeriSign Class 3 Public Primary Certification Authority - G4" root certificate.

Comment 39

[Kathleen Wilson]

As per the summary in Comment #38, and on behalf of Mozilla I approve this request from Symantec to enable EV treatment for the following root certificate:

** "VeriSign Class 3 Public Primary Certification Authority - G4" 

I will file the PSM bug for the approved change.

Comment 40

[Kathleen Wilson]

I have filed bug #1289885 against PSM for the actual changes.