606947 - Add 3 COMODO Rollover Root CA Certificates and enable them for EV

Status: RESOLVED FIXED

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

Description

[Rob Stradling]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20101014 Gentoo Firefox/3.6.9
Build Identifier: 

CA Details
----------

Name: COMODO
Website: www.comodo.com
Organization: COMODO CA Limited, a private corporation.
Primary market: The global, public Internet.


CA Certificate Details
-------------------

Certificate Name: COMODO RSA Certification Authority
Certificate URL: http://crt.comodoca.com/COMODORSACertificationAuthority.crt
Version: X.509v3
SHA1 Fingerprint: AFE5D244A8D1194230FF479FE2F897BBCD7A8CB4
Key Length: 4096-bit RSA
Valid From (YYYY-MM-DD): 2010-01-19
Valid To (YYYY-MM-DD): 2038-01-18
CRL URL: http://crl.comodoca.com/COMODORSACertificationAuthority.crl
OCSP URL: http://ocsp.comodoca.com
Requested Trust Indicators (email, SSL, code): All 3
SSL Class (DV, IV/OV, EV): All 3
EV Policy OID: 1.3.6.1.4.1.6449.1.2.1.5.1
Test URL: https://comodorsacertificationauthority-ev.comodoca.com

Certificate Name: USERTrust RSA Certification Authority
Certificate URL: http://crt.usertrust.com/USERTrustRSACertificationAuthority.crt
Version: X.509v3
SHA1 Fingerprint: 2B8F1B57330DBBA2D07A6C51F70EE90DDAB9AD8E
Key Length: 4096-bit RSA
Valid From (YYYY-MM-DD): 2010-02-01
Valid To (YYYY-MM-DD): 2038-01-18
CRL URL: http://crl.usertrust.com/USERTrustRSACertificationAuthority.crl
OCSP URL: http://ocsp.usertrust.com
Requested Trust Indicators (email, SSL, code): All 3
SSL Class (DV, IV/OV, EV): All 3
EV Policy OID: 1.3.6.1.4.1.6449.1.2.1.5.1
Test URL: https://usertrustrsacertificationauthority-ev.comodoca.com

Certificate Name: USERTrust ECC Certification Authority
Certificate URL: http://crt.usertrust.com/USERTrustECCCertificationAuthority.crt
Version: X.509v3
SHA1 Fingerprint: D1CBCA5DB2D52A7F693B674DE5F05A1D0C957DF0
Key Length: 384-bit ECC (secp384r1)
Valid From (YYYY-MM-DD): 2010-02-01
Valid To (YYYY-MM-DD): 2038-01-18
CRL URL: http://crl.usertrust.com/USERTrustECCCertificationAuthority.crl
OCSP URL: http://ocsp.usertrust.com
Requested Trust Indicators (email, SSL, code): All 3
SSL Class (DV, IV/OV, EV): All 3
EV Policy OID: 1.3.6.1.4.1.6449.1.2.1.5.1
Test URL: https://usertrustecccertificationauthority-ev.comodoca.com


CPS Details
-----------

http://www.comodo.com/repository/EV_CPS_4_JUN_07.pdf
http://www.comodo.com/repository/EV_CPS_Amendment-ECC_Certificates.pdf
http://www.comodo.com/repository/EV_CPS_Amendment-June_2009.pdf


Audit Details
-------------

Type: WebTrust, WebTrust for EV
Auditor: Ernst & Young LLP, 200 Clarendon Street, Boston, Massachusetts 02116.
Audit Reports:
  https://cert.webtrust.org/ViewSeal?id=1082
  https://cert.webtrust.org/ViewSeal?id=1083


Reproducible: Always

Comment 1

[Rob Stradling]

Attachment: COMODO RSA Certification Authority root certificate

Comment 2

[Rob Stradling]

Attachment: USERTrust RSA Certification Authority root certificate

Comment 3

[Rob Stradling]

Attachment: USERTrust ECC Certification Authority root certificate

Comment 4

[Kathleen Wilson]

Accepting this bug.  I will start the Information Gathering and Verification
phase as per https://wiki.mozilla.org/CA:How_to_apply.

