User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008030710 Minefield/3.0b5pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008030710 Minefield/3.0b5pre 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 our root CAs. 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: COMODO ECC Certification Authority Certificate URL: http://crt.comodoca.com/COMODOECCCertificationAuthority.crt Version: X.509v3 SHA1 Fingerprint: 9F744E9F2B4DBAEC0F312C50B6563B8E2D93C311 MD5 Fingerprint: 7C62FF749D31535E684AD578AA1EBF23 Key Length: 384-bit ECC (secp384r1) Valid From (YYYY-MM-DD): 2008-03-06 Valid To (YYYY-MM-DD): 2038-01-18 CRL URL: it will be http://crl.comodoca.com/COMODOECCCertificationAuthority.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 EV Policy OID: 22.214.171.124.4.1.64126.96.36.199.5.1 Certificate CPS Details ----------------------- http://www.comodo.com/repository/EV_CPS_4_JUN_07.pdf http://www.comodo.com/repository/EV_CPS_Amendment-ECC_Certificates.pdf Reproducible: Always
Adding the COMODO ECC Certification Authority root certificate as an attachment.
I know that Kai will want to know the following URL for technical testing: https://comodoecccertificationauthority-ev.comodoca.com Please note: For logistical reasons, our ECC private keys are currently being held off-line, so we are not currently able to issue CRLs or sign OCSP responses. The test EV certificate for the above URL references our OCSP Responder, which will therefore currently return an "unauthorized" response, thus preventing the EV UI from being displayed. Now, we also have a second test EV certificate that contains neither CRL nor OCSP URLs. I've built the latest Firefox 3 CVS code, first adding our ECC Root to myTrustedEVInfos and the trusted root store, and I can confirm that the EV UI did appear for this no-CRL/no-OCSP test certificate. (I realize that this behaviour will cease once Bug 413997 is resolved, but nevertheless the current behaviour was very useful for my testing purposes). We're obviously rather reluctant to put this no-CRL/no-OCSP test certificate on a publicly live site, since the EV Guidelines mandate that at least 1 revocation URL is included in each EV certificate.
Frank, please prioritize this bug ahead of the 8 roots that remain to be reviewed in bug #401587. If we had to choose, we would prefer to see this new ECC Root present, and trusted for EV, in Firefox 188.8.131.52. Thanks.
Frank, will you be reviewing this request in time for Firefox 184.108.40.206 ? Given that we want this Root Certificate enabled for EV, I've just marked this bug as blocking Bug #398944, in the hope of ensuring that it doesn't fall off your radar.
I've updated the Summary of this bug, as per Nelson's recommendation to the CABForum regarding how to ensure that EV Root Submissions appear in Frank's radar.
Summary: Add COMODO ECC Certification Authority root certificate → Add COMODO ECC Certification Authority root certificate and enable it for EV
I'm assigning this bug to Kathleen Wilson, who'll be gathering information relating to this and other requests.
Assignee: hecker → kathleen95014
Rob, As per the info-gathering I’ve been asked to do, I have the following questions. 1) Please confirm that the maximum time for updating end-entity CRLs is 24 hours. This is based on info I found in the CPS. 2) What is the maximum time for updating OCSP? I ask this in regards to EV Guidelines section 26(a): “OCSP responses from this service MUST have a maximum expiration time of ten days.” 3) Would you please provide the hierarchy for this CA? From the CPS it looks like it has a sub-CA called COMODO EV SSL ECC CE that is internally operated. Can it have 3rd-party operated sub-CAs? It looks like it’s cross-signed by the root COMODO CA. I would like to confirm that I’m interpreting the CPS correctly, so a diagram would be really helful. The reason I ask about sub-CAs and cross-signing is in regards to http://wiki.mozilla.org/CA:Problematic_Practices There is a section which says: “Some CAs authorize external entities to operate their own CAs as subordinate CAs under the original CA's root. This raises concerns relating to whether or not such external entities are audited in a manner equivalent to the root CA, as well as what legal and technical arrangements constrain the external entities.” 4) Since I cannot confirm the test site, can you provide example certs issued under this CA for ssl and email? Thanks, Kathleen
Hi Kathleen. Thank you for starting to process this application. > 1) Please confirm that the maximum time for updating end-entity CRLs is 24 > hours. This is based on info I found in the CPS. > > 2) What is the maximum time for updating OCSP? We currently refresh both our end-entity CRLs and end-entity OCSP Responses at least every 24 hours. Each CRL and OCSP Response is valid for up to 96 hours (i.e. the "nextUpdate" is 96 hours after the "thisUpdate"). As I mentioned in comment #2, our ECC CA private keys are currently held off-line, so we cannot issue Certificates, CRLs or OCSP Responses at the moment. Once the "COMODO ECC Certification Authority" Root Certificate has been approved and included in some browsers that support ECC, it will become commercially useful. At that point, we will bring our ECC CA private keys back on-line and start issuing Certificates, CRLs and OCSP Responses. I hope this doesn't pose any problem for you. > 3) Would you please provide the hierarchy for this CA? So far, we have issued zero sub-CA certificates and only 2 test end-entity certificates (as mentioned in comment #2) from this Root Certificate. > From the CPS it looks like it has a sub-CA called COMODO EV SSL ECC CE that > is internally operated. The COMODO EV SSL ECC CA sub-CA certificate mentioned in section 1.8.1 of EV_CPS_Amendment-ECC_Certificates.pdf does not yet exist. After we bring our ECC CA private keys back on-line, we will issue this sub-CA certificate. It will then be used to issue end-entity EV SSL Certificates that contain ECC keys. Yes, it will be operated by Comodo rather than by any 3rd party. > Can it have 3rd-party operated sub-CAs? We have no current plans to do so. If the need ever arises in the future, we'd be happy to discuss the matter with you and Frank then. > It looks like it’s cross-signed by the root COMODO CA. The "COMODO ECC Certification Authority" root certificate has not yet been cross-certified by any other CA certificate. However, I anticipate that we will cross-certify it with one of our older RSA root certificates before we use it commercially, in order to ensure that previous versions of ECC-enabled Firefox (from 220.127.116.11 upwards, I believe) are able to build a certificate chain up to a trusted root. As and when we formulate a clearer plan, we will seek to discuss it with you and Frank. > so a diagram would be really helful. The first hierarchy diagram in section 1.8.1 of EV_CPS_Amendment-ECC_Certificates.pdf, together with what I've written in this comment, is the best I can offer at the moment. > 4) Since I cannot confirm the test site My apologies. It appears that the test site has been down for a few weeks, and I've only just noticed (I've just been on paternity leave for 2 weeks - is that a good enough excuse? :-) ). The https://comodoecccertificationauthority-ev.comodoca.com/ test site is now online again. I think that you should be able to access it and confirm everything you need to. (Regarding my comment #2: I hope the fact that our OCSP Responder cannot currently provide authoritative OCSP responses for the test certificate isn't a problem for you). > can you provide example certs issued under this CA for ssl You can now obtain our example EV SSL Certificate from the test site. > and email? As our ECC CA private keys are currently off-line, I'm afraid we cannot issue an example email certificate at the moment.
Hi Rob, RE: I've just been on paternity leave for 2 weeks Congratulations!!! Thank you for your quick and thorough response, and for fixing the ssl test site. This test site and the corresponding end-entity cert is sufficient, so we don't need the email test cert. I have found that section 4.2.5 of the CPS very effectivley describes how ownership of domain is checked for SSL. However for the email certs, I have not been able to find the text about verifying that the email account associated with the email address in the cert is owned by the subscriber. Would you please point me to the appropriate section/document? Thanks, Kathleen
> However for the email certs, I have not been able to find the text about > verifying that the email account associated with the email address in the cert > is owned by the subscriber. Would you please point me to the appropriate > section/document? I'll refer this question, and any further CPS questions you might have, to my colleague Robin Alden.
I have added this request to the pending list http://www.mozilla.org/projects/security/certs/pending/#Comodo
(In reply to comment #9) > for the email certs, I have > not been able to find the text about verifying that the email account > associated with the email address in the cert is owned by the subscriber. > Would you please point me to the appropriate section/document? > Thanks, > Kathleen The part of the CPS that talks about validation of email certificates is in http://www.comodo.com/repository/09_22_2006_Certification_Practice_Statement_v.3.0.pdf at the bottom of page 24, section 2.4.2. That section in turn refers to page 48 sections 4.2.6 and 4.2.7. Regards Robin
Attaching summary of info gathered and verified for this request.
Completed info-gathering/verification phase. Assigning back to Frank, so this request can proceed to the discussion phase.
Assignee: kathleen95014 → hecker
Whiteboard: EV → EV - information confirmed complete
Accepting bug. I'll proceed with the first public comment period once I figure out where this request sits in the queue relative to other similar requests.
Status: NEW → ASSIGNED
I have now opened a one-week period of public discussion of this request, as mentioned in my post to the mozilla.dev.tech.crypto forum: http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/8a738f97ae3c55a4# This public discussion period will provide people in the Mozilla community with an opportunity to comment on the request, raise concerns, ask additional questions, etc. After the discussion period ends I will make a preliminary decision about whether or not to approve this request, and if I decide to move forward with approval then we will have a further one-week discussion period to address any remaining questions or issues. Note that the mozilla.dev.tech.crypto forum is also accessible via email; see https://lists.mozilla.org/listinfo/dev-tech-crypto for information on how to subscribe and post to the mailing list.
Whiteboard: EV - information confirmed complete → EV - in public discussion
The first public comment period for this request is now over. I have evaluated this request, as per sections 1, 5 and 15 of the official CA policy at http://www.mozilla.org/projects/security/certs/policy/ On behalf of the Mozilla project, I apologise for any delay. Here follows my assessment. If anyone sees any factual errors, please point them out. To summarize, this assessment is for the request to add a new root CA certificate for Comodo ECC Certification Authority, and then to enable that root for EV use (with EV policy OID 18.104.22.168.4.1.6422.214.171.124.5.1). It is unrelated to and independent of any other requests from Comodo. Section 4 [Technical]. I'm not aware of any technical issues with certificates issued by Comodo, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report. There were some concerns expressed in the comment period regarding technical interoperability of Comodo-issued ECC certs with NSS. Note in this regard that Comodo provided a test server with an ECC certificate issued under the hierarchy rooted at Comodo ECC Certification Authority, and multiple people were able to use Firefox 3 to successfully connect to the server. Section 6 [Relevancy and Policy]. Comodo appears to provide a service relevant to Mozilla users: It's a commercial CA offering certificates to customers worldwide. It has roots already included in Mozilla, and this new root is associated with extensions of Comodo's existing certificate offerings. Policies are documented in the documents published on its website and listed in the entry on the pending applications list. In Comodo's case the relevant documents are structured as follows: * An overall CPS for all Comodo CAs and certificate products * A CPS addendum specifically for EV offerings * A CPS addendum specifically for ECC CAs Section 7 [Validation]. Comodo appears to meet the minimum requirements for subscriber verification, as follows: * 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 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.) 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.) * 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]. Section 8-10 [Audit]. Comodo has successfully completed independent audits using the WebTrust for CAs criteria and the WebTrust EV criteria. The audits were done by KPMG. Note that the audit reports are a bit over a year old, but still within the window that we've discussed as a potential future policy requirement. (Our current policy doesn't have a formal requirement relating to audit frequency.) Section 13 [Certificate Hierarchy]. Comodo ECC Certification Authority has a single subordinate CA, the COMODO EV SSL ECC Certification Authority, the issuing CA for EV SSL certificates. Comodo plans to offer other types of certificates under this hierarchy in future, but the exact subordinate structure is not yet determined as far as I'm aware. However any such subordinates would be operated by Comodo. Other: Comodo issues CRLs (on a 24-hour schedule) and also operates an OCSP responder. Potentially problematic practices: There are no known potentially problematic practices associated with Comodo ECC Certification Authority and its associated CA hierarchy as it exists and is planned. Based on the information available to me I am minded to approve this request to add the Comodo ECC Certification Authority certificate and enable it for EV use. Before I issue my final decision, I'm opening up a second one-week period of public discussion of this request in the mozilla.dev.tech.crypto newsgroup .  The mozilla.dev.tech.crypto newsgroup is accessible via NNTP-capable newsreaders 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
We're past the end of the second comment period, and based on all the comments up to now I'm now ready to make a final decision. Of the additional issues that came up in the second comment period, a couple (wildcard DV certs and long-lived certs) I've already dealt with in a prior request, one (multiple certs with the same FQDN) I don't see as a reason for rejection of the request (per my earlier message to m.d.t.crypto ), and one (certs with hostnames and private IP addresses) I consider now moot based on the previous public statement/commitment by Comodo . Also, I've given my opinion that issuance of certs for static public IP addresses, though not strictly speaking addressed in our policy, is in fact consistent with the intent of our policy assuming ownership/control of the addresses is verified .  http://groups.google.com/group/mozilla.dev.tech.crypto/msg/ef7779ca1af0df26  http://groups.google.com/group/mozilla.dev.tech.crypto/msg/b7c7cc588a13a248 Based on the resolution of these issues I'm therefore officially approving the Comodo request to add the Comodo ECC Certification Authority root certificate to NSS and to enable it in PSM for EV use, and will proceed to file the necessary bugs against NSS and PSM respectively.
Whiteboard: EV - in public discussion → EV - approved
Frank, In bug 450427 comment 6, Rob Stradling wrote: > I've just noticed a couple of errors for this Root's entry on: > http://www.mozilla.org/projects/security/certs/pending/#Comodo > > "Modulus (key length) 2048" should in fact be... > "Modulus (key length) SECG elliptic curve secp384r1 (aka NIST P-384)" > > "Valid From 2000-03-06" should in fact be... > "Valid From 2008-03-06"
Whiteboard: EV - approved → EV - approved - In NSS and In PSM - Awaiting ?
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: EV - approved - In NSS and In PSM - Awaiting ? → EV - approved - In NSS and In PSM
You need to log in before you can comment on or make changes to this bug.