364568 - Add DigiCert CA Root Certificates (3 Roots, 1 EV)

Status: RESOLVED FIXED

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

Description

[Ken Bretschneider (DigiCert Inc)]

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

DigiCert® (DigiCert, Inc.) is a US-based CA located in Lindon, UT. DigiCert provides High-Assurance SSL Certificates (soon to offer other digital signature products including email and code-signing) to some of the most respected and prestigious organizations in the world, including national and state governments, educational and medical institutions, and Fortune 500 companies. DigiCert is ranked in the top 10 of commercial CAs regarding market share of SSL Server Certificates as reported by respected industry surveys.

DigiCert is a WebTrust Certified Certificate Authority (https://cert.webtrust.org/ViewSeal?id=558), a member of the CA/Browser Forum (http://www.cabforum.org/forum.html) and the W3C Consortium (http://www.w3.org/Consortium/Member/Testimonial/Home/home-1084). 

DigiCert is requesting inclusion of the following (3) CA Root Certificates:

DigiCert Assured ID Root CA
http://www.digicert.com/CACerts/DigiCertAssuredIDRootCA.crt 
Valid from: Thursday, November 09, 2006 5:00:00 PM
Valid to: Sunday, November 09, 2031 5:00:00 PM
Thumbprint: 05 63 b8 63 0d 62 d7 5a bb c8 ab 1e 4b df b5 a8 99 b2 4d 43
Purposes/Usage: ALL (SSL-enabled servers, digitally-signed and/or encrypted email, digitally-signed executable code objects, time-stamping)
CRL: http://crl3.digicert.com/DigiCertAssuredIDRootCA.crl 
OCSP: Active
 
DigiCert Global Root CA
http://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt 
Valid from: Thursday, November 09, 2006 5:00:00 PM
Valid to: Sunday, November 09, 2031 5:00:00 PM
Thumbprint: a8 98 5d 3a 65 e5 e5 c4 b2 d7 d6 6d 40 c6 dd 2f b1 9c 54 36
Purposes/Usage: ALL (SSL-enabled servers, digitally-signed and/or encrypted email, digitally-signed executable code objects, time-stamping)
CRL: http://crl3.digicert.com/DigiCertGlobalRootCA.crl 
OCSP: Active
 
DigiCert High Assurance EV Root CA
http://www.digicert.com/CACerts/DigiCertHighAssuranceEVRootCA.crt 
Valid from: Thursday, November 09, 2006 5:00:00 PM
Valid to: Sunday, November 09, 2031 5:00:00 PM
Thumbprint: 5f b7 ee 06 33 e2 59 db ad 0c 4c 9a e6 d3 8f 1a 61 c7 dc 25
Purposes/Usage: ALL (SSL-enabled servers, digitally-signed and/or encrypted email, digitally-signed executable code objects, time-stamping)
CRL: http://crl3.digicert.com/DigiCertHighAssuranceEVRootCA.crl 
OCSP: Active

End-User SSL Certificates will be issued from Sub-CA-Root-Certificates not directly from the Embedded-Roots listed above.

Microsoft has approved the above listed Root Certificates for inclusion in their next update (expected Jan 2007 - Includes EV Certificate issuance). Other major browsers, mobile devices and hardware/software platforms are in the works.

DigiCert's Legal Repository (containing our CPS(s), Subscriber Agreement(s), Relying Party Agreement, Privacy Policy and Terms & Conditions) can be found at the following URL: http://www.digicert.com/ssl-cps-repository.htm 

DigiCert provides 24 Hour Personalized Support (including; Phone, Live-Chat and Email). We also include detailed support documentation on our website. We are dedicated to providing the best support in our industry. DigiCert is also committed to best practices regarding our Validation/Vetting procedures.

Thank you for your time and consideration. If you require additional information, please contact:

Ken Bretschneider
DigiCert, Inc.
[e-mail]
Off: 1-801-413-2896
Mob: [phone]
http://www.digicert.com


Reproducible: Always

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

I confirm that this is an enhancement request.

Comment 2

[Gervase Markham [:gerv]]

Ken: I have a couple of questions about these root certificates.

You give CRL URLs and say that OCSP is "Active" but, as far as I can tell, neither a CRL URL nor an OCSP URL is embedded in the certificates downloadable from the certificate URLs given. How is Firefox supposed to know about the CRL and OCSP responder if the information is not in the certificate?

Also, http://crl3.digicert.com/DigiCertAssuredIDRootCA.crl gives an error when I try and import it into Firefox. Is Firefox broken, or your CRL?

Thanks,

Gerv

Comment 3

[Ken Bretschneider (DigiCert Inc)]

Hi Gerv,

I will respond inline below:

>>> You give CRL URLs and say that OCSP is "Active" but, as far as I can tell, neither a CRL URL nor an OCSP URL is embedded in the certificates downloadable from the certificate URLs given. How is Firefox supposed to know about the CRL and OCSP responder if the information is not in the certificate? >>>

The links I provided were simply a direct download of our root certificates. Below I will provide links to the actual test certificates so that you can view the entire chain (Root > Sub-CA > End-User-Certificate). Our root certificates do not contain CRL/OCSP fields as we were advised not to include them. Many of the current active CA roots in the market do not contain these fields. Of course our end user certificates and issuing sub-ca certificate(s) do contain the CRL/OCSP fields.

https://catest.digicert-high-assurance-ev-ca-1.digicert.com/
https://catest.digicert-assured-id-ca-1.digicert.com/
https://catest.digicert-global-ca-1.digicert.com/

>>> Also, http://crl3.digicert.com/DigiCertAssuredIDRootCA.crl gives an error when I try and import it into Firefox. Is Firefox broken, or your CRL? >>>

It appears that in our initial setup of the CRLs for these new roots, the wrong file was posted at the URL for the DigiCert Assured ID Root CA CRL. We didn’t notice the issue at first, because while testing we received no errors in Firefox or IE (in fact, I never was able to get the error personally, but one of our developers got it today and helped to identify the problem). The CRL for that root has been updated and the issue has been resolved. Thank you for bringing this to our attention.

____________________

Also, I wanted to mention that while testing the CRL today I noticed a typo in the success prompt.  The message says, “Would would like to view the automatic update settings?”; I assume this should read, “Would you like to view the automatic update settings?”  Below is the copy of the message/prompt. 

--------------------

The Certificate Revocation List (CRL) was successfully imported.

CRL Issued By:
Organization: DigiCert Inc
Unit: www.digicert.com

Next Update On: 5/19/2007

Automatic Update is enabled for this CRL.
Would would like to view the automatic update settings?

--------------------

Best Regards, Ken 

Comment 4

[Gervase Markham [:gerv]]

Ken: thanks for those clarifications. I think I nearly have all the information I need. A few more quick questions:

- What sort of certificates do you plan to issue from each of the three roots (DV, OV, EV)?

- Do you have separate Certificate Policy documents for each, or just a CPS?

I've filed bug 372389 on those typos - thanks :-)

Gerv

Comment 5

[Ken Bretschneider (DigiCert Inc)]

Gerv, I will respond inline below:

> - What sort of certificates do you plan to issue from each of the three roots
> (DV, OV, EV)?

Currently we issue OV certificates only, we should go live with EV in the next week or two. We have no plans at this time to issue DV certificates.

To be more specific we will be issuing OV and EV certificates from our three roots (using Sub-CAs).

> - Do you have separate Certificate Policy documents for each, or just a CPS?

Our OV certificate procedures follow our Certificate Policy and Certification Practice Statement which combine both documents - found at the following URL: http://www.digicert.com/CPS-11-9-2006.pdf

Our EV certificate procedures follow our Certification Practice Statement for Extended Validation - found at the following URL: http://www.digicert.com/EV-CPS-11-20-2006.pdf

We did not combine the EV CP/CPS as we did with our OV certificates since we follow the EV guidelines as our CP. Our EV CPS references and provides a link to the current EV guidelines from the CAB/Forum website. Since the EV guidelines will be expanding over time and because Webtrust requires that EV qualified CAs strictly follow the guidelines as written by the CAB/Forum, our legal team decided it would be best to adopt these guidelines as our CP.

*Note: I purposely used the word written above as the EV guidelines have not yet been adopted/approved by the majority of the CAB/Forum members.

> I've filed bug 372389 on those typos - thanks :-)

You are welcome - thanks again for your help Gerv. I hope that I have been able to satisfactorily answer your questions above. Let me know if you need any additional details.

Thanks, Ken

Comment 6

[Gervase Markham [:gerv]]

(In reply to comment #5)
> To be more specific we will be issuing OV and EV certificates from our three
> roots (using Sub-CAs).

You will be issuing OV certs from the root specifically named as an EV root?

> We did not combine the EV CP/CPS as we did with our OV certificates since we
> follow the EV guidelines as our CP. Our EV CPS references and provides a link
> to the current EV guidelines from the CAB/Forum website. 

You mean the URL and document:
http://www.cabforum.org/EV_Certificate_Guidelines.pdf
? Isn't that rather dangerous? There's no guarantees that URL will continue to be valid, or contain the same content - as it's not versioned. Are the auditors happy with the procedure being so tenuously defined, and potentially changing under your feet?

Gerv

Comment 7

[Ken Bretschneider (DigiCert Inc)]

(In reply to comment #6)

> You will be issuing OV certs from the root specifically named as an EV root?

Many other CAs plan or are issuing OV and EV certificates from the same root. Our root (DigiCert High Assurance EV Root CA) was intended for issuing both OV and EV certificates. The name we assigned for this root was intentional and covers both types of certificates (the "High Assurance" portion of the name refers to our OV certificates and the "EV" portion of the name of course refers to our EV certificates).

We are issuing EV and OV end user certificates from their own assigned/unique Sub-CAs. EV end user certificates contain the EV OID and reference our EV CPS/Policies. OV end user certificates do not contain the EV OID and reference the DigiCert OV CPS/Polices.

> You mean the URL and document:
> http://www.cabforum.org/EV_Certificate_Guidelines.pdf
> ? Isn't that rather dangerous? There's no guarantees that URL will continue to
> be valid, or contain the same content - as it's not versioned. Are the auditors
> happy with the procedure being so tenuously defined, and potentially changing
> under your feet?

I apologize if we haven’t been very clear. Currently, we have two CP/CPS policy documents, both located in our repository at http://www.digicert.com/ssl-cps-repository.htm. They are the “DigiCert Certificate Policy and Certification Practice Statement,” version 3.x (for non-EV certificates) and the “DigiCert Certification Practice Statement for Extended Validation Certificates,” version 1.x (for EV Certificates). Those policy documents specify the CP OID arcs that will appear in end entity certificates:

2.16.840.1.114412.1.3 ({digicert} {cp-cps} {ver-3}) for Certificates issued pursuant to the CP/CPS v. 3, and

2.16.840.1.114412.2.1 ({digicert} {ev-cps} {ver-1}) for EV Certificates issued pursuant to EV CPS v. 1.  

Certificate profiles are included as appendices to these CP/CPS policy documents.

I also meant to say that our CP/CPS policy advisor has instructed us not to use the words “Certificate Policy” in the title of our EV policy document because the Guidelines are in essence a CP. More important, however, are the CP OIDs that we use, and the fact that we still have control over the content and meaning of the certificates we issue. Also, our approach to CP/CPS maintenance is similar to other CAs who keep their CPS’s up-to-date so that they accurately reflect current certification practices. Moreover, DigiCert published a specific CPS for EV instead of combining OV and EV together as a single CPS document. 

On the issue of linking the EV guidelines from the CAB/Forum website in our EV CPS, I was mistaken (I guess that is what happens when one replies to important questions while on vacation at Disneyland). Correcting this statement - our EV CPS specifies our intent to comply with version 1.0 (draft 11) of the EV Guidelines (which is a requirement of the guidelines) and provides a link to the www.cabforum.org website for purpose of reference only. Since the EV Guidelines are surely going to change over time along with the requirements to comply with EV Webtrust audits, our CPS/Versions will likewise be updated. We could post a copy of the EV Guidelines (V1-draft 11) to our repository if you feel that it is important.

Thanks, Ken

Comment 8

[Gervase Markham [:gerv]]

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

Comment 9

[Ken Bretschneider (DigiCert Inc)]

(In reply to comment #8)

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

I have found the following:

-----------------

Regarding - DigiCert Assured ID Root CA

> Type OV, EV in future

This should be changed to ... 

Type OV, EV

... as we have started accepting EV requests (paper) and expect to have our web-based systems in place in a week or less.

All other information is correct for this root.

-----------------

Regarding - DigiCert Global Root CA

Same as above - please change "Type OV, EV in future" to "Type OV, EV"

All other information is correct for this root.

-----------------

Regarding - DigiCert High Assurance EV Root CA

The SHA1 Fingerprint is missing. It should list the following:

SHA1 5F:B7:EE:06:33:E2:59:DB:AD:OC:4C:9A:E6:D3:8F:1A:61:C7:DC:25

and again as above - please change "Type OV, EV in future" to "Type OV, EV"

All other information is correct for this root.

-----------------
 
> 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 :-)

Regarding the summary paragraph, you currently list: "DigiCert is a US-based CA located in Lindon, UT."

I would suggest the following:

DigiCert is a US-based commercial CA with headquarters in Lindon, UT. DigiCert provides digital certification and identity assurance services internationally to a variety of sectors including business, education, and government.

I trust the paragraph above does not cross the line of marketing hype ;)

-----------------

One last item - at the top you have DigiCert, Inc. linked to e-trust.be - this of course should be linked to http://www.digicert.com

-----------------

Thanks, Ken

Comment 10

[Ken Bretschneider (DigiCert Inc)]

Gerv,

As a follow-up our legal updated our CPS and EV/CPS today. New links are as follows:

--------------------------

DigiCert Certificate Policy & Certification Practice Statement (CP and CPS for OV), v3.0.3  

http://www.digicert.com/CPS_V3-0-3_3-15-2007.pdf

--------------------------

Document DigiCert Certification Practice Statement for Extended Validation Certificates (CPS for EV), v1.0.1


http://www.digicert.com/EV_CPS_V-1-0-1_3-19-2007.pdf

--------------------------


Best Regards, Ken

Comment 11

[Gervase Markham [:gerv]]

Hi Ken,

I have started the evaluation. A few questions:

- Does DigiCert issue certificates for securing email? I can't find an explicit mention of it in the CPS, or of the procedure for confirming that the applicant has control of the email address in question.

- Does DigiCert currently issue code signing certificates? I find no mention of it in the CPS.

- When I asked about your root whose name contained both "High Assurance" and "EV", you said that many CAs are issuing both types from the same root, and that you were issuing the two from different sub-CAs. However, Appendix B, 2.a. has an intermediate cert called "DigiCert High Assurance EV CA-2", and 3.a. has an End Entity certificate called a "DigiCert High Assurance EV CA-2 End Entity", which continues to mix the two concepts. What's the story?

Thanks,

Gerv

Comment 12

[Ken Bretschneider (DigiCert Inc)]

Hi Gerv,

Inline:

> - Does DigiCert issue certificates for securing email? I can't find an explicit
> mention of it in the CPS, or of the procedure for confirming that the applicant
> has control of the email address in question.

We are in the works to provide SMIME/Email certificates to our customers. We should have this updated in our CP/CPS in the next two days. We will be offering email certificates which will verify/vet the following:

1) Confirm Organization or Individual (as we do with OV server certificates).

2) Confirm control of email address through Email/Code reply.

