Closed Bug 401587 Opened 18 years ago Closed 16 years ago

add Comodo EV root certificates

Categories

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

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: Robin.Alden, Assigned: hecker)

References

(
URL
)

Details

(Whiteboard: EV - information incomplete for some certs)

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.04506.30) Build Identifier: Please could you: Add one new CA certificate to the Mozilla Root program for us. Amend the Trust Indicators associated with our CA certificates. Enable our root certificates for EV. The CA Details are in the "Additional Information" section. This has details of 11 CA certificates which are already in your root program plus one we would like to add. Regards Robin Alden Comodo CA Limited Reproducible: Always CA Details ---------- CA Name: Comodo CA Ltd Website: www.comodo.com One Paragraph Summary of CA: The Comodo companies provide the infrastructure that is essential in enabling e-merchants, other Internet-connected companies, software companies, and individual consumers to interact and conduct business via the Internet safely and securely. The Comodo companies offer PKI SSL, Code Signing, Content Verification and E-Mail Certificates; award winning PC security software; vulnerability scanning services for PCI Compliance; secure e-mail and fax services. Continual innovation, a core competence in PKI, and a commitment to reversing the growth of Internet-crime distinguish the Comodo companies as vital players in the Internet's ongoing development. Comodo secures and authenticates online transactions and communications for over 200,000 business customers and 3,000,000 users of our desktop security products. Comodo CA Ltd. is a commercial CA. Although we are a UK Limited Company we deal with customers throughout the world both directly and through partners. We have 124 subordinate CAs signed by the root CAs listed below. Some of them exist to differentiate between different Comodo brands or products and some are used to re-brand products for our partners. In each case we retain the private key for the subordinate CA within our infrastructure. Audit Type (WebTrust, ETSI etc.): WebTrust for Certification Authorities (CAs) Auditor: KPMG LLP 1 The Embankment Neville Street Leeds LS1 4DW United Kingdom Auditor Website: http://www.kpmg.co.uk Audit Document URL(s): https://cert.webtrust.org/SealFile?seal=636&file=pdf http://www.comodo.com/repository/ev_audit_report_and_management_assertions.pdf Certificate Details ------------------- Certificate Name: AddTrust Class 1 CA Root Certificate URL: http://crt.comodoca.com/AddTrustClass1CARoot.crt Version: X.509v3 SHA1 Fingerprint: CCAB0EA04C2301D6697BDD379FCD12EB24E3949D MD5 Fingerprint: 1E42950233926BB95FC07FDAD6B24BFC Modulus Length (a.k.a. "key length"): 2048-bit RSA Valid From (YYYY-MM-DD): 2000-05-30 Valid To (YYYY-MM-DD): 2020-05-30 CRL URL: http://crl.comodoca.com/AddTrustClass1CARoot.crl OCSP URL: it will be http://ocsp.comodoca.com Class (domain-validated, identity-validated or EV): All 3 Requested Trust Indicators (email and/or SSL and/or code): All 3 (This Root Certificate is already present in the Mozilla Root Program, but we want the following changes... - Enable it for EV - our EV Policy OID is 1.3.6.1.4.1.6449.1.2.1.5.1 - Enable the "code" Trust Indicator ) Certificate Name: AddTrust External CA Root Certificate URL: http://crt.comodoca.com/AddTrustExternalCARoot.crt Version: X.509v3 SHA1 Fingerprint: 02FAF3E291435468607857694DF5E45B68851868 MD5 Fingerprint: 1D3554048578B03F42424DBF20730A3F Modulus Length (a.k.a. "key length"): 2048-bit RSA Valid From (YYYY-MM-DD): 2000-05-30 Valid To (YYYY-MM-DD): 2020-05-30 CRL URL: http://crl.comodoca.com/AddTrustExternalCARoot.crl OCSP URL: it will be http://ocsp.comodoca.com Class (domain-validated, identity-validated or EV): All 3 Requested Trust Indicators (email and/or SSL and/or code): All 3 (This Root Certificate is already present in the Mozilla Root Program, but we want the following changes... - Enable it for EV - our EV Policy OID is 1.3.6.1.4.1.6449.1.2.1.5.1 ) Certificate Name: AddTrust Public CA Root Certificate URL: http://crt.comodoca.com/AddTrustPublicCARoot.crt Version: X.509v3 SHA1 Fingerprint: 2AB628485E78FBF3AD9E7910DD6BDF99722C96E5 MD5 Fingerprint: C1623E23C582739C03594B2BE977497F Modulus Length (a.k.a. "key length"): 2048-bit RSA Valid From (YYYY-MM-DD): 2000-05-30 Valid To (YYYY-MM-DD): 2020-05-30 CRL URL: http://crl.comodoca.com/AddTrustPublicCARoot.crl OCSP URL: it will be http://ocsp.comodoca.com Class (domain-validated, identity-validated or EV): All 3 Requested Trust Indicators (email and/or SSL and/or code): All 3 (This Root Certificate is already present in the Mozilla Root Program, but we want the following changes... - Enable it for EV - our EV Policy OID is 1.3.6.1.4.1.6449.1.2.1.5.1 - Ensure that all 3 Trust Indicators are enabled, 'cos they have been disabled in some versions of Netscape/Mozilla/Firefox!! ) Certificate Name: AddTrust Qualified CA Root Certificate URL: http://crt.comodoca.com/AddTrustQualifiedCARoot.crt Version: X.509v3 SHA1 Fingerprint: 4D2378EC919539B5007F758F033B211EC54D8BCF MD5 Fingerprint: 27EC3947CDDA5AAFE29A016521A94CBB Modulus Length (a.k.a. "key length"): 2048-bit RSA Valid From (YYYY-MM-DD): 2000-05-30 Valid To (YYYY-MM-DD): 2020-05-30 CRL URL: http://crl.comodoca.com/AddTrustQualifiedCARoot.crl OCSP URL: it will be http://ocsp.comodoca.com Class (domain-validated, identity-validated or EV): All 3 Requested Trust Indicators (email and/or SSL and/or code): All 3 (This Root Certificate is already present in the Mozilla Root Program, but we want the following changes... - Enable it for EV - our EV Policy OID is 1.3.6.1.4.1.6449.1.2.1.5.1 ) Certificate Name: UTN - DATACorp SGC Certificate URL: http://crt.comodoca.com/UTN-DATACorpSGC.crt Version: X.509v3 SHA1 Fingerprint: 58119F0E128287EA50FDD987456F4F78DCFAD6D4 MD5 Fingerprint: B3A53E77216DAC4AC0C9FBD5413DCA06 Modulus Length (a.k.a. "key length"): 2048-bit RSA Valid From (YYYY-MM-DD): 1999-06-24 Valid To (YYYY-MM-DD): 2019-06-24 CRL URL: http://crl.comodoca.com/UTN-DATACorpSGC.crl OCSP URL: it will be http://ocsp.comodoca.com Class (domain-validated, identity-validated or EV): All 3 Requested Trust Indicators (email and/or SSL and/or code): All 3 (This Root Certificate is already present in the Mozilla Root Program, but we want the following changes... - Enable it for EV - our EV Policy OID is 1.3.6.1.4.1.6449.1.2.1.5.1 - Enable the "email" and "code" Trust Indicators ) Certificate Name: UTN-USERFirst-Client Authentication and Email Certificate URL: http://crt.comodoca.com/UTN-USERFirst-ClientAuthenticationandEmail.crt Version: X.509v3 SHA1 Fingerprint: B172B1A56D95F91FE50287E14D37EA6A4463768A MD5 Fingerprint: D7343DEF1D270928E131025B132BDDF7 Modulus Length (a.k.a. "key length"): 2048-bit RSA Valid From (YYYY-MM-DD): 1999-07-09 Valid To (YYYY-MM-DD): 2019-07-09 CRL URL: http://crl.comodoca.com/UTN-USERFirst-ClientAuthenticationandEmail.crl OCSP URL: it will be http://ocsp.comodoca.com Class (domain-validated, identity-validated or EV): All 3 Requested Trust Indicators (email and/or SSL and/or code): All 3 (This Root Certificate is already present in the Mozilla Root Program, but we want the following changes... - Enable it for EV - our EV Policy OID is 1.3.6.1.4.1.6449.1.2.1.5.1 - Enable the "SSL" and "code" Trust Indicators ) Certificate Name: UTN-USERFirst-Hardware Certificate URL: http://crt.comodoca.com/UTN-USERFirst-Hardware.crt Version: X.509v3 SHA1 Fingerprint: 0483ED3399AC3608058722EDBC5E4600E3BEF9D7 MD5 Fingerprint: 4C5641E50DBB2BE8CAA3ED1808AD4339 Modulus Length (a.k.a. "key length"): 2048-bit RSA Valid From (YYYY-MM-DD): 1999-07-09 Valid To (YYYY-MM-DD): 2019-07-09 CRL URL: http://crl.comodoca.com/UTN-USERFirst-Hardware.crl OCSP URL: it will be http://ocsp.comodoca.com Class (domain-validated, identity-validated or EV): All 3 Requested Trust Indicators (email and/or SSL and/or code): All 3 (This Root Certificate is already present in the Mozilla Root Program, but we want the following changes... - Enable it for EV - our EV Policy OID is 1.3.6.1.4.1.6449.1.2.1.5.1 - Enable the "email" and "code" Trust Indicators ) Certificate Name: UTN-USERFirst-Object Certificate URL: http://crt.comodoca.com/UTN-USERFirst-Object.crt Version: X.509v3 SHA1 Fingerprint: E12DFB4B41D7D9C32B30514BAC1D81D8385E2D46 MD5 Fingerprint: A7F2E41606411150306B9CE3B49CB0C9 Modulus Length (a.k.a. "key length"): 2048-bit RSA Valid From (YYYY-MM-DD): 1999-07-09 Valid To (YYYY-MM-DD): 2019-07-09 CRL URL: http://crl.comodoca.com/UTN-USERFirst-Object.crl OCSP URL: it will be http://ocsp.comodoca.com Class (domain-validated, identity-validated or EV): All 3 Requested Trust Indicators (email and/or SSL and/or code): All 3 (This Root Certificate is already present in the Mozilla Root Program, but we want the following changes... - Enable it for EV - our EV Policy OID is 1.3.6.1.4.1.6449.1.2.1.5.1 - Enable the "email" and "SSL" Trust Indicators ) Certificate Name: AAA Certificate Services Certificate URL: http://crt.comodoca.com/AAACertificateServices.crt Version: X.509v3 SHA1 Fingerprint: D1EB23A46D17D68FD92564C2F1F1601764D8E349 MD5 Fingerprint: 497904B0EB8719AC47B0BC11519B74D0 Modulus Length (a.k.a. "key length"): 2048-bit RSA Valid From (YYYY-MM-DD): 2004-01-01 Valid To (YYYY-MM-DD): 2028-12-31 CRL URL: http://crl.comodoca.com/AAACertificateServices.crl OCSP URL: it will be http://ocsp.comodoca.com Class (domain-validated, identity-validated or EV): All 3 Requested Trust Indicators (email and/or SSL and/or code): All 3 (This Root Certificate is already present in the Mozilla Root Program, but we want the following changes... - Enable it for EV - our EV Policy OID is 1.3.6.1.4.1.6449.1.2.1.5.1 ) Certificate Name: Secure Certificate Services Certificate URL: http://crt.comodoca.com/SecureCertificateServices.crt Version: X.509v3 SHA1 Fingerprint: 4A65D5F41DEF39B8B8904A4AD3648133CFC7A1D1 MD5 Fingerprint: D3D9BDAE9FAC6724B3C81B52E1B9A9BD Modulus Length (a.k.a. "key length"): 2048-bit RSA Valid From (YYYY-MM-DD): 2004-01-01 Valid To (YYYY-MM-DD): 2028-12-31 CRL URL: http://crl.comodoca.com/SecureCertificateServices.crl OCSP URL: it will be http://ocsp.comodoca.com Class (domain-validated, identity-validated or EV): All 3 Requested Trust Indicators (email and/or SSL and/or code): All 3 (This Root Certificate is already present in the Mozilla Root Program, but we want the following changes... - Enable it for EV - our EV Policy OID is 1.3.6.1.4.1.6449.1.2.1.5.1 ) Certificate Name: Trusted Certificate Services Certificate URL: http://crt.comodoca.com/TrustedCertificateServices.crt Version: X.509v3 SHA1 Fingerprint: E19FE30E8B84609E809B170D72A8C5BA6E1409BD MD5 Fingerprint: 911B3F6ECD9EABEE07FE1F71D2B36127 Modulus Length (a.k.a. "key length"): 2048-bit RSA Valid From (YYYY-MM-DD): 2004-01-01 Valid To (YYYY-MM-DD): 2028-12-31 CRL URL: http://crl.comodoca.com/TrustedCertificateServices.crl OCSP URL: it will be http://ocsp.comodoca.com Class (domain-validated, identity-validated or EV): All 3 Requested Trust Indicators (email and/or SSL and/or code): All 3 (This Root Certificate is already present in the Mozilla Root Program, but we want the following changes... - Enable it for EV - our EV Policy OID is 1.3.6.1.4.1.6449.1.2.1.5.1 ) Certificate Name: COMODO Certification Authority Certificate URL: http://crt.comodoca.com/COMODOCertificationAuthority.crt Version: X.509v3 SHA1 Fingerprint: 6631BF9EF74F9EB6C9D5A60CBA6ABED1F7BDEF7B MD5 Fingerprint: 5C48DCF74272EC56946D1CCC71358075 Modulus Length (a.k.a. "key length"): 2048-bit RSA Valid From (YYYY-MM-DD): 2006-12-01 Valid To (YYYY-MM-DD): 2029-12-31 CRL URL: http://crl.comodoca.com/COMODOCertificationAuthority.crl OCSP URL: it will be http://ocsp.comodoca.com Class (domain-validated, identity-validated or EV): All 3 Requested Trust Indicators (email and/or SSL and/or code): All 3 (This Root Certificate is *not* yet present in the Mozilla Root Program. Please also... - Enable it for EV - our EV Policy OID is 1.3.6.1.4.1.6449.1.2.1.5.1 )
I notice that several other CAs' recent Root Certificate Addition requests have progressed to "NEW" or "ASSI", whereas this request from COMODO remains "UNCO"nfirmed. http://www.mozilla.org/projects/security/certs/pending/ doesn't mention COMODO either. I just want to make sure that this request doesn't get overlooked.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: EV
Independent of approval process, for technical testing purposes: Could you please supply an https:// URL to an example SSL server (customer or demo) that uses a server cert issued (directly or through intermediates) by this root? Should you request multiple roots to be enabled for EV, please provide one example URL for each root. Thank you.
I've added an entry for Comodo to the pending list: http://www.mozilla.org/projects/security/certs/pending/#Comodo Please double check all the information in the entry. In particular, I'm a bit confused by the plethora of Comodo CPSs and addendums thereto that are listed at http://www.comodo.com/repository/index.html For each root CA, please indicate exactly which CPSs and CPS addendums apply to that particular root and its subordinates.
(In reply to comment #2) Kai, we're in the process of setting up some new test sites for each of our Roots. I notice that you said "uses a server cert" rather than "uses an EV server cert". Does this mean that non-EV certs would be sufficient for your testing purposes? Also, just FYI (with Bug #405139 and others in mind), we will include the CRL Distribution Points extension in these test certificates, but we're not planning to include an OCSP Responder URL (in the Authority Info Access extension).
(In reply to comment #3) Frank, FYI, Robin Alden will soon be posting a comment to clarify our CPSs/addendums. (In reply to comment #4) Nobody's replied to my question, but in the interest of moving things along, below are some test site URLs for each of our Roots. Each of these test sites uses a non-EV SSL Certificate, issued directly from the appropriate Root. Each site certificate refers to a CRL Distribution Point but does not refer to an OCSP Responder. https://addtrustclass1caroot.comodoca.com https://addtrustexternalcaroot.comodoca.com https://addtrustpubliccaroot.comodoca.com https://addtrustqualifiedcaroot.comodoca.com https://utndatacorpsgc.comodoca.com https://utnuserfirstclientauthenticationandemail.comodoca.com https://utnuserfirsthardware.comodoca.com https://utnuserfirstobject.comodoca.com https://aaacertificateservices.comodoca.com https://securecertificateservices.comodoca.com https://trustedcertificateservices.comodoca.com https://comodocertificationauthority.comodoca.com Also, here is 1 test site with an EV SSL Certificate: https://comodocertificationauthority-ev.comodoca.com Please let me know if you need any further test sites.
(In reply to Frank's comment #3) Certificate CPS Details ------------------- In each case, unless otherwise stated, the request for the extra classes and trust indicators is made in order that, if we do want to issue certificates of those types in the future, those certificates would be trusted by platforms back to Firefox 3.0. We will amend our published CPS to include the new types of certificates before issuing them to customers according to the amendment policy of our Certificate Policy Authority. Certificate Name: AddTrust Class 1 CA Root CPS:- This root has not yet been used for server certificate issuance - except for the issuance of a test certificate for proof of concept. Certificate Name: AddTrust External CA Root CPS:- This root is used for server certificate issuance today and is covered in the following CPS docs (all from http://www.comodo.com/repository) : December_2007_CPS_Amendment.pdf Essential_SSL_addendum_to_the_Certification_Practice_Statement.pdf PositiveSSL_addendum_to_the_Certification_Practice_Statement.pdf litessl_cps_addendum.pdf Certificate Name: AddTrust Public CA Root CPS:- This root has not yet been used for server certificate issuance - except for the issuance of a test certificate for proof of concept. Certificate Name: AddTrust Qualified CA Root CPS:- This root has not yet been used for server certificate issuance - except for the issuance of a test certificate for proof of concept. Certificate Name: UTN - DATACorp SGC CPS: This root is used for server certificate issuance today, and is covered in the following CPS docs:- EV_CPS_4_JUN_07.pdf 09_22_2006_Certification_Practice_Statement_v.3.0.pdf Certificate Name: UTN-USERFirst-Client Authentication and Email CPS:- This root is used for client certificate issuance today and is covered in 09_22_2006_Certification_Practice_Statement_v.3.0.pdf Certificate Name: UTN-USERFirst-Hardware CPS:- This root is used for server certificate issuance today and is covered in the following CPS docs:- December_2007_CPS_Amendment.pdf Essential_SSL_addendum_to_the_Certification_Practice_Statement.pdf PositiveSSL_addendum_to_the_Certification_Practice_Statement.pdf litessl_cps_addendum.pdf Certificate Name: UTN-USERFirst-Object CPS:- This root has not yet been used for server certificate issuance - except for the issuance of a test certificate for proof of concept. Certificate Name: AAA Certificate Services CPS:- This root is used for client certificate issuance today. It is also used for server certificate issuance and is covered in these CPS docs:- November_2007_CPS_Amendment.pdf CPS_Amendment_Intel_Pro.pdf CPS_Amendment_of_Version_3_UCC.pdf Certificate Name: Secure Certificate Services CPS:- This root has not yet been used for server certificate issuance - except for the issuance of a test certificate for proof of concept. Certificate Name: Trusted Certificate Services CPS:- This root has not yet been used for server certificate issuance - except for the issuance of a test certificate for proof of concept. Certificate Name: COMODO Certification Authority CPS: This root is used for server certificate issuance today, and is covered in the following CPS doc:- EV_CPS_4_JUN_07.pdf Please let me know if any further information is needed.
(in reply to comment #3) > I've added an entry for Comodo to the pending list: > http://www.mozilla.org/projects/security/certs/pending/#Comodo > Please double check all the information in the entry. A couple of minor errors I've just noticed on that pending certificates webpage... UTN-USERFirst-Hardware The SHA1 hash is missing. It should be: 04:83:ED:33:99:AC:36:08:05:87:22:ED:BC:5E:46:00:E3:BE:F9:D7 UTN-USERFirst-Object The CRL Distribution Point URL is incorrect. It should be: http://crl.comodoca.com/UTN-USERFirst-Object.crl Secure Certificate Services The SHA1 hash is missing. It should be: 4A:65:D5:F4:1D:EF:39:B8:B8:90:4A:4A:D3:64:81:33:CF:C7:A1:D1 ALL 12 Roots The OCSP Responder URL is not specified correctly. It should be: http://ocsp.comodoca.com NOTE: We do not yet include this OCSP Responder URL in the AIA extension in most certificates we issue, mainly due to bug #419030.
(In reply to comment #7) > A couple of minor errors I've just noticed on that pending certificates > webpage... I've corrected all the errors listed in comment #7 and have checked in a new copy of the pending list. I have not yet addressed the CP/CPS corrections from comment #6; that will be next.
(In reply to comment #4) > (In reply to comment #2) > Kai, we're in the process of setting up some new test sites for each of our > Roots. > > I notice that you said "uses a server cert" rather than "uses an EV server > cert". Does this mean that non-EV certs would be sufficient for your testing > purposes? Since the certs in question are already in Firefox et.al., they presumably already work with non-EV certs. Kai's intent was to get URLs for sites with EV certs he could use to check EV functionality for each of the roots.
(In reply to comment #6) > Certificate Name: AddTrust Class 1 CA Root > CPS:- This root has not yet been used for server certificate issuance - except > for the issuance of a test certificate for proof of concept. You didn't specify a CPS here. Is this CA covered by the umbrella CPS or the EV CPS (or indeed any CPS)? It is not mentioned in either document except in the list at the back. Pending resolution of this question I'm removing the document references for this CA in the pending list. > Certificate Name: AddTrust External CA Root > CPS:- This root is used for server certificate issuance today and is covered in > the following CPS docs (all from http://www.comodo.com/repository) : > December_2007_CPS_Amendment.pdf > Essential_SSL_addendum_to_the_Certification_Practice_Statement.pdf > PositiveSSL_addendum_to_the_Certification_Practice_Statement.pdf > litessl_cps_addendum.pdf I added these documents to the list of documents relevant to this root, in addition to the umbrella CPS and EV CPS (which reference this root in section 1.8). > Certificate Name: AddTrust Public CA Root > CPS:- This root has not yet been used for server certificate issuance - except > for the issuance of a test certificate for proof of concept. Same question as for AddTrust Class 1 CA: Is this CA covered by the umbrella CPS or the EV CPS (or indeed any CPS)? Pending resolution of this question I'm removing the document references for this CA in the pending list. > Certificate Name: AddTrust Qualified CA Root > CPS:- This root has not yet been used for server certificate issuance - except > for the issuance of a test certificate for proof of concept. Same question as for AddTrust Class 1 CA: Is this CA covered by the umbrella CPS or the EV CPS (or indeed any CPS)? Pending resolution of this question I'm removing the document references for this CA in the pending list. > Certificate Name: UTN - DATACorp SGC > CPS: This root is used for server certificate issuance today, and is covered in > the following CPS docs:- > EV_CPS_4_JUN_07.pdf > 09_22_2006_Certification_Practice_Statement_v.3.0.pdf These documents are already listed for this CA in the pending list, so no change is necessary. > Certificate Name: UTN-USERFirst-Client Authentication and Email > CPS:- This root is used for client certificate issuance today and is covered in > 09_22_2006_Certification_Practice_Statement_v.3.0.pdf Removing the reference to the EV CPS for this root, since it's not mentioned in that document. > Certificate Name: UTN-USERFirst-Hardware > CPS:- This root is used for server certificate issuance today and is covered in > the following CPS docs:- > December_2007_CPS_Amendment.pdf > Essential_SSL_addendum_to_the_Certification_Practice_Statement.pdf > PositiveSSL_addendum_to_the_Certification_Practice_Statement.pdf > litessl_cps_addendum.pdf Adding these document references in addition to the existing references to the umbrella CPS and the EV CPS. > Certificate Name: UTN-USERFirst-Object > CPS:- This root has not yet been used for server certificate issuance - except > for the issuance of a test certificate for proof of concept. This root is mentioned in umbrella CPS (section 1.8), but not in the EV CPS (except in passing); I'm therefore removing the reference to the EV CPS for this root. > Certificate Name: AAA Certificate Services > CPS:- This root is used for client certificate issuance today. It is also used > for server certificate issuance and is covered in these CPS docs:- > November_2007_CPS_Amendment.pdf > CPS_Amendment_Intel_Pro.pdf > CPS_Amendment_of_Version_3_UCC.pdf I've added these document references for this root to the existing reference to the umbrella CPS, and removed the reference to the EV CPS since this root isn't mentioned in that document except in passing. > Certificate Name: Secure Certificate Services > CPS:- This root has not yet been used for server certificate issuance - except > for the issuance of a test certificate for proof of concept. Same question as for AddTrust Class 1 CA: Is this CA covered by the umbrella CPS or the EV CPS (or indeed any CPS)? Pending resolution of this question I'm removing the document references for this CA in the pending list. > Certificate Name: Trusted Certificate Services > CPS:- This root has not yet been used for server certificate issuance - except > for the issuance of a test certificate for proof of concept. Same question as for AddTrust Class 1 CA: Is this CA covered by the umbrella CPS or the EV CPS (or indeed any CPS)? Pending resolution of this question I'm removing the document references for this CA in the pending list. > Certificate Name: COMODO Certification Authority > CPS: This root is used for server certificate issuance today, and is covered in > the following CPS doc:- > EV_CPS_4_JUN_07.pdf Is the reference to "Comodo Certification Authority" in section 1.9 of the umbrella CPS a reference to this root, or just a reference to Comodo in general? For now I've left the references to both documents as is. > Please let me know if any further information is needed. See the questions above, and please double check the changes I made to the document references for the various roots. I have some additional comments once you respond, but I don't want to get too far ahead of myself.
Making EV root cert requests have uniform summaries.
Summary: Please add Comodo EV root certificates to your root program. → add Comodo EV root certificates
(In reply to comment #10) > See the questions above, and please double check the changes I made to the > document references for the various roots. I have some additional comments once > you respond, but I don't want to get too far ahead of myself. In the interests of time I decided to go ahead and comment: Right now my top priority is processing applications for EV-capable roots in time for the Firefox 3 launch (if possible). This request is for EV upgrades for 12 separate roots. However of those 12 roots only 4 roots appear to be currently used for EV and are referenced in the EV CPS: AddTrust External CA Root, UTN - DATACorp SGC, UTN-USERFirst-Hardware, and COMODO Certification Authority. To save time I therefore propose to evaluate just those 4 requests for now, and postpone the others for post-Firefox 3. In fact, for that matter, why can't we just add the COMODO Certification Authority root and EV-enable it? From the EV CPS it appears that all the issuing CAs that issue EV certs (COMODO EV SSL CA and COMODO EV SGC CA) chain up to the COMDO Certification Authority, so if the COMODO Certification Authority root were pre-loaded in Firefox et.al. and associated with the EV OID, wouldn't path processing stop there and the EV certs be recognized?
(In reply to comment #12) Frank, Of the 4 roots you have identified as being covered for EV usage by our CPS(s) for our existing product range we would strongly urge you (beg with, plead with, etc) to EV enable all 4. We agree that on a good day with the wind behind us we would only need the COMODO Certification Authority root EV enabling to support our *current* product range, but given the hoops we have to jump through with cross-signing and beacon sites to make EV certificates work as EV certificates without warnings on IE7 on XP, and given the unresolved nature of bug #406755 we are not confident that enabling the single new root for EV will be sufficient. We would also like to get those other 8 EV enabled asap too, although I would put them at a slightly lower priority that the first 4 if we must make a distinction. These are not for today, but are for future product ranges. Most of them are embedded and EV enabled in MS IE already, and if/when we launch products with them we would love to be able to say these products work with Firefox 3.0+, rather than some later version.
(In reply to comment #13) > Of the 4 roots you have identified as being covered for EV usage by our > CPS(s) for our existing product range we would strongly urge you (beg with, > plead with, etc) to EV enable all 4. > We agree that on a good day with the wind behind us we would only need the > COMODO Certification Authority root EV enabling to support our *current* > product range, but given the hoops we have to jump through with cross-signing > and beacon sites to make EV certificates work as EV certificates without > warnings on IE7 on XP, and given the unresolved nature of bug #406755 we are > not confident that enabling the single new root for EV will be sufficient. After consulting with others who are doing some testing related to this, I've concluded that you are correct. I will therefore proceed to evaluate AddTrust External CA Root, UTN - DATACorp SGC, and UTN-USERFirst-Hardware for upgrades for EV, and COMODO Certification Authority for inclusion of the new root and an upgrade for EV. At the same time I'll evaluate the requests to have the "email" and "code" trust bits enabled for the UTN - DATACorp SGC and UTN-USERFirst-Hardware roots. I think I now have all the information I need for the 4 roots in question, so I've marked those parts of the Comodo entry in the pending list as complete. (You should see this new version show up in an hour or so.) If I've overlooked anything for those four CAs please let me know. > We would also like to get those other 8 EV enabled asap too, although I would > put them at a slightly lower priority that the first 4 if we must make a > distinction. These are not for today, but are for future product ranges. Most > of them are embedded and EV enabled in MS IE already, and if/when we launch > products with them we would love to be able to say these products work with > Firefox 3.0+, rather than some later version. A couple of points here: First. because of the Firefox automated update system almost all Firefox users run the very latest version. So if we can't get the other CAs upgraded in time for Firefox 3.0.0.0, but have to wait until Firefox 3.0.0.x, the resulting number of Firefox 3 instances that won't recognize EV certs from the other 8 hierarchies will likely be very small. Second, at this point you've made no official commitment (i.e., through your published CPSs) to actually adhere to the EV guidelines for certs issued through your other 8 hierarchies. Before having us upgrade the other 8 roots for EV use I'd like to at least see the Comodo EV CPS revised to bring those other 8 hierarchies "into the fold".
According to http://www.mozilla.org/projects/security/certs/pending/#Comodo the information for some of the certs in this application is incomplete, but is complete for certain others.
Whiteboard: EV → EV - information incomplete for some certs
I have now completed my review of Comodo's application for adding the COMODO Certification Authority root CA certificate and enabling it for EV use, per the official Mozilla CA certificate policy at: http://www.mozilla.org/projects/security/certs/policy/ I apologize for any delays on my part in doing the review. Here follows my final assessment. If anyone sees any factual errors, please point them out. NOTE: This assessment applies only to the COMODO Certification Authority root. I'll do assessments for the other Comodo roots later. Section 4 [Technical]. I'm not aware of any technical issues with certificates issued by Comodo under the COMODO Certification Authority hierarchy, or 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 report. Section 6 [Relevancy and Policy]. Comodo appears to provide a service relevant to Mozilla users; it is a commercial CA serving customers worldwide, and operates various CA services under the Comodo brand and others. Its policies for the COMODO Certification Authority are documented in the following CPSes: http://www.comodo.com/repository/09_22_2006_Certification_Practice_Statement_v.3.0.pdf http://www.comodo.com/repository/EV_CPS_4_JUN_07.pdf * Email: For email certificates Comodo at a minimum validates that the applicant controls the email account associated with the certificate. (See section 4.2.6 of the main CPS.) * SSL: For non-EV SSL certificates Comodo at a minimum validates that the applicant controls the domain associated with the certificate. (See sections 4.2.1 through 4.2.4 of the main CPS.) For EV SSL certificates Comodo validates applicant information in accordance with the EV guidelines. (See sections 4.2 and 4.3 of the EV CPS, among others.) * Code: For code signing certificates Comodo validates the identity of the certificate applicant. (See sections 4.2.8 and 4.2.1 of the main CPS.) Section 8-10 [Audit]. Comodo has successfully completed independent audits for the COMODO Certification Authority using the WebTrust for CAs criteria and the WebTrust EV criteria. The audits were done by KPMG. Attestation of the successful completion of the audits is in the form of standard WebTrust and WebTrust EV reports available at https://cert.webtrust.org/SealFile?seal=636&file=pdf http://www.comodo.com/repository/ev_audit_report_and_management_assertions.pdf Note that the WebTrust EV audit was done against the draft versions of the EV guidelines and WebTrust EV criteria. Audits are done on a regular basis, with frequency as specified by the EV guidelines (currently annual). (See section 1.6 of the EV CPS). Section 13 [Certificate Hierarchy]. At present the COMODO Certification Authority has two subordinate CAs, the COMODO EV SSL CA and the COMODO EV SGC CA, which issue the end entity certificates. (See section 1.8 of the EV CPS.) Other: Comodo updates and publishes a new CRL for end entity certificates every 24 hours, or more frequently under special circumstances (See section 2.3 of the EV CPS.) Comodo also operates an OCSP responder. Based on the above information, I am minded to approve the inclusion of the COMODO Certification Authority root in NSS (and thence in Firefox and other Mozilla-based products), with the trust bits for email, SSL, and code signing set, and the root's enabling for EV with policy OID 1.3.6.1.4.1.6449.1.2.1.5.1. Before I issue my final approval I'm opening up a period of public discussion of this request in the mozilla.dev.tech.crypto newsgroup [1]. Final approval is also contingent on verification with KPMG that the Comodo-supplied WebTrust EV report is valid. [1] The mozilla.dev.tech.crypto newsgroup is accessible via NNTP-capablen ewsreaders at: news://news.mozilla.org/mozilla.dev.tech.crypto via email by subscribing to the associated mailing list: https://lists.mozilla.org/listinfo/dev-tech-crypto and via the web at: http://groups.google.com/group/mozilla.dev.tech.crypto/topics
Why is Comodo announcing that their EV certificates are supported in Firefox 3.x if they are not accepted yet?: http://www.comodo.com/news/press_releases/14_02_08.html
(in reply to comment #17) > Why is Comodo announcing that their EV certificates are supported in Firefox > 3.x if they are not accepted yet?: Hi Marius. Our Marketing Department put out this press release without consulting those of us within Comodo who are actually following Mozilla's EV development effort closely. We know it is inaccurate, but with the forthcoming (we hope) inclusion of our EV Roots in Mozilla, we anticipate that this press release will prove to be prescient rather than just plain wrong. :-) I think our Marketing Department must have taken the Firefox 3 Beta 3 Release Notes at face value. http://www.mozilla.com/en-US/firefox/3.0b3/releasenotes simply says... "When a site uses Extended Validation (EV) SSL certificates, the site favicon button will turn green and show the name of the company you're connected to." IMHO, those Release Notes should have explained some of the caveats, rather than imply that "EV is now fully working!"
(in reply to comment #16) > I have now completed my review of Comodo's application for adding the COMODO > Certification Authority root CA certificate and enabling it for EV use... Thanks Frank. (further to comment #5, and in reply to comment #9) > Since the certs in question are already in Firefox et.al., they presumably > already work with non-EV certs. Kai's intent was to get URLs for sites with EV > certs he could use to check EV functionality for each of the roots. We have now set up EV test sites for each of the other Roots that are still waiting to be reviewed by Frank: https://addtrustclass1caroot-ev.comodoca.com https://addtrustexternalcaroot-ev.comodoca.com https://addtrustpubliccaroot-ev.comodoca.com https://addtrustqualifiedcaroot-ev.comodoca.com https://utndatacorpsgc-ev.comodoca.com https://utnuserfirstclientauthenticationandemail-ev.comodoca.com https://utnuserfirsthardware-ev.comodoca.com https://utnuserfirstobject-ev.comodoca.com https://aaacertificateservices-ev.comodoca.com https://securecertificateservices-ev.comodoca.com https://trustedcertificateservices-ev.comodoca.com
I have now completed my review of Comodo's application for enabling AddTrust External CA Root, UTN - DATACorp SGC, and UTN-USERFirst-Hardware for EV use and enabling all trust bits for the aforementioned roots, per the official Mozilla CA certificate policy at: http://www.mozilla.org/projects/security/certs/policy/ I apologize for any delays on my part in doing the review. Here follows my final assessment. If anyone sees any factual errors, please point them out. NOTE 1: Comodo's request in this bug encompasses 12 separate roots. This assessment applies *only* to AddTrust External CA Root, UTN - DATACorp SGC, and UTN-USERFirst-Hardware. I have already done an assessment for the new COMODO Certification Authority root; I'll do assessments for the remaining 8 Comodo roots later. NOTE 2: Although all these roots are already in NSS, in the interests of thoroughness I'll repeat all the evaluation steps as if they were new roots. NOTE 3: Comodo has separately applied to add a new root, COMODO Certification Authority, and enable it for EV use. As noted in section 1.8 of the Comodo EV CPS, that root's public key is cross-signed such that servers using Comodo EV certs will send cert chains terminating in one of these three roots. Section 4 [Technical]. I'm not aware of any technical issues with certificates issued by Comodo under the AddTrust External CA Root, UTN - DATACorp SGC, and UTN-USERFirst-Hardware hierarchies, or 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 report. Section 6 [Relevancy and Policy]. Comodo appears to provide a service relevant to Mozilla users; it is a commercial CA serving customers worldwide, and operates various CA services under the Comodo brand and others, including issuance of SSL certificates of multiple types (including Essential SSL, Positive SSL, InstantSSL, EnterpriseSSL, Optimum SSL, Comodo SGC, Platinum SGC, and EV), secure email and custom client certificates, object signing certificates, and time stamping certificates. Comodo's policies for AddTrust External CA Root, UTN - DATACorp SGC, and UTN-USERFirst-Hardware are documented in the following CPSes: http://www.comodo.com/repository/09_22_2006_Certification_Practice_Statement_v.3.0.pdf http://www.comodo.com/repository/EV_CPS_4_JUN_07.pdf http://www.comodo.com/repository/December_2007_CPS_Amendment.pdf http://www.comodo.com/repository/Essential_SSL_addendum_to_the_Certification_Practice_Statement.pdf http://www.comodo.com/repository/PositiveSSL_addendum_to_the_Certification_Practice_Statement.pdf http://www.comodo.com/repository/litessl_cps_addendum.pdf * Email: For email certificates Comodo at a minimum validates that the applicant controls the email account associated with the certificate. (See section 4.2.6 of the main Comodo CPS dated 2006/09/22.) * SSL: For non-EV SSL certificates Comodo at a minimum validates that the applicant controls the domain associated with the certificate. (See sections 2.4.1 and 4.2.1 through 4.2.4 of the main CPS, sections 2.4.1 and 4.2 of the EssentialSSL addendum, sections 2.4.1 and 4.2 of the PositiveSSL addendum, and sections 2.4.1 and 4.2 of the LiteSSL addendum.) For EV SSL certificates Comodo validates applicant information in accordance with the EV guidelines. (See sections 4.2 and 4.3 of the EV CPS, among others.) * Code: For code signing certificates Comodo validates the identity of the certificate applicant. (See sections 4.2.8 and 4.2.1 of the main CPS.) Section 8-10 [Audit]. Comodo has successfully completed independent audits for AddTrust External CA Root, UTN - DATACorp SGC, and UTN-USERFirst-Hardware using the WebTrust for CAs criteria and the WebTrust EV criteria. The audits were done by KPMG. Attestation of the successful completion of the audits is in the form of standard WebTrust and WebTrust EV reports available at https://cert.webtrust.org/SealFile?seal=636&file=pdf http://www.comodo.com/repository/ev_audit_report_and_management_assertions.pdf Note that the WebTrust EV audit was done against the draft versions of the EV guidelines and WebTrust EV criteria. Audits are done on a regular basis, with frequency as specified by the EV guidelines (currently annual). (See section 1.6 of the EV CPS). Section 13 [Certificate Hierarchy]. The three roots in question have one or more subordinate CAs, and also issue end entity certificates directly in some cases; the roots also are used in various cross-signing schemes. The Comodo CPS documents have (apparently) complete documentation of all the relevant CA relationships. (See section 1.8 of each of the main Comodo CPS, EV CPS, EssentialSSL addendum, PositiveSSL addendum, and LiteSSL addendum.) Other: Comodo updates and publishes a new CRL for end entity certificates every 24 hours, or more frequently under special circumstances (See section 3.7 of the main CPS and section 2.3 of the EV CPS.) Comodo also operates an OCSP responder, at least for EV end entity certificates. Based on the above information, I am minded to * reaffirm the inclusion of the AddTrust External CA Root, UTN - DATACorp SGC, and UTN-USERFirst-Hardware roots in NSS (and thence in Firefox and other Mozilla-based products); * approve enabling the trust bits for email, SSL, and code signing for all three roots; and * approve enabling all three roots for EV use, with policy OID 1.3.6.1.4.1.6449.1.2.1.5.1. Before I issue my final approval I'm opening up a period of public discussion of this request in the mozilla.dev.tech.crypto newsgroup [1]. Final approval is also contingent on verification with KPMG that the Comodo-supplied WebTrust EV report is valid. [1] The mozilla.dev.tech.crypto newsgroup is accessible via NNTP-capablen ewsreaders at: news://news.mozilla.org/mozilla.dev.tech.crypto via email by subscribing to the associated mailing list: https://lists.mozilla.org/listinfo/dev-tech-crypto and via the web at: http://groups.google.com/group/mozilla.dev.tech.crypto/topics
The public comment period has ended for the two separate items mentioned above in comment #16 and comment #20, namely the request to add and EV-enable the new COMODO Certification Authority root, and the request to enable for EV use the existing AddTrust External CA, UTN - DATACorp SGC, and UTN-USERFirst-Hardware roots. To avoid repeating myself I'll deal with both requests in one response. There were several issues raised in the public comment period; see the relevant m.d.t.crypto threads for full details: http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/fc7eaa37561a55ed# http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/aca31a1201ade57c# In particular there were two issues raised for which disagreement remains as to whether these issues should affect approval: * Comodo's issuance of wildcard DV certs. The specific concern is the ease by which an attacker controlling, e.g., example.com and getting a wildcard DV cert for *.example.com could set up multiple SSL-enabled phishing sites as subdomains of that domain (e.g., paypal.example.com, etrade.example.com, etc.), evading any protections the CA might have to reject suspect cert applications (e.g., checking subscriber domain names against a list of names likely to used in phishing attacks). * Comodo's issuance of domain-validated certificates with a long lifetime (up to 10 years). The specific concern is a potential exploit whereby an attacker could register a domain and obtain a DV cert for it, give up the domain and wait for someone else to register it, and then use the previously obtained (and still valid) DV cert in conjunction with DNS spoofing to execute a MITM attack on the current site at the domain. These practices are not specific to Comodo (i.e., other CAs issue long-lifetime DV certs and/or wildcard DV certs), are not new practices, and are independent of Comodo's issuance of EV certs (the subject of the present requests). These practices are also not specifically addressed by the current Mozilla CA policy (i.e., neither expressly permitted nor expressly prohibited), so any application of the policy to these practices rests on the policy language relating to general security considerations that might cause us to reject inclusion of a root. In considering these issues my options include approving the requests as is, making approval conditional on Comodo no longer issuing long-lived DV certs or wildcard SSL certs, or (as a last resort) rejecting the requests and directing that Comodo's root be removed. After thinking about this and posting my thoughts in m.d.t.crypto, in the end I don't think the potential security implications of the practices in question rise to the level that would justify my rejecting or holding up the requests, and I think that we have a clear security interest in enabling recognition of Comodo EV certs, so that Mozilla users can take advantage of the increased identity information provided by such certs. More specifically: With regard to wildcard SSL certs: The proposal here is to require Comodo (and potentially other CAs) not to issue wild card certs for domains where only control of the domain has been validated, but instead to require some form of verification of the subscriber's identity. There are multiple costs to implementing such an idea: a cost to Comodo and other CAs (who may have to change their procedures and product offerings), a cost to cert subscribers (who may have to pay more for certs), a cost to us (who have to figure out all the CAs doing wildcard DV certs, and then try to persuade them to change what they're doing), and potentially a cost to end users (e.g., if they can no longer access sites because we decide to punish CAs by removing their roots or disabling validation of certain wildcard certs). At the same time there are measures already in place to protect users against the general phishing threat, most notably the Firefox "phishing protection" features; these measures work against phishing sites using the hypothetical wildcard DV cert exploit, and against other phishing sites as well. There is also a general measure available to provide more assurance and accountability for web sites doing high-value SSL-enabled transactions, namely EV certs. The threat from wildcard DV certs is hypothetical, with no evidence known to me of such attacks actually being a problem in the real world. There are also legitimate uses of wildcard DV certs, e.g., to protect low-value transactions with multiple publicly accessible servers associated with a personal or small organizational domain. Since there are other measures already in place to protect users against phishing attacks, and EV certs available to protect high-value transactions conducted over SSL, I think the potential incremental security benefits of implementing the proposed ban on wildcard DV certs don't justify incurring the burden placed on legitimate uses and the associated costs for the various parties mentioned above. * With regard to long-lived DV certs: The proposal here is to require that Comodo (and other CAs) limit the lifetime of DV certs to some "reasonable" time period (e.g., 2 years). However limiting the lifetime in such a way does not prevent the proposed exploit, it simply reduces the amount of time during which it could occur. (This is especially true since a domain can be registered, a cert applied for and received, and then the domain returned for reuse, well before expiration of even a 1-year cert.) At the same time, while a longer cert lifetime increases the period of time during which the exploit could occur, it also makes the attack less economically feasible for attackers (since longer-lived certs cost more). As with the wildcart SSL issue, there appears to be no evidence that this potential exploit is actually a problem in the real world. To the extent that it might be a problem, it's not clear at all that it would be affected one way or another by allowing longer cert lifetimes. I can't therefore at this time justify mandating that CAs restrict cert lifetimes to some arbitrary limit as a condition for including their roots in Mozilla. In summary: While the wildcard DV cert and long-lived DV cert issues are not trivial, in my opinion they don't rise to a level that would justify me rejecting or delaying approval of Comodo's current EV-related requests as discussed in comment #16 and comment #20. I am therefore formally approving the requests, and will proceed to file NSS and PSM bugs for the associated code changes.
Filed bug 426568 and bug 426572 to add COMODO Certification Authority root and mark it for EV.
Depends on: 426575
Filed bug 426575 to enable AddTrust External CA, UTN - DATACorp SGC, and UTN-USERFirst-Hardware root for EV.
Depends on: 426572
Not sure this comment is right here, but I wanted to flag that I've had issues with the certificate with "UTN-USERFirst-Hardware". Specifically, I came across to versions of this certificate which raises a red flag for me re: the validity of this certificate and the security of its underlying private key. The first version of the certificate is the CA certificate that's built into Mozilla, serial number 44:be:0c:8b:50:00:24:b4:11:d3:36:2a:fe:65:0a:fd, and for which Comodo requests some changes as laid out above. The second version of this certificate is an intermediary CA certificate with serial number 52:42:06:4a:4f:37:fe:43:69:48:7a:96:67:ff:5d:27 and same (!!!) public key. You can download that certificate from https://www.hosteurope.de/support/CA/UTNAddTrustServerCA.pem for example (Host Europe is a big server hoster in Germany and is using UTN's wildcard certificate for the webservers its hosts for its clients). This second version is issued by Add Trust External Root CA, SHA-1 fingerprint 02:FA:F3:E2:91:43:54:68:60:78:57:69:4D:F5:E4:5B:68:85:18:68, which is also one of Mozilla's built-in certificates. The issue that raised a red flags for me is that both certificates have the same public key, but one is a self-signed CA certificate built into Mozilla, whereas the other is an intermediary CA issues by a CA that's also built into Mozilla. Shouldn't each certificate only be issued once, and shouldn't this especially hold for CA certificates? For me, the concern is whether "UTN-USERFirst-Hardware" is still trustworthy enough. I have not read your policy on CA certificates, but I hope that it would include some provision preventing this sort of confusion. I would like to urge you to clarify this with Comodo. Thanks, Christoph Here's the subject key id of the certificate that's built into Mozilla (e.g., in my Mozilla Firefox 2.0.0.14): a1 72 5f 26 1b 28 98 43 95 5d 07 37 d5 85 96 9d 4b d2 c3 45 Here's the subject key id of the certificate https://www.hosteurope.de/support/CA/UTNAddTrustServerCA.pem which is signed by "Add Trust External Root CA": A1:72:5F:26:1B:28:98:43:95:5D:07:37:D5:85:96:9D:4B:D2:C3:45
(In reply to comment #24) In the interests of clarity and full disclosure: Both the "UTN-USERFirst-Hardware" and "AddTrust External CA Root" CAs belong to Comodo. The set of platforms (and also the set of versions of platforms) which trust each of those CAs is not the same. In order to be able to issue end entity certificates which are trusted on the widest range of platforms possible with these roots we have "cross-signed" the "UTN-USERFirst-Hardware" CA certificate with the "AddTrust External CA Root" CA. > Shouldn't each certificate only be issued once, and > shouldn't this especially hold for CA certificates? Well yes, but RFC3280 tells us that "the issuer name and serial number identify a unique certificate". The two certificates you indicate do not have the same issuer, so cannot be examples of the same certificate. Besides, the serial numbers are different. > For me, the concern is whether "UTN-USERFirst-Hardware" is still > trustworthy enough. I don't feel that your concern is justified in this case. What do you perceive to be the problem?
Robin, do you want to explain why you are using the same keys for two different certificates? And how can you control certificates on a per-platform basis?
(In reply to comment #26) Eddy, you are already familiar with cross-signing. Most recently (in forums I am party to) in https://bugzilla.mozilla.org/show_bug.cgi?id=431621 . I'm not clear that any further elaboration of how it works technically is required here. I agree with what I understood you to be saying in that thread - that the superior CA is certifying (warrantying, assuring, etc) everything issued by the subordinate CA that is current during the lifetime of the cross-signing certificate. In our case this gives us no difficulties because we operate both CAs. If the subordinate CA was operated in any way by a third party then we would need assurances (contracts, etc) with the third party to ensure that end entity certificates were issued only in accordance with the policy of the superior CA. How do we control certificates per-platform? - We don't really. We just make sure all the needed certificates are available to (and / or trusted by) the platform and let it sort it out for itself.
(In reply to comment #25) > (In reply to comment #24) > In the interests of clarity and full disclosure: > Both the "UTN-USERFirst-Hardware" and "AddTrust External CA Root" CAs belong to > Comodo. > The set of platforms (and also the set of versions of platforms) which trust > each of those CAs is not the same. > In order to be able to issue end entity certificates which are trusted on the > widest range of platforms possible with these roots we have "cross-signed" the > "UTN-USERFirst-Hardware" CA certificate with the "AddTrust External CA Root" > CA. Understood. Why are you submitting *both* "UTN-USERFirst-Hardware" and "AddTrust External CA Root" for CAs to be included in Mozilla? Wouldn't it be sufficient to just include "AddTrust External CA Root"? If you have different platforms in mind with these two CAs, I can see no need for cross-signing other than including one of the platforms within the other. If this is the case, I'd opt for removing this redundancy to have clear chains of trust. > > Shouldn't each certificate only be issued once, and > > shouldn't this especially hold for CA certificates? > Well yes, but RFC3280 tells us that "the issuer name and serial number identify > a unique certificate". The two certificates you indicate do not have the same > issuer, so cannot be examples of the same certificate. Besides, the serial > numbers are different. Fair -- any certificate signed by "UTN-USERFirst-Hardware", however, is automatically considered signed by "AddTrust External CA Root" as well, that's the cross-signing. > > For me, the concern is whether "UTN-USERFirst-Hardware" is still > > trustworthy enough. > I don't feel that your concern is justified in this case. What do you perceive > to be the problem? I see the problem that there might be other cross-signers of "UTN-USERFirst-Hardware" with different policies and thus higher level of trust, and it might be helpful to have an assurance which other cross-signers exist to be certain that there are no unintended consequences of this - i.e. higher level of trust through another co-signer. I do not have a deep enough understanding of the way Mozilla deals with the case of multiple chains of trust.
:-) It would be good that you'd explain it to Christoph. I'm not in the position to explain which cross-signing you performed and which certificate chains to what exactly. Yes, perhaps you should elaborate, which might be also in your interest.
Robin, sorry for this confusion. I just saw the discussion on m.d.t.crypto: http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/220d1e49e7c4479c/d78e5300bed24cf7 Then I also went through the CPS and read about the cross-signing practice, sorry Robin for not reading that in the first place. I also checked the OCSP responder http://ocsp.comodoca.com with the two UTN certificates (both the chained one through AddTrust and the real CA one) using openssl and it all worked out nicely. To the Mozilla community: I now learned that the problem may be that my ISP in South Africa (Vodacom) seems to be blocking DNS lookup of usertrust.com, thus Firefox would not be able to download the CRL and stop working. FF2 started bringing up OCSP validation error message -8048 (general OCPS validation error). Is there a nicer way of displaying what is actually going wrong? I.e. saying that either the CRL cannot be downloaded, the OCSP server cannot be reached, CRL is invalid or OCSP response cannot be verified or something like that? I was really left puzzled and thought for a while that the cross-signing issue could be the problem. Looks like it is not.
(in reply to comment #30) > FF2 started bringing up OCSP validation error message -8048 (general OCPS > validation error). Chrisoph, Comodo's OCSP Responder is not at fault. That -8048 error is due to Bug #419030, which will apparently be fixed in Firefox 2.0.0.15.
Thanks a lot - cannot believe this is STILL a bug in FF2.0.14. Anyhow, glad you pointed it out and that Comodo is actually and actively using OCSP. Looking forward to FF3!
Christoph, Regarding comment 24, I have not yet looked closely at the certs you mention, but based on your description, this "cross certification" phenomenon is actually very common. Virtually all of the new "EV" CAs already have this arrangement. One CA "cross certifies" another by issuing a certificate for the cross- certified CA that bears the same subject name, same public key, and same subject key ID, but different issuer name (and signature, naturally) as the other cert(s) that already exist for that cross-certified CA. So, assuming that what I just wrote is a fair description of what you found, then what you found is not generally cause for alarm.
What is the effect of https://bugzilla.mozilla.org/show_bug.cgi?id=470897 on this request? That bug refers to a mis-issued certificate by a CA that chains to the UTN-UserFirst-Hardware root. (Comodo accepted and processed requests from a contracted registration authority to sign at least two documented certificates which did not have any actual verification performed by the RA. One of these was for a certificate issued to CN=www.mozilla.com, sAN=[DNS:www.mozilla.com, DNS:mozilla.com].) I request that Mozilla deny EV-enablement unless and until Comodo provides written documentation that they will not ever accept and process a submission for EV certification from an RA without examining the documents itself.
I think that examining applicant credentials and approving certificate issuance is basically the definition of an RA. What I'm wondering is whether the Webtrust guidelines allow delegation of RA functions like that, if the delegated RA is not itself audited. If yes, it sounds like a gap in the guidelines. Even if it is ok, certainly the CPS should say what is going on.
To all of my knowledge, the WebTrust criteria requires sufficient controls which the CA applies (contractual, review and testing, taking samples, etc.). The RA itself must have sufficient controls for the validation procedures. IIRC, RAs are not audited by default, but the controls of the CA are. Having said that, Mozilla many times has different/additional requirements than the WebTrust audit criteria. Those must be part of the CAs CP/CPS and are reviewed during the "Information Gathering" and later at the "Public Discussion" period. Until now it was assumed that RAs don't place a special problem due to the controls in place by the CA. However I expect a change in this policy.
Chaps: it would be much easier if we could prevent discussion of the current issue being spread across multiple venues. Let's try and keep it to the newsgroup and bug 470897 for the moment, OK? I'm confident you will not let us forget the possibility this bug provides for sanctions against Comodo. Gerv
The "COMODO Certification Authority" root certificate was included as per this request. If further updates are desired, please open a new bug as per https://wiki.mozilla.org/CA:How_to_apply
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.