cps.letsencrypt.orgISRG CP/CPS v5.3 - Let's Encrypt

Internet Security Research Group (ISRG) Combined Certificate Policy and Certification Practice Statement Version 5.3 Updated March 22, 2024 Approved by the ISRG Policy Management Authority 1. INTRODUCTION 1.1 Overview This combined Certificate Policy ("CP") and Certification Practice Statement ("CPS") document ("CP/CPS") outlines the certification services practices for Internet Security Research Group ("ISRG") Public Key Infrastructure ("ISRG PKI"). ISRG PKI services include, but are not limited to, issuing, managing, validating, and revoking publicly-trusted Certificates in a manner consistent with this CP/CPS. These services are provided to the general public with exceptions as ISRG management deems appropriate or in accordance with relevant law. ISRG PKI services are most commonly, but not necessarily exclusively, provided under the brand/trademark "Let’s Encrypt". The ISRG PKI conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at https://www.cabforum.org . In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document. Other documents related to the behavior and control of the ISRG PKI, such as a Subscriber Agreement and Privacy Policy, can be found at https://letsencrypt.org/repository/ . Per IETF PKIX RFC 3647, this CP/CPS is divided into nine components that cover security controls, practices, and procedures for certification services provided by the ISRG PKI. The following Certification Authorities are covered under this document: CA Type Distinguished Name Key Pair Type and Parameters Cert SHA-256 Fingerprint Validity Period Root CA C=US, O=Internet Security Research Group, CN=ISRG Root X1 RSA, n has 4096 bits, e=65537 96:BC:EC:06:26:49:76:F3: 74:60:77:9A:CF:28:C5:A7: CF:E8:A3:C0:AA:E1:1A:8F: FC:EE:05:C0:BD:DF:08:C6 Not Before: Jun 4 11:04:38 2015 GMT, Not After: Jun 4 11:04:38 2035 GMT Root CA C=US, O=Internet Security Research Group, CN=ISRG Root X2 ECDSA, NIST curve P-384 69:72:9B:8E:15:A8:6E:FC: 17:7A:57:AF:B7:17:1D:FC: 64:AD:D2:8C:2F:CA:8C:F1: 50:7E:34:45:3C:CB:14:70 Not Before: Sept 4 00:00:00 2020 GMT, Not After: Sept 17 16:00:00 2040 GMT This work is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit https://creativecommons.org/licenses/by/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. 1.2 Document name and identification This is the ISRG CP/CPS. This document was approved for publication by the ISRG Policy Management Authority, and is made available at https://letsencrypt.org/repository/ . The following revisions have been made: Date Changes Version May 5, 2023 CP and CPS documents are combined. See past documents for prior version history. 5.0 May 16, 2023 Make CPS OID and URL in Subscriber Certificates optional. 5.1 Feb 7, 2024 Add CRL Distribution Point to subscriber certificate profile. Add IssuingDistributionPoint to subordinate CRL profile. Remove id-qt-cps from subscriber certificate profile, make it optional for subordinate certificate profile. Clarify waste disposal procedure. 5.2 Mar 22, 2024 Improve accuracy of information regarding subscriber key compromise in sections 4.9.3 and 4.9.12. 5.3 1.3 PKI Participants 1.3.1 Certification Authorities This CP/CPS applies to the ISRG CA. 1.3.2 Registration Authorities ISRG does not delegate any of the Section 3.2 requirements to a Delegated Third Party. ISRG serves as its own RA. 1.3.3 Subscribers See definition of "Subscriber" in Section 1.6.1 Definitions. 1.3.4 Relying Parties See definition of "Relying Party" in Section 1.6.1 Definitions. 1.3.5 Other Participants Other participants include CAs that cross-sign or issue subordinates to the ISRG PKI. ISRG PKI vendors and service providers with access to confidential information or privileged systems are required to operate in compliance with this ISRG CP/CPS. 1.4 Certificate Usage 1.4.1 Appropriate Certificate Uses No stipulation. 1.4.2 Prohibited Certificate Uses Certificates may not be used: For any application requiring fail-safe performance, such as: a) the operation of nuclear power facilities; b) air traffic control systems; c) aircraft navigation systems; d) weapons control systems; or e) any other system in which failure could lead to injury, death, or environmental damage. For software or hardware architectures that provide facilities for interference with encrypted communications, including but not limited to: a) active eavesdropping (e.g., monster-in-the-middle attacks); or b) traffic management of domain names or internet protocol addresses that the organization does not own or control. Note that these restrictions shall apply regardless of whether a relying party communicating through the software or hardware architecture has knowledge of its providing facilities for interference with encrypted communications. Note that Certificates do not guarantee anything regarding reputation, honesty, or the current state of endpoint security. A Certificate only represents that the information contained in it was verified as reasonably correct when the Certificate was issued. 1.5 Policy administration 1.5.1 Organization Administering the Document The ISRG PMA maintains this document. 1.5.2 Contact Person The ISRG PMA can be contacted at: Policy Management Authority Internet Security Research Group P.O. Box 18666 Minneapolis, MN 55418-0666 USA Certificate revocation requests can be made via the ACME API. Please see Section 4.9.3 for more information. Certificate Problem Reports can be submitted via email to: cert-prob-reports@letsencrypt.org Issues can be filed via the GitHub repository where this document is maintained: https://github.com/letsencrypt/cp-cps 1.5.3 Person Determining CP/CPS suitability for the policy The ISRG PMA is responsible for determining the suitability of this CP/CPS. ISRG policy is informed by results and recommendations received from an independent auditor. 1.5.4 CP/CPS approval procedures The ISRG PMA approves any revisions to this CP/CPS after formal review. 1.6 Definitions and Acronyms 1.6.1 Definitions ACME Protocol : A protocol used for validation, issuance, and management of certificates. The protocol is an open standard managed by the IETF. Baseline Requirements : A document published by the CAB Forum which outlines minimum requirements for publicly trusted Certificate Authorities. CAB Forum : Certificate Authority / Browser Forum, a group of CAs and browsers which come together to discuss technical and policy issues related to PKI systems. ( https://cabforum.org/ ) Certificate Repository : A repository of information about ISRG certificates. It is located at: https://letsencrypt.org/certificates/ Policy and Legal Repository : A repository of policy and legal documents related to the ISRG PKI. It is located at: https://letsencrypt.org/repository/ Precertificate : A certificate containing a critical poison extension as defined by RFC 6962 Section 3.1. Secure PKI Facilities : Facilities designed to protect sensitive PKI infrastructure, including CA private keys. Trusted Contributor : A contributor who performs in a Trusted Role. Trusted Contributors may be employees, contractors, or community members. Trusted Contributors must be properly trained and qualified, and have the proper legal obligations in place before performing in a Trusted Role. Trusted Role : A role which qualifies a person to access or modify ISRG PKI systems, infrastructure, and confidential information. See the Baseline Requirements for additional definitions. 1.6.2 Acronyms Acronym Meaning ACME Automated Certificate Management Environment DV Domain Validation HSM Hardware Security Module IP Internet Protocol ISRG Internet Security Research Group PMA Policy Management Authority SAN Subject Alternative Name TLD Top Level Domain See the Baseline Requirements for additional...