3) In the case were the Organization or Individual owns/controls the base domain as part of the email certificate(s) address we also confirm control of the domain by reviewing Whois record details. So in other words we verify that they are the registrant of the domain and/or we receive a domain authorization letter from the registrant of the domain stating that the Organization or Individual has the right/permission to acquire certificates under their domain. We also confirm control of domain via Email/Code reply.

Email/Code reply involves following:

For purpose of verifying domain control we send out an email containing a link and unique code which requires click-through confirmation. This email is sent to the domain administrator using an email address as specified in the whois record details or a generic administrative address based on the domain (e.g. [e-mail]). To confirm control of a specific applied for email address we will be sending out the same type confirmation email (Email/Code reply).

Again I expect this to be completed and reflected in our CP/CPS in a couple of days. I will update you the moment this is available.

> - Does DigiCert currently issue code signing certificates? I find no mention of
> it in the CPS.

Regarding code signing we plan to offer this product to our customers in the future, however at this time we do not offer code signing certificates and thus details are not reflected in our CP/CPS. Since we plan to offer code signing in the future and would like to build ubiquity we have requested code signing usage to be including in our roots. It would be great if that can happen, however, I understand if this usage can only be added once we update code signing in our CP/CPS.

> - When I asked about your root whose name contained both "High Assurance" and
> "EV", you said that many CAs are issuing both types from the same root, and
> that you were issuing the two from different sub-CAs. However, Appendix B, 2.a.
> has an intermediate cert called "DigiCert High Assurance EV CA-2", and 3.a. has
> an End Entity certificate called a "DigiCert High Assurance EV CA-2 End
> Entity", which continues to mix the two concepts. What's the story?

