1701317 - ISRG Root X2 inclusion request

Status: RESOLVED FIXED

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

Description

[Josh Aas]

ISRG (Let's Encrypt) would like to request the inclusion of our ECDSA root, ISRG Root X2:

https://crt.sh/?id=3335562555
https://letsencrypt.org/certs/isrg-root-x2.pem

CCADB Case: 00000749

This root will only be used for TLS-enabled servers, not email or code signing.

This root will only issued Domain Validation (DV) certificates, not OV or EV.

CP and CPS documents can be found here:

https://letsencrypt.org/repository/

Test websites can be found here:

valid-isrgrootx2.letsencrypt.org
revoked-isrgrootx2.letsencrypt.org
expired-isrgrootx2.letsencrypt.org

Note that the expired website does not have an expired certificate yet because we do not want to modify our systems to issue a certificate with a lifetime less than 90 days. We believe modifying our issuance systems for such an exceptional event is not worth the risk.

Comment 1

[Ben Wilson]

Please update these two sections at https://ccadb.force.com/a004o00000AhCpkAAF :

• Application Information
• PKI Hierarchy

Comment 2

[Josh Aas]

Updated

Comment 3

[Ben Wilson]

There are three other sections at this URL - https://ccadb.force.com/5004o00000KEucgAAD that need to be completed under "Mozilla Additional Requirements." They are "BR Self Assessment", "CA's Response to Required Practices", and "CA's Response to Forbidden Practices". Thanks.

Comment 4

[Josh Aas]

Attachment: 2021.05 ISRG BR Self Assessment

Comment 5

[Josh Aas]

We have completed the Mozilla Additional Requirements section.

Comment 6

[Ben Wilson]

Review of ISRG CP (v.2.6) and CPS (v.3.2)

available at https://letsencrypt.org/docs/

Here are the results of a CP/CPS review for the following policy requirements:

CP/CPS structured in accordance with RFC 3647 with no blank sections (MRSP § 3.3.5) (BR § 2.2)

Good. ISRG satisfies this requirement.

---

CP/CPS made available under a Creative Commons License (MRSP § 3.3.3)

“CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)”

Good. Section 1.1 of the CPS states, “This work is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/ …”

---

Statement of adherence to BRs and their precedence (MRSP § 2.3) (BR § 2.2)

“The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version”, including a statement such as “in the event of any inconsistency between this CP/CPS and those Requirements, those Requirements take precedence.” CAB Forum requirement or guideline shall take precedence.”

Good. Section 1.1 of the CPS also states “If there is any conflict between this CPS and a relevant CAB Forum requirement or guideline, then the CAB Forum requirement or guideline shall take precedence.”

---

Separate, EKU-constrained issuing CAs (MRSP § 5.3) (BR § 7.1.2.2.g.)

Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU.

Good. A review of the E1 and E2 Intermediate CAs indicates the following EKUs: Client Authentication, Server Authentication.

---

Clear identification of CAs covered by CP/CPS (MRSP § 3.3.6)

“CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.”

Good. The X1 and X2 root CAs are listed in section 1.1 of the CPS.

---

Explicit annual revision of CP/CPS w/ table of changes (MRSP § 3.3.4) (BR § 2.3)

“CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.” Also, a version history table provides evidence of compliance and good change management practices.

Satisfactory. Section 9.12.1 indicates that the CPS is reviewed at least annually. Also see CPS Section 1.2 for a table of changes.

---

Statement of Non-Delegation for Domain Validation (BR § 1.3.2)

“With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.”

Good. Section 1.3.2 indicates, “RA services are not performed by third parties.”

---

Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3)

“The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.”

Satisfactory. Section 1.5.2 of the CPS says, “Certificate Problem Reports can be submitted via email to: [e-mail].”

---

Naming compliant with X.500, RFC5280 and BRs

The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards.

Satisfactory. Section 3.1.1 of the CPS says, “Certificate distinguished names and subject alternative names are compliant with the CP.” Section 7.1.4 of the CPS also refers to the CP. Section 7.1.4.2.1 of the CP (Subject alternative name extension) contains unnecessary language copied from the Baseline requirements. Also, Section 7.1.4.2.2 of the CP (Subject distinguished name fields), or a corresponding provision of the CPS, could be updated and written as more specific to the DV certificates issued by ISRG.

