1480510 - Add Entrust G4 Root

Status: RESOLVED FIXED

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

Description

[Bruce Morton]

Attachment: Entrust_Root_CA_G4.txt

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.84 Safari/537.36

Steps to reproduce:

Add Entrust root certificate with CN = Entrust Root Certification Authority - G4

Comment 1

[Bruce Morton]

Attachment: Entrust_G4_ CA Information.pdf

Comment 2

[Bruce Morton]

Attachment: Entrust- CA's BR Self Assessment - 201807 v1.pdf

Comment 3

[Bruce Morton]

The Entrust CPS has been updated to support the Mozilla Policy 2.6, see https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20180801-version-3_1.pdf

Comment 4

[Kathleen Wilson]

Acknowledging receipt of this root inclusion request. I have a huge backlog of CA updates/requests to review, so this has been added to my list. I will update this bug when I begin information verification of this request as per step #2 of our process:
https://wiki.mozilla.org/CA/Application_Process#Process_Overview

Comment 5

[Kathleen Wilson]

Attachment: 1480510-CA-Information-Oct9-2018.pdf

The attached file shows the CA information that has been verified. Search in the document for the word "NEED" to see where further clarification is requested.

In particular:

1) Replace all instances of "No Stipulation" in the CPS with more specific/accurate text -- only use "No Stipulation" when there are no rules regarding that section. For example, if it is a domain validation method that is not used by your CA, change "No Stipulation" to "This method of domain validation is not used" or "... not allowed".

2)  Resolve all errors listed here:
https://certificate.revocationcheck.com/validg4.entrust.net

3) Update CPS section 7.1.6.3 to require third party subordinate CAs to comply with this CPS and with the BRs if EKU in the subCA cert enables SSL cert issuance.
CPS section 7.1.6.3 says: "Subordinate CA Certificates issued to a Third Party Subordinate CA must include one or more explicit certificate policy object identifiers that indicates the Third Party Subordinate CA’s adherence to and compliance with the requirements documented in its CP and/or CPS. These requirements may include adherence and compliance to the Baseline Requirements."

Comment 6

[Bruce Morton]

Response to comments above:

1) We will update the CPS to replace “No stipulation” with other statements in sections 3.2.2.4, 4.5.1, 4.9.11, 4.9.13 and 7.1.5. We will replace "No stipulation" in sections 4.9.14, 4.9.15 and 4.9.16 with "Not applicable" as these sections are about Suspension, which cannot be performed per the BRs. For other sections using “No stipulation”, there are currently no changes planned if the the BRs state “No stipulation”, “Not applicable” or a blank section. 

2) There are no errors listed at https://certificate.revocationcheck.com/validg4.entrust.net.

3) We will update CPS section 7.1.6.3 to require the BRs to be met if a Third Party Subordinate CA is permitted to issue SSL certificates.

I will follow up with a link to the updated CPS.

Bruce.

Comment 7

[Bruce Morton]

The Entrust CPS has been updated to cover comments 1 and 3 above. See https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20181012-version-3_2.pdf?la=en&hash=6A125479A6A3C564F393D7811007DCF8AB551BA8

Bruce.

Comment 8

[Kathleen Wilson]

Attachment: 1480510-CA-Information-Oct12-2018.pdf

Comment 9

[Kathleen Wilson]

This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.

Comment 10

[Wayne Thayer]

I've performed a preliminary review and identified the following potential concerns:

* External RAs are permitted, but the CPS does not make it clear that domain validation will not be delegated as required by BR section 1.3.2.
* Entrust self-reported a bug in which they had improperly encoded an IP address in a certificate. [1] In March 2018, they indicated in the bug that they would implement pre-issuance linting, but not until early 2019. While pre-issuance linting is not a requirement, it is certainly a best practice and taking almost a year to implement it is discouraging. In fact, it appears [2] that another recent misissuance would have been prevented if pre-issuance linting had been implemented sooner.
* In the most recent incident [3], Entrust failed to meet the 5-day revocation requirements because “the revocation process was not followed properly.” Ryan Sleevi requested a separate incident report be filed for this issue, but so far that has not been done and we have not received further information on the root cause of the revocation failure.
* CPS section 9.8.2.2 appears to limit liability to $1000 USD per Subscriber, but EVGL section 18 sets a minimum of $2000 USD.