I will try to be more clear, our root (DigiCert High Assurance EV Root CA) contains the name of both certificate types. We issue only EV enabled certificates from a specific sub-ca (DigiCert High Assurance EV CA-1) which contains our EV OID and references our EV CPS/Policies. OV certificates are issued from a separate sub-ca (DigiCert High Assurance EV CA-2) which does not contain our EV OID and references our OV CPS/Policies.

So to summarize:

DigiCert High Assurance EV CA-1 (sub-ca) issues only EV vetted and enabled end-user certificates which contain our EV OID and references our EV CPS/Policies. These EV certificates will activate the EV functionality built into the browser. This sub-ca is listed in our EV CPS only.

DigiCert High Assurance EV CA-2 (sub-ca) issues only OV vetted certificates which does not contain our EV OID and references our OV CPS/Policies. These OV certificates are not EV vetted or EV enabled so they will not activate the EV functionality built into the browser. This sub-ca is listed in our OV CPS only.

Best Regards, Ken

Comment 13

[Gervase Markham [:gerv]]

OK, I'll wait for the updated CP/CPS. When you post it, pointers to the relevant sections would be appreciated.

Re: code signing, I am currently minded not to enable code signing for CAs who do not yet have details written into their documents as to how they are going to issue the certs. (It makes it impossible for me to confirm compliance with the code-signing section of our policy.) You can, of course, write those details in some time before you are completely ready to roll out the service, and apply for a change of trust bits.

