382352 - Add Entrust Root Certificate

Status: RESOLVED FIXED

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

Description

[Bruce Morton]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Build Identifier: 

The following Root CA certificate was created primarily for the for CAB Forum Extended Validation (EV) program. Please add to to the Mozilla root store:

Entrust Root Certification Authority
Key Identifier: 68 90 e4 67 a4 a6 53 80 c7 86 66 a4 f1 f7 4b 43 fb 84 bd 6d 
Thumbprint: b3 1e b1 b7 40 e3 6c 84 02 da dc 37 d4 4d f5 d4 67 49 52 f9

Contact Information:
Entrust Limited
1000 Innovation Drive
Ottawa, Ontario, Canada
K2K 3E7
Attention: Bruce Morton

I will follow up with email to submit all of the required information.

Bruce Morton
Entrust


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Bruce Morton]

Website:  www.entrust.net

One Paragraph Summary of CA, including the following:
  - General nature (e.g., commercial, government,academic/research, nonprofit)
  - Primary geographical area(s) served
  - Number and type of subordinate CAs

Entrust is a commercial CA serving the global market for SSL web certificates. Entrust also issues certificates to subordiate CAs for enterprise and commercial use. Currently Entrust has three enterprise subordiate CAs that issue certificates for SSL and S/MIME internal use. There are also six commercial subordinate CAs that issue SSL certificates to the public.

Audit Type (WebTrust, ETSI etc.):  WebTrust for CA and WebTrust for EV

Auditor:  Deloitte and Touche LLP

Auditor Website:  www.deloitte.ca

Audit Document URL(s):  https://entrust.webtrust.org/ViewSeal?id=328  (Note - 2007 audit reports have not been posted as of 30 May 2007)

Certificate Details
-------------------
(To be completed once for each certificate)

Certificate Name:  Entrust Root Certification Authority

Summary Paragraph, including the following:
  - End entity certificate issuance policy,
    i.e. what you plan to do with the root Certificate HTTP URL (on CA website):

This root was primarility created as the trust root for Entrust EV SSL certificates. The Entrust EV Business Practice statement can be found at http://www.entrust.net/ev/business_practice.htm

Version:  V3

SHA1 Fingerprint:  b3 1e b1 b7 40 e3 6c 84 02 da dc 37 d4 4d f5 d4 67 49 52 f9

Modulus Length (a.k.a. "key length"):  RSA (2048 bits)

Valid From (YYYY-MM-DD):  2006-11-27

Valid To (YYYY-MM-DD):  2026-11-27

CRL HTTP URL:  not applicable for the root; issuing CA CRL can be found at http://crl.entrust.net/rootca1.crl

OCSP URL:  http://ocsp.entrust.net

Class (domain-validated, identity/organisationally-validated or EV):  OV and EV (currently only EV)

Certificate Policy URL:  http://www.entrust.net/about/practices.cfm

CPS URL:  http://www.entrust.net/about/practices.cfm

Requested Trust Indicators (email and/or SSL and/or code): email, SSL and code signing

URL of website using certificate chained to this root (if applying for SSL):  https://www.entrust.net

Comment 2

[Gervase Markham [:gerv]]

Hi Bruce,

Thanks for the info. You missed one important thing - an HTTP URL to the certificate itself :-)

Does this document: http://www.entrust.net/CPS/pdf/webcps051404.pdf
function as both a CP and a CPS?

Also, I'm slightly confused - you say that https://www.entrust.net is using this root, but I don't get an error in my browser. Is this some cross-signing magic? None of the roots in the chain I see look like the one you've described here.

Thanks,

Gerv

Comment 3

[Bruce Morton]

Attachment: Root CA certificate

Comment 4

[Bruce Morton]

Gerv, answers to your comments, itemized below:

1. I have attached the root certificate to the bug report.

2. Entrust does not have a separate CP, so yes, the CPS documents function as both. We have both an EV and a non-EV CPS found at the following:
http://www.entrust.net/CPS/pdf/evssl_cps_english011107.pdf
http://www.entrust.net/CPS/pdf/webcps051404.pdf

3. You are correct, the actual Root CA certificate is not found in the chain of https://www.entrust.net. It has been replaced on the web server by a cross-certificate to our legacy Root. This also explains why you do not get an error in your browser.

Regards, Bruce.

Comment 5