Comment 5

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

[Kathleen Wilson]

Current audit statements:
https://cert.webtrust.org/SealFile?seal=1221&file=pdf
https://cert.webtrust.org/SealFile?seal=1222&file=pdf

Comment 7

[Robin Alden]

Hi Kathleen,
     I'm glad to be able to pick up this bug again.

I've tried to respond to all of the highlighted parts of the information gathering document.  If I've missed any or my answers are not clear or adequate then I will be happy to elucidate further.

Mozilla: Certificate Name: COMODO RSA Certification Authority
Mozilla: Cert Summary: Is this the next version of the “COMODO Certification Authority” root certificate that was included in bug#401587?
Broadly speaking, yes.  The new root from that bug is 'Comodo' branded with an RSA key.
The (old) root certificate from bug#401587 has a 2048 bit RSA key, a SHA1 based signature, and expires in 2029.  
This root is Comodo branded, has a 4096 bit key, a SHA2 based signature, and expires in 2038.

Mozilla: CA Hierarchy: Please provide a description and/or diagram of the CA hierarchy that is planned for this root.

We have so far issued internally operated sub-CAs from this root as follows:
    COMODO RSA Extended Validation Secure Server CA
    COMODO RSA Client Authentication and Secure Email CA
    COMODO RSA Code Signing CA
We will likely issue 2 further sub-CAs, one each for OV and DV Server certificates, plus further CAs immediately subordinate to this root to partition the sales of resellers, some bearing the name of the reseller in the subject and others bearing the Comodo name.

Mozilla: Externally operated subCAs: Does or will this root have any subordinate CAs that are operated by external third parties? If yes, please see https://wiki.mozilla.org/CA:SubordinateCA_checklist
We comply with the CABF Baseline requirements v 1.1.6 and are undergoing a WebTrust BR audit.
We comply with Mozilla’s CA Policy version 2.2, including item 8 which deals with externally operated sub-CAs.
There are currently no externally operated sub-CAs issued from this root, but if we issue any they will be operated in accordance with Mozilla's CA Certificate Policy and will either be technically constrained or be publicly disclosed and audited.

