Closed Bug 1480510 Opened 3 years ago Closed 1 year ago

Add Entrust G4 Root

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bruce.morton, Assigned: kwilson)

References

Details

(Whiteboard: [ca-approved] - In NSS 3.48, FF 72; EV enabled in FF 76)

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.

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

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

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

Assignee: wthayer → kwilson
Whiteboard: [ca-in-discussion] - WT 2019-07-26 → [ca-pending-approval]

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

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

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.

Whiteboard: [ca-pending-approval] → [ca-approved] - Pending NSS and PSM code changes
Depends on: 1591178
Depends on: 1591180

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

Whiteboard: [ca-approved] - Pending NSS and PSM code changes → [ca-approved] - In NSS 3.48, FF 72; pending PSM code changes
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Whiteboard: [ca-approved] - In NSS 3.48, FF 72; pending PSM code changes → [ca-approved] - In NSS 3.48, FF 72; EV enabled in FF 76
You need to log in before you can comment on or make changes to this bug.