416544 - Enable Entrust roots for EV

Status: RESOLVED FIXED

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

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: 

* Name of the CA certificate

Entrust has three Roots that are requested to be enabled for EV.

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

Entrust.net Secure Server Certification Authority
Authority Key Identifier: f0 17 62 13 55 3d b3 ff 0a 00 6b fb 50 84 97 f3 ed 62 d0 1a
Thumbprint (SHA1): 99 a6 9b e6 1a fe 88 6b 4d 2b 82 00 7c b8 54 fc 31 7e 15 39

Entrust.net Certification Authority (2048)
Key Identifier:	55 e4 81 d1 11 80 be d8 89 b9 08 a3 31 f9 a1 24 09 16 b9 70
Thumbprint (SHA1): 80 1d 62 d0 7b 44 9d 5c 5c 03 5c 98 ea 61 fa 44 3c 2a 58 fe

All Entrust roots can be found at: http://www.entrust.net/developer/index.cfm

* Published CP/CPS where you describe how you're operating in accordance with the EV guidelines.

Entrust's EV CPS can be found at: http://www.entrust.net/CPS/pdf/evssl_cps_english080107.pdf
The Entrust EV Business Practice statement can be found at: http://www.entrust.net/ev/business_practice.htm

* Published report describing how you're meeting the audit requirements of secton J of the EV guidelines (e.g., EV equivalent of current WebTrust reports).

Entrust's WebTrust for EV audit report can be found at: http://www.entrust.net/ssl-resources/pdf/webtrust-ev.pdf

* EV OID(s) for the CA certificate in question.

Entrust's EV Policy OID is: 2.16.840.1.114028.10.1.2

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

It appears that two of the 3 certificates named above are already in NSS's
root cert module, and for them, this bug merely asks that they be marked
for EV with the appropriate EV OID(s).  Those certs have "Entrust.net" in 
their names.

One of the certs named above, named: "Entrust Root Certification Authority"
does NOT appear to be presently in NSS's root CA list.  I will attach a copy
of the cert (obtained from their web site) shortly.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Attachment: Entrust Root Certification Authority

Here's the "Entrust Root Certification Authority" cert in PEM format.
Of course, don't take my word for it.  Check the SHA1 thumbprint for yourself.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Making EV root cert requests have uniform summaries.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

This bug requests that one cert be added to NSS, and that that cert and 
two others (already in NSS) be approved for EV.

But it appears that the cert that this bug asks to add to NSS has already
been requested in a prior bug, bug 382352, and has already been approved
to be added to NSS (see bug 387892).

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

Agreed? 

By the way, the serial number for the twice-requested cert is an ASCII string 
reading "EkPT".  Does that string have significance to Entrust?  :)

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

OK, I've got it straightened out now.  
This bug originally requested only that 3 Entrust roots be approved for EV.
One of those certs was not yet added to NSS, but it had already been 
approved to be added.  So, I'm changing the summary of this bug back to 
indicate that the scope of this bug is only to request EV approval.

Comment 6

[Kai Engert (:KaiE:)]

Bruce, can you please provide links to live EV test servers for each of the 3 roots?

Comment 7

[Bruce Morton]

For the first root listed above, here is a link:  https://www.entrust.net/

There are no EV certificates issued under the other two roots. I will work on getting test certs/pages set up for those roots.

Comment 8

[Kai Engert (:KaiE:)]

Attachment: patch

Please ignore this attachment. (I created it for some testing and attach it here as a backup.)

Comment 9

[Bruce Morton]

Kai, I hope that the lack of test certificates for the two roots does not impact the EV status of the first root. If this makes a difference, I will consider withdrawing the request for the latter two roots to be enabled for EV.

Comment 10

[Kai Engert (:KaiE:)]

(In reply to comment #9)
> Kai, I hope that the lack of test certificates for the two roots does not
> impact the EV status of the first root. If this makes a difference, I will
> consider withdrawing the request for the latter two roots to be enabled for EV.

If I understand correctly, Frank has not yet approved your request to enable your roots for EV. Correct?

I think the lack of test sites is irrelevant for Frank's approval work.
I'm not involved in the approval process at all, but I'll be waiting for a signal from Frank.

(Only after the approval processed is finished we can start the technical aspects of getting it enabled. I think the lack of test sites is not a requirement to technically enable your certs for EV, but would be highly preferred.)

Comment 11

[Bruce Morton]

Yes, Frank's approval is the issue of concern. My understanding was until this bugzilla is resolved then our roots were not approved for EV.

Comment 12

[Frank Hecker]

I've posted to mozilla.dev.tech.crypto newsgroup soliciting public comments on the request to enable the Entrust Root Certification Authority root for EV. (I'm postponing any action on Entrust.net Secure Server Certification Authority and Entrust.net Certification Authority for now.)

I've also updated the Entrust entry in the pending list to include the current EV info, including a link to the Entrust EV audit:

http://www.mozilla.org/projects/security/certs/pending/#Entrust

(I just checked in these changes, so they may take an hour or two to show up on the site.)

Comment 13

[Frank Hecker]

Bruce, as you previously noted to me, the Entrust Root Certification Authority has only one subordinate CA, Entrust Certificate Authority - L1A, which issues EV certificates. Does the L1A subordinate issue *only* EV certs? I'm guessing so, but again wanted to confirm.

Comment 14

[Bruce Morton]

Yes the L1A CA currently only issues EV certs; however, we do not want to limit the trust to only EV. 