Would Entrust like to make any updates to the CPS or the incident bugs I've noted before I begin a public discussion?

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1448986
[2] https://crt.sh/?id=958918578&opt=cablint
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1512018
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1390996
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1428891
[6] https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/2018-specified-procedures-report.pdf

Comment 11

[Bruce Morton]

Thanks for the review. Please wait for a CPS update before starting the public discussion. This will also give us time to raise the other incident report.

Regarding 9.8.2.2, we have addressed the limit of liability in the Subscriber agreement, section 9.2, see https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/subscription_agreement_20180320.pdf?la=en&hash=11C8332F4159A75F271B02A7D2B96CC39B778F32. Please advise if this meets Mozilla's requirements.

Thanks, Bruce.

Comment 12

[Wayne Thayer]

(In reply to Bruce Morton from comment #11)
> Regarding 9.8.2.2, we have addressed the limit of liability in the
> Subscriber agreement, section 9.2, see
> https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/
> subscription_agreement_20180320.
> pdf?la=en&hash=11C8332F4159A75F271B02A7D2B96CC39B778F32. Please advise if
> this meets Mozilla's requirements.

I would expect the CPS to take precedence over the Subscriber Agreement. Perhaps one of your attorneys can take a look and explain how this meets the EVGL requirement?

Comment 13

[Bruce Morton]

I believe the Subscriber Agreement takes precedence as this is the contractual agreement between Entrust and the Subscriber. The Subscriber Agreement references the CPS as a subordinate document. Also, please note that the EV Guidelines also take precedent over the CPS, as stated in the EV Guideline and the CPS. 

I will review this issue with our legal council.

Comment 14

[Wayne Thayer]

Bruce: any update on this?

Comment 15

[Bruce Morton]

(In reply to Wayne Thayer [:wayne] from comment #14)

Bruce: any update on this?

The CPS has been updated to address the EV $2000 USD issue, see https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190531-version-3_4.pdf.

Pre-issuance linting has been deployed and the separate incident report due to the late revocation has been issued and closed.

I failed to update CPS section 1.3.2 to state that a third-party cannot validate a domain name (or an IP address). This change will be in the next release which should be posted by the end of July 2019. I will post an update when the CPS is published.

Comment 16

[Bruce Morton]

The CPS has been updated and addresses the the third-party domain validation issue, see
https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190725-version-35.pdf. CPS section 1.3.2 states, "Third Party RAs may not be delegated to validate FQDNs nor IP Addresses per §3.2.2.4 or §3.2.2.5."

Comment 17

[Wayne Thayer]

Discussion period has begun: https://groups.google.com/d/msg/mozilla.dev.security.policy/-4B6g8T-kis/q-xuaS0TDAAJ

Comment 18

[Bruce Morton]

Attachment: Entrust - Specified Procedures Report 2019 FINAL.pdf

This is a specified procedures audit report to address the qualified items in the annual BR/Network Security audit report.

Comment 19

[Bruce Morton]

(In reply to Wayne Thayer [:wayne] from comment #17)

Discussion period has begun: https://groups.google.com/d/msg/mozilla.dev.security.policy/-4B6g8T-kis/q-xuaS0TDAAJ

Per the discussion, sections 4.2 and 9.12.3 have been updated in the CPS, see https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190930-version-36.pdf.

Comment 20

[Wayne Thayer]

Sent update to the list requesting any additional comments by 10/15.

Comment 21

[Wayne Thayer]

The discussion period for this request has ended. I believe that all questions have been answered, so I am recommending approval of this request.

Link to the discussion: https://groups.google.com/d/msg/mozilla.dev.security.policy/-4B6g8T-kis/q-xuaS0TDAAJ

Comment 22

[Kathleen Wilson]

The information for this root inclusion request is available at the following URL.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000332

Comment 23

[Kathleen Wilson]

As per Comment #21, and on behalf of Mozilla I approve this request from Entrust to include the following root certificate:

** 'Entrust Root Certification Authority - G4' (Email, Websites), enable EV

I will file the NSS and PSM bugs for the approved changes.

Comment 24

[Kathleen Wilson]

I have filed bug #1591178 against NSS and bug #1591180 against PSM for the actual changes.