Open Bug 1480510 Opened Last year Updated Last month

Add Entrust G4 Root

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: bruce.morton, Assigned: wayne)

Details

(Whiteboard: [ca-in-discussion] - WT 2019-07-26)

Attachments

(6 files)

Attached file 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
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
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
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-verifying]
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."
QA Contact: kwilson
Whiteboard: [ca-verifying] → [ca-verifying] - KW Comment #5 2018-10-09
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.
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.
Assignee: kwilson → wthayer
Whiteboard: [ca-verifying] - KW Comment #5 2018-10-09 → [ca-cps-review] - KW 2018-10-12
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
Flags: needinfo?(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.
Flags: needinfo?(bruce.morton)
(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?
Whiteboard: [ca-cps-review] - KW 2018-10-12 → [ca-cps-review] - Pending CPS Updates 2018-12-21
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.

Bruce: any update on this?

Flags: needinfo?(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.

Flags: needinfo?(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."

Whiteboard: [ca-cps-review] - Pending CPS Updates 2018-12-21 → [ca-in-discussion] - WT 2019-07-26

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

You need to log in before you can comment on or make changes to this bug.