Currently, the Entrust Root Certification Authroity is embedded in Microsft IE for all standard public key usages (server auth, client auth, code signing, secure email). It is also marked for EV. Our goal is browser ubiquity. The intention is that L1A will only issue SSL certificates and currently only issues EV SSL certificates. Additional certificate types (code signing, S/MIME) would likely require other issuing CAs to manage different certificate policies.

Comment 15

[Frank Hecker]

Bruce, thanks. Note that at present we have no way to technically restrict recognition to just EV certificates -- inclusion of a root automatically implies recognition of non-EV certs (with EV certs treated as non-EV), then there's a separate change to have EV certs recognized as EV. My question was rather directed at the question of which CPS governed various aspects of the Entrust Root CA and the L1A subordinate. Based on your response my assumption is that the EV CPS governs issuance of EV certs by the L1A CA, and the original Entrust CPS would govern any future issuance of non-EV SSL certs by the L1A CA.

As for any future issuance on S/MIME or code signing certs by other subordinates under Entrust Root CA, right now Entrust Root CA is enabled for recognition of SSL certs only. Recognition of S/MIME or code signing certs would require us to turn on the respective "trust bits" for those uses, and that in turn would depend on Entrust having a CPS or CPSs in place that addressed those types of certs. My understanding is the current CPS addresses SSL certs only.

Comment 16

[Bruce Morton]

Frank, your assumption on which CPS to use for EV and non-EV SSL certificates is correct. The end-entity certificate will have the specific policy OID that is referenced in the applicable CPS.

I understand your position on future issuance of S/MIME and code signing certificates. Traditionally, these trust bits are requested at the time of embedding. This allows the root to gain some browser ubiquity prior to actually issuing the certificate type. It would be a shame to have to cross-certify an embedded root at some future date to gain this coverage.

Comment 17

[Frank Hecker]

(In reply to comment #16)
> Frank, your assumption on which CPS to use for EV and non-EV SSL certificates
> is correct. The end-entity certificate will have the specific policy OID that
> is referenced in the applicable CPS.

Thank for confirming this.

> I understand your position on future issuance of S/MIME and code signing
> certificates. Traditionally, these trust bits are requested at the time of
> embedding. This allows the root to gain some browser ubiquity prior to
> actually issuing the certificate type.

You don't have to wait until you actually start issuing certificates. Our concern is rather with having a CPS that covers the procedures relating to the to-be-issued certs.

Comment 18

[Frank Hecker]

Kathleen Wilson has confirmed with Deloitte Touche that the WebTrust EV audit report for Entrust downloadable at

http://www.entrust.net/ssl-resources/pdf/webtrust-ev.pdf

is indeed genuine. So that particular issue is resolved to my satisfaction.

Comment 19

[Frank Hecker]

We've completed the initial period of public comments on the request to EV-enable the Entrust Root Certification Authority root CA certificate in Mozilla products. I am now ready to make a preliminary decision and start the second round of public comment on this request.

NOTE 1: This request is limited to the Entrust Root Certification Authority root, and it is independent of any requests or issues related to Entrust's other roots. In particular, I am postponing for now considering the requests in this bug to EV-enable the Entrust.net Secure Server Certification Authority and Entrust.net Certification Authority (2048) roots. We'll come back to those requests later.

NOTE 2: The Entrust Root Certification Authority root has already been approved for inclusion in Mozilla per the Mozilla CA certificate policy; see bug 382352. There was an issue raised in the first public comment period for this request relating to Entrust verification of ownership/control of domains when issuing non-EV SSL certificates. After reading the various comments on this issue and Entrust's responses, it is my judgment that Entrust is in compliance with the basic requirements of the policy with regard to non-EV SSL certs.

I'm therefore going to make my decision on this request based solely on Entrust's compliance with the EV parts of the Mozilla policy:

Section 6 [Relevancy and Policy]. Entrust's EV-related policies are documented in the Entrust CPS for EV SSL certificates:

http://www.entrust.net/CPS/pdf/evssl_cps_english080107.pdf

A summary of Entrust's EV offering is at

http://www.entrust.net/ev/business_practice.htm

Section 7 [Validation]. For EV SSL certificates Entrust verifies individual and organizational identity per the EV guidelines (see the Entrust EV CPS, including section 3 and in particular sections 3.1.8 and 3.1.9).

The Entrust Root Certificate Authority root as presently included in Mozilla is not marked for email or code signing use, so only SSL use is relevant for purposes of this request.

Section 8-10 [Audit]. Entrust has successfully completed an audit using the
WebTrust EV criteria. The auditors were Deloitte and Touche. The audit is
currently valid. The audit report is available from Entrust:

http://www.entrust.net/ssl-resources/pdf/webtrust-ev.pdf

We've verified with Deloitte that the report is genuine.

Section 13 [Certificate Hierarchy]. Entrust EV certificates are issued through the Entrust Certification Authority - L1A subordinate CA. At present that is the only subordinate CA under the Entrust Root Certification Authority root.

Based on the above I am minded to approve the request to EV-enable the Entrust Root Certification Authority root. Before I do any final approval, I'm opening up a final one-week period of public discussion of this request in the mozilla.dev.tech.crypto newsgroup [1].

[1] 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

Comment 20

[Frank Hecker]

The second comment period is now over, with no further comments received. Based on my evaluation and the comments received thus far, I am officially approving this specific request to enable the Entrust Root Certification Authority for EV use, and have filed bug 442561 against PSM for the actual change. 

Comment 21

[Kathleen Wilson]

Changing whiteboard status to approved.

Comment 22

[Frank Hecker]

Since the corresponding PSM change (bug 442561) has been resolved FIXED, I'm resolving this bug as FIXED as well.