---

No internal names or reserved IP addresses (BR § 7.1.4.2.1)

“CAs SHALL NOT issue certificates with a subjectAltName extension or subject:commonName field containing a Reserved IP Address or Internal Name.”

Should be updated. Section 7.1.4.2.1 of the CP (Subject alternative name extension) is outdated and should be replaced.

---

ALL certificates must meet Mozilla/BR validation requirements

CPS must specifically explain validation methods and validation steps taken to verify certificate requests in accordance with BR §§ 3.2.2.4 and 3.2.2.5 (MRSP § 2.2.3 and MRSP § 3.3.1)

CP/CPS must be sufficient “for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate requests”.

Needs to be updated. Section 3.2.2 of the CPS indicates that ISRG uses the following methods from the Baseline Requirements: sections 3.2.2.4.6, 3.2.2.4.7, and 3.2.2.4.10. The method in BR section 3.2.2.4.6 (change to a website) is replaced with section 3.2.2.4.19. And method under section 3.2.2.4.10 (TLS Using a Random Number) has been removed. It appears that some updates have been made to the CP. Still, ISRG should review the most recent version of the Baseline Requirements and update its CP and CPS accordingly.

---

CA validates domain part of all e-mail addresses (MRSP § 2.2.2)

“For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA SHALL NOT delegate validation of the domain portion of an email address.”

N/A

---

Data sources need to be accurate (BR § 3.2.2.7 and EVG § 11.11.5)

For OV – “[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.”

Good. ISRG’s CP section 3.2.2.7 notes the criteria for determining data source accuracy.

---

All information in a certificate must be verified (MRSP § 2.2.1)

“All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information or an alternative communication channel before it is included in the certificate.”

Good. Section 3.2.4 of the CPS states, “Non-verified Applicant information is not included in ISRG certificates.”

---

Data reuse (certificate renewal) limited to 398 and 825 days (MRSP § 2.1.5) (BR § 4.2.1)

CAs must “verify that all of the information that is included in SSL certificates remains current and correct at time intervals of 825 days or less”, and “for server certificates issued on or after October 1, 2021, each dNSName or IPAddress in a SAN or commonName MUST have been validated in accordance with section 3.2.2 of the CA/Browser Forum's Baseline Requirements within the prior 398 days.”

Should be fixed. While it is noted that section 4.6 of the CPS states, “Certificate renewal requests are treated as applications for new certificates.” ISRG should update section 4.2.1 of its CP to conform to the new 398-day reuse period allowed for domain names and IP addresses. Alternatively, the CPS could make it more explicit that ISRG does not rely on any reuse of domain validation (and IP address validation, if any) performed under CPS section 3.2.2.

---

CAA record checking and recognized domain names in section 4.2 (BR § 2.2)

“Section 4.2 of a CA’s Certificate Policy and/or Certification Practice Statement SHALL state the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements.”

Needs to be fixed. The Baseline Requirements require that the CCA record processing practices appear in section 4.2 of the CP/CPS. Currently, this language appears in section 3.2.2.8 of the CP, which is good, but this language needs to be relocated to section 4.2.

---

Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3)

CAs must “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”.

Good. Section 6.5.1 of the CP states, “The CA SHALL enforce multi-factor authentication for all accounts capable of directly causing certificate issuance.”

---

Pre-issuance linting (Recommended Practices)

“It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences”

Should be fixed. ISRG should explain that it performs pre-issuance checks on certificates to avoid misissuance.

---

Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2)

24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)

Needs to be fixed. Part of subsection 11 in section 4.9.1.1 of the Baseline Requirements was moved to subsection 4 in 4.9.1.1 and requires 24-hour revocation when “The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, . . . ). ISRG needs to update its CP.

---

CRLs at least every 7 days w/ nextUpdate not more than 10 days (MRSP § 6)

Satisfactory. See CP/CPS section 4.9.7.

---

Clearly specify methods to demonstrate private key compromise (MRSP § 6)