Mozilla: Cross-Signing: List any other root CAs that have (or are planned to) issued cross-signing certificates for this root CA.
We have cross-signed this certificate from our "AddTrust External CA Root" (sha1 fingerprint: 02:fa:f3:e2:91:43:54:68:60:78:57:69:4d:f5:e4:5b:68:85:18:68, already in Mozilla's root program)
This root has not been cross-signed by any other CAs.
We have no plans to have this root cross-signed by any other CAs.  

Mozilla: Certificate Name: USERTrust RSA Certification Authority
Mozilla: Cert Summary: Is this the next version of one or more of the root certificates that were included in bug#242610?
Broadly speaking, yes.  All of those are 'USERTRUST' branded roots with RSA keys.
The (old) root certificates from bug#242610 have 2048 bit RSA keys, SHA1 based signatures, and expire in 2019.  
This root has a 4096 bit RSA key, a SHA2 based signature, and expires in 2038.

Mozilla: CA Hierarchy: Please provide a description and/or diagram of the CA hierarchy that is planned for this root.

We have so far issued an internally operated sub-CA from this root as follows:
    USERTrust RSA Extended Validation Secure Server CA

We plan to issue further sub-CAs as follows:
    USERTrust RSA Client Authentication and Secure Email CA
    USERTrust RSA Code Signing CA
    (name tbd) for OV Server certificates
    (name tbd) for DV Server certificates
plus further CAs immediately subordinate to this root to partition the sales of resellers, some bearing the name of the reseller in the subject and others bearing the UserTrust name.

Mozilla: Externally operated subCAs: Does or will this root have any subordinate CAs that are operated by external third parties? If yes, please see https://wiki.mozilla.org/CA:SubordinateCA_checklist
We comply with the CABF Baseline requirements v 1.1.6 and are undergoing a WebTrust BR audit.
We  comply with Mozillas CA Policy version 2.2, including item 8 which deals with externally operated sub-CAs.
There are currently no externally operated sub-CAs issued from this root, but if we issue any they will be operated in accordance with Mozilla's CA Certificate Policy and will either be technically constrained or be publicly disclosed and audited.

Mozilla: Cross-Signing: List any other root CAs that have (or are planned to) issued cross-signing certificates for this root CA.
We have cross-signed this certificate from our "AddTrust External CA Root" (sha1 fingerprint: 02:fa:f3:e2:91:43:54:68:60:78:57:69:4d:f5:e4:5b:68:85:18:68, already in Mozilla's root program)
This root has not been cross-signed by any other CAs.
We have no plans to have this root cross-signed by any other CAs.  

Mozilla: Certificate Name: USERTrust ECC Certification Authority
Mozilla: Cert Summary: Is this the next version of one or more of the root certificates that were included in bug#242610?
In a sense, yes.  All of those are 'USERTRUST' branded roots with RSA keys.
The (old) root certificates from bug#242610 have 2048 bit RSA keys, SHA1 based signatures, and expire in 2019.  
This root has a 384 bit ECC key, a SHA2 based signature, and expires in 2038.

Mozilla: CA Hierarchy: Please provide a description and/or diagram of the CA hierarchy that is planned for this root.

We have so far issued an internally operated sub-CA from this root as follows:
    USERTrust ECC Extended Validation Secure Server CA

We plan to issue sub-CAs as follows:
    USERTrust ECC Client Authentication and Secure Email CA
    USERTrust ECC Code Signing CA
    (name tbd) for OV Server certificates
    (name tbd) for DV Server certificates
plus further CAs immediately subordinate to this root to partition the sales of resellers, some bearing the name of the reseller in the subject and others bearing the UserTrust name.

Mozilla: Externally operated subCAs: Does or will this root have any subordinate CAs that are operated by external third parties? If yes, please see https://wiki.mozilla.org/CA:SubordinateCA_checklist
We comply with the CABF Baseline requirements v 1.1.6 and are undergoing a WebTrust BR audit.
We  comply with Mozillas CA Policy version 2.2, including item 8 which deals with externally operated sub-CAs.
There are currently no externally operated sub-CAs issued from this root, but if we issue any they will be operated in accordance with Mozilla's CA 

Certificate Policy and will either be technically constrained or be publicly disclosed and audited.

Mozilla: Cross-Signing: List any other root CAs that have (or are planned to) issued cross-signing certificates for this root CA.
We have cross-signed this certificate from our "AddTrust External CA Root" (sha1 fingerprint: 02:fa:f3:e2:91:43:54:68:60:78:57:69:4d:f5:e4:5b:68:85:18:68, already in Mozilla's root program)
This root has not been cross-signed by any other CAs.
We have no plans to have this root cross-signed by any other CAs.  

The following answers apply to all 3 of the roots to be added.

Mozilla: What is the maximum expiration time for OCSP responses?
OCSP responses for end entity certificates are regenerated every 24 hours.
The OCSP responses show a 'Next Update' date 4 days after 'This Update' date.  
The 'This Update' date is the date (and time) at which we publish the OCSP response.
The 'Next Update' date is the nearest analogue to an expiry date for an OCSP response.

Mozilla: please provide the complete list of email address prefixes that Comodo uses, and where this is documented.
Mozilla: Please see: https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs
We comply with the CABF Baseline requirements v 1.1.6 and are undergoing a WebTrust BR audit.
The Baseline requirements set out the acceptable email address prefixes that may be used for domain control validation.
The BRs are at https://www.cabforum.org/Baseline_Requirements_V1_1_6.pdf
Section 11.1.1.4 says..
"the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant either is the Domain Name Registrant or has control over the FQDN by:... 
4. Communicating 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;”

Comodo accept any of those five email address prefixes (‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’) plus email addresses from the WHOIS entry.

Mozilla: Will the CPS be updated in regards to these new roots? Or will there be an addendum to cover them?
Our current CPS is http://www.comodo.com/repository/Comodo_CA_CPS_4.0.pdf
We are (as of Nov 11 2013) preparing a new version of the CPS which will include mention of these new roots.

Mozilla: AUDIT
Mozilla: “…for the ‘Comodo EV SGC SSL Certificate’ and ‘Comodo EV SSL Certificate’ products…”
Mozilla: How does, or will this relate to these new roots?

We will issue ‘Comodo EV SGC SSL Certificate’ and ‘Comodo EV SSL Certificate’ products from these three roots via internal (i.e. operated by Comodo) subordinate CAs which will be used only for the issuance of EV certificates.

Our latest audit results (from 2012) may be found at:
http://cert.webtrust.org/SealFile?seal=1410&file=pdf
http://cert.webtrust.org/SealFile?seal=1409&file=pdf
From this year, 2013, we will have audit reports for
    WebTrust for CAs
    WebTrust SSL Baseline Requirements
    WebTrust Extended Validation
and all three will show these three new roots as being in-scope for the issuance of certificates under the corresponding criteria (being publicly trusted certificates in general, publicly trusted certificates for server authentication, and Extended Validation certificates for server authentication).
We expect to have the next audit reports for WebTrust for CAs and WebTrust for EV by thanksgiving this year, and the report for WebTrust for BRs by the end of 2013.

Mozilla: Potentially Problematic Practices
Mozilla: Please review the list of Potentially Problematic Practices (http://wiki.mozilla.org/CA:Problematic_Practices). Identify the ones that are and are not applicable. For the ones that are applicable, please provide further information.

Mozilla: Long-lived DV certificates:
Comodo issues DV certificates valid for up to 60 months.
From 1st April 2015 Comodo will issue DV certificates for up to 39 months.
This matches the requirement of section 9.4.1 of the CABF BRs.

For unrevoked SSL certificates valid for more than 39 months, Comodo verifies that all of the information that is included in SSL certificates remains current and correct at time intervals of thirty-nine months or less.

Mozilla: Wildcard DV SSL certificates
Comodo issues Wildcard DV certificates and Wildcard OV certificates.

Mozilla: Email Address Prefixes for DV Certs
When validating domain control using an email challenge-response, Comodo permit the use of the following email address prefixes when used with the domain for which the certificate is being requested.
    admin@
    administrator@
    hostmaster@
    postmaster@
    webmaster@
In addition we accept the use of an email address found in the WHOIS record of the domain for which the certificate is being requested.

Mozilla: Delegation of Domain / Email validation to third parties
Comodo does not delegate Domain validation to third parties.

In the general case, Comodo does not delegate Email validation to third parties, although there are some third parties which are able to issue email certificates for [e-mail] where there is a per third-party whitelist of possible values of domain.com.

Mozilla: Issuing end entity certificates directly from roots
Comodo does not issuing end entity certificates directly from root CAs.

Mozilla: Allowing external entities to operate subordinate CAs
Where Comodo issues subordinate CA certificates to external entities they are either technically constrained or publicly disclosed and audited as per 

Mozilla's Inclusion Policy.

Mozilla: Distributing generated private keys in PKCS#12 files
Comodo does not generate key-pairs for end entity SSL certificates.
In the general case for client certificates (including SMIME) Comodo does not generate key-pairs for end entity client certificates.
In specific enterprise and academic environments where key backup and/or key escrow are supported for client encryption certificates we do generate the key-pair for the end-entity certificates but we do not transfer certificates with their keys through unsecure electronic channels.

Mozilla: Certificates referencing hostnames or private IP addresses
We follow the CABF Baseline Requirements, including the date restrictions on the issuance of certificates including a Reserved IP Address or Internal 

Server Name in section 9.2.1.

Mozilla: Issuing SSL Certificates for Internal Domains
We recognize .int as an internet-resolvable TLD.
We operate a process to incorporate new TLDs as they are registered by ICANN.

Mozilla: OCSP Responses signed by a certificate under a different root
Comodo does not sign OCSP Responses using a certificate under a different root.

Mozilla: CRL with critical CIDP Extension
Comodo does not issue partitioned or partial CRLs.

Mozilla: Generic names for CAs
Comodo uses meaningful names for CAs.

Mozilla: Lack of Communication With End Users
Comodo undertakes to continue to respond to end user concerns.

Comment 8

[Kathleen Wilson]

Attachment: COMODO-RSA-test_ev_roots.txt

Comment 9

[Kathleen Wilson]

Attachment: COMODO-RSA-EV-screenshot.png

Comment 10

[Kathleen Wilson]

Attachment: USERTrust-RSA-test_ev_roots.txt

Comment 11

[Kathleen Wilson]

Attachment: USERTrust-RSA-EV-screenshot.png

Comment 12

[Kathleen Wilson]

Attachment: USERTrust-ECC-test_ev_roots.txt

Comment 13

[Kathleen Wilson]

Attachment: USERTrust-ECC-EV-screenshot.png

Comment 14

[Kathleen Wilson]

Attachment: Updated 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, and provide the necessary information in this bug.

Comment 15

[Rob Stradling]

(In reply to Robin Alden from comment #7)
<snip>
> We expect to have the next audit reports for WebTrust for CAs and WebTrust
> for EV by thanksgiving this year, and the report for WebTrust for BRs by the
> end of 2013.

New audit statements:
WebTrust for CAs: https://cert.webtrust.org/SealFile?seal=1613&file=pdf
WebTrust for EV: https://cert.webtrust.org/SealFile?seal=1614&file=pdf

Our auditors are still working on the WebTrust for BRs audit.

Comment 16

[Robin Alden]

Hi Kathleen,
    Here are our answers to the points you raised.

page 1:
Mozilla:
This SHA-384 "COMODO RSA Certification Authority" root certificate will eventually replace the SHA-1 "COMODO Certification Authority" root certificate that was included via Bugzilla Bug #401587.  
Is the above statement correct?

Comodo:
Yes, that is a correct statement.


Mozilla:
This SHA-384 "USERTrust RSA Certification Authority" root certificate will eventually replace the SHA-1 "UTN-USERFirst-Hardware", "UTN - DATACorp SGC", "UTN-USERFirst-Client Authentication and Email", and "UTN-USERFirst-Object" root certificates that were included via Bugzilla Bug #242610. 
Is the above statement correct?

Comodo:
Yes, that is a correct statement.

Mozilla:
This "USERTrust ECC Certification Authority" root certificate is the ECC version of the "USERTrust RSA Certification Authority" root certificate. 
Is the above statement correct?

Comodo:
Yes, that is a correct statement.


page 3
Mozilla: 
Are there currently externally-operated subCAs under the "COMODO Certification Authority" root certificate that will be transitioned to this root? 

Comodo: No, none.

Mozilla:
Are there currently externally operated subCAs under the existing four "UTN ..." root certificates that will be transitioned to this root?

Comodo:
Yes, some.
Regarding externally-operated subCAs issued from any of our existing roots and their potential transition to these new roots: previously, externally operated subCAs have (where not already compliant with v2.1 of Mozilla's policy) been overseen via contractual controls or technical monitoring supported by internal audit; Comodo is in the process of transitioning these clients before May 15, 2014 to either technical controls (nameConstraints) or audit with public disclosure as specified in Section 9 of the Mozilla CA Inclusion Policy.
As previously mentioned there are not yet any external subCAs under any of the new roots which are the subject of this bug and this situation is unlikely to change before May 15, 2014.

page 7
Mozilla:
"Technical Constraints on Third-party Issuers"
Please describe how it is ensured that only an internal Comodo RA does the domain control validation? 
i.e. Is it through the "Management Area" where RAs and Resellers are limited to what information they can verify? 
And then the "Management Area" requires a separate (Comodo automated or manual) approval of the domain name before the certificate request can be completed? 

Comodo:
Yes, RAs & resellers (& any other type of account holder other than an internal Comodo RA account) are not able to give any indication about whether or not DCV has been completed.
Server certificate requests placed with us always, without exception, hold until the domain name has been approved following either a Comodo-automated domain control validation or a manual approval given by an authorized Comodo internal RA operator.

Mozilla:
CPS section 1.10: Only Registration Authorities which hold their own WebTrust for CAs Certification may issue or cause the issuance of SSL certificates. 
Other Registration Authorities may
be enabled to perform validation of some or all of the subject identity information, but are not able to undertake domain control validation.

Comodo:  This was a statement introduced to implement and formalize our acceptance of Microsoft's requirement of us in their amendment to their CA program technical requirements dated April 6, 2011, that "3. Resellers and Registration Authorities (RAs) may not cause the issuance of certificates on behalf of a Program CA.  a). For purposes of the Program, a reseller or RA that can cause the issuance of certificates on behalf of a Program CA is in fact a sub-CA of the Program CA, and will be treated as an extension of the CA, and is subject to the same terms and conditions as the Program CA, including audit requirements by a qualified audit authority.".  
It is a forward-looking statement since we do not have any external RAs who have their own WebTrust audits and if we did we would include the interface between our systems and theirs within the scope of our respective WebTrust audits.

Mozilla:
"Network Security"
Confirm that you have performed the actions listed in #7 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

Comodo:
We confirm that we have performed the actions listed in #7 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices.

Mozilla: Document Handling of IDNs in CP/CPS
Comodo: The next revision of our CPS will document our handling of IDNs.
Every certificate request that includes one or more IDNs is flagged for manual review by an internal Comodo RA operator.

Mozilla: DNS names go in SAN
Comodo: Comodo follows the BRs (9.2.1 and 9.2.2) in our inclusion of DNS names in SANs.

Mozilla: Domain owned by a Natural Person
Comodo: When we issue a server certificate to an individual we put the person's name into the 'O' field of the certificate subject.

Mozilla:
Comodo does not delegate Domain validation to third parties – unless they get a separate WebTrust audit?
CPS section 1.10: "Only Registration Authorities which hold their own WebTrust for CAs Certification may issue or cause the issuance of SSL certificates. 
Other Registration Authorities may be enabled to perform validation of some or all of the subject identity information, but are not able to undertake domain control validation." 

Comodo:  This was a statement introduced to implement and formalize our acceptance of Microsoft's requirement of us in their amendment to their CA program technical requirements dated April 6, 2011, that "3. Resellers and Registration Authorities (RAs) may not cause the issuance of certificates on behalf of a Program CA.  a). For purposes of the Program, a reseller or RA that can cause the issuance of certificates on behalf of a Program CA is in fact a sub-CA of the Program CA, and will be treated as an extension of the CA, and is subject to the same terms and conditions as the Program CA, including audit requirements by a qualified audit authority.".  
It is a forward-looking statement since we do not have any external RAs who have their own WebTrust audits and if we did we would include the interface between our systems and theirs within the scope of our respective WebTrust audits.

page 8
Mozilla:
Generic names for CAs Two of the roots in this request have: "O = The USERTRUST Network", and nothing in the Issuer field to indicate that Comodo owns the root. Please explain why this
"O" is meaningful. 

Comodo:
"USERTrust" and "The USERTRUST Network" are names that Comodo has used since its purchase of Usertrust Inc. assets in 2004.  We are carrying forward the use of this brand for the time being and we have trademark rights with respect to "USERtrust".

Mozilla:
Is there actually a registered organization and/or trademark named "The USERTRUST Network"? 

Comodo:
No.

Comment 17

[Kathleen Wilson]

Thanks for the information. 

According to my notes there are two remaining things that I need before I can start the public discussion:

1) Comment #7: Our current CPS is http://www.comodo.com/repository/Comodo_CA_CPS_4.0.pdf
We are (as of Nov 11 2013) preparing a new version of the CPS which will include mention of these new roots.

2) Comment #15: Our auditors are still working on the WebTrust for BRs audit.

Please add a comment to this bug when the updated CPS and the BR audit are available.

Comment 18

[Rob Stradling]

(In reply to Kathleen Wilson from comment #17)
<snip>
> Please add a comment to this bug when the updated CPS and the BR audit are
> available.

Kathleen, here's the BR audit statement:
https://cert.webtrust.org/SealFile?seal=1644&file=pdf

Robin, is the CPS update ready yet?

Comment 19

[Rob Stradling]

Attachment: Comodo CPS v4.1

Kathleen, I'm attaching our updated CPS (v4.1).  I believe we're now finally ready to enter the queue for public discussion!

Comment 20

[Kathleen Wilson]

Attachment: Completed CA Information Document

Comment 21

[Kathleen Wilson]

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

In the meantime, please update this bug when version 4.1 of the CPS has been added to http://www.comodo.com/about/comodo-agreements.php

Comment 22

[Rob Stradling]

(In reply to Kathleen Wilson from comment #21)
> This request has been added to the queue for public discussion. 
> https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion 

Thanks Kathleen.

> In the meantime, please update this bug when version 4.1 of the CPS has been
> added to http://www.comodo.com/about/comodo-agreements.php

It's there now.

Comment 23

[Kathleen Wilson]

I am now opening the first public discussion period for this request from Comodo to include the “COMODO RSA Certification Authority”, “USERTrust RSA Certification Authority”, and “USERTrust ECC Certification Authority” root certificates and turn on all three trust bits and enable EV treatment for the new roots.

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.

The discussion thread is called “Comodo Request to Include Renewed Roots”.

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

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

Comment 24

[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/about/governance/policies/security-group/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 include the “COMODO RSA Certification Authority”, “USERTrust RSA Certification Authority”, and “USERTrust ECC Certification Authority” root certificates and turn on all three trust bits and enable EV treatment for the new roots.

Section 4 [Technical]. I am not aware of instances where Comodo has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug.

Section 6 [Relevancy and Policy]. Comodo appears to provide a service relevant to Mozilla users: It is a commercial CA offering certificates to customers worldwide. These new root certificates are intended to eventually replace root certificates currently included in the NSS root store.

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 CPS documents which are provided in English.

Document Repository: http://www.comodo.com/about/comodo-agreements.php
CPS: http://www.comodo.com/repository/Comodo_CA_CPS_4.1.4_clean.pdf
EV CPS: http://www.comodo.com/repository/EV_CPS_4_JUN_07.pdf
Addendum to EV CPS: http://www.comodo.com/repository/EV_CPS_Amendment-June_2009.pdf

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

* SSL: Comodo verifies the Applicant’s control of the domain name to be included in the certificate in accordance to the CA/Browser Forum Baseline Requirements and as described in section 3.2.2.1 of the CPS.

* Email: According to section 3.2.5.1 and 3.2.7.1 of the CPS, Comodo validates the right for the Applicant to use the submitted email address via a challenge and response check made to the email address submitted during the Certificate application.

* Code: Comodo verifies the legal existence of the organization requesting the certificate, and the identity and authority of the certificate subscriber, as documented in section 3.2.2.2 of the CPS and section 4.2 of the EV CPS and the Addendum to the EV CPS.

Section 18 [Certificate Hierarchy]. 
* The new SHA-384 “COMODO RSA Certification Authority” root certificate will eventually replace the SHA-1 “COMODO Certification Authority” root certificate that was included via Bugzilla Bug #401587.
“COMODO RSA Certification Authority” currently has the following internally-operated sub-CAs:
- COMODO RSA Extended Validation Secure Server CA
- COMODO RSA Client Authentication and Secure Email CA
- COMODO RSA Code Signing CA
The following internally-operated sub-CAs are also planned:
- (name tbd) for OV Server certificates
- (name tbd) for DV Server certificates
- (names tbd) to partition the sales of resellers, some bearing the name of the reseller in the subject and others bearing the Comodo name.
* The new SHA-384 “USERTrust RSA Certification Authority” root certificate will eventually replace the SHA-1 “UTN-USERFirst-Hardware”, “UTN - DATACorp SGC”, “UTN-USERFirst-Client Authentication and Email”, and “UTN-USERFirst-Object” root certificates that were included via Bugzilla Bug #242610.
“USERTrust RSA Certification Authority” currently has the following internally-operated subCA:
- USERTrust RSA Extended Validation Secure Server CA
The following internally-operated sub-CAs are also planned:
- USERTrust RSA Client Authentication and Secure Email CA
- USERTrust RSA Code Signing CA
- (name tbd) for OV Server certificates
- (name tbd) for DV Server certificates
- (names tbd) to partition the sales of resellers, some bearing the name of the reseller in the subject and others bearing the UserTrust name.
* The “USERTrust ECC Certification Authority” root certificate is the ECC version of the “USERTrust RSA Certification Authority” root certificate.

* EV Policy OID: 1.3.6.1.4.1.6449.1.2.1.5.1
** EV treatment is requested for all three new root certs.

* OCSP
http://ocsp.comodoca.com
http://ocsp.usertrust.com
http://ocsp.trust-provider.com

* Potentially Problematic Practices 
(http://wiki.mozilla.org/CA:Problematic_Practices)

** Comodo currently issues Wildcard DV certificates. 
CPS section 1.4.1: Wildcard Certificates are Certificates that cover sub-domains of any single domain.
See CPS section 3.2.2.1 for domain control validation for DV SSL certs.

** CPS section 1.3.2, Registration Authorities: RAs act locally within their own context of geographical or business partnerships on approval and authorization by Comodo in accordance with Comodo practices and procedures.
Comodo extends the use of RAs for its Web Host Reseller, Enterprise Public Key Infrastructure (EPKI) Manager and, optionally, Powered SSL programs. Upon successful approval to join the respective programs the Web Host Reseller Subscriber, EPKI Manager Subscriber or Powered SSL Subscriber are permitted to act as an RA on behalf of Comodo. RAs are restricted to operating within the set validation guidelines published by Comodo to the RA upon joining the programs. Certificates issued through an RA contain an amended Certificate Profile within an issued Certificate to represent the involvement of the RA in the issuance process to the Relying Party.
Only RAs which hold their own WebTrust for CAs Certification may issue or cause the issuance of SSL Certificates. Other RAs may be enabled to perform validation of some or all of the subject identity information, but are not able to undertake domain control validation.
RAs may only undertake their validation duties from pre-approved systems which are identified to the CA by various means that always include but are not limited to the white-listing of the IP address from which the RA operates.
Comodo operates a number of intermediate CAs from which it issues certificates for which some part of the validation has been performed by a Registration Authority. Some of the intermediate CAs are dedicated to the work of a single RA, whilst others are dedicated to the work of multiple related RAs.
** CPS section 1.3.2.1, Internal Registration Authority: For the issuance of Secure Server Certificates this RA is also equipped with automated systems that validate domain control. For that minority of Secure Server Certificates for which the validation of domain control is not possible by completely automated means, the specially trained and vetted staff that Comodo employs in its RA have the ability to cause the issuance of Certificates – but only when they are authenticated to Comodo’s issuance systems using twofactor authentication.
** CPS section 1.3.2.2, Web Host Resellers: Web Host Resellers do not validate domain control for Secure Server Certificates. This element of the validation of Secure Server Certificates is always performed by Comodo’s internal RA as described in 1.3.2.1.


Sections 11-14 [Audit].  
* Annual audits are performed by Ernst & Young according to the WebTrust criteria.
WebTrust CA: https://cert.webtrust.org/SealFile?seal=1613&file=pdf  
WebTrust EV: https://cert.webtrust.org/SealFile?seal=1614&file=pdf
BR: https://cert.webtrust.org/SealFile?seal=1644&file=pdf 

Based on this assessment I intend to approve this request to include the “COMODO RSA Certification Authority”, “USERTrust RSA Certification Authority”, and “USERTrust ECC Certification Authority” root certificates and turn on all three trust bits and enable EV treatment for the new roots.

Comment 25

[Kathleen Wilson]

As per the summary in Comment #24, and on behalf of Mozilla I approve this request from Comodo to include the following root certificates:

** “COMODO RSA Certification Authority” (websites, email, code signing), enable EV
** “USERTrust RSA Certification Authority” (websites, email, code signing), enable EV
** “USERTrust ECC Certification Authority” (websites, email, code signing), enable EV

I will file the NSS and PSM bugs for the approved changes.

Comment 26

[Kathleen Wilson]

I have filed bug #1062589 against NSS and bug #1062600 against PSM for the actual changes.

Comment 27

[Rob Stradling]

Hi Kathleen.  New WebTrust audit reports...

CA: https://cert.webtrust.org/SealFile?seal=1743&file=pdf
EV: https://cert.webtrust.org/SealFile?seal=1746&file=pdf
BR: https://cert.webtrust.org/SealFile?seal=1742&file=pdf