[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/
(Note: it may be a few hours before this updates.)

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 at the top of the 
entry, please feel free to provide one. Note: these paragraphs are not 
supposed to be marketing statements :-)

Gerv

Comment 6

[Bruce Morton]

Have reviewed the inormation at http://www.mozilla.org/projects/security/certs/pending/#IDAC3OGB and have the following comments:

1. WebTrust for EV audit report can be found at http://www.entrust.net/ssl-resources/pdf/webtrust-ev.pdf. This link could be added to the Audit line.

2. The two (CPS) document links are the same. This link for the EV CPS should be added http://www.entrust.net/CPS/pdf/evssl_cps_english011107.pdf

3. The CA summary paragraph can be changed to "Entrust is a commercial CA serving the global market for SSL web certificates. Entrust also issues certificates to subordiate CAs for enterprise and commercial use."

Comment 7

[Gervase Markham [:gerv]]

Bruce,

Thanks for that. We will be doing EV approvals as a separate process (which I have to think about, now that EV has gone 1.0!).

- The document you reference is the "Entrust SSL Web Server Certification Practice Statement", version 2.06. However, you also are requesting the email and code signing bits to be set for your cert. Can you show me the CPS which covers your issuance of these certificate types?

- Do you have a certificate hierarchy diagram?

- At what frequency do you issue CRLs for end entity certificates?

Gerv

Comment 8

[Bruce Morton]

1. We currently do not issue code signing or S/MIME certificates, but I want to ensure that we are embedded properly so as not to preclude this in the future. We do not have a CPS that covers code signing or secure email certificates.

2. I do not have a certificate hierarchy diagram. Please let me know if this is a requirement.

3. We issue our CRL every 24 hours.

Comment 9

[Gervase Markham [:gerv]]

1. We can't enable you for these functions without knowing what your procedures are or will be. I will remove that part of the request. As soon as you are prepared to issue such certs, let us know and we can go through a process to flip the bits.

2. It's not a requirement; it's just useful. Perhaps you might be able to describe it briefly in words? Do you have separate intermediate CAs for each class of certificate, for example?

Gerv

Comment 10

[Bruce Morton]

Entrust CA Hierarchy

Entrust.net Secure Server CA - 1024 bit Root CA used for issuing SSL (non EV) certificates, cross-certificates, and intermmediate CA certificates.

Entrust Root CA - 2048 bit Root Ca used for issuing intermediate CA certificates. This CA has been cross-certified by the above CA for legacy browser coverage.

Entrust L1A CA - 2048 bit Intermediate CA used for issuing EV SSL certificates. This CA's certificate has been signed by the above CA.

Comment 11

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

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 Entrust, 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]. Entrust appears to provide a service relevant to Mozilla users: they are a commercial CA serving the global market for SSL web certificates. Policies are documented in the documents published on their website and listed in the entry on the pending applications list.

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

* Email: Entrust do not currently issue email certificates.

* SSL: For certificates with the TLS Web Server Authentication EKU (1.3.6.1.5.5.7.3.1), Entrust verifies domain control by consulting databases (presumably including WHOIS) to see that the information matches their validated identity. As they do not issue DV certificates, this is sufficient. (See section 3.1.8 of CPS v2.06.)

* Code: Entrust do not currently issue code-signing certificates.

Section 8-10 [Audit]. Entrust has successfully completed an audit using the WebTrust for CAs criteria. The auditors were Deloitte and Touche. The audit is currently valid.

Section 13 [Certificate Hierarchy]. Entrust has a legacy 1024-bit root, and a more recent 2048-bit root, used for issuing intermediate certificates only.

Other: Entrust 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 12

[Gervase Markham [:gerv]]

The two-week comment period has passed with no comments. I have opened bug 387892 to track the inclusion of this certificate in NSS.

Gerv

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

Bug 416544 seems to be requesting the addition of the same certificate 
as the cert this bug requested.  

If we remove the apparently-duplicate request to add this cert from bug 416544,
then I think that bug reduces to merely a request to approve some existing 
Entrust roots (already in NSSckbi) for EV.

Comment 14

[Bruce Morton]

The confusion may be caused by my unfamiliarity of the process. I opened this bug 382352 to add our new root cert. Marking of the new root as EV was out of scope per comment #7 above. I understood that this bug was resolved and the actual inclusion was being tracked by bug 387892 per comment #12. 

I have subsequently opened bug 416544 to request EV status for three roots certificates including the new root being added.