Effective with version 2.7.1 of the Mozilla Root Store Policy, CAs are supposed to specify how parties can demonstrate key compromise to them in section 4.9.12 of their CPS.

Should be fixed. ISRG indicated in the April 2021 CA Survey “Section 4.9.12 of our CPS already specifies the methods that parties may use to demonstrate private key compromise.” Section 4.9.12 of the CPS references section 4.9.3, which states “Revocation requests may be made by anyone, at any time, via the Certificate Revocation interface of the ACME Protocol defined in RFC 8555 section 7.6. Successful revocation requests with a reason code of keyCompromise will result in the affected key being blocked for future issuance and all currently valid certificates with that key will be revoked.” It would be better if that explanation appeared in section 4.9.12 itself and not as a cross-reference. Also, I am not sure that the process provided by ISRG constitutes a demonstration of key compromise.

---

CA must not allow certificate suspension (BR § 4.9.13)

Good. According to section 4.9.13 of the CPS, “ISRG does not suspend certificates.”

---

OCSP updates every 4 days w/ max. expiration of 10 days (MRSP § 6)

Good. Section 4.9.10 of the CP states intervals consistent with the requirements.

---

Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7)

“Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla.”

Good. Section 5.7.1 of the CP states, “The CA SHALL document a business continuity and disaster recovery procedures designed to notify and reasonably protect Application Software Suppliers, Subscribers, and Relying Parties in the event of a disaster, security compromise, or business failure.” Also, section 5.7.3 of the CPS states, “ISRG will notify root programs relying on the integrity of the key in question.”

---

CA must not generate Subscriber key pairs (MRSP § 5.2)

“CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage.”

Good. Section 6.1.2 of the CPS states, “ISRG never generates or has access to Subscriber Private Keys.”

---

Must meet RSA key requirements (MRSP § 5.1)

Satisfactory. Sections 6.1.5 and 6.1.6 of the CP adequately specify requirements for RSA key pairs.

---

Must meet ECC key requirements, P-256 or P-384 (MRSP § 5.1)

Satisfactory. Sections 6.1.5 and 6.1.6 of the CP adequately specify requirements for ECC key pairs.

---

Certificate lifetimes limited to 398 days (BR § 6.3.2)

“Subscriber Certificates … SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.”

Good. ISRG certificates are issued for a maximum of 90-100 days.

---

Network Security (MRSP § 2.1.2)

CAs must “follow industry best practice for securing their networks, for example by conforming to the CAB Forum Network Security Guidelines or a successor document”.

Should be fixed. While section 5 of ISRG’s CP states, “The CA/Browser Forum’s Network and Certificate System Security Requirements are incorporated by reference as if fully set forth herein,” ISRG should amend either section 5 or section 6.7 of its CPS to state that it complies with the CA/Browser Forum’s Network and Certificate System Security Requirements.

---

Serial numbers greater than 64 bits generated by a CSPRNG (MRSP § 5.2)

“all new certificates MUST have a serial number greater than zero, containing at least 64 bits of output from a CSPRNG.”

Good. Both the CP and CPS reference that serial numbers must be unique with 64 bits of output from a CSPRNG.

---

EKUs required in certificates issued after 7-1-2020 (MRSP § 5.2) (BR § 7.1.2.3.f)

Good. Section 7.1.2.3.f of the CP states that extKeyUsage is required.

---

Use of SHA-1 prohibited (MRSP § 5.1.3) (BR § 7.1.3.2.1)

Good. Section 7.1.3.2 of the CP states the appropriate conditions under which a SHA-1 certificate may be issued.

---

Any CN must also be in a SAN (BR § 7.1.4.2.2.a)

Good. CPS Section 7.1 (profile for end entity certificates) indicates that the CN=one of the values from the Subject Alternative Name extension. Also, section 7.1.4.2.2 of the CP states, “If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension.”

Comment 7

[Josh Aas]

We have issued CP v2.7 and CPS v3.3 to address the comments here.

https://letsencrypt.org/repository/

We really appreciate the review and the helpful notes.

Comment 8

[Ben Wilson]

Review of ISRG CP (v.2.7) and CPS (v.3.3)