As for the EV things, it's not a big issue, just one of naming. I would have expected you to call the intermediate certs "DigiCert EV CA-1" and "DigiCert High Assurance CA-2" - i.e. to omit from the name the type of certificate which you are not issuing. But this is not a requirement :-)

Gerv

Comment 14

[Ken Bretschneider (DigiCert Inc)]

Hi Gerv,

In line below:

(In reply to comment #13)
> OK, I'll wait for the updated CP/CPS. When you post it, pointers to the
> relevant sections would be appreciated.

We have our new updated CPS (V3.04) live, which contains our email certificate details. The new updated link is as follows: http://digicert.com/CPS_V3-04_4-03-2007.pdf

Relevant sections are as follows:

3.1.1 (ending paragraph)
3.2.3 (3rd bullet & ending paragraph)
3.2.4
3.2.5 (ending paragraph)
Under - Appendix B }}} 3. DigiCert End Entity Certificates }}} d. DigiCert High Assurance CA-3 Email Certificate

> Re: code signing, I am currently minded not to enable code signing for CAs who
> do not yet have details written into their documents as to how they are going
> to issue the certs. (It makes it impossible for me to confirm compliance with
> the code-signing section of our policy.) You can, of course, write those
> details in some time before you are completely ready to roll out the service,
> and apply for a change of trust bits.

