Closed Bug 365281 Opened 19 years ago Closed 18 years ago

Add 2 more QuoVadis roots (1 EV)

Categories

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

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: sdavidson, Assigned: gerv)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 QuoVadis is a commercial CA serving a global client base. QuoVadis has one existing root that is widely distributed, including in Mozilla since early 2005 (see Bug 238381). However, the growth of QuoVadis’ operations requires us to diversify our certification activities across two additional new root hierarchies. QuoVadis intends to issue “Extended Validation” (or EV) SSL certificates as described in the CA/Browser Forum Guidelines (see http://wwwcabforum.org/) from one of the new roots. QuoVadis is requesting inclusion of two new roots in the builtin trusted CA list. The two new roots have been accepted into the Microsoft Root Certificate Programme for distribution in January 2007, and requests for distribution have been made to other applications/operating systems. QuoVadis Root CA 2 Description: This root will be used for SSL/device certificates, including standard “organisation validated” certificates as well as EV certificates. Download: http://www.quovadis.bm/public/qvrca2.crt Thumbprint: ca 3a fb cf 12 40 36 4b 44 b2 16 20 88 80 48 39 19 93 7c f7 Purposes/Usage: ALL CRL: http://crl.quovadisglobal.com/qvrca2.crl OCSP: Active The EV OID associated with Root CA2 is: 1.3.6.1.4.1.8024.0.2.100.1.2 QuoVadis Root CA 3 Description: This root will operate under a similar CP/CPS to our existing “qualified” Root CA 1, primarily used for end user certificates. Download: http://www.quovadis.bm/public/qvrca3.crt Thumbprint: 1f 49 14 f7 d8 74 95 1d dd ae 02 c0 be fd 3a 2d 82 75 51 85 Purposes/Usage: ALL CRL: http://crl.quovadisglobal.com/qvrca3.crl OCSP: Active QuoVadis undertakes the following audits and certifications: i. WebTrust for Certification Authorities, conducted by Ernst & Young (Technology and Security Risk Services). See https://cert.webtrust.org/ViewSeal?id=522. ii. WebTrust for Extended Validation Certificates readiness review, conducted by Ernst & Young (Technology and Security Risk Services). iii. Qualified Certification Service Provider (Switzerland) entitled to issue and administer qualified electronic certificates, conducted by KPMG Klynveld Peat Marwick Goerdeler SA for the Swiss regulator SAS. See http://www.sas.ch/en/pki_isms/pki.html. This includes certification to SR 943.03 (ZertES) and other Swiss laws and regulations, as well as ETSI TS 101.456 (Policy requirements for Digital Certification Authorities issuing Qualified Digital Certificates), ETSI TS 101.856 (Policy requirements for time-stamping authorities), and other standards. iv. Bermuda Authorised Certification Service Provider, conducted by Ernst & Young for the Bermuda Government. This “qualified” scheme synthesizes elements of ISO 17799 (Code of Practice for Information Security Management) and the European Electronic Signature Standardisation Initiative, as well as WebTrust for CAs. Policies for the new Root CAs will be posted at: http://www.quovadisglobal.com/cps (under development, see existing policies at http://www.quovadis.bm/policies/. Note: The policies for the new roots will be posted before the new roots are used.) Reproducible: Always Many thanks. Please contact me if you require additional details. Stephen Davidson Vice President, QuoVadis Limited 7 Reid Street, Washington Mall, 3f Hamilton HM11, Bermuda 1-441-278-2800 sdavidson@quovadis.bm
I confirm that this is an enhancement request.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: QuoVadis CA – requesting two additional roots in trusted CA list → Add 2 more QuoVadis roots (1 EV)
QA Contact: ca-certificates
Confirming that the EV-ready CPS is posted at http://www.quovadis.bm/policies/. QuoVadis also requests that its EV OID (1.3.6.1.4.1.8024.0.2.100.1.2) be associated with its existing "QuoVadis Root Certification Authority" which is already distributed by Mozilla (see Bug 238381).
Priority: -- → P1
Stephen: I can't find a CP/CPS explicitly labelled as being for Root CA 3. Can you confirm that it is using the same CP/CPS as your original root? The text above says it will operate under a "similar" CP/CPS. Gerv
I confirm that QuoVadis Root CA 3 operates under the same CP/CPS as the original QuoVadis Root Certification Authority. We will soon post an update to that CP/CPS document to make that relationship more explicit.
Fab. Could you post here when that's done? Thanks. Gerv
Hello: An updated CP/CPS has been posted at http://www.quovadis.bm/policies/QV_CPCPS_V4_2.pdf. Best, Stephen
Stephen: Fab. Checking my records, I think the last things I need are the URLs of the OCSP responders you are planning to use for each certificate. Gerv
Hi Gerv: The QuoVadis OCSP service is at http://ocsp.quovadisglobal.com/ This covers all three roots and associated issuing CAs. Best, Stephen
I have gathered together all the information you have provided, and placed it in the "pending" CA root certificate request list, which is here: http://www.mozilla.org/projects/security/certs/pending/ Please confirm that the information for your CA is correct, and add a comment to this bug to that effect. Once you have done that, your application will turn "green" and be ready for consideration. If your CA or certificate does not have a summary paragraph, please feel free to provide one. Note: these paragraphs are not supposed to be marketing statements :-) Gerv
Hello: Following is an amended company description, plus a correction. Otherwise I confirm the details of your listing. Note also that we request EV tagging for our existing QuoVadis Root Certification Authority (see Bug 238381). Best, Stephen QuoVadis is a commercial CA, based in Bermuda and operating globally. QuoVadis is a Qualified Certification Services Provider in Switzerland. Audit: WebTrust, performed by Ernst & Young (Technology and Security Risk Services): Audit Report and Management's Assertions. ETSI, performed by KPMG [http://www.kpmg.ch/]: notation on Swiss Accreditation Service website [http://www.seco.admin.ch/sas/00229/00251/00254/index.html?lang=en]. I only see one correction: The CRL for QuoVadis Root CA3 is: http://crl.quovadisglobal.com/qvrca3.crl
Stephen, Thanks for the conformation. I've made the changes and will soon turn your CA 'green'. I hope to find time soon to evaluate your request. EV approvals will be a separate process. Gerv
Stephen, I have begun evaluating your application, and I have some questions. The WebTrust criteria: http://ftp.webtrust.org/webtrust_public/tpafile7-8-03fortheweb.doc say that companies must be re-audited regularly, and at least every twelve months. Your CPS also mentions annual audits. However, the QuoVadis Audit Report and Management's Assertions on the WebTrust website: https://cert.webtrust.org/SealFile?seal=522&file=pdf (PDF) are dated November to December 2005 - i.e. fifteen months ago. Has your auditor failed to update the WebTrust website? What are the start date and expiry date of your current audit? In addition, the link in the audit marked "Certificate Practice Statement" just links to a general page on your website rather than to a specific CPS. According to the change history of the two CPSes submitted, one did not even exist at this time, and the other was at version 2.08 (current version: 4.2). Can you confirm that the audit used CPS version 2.08? Thanks, Gerv
Status: NEW → ASSIGNED
Hello Gerv: As you are aware, audits are retrospective, (i.e., conducted on transactions that occurred during a past observation period). WebTrust requires that audits be conducted every 12 months; accordingly WebTrust seals may be effective for 13 months. QuoVadis’ current WebTrust seal was granted in March 2006, with the corresponding audit by Ernst & Young covering the period November 1 to December 31, 2005. Ernst & Young is currently conducting our renewal WebTrust audit, covering the period November 1 to December 31, 2006. We do not expect any issues that would impact the timely renewal of the QuoVadis WebTrust seal. At the time of the last audit, the QuoVadis CPS covered a sole root (known as QuoVadis Root Certification Authority). That original CPS has undergone revisions to accommodate the additional requirements of our Swiss certification (granted in June 2006 following an audit by KPMG for the Swiss Accreditation Service against ETSI TS 101.456, 101.862, 102.023, 101.861, and 3 local laws/regulations) as well as the creation of the new QuoVadis RCA3 root that is the subject of this bug. Those CP/CPS revisions have been additive to the WebTrust requirements. In addition, a separate CP/CPS was created to reflect the different business needs of the new QuoVadis RCA2 root that is also the subject of this bug. QuoVadis was the subject of a separate “Readiness Audit” by Ernst & Young in December 2006 using the WebTrust Extended Validation (EV) Audit Criteria. Both RCA2 and RCA3, and all current QuoVadis CP/CPS documents, are included in the WebTrust audit in progress. Regards, Stephen
Some more questions, from my continued assessment: Please can you point me at a diagram showing your certificate hierarchy, so I can assess you against point 13 of the Mozilla project guidelines. CPCPS 4.2, Appendix A, section 10.1.1 talks about test certificates (issued without validation) which may have the Secure Email EKU. What is to prevent someone obtaining such a certificate with false information in it and using it just as one might use a normal certificate? CPCPS 4.2, Appendix A, section 10.1.2 talks about Standard Personal Certificates. Such certificates have an email address embedded in them, yet the "Registration Process" section does not state that you verify that the person concerned controls the email address that they give you. Do you do such verification? If so, why does the procedure not appear? What about the other CPs in this Appendix? CPCPS 4.2, Appendix A, section 10.1.6 talks about Device Digital Certificates, which are the only types of certificate in that file which have "Server Authentication" and "Code Signing" EKUs. However, the document does not give information on the circumstances under which they are issued. Why is that? When are such certificates issued? Do you issue code signing certs of any type other than that mentioned in section 10.1.6, as referenced above? Gerv
Hello Gerv: Point 13 of the Mozilla Guidelines recommends that CAs set up separate CAs corresponding to different certificate policies. This is not practical for many CAs for perfectly valid reasons. Our published policy documents include publicly available information about the QuoVadis PKI and our certificate classes. Any CA in the RCA and RCA3 hierarchies may issue certificates according to the stipulations on page 55 of the v4.2 document you reference. I am surprised by your following questions as issues such as these are covered by the WebTrust and equivalent audits required by Mozilla, where the auditors are tasked with understanding and testing the application of the CP/CPS in line with the standards against the CAs business. Regarding Test Certificates. QuoVadis issues test certificates under very limited circumstances and with short duration of validity. They contain a statement to the effect “test purposes – no reliance” in the OU and Cert Policies fields. I emphasize that these are test certificates, not free certificates available to the public. Regarding E-mail Address in Standard Personal Certificates. As with many CAs, verification of email address is shown by the ability of the applicant to receive email at that address. I understand that you are validating against point 7 of the Mozilla Guidelines, however, from a practical perspective the email client will not work if the email address they are sending from is not the same as the email field on the certificate. From a document signing perspective, the email address has no legal validity and does not require additional vetting procedures. Regarding Device Digital Certificates. I am not sure I understand your question. This CP covers device certificates, which may include SSL and code signing certificates. As you will have noted, the new RCA2 which is the subject of this bug deals extensively with SSL and is now our commercial provider for SSL. As noted earlier, QuoVadis has incorporated the Webtrust EV procedures into our current WebTrust audit. We do not currently commercially issue code signing certificates; however as you know this may be considered as part of the EV rollout. If QuoVadis pursues this, the RCA2 CP/CPS will be appropriately amended. Regards, Stephen
(In reply to comment #15) > Point 13 of the Mozilla Guidelines recommends that CAs set up separate CAs > corresponding to different certificate policies. This is not practical for > many CAs for perfectly valid reasons. Of course. I quite understand that it's not a requirement. However, historically, assessment statements have included an advisory sentence on the topic. Hence my request. > Our published policy documents include > publicly available information about the QuoVadis PKI and our certificate > classes. I'm sure. It's just that a diagram is rather easier to understand. But if you don't have one, you don't have one (although I'd be a bit surprised). > I am surprised by your following questions as issues such as these are covered > by the WebTrust and equivalent audits required by Mozilla, where the auditors > are tasked with understanding and testing the application of the CP/CPS in > line with the standards against the CAs business. Of course. And I am tasked with understanding them to the (lesser) extent necessary to see that they match the policy document. > Regarding Test Certificates. QuoVadis issues test certificates under very > limited circumstances and with short duration of validity. They contain a > statement to the effect “test purposes – no reliance” in the OU and Cert > Policies fields. ...which fields, of course, tend not to be displayed in user agents. > I emphasize that these are test certificates, not free > certificates available to the public. I understand this. However, as far as I can see, your document doesn't state that there are any limits on their issue. As a CPS is a statement of the practices which a certification authority employs in issuing certificates, I was wondering why it doesn't state any practices with respect to how you issue these particular ones. > Regarding E-mail Address in Standard Personal Certificates. As with many CAs, > verification of email address is shown by the ability of the applicant to > receive email at that address. That's all I needed to know; thank you. (Does the document state this somewhere I missed?) > I understand that you are validating against > point 7 of the Mozilla Guidelines, however, from a practical perspective the > email client will not work if the email address they are sending from is not > the same as the email field on the certificate. What the email client knows about "The email address they are sending from" is entirely under the control of the user/attacker. If I have a valid certificate for sdavidson@quovadis.bm, it is trivial for me to configure Thunderbird to send email signed by "you". Anyway, as long as you confirm control of the email address, that's fine. > Regarding Device Digital Certificates. I am not sure I understand your > question. I apologise. Let me try and be more clear. All of the 10.1.x sections preceding 10.1.6 have details of the registration process for the certificate type in question. Section 10.1.6 has no such section. How do I find out to whom such certificates are issued and under what circumstances? > We do not currently commercially issue code signing certificates; however as > you know this may be considered as part of the EV rollout. If QuoVadis > pursues this, the RCA2 CP/CPS will be appropriately amended. I will need to take advice on this. Gerv
> I will need to take advice on this. Further to this particular point: how much warning would you be able to give us before rolling out code signing certificates? Gerv
The CP/CPS for the QuoVadis RCA and RCA3 (WebTrust audited) supports code signing, and we'd like to have that capability turned on for those roots. As you note, the CP/CPS for RCA2 does not currently encompass code signing, however we would prefer to have the root marked to ensure that there would be no undue delay or compatibility problems should that CP/CPS be amended and a service be rolled out from RCA2. I believe the same situation exists for quite a few CAs already in, and proposed for inclusion in, the NSS root store. As stated, it is probable that QuoVadis will introduce code signing from RCA2 (and that activity would fall within our WebTrust audit). We could presumably provide up to three months prior notice of that occurance. Are you implying that future-Firefox may include the ability to dynamically update the meta data for roots, similar to Vista?
> The CP/CPS for the QuoVadis RCA and RCA3 (WebTrust audited) supports code > signing, and we'd like to have that capability turned on for those roots. Having searched CP/CPS 4.2, I can't find any reference to code signing, apart from those which state that you enable it for the "Device Digital Certificate" class of certificates. (I grepped the file for the word "code".) Did I miss the text which explains the procedures for issuing code signing certificates? > we would prefer to have the root marked to ensure that there would be > no undue delay or compatibility problems should that CP/CPS be amended and a > service be rolled out from RCA2. I'm sure you would :-) However, I have issues with doing so without even seeing the CP/CPS text on which such a service would be based. As a hypothetical comparator, would you think it reasonable for me to accept another CA's assertion of the form "please enable our root for EV. We haven't had an audit yet, but we want everything to work fine when we get one"? > Are you implying that future-Firefox may include the ability to dynamically > update the meta data for roots, similar to Vista? We plan to roll out root store updates with our regular security updates. By default, these are automatically installed. We usually release one every six to eight weeks. I also look forward to your responses to the other issues in comment #16. Gerv
Hello: Codesigning: QuoVadis has amended the CP/CPS for RCA and RCA3 to clarify the issuance requirements for codesigning and other special purpose certificates. See section 10.1.6 of http://www.quovadis.bm/policies/QV_CPCPS_V4_3.pdf At this time, the CP/CPS for RCA2 does not accomodate codesigning certs. Test certs: QuoVadis' issuance of Test certs is very restricted (in particular, they are not issued to retail). This cert class is used in tests for larger rollouts of standard or qualified certs, which are covered by contractual terms. Email control: The vast majority of our end user certs are issued in organisational environments where this is not an issue. In any case, our provisioning tool, Trust/Link, verifies email control via the typical email/webpage volley used by most CAs. Regards, Stephen
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 the delay. Here follows my assessment. Section 4 [Technical]. I'm not aware of any technical issues with certificates issued by QuoVadis, 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. Section 6 [Relevancy and Policy]. QuoVadis appears to provide a service relevant to Mozilla users: they are a commercial CA with a worldwide clientele. Policies are documented in the documents published on their website and listed in the entry on the pending applications list. Section 7 [Validation]. QuoVadis appears to meet the minimum requirements for subscriber verification, as follows: * Email: For certificates with the E-mail Protection EKU (1.3.6.1.5.5.7.3.4), QuoVadis verifies that the entity submitting the request controls the email account associated with the email address referenced in the certificate - as stated in comment #15 and comment #20 in this bug. * SSL: For certificates with the TLS Web Server Authentication EKU (1.3.6.1.5.5.7.3.1), QuoVadis verifies domain control (See Appendix B of QuoVadis CP/CPS 1.7). QuoVadis also requires additional verification in all cases. * Code: For certificates with the Code Signing EKU (1.3.6.1.5.5.7.3.3), QuoVadis verifies that the entity submitting the certificate signing request is the same entity referenced in the certificate. (See section 10.1.6 of CPS v4.3.) Note: QuoVadis only rarely issues such certs. Section 8-10 [Audit]. QuoVadis has successfully completed an audit using the WebTrust for CAs criteria. The auditors were Ernst & Young. According to QuoVadis, the audit is currently valid until some time in April. Section 13 [Certificate Hierarchy]. QuoVadis has multiple intermediate CAs under three roots. Other: QuoVadis issues CRLs (on a 12-hour schedule) and also has an OCSP responder. I am therefore minded to approve the application. Before I do, I'm opening up a period of public discussion of this request. I'll post in the news://news.mozilla.org/mozilla.dev.tech.crypto newsgroup to allow people to make comments. The normal comment period, unless discussion continues beyond that time, is two weeks. Special note: given that the QuoVadis WebTrust audit expires this month, it makes sense to wait for its renewal before finally approving the application. So I will do that. Gerv
Reassign all open CA bugs to me. Apologies for the bugspam. Gerv
Assignee: hecker → gerv
Status: ASSIGNED → NEW
QuoVadis' updated WebTrust report may be viewed at https://cert.webtrust.org/ViewSeal?id=612 Best, Stephen
The comment period has passed without incident; I have therefore opened bug 378161 to cover the actual inclusion of the certificates in the store. Gerv
Status: NEW → RESOLVED
Closed: 18 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.