Here are the results of a follow-up review of the IRSG CP and CPS based on Comment #6.

---

No internal names or reserved IP addresses (BR § 7.1.4.2.1)

“CAs SHALL NOT issue certificates with a subjectAltName extension or subject:commonName field containing a Reserved IP Address or Internal Name.”

Should be updated. Section 7.1.4.2.1 of the CP (Subject alternative name extension) is outdated and should be replaced.

Fixed

---

ALL certificates must meet Mozilla/BR validation requirements

CPS must specifically explain validation methods and validation steps taken to verify certificate requests in accordance with BR §§ 3.2.2.4 and 3.2.2.5 (MRSP § 2.2.3 and MRSP § 3.3.1)

CP/CPS must be sufficient “for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate requests”.

Needs to be updated. Section 3.2.2 of the CPS indicates that ISRG uses the following methods from the Baseline Requirements: sections 3.2.2.4.6, 3.2.2.4.7, and 3.2.2.4.10. The method in BR section 3.2.2.4.6 (change to a website) is replaced with section 3.2.2.4.19. And method under section 3.2.2.4.10 (TLS Using a Random Number) has been removed. It appears that some updates have been made to the CP. Still, ISRG should review the most recent version of the Baseline Requirements and update its CP and CPS accordingly.

Fixed

---

Data reuse (certificate renewal) limited to 398 and 825 days (MRSP § 2.1.5) (BR § 4.2.1)

CAs must “verify that all of the information that is included in SSL certificates remains current and correct at time intervals of 825 days or less”, and “for server certificates issued on or after October 1, 2021, each dNSName or IPAddress in a SAN or commonName MUST have been validated in accordance with section 3.2.2 of the CA/Browser Forum's Baseline Requirements within the prior 398 days.”

Should be fixed. While it is noted that section 4.6 of the CPS states, “Certificate renewal requests are treated as applications for new certificates.” ISRG should update section 4.2.1 of its CP to conform to the new 398-day reuse period allowed for domain names and IP addresses. Alternatively, the CPS could make it more explicit that ISRG does not rely on any reuse of domain validation (and IP address validation, if any) performed under CPS section 3.2.2.

Fixed

---

CAA record checking and recognized domain names in section 4.2 (BR § 2.2)

“Section 4.2 of a CA’s Certificate Policy and/or Certification Practice Statement SHALL state the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements.”

Needs to be fixed. The Baseline Requirements require that the CCA record processing practices appear in section 4.2 of the CP/CPS. Currently, this language appears in section 3.2.2.8 of the CP, which is good, but this language needs to be relocated to section 4.2.

Fixed - Section 4.2.4 of the CPS states, "As part of the issuance process, ISRG will check for CAA records and follow the processing instructions found, for each dNSName in the subjectAltName extension of the certificate to be issued, as specified in RFC 8659. If the CA issues, the CA will do so within the TTL of the CAA record, or 8 hours, whichever is greater. See Section 3.2.2.8 of the ISRG CP for more information about CAA checking policy."

---

Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2)

24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)

Needs to be fixed. Part of subsection 11 in section 4.9.1.1 of the Baseline Requirements was moved to subsection 4 in 4.9.1.1 and requires 24-hour revocation when “The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, . . . ). ISRG needs to update its CP.

Fixed

Comment 9

[Ben Wilson]

Public discussion began today with a tentative closure date in three weeks (Oct. 11, 2021) - https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/D8coPL0eU3k/m/bE_aRuWxCAAJ

Comment 10

[Ben Wilson]

Public discussion closed today with a recommendation that Mozilla approve ISRG's/Let's Encrypt's inclusion request:
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/D8coPL0eU3k/m/t1JxqeZ8AwAJ A one-week "last call" period will end on 22-Oct-2021.

Comment 11

[Kathleen Wilson]

As per Comment #10, and on behalf of Mozilla I approve this request from Internet Security Research Group (ISRG) to include the following root certificate:

** ISRG Root X2 (Websites)

I will file the NSS bug for the approved changes.

Comment 12

[Kathleen Wilson]

I have filed bug #1738805 against NSS and for the actual changes.