I understand Gerv. We will work to get our CPS updated for code signing at some later date. I suspect we will take care of this soon.

> As for the EV things, it's not a big issue, just one of naming. I would have
> expected you to call the intermediate certs "DigiCert EV CA-1" and "DigiCert
> High Assurance CA-2" - i.e. to omit from the name the type of certificate which
> you are not issuing. But this is not a requirement :-)

This makes sense Gerv. We have gone ahead and generated a new sub-ca with the name of DigiCert High Assurance CA-3 which will be used to issue our OV only certificates. This new sub-ca has replaced the DigiCert High Assurance EV CA-2 as of April 3rd, 2007.

Thanks, Ken

Comment 15

[Gervase Markham [:gerv]]

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. If anyone sees any factual errors, please point them out.

Section 4 [Technical]. I'm not aware of any technical issues with certificates issued by Digicert, 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]. Digicert appears to provide a service relevant to Mozilla users: they are a commercial CA with a varied clientele. Policies are documented in the documents published on their website and listed in the entry on the pending applications list.

Section 7 [Validation]. Digicert 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), Digicert verifies that the entity submitting the request controls the email account associated with the email address referenced in the certificate. (See section 3.2.3 of CPS v3.04.)

* SSL: For certificates with the TLS Web Server Authentication EKU (1.3.6.1.5.5.7.3.1), Digicert verifies domain control by communicating with the Administrative Contact listed in WHOIS. (See sections 3.2.5 and 4.2.1 of CPS v3.04.)

* Code: Digicert does not currently issue code signing certs.

Section 8-10 [Audit]. Digicert has successfully completed an independent audit using the WebTrust for CAs criteria. The auditors were KPMG. The audit expires in June 2007.

Section 13 [Certificate Hierarchy]. Digicert issues different classes of certificate from different intermediate roots, as explained in this bug.

Other: Digicert issues CRLs (on a 24-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.

Gerv

Comment 16

[Ken Bretschneider (DigiCert Inc)]

- np on the delay Gerv. I know you have a rather long list of CAs with new roots submitted. I appreciate your help/time. 

Thanks, Ken

Comment 17

[Gervase Markham [:gerv]]

Reassign all open CA bugs to me. Apologies for the bugspam.

Gerv

Comment 18

[Gervase Markham [:gerv]]

The comment period has passed without incident; I have therefore opened bug
378162 to cover the actual inclusion of the certificates in the store.

Gerv