From 070bef1ba8c6c1fecabd22b774fcec453cc2658a Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Thu, 12 Jan 2023 12:01:40 -0500 Subject: [PATCH] Integrate SC-56 and SC-58 (#409) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Update README (#294) Co-authored-by: Jos Purvis * Adjust the workflow file to build the actions (#296) This addresses a few requests that recently came up from the certificate profiles work: - Remove the explicit retention period (of 21 days) to allow the GitHub default of 90 days. - Change the generated ZIP file from being "BR.md-hash" to being "BR-hash". - Allow manually invoking the workflow (via workflow_dispatch), in the event folks want to re-run for a particular branch (e.g. profiles) - Attempt to resolve the "non-deterministic redline" noted by Jos. When a given commit is on cabforum/servercert, it may be both a commit (to a branch) and part of a pull request (to main). We want the pull request redline to be against main, while the commit redline to be against the previous commit. Because both jobs run, and both upload the same file name, this results in a non-deterministic clobbering, where the commit-redline may clobber the pr-redline. This changes the generated zip file to be "file-hash-event_type", so that it will generate redlines for both PRs and commits and attach both. * SC47 Sunset subject:organizationalUnitName (#282) (#290) * SC47 Sunset subject:organizationalUnitName (#282) * Deprecation of subject:organizationalUnitName * Update language to avoid confusion on the effective date This version updates SC47 to state "issued on or after September 1, 2022" and makes the EV Guidelines reference the BRs as suggested by Ryan Sleevi from Google. Co-authored-by: Paul van Brouwershaven Co-authored-by: Ryan Sleevi Co-authored-by: Jos Purvis * SC47 datefix (#298) * Update dates table * Update EVG.md Add SC47 reference to relevant dates table * Fixup section number in prior commit Co-authored-by: Jos Purvis Co-authored-by: Wayne Thayer * SC48 - Domain Name and IP Address Encoding (#285) (#302) * SC48 - Domain Name and IP Address Encoding (#285) * First pass * Add more RFC references, some wordsmithing * Another few fixes * Switch to use "LDH Labels" * Propose concrete effective date * Clarification about root zone trailing dot * Replace "label" with "Domain Label" throughout (#1) Replace "label" with "Domain Label" and "domain name" with "Domain Name" throughout Co-authored-by: Corey Bonnell Co-authored-by: Ryan Sleevi * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell Co-authored-by: Ryan Sleevi Co-authored-by: Jos * Wrap xn-- to prevent ligaturization * SC48 - Domain Name and IP Address Encoding (#285) * First pass * Add more RFC references, some wordsmithing * Another few fixes * Switch to use "LDH Labels" * Propose concrete effective date * Clarification about root zone trailing dot * Replace "label" with "Domain Label" throughout (#1) Replace "label" with "Domain Label" and "domain name" with "Domain Name" throughout Co-authored-by: Corey Bonnell Co-authored-by: Ryan Sleevi * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell Co-authored-by: Ryan Sleevi Co-authored-by: Jos * Wrap xn-- to prevent ligaturization * Update dates and version numbers Co-authored-by: Corey Bonnell Co-authored-by: Corey Bonnell Co-authored-by: Ryan Sleevi Co-authored-by: Jos Purvis * Ballot SC50 - Remove the requirements of 4.1.1 (#328) * SC50 - Remove the requirements of 4.1.1 (#323) * Bump cairosvg from 1.0.20 to 2.5.1 Bumps [cairosvg](https://github.com/Kozea/CairoSVG) from 1.0.20 to 2.5.1. - [Release notes](https://github.com/Kozea/CairoSVG/releases) - [Changelog](https://github.com/Kozea/CairoSVG/blob/master/NEWS.rst) - [Commits](https://github.com/Kozea/CairoSVG/compare/1.0.20...2.5.1) Signed-off-by: dependabot[bot] * Bump kramdown from 2.3.0 to 2.3.1 Bumps [kramdown](https://github.com/gettalong/kramdown) from 2.3.0 to 2.3.1. - [Release notes](https://github.com/gettalong/kramdown/releases) - [Changelog](https://github.com/gettalong/kramdown/blob/master/doc/news.page) - [Commits](https://github.com/gettalong/kramdown/commits) Signed-off-by: dependabot[bot] * Remove 4.1.1; persist compromised keys in 6.1.1.3 Remove section 4.1.1 from the BRs Explicitly require persistent access to compromised keys * Rebase based on upstream/main * Move System requirement to 6.1.1.3 * Add 4.1.1 as blank * Remove capitalization from 6.1.1.3 where terms are not defined * Re-add 'No stipulation.' to 4.1.1 * Remove change to 6.1.1.3 Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson * Update version and date table Co-authored-by: Clint Wilson Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson Co-authored-by: Jos Purvis * Ballot SC53: Sunset SHA-1 for OCSP signing (#330) (#338) * Sunset SHA-1 for OCSP signing (#330) * Sunset SHA-1 OCSP signing * Clarify necessity of both items * Standardize date format, fix year in effective date table Co-authored-by: Corey Bonnell * Update version, table, and date Co-authored-by: Corey Bonnell Co-authored-by: Corey Bonnell Co-authored-by: Jos Purvis * Bump actions/checkout from 2 to 3 (#342) Bumps [actions/checkout](https://github.com/actions/checkout) from 2 to 3. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](https://github.com/actions/checkout/compare/v2...v3) --- updated-dependencies: - dependency-name: actions/checkout dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Ballot SC51: Reduce and Clarify Log and Records Archival Retention Requirements (#347) * Ballot SC51: Reduce and Clarify Audit Log and Records Archival Retention Requirements (#336) * Bump cairosvg from 1.0.20 to 2.5.1 Bumps [cairosvg](https://github.com/Kozea/CairoSVG) from 1.0.20 to 2.5.1. - [Release notes](https://github.com/Kozea/CairoSVG/releases) - [Changelog](https://github.com/Kozea/CairoSVG/blob/master/NEWS.rst) - [Commits](https://github.com/Kozea/CairoSVG/compare/1.0.20...2.5.1) Signed-off-by: dependabot[bot] * Bump kramdown from 2.3.0 to 2.3.1 Bumps [kramdown](https://github.com/gettalong/kramdown) from 2.3.0 to 2.3.1. - [Release notes](https://github.com/gettalong/kramdown/releases) - [Changelog](https://github.com/gettalong/kramdown/blob/master/doc/news.page) - [Commits](https://github.com/gettalong/kramdown/commits) Signed-off-by: dependabot[bot] * Restructure parts of 5.4.x and 5.5.x * Use 'events' consistently in 5.4.1 * Forgot to remove "revocation" as condition for start of retention period of Subscriber Certificates. * Introduce possessive in 5.4.1 and 5.5.1 to better deliniate responsiblities of CAs using DTPs * Remove WIP title; * re-order list in 5.5.2; add 'or' clause to validation documentation archival list entry. * Incorporate feedback from Aaron and Dimitris in Servercert-wg Discussion Period Based on the feedback from Aaron here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003115.html) and here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003125.html), update 5.5.1 and 5.5.2. Based on the feedback from Dimitris here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003110.html), update 5.4.3 and 5.5.2. * Update link formatting in 5.4.1 The "Section" links throughout include the word "Section" in the link, except for in 5.4.1; this fixes that inconsistency. Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson * Update effective date and version number * Update ballot table in document * Fix date string Co-authored-by: Clint Wilson Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson Co-authored-by: Jos Purvis * Ballot SC54: Onion Cleanup (#369) * SC-54: Onion cleanup (#348) # Voting Results The voting on ballot SC54 has completed, and the ballot has passed. Voting Results Certificate Issuers votes total, with no abstentions: 18 Yes votes: Amazon, Buypass, DigiCert, eMudhra, Entrust, GDCA, GlobalSign, GoDaddy, HARICA, Izenpe, JPRS, NAVER, OISTE, Sectigo, SwissSign, TrustCor, SecureTrust, Visa 0 No Votes 0 Abstentions Certificate Consumers 6 votes total, with no abstentions: 6 Yes votes: 360, Apple, Cisco, Google, Microsoft, Mozilla 0 No votes 0 Abstentions Bylaw Requirements 1. Bylaw 2.3(f) requires: · A "yes" vote by two-thirds of Certificate Issuer votes and by 50%-plus-one of Certificate Consumer votes. Votes to abstain are not counted for this purpose. This requirement was MET for Certificate Issuers and MET for Certificate Consumers. · At least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was MET. 2. Bylaw 2.3(g) requires that a ballot result only be considered valid when “more than half of the number of currently active Members has participated”. Votes to abstain are counted in determining quorum. Half of the currently active members at the start of voting was 14, so the quorum was 15 for this ballot. This requirement was MET. This ballot now enters the IP Rights Review Period to permit members to review the ballot for relevant IP rights issues. —— # Commit History * Addresses #270 allowing method 3.2.2.4.20 for `.onion` domains. * Addresses #242 creating an exception for `.onion` domains, using existing language from the opening section of 3.2.2.4. * Addresses #241 removing the currently deprecated Domain validation method 3.2.2.4.6. * Addresses #240. Things are signed using private, not public keys. * Addresses #190, #191. According to https://github.com/cabforum/servercert/issues/191#issuecomment-827810409, effectively 2021-10-15 is when v2 stops working everywhere. We could proceed without an effective date, remove most of Appendix F in the EV Guidelines and point to Appendix B of the Baseline Requirements directly. No strong feelings either way. * This is a mitigation against a malicious CA but the Applicant ultimately creates the Nonce. We agreed with Corey and Wayne to propose the removal of the requirement for the CA to *confirm* entropy. * Update language to deprecate legacy Appendix F validation method with "immediate" effect, after the ballot clears IPR (30 days after voting). * remove double space * Remove EVG Appendix F, introduce Onion Domain Name term * A few more minor tweaks * Fix numbering * Update for easier read. * Revert "Update for easier read." This reverts commit 1bac785b2fd6a3fe0957434f9d13b13a47d4d19b. Co-authored-by: Corey Bonnell * SC-54: Onion cleanup (#348) # Voting Results The voting on ballot SC54 has completed, and the ballot has passed. Voting Results Certificate Issuers votes total, with no abstentions: 18 Yes votes: Amazon, Buypass, DigiCert, eMudhra, Entrust, GDCA, GlobalSign, GoDaddy, HARICA, Izenpe, JPRS, NAVER, OISTE, Sectigo, SwissSign, TrustCor, SecureTrust, Visa 0 No Votes 0 Abstentions Certificate Consumers 6 votes total, with no abstentions: 6 Yes votes: 360, Apple, Cisco, Google, Microsoft, Mozilla 0 No votes 0 Abstentions Bylaw Requirements 1. Bylaw 2.3(f) requires: · A "yes" vote by two-thirds of Certificate Issuer votes and by 50%-plus-one of Certificate Consumer votes. Votes to abstain are not counted for this purpose. This requirement was MET for Certificate Issuers and MET for Certificate Consumers. · At least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was MET. 2. Bylaw 2.3(g) requires that a ballot result only be considered valid when “more than half of the number of currently active Members has participated”. Votes to abstain are counted in determining quorum. Half of the currently active members at the start of voting was 14, so the quorum was 15 for this ballot. This requirement was MET. This ballot now enters the IP Rights Review Period to permit members to review the ballot for relevant IP rights issues. —— # Commit History * Addresses #270 allowing method 3.2.2.4.20 for `.onion` domains. * Addresses #242 creating an exception for `.onion` domains, using existing language from the opening section of 3.2.2.4. * Addresses #241 removing the currently deprecated Domain validation method 3.2.2.4.6. * Addresses #240. Things are signed using private, not public keys. * Addresses #190, #191. According to https://github.com/cabforum/servercert/issues/191#issuecomment-827810409, effectively 2021-10-15 is when v2 stops working everywhere. We could proceed without an effective date, remove most of Appendix F in the EV Guidelines and point to Appendix B of the Baseline Requirements directly. No strong feelings either way. * This is a mitigation against a malicious CA but the Applicant ultimately creates the Nonce. We agreed with Corey and Wayne to propose the removal of the requirement for the CA to *confirm* entropy. * Update language to deprecate legacy Appendix F validation method with "immediate" effect, after the ballot clears IPR (30 days after voting). * remove double space * Remove EVG Appendix F, introduce Onion Domain Name term * A few more minor tweaks * Fix numbering * Update for easier read. * Revert "Update for easier read." This reverts commit 1bac785b2fd6a3fe0957434f9d13b13a47d4d19b. Co-authored-by: Corey Bonnell * Update version numbers and dates Co-authored-by: Dimitris Zacharopoulos Co-authored-by: Corey Bonnell Co-authored-by: Jos Purvis * SC-56: 2022 Cleanup (#401) * SC-56: 2022 Cleanup (#385) Ballot has passed; moving to SC56 branch for IPR * #340 * #339 * #333 * #318 * #315 * #312 * #309 * #275 * #344 * #345 * #378 * #380 * #287 * #300 * #259 * #284 * #277 * #311 * #310 * Remove historical effective dates * #196 * #251 * #212 * #386 * Grammatical improvement suggested by Wendy Brown * Remove text for retired methods * Switch to new tables tooling * Fix broken section references * Bump upload-artifact version * Linkify US denied persons/entities list URLs Co-authored-by: Corey Bonnell * Update effective dates and tables Co-authored-by: Corey Bonnell Co-authored-by: Corey Bonnell * SC-58: Require distributionPoint in sharded CRLs (#396) (#403) * SC-58: Require distributionPoint in sharded CRLs (#396) * SC-XX: Require distributionPoint in sharded CRLs The language in RFC 5280 regarding the interaction between the distributionPoint field of the Issuing Distribution Point CRL extension and the existence of sharded CRLs has led to significant debate on interpretation, and appears to contradict X.509. To protect against replacement attacks, make it explicitly clear that the Issuing Distribution Point extension and distributionPoint field are required for sharded or partitioned CRLs. * Remind readers that the IDP must be critical * Change effective date to Jan 15 * Change effective date in Section 1.2 table, too * Update BR.md Co-authored-by: Aaron Gable Co-authored-by: Jos Co-authored-by: Jos Purvis Co-authored-by: Ryan Sleevi Co-authored-by: Paul van Brouwershaven Co-authored-by: Ryan Sleevi Co-authored-by: Wayne Thayer Co-authored-by: Corey Bonnell Co-authored-by: Clint Wilson Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson Co-authored-by: Dimitris Zacharopoulos Co-authored-by: Iñigo Barreira <92998585+barrini@users.noreply.github.com> Co-authored-by: Aaron Gable --- .github/workflows/build-draft-docs.yml | 4 +- docs/BR.md | 183 +++++++++++-------------- docs/EVG.md | 47 +++---- 3 files changed, 99 insertions(+), 135 deletions(-) diff --git a/.github/workflows/build-draft-docs.yml b/.github/workflows/build-draft-docs.yml index 96fb4425..f156aa54 100644 --- a/.github/workflows/build-draft-docs.yml +++ b/.github/workflows/build-draft-docs.yml @@ -19,7 +19,7 @@ jobs: with: ref: ${{ github.event.pull_request.base.sha || github.event.push.before }} path: old/ - - uses: docker://ghcr.io/sleevi/build-guidelines-action:tables + - uses: docker://ghcr.io/cabforum/build-guidelines-action:2.1.0 id: build_doc with: markdown_file: docs/${{ matrix.document }}.md @@ -28,7 +28,7 @@ jobs: docx: true lint: true draft: ${{ !(github.event_name == 'push' && github.repository == 'cabforum/servercert' && github.ref == 'refs/heads/main') }} - - uses: actions/upload-artifact@v2 + - uses: actions/upload-artifact@v3 with: name: ${{ matrix.document }}-${{ github.event.pull_request.head.sha || github.sha }}-${{ github.event_name }} path: | diff --git a/docs/BR.md b/docs/BR.md index aa2930f9..928e07a8 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1,9 +1,10 @@ --- title: Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates -subtitle: Version 1.8.4 +subtitle: Version 1.8.6 author: - CA/Browser Forum -date: 23 April, 2022 +date: 14 December, 2022 + copyright: | Copyright 2022 CA/Browser Forum @@ -32,7 +33,7 @@ These Requirements are applicable to all Certification Authorities within a chai This certificate policy (CP) contains the requirements for the issuance and management of publicly-trusted SSL certificates, as adopted by the CA/Browser Forum. -The following Certificate Policy identifiers are reserved for use by CAs as an optional means of asserting compliance with this document (OID arc 2.23.140.1.2) as follows: +The following Certificate Policy identifiers are reserved for use by CAs to assert compliance with this document (OID arc 2.23.140.1.2) as follows: `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) domain-validated(1)} (2.23.140.1.2.1);` and @@ -127,6 +128,9 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o | 1.8.2 | SC53 | Sunset for SHA-1 OCSP Signing | 26-Jan-2022 | 4-Mar-2022 | | 1.8.3 | SC51 | Reduce and Clarify Log and Records Archival Retention Requirements | 01-Mar-2022 | 15-Apr-2022 | | 1.8.4 | SC54 | Onion Cleanup | 24-Mar-2022 | 23-Apr-2022 | +| 1.8.5 | SC56 | 2022 Cleanup | 25-Oct-2022 | 30-Nov-2022 | +| 1.8.6 | SC58 | Require distributionPoint in sharded CRLs | 7-Nov-2022 | 11-Dec-2022 | + \* Effective Date and Additionally Relevant Compliance Date(s) @@ -166,7 +170,7 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o | 2020-09-01 | 6.3.2 | Certificates issued SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. | | 2020-09-30 | 4.9.10 | OCSP responses MUST conform to the validity period requirements specified. | | 2020-09-30 | 7.1.4.1 | Subject and Issuer Names for all possible certification paths MUST be byte-for-byte identical. | -| 2020-09-30 | 7.1.6.4 | Subscriber Certificates MUST include a CA/Browser Form Reserved Policy Identifier in the Certificate Policies extension. | +| 2020-09-30 | 7.1.6.4 | Subscriber Certificates MUST include a CA/Browser Forum Reserved Policy Identifier in the Certificate Policies extension. | | 2020-09-30 | 7.2 and 7.3 | All OCSP and CRL responses for Subordinate CA Certificates MUST include a meaningful reason code. | | 2021-07-01 | 3.2.2.8 | CAA checking is no longer optional if the CA is the DNS Operator or an Affiliate. | | 2021-07-01 | 3.2.2.4.18 and 3.2.2.4.19 | Redirects MUST be the result of one of the HTTP status code responses defined. | @@ -174,6 +178,7 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o | 2021-12-01 | 3.2.2.4 | CAs MUST NOT use methods 3.2.2.4.6, 3.2.2.4.18, or 3.2.2.4.19 to issue wildcard certificates or with Authorization Domain Names other than the FQDN. | | 2022-06-01 | 7.1.3.2.1 | CAs MUST NOT sign OCSP responses using the SHA-1 hash algorithm. | | 2022-09-01 | 7.1.4.2.2 | CAs MUST NOT include the organizationalUnitName field in the Subject | +| 2023-01-15 | 7.2.2 | Sharded or partitioned CRLs MUST have a distributionPoint | ## 1.3 PKI Participants @@ -256,7 +261,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Affiliate**: A corporation, partnership, joint venture or other entity controlling, controlled by, or under common control with another entity, or an agency, department, political subdivision, or any entity operating under the direct control of a Government Entity. -**Applicant**: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate issues, the Applicant is referred to as the Subscriber. For Certificates issued to devices, the Applicant is the entity that controls or operates the device named in the Certificate, even if the device is sending the actual certificate request. +**Applicant**: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate is issued, the Applicant is referred to as the Subscriber. For Certificates issued to devices, the Applicant is the entity that controls or operates the device named in the Certificate, even if the device is sending the actual certificate request. **Applicant Representative**: A natural person or human sponsor who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant: @@ -292,21 +297,21 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Certificate Problem Report**: Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates. +**Certificate Profile**: A set of documents or files that defines requirements for Certificate content and Certificate extensions in accordance with [Section 7](#7-certificate-crl-and-ocsp-profiles), e.g. a Section in a CA’s CPS or a certificate template file used by CA software. + **Certificate Revocation List**: A regularly updated time-stamped list of revoked Certificates that is created and digitally signed by the CA that issued the Certificates. -**Certification Authority**: An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Roots CAs and Subordinate CAs. +**Certification Authority**: An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Root CAs and Subordinate CAs. **Certification Practice Statement**: One of several documents forming the governance framework in which Certificates are created, issued, managed, and used. -**Certificate Profile**: A set of documents or files that defines requirements for Certificate content and Certificate extensions in accordance with [Section 7](#7-certificate-crl-and-ocsp-profiles). e.g. a Section in a CA’s CPS or a certificate template file used by CA software. - **Control**: "Control" (and its correlative meanings, "controlled by" and "under common control with") means possession, directly or indirectly, of the power to: (1) direct the management, personnel, finances, or plans of such entity; (2) control the election of a majority of the directors ; or (3) vote that portion of voting shares required for "control" under the law of the entity's Jurisdiction of Incorporation or Registration but in no case less than 10%. **Country**: Either a member of the United Nations OR a geographic region recognized as a Sovereign State by at least two UN member nations. **Cross-Certified Subordinate CA Certificate**: A certificate that is used to establish a trust relationship between two Root CAs. -**CSPRNG**: A random number generator intended for use in cryptographic system. +**CSPRNG**: A random number generator intended for use in a cryptographic system. **Delegated Third Party**: A natural person or Legal Entity that is not the CA but is authorized by the CA, and whose activities are not within the scope of the appropriate CA audits, to assist in the Certificate Management Process by performing or fulfilling one or more of the CA requirements found herein. @@ -318,8 +323,6 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **DNS TXT Record Phone Contact**: The phone number defined in [Appendix A.2.2](#a22-dns-txt-record-phone-contact). -**Domain Authorization Document**: Documentation provided by, or a CA's documentation of a communication with, a Domain Name Registrar, the Domain Name Registrant, or the person or entity listed in WHOIS as the Domain Name Registrant (including any private, anonymous, or proxy registration service) attesting to the authority of an Applicant to request a Certificate for a specific Domain Namespace. - **Domain Contact**: The Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record, or as obtained through direct contact with the Domain Name Registrar. **Domain Label**: From RFC 8499 (): "An ordered list of zero or more octets that makes up a portion of a domain name. Using graph theory, a label identifies one node in a portion of the graph of all possible domain names." @@ -366,7 +369,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Legal Entity**: An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a country's legal system. -**Non-Reserved LDH Label**: From RFC 5890 (): "The set of valid LDH labels that do not have '--' in the third and fourth positions." +**Non-Reserved LDH Label**: From RFC 5890 (): "The set of valid LDH labels that do not have '`--`' in the third and fourth positions." **Object Identifier**: A unique alphanumeric or numeric identifier registered under the International Organization for Standardization's applicable standard for a specific object or object class. @@ -475,9 +478,9 @@ The script outputs: **Valid Certificate**: A Certificate that passes the validation procedure specified in RFC 5280. -**Validation Specialists**: Someone who performs the information verification duties specified by these Requirements. +**Validation Specialist**: Someone who performs the information verification duties specified by these Requirements. -**Validity Period**: Prior to 2020-09-01, the period of time measured from the date when the Certificate is issued until the Expiry Date. For Certificates issued on or after 2020-09-01, the validity period is as defined within RFC 5280, Section 4.1.2.5: the period of time from notBefore through notAfter, inclusive. +**Validity Period**: From RFC 5280 (): "The period of time from notBefore through notAfter, inclusive." **WHOIS**: Information retrieved directly from the Domain Name Registrar or registry operator via the protocol defined in RFC 3912, the Registry Data Access Protocol defined in RFC 7482, or an HTTPS website. @@ -528,53 +531,51 @@ ETSI TS 102 042, Electronic Signatures and Infrastructures (ESI); Policy require FIPS 140-2, Federal Information Processing Standards Publication - Security Requirements For Cryptographic Modules, Information Technology Laboratory, National Institute of Standards and Technology, May 25, 2001. +FIPS 140-3, Federal Information Processing Standards Publication - Security Requirements For Cryptographic Modules, Information Technology Laboratory, National Institute of Standards and Technology, March 22, 2019. + FIPS 186-4, Federal Information Processing Standards Publication - Digital Signature Standard (DSS), Information Technology Laboratory, National Institute of Standards and Technology, July 2013. ISO 21188:2006, Public key infrastructure for financial services -- Practices and policy framework. -Network and Certificate System Security Requirements, v.1.0, 1/1/2013. +Network and Certificate System Security Requirements, Version 1.7, available at . NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications, . -RFC2119, Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement Levels, Bradner, March 1997. - -RFC2527, Request for Comments: 2527, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework, Chokhani, et al, March 1999. +RFC2119, Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. RFC3492, Request for Comments: 3492, Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). A. Costello. March 2003. -RFC3647, Request for Comments: 3647, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework, Chokhani, et al, November 2003. +RFC3647, Request for Comments: 3647, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework. S. Chokhani, et al. November 2003. -RFC3912, Request for Comments: 3912, WHOIS Protocol Specification, Daigle, September 2004. +RFC3912, Request for Comments: 3912, WHOIS Protocol Specification. L. Daigle. September 2004. RFC3986, Request for Comments: 3986, Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee, et al. January 2005. -RFC4366, Request for Comments: 4366, Transport Layer Security (TLS) Extensions, Blake-Wilson, et al, April 2006. - -RFC5019, Request for Comments: 5019, The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments, A. Deacon, et al, September 2007. +RFC5019, Request for Comments: 5019, The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments. A. Deacon, et al. September 2007. -RFC5280, Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile, Cooper et al, May 2008. +RFC5280, Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile. D. Cooper, et al. May 2008. RFC5890, Request for Comments: 5890, Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. J. Klensin. August 2010. RFC5952, Request for Comments: 5952, A Recommendation for IPv6 Address Text Representation. S. Kawamura, et al. August 2010. -RFC8659, Request for Comments: 8659, DNS Certification Authority Authorization (CAA) Resource Record, Hallam-Baker, Stradling, Hoffman-Andrews, November 2019. +RFC6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. S. Santesson, et al. June 2013. -RFC6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. Santesson, Myers, Ankney, Malpani, Galperin, Adams, June 2013. +RFC6962, Request for Comments: 6962, Certificate Transparency. B. Laurie, et al. June 2013. -RFC6962, Request for Comments: 6962, Certificate Transparency. B. Laurie, A. Langley, E. Kasper. June 2013. +RFC7231, Request For Comments: 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, et al. June 2014. -RFC7231, Request For Comments: 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, R. Fielding, J. Reschke. June 2014. +RFC7482, Request for Comments: 7482, Registration Data Access Protocol (RDAP) Query Format. A. Newton, et al. March 2015. -RFC7538, Request For Comments: 7538, The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect), J. Reschke. April 2015. - -RFC7482, Request for Comments: 7482, Registration Data Access Protocol (RDAP) Query Format, Newton, et al, March 2015. +RFC7538, Request For Comments: 7538, The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). J. Reschke. April 2015. RFC8499, Request for Comments: 8499, DNS Terminology. P. Hoffman, et al. January 2019. -WebTrust for Certification Authorities, SSL Baseline with Network Security, Version 2.3, available at . +RFC8659, Request for Comments: 8659, DNS Certification Authority Authorization (CAA) Resource Record. P. Hallam-Baker, et al. November 2019. + +WebTrust for Certification Authorities, SSL Baseline with Network Security, Version 2.5, available at . -X.509, Recommendation ITU-T X.509 (10/2012) \| ISO/IEC 9594-8:2014 (E), Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks. +X.509, Recommendation ITU-T X.509 (08/2005) \| ISO/IEC 9594-8:2005, Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks. ### 1.6.4 Conventions @@ -659,7 +660,7 @@ If the Subject Identity Information is to include a DBA or tradename, the CA SHA 1. Documentation provided by, or communication with, a government agency in the jurisdiction of the Applicant's legal creation, existence, or recognition; 2. A Reliable Data Source; -3. Communication with a government agency responsible for the management of such DBAs or tradenames; +3. Communication with a government agency responsible for the management of such DBAs or trade names; 4. An Attestation Letter accompanied by documentary support; or 5. A utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable. @@ -713,13 +714,7 @@ The Random Value SHALL remain valid for use in a confirming response for no more ##### 3.2.2.4.3 Phone Contact with Domain Contact -Confirming the Applicant's control over the FQDN by calling the Domain Name Registrant's phone number and obtaining a response confirming the Applicant's request for validation of the FQDN. The CA MUST place the call to a phone number identified by the Domain Name Registrar as the Domain Contact. - -Each phone call SHALL be made to a single number and MAY confirm control of multiple FQDNs, provided that the phone number is identified by the Domain Registrar as a valid contact method for every Base Domain Name being verified using the phone call. - -CAs SHALL NOT perform validations using this method after May 31, 2019. Completed validations using this method SHALL continue to be valid for subsequent issuance per the applicable certificate data reuse periods. - -**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates. ##### 3.2.2.4.4 Constructed Email to Domain Contact @@ -745,19 +740,7 @@ This method has been retired and MUST NOT be used. Prior validations using this ##### 3.2.2.4.6 Agreed-Upon Change to Website -Confirming the Applicant's control over the FQDN by confirming one of the following under the "/.well-known/pki-validation" directory, or another path registered with IANA for the purpose of Domain Validation, on the Authorization Domain Name that is accessible by the CA via HTTP/HTTPS over an Authorized Port: - -1. The presence of Required Website Content contained in the content of a file. The entire Required Website Content MUST NOT appear in the request used to retrieve the file or web page, or -2. The presence of the Request Token or Random Value contained in the content of a file where the Request Token or Random Value MUST NOT appear in the request. - -If a Random Value is used, the CA SHALL provide a Random Value unique to the Certificate request and SHALL not use the Random Value after the longer of - - i. 30 days or - ii. if the Applicant submitted the Certificate request, the timeframe permitted for reuse of validated information relevant to the certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of these Guidelines or Section 11.14.3 of the EV Guidelines). - -CAs SHALL NOT perform validations using this method after June 3, 2020. CAs MAY continue to re-use information and validations for domains validated under this method per the applicable certificate data reuse periods. - -**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates. ##### 3.2.2.4.7 DNS Change @@ -766,7 +749,7 @@ Confirming the Applicant's control over the FQDN by confirming the presence of a If a Random Value is used, the CA SHALL provide a Random Value unique to the Certificate request and SHALL not use the Random Value after i. 30 days or - ii. if the Applicant submitted the Certificate request, the timeframe permitted for reuse of validated information relevant to the Certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of these Guidelines or Section 11.14.3 of the EV Guidelines). + ii. if the Applicant submitted the Certificate request, the time frame permitted for reuse of validated information relevant to the Certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of these Guidelines or Section 11.14.3 of the EV Guidelines). **Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. @@ -830,7 +813,7 @@ The Random Value SHALL remain valid for use in a confirming response for no more Confirm the Applicant's control over the FQDN by calling the DNS TXT Record Phone Contact’s phone number and obtain a confirming response to validate the ADN. Each phone call MAY confirm control of multiple ADNs provided that the same DNS TXT Record Phone Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN. -The CA MAY NOT knowingly be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation. +The CA MUST NOT knowingly be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation. In the event of reaching voicemail, the CA may leave the Random Value and the ADN(s) being validated. The Random Value MUST be returned to the CA to approve the request. @@ -878,8 +861,7 @@ If a Random Value is used, then: 2. The Random Value MUST remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS. **Note**: - * For Certificates issued prior to 2021-12-01, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. - * For Certificates issued on or after 2021-12-01, the CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names. + * The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names. ##### 3.2.2.4.19 Agreed-Upon Change to Website - ACME @@ -898,8 +880,7 @@ If the CA follows redirects, the following apply: 3. Redirects MUST be to resource URLs accessed via Authorized Ports. **Note**: - * For Certificates issued prior to 2021-12-01, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. - * For Certificates issued on or after 2021-12-01, the CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names. + * The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names. ##### 3.2.2.4.20 TLS Using ALPN @@ -926,7 +907,7 @@ Confirming the Applicant's control over the requested IP Address by confirming t If a Random Value is used, the CA SHALL provide a Random Value unique to the certificate request and SHALL not use the Random Value after the longer of i. 30 days or - ii. if the Applicant submitted the certificate request, the timeframe permitted for reuse of validated information relevant to the certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of this document). + ii. if the Applicant submitted the certificate request, the time frame permitted for reuse of validated information relevant to the certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of this document). ##### 3.2.2.5.2 Email, Fax, SMS, or Postal Mail to IP Address Contact @@ -1076,7 +1057,7 @@ The certificate request MAY include all factual information about the Applicant Applicant information MUST include, but not be limited to, at least one Fully-Qualified Domain Name or IP address to be included in the Certificate's `subjectAltName` extension. -[Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) limits the validity period of Subscriber Certificates. The CA MAY use the documents and data provided in [Section 3.2](#32-initial-identity-validation) to verify certificate information, or may reuse previous validations themselves, provided that the CA obtained the data or document from a source specified under [Section 3.2](#32-initial-identity-validation) or completed the validation itself no more than 825 days prior to issuing the Certificate. Effective 2021-10-01, for validation of Domain Names and IP Addresses according to Section 3.2.2.4 and 3.2.2.5, any reused data, document, or completed validation MUST be obtained no more than 398 days prior to issuing the Certificate. +[Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) limits the validity period of Subscriber Certificates. The CA MAY use the documents and data provided in [Section 3.2](#32-initial-identity-validation) to verify certificate information, or may reuse previous validations themselves, provided that the CA obtained the data or document from a source specified under [Section 3.2](#32-initial-identity-validation) or completed the validation itself no more than 825 days prior to issuing the Certificate. For validation of Domain Names and IP Addresses according to Section 3.2.2.4 and 3.2.2.5, any reused data, document, or completed validation MUST be obtained no more than 398 days prior to issuing the Certificate. In no case may a prior validation be reused if any data or document used in the prior validation was obtained more than the maximum time permitted for reuse of the data or document prior to issuing the Certificate. @@ -1234,17 +1215,17 @@ The CA SHALL revoke a Certificate within 24 hours if one or more of the followin The CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days if one or more of the following occurs: -1. The Certificate no longer complies with the requirements of [Section 6.1.5](#615-key-sizes) and [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking); -2. The CA obtains evidence that the Certificate was misused; -3. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use; -4. The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrant's right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name); -5. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name; -6. The CA is made aware of a material change in the information contained in the Certificate; -7. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA's Certificate Policy or Certification Practice Statement; -8. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate; -9. The CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository; -10. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement; or -11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed. +6. The Certificate no longer complies with the requirements of [Section 6.1.5](#615-key-sizes) and [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking); +7. The CA obtains evidence that the Certificate was misused; +8. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use; +9. The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrant's right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name); +10. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name; +11. The CA is made aware of a material change in the information contained in the Certificate; +12. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA's Certificate Policy or Certification Practice Statement; +13. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate; +14. The CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository; +15. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement; or +16. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed. #### 4.9.1.2 Reasons for Revoking a Subordinate CA Certificate @@ -1329,11 +1310,6 @@ The validity interval of an OCSP response is the difference in time between the For the status of Subscriber Certificates: -Prior to 2020-09-30: -The CA SHALL update information provided via an Online Certificate Status Protocol at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days. - -Effective 2020-09-30: - 1. OCSP responses MUST have a validity interval greater than or equal to eight hours; 2. OCSP responses MUST have a validity interval less than or equal to ten days; 3. For OCSP responses with validity intervals less than sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol prior to one-half of the validity period before the nextUpdate. @@ -1580,9 +1556,9 @@ Additionally, the CA's security program MUST include an annual Risk Assessment t ### 5.5.1 Types of records archived -The CA and each Delegated Party SHALL archive all audit logs (as set forth in [Section 5.4.1](#541-types-of-events-recorded)). +The CA and each Delegated Third Party SHALL archive all audit logs (as set forth in [Section 5.4.1](#541-types-of-events-recorded)). -Additionally, the CA and each Delegated Party SHALL archive: +Additionally, the CA and each Delegated Third Party SHALL archive: 1. Documentation related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems; and 2. Documentation related to their verification, issuance, and revocation of certificate requests and Certificates. @@ -1590,7 +1566,7 @@ Additionally, the CA and each Delegated Party SHALL archive: Archived audit logs (as set forth in [Section 5.5.1](#551-types-of-records-archived) SHALL be retained for a period of at least two (2) years from their record creation timestamp, or as long as they are required to be retained per [Section 5.4.3](#543-retention-period-for-audit-log), whichever is longer. -Additionally, the CA and each delegated party SHALL retain, for at least two (2) years: +Additionally, the CA and each Delegated Third Party SHALL retain, for at least two (2) years: 1. All archived documentation related to the security of Certificate Systems, Certificate Management Systems, Root CA Systems and Delegated Third Party Systems (as set forth in [Section 5.5.1](#551-types-of-records-archived)); and 2. All archived documentation relating to the verification, issuance, and revocation of certificate requests and Certificates (as set forth in [Section 5.5.1](#551-types-of-records-archived)) after the later occurrence of: 1. such records and documentation were last relied upon in the verification, issuance, or revocation of certificate requests and Certificates; or @@ -1752,7 +1728,7 @@ If the Issuing CA generated the Private Key on behalf of the Subordinate CA, the ### 6.2.7 Private key storage on cryptographic module -The CA SHALL protect its Private Key in a system or device that has been validated as meeting at least FIPS 140 level 3 or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the Private Key and other assets against known threats. +The CA SHALL protect its Private Key in a system or device that has been validated as meeting at least FIPS 140-2 level 3, FIPS 140-3 level 3, or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the Private Key and other assets against known threats. ### 6.2.8 Activating Private Keys @@ -1760,7 +1736,7 @@ The CA SHALL protect its Private Key in a system or device that has been validat ### 6.2.10 Destroying Private Keys -### 6.2.11 Cryptographic Module Capabilities +### 6.2.11 Cryptographic Module Rating ## 6.3 Other aspects of key pair management @@ -3031,7 +3007,7 @@ In addition, the CA MAY use the following signature algorithm and encoding if al * The only differences between the new Certificate and existing Certificate are one of the following: * A new `subjectPublicKey` within the `subjectPublicKeyInfo`, using the same algorithm and key size; and/or, * A new `serialNumber`, of the same encoded length as the existing Certificate; and/or - * The new Certificate's `extKeyUsage` extension is present, has at least one key purpose specified, and none of the key purposes specified are the id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) or the anyExtendedKeyUsage (OID: 2.5.2937.0) key purposes; and/or + * The new Certificate's `extKeyUsage` extension is present, has at least one key purpose specified, and none of the key purposes specified are the id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) or the anyExtendedKeyUsage (OID: 2.5.29.37.0) key purposes; and/or * The new Certificate's `basicConstraints` extension has a pathLenConstraint that is zero. * If used within an OCSP response, such as the `signatureAlgorithm` of a BasicOCSPResponse: * The `producedAt` field value of the ResponseData MUST be earlier than 2022-06-01 00:00:00 UTC; and, @@ -3164,8 +3140,6 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o 1. `reasonCode` (OID 2.5.29.21) - Effective 2020-09-30, all of the following requirements MUST be met: - If present, this extension MUST NOT be marked critical. If a CRL entry is for a Root CA or Subordinate CA Certificate, including Cross-Certified Subordinate CA Certificates, this CRL entry extension MUST be present. @@ -3176,12 +3150,16 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o If a CRL entry is for a Certificate subject to these Requirements, the `CRLReason` MUST NOT be certificateHold (6). If a `reasonCode` CRL entry extension is present, the `CRLReason` MUST indicate the most appropriate reason for revocation of the certificate, as defined by the CA within its CP/CPS. + +2. `issuingDistributionPoint` (OID 2.5.29.28) + + Effective 2023-01-15, if a CRL does not contain entries for all revoked unexpired certificates issued by the CRL issuer, then it MUST contain a critical Issuing Distribution Point extension and MUST populate the `distributionPoint` field of that extension. ## 7.3 OCSP profile -Effective 2020-09-30, if an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross-Certified Subordinate CA Certificates, and that certificate has been revoked, then the `revocationReason` field within the `RevokedInfo` of the `CertStatus` MUST be present. +If an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross-Certified Subordinate CA Certificates, and that certificate has been revoked, then the `revocationReason` field within the `RevokedInfo` of the `CertStatus` MUST be present. -Effective 2020-09-30, the `CRLReason` indicated MUST contain a value permitted for CRLs, as specified in [Section 7.2.2](#722-crl-and-crl-entry-extensions). +The `CRLReason` indicated MUST contain a value permitted for CRLs, as specified in [Section 7.2.2](#722-crl-and-crl-entry-extensions). ### 7.3.1 Version number(s) @@ -3193,10 +3171,9 @@ The `singleExtensions` of an OCSP response MUST NOT contain the `reasonCode` (OI The CA SHALL at all times: -1. Issue Certificates and operate its PKI in accordance with all law applicable to its business and the Certificates it issues in every jurisdiction in which it operates; -2. Comply with these Requirements; -3. Comply with the audit requirements set forth in this section; and -4. Be licensed as a CA in each jurisdiction where it operates, if licensing is required by the law of such jurisdiction for the issuance of Certificates. +1. Comply with these Requirements; +2. Comply with the audit requirements set forth in this section; and +3. Be licensed as a CA in each jurisdiction where it operates, if licensing is required by the law of such jurisdiction for the issuance of Certificates. **Implementers' Note**: Version 1.1.6 of the SSL Baseline Requirements was published on July 29, 2013. Version 2.0 of WebTrust's Principles and Criteria for Certification Authorities - SSL Baseline with Network Security and ETSI's Electronic Signatures and Infrastructures (ESI) 102 042 incorporate version 1.1.6 of these Baseline Requirements and version 1.0 of the Network and Certificate System Security Requirements. The CA/Browser Forum continues to improve the Baseline Requirements while WebTrust and ETSI also continue to update their audit criteria. We encourage all CAs to conform to each revision herein on the date specified without awaiting a corresponding update to an applicable audit criterion. In the event of a conflict between an existing audit criterion and a guideline revision, we will communicate with the audit community and attempt to resolve any uncertainty, and we will respond to implementation questions directed to . Our coordination with compliance auditors will continue as we develop guideline revision cycles that harmonize with the revision cycles for audit criteria, the compliance auditing periods and cycles of CAs, and the CA/Browser Forum's guideline implementation dates. @@ -3250,8 +3227,6 @@ The Audit Report SHALL state explicitly that it covers the relevant systems and The CA MUST make its Audit Report publicly available no later than three months after the end of the audit period. In the event of a delay greater than three months, the CA SHALL provide an explanatory letter signed by the Qualified Auditor. -For Audit Reports in which the Audit Period includes a date later than 2020-08-01, then the requirements set forth in the remainder of this [Section 8.6](#86-communication-of-results) SHALL be met. Audit Reports for Audit Periods that conclude prior to 2020-08-01 SHOULD meet these requirements. - The Audit Report MUST contain at least the following clearly-labelled information: 1. name of the organization being audited; @@ -3348,20 +3323,16 @@ The Certificate Warranties specifically include, but are not limited to, the fol ii. followed the procedure when issuing the Certificate; and iii. accurately described the procedure in the CA's Certificate Policy and/or Certification Practice Statement; 3. **Accuracy of Information**: That, at the time of issuance, the CA - i. implemented a procedure for verifying the accuracy of all of the information contained in the Certificate (with the exception of the subject:organizationalUnitName attribute); + i. implemented a procedure for verifying the accuracy of all of the information contained in the Certificate; ii. followed the procedure when issuing the Certificate; and iii. accurately described the procedure in the CA's Certificate Policy and/or Certification Practice Statement; -4. **No Misleading Information**: That, at the time of issuance, the CA - i. implemented a procedure for reducing the likelihood that the information contained in the Certificate's subject:organizationalUnitName attribute would be misleading; +4. **Identity of Applicant**: That, if the Certificate contains Subject Identity Information, the CA + i. implemented a procedure to verify the identity of the Applicant in accordance with [Section 3.2](#32-initial-identity-validation) and [Section 7.1.2](#712-certificate-content-and-extensions); ii. followed the procedure when issuing the Certificate; and iii. accurately described the procedure in the CA's Certificate Policy and/or Certification Practice Statement; -5. **Identity of Applicant**: That, if the Certificate contains Subject Identity Information, the CA - i. implemented a procedure to verify the identity of the Applicant in accordance with [Section 3.2](#32-initial-identity-validation) and [Section 7.1.2](#712-certificate-content-and-extensions); - ii. followed the procedure when issuing the Certificate; and - iii. accurately described the procedure in the CA's Certificate Policy and/or Certification Practice Statement; -6. **Subscriber Agreement**: That, if the CA and Subscriber are not Affiliated, the Subscriber and CA are parties to a legally valid and enforceable Subscriber Agreement that satisfies these Requirements, or, if the CA and Subscriber are the same entity or are Affiliated, the Applicant Representative acknowledged the Terms of Use; -7. **Status**: That the CA maintains a 24 x 7 publicly-accessible Repository with current information regarding the status (valid or revoked) of all unexpired Certificates; and -8. **Revocation**: That the CA will revoke the Certificate for any of the reasons specified in these Requirements. +5. **Subscriber Agreement**: That, if the CA and Subscriber are not Affiliated, the Subscriber and CA are parties to a legally valid and enforceable Subscriber Agreement that satisfies these Requirements, or, if the CA and Subscriber are the same entity or are Affiliated, the Applicant Representative acknowledged the Terms of Use; +6. **Status**: That the CA maintains a 24 x 7 publicly-accessible Repository with current information regarding the status (valid or revoked) of all unexpired Certificates; and +7. **Revocation**: That the CA will revoke the Certificate for any of the reasons specified in these Requirements. The Root CA SHALL be responsible for the performance and warranties of the Subordinate CA, for the Subordinate CA's compliance with these Requirements, and for all liabilities and indemnification obligations of the Subordinate CA under these Requirements, as if the Root CA were the Subordinate CA issuing the Certificates @@ -3434,6 +3405,8 @@ Notwithstanding any limitations on its liability to Subscribers and Relying Part ## 9.15 Compliance with applicable law +The CA SHALL issue Certificates and operate its PKI in accordance with all law applicable to its business and the Certificates it issues in every jurisdiction in which it operates. + ## 9.16 Miscellaneous provisions ### 9.16.1 Entire agreement @@ -3511,7 +3484,7 @@ This appendix defines permissible verification procedures for including one or m a. The CA MAY verify the Applicant's control over the .onion service by using one of the following methods from [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control): i. [Section 3.2.2.4.18 - Agreed-Upon Change to Website v2](#322418-agreed-upon-change-to-website-v2) - ii. [Section 3.2.2.4.19 - Agreed-Upon Change to Website - ACME](#322419-agreed-upon-change-to-website-acme) + ii. [Section 3.2.2.4.19 - Agreed-Upon Change to Website - ACME](#322419-agreed-upon-change-to-website---acme) iii. [Section 3.2.2.4.20 - TLS Using ALPN](#322420-tls-using-alpn) When these methods are used to verify the Applicant's control over the .onion service, the CA MUST use Tor protocol to establish a connection to the .onion hidden service. The CA MUST NOT delegate or rely on a third-party to establish the connection, such as by using Tor2Web. diff --git a/docs/EVG.md b/docs/EVG.md index 016961d1..4f1d5df9 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -1,9 +1,9 @@ --- title: Guidelines for the Issuance and Management of Extended Validation Certificates -subtitle: Version 1.7.9 +subtitle: Version 1.8.0 author: - CA/Browser Forum -date: 23 April, 2022 +date: 30 November, 2022 copyright: | Copyright 2022 CA/Browser Forum @@ -12,8 +12,6 @@ copyright: | # Introduction -This version 1.7.8 represents the Extended Validation Guidelines, as adopted by the CA/Browser Forum as of Ballot SC48, passed by the Server Certificate Working Group on 22 July 2021, and effective as of 25 August 2021. - The Guidelines describe an integrated set of technologies, protocols, identity proofing, lifecycle management, and auditing practices specifying the minimum requirements that must be met in order to issue and maintain Extended Validation Certificates ("EV Certificates") concerning an organization. Subject Organization information from valid EV Certificates can then be used in a special manner by certain relying-party software applications (e.g., browser software) in order to provide users with a trustworthy confirmation of the identity of the entity that controls the Web site or other services they are accessing. Although initially intended for use in establishing Web-based data communication conduits via TLS/SSL protocols, extensions are envisioned for S/MIME, time-stamping, VoIP, IM, Web services, etc. The primary purposes of Extended Validation Certificates are to: 1) identify the legal entity that controls a Web or service site, and 2) enable encrypted communications with that site. The secondary purposes include significantly enhancing cybersecurity by helping establish the legitimacy of an organization claiming to operate a Web site, and providing a vehicle that can be used to assist in addressing problems related to distributing malware, phishing, identity theft, and diverse forms of online fraud. @@ -71,6 +69,7 @@ The CA/Browser Forum is a voluntary open organization of certification authoriti | 1.7.7 | SC47 | Sunset subject:organizationalUnitName | 30-Jun-2021 | 16-Aug-2021 | | 1.7.8 | SC48 | Domain Name and IP Address Encoding | 22-Jul-2021 | 25-Aug-2021 | | 1.7.9 | SC54 | Onion Cleanup | 24-Mar-2022 | 23-Apr-2022 | +| 1.8.0 | SC56 | 2022 Cleanup | 25-Oct-2022 | 30-Nov-2022 | \* Effective Date and Additionally Relevant Compliance Date(s) @@ -79,7 +78,7 @@ The CA/Browser Forum is a voluntary open organization of certification authoriti | **Compliance** | **Section(s)** | **Summary Description (See Full Text for Details)** | |--|--|----------| | 2020-01-31 | [9.2.8](#928-subject-organization-identifier-field) | If subject:organizationIdentifier is present, the CA/Browser Forum Organization Identifier Extension MUST be present | -| 2020-09-01 | [9.4](#94-maximum-validity-period-for-ev-certificate) & [Appendix F](#appendix-f--issuance-of-certificates-for-onion-domain-names) | Certificates issued MUST NOT have a Validity Period greater than 398 days. | +| 2020-09-01 | [9.4](#94-maximum-validity-period-for-ev-certificate) & Appendix F | Certificates issued MUST NOT have a Validity Period greater than 398 days. | | 2020-10-01 | [11.1.3](#1113-disclosure-of-verification-sources) | Prior to using an Incorporating Agency or Registration Agency, the CA MUST ensure the agency has been publicly disclosed | | 2022-09-01 | [9.2.7](#927-subject-organizational-unit-name-field) | CAs MUST NOT include the organizationalUnitName field in the Subject | @@ -153,10 +152,6 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Demand Deposit Account**: A deposit account held at a bank or other financial institution, the funds deposited in which are payable on demand. The primary purpose of demand accounts is to facilitate cashless payments by means of check, bank draft, direct debit, electronic funds transfer, etc. Usage varies among countries, but a demand deposit account is commonly known as a share draft account, a current account, or a checking account. -**Enterprise EV Certificate**: An EV Certificate that an Enterprise RA authorizes the CA to issue at third and higher domain levels. - -**Enterprise EV RA**: An RA that is authorized by the CA to authorize the CA to issue EV Certificates at third and higher domain levels. - **EV Authority**: A source other than the Certificate Approver, through which verification occurs that the Certificate Approver is expressly authorized by the Applicant, as of the date of the EV Certificate Request, to take the Request actions described in these Guidelines. **EV Certificate**: A certificate that contains subject information specified in these Guidelines and that has been validated in accordance with these Guidelines. @@ -518,8 +513,7 @@ __Contents__: This field MUST contain the address of the physical location of th ### 9.2.7. Subject Organizational Unit Name Field __Certificate Field__: `subject:organizationalUnitName` (OID: 2.5.4.11) -__Required/Optional/Prohibited:__ As stated in Section 7.1.4.2.2 i of the Baseline Requirements. -__Contents__: The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with [Section 11](#11-verification-requirements). This field MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. +__Required/Optional/Prohibited:__ __Prohibited__. ### 9.2.8. Subject Organization Identifier Field @@ -593,8 +587,7 @@ A Certificate issued to a Subscriber MUST contain one or more policy identifier( ## 9.4. Maximum Validity Period For EV Certificate -The Validity Period for an EV Certificate SHALL NOT exceed 825 days. -Effective 2020-09-01, the Validity Period for an EV Certificate SHALL NOT exceed 398 days. +The Validity Period for an EV Certificate SHALL NOT exceed 398 days. It is RECOMMENDED that EV Subscriber Certificates have a Maximum Validity Period of twelve months. @@ -679,7 +672,7 @@ CABFOrganizationIdentifier ::= SEQUENCE { registrationSchemeIdentifier PrintableString (SIZE(3)), registrationCountry PrintableString (SIZE(2)), registrationStateOrProvince [0] IMPLICIT PrintableString - OPTIONAL (SIZE(0..128)), + (SIZE(0..128)) OPTIONAL, registrationReference UTF8String } ``` @@ -1214,9 +1207,9 @@ The High Risk Certificate requirements of Section 4.2.1 of the Baseline Requirem A. If the CA has operations in the U.S., the CA MUST take reasonable steps to verify with the following US Government denied lists and regulations: - i. BIS Denied Persons List - https://www.bis.doc.gov/index.php/the-denied-persons-list - ii. BIS Denied Entities List - https://www.bis.doc.gov/index.php/policy-guidance/lists-of-parties-of-concern/entity-list - iii. US Treasury Department List of Specially Designated Nationals and Blocked Persons - https://www.treasury.gov/resource-center/sanctions/sdn-list/pages/default.aspx + i. BIS Denied Persons List - [https://www.bis.doc.gov/index.php/the-denied-persons-list](https://www.bis.doc.gov/index.php/the-denied-persons-list) + ii. BIS Denied Entities List - [https://www.bis.doc.gov/index.php/policy-guidance/lists-of-parties-of-concern/entity-list](https://www.bis.doc.gov/index.php/policy-guidance/lists-of-parties-of-concern/entity-list) + iii. US Treasury Department List of Specially Designated Nationals and Blocked Persons - [https://www.treasury.gov/resource-center/sanctions/sdn-list/pages/default.aspx](https://www.treasury.gov/resource-center/sanctions/sdn-list/pages/default.aspx) iv. US Government export regulations B. If the CA has operations in any other country, the CA MUST take reasonable steps to verify with all equivalent denied lists and export regulations (if any) in such other country. @@ -1236,8 +1229,6 @@ A CA verifying an Applicant using information of the Applicant's Parent, Subsidi ## 11.13. Final Cross-Correlation and Due Diligence -Except for Enterprise EV Certificates: - 1. The results of the verification processes and procedures outlined in these Guidelines are intended to be viewed both individually and as a group. Thus, after all of the verification processes and procedures are completed, the CA MUST have a person who is not responsible for the collection of information review all of the information and documentation assembled in support of the EV Certificate application and look for discrepancies or other details requiring further explanation. 2. The CA MUST obtain and document further explanation or clarification from the Applicant, Certificate Approver, Certificate Requester, Qualified Independent Information Sources, and/or other sources of information, as necessary, to resolve those discrepancies or details that require further explanation. 3. The CA MUST refrain from issuing an EV Certificate until the entire corpus of information and documentation assembled in support of the EV Certificate Request is such that issuance of the EV Certificate will not communicate factual information that the CA knows, or the exercise of due diligence should discover from the assembled information and documentation, to be inaccurate,. If satisfactory explanation and/or additional documentation are not received within a reasonable time, the CA MUST decline the EV Certificate Request and SHOULD notify the Applicant accordingly. @@ -1247,7 +1238,7 @@ Except for Enterprise EV Certificates: B. When the CA has utilized the services of an RA, the CA MAY rely on the language skills of the RA to perform the Final Cross-Correlation and Due Diligence, provided that the RA complies with [Section 11.13](#1113-final-cross-correlation-and-due-diligence), Subsections (1), (2) and (3). Notwithstanding the foregoing, prior to issuing the EV Certificate, the CA MUST review the work completed by the RA and determine that all requirements have been met; or C. When the CA has utilized the services of an RA, the CA MAY rely on the RA to perform the Final Cross-Correlation and Due Diligence, provided that the RA complies with this section and is subjected to the Audit Requirements of [Section 17.5](#175-regular-self-audits) and [Section 17.6](#176-auditor-qualification). - In the case of Enterprise EV Certificates to be issued in compliance with the requirements of [Section 14.2](#142-delegation-of-functions-to-registration-authorities-and-subcontractors), the Enterprise RA MAY perform the requirements of this Final Cross-Correlation and Due Diligence section. +In the case of EV Certificates to be issued in compliance with the requirements of [Section 14.2](#142-delegation-of-functions-to-registration-authorities-and-subcontractors), the Enterprise RA MAY perform the requirements of this Final Cross-Correlation and Due Diligence section. ## 11.14. Requirements for Re-use of Existing Documentation @@ -1295,7 +1286,7 @@ Root CA Private Keys MUST NOT be used to sign EV Certificates. # 13. Certificate Revocation and Status Checking -The requirements in Section 4.9 of the Baseline Requirements apply equally to EV Certificates. However, CAs MUST ensure that CRLs for an EV Certificate chain can be downloaded in no more than three (3) seconds over an analog telephone line under normal network conditions. +The requirements in Section 4.9 of the Baseline Requirements apply equally to EV Certificates. # 14. Employee and third party issues @@ -1343,13 +1334,13 @@ The CA SHALL verify that the Delegated Third Party's personnel involved in the i ### 14.2.2. Enterprise RAs -The CA MAY contractually authorize the Subject of a specified Valid EV Certificate to perform the RA function and authorize the CA to issue additional EV Certificates at third and higher domain levels that are contained within the domain of the original EV Certificate (also known as an Enterprise EV Certificate). In such case, the Subject SHALL be considered an Enterprise RA, and the following requirements SHALL apply: +The CA MAY contractually authorize a Subscriber to perform the RA function and authorize the CA to issue additional EV Certificates. In such case, the Subscriber SHALL be considered an Enterprise RA, and the following requirements SHALL apply: + +1. In all cases, the Subscriber MUST be an organization verified by the CA in accordance with these Guidelines; +2. The CA MUST impose these limitations as a contractual requirement with the Enterprise RA and monitor compliance by the Enterprise RA; and +3. The Final Cross-Correlation and Due Diligence requirements of [Section 11.13](#1113-final-cross-correlation-and-due-diligence) MAY be performed by a single person representing the Enterprise RA. -1. An Enterprise RA SHALL NOT authorize the CA to issue an Enterprise EV Certificate at the third or higher domain levels to any Subject other than the Enterprise RA or a business that is owned or directly controlled by the Enterprise RA; -2. In all cases, the Subject of an Enterprise EV Certificate MUST be an organization verified by the CA in accordance with these Guidelines; -3. The CA MUST impose these limitations as a contractual requirement with the Enterprise RA and monitor compliance by the Enterprise RA; -4. The Final Cross-Correlation and Due Diligence requirements of [Section 11.13](#1113-final-cross-correlation-and-due-diligence) MAY be performed by a single person representing the Enterprise RA; and -5. The audit requirements of [Section 17.1](#171-eligible-audit-schemes) SHALL apply to the Enterprise RA, except in the case where the CA maintains control over the Root CA Private Key or Subordinate CA Private Key used to issue the Enterprise EV Certificates, in which case, the Enterprise RA MAY be exempted from the audit requirements. +Enterprise RAs that authorize the issuance of EV Certificates solely for its own organization are exempted from the audit requirements of [Section 17.1](#171-eligible-audit-schemes). In all other cases, the requirements of [Section 17.1](#171-eligible-audit-schemes) SHALL apply. ### 14.2.3. Guidelines Compliance Obligation @@ -1419,7 +1410,7 @@ All requirements in Section 6.1.1.1 of the Baseline Requirements apply equally t # 18. Liability and Indemnification -CAs MAY limit their liability as described in Section 9.8 of the Baseline Requirements except that a CA MAY NOT limit its liability to Subscribers or Relying Parties for legally recognized and provable claims to a monetary amount less than two thousand US dollars per Subscriber or Relying Party per EV Certificate. +CAs MAY limit their liability as described in Section 9.8 of the Baseline Requirements except that a CA MUST NOT limit its liability to Subscribers or Relying Parties for legally recognized and provable claims to a monetary amount less than two thousand US dollars per Subscriber or Relying Party per EV Certificate. A CA's indemnification obligations and a Root CA's obligations with respect to subordinate CAs are set forth in Section 9.9 of the Baseline Requirements.