From 47744bdab42d8d7b3ab9ce052a8d93bd81a025a3 Mon Sep 17 00:00:00 2001 From: Dimitris Zacharopoulos Date: Fri, 31 Oct 2025 19:11:12 +0200 Subject: [PATCH 001/121] Addresses #584 --- docs/BR.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 5298d38a..768fa055 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2554,7 +2554,7 @@ Table: `GeneralName` requirements for the `base` field | __Name Type__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | __Entire Namespace Exclusion__ | | --------------- | ------------- | ----------------------- | ------------------------ | ------------------------ | | `dNSName` | MUST | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | If no `dNSName` instance is present in the `permittedSubtrees`, then the CA MUST include a zero-length `dNSName` to indicate no domain names are permitted. | -| `iPAddress` | MUST | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the asignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | If no IPv4 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 8 zero octets, indicating the IPv4 range of 0.0.0.0/0 being excluded. If no IPv6 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 32 zero octets, indicating the IPv6 range of ::0/0 being excluded. | +| `iPAddress` | MUST | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the assignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | If no IPv4 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 8 zero octets, indicating the IPv4 range of 0.0.0.0/0 being excluded. If no IPv6 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 32 zero octets, indicating the IPv6 range of ::0/0 being excluded. | | `directoryName` | MUST | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | It is NOT RECOMMENDED to include values within `excludedSubtrees`. | The CA MUST include a value within `permittedSubtrees`, and as such, this does not apply. See the Excluded Subtrees requirements for more. | | `otherName` | NOT RECOMMENDED | See below | See below | See below | | Any other value | MUST NOT | - | - | - | @@ -3236,7 +3236,7 @@ Table: `GeneralName` requirements for the `base` field | __Name Type__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | | --- | -- | --- | -- | | `dNSName` | MAY | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | -| `iPAddress` | MAY | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the asignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | +| `iPAddress` | MAY | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the assignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | | `directoryName` | MAY | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | It is NOT RECOMMENDED to include values within `excludedSubtrees`. | | `rfc822Name` | NOT RECOMMENDED | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | If no `rfc822Name` instance is present in the `permittedSubtrees`, then the CA MAY include a zero-length `rfc822Name` to indicate no mailboxes are permitted. | | `otherName` | NOT RECOMMENDED | See below | See below | See below | From c6dcede255c81e1ad92ad62b7a41a69f05b53cd2 Mon Sep 17 00:00:00 2001 From: Dimitris Zacharopoulos Date: Fri, 31 Oct 2025 19:22:01 +0200 Subject: [PATCH 002/121] Addresses #592 --- docs/BR.md | 46 +--------------------------------------------- 1 file changed, 1 insertion(+), 45 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 768fa055..cdf7d338 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -159,49 +159,6 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | **Compliance** | **Section(s)** | **Summary Description (See Full Text for Details)** | |----------------|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| 2013-01-01 | 6.1.6 | For RSA public keys, CAs SHALL confirm that the value of the public exponent is an odd number equal to 3 or more. | -| 2013-01-01 | 4.9.10 | CAs SHALL support an OCSP capability using the GET method. | -| 2013-01-01 | 5 | CAs SHALL comply with the Network and Certificate System Security Requirements. | -| 2013-08-01 | 4.9.10 | OCSP Responders SHALL NOT respond "Good" for Unissued Certificates. | -| 2013-09-01 | 3.2.2.6 | CAs SHALL revoke any certificate where wildcard character occurs in the first label position immediately to the left of a "registry-controlled" label or "public suffix". | -| 2013-12-31 | 6.1.5 | CAs SHALL confirm that the RSA Public Key is at least 2048 bits or that one of the following ECC curves is used: P-256, P-384, or P-521. A Root CA Certificate issued prior to 31 Dec. 2010 with an RSA key size less than 2048 bits MAY still serve as a trust anchor. | -| 2015-01-16 | 7.1.3 | CAs SHOULD NOT issue Subscriber Certificates utilizing the SHA-1 algorithm with an Expiry Date greater than 1 January 2017. | -| 2015-04-01 | 6.3.2 | CAs SHALL NOT issue certificates with validity periods longer than 39 months, except under certain circumstances. | -| 2015-04-15 | 2.2 | A CA's CPS must state whether it reviews CAA Records, and if so, its policy or practice on processing CAA records for Fully-Qualified Domain Names. | -| 2015-11-01 | 7.1.4.2.1 | Issuance of Certificates with Reserved IP Address or Internal Name prohibited. | -| 2016-01-01 | 7.1.3 | CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA-1 hash algorithm. | -| 2016-06-30 | 6.1.7 | CAs MUST NOT issue Subscriber Certificates directly from Root CAs. | -| 2016-06-30 | 6.3.2 | CAs MUST NOT issue Subscriber Certificates with validity periods longer than 39 months, regardless of circumstance. | -| 2016‐09‐30 | 7.1 | CAs SHALL generate Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG | -| 2016-10-01 | 7.1.4.2.1 | All Certificates with Reserved IP Address or Internal Name must be revoked. | -| 2016-12-03 | 1 and 2 | Ballot 156 amendments to sections 1.5.2, 2.3, and 2.4 are applicable | -| 2017-01-01 | 7.1.3 | CAs MUST NOT issue OCSP responder certificates using SHA-1 (inferred). | -| 2017-03-01 | 3.2.2.4 | CAs MUST follow revised validation requirements in Section 3.2.2.4. | -| 2017-09-08 | 3.2.2.8 | CAs MUST check and process CAA records | -| 2018-03-01 | 4.2.1 and 6.3.2 | Certificates issued MUST have a Validity Period no greater than 825 days and re-use of validation information limited to 825 days | -| 2018-05-31 | 2.2 | CP and CPS must follow RFC 3647 format | -| 2018-08-01 | 3.2.2.4.1 and .5 | CAs must stop using domain validation methods BR 3.2.2.4.1 and 3.2.2.4.5, stop reusing validation data from those methods | -| 2019-01-15 | 7.1.4.2.1 | All certificates containing an underscore character in any dNSName entry and having a validity period of more than 30 days MUST be revoked prior to January 15, 2019 | -| 2019-05-01 | 7.1.4.2.1 | underscore characters (“_”) MUST NOT be present in dNSName entries | -| 2019-06-01 | 3.2.2.4.3 | 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. | -| 2019-08-01 | 3.2.2.5 | CAs SHALL maintain a record of which IP validation method, including the relevant BR version number, was used to validate every IP Address | -| 2019-08-01 | 3.2.2.5.4 | CAs SHALL NOT perform validations using this method after July 31, 2019. Completed validations using this method SHALL NOT be re-used for certificate issuance after July 31, 2019. Any certificate issued prior to August 1, 2019 containing an IP Address that was validated using any method that was permitted under the prior version of this Section 3.2.2.5 MAY continue to be used without revalidation until such certificate naturally expires | -| 2020-06-03 | 3.2.2.4.6 | CAs MUST NOT perform validation using this method after 3 months from the IPR review date of Ballot SC25 | -| 2020-08-01 | 8.6 | Audit Reports for periods on-or-after 2020-08-01 MUST be structured as defined. | -| 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 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. | -| 2021-10-01 | 7.1.4.2.1 | Fully-Qualified Domain Names MUST consist solely of P-Labels and Non-Reserved LDH Labels. | -| 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 | -| 2023-07-15 | 4.9.1.1 and 7.2.2 | New CRL entries MUST have a revocation reason code | -| 2023-09-15 | Section 7 (and others) | CAs MUST use the updated Certificate Profiles passed in Version 2.0.0 | | 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | | 2024-09-15 | 4.3.1.2 | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | | 2025-01-15 | 4.9.9 | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. | @@ -1342,7 +1299,6 @@ Certificate issuance by the Root CA SHALL require an individual authorized by th #### 4.3.1.2 Linting of to-be-signed Certificate content Due to the complexity involved in implementing Certificate Profiles that conform to these Requirements, it is considered best practice for the CA to implement a Linting process to test the technical conformity of each to-be-signed artifact prior to signing it. When a Precertificate has undergone Linting, it is not necessary for the corresponding to-be-signed Certificate to also undergo Linting, provided that the CA has a technical control to verify that the to-be-signed Certificate corresponds to the to-be-signed Precertificate in the manner described by RFC 6962, Section 3.2. -Effective 2024-09-15, the CA SHOULD implement such a Linting process. Effective 2025-03-15, the CA SHALL implement such a Linting process. Methods used to produce a certificate containing the to-be-signed Certificate content include, but are not limited to: @@ -2126,7 +2082,7 @@ The CA MAY perform Linting on the corpus of its unexpired, un-revoked Subscriber The CA SHALL meet the technical requirements set forth in [Section 6.1.5 - Key Sizes](#615-key-sizes), and [Section 6.1.6 - Public Key Parameters Generation and Quality Checking](#616-public-key-parameters-generation-and-quality-checking). -Prior to 2023-09-15, the CA SHALL issue Certificates in accordance with the profile specified in these Requirements or the profile specified in version 1.8.6 of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Effective 2023-09-15, the CA SHALL issue Certificates in accordance with the profile specified in these Requirements. +The CA SHALL issue Certificates in accordance with the profile specified in these Requirements. ### 7.1.1 Version number(s) From eedf28ad1d7dcbb57dbb22ffe1c5509951f0e16c Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 4 Nov 2025 14:38:17 +0100 Subject: [PATCH 003/121] Addresses #603 - typo IASE -> ISAE --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index cdf7d338..d522ddac 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1162,7 +1162,7 @@ SHOULD: - Facility & Service Provider Requirements - Be hosted from an ISO/IEC 27001 certified facility or equivalent security framework independently audited and certified or reported. - - Rely on services covered in one of the following reports: System and Organization Controls 2 (SOC 2), IASE 3000, ENISA 715, FedRAMP Moderate, C5:2020, CSA STAR CCM, or equivalent services framework independently audited and certified or reported. + - Rely on services covered in one of the following reports: System and Organization Controls 2 (SOC 2), ISAE 3000, ENISA 715, FedRAMP Moderate, C5:2020, CSA STAR CCM, or equivalent services framework independently audited and certified or reported. - Vulnerability Detection and Patch Management - Implement intrusion detection and prevention controls to protect against common network and system threats. - Document and follow a vulnerability correction process that addresses the identification, review, response, and remediation of vulnerabilities. From ced04a09bd24f8c1063ac176803a66f9a8062a24 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 15:06:42 +0100 Subject: [PATCH 004/121] Addresses #496 - phone number example --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index d522ddac..2823cb04 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -3909,7 +3909,7 @@ The following is an example where the holder of the domain specified the contact ```DNS Zone $ORIGIN example.com. - CAA 0 contactphone "+1 (555) 123-4567" + CAA 0 contactphone "+1 555 123 4567" ``` The contactphone property MAY be critical if the domain owner does not want CAs who do not understand it to issue certificates for the domain. From 0fa3911005fa369614e597cf523b9f88c0241a3d Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 15:23:19 +0100 Subject: [PATCH 005/121] #303 removed code signing reference --- docs/EVG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/EVG.md b/docs/EVG.md index c76e1e69..e4aa6589 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -28,7 +28,7 @@ The CA/Browser Forum is a voluntary open organization of certification authoriti ## 1.1 Overview These Guidelines for the issuance and management of Extended Validation Certificates describe certain of the minimum requirements that a Certification Authority must meet in order to issue Extended Validation Certificates. Subject Organization information from Valid EV Certificates may be displayed 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 they are accessing. These Guidelines incorporate the Baseline Requirements established by the CA/Browser Forum by reference. A copy of the Baseline Requirements is available on the CA/Browser Forum's website at . -These Guidelines address the basic issue of validating Subject identity information in EV Certificates and some related matters. They do not address all of the related matters, such as certain technical and operational ones. This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet and for code signing. Similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. may be covered in future versions. +These Guidelines address the basic issue of validating Subject identity information in EV Certificates and some related matters. They do not address all of the related matters, such as certain technical and operational ones. This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet. However, the Working Group encourages the re-use of these guidelines as a basis for similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. These Guidelines do not address the verification of information, or the issuance, use, maintenance, or revocation of EV Certificates by enterprises that operate their own Public Key Infrastructure for internal purposes only, where its Root CA Certificate is not distributed by any Application Software Supplier. From 6d019198b8af9f897d8e8342a9743cb67d6a39f8 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 15:26:00 +0100 Subject: [PATCH 006/121] #452 changed SIZE 1..128 --- docs/EVG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/EVG.md b/docs/EVG.md index e4aa6589..77fa86c5 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -1303,7 +1303,7 @@ CABFOrganizationIdentifier ::= SEQUENCE { registrationSchemeIdentifier PrintableString (SIZE(3)), registrationCountry PrintableString (SIZE(2)), registrationStateOrProvince [0] IMPLICIT PrintableString - (SIZE(0..128)) OPTIONAL, + (SIZE(1..128)) OPTIONAL, registrationReference UTF8String } ``` From e65f153635665dbc03ade4a128fd01ad48a6bdd4 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 15:28:17 +0100 Subject: [PATCH 007/121] #547 added v2 to header --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 2823cb04..01f6ef9c 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -863,7 +863,7 @@ CAs performing validations using this method MUST implement Multi-Perspective Is **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. -##### 3.2.2.4.15 Phone Contact with Domain Contact +##### 3.2.2.4.15 Phone Contact with Domain Contact v2 Confirm the Applicant's control over the FQDN by calling the Domain 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 Domain Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN. From 62af9baab1b4c6c276ec4074c4baf926daed3930 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 15:33:34 +0100 Subject: [PATCH 008/121] #540 MUST NOT -> SHOULD NOT --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 01f6ef9c..398ed001 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2869,7 +2869,7 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | `subjectAltName` | MUST NOT | - | - | | `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `authorityInformationAccess` | NOT RECOMMENDED | N | See [Section 7.1.2.8.3](#71283-ocsp-responder-authority-information-access) | -| `certificatePolicies` | MUST NOT | N | See [Section 7.1.2.8.8](#71288-ocsp-responder-certificate-policies) | +| `certificatePolicies` | SHOULD NOT | N | See [Section 7.1.2.8.8](#71288-ocsp-responder-certificate-policies) | | `crlDistributionPoints` | MUST NOT | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | From 5eaf69b1fbb4182e72c863458016864aee2f77b2 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 15:34:33 +0100 Subject: [PATCH 009/121] #540 Note about effective dates removed --- docs/BR.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 398ed001..2bc0c957 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2943,9 +2943,6 @@ Table: Permitted `policyQualifiers` | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | - -**Note**: See [Section 7.1.2.8.2](#71282-ocsp-responder-extensions) for applicable effective dates for when this extension may be included. - **Note**: Because the Certificate Policies extension may be used to restrict the applicable usages for a Certificate, incorrect policies may result in OCSP Responder Certificates that fail to successfully validate, resulting in invalid OCSP Responses. Including the `anyPolicy` policy can reduce this risk, but add to client processing complexity and interoperability issues. #### 7.1.2.9 Precertificate Profile From 21af19c3f56734993de982a07ed3e2bd62ea9fa5 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 15:38:48 +0100 Subject: [PATCH 010/121] #415 changed APPENDIX -> Appendix as in other BR --- docs/BR.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 2bc0c957..210b01bf 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -3875,7 +3875,7 @@ Any modification to CA practice enabled under this section MUST be discontinued ## 9.17 Other provisions -# APPENDIX A – CAA Contact Tag +# Appendix A – CAA Contact Tag These methods allow domain owners to publish contact information in DNS for the purpose of validating domain control. @@ -3921,7 +3921,7 @@ The DNS TXT record MUST be placed on the "`_validation-contactemail`" subdomain The DNS TXT record MUST be placed on the "`_validation-contactphone`" subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid Global Number as defined in RFC 3966, Section 5.1.4, or it cannot be used. -# APPENDIX B – Issuance of Certificates for Onion Domain Names +# Appendix B – Issuance of Certificates for Onion Domain Names This appendix defines permissible verification procedures for including one or more Onion Domain Names in a Certificate. From 327e12dd632631ce04f2529ba7d0b1b5778aca87 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 15:45:08 +0100 Subject: [PATCH 011/121] #546 3.2.2.4.4 changed to Email to a Constructed Address --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 210b01bf..07566a83 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -765,7 +765,7 @@ Effective July 15, 2025: 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 +##### 3.2.2.4.4 Email to a Constructed Address Confirm the Applicant's control over the FQDN by From a7b16dd4e185b3acc7c77fdc6218112c178597bc Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 15:56:28 +0100 Subject: [PATCH 012/121] #458 changed 4.9.1.1 example 9 --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 07566a83..46fe915b 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1459,7 +1459,7 @@ With the exception of Short-lived Subscriber Certificates, the CA SHOULD revoke 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) (CRLReason #4, superseded); 7. The CA obtains evidence that the Certificate was misused (CRLReason #9, privilegeWithdrawn); 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 (CRLReason #9, privilegeWithdrawn); -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) (CRLReason #5, cessationOfOperation); +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) (CRLReason # 5, cessationOfOperation); 10. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name (CRLReason #9, privilegeWithdrawn); 11. The CA is made aware of a material change in the information contained in the Certificate (CRLReason #9, privilegeWithdrawn); 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 (CRLReason #4, superseded); From fbc9a632ddb6b22eae3a6a0286a9b7f13183f6af Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 15:57:36 +0100 Subject: [PATCH 013/121] #458 removed 4.9.1.1 example 2 and 3 --- docs/BR.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 46fe915b..b62923a7 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1449,8 +1449,6 @@ The CA MAY support revocation of Short-lived Subscriber Certificates. With the exception of Short-lived Subscriber Certificates, the CA SHALL revoke a Certificate within 24 hours and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs: 1. The Subscriber requests in writing, without specifying a CRLreason, that the CA revoke the Certificate (CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL); -2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization (CRLReason #9, privilegeWithdrawn); -3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise (CRLReason #1, keyCompromise); 4. 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, including but not limited to those identified in [Section 6.1.1.3(5)](#6113-subscriber-key-pair-generation) (CRLReason #1, keyCompromise); 5. The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon (CRLReason #4, superseded). From 8f131de6e2a03231b56ffca1fc8fa63a4b51ec34 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 16:05:45 +0100 Subject: [PATCH 014/121] #574 header is ok, removed spaces --- docs/BR.md | 47 +++++++++++++++++++++++------------------------ 1 file changed, 23 insertions(+), 24 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index b62923a7..97de2510 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -156,30 +156,29 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse ### 1.2.2 Relevant Dates - -| **Compliance** | **Section(s)** | **Summary Description (See Full Text for Details)** | -|----------------|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | -| 2024-09-15 | 4.3.1.2 | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | -| 2025-01-15 | 4.9.9 | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. | -| 2025-01-15 | 3.2.2.4 | CAs MUST NOT rely on HTTPS websites to identify Domain Contact information. CAs MUST rely on IANA resources for identifying Domain Contact information. | -| 2025-03-15 | 4.3.1.2 | The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | -| 2025-03-15 | 8.7 | The CA SHOULD use a Linting process to test the technical accuracy of already issued Certificates against the sample set chosen for Self-Audits. | -| 2025-03-15 | 3.2.2.9 | CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified. | -| 2025-07-15 | 3.2.2.4 | CAs MUST NOT rely on Methods 3.2.2.4.2 and 3.2.2.4.15 to issue Subscriber Certificates. | -| 2025-12-01 | 5.7.1.2 | CAs SHALL assert in section 5.7.1 of their CPS or combined CP/CPS their mass revocation plan, testing, and continuous improvements. | -| 2026-03-15 | 4.2.1 | Subject Identity Information validation maximum data reuse period is 398 days. | -| 2026-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 200 days. | -| 2026-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 200 days. | -| 2026-03-15 | 3.2.2.4 | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. | -| 2026-03-15 | 3.2.2.4 | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. | -| 2026-03-15 | 3.2.2.8.1 | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. | -| 2026-03-15 | 3.2.2.8.1 | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. | -| 2026-03-15 | 3.2.2.8.1 | DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. | -| 2027-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 100 days. | -| 2027-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 100 days. | -| 2029-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 10 days. | -| 2029-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 47 days. | +| **Compliance** | **Section(s)** | **Summary Description (See Full Text for Details)** | +|----------------|----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | +| 2024-09-15 | 4.3.1.2 | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | +| 2025-01-15 | 4.9.9 | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. | +| 2025-01-15 | 3.2.2.4 | CAs MUST NOT rely on HTTPS websites to identify Domain Contact information. CAs MUST rely on IANA resources for identifying Domain Contact information. | +| 2025-03-15 | 4.3.1.2 | The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | +| 2025-03-15 | 8.7 | The CA SHOULD use a Linting process to test the technical accuracy of already issued Certificates against the sample set chosen for Self-Audits. | +| 2025-03-15 | 3.2.2.9 | CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified. | +| 2025-07-15 | 3.2.2.4 | CAs MUST NOT rely on Methods 3.2.2.4.2 and 3.2.2.4.15 to issue Subscriber Certificates. | +| 2025-12-01 | 5.7.1.2 | CAs SHALL assert in section 5.7.1 of their CPS or combined CP/CPS their mass revocation plan, testing, and continuous improvements. | +| 2026-03-15 | 4.2.1 | Subject Identity Information validation maximum data reuse period is 398 days. | +| 2026-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 200 days. | +| 2026-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 200 days. | +| 2026-03-15 | 3.2.2.4 | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. | +| 2026-03-15 | 3.2.2.4 | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. | +| 2026-03-15 | 3.2.2.8.1 | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. | +| 2026-03-15 | 3.2.2.8.1 | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. | +| 2026-03-15 | 3.2.2.8.1 | DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. | +| 2027-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 100 days. | +| 2027-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 100 days. | +| 2029-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 10 days. | +| 2029-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 47 days. | ## 1.3 PKI Participants From 306c1c0c18805e82579f4c3a47dd0f535873faa5 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 16:08:17 +0100 Subject: [PATCH 015/121] #489 changed RFC 7482 -> 9082 in WHOIS def --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 97de2510..a383a396 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -494,7 +494,7 @@ The script outputs: **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. +**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 9082, or an HTTPS website. **Wildcard Certificate**: A Certificate containing at least one Wildcard Domain Name in the Subject Alternative Names in the Certificate. From d8613dac9bef93d9f446582ed9971339a6554dc2 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 21:32:33 +0100 Subject: [PATCH 016/121] #542 added number 1.2.2 to Relevant Dates --- docs/EVG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/EVG.md b/docs/EVG.md index 77fa86c5..338bd248 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -84,7 +84,7 @@ These Guidelines do not address the verification of information, or the issuance \* Effective Date and Additionally Relevant Compliance Date(s) -## Relevant Dates +### 1.2.2 Relevant Dates | **Compliance** | **Section(s)** | **Summary Description (See Full Text for Details)** | |--|--|----------| From 6f7abd636267e8b1d324f6180afdadfba8cdcf49 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 21:45:18 +0100 Subject: [PATCH 017/121] #428 NTR Registration Scheme identifier definition updated according to S/MIME language --- docs/EVG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/EVG.md b/docs/EVG.md index 338bd248..3463be59 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -1402,7 +1402,7 @@ The Registration Scheme MUST be identified using the using the following structu * 3 character Registration Scheme identifier; * 2 character ISO 3166 country code for the nation in which the Registration Scheme is operated, or if the scheme is operated globally ISO 3166 code "XG" shall be used; -* For the NTR Registration Scheme identifier, if required under [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field), a 2 character ISO 3166-2 identifier for the subdivision (state or province) of the nation in which the Registration Scheme is operated, preceded by plus "+" (0x2B (ASCII), U+002B (UTF-8)); +* For the NTR Registration Scheme identifier, where registrations are administrated at the subdivision (state or province) level, if required under [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field), a plus "+" (0x2B (ASCII), U+002B (UTF-8)) followed by an up-to-three alphanumeric character ISO 3166-2 identifier for the subdivision of the nation in which the Registration Scheme is operated; * a hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8)); * Registration Reference allocated in accordance with the identified Registration Scheme From 04cd7652788c3990c51d586a0c704b64cd9ad56e Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 21:52:05 +0100 Subject: [PATCH 018/121] #193 changed common date format to ISO 8601 --- docs/EVG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/EVG.md b/docs/EVG.md index 3463be59..13d91a7b 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -1366,7 +1366,7 @@ Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, t __Certificate Field__: `subject:serialNumber` (OID: 2.5.4.5) __Required/Optional__: __Required__ -__Contents__: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field in any one of the common date formats. +__Contents__: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). For Government Entities that do not have a Registration Number or readily verifiable date of creation, the CA SHALL enter appropriate language to indicate that the Subject is a Government Entity. From e3a751e7d27bbc7c666a44727ad6d40705f24abd Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 21:53:04 +0100 Subject: [PATCH 019/121] #193 changed common date format to ISO 8601 --- docs/EVG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/EVG.md b/docs/EVG.md index 13d91a7b..0bda0929 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -1370,7 +1370,7 @@ __Contents__: For Private Organizations, this field MUST contain the Registratio For Government Entities that do not have a Registration Number or readily verifiable date of creation, the CA SHALL enter appropriate language to indicate that the Subject is a Government Entity. -For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in any one of the common date formats. +For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). Effective as of 1 October 2020, if the CA has disclosed a set of acceptable format or formats for Registration Numbers for the applicable Registration Agency or Incorporating Agency, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), the CA MUST ensure, prior to issuance, that the Registration Number is valid according to at least one currently disclosed format for that applicable Registration Agency or Incorporating agency. From 09cd828546e29fdd05e14fec068c86f08024cc1c Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 21:55:31 +0100 Subject: [PATCH 020/121] #322 removed duplicated by a from sentence --- docs/EVG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/EVG.md b/docs/EVG.md index 0bda0929..97bb9438 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -958,7 +958,7 @@ The CA MAY only issue EV Certificates to Applicants that meet the Private Organi An Applicant qualifies as a Private Organization if: -1. The entity's legal existence is created or recognized by a by a filing with (or an act of) the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration (e.g., by issuance of a certificate of incorporation, registration number, etc.) or created or recognized by a Government Agency (e.g. under a charter, treaty, convention, or equivalent recognition instrument); +1. The entity's legal existence is created or recognized by a filing with (or an act of) the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration (e.g., by issuance of a certificate of incorporation, registration number, etc.) or created or recognized by a Government Agency (e.g. under a charter, treaty, convention, or equivalent recognition instrument); 2. The entity designated with the Incorporating or Registration Agency a Registered Agent, a Registered Office (as required under the laws of the Jurisdiction of Incorporation or Registration), or an equivalent facility; From 836355579249d6c5ff84402c46739432bc4b266e Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 5 Nov 2025 22:04:45 +0100 Subject: [PATCH 021/121] #458 fixed numbering sequence --- docs/BR.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index a383a396..854b9748 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1448,22 +1448,22 @@ The CA MAY support revocation of Short-lived Subscriber Certificates. With the exception of Short-lived Subscriber Certificates, the CA SHALL revoke a Certificate within 24 hours and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs: 1. The Subscriber requests in writing, without specifying a CRLreason, that the CA revoke the Certificate (CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL); -4. 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, including but not limited to those identified in [Section 6.1.1.3(5)](#6113-subscriber-key-pair-generation) (CRLReason #1, keyCompromise); -5. The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon (CRLReason #4, superseded). +2. 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, including but not limited to those identified in [Section 6.1.1.3(5)](#6113-subscriber-key-pair-generation) (CRLReason #1, keyCompromise); +3. The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon (CRLReason #4, superseded). With the exception of Short-lived Subscriber Certificates, the CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs: -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) (CRLReason #4, superseded); -7. The CA obtains evidence that the Certificate was misused (CRLReason #9, privilegeWithdrawn); -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 (CRLReason #9, privilegeWithdrawn); -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) (CRLReason # 5, cessationOfOperation); -10. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name (CRLReason #9, privilegeWithdrawn); -11. The CA is made aware of a material change in the information contained in the Certificate (CRLReason #9, privilegeWithdrawn); -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 (CRLReason #4, superseded); -13. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate (CRLReason #9, privilegeWithdrawn); -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 (CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL); -15. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement for a reason that is not otherwise required to be specified by this section 4.9.1.1 (CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL); 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 (CRLReason #1, keyCompromise). +4. 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) (CRLReason #4, superseded); +5. The CA obtains evidence that the Certificate was misused (CRLReason #9, privilegeWithdrawn); +6. 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 (CRLReason #9, privilegeWithdrawn); +7. 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) (CRLReason # 5, cessationOfOperation); +8. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name (CRLReason #9, privilegeWithdrawn); +9. The CA is made aware of a material change in the information contained in the Certificate (CRLReason #9, privilegeWithdrawn); +10. 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 (CRLReason #4, superseded); +11. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate (CRLReason #9, privilegeWithdrawn); +12. 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 (CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL); +13. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement for a reason that is not otherwise required to be specified by this section 4.9.1.1 (CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL); or +14. 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 (CRLReason #1, keyCompromise). #### 4.9.1.2 Reasons for Revoking a Subordinate CA Certificate From 42c6eba5348b8536c347973eb71a786ee40f02b2 Mon Sep 17 00:00:00 2001 From: dzacharo Date: Sat, 22 Nov 2025 12:49:14 +0200 Subject: [PATCH 022/121] Addresses #435 --- docs/EVG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/EVG.md b/docs/EVG.md index 97bb9438..2d588a30 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -278,7 +278,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Suspect code**: Code that contains malicious functionality or serious vulnerabilities, including spyware, malware and other code that installs without the user's consent and/or resists its own removal, and code that can be exploited in ways not intended by its designers to compromise the trustworthiness of the platforms on which it executes. -**Translator**: An individual or Business Entity that possesses the requisite knowledge and expertise to accurately translate the words of a document written in one language to the native language of the CA. +**Translator**: A Natural Person or a Legal Entity that possesses the requisite knowledge and expertise to accurately translate the words of a document written in one language to the native language of the CA. **Verified Accountant Letter**: A document meeting the requirements specified in [Section 3.2.2.11.2](#322112-verified-accountant-letter). From cb47fd08bcfaea426fdf0be044e3897ea23c77f5 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Sat, 22 Nov 2025 12:16:17 +0100 Subject: [PATCH 023/121] #496 changed definition "spaces as visual separators" --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 854b9748..dae453f3 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -3897,7 +3897,7 @@ The contactemail property MAY be critical, if the domain owner does not want CAs SYNTAX: `contactphone ` -The CAA contactphone property takes a phone number as its parameter. The entire parameter value MUST be a valid Global Number as defined in RFC 3966, Section 5.1.4, or it cannot be used. Global Numbers MUST have a preceding + and a country code and MAY contain visual separators. +The CAA contactphone property takes a phone number as its parameter. The entire parameter value MUST be a valid Global Number as defined in RFC 3966, Section 5.1.4, or it cannot be used. Global Numbers MUST have a preceding + and a country code and MAY contain spaces as visual separators. The following is an example where the holder of the domain specified the contact property using a phone number. From 3d1c310d7f61e9149d8825c0faa5cd8541affe7a Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Sat, 22 Nov 2025 12:24:33 +0100 Subject: [PATCH 024/121] #303 removed "or distribute executable code," and "malware" --- docs/EVG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/EVG.md b/docs/EVG.md index 2d588a30..4a35a7be 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -133,7 +133,7 @@ The primary purposes of an EV Certificate are to: #### 1.4.1.2 Secondary Purposes -The secondary purposes of an EV Certificate are to help establish the legitimacy of a business claiming to operate a Web site or distribute executable code, and to provide a vehicle that can be used to assist in addressing problems related to phishing, malware, and other forms of online identity fraud. By providing more reliable third-party verified identity and address information regarding the business, EV Certificates may help to: +The secondary purposes of an EV Certificate are to help establish the legitimacy of a business claiming to operate a Web site, and to provide a vehicle that can be used to assist in addressing problems related to phishing, and other forms of online identity fraud. By providing more reliable third-party verified identity and address information regarding the business, EV Certificates may help to: 1. Make it more difficult to mount phishing and other online identity fraud attacks using Certificates; 2. Assist companies that may be the target of phishing attacks or online identity fraud by providing them with a tool to better identify themselves to users; and From b4631a6658aa3384aed2de78592223d5acf08729 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Sat, 22 Nov 2025 12:46:58 +0100 Subject: [PATCH 025/121] #432 table headers bold changed from __ to ** --- docs/BR.md | 172 ++++++++++++++++++++++++++--------------------------- 1 file changed, 86 insertions(+), 86 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index dae453f3..031ac36b 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1255,7 +1255,7 @@ The CA MAY use the documents and data provided in [Section 3.2](#32-initial-iden Table: Subject Identity Information validation data reuse periods -| __Certificate issued on or after__ | __Certificate issued before__ | __Maximum data reuse period__ | +| **Certificate issued on or after** | **Certificate issued before** | **Maximum data reuse period** | | -- | -- | -- | | | March 15, 2026 | 825 days | | March 15, 2026 | | 398 days | @@ -1264,7 +1264,7 @@ For validation of Domain Names and IP Addresses according to [Section 3.2.2.4](# Table: Domain Name and IP Address validation data reuse periods -| __Certificate issued on or after__ | __Certificate issued before__ | __Maximum data reuse period__ | +| **Certificate issued on or after** | **Certificate issued before** | **Maximum data reuse period** | | -- | -- | -- | | | March 15, 2026 | 398 days | | March 15, 2026 | March 15, 2027 | 200 days | @@ -2032,7 +2032,7 @@ Subscriber Certificates issued on or after 15 March 2029 SHOULD NOT have a Valid Table: Reference for maximum Validity Periods of Subscriber Certificates -| __Certificate issued on or after__ | __Certificate issued before__ | __Maximum Validity Period__ | +| **Certificate issued on or after** | **Certificate issued before** | **Maximum Validity Period** | | -- | -- | -- | | | March 15, 2026 | 398 days | | March 15, 2026 | March 15, 2027 | 200 days | @@ -2105,7 +2105,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates #### 7.1.2.1 Root CA Certificate Profile -| __Field__ | __Description__ | +| **Field** | **Description** | | ---- | ------ | | `tbsCertificate` | | |     `version` | MUST be v3(2) | @@ -2123,7 +2123,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates ##### 7.1.2.1.1 Root CA Validity -| __Field__ | __Minimum__ | __Maximum__ | +| **Field** | **Minimum** | **Maximum** | | -- | ---- | ---- | | `notBefore` | One day prior to the time of signing | The time of signing | | `notAfter` | 2922 days (approx. 8 years) | 9132 days (approx. 25 years) | @@ -2132,7 +2132,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates ##### 7.1.2.1.2 Root CA Extensions -| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| **Extension** | **Presence** | **Critical** | **Description** | | ---- | -- | - | --- | | `authorityKeyIdentifier` | RECOMMENDED | N | See [Section 7.1.2.1.3](#71213-root-ca-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.1.4](#71214-root-ca-basic-constraints) | @@ -2145,7 +2145,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates ##### 7.1.2.1.3 Root CA Authority Key Identifier -| __Field__ | __Description__ | +| **Field** | **Description** | | --- | ------- | | `keyIdentifier` | MUST be present. MUST be identical to the `subjectKeyIdentifier` field. | | `authorityCertIssuer` | MUST NOT be present | @@ -2153,7 +2153,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates ##### 7.1.2.1.4 Root CA Basic Constraints -| __Field__ | __Description__ | +| **Field** | **Description** | | --- | ------- | | `cA` | MUST be set TRUE | | `pathLenConstraint` | NOT RECOMMENDED | @@ -2164,7 +2164,7 @@ This Certificate Profile MAY be used when issuing a CA Certificate using the sam Before issuing a Cross-Certified Subordinate CA, the Issuing CA MUST confirm that the existing CA Certificate(s) are subject to these Baseline Requirements and were issued in compliance with the then-current version of the Baseline Requirements at time of issuance. -| __Field__ | __Description__ | +| **Field** | **Description** | | ---- | ------ | | `tbsCertificate` | | |     `version` | MUST be v3(2) | @@ -2182,7 +2182,7 @@ Before issuing a Cross-Certified Subordinate CA, the Issuing CA MUST confirm tha ##### 7.1.2.2.1 Cross-Certified Subordinate CA Validity -| __Field__ | __Minimum__ | __Maximum__ | +| **Field** | **Minimum** | **Maximum** | | -- | ---- | ---- | | `notBefore` | The earlier of one day prior to the time of signing or the earliest `notBefore` date of the existing CA Certificate(s) | The time of signing | | `notAfter` | The time of signing | Unspecified | @@ -2195,7 +2195,7 @@ The `subject` MUST comply with the requirements of [Section 7.1.4](#714-name-for ##### 7.1.2.2.3 Cross-Certified Subordinate CA Extensions -| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| **Extension** | **Presence** | **Critical** | **Description** | | --- | -- | -- | --- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | @@ -2218,7 +2218,7 @@ The extKeyUsage extension MAY be "unrestricted" as described in the following ta Table: Cross-Certified Subordinate CA with Unrestricted EKU -| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| **Extension** | **Presence** | **Critical** | **Description** | | --- | -- | -- | --- | | `extKeyUsage` | SHOULD[^eku_ca] | N | See [Section 7.1.2.2.4](#71224-cross-certified-subordinate-ca-extended-key-usage---unrestricted) | @@ -2226,7 +2226,7 @@ In all other cases, the extKeyUsage extension MUST be "restricted" as described Table: Cross-Certified Subordinate CA with Restricted EKU -| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| **Extension** | **Presence** | **Critical** | **Description** | | --- | -- | -- | --- | | `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.2.5](#71225-cross-certified-subordinate-ca-extended-key-usage---restricted) | @@ -2238,7 +2238,7 @@ Table: Cross-Certified Subordinate CA with Restricted EKU Table: Unrestricted Extended Key Usage Purposes (Affiliated Cross-Certified CA) -| __Key Purpose__ | __Description__ | +| **Key Purpose** | **Description** | | --- | ------- | | `anyExtendedKeyUsage` | The special extended key usage to indicate there are no restrictions applied. If present, this MUST be the only key usage present. | | Any other value | CAs MUST NOT include any other key usage with the `anyExtendedKeyUsage` key usage present. | @@ -2249,7 +2249,7 @@ Alternatively, if the Issuing CA does not use this form, then the Extended Key U Table: Restricted TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs issuing TLS certificates directly or transitively) -| __Key Purpose__ | __Description__ | +| **Key Purpose** | **Description** | | --- | ------- | | `id-kp-serverAuth` | MUST be present.| | `id-kp-clientAuth` | MAY be present.| @@ -2261,7 +2261,7 @@ Table: Restricted TLS Cross-Certified Subordinate CA Extended Key Usage Purposes Table: Restricted Non-TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs not issuing TLS certificates directly or transitively) -| __Key Purpose__ | __Description__ | +| **Key Purpose** | **Description** | | --- | ------- | | `id-kp-serverAuth` | MUST NOT be present.| | `anyExtendedKeyUsage` | MUST NOT be present.| @@ -2284,7 +2284,7 @@ The Certificate Policies extension MUST contain at least one `PolicyInformation` Table: No Policy Restrictions (Affiliated CA) -| __Field__ | __Presence__ | __Contents__ | +| **Field** | **Presence** | **Contents** | | --- | -- | ----- | | `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, and if the Subordinate CA is an Affiliate of the Issuing CA, then the Issuing CA MAY use the `anyPolicy` Policy Identifier, which MUST be the only `PolicyInformation` value. | |     `anyPolicy` | MUST | | @@ -2293,7 +2293,7 @@ Table: No Policy Restrictions (Affiliated CA) Table: Policy Restricted -| __Field__ | __Presence__ | __Contents__ | +| **Field** | **Presence** | **Contents** | | --- | --- | ---- | | `policyIdentifier` | MUST | One of the following policy identifiers: | |     A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The CA MUST include at least one Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)) transitively issued by this Certificate. | @@ -2313,7 +2313,7 @@ If the `policyQualifiers` is permitted and present within a `PolicyInformation` Table: Permitted `policyQualifiers` -| __Qualifier ID__ | __Presence__ | __Field Type__ | __Contents__ | +| **Qualifier ID** | **Presence** | **Field Type** | **Contents** | | --- | -- | -- | --- | | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | @@ -2322,7 +2322,7 @@ Table: Permitted `policyQualifiers` This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will not be used to issue TLS certificates directly or transitively. -| __Field__ | __Description__ | +| **Field** | **Description** | | ---- | ------ | | `tbsCertificate` | | |     `version` | MUST be v3(2) | @@ -2340,7 +2340,7 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be ##### 7.1.2.3.1 Technically Constrained Non-TLS Subordinate CA Extensions -| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| **Extension** | **Presence** | **Critical** | **Description** | | --- | -- | -- | --- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | @@ -2360,7 +2360,7 @@ If present, the Certificate Policies extension MUST be formatted as one of the t Table: No Policy Restrictions (Affiliated CA) -| __Field__ | __Presence__ | __Contents__ | +| **Field** | **Presence** | **Contents** | | --- | --- | ---- | | `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, the Subordinate CA MUST be an Affiliate of the Issuing CA. The Certificate Policies extension MUST contain only a single `PolicyInformation` value, which MUST contain the `anyPolicy` Policy Identifier. | |     `anyPolicy` | MUST | | @@ -2369,7 +2369,7 @@ Table: No Policy Restrictions (Affiliated CA) Table: Policy Restricted -| __Field__ | __Presence__ | __Contents__ | +| **Field** | **Presence** | **Contents** | | --- | --- | ---- | | `policyIdentifier` | MUST | One of the following policy identifiers: | |     A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST NOT | | @@ -2380,7 +2380,7 @@ Table: Policy Restricted Table: Permitted `policyQualifiers` -| __Qualifier ID__ | __Presence__ | __Field Type__ | __Contents__ | +| **Qualifier ID** | **Presence** | **Field Type** | **Contents** | | --- | -- | -- | --- | | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | @@ -2390,7 +2390,7 @@ Table: Permitted `policyQualifiers` The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to issue certificates for each included extended key usage purpose. Multiple, independent key purposes (e.g. `id-kp-timeStamping` and `id-kp-codeSigning`) are NOT RECOMMENDED. -| __Key Purpose__ | __OID__ | __Presence__ | +| **Key Purpose** | **OID** | **Presence** | | ---- | ---- | -- | | `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST NOT | | `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | @@ -2406,7 +2406,7 @@ A Precertificate Signing CA MUST only be used to sign Precertificates, as define As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is not altered as part of these modifications. As such, the Precertificate Signing CA MUST use the same signature algorithm as the Issuing CA when issuing Precertificates, and, correspondingly, MUST use a public key of the same public key algorithm as the Issuing CA, although MAY use a different CA Key Pair. -| __Field__ | __Description__ | +| **Field** | **Description** | | ---- | ------ | | `tbsCertificate` | | |     `version` | MUST be v3(2) | @@ -2424,7 +2424,7 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is ##### 7.1.2.4.1 Technically Constrained Precertificate Signing CA Extensions -| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| **Extension** | **Presence** | **Critical** | **Description** | | ---- | -- | -- | -- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | @@ -2440,7 +2440,7 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is ##### 7.1.2.4.2 Technically Constrained Precertificate Signing CA Extended Key Usage -| __Key Purpose__ | __OID__ | __Presence__ | +| **Key Purpose** | **OID** | **Presence** | | ---- | ---- | -- | | Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST | | Any other value | - | MUST NOT | @@ -2449,7 +2449,7 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will be used to issue TLS certificates directly or transitively. -| __Field__ | __Description__ | +| **Field** | **Description** | | ---- | ------ | | `tbsCertificate` | | |     `version` | MUST be v3(2) | @@ -2467,7 +2467,7 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be ##### 7.1.2.5.1 Technically Constrained TLS Subordinate CA Extensions -| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| **Extension** | **Presence** | **Critical** | **Description** | | ---- | -- | -- | -- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | @@ -2487,7 +2487,7 @@ For a TLS Subordinate CA to be Technically Constrained, Name Constraints extensi Table: `nameConstraints` requirements -| __Field__ | __Description__ | +| **Field** | **Description** | | ---- | ------ | | `permittedSubtrees` | The `permittedSubtrees` MUST contain at least one `GeneralSubtree` for both of the `dNSName` and `iPAddress` `GeneralName` name types, UNLESS the specified `GeneralName` name type appears within the `excludedSubtrees` to exclude all names of that name type. Additionally, the `permittedSubtrees` MUST contain at least one `GeneralSubtree` of the `directoryName` `GeneralName` name type. | |     `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | @@ -2504,7 +2504,7 @@ The following table contains the requirements for the `GeneralName` that appears Table: `GeneralName` requirements for the `base` field -| __Name Type__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | __Entire Namespace Exclusion__ | +| **Name Type** | **Presence** | **Permitted Subtrees** | **Excluded Subtrees** | **Entire Namespace Exclusion** | | --------------- | ------------- | ----------------------- | ------------------------ | ------------------------ | | `dNSName` | MUST | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | If no `dNSName` instance is present in the `permittedSubtrees`, then the CA MUST include a zero-length `dNSName` to indicate no domain names are permitted. | | `iPAddress` | MUST | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the assignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | If no IPv4 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 8 zero octets, indicating the IPv4 range of 0.0.0.0/0 being excluded. If no IPv6 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 32 zero octets, indicating the IPv6 range of ::0/0 being excluded. | @@ -2524,7 +2524,7 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in #### 7.1.2.6 TLS Subordinate CA Certificate Profile -| __Field__ | __Description__ | +| **Field** | **Description** | | ---- | ------ | | `tbsCertificate` | | |     `version` | MUST be v3(2) | @@ -2542,7 +2542,7 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in ##### 7.1.2.6.1 TLS Subordinate CA Extensions -| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| **Extension** | **Presence** | **Critical** | **Description** | | --- | -- | -- | --- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | @@ -2558,7 +2558,7 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in #### 7.1.2.7 Subscriber (Server) Certificate Profile -| __Field__ | __Description__ | +| **Field** | **Description** | | ---- | ------ | | `tbsCertificate` | | |     `version` | MUST be v3(2) | @@ -2580,7 +2580,7 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in There are four types of Subscriber Certificates that may be issued, which vary based on the amount of Subject Information that is included. Each of these certificate types shares a common profile, with three exceptions: the `subject` name fields that may occur, how those fields are validated, and the contents of the `certificatePolicies` extension. -| __Type__ | __Description__ | +| **Type** | **Description** | | ---- | ------ | | Domain Validated (DV) | See [Section 7.1.2.7.2](#71272-domain-validated) | | Individual Validated (IV) | See [Section 7.1.2.7.3](#71273-individual-validated) | @@ -2593,7 +2593,7 @@ There are four types of Subscriber Certificates that may be issued, which vary b For a Subscriber Certificate to be Domain Validated, it MUST meet the following profile: -| __Field__ | __Requirements__ | +| **Field** | **Requirements** | | --- | ------- | | `subject` | See following table. | | `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.1` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). | @@ -2605,7 +2605,7 @@ The following table details the acceptable `AttributeType`s that may appear with Table: Domain Validated `subject` Attributes -| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | +| **Attribute Name** | **Presence** | **Value** | **Verification** | | -- | --- | --- | -- | | `countryName` | MAY | The two-letter ISO 3166-1 country code for the country associated with the Subject. | [Section 3.2.2.3](#3223-verification-of-country) | | `commonName` | NOT RECOMMENDED | If present, MUST contain a value derived from the `subjectAltName` extension according to [Section 7.1.4.3](#7143-subscriber-certificate-common-name-attribute). | | @@ -2615,7 +2615,7 @@ Table: Domain Validated `subject` Attributes For a Subscriber Certificate to be Individual Validated, it MUST meet the following profile: -| __Field__ | __Requirements__ | +| **Field** | **Requirements** | | -- | ------- | | `subject` | See following table. | | `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.3` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). | @@ -2627,7 +2627,7 @@ The following table details the acceptable `AttributeType`s that may appear with Table: Individual Validated `subject` Attributes -| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | +| **Attribute Name** | **Presence** | **Value** | **Verification** | | --- | -- | --- | -- | | `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.3](#323-authentication-of-individual-identity) | @@ -2647,7 +2647,7 @@ In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '- For a Subscriber Certificate to be Organization Validated, it MUST meet the following profile: -| __Field__ | __Requirements__ | +| **Field** | **Requirements** | | --- | ------- | | `subject` | See following table. | | `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.2` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). | @@ -2659,7 +2659,7 @@ The following table details the acceptable `AttributeType`s that may appear with Table: Organization Validated `subject` Attributes -| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | +| **Attribute Name** | **Presence** | **Value** | **Verification** | | --- | -- | --- | -- | | `domainComponent` | MAY | If present, this field MUST contain a Domain Label from a Domain Name. The `domainComponent` fields for the Domain Name MUST be in a single ordered sequence containing all Domain Labels from the Domain Name. The Domain Labels MUST be encoded in the reverse order to the on-wire representation of domain names in the DNS protocol, so that the Domain Label closest to the root is encoded first. Multiple instances MAY be present. | [Section 3.2] | `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.2.1](#3221-identity) | @@ -2681,7 +2681,7 @@ In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '- For a Subscriber Certificate to be Extended Validation, it MUST comply with the Certificate Profile specified in the then-current version of the Guidelines for the Issuance and Management of Extended Validation Certificates. In addition, it MUST meet the following profile: -| __Field__ | __Requirements__ | +| **Field** | **Requirements** | | --- | ------- | | `subject` | See Guidelines for the Issuance and Management of Extended Validation Certificates, Section 7.1.4.2. | | `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.1` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). | @@ -2691,7 +2691,7 @@ In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '- ##### 7.1.2.7.6 Subscriber Certificate Extensions -| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| **Extension** | **Presence** | **Critical** | **Description** | | --------------------------------- | ----------- | ------------ | -------------------------------------- | | `authorityInformationAccess` | MUST | N | See [Section 7.1.2.7.7](#71277-subscriber-certificate-authority-information-access) | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | @@ -2716,7 +2716,7 @@ The `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. E The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. -| __Access Method__ | __OID__ | __Access Location__ | __Presence__ | __Maximum__ | __Description__ | +| **Access Method** | **OID** | **Access Location** | **Presence** | **Maximum** | **Description** | | -- | -- | --- | -- | -- | --- | | `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. | | `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | SHOULD | \* | A HTTP URL of the Issuing CA's certificate. | @@ -2724,7 +2724,7 @@ The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with t ##### 7.1.2.7.8 Subscriber Certificate Basic Constraints -| __Field__ | __Description__ | +| **Field** | **Description** | | --- | ------- | | `cA` | MUST be FALSE | | `pathLenConstraint` | MUST NOT be present | @@ -2733,7 +2733,7 @@ The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with t If present, the Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile: -| __Field__ | __Presence__ | __Contents__ | +| **Field** | **Presence** | **Contents** | | --- | -- | ----- | | `policyIdentifier` | MUST | One of the following policy identifiers: | |     A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)). | @@ -2747,7 +2747,7 @@ This Profile RECOMMENDS that the first `PolicyInformation` value within the Cert Table: Permitted `policyQualifiers` -| __Qualifier ID__ | __Presence__ | __Field Type__ | __Contents__ | +| **Qualifier ID** | **Presence** | **Field Type** | **Contents** | | --- | -- | -- | --- | | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | @@ -2756,7 +2756,7 @@ Table: Permitted `policyQualifiers` ##### 7.1.2.7.10 Subscriber Certificate Extended Key Usage -| __Key Purpose__ | __OID__ | __Presence__ | +| **Key Purpose** | **OID** | **Presence** | | ---- | ---- | -- | | `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST | | `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | @@ -2774,7 +2774,7 @@ The acceptable Key Usage values vary based on whether the Certificate's `subject Table: Key Usage for RSA Public Keys -| __Key Usage__ | __Permitted__ | __Required__ | +| **Key Usage** | **Permitted** | **Required** | | ----- | -- | --- | | `digitalSignature` | Y | SHOULD | | `nonRepudiation` | N | -- | @@ -2790,7 +2790,7 @@ Table: Key Usage for RSA Public Keys Table: Key Usage for ECC Public Keys -| __Key Usage__ | __Permitted__ | __Required__ | +| **Key Usage** | **Permitted** | **Required** | | ----- | -- | --- | | `digitalSignature` | Y | MUST | | `nonRepudiation` | N | -- | @@ -2812,7 +2812,7 @@ If the `subject` field of the certificate is an empty SEQUENCE, this extension M Table: `GeneralName` within a `subjectAltName` extension -| __Name Type__ | __Permitted__ | __Validation__ | +| **Name Type** | **Permitted** | **Validation** | | --- | -- | ----- | | `otherName` | N | - | | `rfc822Name` | N | - | @@ -2830,7 +2830,7 @@ Table: `GeneralName` within a `subjectAltName` extension If the Issuing CA does not directly sign OCSP responses, it MAY make use of an OCSP Authorized Responder, as defined by [RFC 6960](https://tools.ietf.org/html/rfc6960#section-4.2.2.2). The Issuing CA of the Responder MUST be the same as the Issuing CA for the Certificates it provides responses for. -| __Field__ | __Description__ | +| **Field** | **Description** | | --- | ------ | | `tbsCertificate` | | |     `version` | MUST be v3(2) | @@ -2848,14 +2848,14 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O ##### 7.1.2.8.1 OCSP Responder Validity -| __Field__ | __Minimum__ | __Maximum__ | +| **Field** | **Minimum** | **Maximum** | | -- | ---- | ---- | | `notBefore` | One day prior to the time of signing | The time of signing | | `notAfter` | The time of signing | Unspecified | ##### 7.1.2.8.2 OCSP Responder Extensions -| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| **Extension** | **Presence** | **Critical** | **Description** | | --- | -- | -- | --- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `extKeyUsage` | MUST | - | See [Section 7.1.2.8.5](#71285-ocsp-responder-extended-key-usage) | @@ -2877,7 +2877,7 @@ For OCSP Responder certificates, this extension is NOT RECOMMENDED, as the Relyi If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `AuthorityInfoAccessSyntax` MUST contain all required `AccessDescription`s. -| __Access Method__ | __OID__ | __Access Location__ | __Presence__ | __Maximum__ | __Description__ | +| **Access Method** | **OID** | **Access Location** | **Presence** | **Maximum** | **Description** | | - | - | -- | -- | - | --- | | `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | NOT RECOMMENDED | \* | A HTTP URL of the Issuing CA's OCSP responder. | | Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | @@ -2886,7 +2886,7 @@ If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDesc OCSP Responder certificates MUST NOT be CA certificates. The issuing CA may indicate this one of two ways: by omission of the `basicConstraints` extension, or through the inclusion of a `basicConstraints` extension that sets the `cA` boolean to FALSE. -| __Field__ | __Description__ | +| **Field** | **Description** | | --- | ------- | | `cA` | MUST be FALSE | | `pathLenConstraint` | MUST NOT be present | @@ -2895,7 +2895,7 @@ OCSP Responder certificates MUST NOT be CA certificates. The issuing CA may indi ##### 7.1.2.8.5 OCSP Responder Extended Key Usage -| __Key Purpose__ | __OID__ | __Presence__ | +| **Key Purpose** | **OID** | **Presence** | | ---- | ---- | -- | | `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST | | Any other value | - | MUST NOT | @@ -2908,7 +2908,7 @@ This extension MUST have an `extnValue` `OCTET STRING` which is exactly the hex- ##### 7.1.2.8.7 OCSP Responder Key Usage -| __Key Usage__ | __Permitted__ | __Required__ | +| **Key Usage** | **Permitted** | **Required** | | ------ | -- | -- | | `digitalSignature` | Y | Y | | `nonRepudiation` | N | -- | @@ -2924,7 +2924,7 @@ This extension MUST have an `extnValue` `OCTET STRING` which is exactly the hex- If present, the Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile: -| __Field__ | __Presence__ | __Contents__ | +| **Field** | **Presence** | **Contents** | | --- | -- | ----- | | `policyIdentifier` | MUST | One of the following policy identifiers: | |     A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | NOT RECOMMENDED | | @@ -2935,7 +2935,7 @@ If present, the Certificate Policies extension MUST contain at least one `Policy Table: Permitted `policyQualifiers` -| __Qualifier ID__ | __Presence__ | __Field Type__ | __Contents__ | +| **Qualifier ID** | **Presence** | **Field Type** | **Contents** | | --- | -- | -- | --- | | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | @@ -2957,7 +2957,7 @@ A Precertificate may be issued either directly by the Issuing CA or by a Technic Table: When the Precertificate is issued directly by the Issuing CA -| __Field__ | __Description__ | +| **Field** | **Description** | | ---- | ------ | | `tbsCertificate` | | |     `version` | Encoded value MUST be byte-for-byte identical to the `version` field of the Certificate | @@ -2976,7 +2976,7 @@ Table: When the Precertificate is issued directly by the Issuing CA Table: When the Precertificate is issued by a Precertificate Signing CA on behalf of an Issuing CA -| __Field__ | __Description__ | +| **Field** | **Description** | | --- | ------ | | `tbsCertificate` | | |     `version` | Encoded value MUST be byte-for-byte identical to the `version` field of the Certificate | @@ -2998,7 +2998,7 @@ Table: When the Precertificate is issued by a Precertificate Signing CA on behal These extensions apply in the context of a Precertificate directly issued from a CA, and not from a Precertificate Signing CA Certificate, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile). -| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| **Extension** | **Presence** | **Critical** | **Description** | | ---- | - | - | ---- | | Precertificate Poison (OID: 1.3.6.1.4.1.11129.2.4.3) | MUST | Y | See [Section 7.1.2.9.3](#71293-precertificate-poison) | | Signed Certificate Timestamp List | MUST NOT | - | | @@ -3010,7 +3010,7 @@ These extensions apply in the context of a Precertificate directly issued from a These extensions apply in the context of a Precertificate from a Precertificate Signing CA Certificate, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile). For such Precertificates, the `authorityKeyIdentifier`, if present in the Certificate, is modified in the Precertificate, as described in [RFC 6962, Section 3.2](https://tools.ietf.org/doc/html/rfc6962#section-3.2). -| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| **Extension** | **Presence** | **Critical** | **Description** | | ---- | - | - | ---- | | Precertificate Poison (OID: 1.3.6.1.4.1.11129.2.4.3) | MUST | Y | See [Section 7.1.2.9.3](#71293-precertificate-poison) | | `authorityKeyIdentifier` | \* | \* | See [Section 7.1.2.9.4](#71294-precertificate-authority-key-identifier) | @@ -3031,7 +3031,7 @@ For Precertificates issued by a Precertificate Signing CA, the contents of the ` 2. MAY be byte-for-byte identical with the contents of the `authorityKeyIdentifier` extension of the corresponding Certificate. -| __Field__ | __Description__ | +| **Field** | **Description** | | --- | ------- | | `keyIdentifier` | MUST be present. MUST be identical to the `subjectKeyIdentifier` field of the [Precertificate Signing CA Certificate](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) | | `authorityCertIssuer` | MUST NOT be present | @@ -3046,7 +3046,7 @@ This section contains several fields that are common among multiple CA Certifica ##### 7.1.2.10.1 CA Certificate Validity -| __Field__ | __Minimum__ | __Maximum__ | +| **Field** | **Minimum** | **Maximum** | | -- | ---- | ---- | | `notBefore` | One day prior to the time of signing | The time of signing | | `notAfter` | The time of signing | Unspecified | @@ -3057,7 +3057,7 @@ All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-fo The following table details the acceptable `AttributeType`s that may appear within the `type` field of an `AttributeTypeAndValue`, as well as the contents permitted within the `value` field. -| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | +| **Attribute Name** | **Presence** | **Value** | **Verification** | | --- | -- | ---- | - | | `countryName` | MUST | The two-letter ISO 3166-1 country code for the country in which the CA's place of business is located. | [Section 3.2.2.3](#3223-verification-of-country) | | `stateOrProvinceName` | MAY | If present, the CA's state or province information. | [Section 3.2.2.1](#3221-identity) | @@ -3075,7 +3075,7 @@ If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDesc The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. -| __Access Method__ | __OID__ | __Access Location__ | __Presence__ | __Maximum__ | __Description__ | +| **Access Method** | **OID** | **Access Location** | **Presence** | **Maximum** | **Description** | | - | - | --- | - | - | --- | | `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. | | `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's certificate. | @@ -3083,7 +3083,7 @@ The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with t ##### 7.1.2.10.4 CA Certificate Basic Constraints -| __Field__ | __Description__ | +| **Field** | **Description** | | --- | ------- | | `cA` | MUST be set TRUE | | `pathLenConstraint` | MAY be present | @@ -3095,7 +3095,7 @@ If present, the Certificate Policies extension MUST contain at least one `Policy Table: No Policy Restrictions (Affiliated CA) -| __Field__ | __Presence__ | __Contents__ | +| **Field** | **Presence** | **Contents** | | --- | -- | ----- | | `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, and if the Subordinate CA is an Affiliate of the Issuing CA, then the Issuing CA MAY use the `anyPolicy` Policy Identifier, which MUST be the only `PolicyInformation` value. | |     `anyPolicy` | MUST | | @@ -3104,7 +3104,7 @@ Table: No Policy Restrictions (Affiliated CA) Table: Policy Restricted -| __Field__ | __Presence__ | __Contents__ | +| **Field** | **Presence** | **Contents** | | --- | -- | ----- | | `policyIdentifier` | MUST | One of the following policy identifiers: | |     A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The CA MUST include exactly one Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)) directly or transitively issued by this Certificate. | @@ -3124,14 +3124,14 @@ If the `policyQualifiers` is permitted and present within a `PolicyInformation` Table: Permitted `policyQualifiers` -| __Qualifier ID__ | __Presence__ | __Field Type__ | __Contents__ | +| **Qualifier ID** | **Presence** | **Field Type** | **Contents** | | --- | - | - | ----- | | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | ##### 7.1.2.10.6 CA Certificate Extended Key Usage -| __Key Purpose__ | __OID__ | __Presence__ | +| **Key Purpose** | **OID** | **Presence** | | ---- | ---- | -- | | `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST | | `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | @@ -3145,7 +3145,7 @@ Table: Permitted `policyQualifiers` ##### 7.1.2.10.7 CA Certificate Key Usage -| __Key Usage__ | __Permitted__ | __Required__ | +| **Key Usage** | **Permitted** | **Required** | | ---- | - | - | | `digitalSignature` | Y | N[^ocsp_signing] | | `nonRepudiation` | N | -- | @@ -3166,7 +3166,7 @@ If present, the Name Constraints extension MUST be encoded as follows. As an exp Table: `nameConstraints` requirements -| __Field__ | __Description__ | +| **Field** | **Description** | | --- | ------- | | `permittedSubtrees` | | |   `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | @@ -3183,7 +3183,7 @@ The following table contains the requirements for the `GeneralName` that appears Table: `GeneralName` requirements for the `base` field -| __Name Type__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | +| **Name Type** | **Presence** | **Permitted Subtrees** | **Excluded Subtrees** | | --- | -- | --- | -- | | `dNSName` | MAY | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | | `iPAddress` | MAY | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the assignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | @@ -3208,7 +3208,7 @@ This section contains several fields that are common among multiple certificate ##### 7.1.2.11.1 Authority Key Identifier -| __Field__ | __Description__ | +| **Field** | **Description** | | --- | ------- | | `keyIdentifier` | MUST be present. MUST be identical to the `subjectKeyIdentifier` field of the Issuing CA. | | `authorityCertIssuer` | MUST NOT be present | @@ -3237,7 +3237,7 @@ When present, the CRL Distribution Points extension MUST contain at least one `D Table: `DistributionPoint` profile -| __Field__ | __Presence__ | __Description__ | +| **Field** | **Presence** | **Description** | | --- | -- | ----- | | `distributionPoint` | MUST | The `DistributionPointName` MUST be a `fullName` formatted as described below. | | `reasons` | MUST NOT | | @@ -3423,7 +3423,7 @@ CAs that include attributes in the Certificate `subject` field that are listed i Table: Encoding and Order Requirements for Selected Attributes -| __Attribute__ | __OID__ | __Specification__ | __Encoding Requirements__ | __Max Length[^maxlength]__ | +| **Attribute** | **OID** | **Specification** | **Encoding Requirements** | **Max Length[^maxlength]** | | ---- | -- | --- | ---- | - | | `domainComponent` | `0.9.2342.19200300.100.1.25` | [RFC 4519](https://tools.ietf.org/html/rfc4519) | MUST use `IA5String` | 63 | | `countryName` | `2.5.4.6` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 2 | @@ -3443,7 +3443,7 @@ CAs that include attributes in the Certificate `subject` field that are listed i Table: Encoding Requirements for Selected Attributes -| __Attribute__ | __OID__ | __Specification__ | __Encoding Requirements__ | __Max Length[^maxlength]__ | +| **Attribute** | **OID** | **Specification** | **Encoding Requirements** | **Max Length[^maxlength]** | | ---- | -- | --- | ---- | - | | `businessCategory` | `2.5.4.15` | X.520 | MUST use `UTF8String` or `PrintableString` | 128 | | `jurisdictionCountry` | `1.3.6.1.4.1.311.60.2.1.3` | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `PrintableString` | 2 | @@ -3509,7 +3509,7 @@ CAs MUST NOT issue indirect CRLs (i.e., the issuer of the CRL is not the issuer Table: CRL Fields -| __Field__ | __Presence__ | __Description__ | +| **Field** | **Presence** | **Description** | | --- | -- | ----- | | `tbsCertList` | | | |     `version` | MUST | MUST be v2(1), see [Section 7.2.1](#721-version-numbers) | @@ -3531,7 +3531,7 @@ Certificate Revocation Lists MUST be of type X.509 v2. Table: CRL Extensions -| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| **Extension** | **Presence** | **Critical** | **Description** | | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `CRLNumber` | MUST | N | MUST contain an INTEGER greater than or equal to zero (0) and less than 2¹⁵⁹, and convey a strictly increasing sequence. | @@ -3540,7 +3540,7 @@ Table: CRL Extensions Table: revokedCertificates Component -| __Component__ | __Presence__ | __Description__ | +| **Component** | **Presence** | **Description** | | ---- | - | ----- | | `serialNumber` | MUST | MUST be byte-for-byte identical to the serialNumber contained in the revoked Certificate. | | `revocationDate` | MUST | Normally, the date and time revocation occurred. See the footnote following this table for circumstances where backdating is permitted. | @@ -3550,14 +3550,14 @@ Table: revokedCertificates Component Table: crlEntryExtensions Component -| __CRL Entry Extension__ | __Presence__ | __Description__ | +| **CRL Entry Extension** | **Presence** | **Description** | | --- | -- | ----- | | `reasonCode` | * | When present (OID 2.5.29.21), MUST NOT be marked critical and MUST indicate the most appropriate reason for revocation of the Certificate.

MUST be present unless the CRL entry is for a Certificate not technically capable of causing issuance and either 1) the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to July 15, 2023 or 2) the reason for revocation (i.e., reasonCode) is unspecified (0).

See the "CRLReasons" table for additional requirements. | | Any other value | NOT RECOMMENDED | - | Table: CRLReasons -| __RFC 5280 reasonCode__ | __RFC 5280 reasonCode value__ | __Description__ | +| **RFC 5280 reasonCode** | **RFC 5280 reasonCode value** | **Description** | | --- | - | ------ | | unspecified | 0 | Represented by the omission of a reasonCode. MUST be omitted if the CRL entry is for a Certificate not technically capable of causing issuance unless the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to July 15, 2023. | keyCompromise | 1 | Indicates that it is known or suspected that the Subscriber’s Private Key has been compromised. | From 4e5539ad2281f3842ceaa1443d6f448d1ba35101 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Sat, 22 Nov 2025 13:09:26 +0100 Subject: [PATCH 026/121] #432 bold changed from __ to ** --- docs/EVG.md | 63 ++++++++++++++++++++++++++--------------------------- 1 file changed, 31 insertions(+), 32 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 4a35a7be..d8e95e2f 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -1272,16 +1272,16 @@ If a CA includes an extension in a certificate that has a Certificate field whic #### 7.1.2.1 Subject Alternative Name Extension -__Certificate Field__: `subjectAltName:dNSName` -__Required/Optional__: __Required__ -__Contents__: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This extension MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. +**Certificate Field**: `subjectAltName:dNSName` +**Required/Optional**: **Required** +**Contents**: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This extension MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. #### 7.1.2.2 CA/Browser Forum Organization Identifier Extension -__Extension Name__: `cabfOrganizationIdentifier` (OID: 2.23.140.3.1) -__Verbose OID__: `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-extensions(3) cabf-organization-identifier(1) }` -__Required/Optional__: __Optional (but see below)__ -__Contents__: If the subject:organizationIdentifier is present, this field MUST be present. +**Extension Name**: `cabfOrganizationIdentifier` (OID: 2.23.140.3.1) +**Verbose OID**: `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-extensions(3) cabf-organization-identifier(1) }` +**Required/Optional**: **Optional (but see below)** +**Contents**: If the subject:organizationIdentifier is present, this field MUST be present. If present, this extension MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. @@ -1322,9 +1322,9 @@ Subject to the requirements of these Guidelines, the EV Certificate and certific ##### 7.1.4.2.1 Subject Organization Name Field -__Certificate Field__: `subject:organizationName` (OID 2.5.4.10) -__Required/Optional__: Required -__Contents__: This field MUST contain the Subject's full legal organization name as listed in the official records of the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration or as otherwise verified by the CA as provided herein. A CA MAY abbreviate the organization prefixes or suffixes in the organization name, e.g., if the official record shows "Company Name Incorporated" the CA MAY include "Company Name, Inc." +**Certificate Field**: `subject:organizationName` (OID 2.5.4.10) +**Required/Optional**: Required +**Contents**: This field MUST contain the Subject's full legal organization name as listed in the official records of the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration or as otherwise verified by the CA as provided herein. A CA MAY abbreviate the organization prefixes or suffixes in the organization name, e.g., if the official record shows "Company Name Incorporated" the CA MAY include "Company Name, Inc." When abbreviating a Subject's full legal name as allowed by this subsection, the CA MUST use abbreviations that are not misleading in the Jurisdiction of Incorporation or Registration. @@ -1334,19 +1334,19 @@ If the combination of names or the organization name by itself exceeds 64 charac ##### 7.1.4.2.2 Subject Common Name Field -__Certificate Field__: `subject:commonName` (OID: 2.5.4.3) -__Required/Optional__: Deprecated (Discouraged, but not prohibited) -__Contents__: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This field MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. +**Certificate Field**: `subject:commonName` (OID: 2.5.4.3) +**Required/Optional**: Deprecated (Discouraged, but not prohibited) +**Contents**: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This field MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. ##### 7.1.4.2.3 Subject Business Category Field -__Certificate Field__: `subject:businessCategory` (OID: 2.5.4.15) -__Required/Optional__: Required -__Contents__: This field MUST contain one of the following strings: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity" depending upon whether the Subject qualifies under the terms of [Section 4.1.1.1](#4111-private-organization-subjects), [Section 4.1.1.2](#4112-government-entity-subjects), [Section 4.1.1.3](#4113-business-entity-subjects) or [Section 4.1.1.4](#4114-non-commercial-entity-subjects), respectively. +**Certificate Field**: `subject:businessCategory` (OID: 2.5.4.15) +**Required/Optional**: Required +**Contents**: This field MUST contain one of the following strings: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity" depending upon whether the Subject qualifies under the terms of [Section 4.1.1.1](#4111-private-organization-subjects), [Section 4.1.1.2](#4112-government-entity-subjects), [Section 4.1.1.3](#4113-business-entity-subjects) or [Section 4.1.1.4](#4114-non-commercial-entity-subjects), respectively. ##### 7.1.4.2.4 Subject Jurisdiction of Incorporation or Registration Field -__Certificate Fields__: +**Certificate Fields**: Locality (if required): `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1) @@ -1357,17 +1357,16 @@ State or province (if required): Country: `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) -__Required/Optional__: Required -__Contents__: These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. Country information MUST be specified using the applicable ISO country code. State or province or locality information (where applicable) for the Subject's Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction. +**Required/Optional**: Required +**Contents**: These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. Country information MUST be specified using the applicable ISO country code. State or province or locality information (where applicable) for the Subject's Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction. Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, the values within these fields have been disclosed within the latest publicly-available disclosure, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), as acceptable values for the applicable Incorporating Agency or Registration Agency. ##### 7.1.4.2.5 Subject Registration Number Field -__Certificate Field__: `subject:serialNumber` (OID: 2.5.4.5) -__Required/Optional__: __Required__ -__Contents__: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). - +**Certificate Field**: `subject:serialNumber` (OID: 2.5.4.5) +**Required/Optional**: **Required** +**Contents**: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). For Government Entities that do not have a Registration Number or readily verifiable date of creation, the CA SHALL enter appropriate language to indicate that the Subject is a Government Entity. For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). @@ -1376,25 +1375,25 @@ Effective as of 1 October 2020, if the CA has disclosed a set of acceptable form ##### 7.1.4.2.6 Subject Physical Address of Place of Business Field -__Certificate Fields__: +**Certificate Fields**: Number and street: `subject:streetAddress` (OID: 2.5.4.9) City or town: `subject:localityName` (OID: 2.5.4.7) State or province (where applicable): `subject:stateOrProvinceName` (OID: 2.5.4.8) Country: `subject:countryName` (OID: 2.5.4.6) Postal code: `subject:postalCode` (OID: 2.5.4.17) -__Required/Optional__: As stated in Section 7.1.4.2.2 d, e, f, g and h of the Baseline Requirements. -__Contents__: This field MUST contain the address of the physical location of the Subject's Place of Business. +**Required/Optional**: As stated in Section 7.1.4.2.2 d, e, f, g and h of the Baseline Requirements. +**Contents**: This field MUST contain the address of the physical location of the Subject's Place of Business. ##### 7.1.4.2.7 Subject Organizational Unit Name Field -__Certificate Field__: `subject:organizationalUnitName` (OID: 2.5.4.11) -__Required/Optional/Prohibited:__ __Prohibited__. +**Certificate Field**: `subject:organizationalUnitName` (OID: 2.5.4.11) +**Required/Optional/Prohibited**: **Prohibited**. ##### 7.1.4.2.8 Subject Organization Identifier Field -__Certificate Field__: `subject:organizationIdentifier` (OID: 2.5.4.97) -__Required/Optional__: Optional -__Contents__: If present, this field MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. +**Certificate Field**: `subject:organizationIdentifier` (OID: 2.5.4.97) +**Required/Optional**: Optional +**Contents**: If present, this field MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. The organizationIdentifier MUST be encoded as a PrintableString or UTF8String. @@ -1648,7 +1647,7 @@ The CA MUST host test Web pages that allow Application Software Suppliers to tes | Client Representative: | **(Exact name of Client Representative who signed the Application – see footnote 2)** | | Application Date: | **(Insert date of Client's Application to the Issuing CA)** | -This firm represents _[__exact__ company name of Client]_ [^1] ("Client"), who has submitted the Application to you dated as of the Application Date shown above ("Application"). We have been asked by our Client to present you with our opinion as stated in this letter. +This firm represents _[**exact** company name of Client]_ [^1] ("Client"), who has submitted the Application to you dated as of the Application Date shown above ("Application"). We have been asked by our Client to present you with our opinion as stated in this letter. [Insert customary preliminary matters for opinion letters in your jurisdiction.] From 6f5a1e79ee55cecd88571510408484583c9913bb Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Sat, 22 Nov 2025 13:41:58 +0100 Subject: [PATCH 027/121] #432 headers - double spaces --- docs/RFC3647_Template.md | 484 +++++++++++++++++++-------------------- 1 file changed, 242 insertions(+), 242 deletions(-) diff --git a/docs/RFC3647_Template.md b/docs/RFC3647_Template.md index d995ea84..92cd8892 100644 --- a/docs/RFC3647_Template.md +++ b/docs/RFC3647_Template.md @@ -1,97 +1,97 @@ -# 1. INTRODUCTION -## 1.1 Overview -## 1.2 Document name and identification -## 1.3 PKI participants -### 1.3.1 Certification authorities -### 1.3.2 Registration authorities -### 1.3.3 Subscribers +# 1. INTRODUCTION +## 1.1 Overview +## 1.2 Document name and identification +## 1.3 PKI participants +### 1.3.1 Certification authorities +### 1.3.2 Registration authorities +### 1.3.3 Subscribers ### 1.3.4 Relying parties -### 1.3.5 Other participants -## 1.4 Certificate usage -### 1.4.1 Appropriate certificate uses +### 1.3.5 Other participants +## 1.4 Certificate usage +### 1.4.1 Appropriate certificate uses ### 1.4.2 Prohibited certificate uses -## 1.5 Policy administration -### 1.5.1 Organization administering the document -### 1.5.2 Contact person -### 1.5.3 Person determining CPS suitability for the policy -### 1.5.4 CPS approval procedures -## 1.6 Definitions and acronyms +## 1.5 Policy administration +### 1.5.1 Organization administering the document +### 1.5.2 Contact person +### 1.5.3 Person determining CPS suitability for the policy +### 1.5.4 CPS approval procedures +## 1.6 Definitions and acronyms # 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES -## 2.1 Repositories -## 2.2 Publication of certification information -## 2.3 Time or frequency of publication -## 2.4 Access controls on repositories +## 2.1 Repositories +## 2.2 Publication of certification information +## 2.3 Time or frequency of publication +## 2.4 Access controls on repositories # 3. IDENTIFICATION AND AUTHENTICATION (11) -## 3.1 Naming -### 3.1.1 Types of names -### 3.1.2 Need for names to be meaningful -### 3.1.3 Anonymity or pseudonymity of subscribers -### 3.1.4 Rules for interpreting various name forms -### 3.1.5 Uniqueness of names -### 3.1.6 Recognition, authentication, and role of trademarks -## 3.2 Initial identity validation -### 3.2.1 Method to prove possession of private key -### 3.2.2 Authentication of organization identity -### 3.2.3 Authentication of individual identity -### 3.2.4 Non-verified subscriber information +## 3.1 Naming +### 3.1.1 Types of names +### 3.1.2 Need for names to be meaningful +### 3.1.3 Anonymity or pseudonymity of subscribers +### 3.1.4 Rules for interpreting various name forms +### 3.1.5 Uniqueness of names +### 3.1.6 Recognition, authentication, and role of trademarks +## 3.2 Initial identity validation +### 3.2.1 Method to prove possession of private key +### 3.2.2 Authentication of organization identity +### 3.2.3 Authentication of individual identity +### 3.2.4 Non-verified subscriber information ### 3.2.5 Validation of authority -### 3.2.6 Criteria for interoperation -## 3.3 Identification and authentication for re-key requests -### 3.3.1 Identification and authentication for routine re-key -### 3.3.2 Identification and authentication for re-key after revocation +### 3.2.6 Criteria for interoperation +## 3.3 Identification and authentication for re-key requests +### 3.3.1 Identification and authentication for routine re-key +### 3.3.2 Identification and authentication for re-key after revocation ## 3.4 Identification and authentication for revocation request -# 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS -## 4.1 Certificate Application -### 4.1.1 Who can submit a certificate application -### 4.1.2 Enrollment process and responsibilities +# 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS +## 4.1 Certificate Application +### 4.1.1 Who can submit a certificate application +### 4.1.2 Enrollment process and responsibilities ## 4.2 Certificate application processing ### 4.2.1 Performing identification and authentication functions ### 4.2.2 Approval or rejection of certificate applications -### 4.2.3 Time to process certificate applications -## 4.3 Certificate issuance -### 4.3.1 CA actions during certificate issuance -### 4.3.2 Notification to subscriber by the CA of issuance of certificate -## 4.4 Certificate acceptance -### 4.4.1 Conduct constituting certificate acceptance -### 4.4.2 Publication of the certificate by the CA -### 4.4.3 Notification of certificate issuance by the CA to other entities +### 4.2.3 Time to process certificate applications +## 4.3 Certificate issuance +### 4.3.1 CA actions during certificate issuance +### 4.3.2 Notification to subscriber by the CA of issuance of certificate +## 4.4 Certificate acceptance +### 4.4.1 Conduct constituting certificate acceptance +### 4.4.2 Publication of the certificate by the CA +### 4.4.3 Notification of certificate issuance by the CA to other entities ## 4.5 Key pair and certificate usage -### 4.5.1 Subscriber private key and certificate usage -### 4.5.2 Relying party public key and certificate usage -## 4.6 Certificate renewal -### 4.6.1 Circumstance for certificate renewal -### 4.6.2 Who may request renewal -### 4.6.3 Processing certificate renewal requests -### 4.6.4 Notification of new certificate issuance to subscriber -### 4.6.5 Conduct constituting acceptance of a renewal certificate -### 4.6.6 Publication of the renewal certificate by the CA -### 4.6.7 Notification of certificate issuance by the CA to other entities -## 4.7 Certificate re-key -### 4.7.1 Circumstance for certificate re-key -### 4.7.2 Who may request certification of a new public key -### 4.7.3 Processing certificate re-keying requests -### 4.7.4 Notification of new certificate issuance to subscriber -### 4.7.5 Conduct constituting acceptance of a re-keyed certificate -### 4.7.6 Publication of the re-keyed certificate by the CA -### 4.7.7 Notification of certificate issuance by the CA to other entities -## 4.8 Certificate modification -### 4.8.1 Circumstance for certificate modification -### 4.8.2 Who may request certificate modification -### 4.8.3 Processing certificate modification requests -### 4.8.4 Notification of new certificate issuance to subscriber -### 4.8.5 Conduct constituting acceptance of modified certificate -### 4.8.6 Publication of the modified certificate by the CA -### 4.8.7 Notification of certificate issuance by the CA to other entities -## 4.9 Certificate revocation and suspension -### 4.9.1 Circumstances for revocation -### 4.9.2 Who can request revocation -### 4.9.3 Procedure for revocation request -### 4.9.4 Revocation request grace period -### 4.9.5 Time within which CA must process the revocation request -### 4.9.6 Revocation checking requirement for relying parties +### 4.5.1 Subscriber private key and certificate usage +### 4.5.2 Relying party public key and certificate usage +## 4.6 Certificate renewal +### 4.6.1 Circumstance for certificate renewal +### 4.6.2 Who may request renewal +### 4.6.3 Processing certificate renewal requests +### 4.6.4 Notification of new certificate issuance to subscriber +### 4.6.5 Conduct constituting acceptance of a renewal certificate +### 4.6.6 Publication of the renewal certificate by the CA +### 4.6.7 Notification of certificate issuance by the CA to other entities +## 4.7 Certificate re-key +### 4.7.1 Circumstance for certificate re-key +### 4.7.2 Who may request certification of a new public key +### 4.7.3 Processing certificate re-keying requests +### 4.7.4 Notification of new certificate issuance to subscriber +### 4.7.5 Conduct constituting acceptance of a re-keyed certificate +### 4.7.6 Publication of the re-keyed certificate by the CA +### 4.7.7 Notification of certificate issuance by the CA to other entities +## 4.8 Certificate modification +### 4.8.1 Circumstance for certificate modification +### 4.8.2 Who may request certificate modification +### 4.8.3 Processing certificate modification requests +### 4.8.4 Notification of new certificate issuance to subscriber +### 4.8.5 Conduct constituting acceptance of modified certificate +### 4.8.6 Publication of the modified certificate by the CA +### 4.8.7 Notification of certificate issuance by the CA to other entities +## 4.9 Certificate revocation and suspension +### 4.9.1 Circumstances for revocation +### 4.9.2 Who can request revocation +### 4.9.3 Procedure for revocation request +### 4.9.4 Revocation request grace period +### 4.9.5 Time within which CA must process the revocation request +### 4.9.6 Revocation checking requirement for relying parties ### 4.9.7 CRL issuance frequency (if applicable) ### 4.9.8 Maximum latency for CRLs (if applicable) -### 4.9.9 On-line revocation/status checking availability +### 4.9.9 On-line revocation/status checking availability ### 4.9.10 On-line revocation checking requirements ### 4.9.11 Other forms of revocation advertisements available ### 4.9.12 Special requirements re key compromise @@ -99,172 +99,172 @@ ### 4.9.14 Who can request suspension ### 4.9.15 Procedure for suspension request ### 4.9.16 Limits on suspension period -## 4.10 Certificate status services +## 4.10 Certificate status services ### 4.10.1 Operational characteristics ### 4.10.2 Service availability ### 4.10.3 Optional features -## 4.11 End of subscription -## 4.12 Key escrow and recovery +## 4.11 End of subscription +## 4.12 Key escrow and recovery ### 4.12.1 Key escrow and recovery policy and practices ### 4.12.2 Session key encapsulation and recovery policy and practices -# 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS (11) -## 5.1 Physical controls -### 5.1.1 Site location and construction -### 5.1.2 Physical access -### 5.1.3 Power and air conditioning -### 5.1.4 Water exposures -### 5.1.5 Fire prevention and protection -### 5.1.6 Media storage -### 5.1.7 Waste disposal -### 5.1.8 Off-site backup -## 5.2 Procedural controls -### 5.2.1 Trusted roles -### 5.2.2 Number of persons required per task -### 5.2.3 Identification and authentication for each role -### 5.2.4 Roles requiring separation of duties -## 5.3 Personnel controls -### 5.3.1 Qualifications, experience, and clearance requirements -### 5.3.2 Background check procedures -### 5.3.3 Training requirements -### 5.3.4 Retraining frequency and requirements -### 5.3.5 Job rotation frequency and sequence -### 5.3.6 Sanctions for unauthorized actions -### 5.3.7 Independent contractor requirements -### 5.3.8 Documentation supplied to personnel -## 5.4 Audit logging procedures -### 5.4.1 Types of events recorded -### 5.4.2 Frequency of processing log -### 5.4.3 Retention period for audit log -### 5.4.4 Protection of audit log -### 5.4.5 Audit log backup procedures -### 5.4.6 Audit collection system (internal vs. external) -### 5.4.7 Notification to event-causing subject -### 5.4.8 Vulnerability assessments -## 5.5 Records archival -### 5.5.1 Types of records archived -### 5.5.2 Retention period for archive -### 5.5.3 Protection of archive -### 5.5.4 Archive backup procedures -### 5.5.5 Requirements for time-stamping of records -### 5.5.6 Archive collection system (internal or external) -### 5.5.7 Procedures to obtain and verify archive information -## 5.6 Key changeover -## 5.7 Compromise and disaster recovery -### 5.7.1 Incident and compromise handling procedures -### 5.7.2 Computing resources, software, and/or data are corrupted -### 5.7.3 Entity private key compromise procedures -### 5.7.4 Business continuity capabilities after a disaster -## 5.8 CA or RA termination -# 6. TECHNICAL SECURITY CONTROLS (11) -## 6.1 Key pair generation and installation -### 6.1.1 Key pair generation -### 6.1.2 Private key delivery to subscriber -### 6.1.3 Public key delivery to certificate issuer -### 6.1.4 CA public key delivery to relying parties -### 6.1.5 Key sizes -### 6.1.6 Public key parameters generation and quality checking -### 6.1.7 Key usage purposes (as per X.509 v3 key usage field) -## 6.2 Private Key Protection and Cryptographic Module Engineering Controls -### 6.2.1 Cryptographic module standards and controls -### 6.2.2 Private key (n out of m) multi-person control -### 6.2.3 Private key escrow -### 6.2.4 Private key backup -### 6.2.5 Private key archival -### 6.2.6 Private key transfer into or from a cryptographic module -### 6.2.7 Private key storage on cryptographic module -### 6.2.8 Method of activating private key -### 6.2.9 Method of deactivating private key +# 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS (11) +## 5.1 Physical controls +### 5.1.1 Site location and construction +### 5.1.2 Physical access +### 5.1.3 Power and air conditioning +### 5.1.4 Water exposures +### 5.1.5 Fire prevention and protection +### 5.1.6 Media storage +### 5.1.7 Waste disposal +### 5.1.8 Off-site backup +## 5.2 Procedural controls +### 5.2.1 Trusted roles +### 5.2.2 Number of persons required per task +### 5.2.3 Identification and authentication for each role +### 5.2.4 Roles requiring separation of duties +## 5.3 Personnel controls +### 5.3.1 Qualifications, experience, and clearance requirements +### 5.3.2 Background check procedures +### 5.3.3 Training requirements +### 5.3.4 Retraining frequency and requirements +### 5.3.5 Job rotation frequency and sequence +### 5.3.6 Sanctions for unauthorized actions +### 5.3.7 Independent contractor requirements +### 5.3.8 Documentation supplied to personnel +## 5.4 Audit logging procedures +### 5.4.1 Types of events recorded +### 5.4.2 Frequency of processing log +### 5.4.3 Retention period for audit log +### 5.4.4 Protection of audit log +### 5.4.5 Audit log backup procedures +### 5.4.6 Audit collection system (internal vs. external) +### 5.4.7 Notification to event-causing subject +### 5.4.8 Vulnerability assessments +## 5.5 Records archival +### 5.5.1 Types of records archived +### 5.5.2 Retention period for archive +### 5.5.3 Protection of archive +### 5.5.4 Archive backup procedures +### 5.5.5 Requirements for time-stamping of records +### 5.5.6 Archive collection system (internal or external) +### 5.5.7 Procedures to obtain and verify archive information +## 5.6 Key changeover +## 5.7 Compromise and disaster recovery +### 5.7.1 Incident and compromise handling procedures +### 5.7.2 Computing resources, software, and/or data are corrupted +### 5.7.3 Entity private key compromise procedures +### 5.7.4 Business continuity capabilities after a disaster +## 5.8 CA or RA termination +# 6. TECHNICAL SECURITY CONTROLS (11) +## 6.1 Key pair generation and installation +### 6.1.1 Key pair generation +### 6.1.2 Private key delivery to subscriber +### 6.1.3 Public key delivery to certificate issuer +### 6.1.4 CA public key delivery to relying parties +### 6.1.5 Key sizes +### 6.1.6 Public key parameters generation and quality checking +### 6.1.7 Key usage purposes (as per X.509 v3 key usage field) +## 6.2 Private Key Protection and Cryptographic Module Engineering Controls +### 6.2.1 Cryptographic module standards and controls +### 6.2.2 Private key (n out of m) multi-person control +### 6.2.3 Private key escrow +### 6.2.4 Private key backup +### 6.2.5 Private key archival +### 6.2.6 Private key transfer into or from a cryptographic module +### 6.2.7 Private key storage on cryptographic module +### 6.2.8 Method of activating private key +### 6.2.9 Method of deactivating private key ### 6.2.10 Method of destroying private key ### 6.2.11 Cryptographic Module Rating -## 6.3 Other aspects of key pair management -### 6.3.1 Public key archival -### 6.3.2 Certificate operational periods and key pair usage periods -## 6.4 Activation data -### 6.4.1 Activation data generation and installation -### 6.4.2 Activation data protection -### 6.4.3 Other aspects of activation data -## 6.5 Computer security controls -### 6.5.1 Specific computer security technical requirements -### 6.5.2 Computer security rating -## 6.6 Life cycle technical controls -### 6.6.1 System development controls -### 6.6.2 Security management controls -### 6.6.3 Life cycle security controls -## 6.7 Network security controls -## 6.8 Time-stamping -# 7. CERTIFICATE, CRL, AND OCSP PROFILES -## 7.1 Certificate profile -### 7.1.1 Version number(s) -### 7.1.2 Certificate extensions -### 7.1.3 Algorithm object identifiers -### 7.1.4 Name forms -### 7.1.5 Name constraints -### 7.1.6 Certificate policy object identifier -### 7.1.7 Usage of Policy Constraints extension -### 7.1.8 Policy qualifiers syntax and semantics +## 6.3 Other aspects of key pair management +### 6.3.1 Public key archival +### 6.3.2 Certificate operational periods and key pair usage periods +## 6.4 Activation data +### 6.4.1 Activation data generation and installation +### 6.4.2 Activation data protection +### 6.4.3 Other aspects of activation data +## 6.5 Computer security controls +### 6.5.1 Specific computer security technical requirements +### 6.5.2 Computer security rating +## 6.6 Life cycle technical controls +### 6.6.1 System development controls +### 6.6.2 Security management controls +### 6.6.3 Life cycle security controls +## 6.7 Network security controls +## 6.8 Time-stamping +# 7. CERTIFICATE, CRL, AND OCSP PROFILES +## 7.1 Certificate profile +### 7.1.1 Version number(s) +### 7.1.2 Certificate extensions +### 7.1.3 Algorithm object identifiers +### 7.1.4 Name forms +### 7.1.5 Name constraints +### 7.1.6 Certificate policy object identifier +### 7.1.7 Usage of Policy Constraints extension +### 7.1.8 Policy qualifiers syntax and semantics ### 7.1.9 Processing semantics for the critical Certificate Policies extension -## 7.2 CRL profile -### 7.2.1 Version number(s) -### 7.2.2 CRL and CRL entry extensions -## 7.3 OCSP profile -### 7.3.1 Version number(s) -### 7.3.2 OCSP extensions -# 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS -## 8.1 Frequency or circumstances of assessment -## 8.2 Identity/qualifications of assessor -## 8.3 Assessor's relationship to assessed entity -## 8.4 Topics covered by assessment -## 8.5 Actions taken as a result of deficiency -## 8.6 Communication of results -# 9. OTHER BUSINESS AND LEGAL MATTERS -## 9.1 Fees -### 9.1.1 Certificate issuance or renewal fees -### 9.1.2 Certificate access fees -### 9.1.3 Revocation or status information access fees -### 9.1.4 Fees for other services -### 9.1.5 Refund policy -## 9.2 Financial responsibility -### 9.2.1 Insurance coverage -### 9.2.2 Other assets -### 9.2.3 Insurance or warranty coverage for end-entities -## 9.3 Confidentiality of business information -### 9.3.1 Scope of confidential information -### 9.3.2 Information not within the scope of confidential information -### 9.3.3 Responsibility to protect confidential information -## 9.4 Privacy of personal information -### 9.4.1 Privacy plan -### 9.4.2 Information treated as private -### 9.4.3 Information not deemed private -### 9.4.4 Responsibility to protect private information -### 9.4.5 Notice and consent to use private information +## 7.2 CRL profile +### 7.2.1 Version number(s) +### 7.2.2 CRL and CRL entry extensions +## 7.3 OCSP profile +### 7.3.1 Version number(s) +### 7.3.2 OCSP extensions +# 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS +## 8.1 Frequency or circumstances of assessment +## 8.2 Identity/qualifications of assessor +## 8.3 Assessor's relationship to assessed entity +## 8.4 Topics covered by assessment +## 8.5 Actions taken as a result of deficiency +## 8.6 Communication of results +# 9. OTHER BUSINESS AND LEGAL MATTERS +## 9.1 Fees +### 9.1.1 Certificate issuance or renewal fees +### 9.1.2 Certificate access fees +### 9.1.3 Revocation or status information access fees +### 9.1.4 Fees for other services +### 9.1.5 Refund policy +## 9.2 Financial responsibility +### 9.2.1 Insurance coverage +### 9.2.2 Other assets +### 9.2.3 Insurance or warranty coverage for end-entities +## 9.3 Confidentiality of business information +### 9.3.1 Scope of confidential information +### 9.3.2 Information not within the scope of confidential information +### 9.3.3 Responsibility to protect confidential information +## 9.4 Privacy of personal information +### 9.4.1 Privacy plan +### 9.4.2 Information treated as private +### 9.4.3 Information not deemed private +### 9.4.4 Responsibility to protect private information +### 9.4.5 Notice and consent to use private information ### 9.4.6 Disclosure pursuant to judicial or administrative process -### 9.4.7 Other information disclosure circumstances -## 9.5 Intellectual property rights -## 9.6 Representations and warranties -### 9.6.1 CA representations and warranties -### 9.6.2 RA representations and warranties -### 9.6.3 Subscriber representations and warranties -### 9.6.4 Relying party representations and warranties -### 9.6.5 Representations and warranties of other participants -## 9.7 Disclaimers of warranties -## 9.8 Limitations of liability -## 9.9 Indemnities -## 9.10 Term and termination -### 9.10.1 Term -### 9.10.2 Termination -### 9.10.3 Effect of termination and survival -## 9.11 Individual notices and communications with participants -## 9.12 Amendments -### 9.12.1 Procedure for amendment -### 9.12.2 Notification mechanism and period -### 9.12.3 Circumstances under which OID must be changed -## 9.13 Dispute resolution provisions -## 9.14 Governing law -## 9.15 Compliance with applicable law -## 9.16 Miscellaneous provisions -### 9.16.1 Entire agreement -### 9.16.2 Assignment -### 9.16.3 Severability -### 9.16.4 Enforcement (attorneys' fees and waiver of rights) -### 9.16.5 Force Majeure -## 9.17 Other provisions +### 9.4.7 Other information disclosure circumstances +## 9.5 Intellectual property rights +## 9.6 Representations and warranties +### 9.6.1 CA representations and warranties +### 9.6.2 RA representations and warranties +### 9.6.3 Subscriber representations and warranties +### 9.6.4 Relying party representations and warranties +### 9.6.5 Representations and warranties of other participants +## 9.7 Disclaimers of warranties +## 9.8 Limitations of liability +## 9.9 Indemnities +## 9.10 Term and termination +### 9.10.1 Term +### 9.10.2 Termination +### 9.10.3 Effect of termination and survival +## 9.11 Individual notices and communications with participants +## 9.12 Amendments +### 9.12.1 Procedure for amendment +### 9.12.2 Notification mechanism and period +### 9.12.3 Circumstances under which OID must be changed +## 9.13 Dispute resolution provisions +## 9.14 Governing law +## 9.15 Compliance with applicable law +## 9.16 Miscellaneous provisions +### 9.16.1 Entire agreement +### 9.16.2 Assignment +### 9.16.3 Severability +### 9.16.4 Enforcement (attorneys' fees and waiver of rights) +### 9.16.5 Force Majeure +## 9.17 Other provisions From daf5502c5738f087d3173dd7c43b6c23c1d7896a Mon Sep 17 00:00:00 2001 From: dzacharo Date: Sun, 23 Nov 2025 12:00:13 +0200 Subject: [PATCH 028/121] Addresses #274. --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 031ac36b..a7264f4f 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -190,7 +190,7 @@ Certification Authority (CA) is defined in [Section 1.6](#16-definitions-and-acr ### 1.3.2 Registration Authorities -With the exception of [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) and [Section 3.2.2.5](#3225-authentication-for-an-ip-address), the CA MAY delegate the performance of all, or any part, of [Section 3.2](#32-initial-identity-validation) requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of [Section 3.2](#32-initial-identity-validation). +With the exception of [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control), [Section 3.2.2.5](#3225-authentication-for-an-ip-address) and (effective 2026-03-15) [Section 3.2.2.8](#3228-caa-records), the CA MAY delegate the performance of all, or any part, of [Section 3.2](#32-initial-identity-validation) requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of [Section 3.2](#32-initial-identity-validation). Before the CA authorizes a Delegated Third Party to perform a delegated function, the CA SHALL contractually require the Delegated Third Party to: From 8286dd0f6336e632ad387df79c06720a44fe271d Mon Sep 17 00:00:00 2001 From: dzacharo Date: Sun, 23 Nov 2025 13:00:45 +0200 Subject: [PATCH 029/121] Addresses #444 --- docs/BR.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/BR.md b/docs/BR.md index a7264f4f..16433157 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -3472,6 +3472,7 @@ Before including such an attribute, the CA SHALL: * Ensure that the contents contain information that has been verified by the CA, independent of the Applicant. ### 7.1.5 Name constraints +See Sections [7.1.2.5.2 Technically Constrained TLS Subordinate CA Name Constraints](#71252-technically-constrained-tls-subordinate-ca-name-constraints) and [7.1.2.10.8 CA Certificate Name Constraints](#712108-ca-certificate-name-constraints). ### 7.1.6 Certificate policy object identifier From f8e55be57fdaf6220cc57a71896a89c485cd65d9 Mon Sep 17 00:00:00 2001 From: dzacharo Date: Sun, 23 Nov 2025 13:06:14 +0200 Subject: [PATCH 030/121] Addresses #449 --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 16433157..3e0a3f0e 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1251,7 +1251,7 @@ Applicant information MUST include, but not be limited to, at least one Fully-Qu [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 within the maximum number of days prior to issuing the Certificate, as defined in the following table: +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, including validation of authority, 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 within the maximum number of days prior to issuing the Certificate, as defined in the following table: Table: Subject Identity Information validation data reuse periods From 949de23f584e51b85aa99f310dd159c0f1d804f2 Mon Sep 17 00:00:00 2001 From: dzacharo Date: Sun, 23 Nov 2025 13:16:22 +0200 Subject: [PATCH 031/121] Addresses #471 --- docs/EVG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/EVG.md b/docs/EVG.md index d8e95e2f..aa4384aa 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -1619,7 +1619,7 @@ A CA's indemnification obligations and a Root CA's obligations with respect to s ### 9.16.3 Severability The CA MAY issue EV Certificates, provided that the CA and its Root CA satisfy the requirements in these Guidelines and the Baseline Requirements. -If a court or government body with jurisdiction over the activities covered by these Guidelines determines that the performance of any mandatory requirement is illegal, then such requirement is considered reformed to the minimum extent necessary to make the requirement valid and legal. This applies only to operations or certificate issuances that are subject to the laws of that jurisdiction. The parties involved SHALL notify the CA/Browser Forum of the facts, circumstances, and law(s) involved, so that the CA/Browser Forum may revise these Guidelines accordingly. +Section 9.16.3 of the Baseline Requirements applies equally to EV Certificates. ### 9.16.4 Enforcement (attorneys' fees and waiver of rights) ### 9.16.5 Force Majeure From 968ca9a7ea626022d6342668640ef8cbfe1f85a8 Mon Sep 17 00:00:00 2001 From: dzacharo Date: Sun, 23 Nov 2025 20:14:06 +0200 Subject: [PATCH 032/121] Addresses #524 --- docs/BR.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 3e0a3f0e..ebff8f19 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -3612,8 +3612,6 @@ The CA SHALL at all times: 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) 319 411-1 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. - ## 8.1 Frequency or circumstances of assessment Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile), [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile), or [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), as well as audited in line with [Section 8.7](#87-self-audits) only, or Unconstrained and fully audited in line with all remaining requirements from this section. A Certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 `basicConstraints` extension, with the `cA` boolean set to true and is therefore by definition a Root CA Certificate or a Subordinate CA Certificate. From d18e330d97b707129f90fb27b38435063c542c3c Mon Sep 17 00:00:00 2001 From: dzacharo Date: Sun, 23 Nov 2025 20:33:05 +0200 Subject: [PATCH 033/121] Addresses #564 --- docs/BR.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index ebff8f19..43bd91ae 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -389,7 +389,9 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Parent Company**: A company that Controls a Subsidiary Company. -**Pending Prohibition​​**: The use of a behavior described with this label is highly discouraged, as it is planned to be deprecated and will likely be designated as MUST NOT in the future. +**Pending Prohibition**: The use of a behavior described with this label is highly discouraged, as it is planned to be deprecated and will likely be designated as MUST NOT in the future. + +**Precertificate**: A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by RFC 6962 and containing the critical poison extension (OID 1.3.6.1.4.1.11129.2.4.3). **Primary Network Perspective**: The Network Perspective used by the CA to make the determination of 1) the CA's authority to issue a Certificate for the requested domain(s) or IP address(es) and 2) the Applicant's authority and/or domain authorization or control of the requested domain(s) or IP address(es). From 458e5b77e8ccbe578cc0ff8d5d974736aa42e928 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Sun, 23 Nov 2025 21:01:18 +0100 Subject: [PATCH 034/121] #432 headers - double spaces --- docs/EVG.md | 515 ++++++++++++++++++++++++++-------------------------- 1 file changed, 258 insertions(+), 257 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index aa4384aa..f1d058c4 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -12,7 +12,8 @@ copyright: | This work is licensed under the Creative Commons Attribution 4.0 International license. --- -# 1. INTRODUCTION +# 1. INTRODUCTION + 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. @@ -25,15 +26,15 @@ The Guidelines for the Issuance and Management of Extended Validation Certificat The CA/Browser Forum is a voluntary open organization of certification authorities and suppliers of Internet browsers and other relying-party software applications. Membership is listed at . -## 1.1 Overview +## 1.1 Overview These Guidelines for the issuance and management of Extended Validation Certificates describe certain of the minimum requirements that a Certification Authority must meet in order to issue Extended Validation Certificates. Subject Organization information from Valid EV Certificates may be displayed 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 they are accessing. These Guidelines incorporate the Baseline Requirements established by the CA/Browser Forum by reference. A copy of the Baseline Requirements is available on the CA/Browser Forum's website at . These Guidelines address the basic issue of validating Subject identity information in EV Certificates and some related matters. They do not address all of the related matters, such as certain technical and operational ones. This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet. However, the Working Group encourages the re-use of these guidelines as a basis for similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. These Guidelines do not address the verification of information, or the issuance, use, maintenance, or revocation of EV Certificates by enterprises that operate their own Public Key Infrastructure for internal purposes only, where its Root CA Certificate is not distributed by any Application Software Supplier. -## 1.2 Document name and identification -### 1.2.1 Revisions +## 1.2 Document name and identification +### 1.2.1 Revisions | **Ver.** | **Ballot** | **Description** | **Adopted** | **Effective\*** | |-|-|-----|--|--| | 1.4.0 | 72 | Reorganize EV Documents | 29 May 2012 | 29 May 2012 | @@ -95,11 +96,11 @@ These Guidelines do not address the verification of information, or the issuance **Implementers' Note**: Version 1.3 of these EV Guidelines was published on 20 November 2010 and supplemented through May 2012 when version 1.4 was published. ETSI TS 102 042 and ETSI TR 101 564 Technical Report: Guidance on ETSI TS 102 042 for Issuing Extended Validation Certificates for Auditors and CSPs reference version 1.3 of these EV Guidelines, and ETSI Draft EN 319 411-1 references version 1.4. Version 1.4.5 of Webtrust(r) for Certification Authorities – Extended Validation Audit Criteria references version 1.4.5 of these EV Guidelines. As illustrated in the Document History table above, the CA/Browser Forum continues to improve relevant industry guidelines, including this document, the Baseline Requirements, and the Network and Certificate System Security Requirements. We encourage all CAs to conform to each revision 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. We will respond to implementation questions directed to questions@cabforum.org. 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. -## 1.3 PKI participants +## 1.3 PKI participants -### 1.3.1 Certification authorities +### 1.3.1 Certification authorities -### 1.3.2 Registration authorities +### 1.3.2 Registration authorities The CA MAY delegate the performance of all or any part of a requirement of these Guidelines to an Affiliate or a Registration Authority (RA) or subcontractor, provided that the process employed by the CA fulfills all of the requirements of [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence). Affiliates and/or RAs must comply with the qualification requirements of [Section 5.3.2](#532-background-check-procedures). @@ -107,7 +108,7 @@ The CA SHALL verify that the Delegated Third Party's personnel involved in the i In all cases, the CA MUST contractually obligate each Affiliate, RA, subcontractor, and Enterprise RA to comply with all applicable requirements in these Guidelines and to perform them as required of the CA itself. The CA SHALL enforce these obligations and internally audit each Affiliate's, RA's, subcontractor's, and Enterprise RA's compliance with these Requirements on an annual basis. -#### 1.3.2.1 Enterprise Registration authorities +#### 1.3.2.1 Enterprise Registration authorities 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; @@ -116,11 +117,11 @@ The CA MAY contractually authorize a Subscriber to perform the RA function and a Enterprise RAs that authorize the issuance of EV Certificates solely for its own organization are exempted from the audit requirements of [Section 8](#8-compliance-audit-and-other-assessments). In all other cases, the requirements of [Section 8](#8-compliance-audit-and-other-assessments) SHALL apply. -### 1.3.3 Subscribers +### 1.3.3 Subscribers ### 1.3.4 Relying parties -### 1.3.5 Other participants -## 1.4 Certificate usage -### 1.4.1 Appropriate certificate uses +### 1.3.5 Other participants +## 1.4 Certificate usage +### 1.4.1 Appropriate certificate uses EV Certificates are intended for establishing Web-based data communication conduits via the TLS/SSL protocols and for verifying the authenticity of executable code. #### 1.4.1.1 Primary Purposes @@ -147,15 +148,15 @@ EV Certificates focus only on the identity of the Subject named in the Certifica 3. That the Subject named in the EV Certificate is trustworthy, honest, or reputable in its business dealings; or 4. That it is "safe" to do business with the Subject named in the EV Certificate. -## 1.5 Policy administration -### 1.5.1 Organization administering the document -### 1.5.2 Contact person -### 1.5.3 Person determining CPS suitability for the policy -### 1.5.4 CPS approval procedures +## 1.5 Policy administration +### 1.5.1 Organization administering the document +### 1.5.2 Contact person +### 1.5.3 Person determining CPS suitability for the policy +### 1.5.4 CPS approval procedures -## 1.6 Definitions and acronyms +## 1.6 Definitions and acronyms -### 1.6.1 Definitions +### 1.6.1 Definitions Capitalized Terms are defined in the Baseline Requirements except where provided below: **Accounting Practitioner**: A certified public accountant, chartered accountant, or a person with an equivalent license within the country of the Applicant's Jurisdiction of Incorporation or Registration or any jurisdiction where the Applicant maintains an office or physical facility; provided that an accounting standards body in the jurisdiction maintains full (not "suspended" or "associate") membership status with the International Federation of Accountants. @@ -294,7 +295,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **WebTrust Seal of Assurance**: An affirmation of compliance resulting from the WebTrust Program for CAs. -### 1.6.2 Acronyms +### 1.6.2 Acronyms Abbreviations and Acronyms are defined in the Baseline Requirements except as otherwise defined herein: | **Acronym** | **Meaning** | @@ -319,10 +320,10 @@ Abbreviations and Acronyms are defined in the Baseline Requirements except as ot | SEC | (US Government) Securities and Exchange Commission | | UTC(k) | National realization of Coordinated Universal Time | -### 1.6.3 References +### 1.6.3 References See Baseline Requirements, which are available at . -### 1.6.4 Conventions +### 1.6.4 Conventions Terms not otherwise defined in these Guidelines shall be as defined in applicable agreements, user manuals, certification practice statements (CPS), and certificate policies (CP) of the CA issuing EV Certificates. The key words "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in these Guidelines shall be interpreted in accordance with RFC 2119. @@ -341,8 +342,8 @@ B. Implement the requirements of C. Specify the CA's and its Root CA's entire root certificate hierarchy including all roots that its EV Certificates depend on for proof of those EV Certificates' authenticity. -## 2.1 Repositories -## 2.2 Publication of certification information +## 2.1 Repositories +## 2.2 Publication of certification information Each CA MUST publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see [Section 8](#8-compliance-audit-and-other-assessments)). The CA's Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647. The Certificate Policy and/or Certification Practice Statement MUST include all material required by RFC 3647. @@ -353,18 +354,18 @@ Each CA SHALL publicly give effect to these Guidelines and represent that they w In addition, the CA MUST include (directly or by reference) the applicable requirements of these Guidelines in all contracts with Subordinate CAs, RAs, Enterprise RAs, and subcontractors that involve or relate to the issuance or maintenance of EV Certificates. The CA MUST enforce compliance with such terms. -## 2.3 Time or frequency of publication -## 2.4 Access controls on repositories +## 2.3 Time or frequency of publication +## 2.4 Access controls on repositories # 3. IDENTIFICATION AND AUTHENTICATION -## 3.1 Naming -### 3.1.1 Types of names -### 3.1.2 Need for names to be meaningful -### 3.1.3 Anonymity or pseudonymity of subscribers -### 3.1.4 Rules for interpreting various name forms -### 3.1.5 Uniqueness of names -### 3.1.6 Recognition, authentication, and role of trademarks +## 3.1 Naming +### 3.1.1 Types of names +### 3.1.2 Need for names to be meaningful +### 3.1.3 Anonymity or pseudonymity of subscribers +### 3.1.4 Rules for interpreting various name forms +### 3.1.5 Uniqueness of names +### 3.1.6 Recognition, authentication, and role of trademarks -## 3.2 Initial identity validation +## 3.2 Initial identity validation ### 3.2.1 Method to prove possession of private key @@ -936,22 +937,22 @@ A CA may rely on a previously verified certificate request to issue a replacemen 3. The CA MAY reuse a previously submitted EV Certificate Request, Subscriber Agreement, or Terms of Use, including use of a single EV Certificate Request in support of multiple EV Certificates containing the same Subject to the extent permitted under [Section 3.2.2.9](#3229-verification-of-signature-on-subscriber-agreement-and-ev-certificate-requests) and [Section 3.2.2.10](#32210-verification-of-approval-of-ev-certificate-request). 4. The CA MUST repeat the verification process required in these Guidelines for any information obtained outside the time limits specified above except when permitted otherwise under [Section 3.2.2.14.1](#322141-validation-for-existing-subscribers). -### 3.2.3 Authentication of individual identity -### 3.2.4 Non-verified subscriber information -### 3.2.5 Validation of authority -### 3.2.6 Criteria for interoperation +### 3.2.3 Authentication of individual identity +### 3.2.4 Non-verified subscriber information +### 3.2.5 Validation of authority +### 3.2.6 Criteria for interoperation -## 3.3 Identification and authentication for re-key requests -### 3.3.1 Identification and authentication for routine re-key -### 3.3.2 Identification and authentication for re-key after revocation +## 3.3 Identification and authentication for re-key requests +### 3.3.1 Identification and authentication for routine re-key +### 3.3.2 Identification and authentication for re-key after revocation ## 3.4 Identification and authentication for revocation request -# 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS +# 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS -## 4.1 Certificate Application +## 4.1 Certificate Application -### 4.1.1 Who can submit a certificate application +### 4.1.1 Who can submit a certificate application The CA MAY only issue EV Certificates to Applicants that meet the Private Organization, Government Entity, Business Entity and Non-Commercial Entity requirements specified below. #### 4.1.1.1 Private Organization Subjects @@ -1010,7 +1011,7 @@ An Applicant qualifies as a Non-Commercial Entity if: Subsidiary organizations or agencies of an entity that qualifies as a Non-Commercial Entity also qualifies for EV Certificates as a Non-Commercial Entity. -### 4.1.2 Enrollment process and responsibilities +### 4.1.2 Enrollment process and responsibilities The documentation requirements in Section 4.1.2 of the Baseline Requirements apply equally to EV Certificates. The Certificate Request requirements in Section 4.1.2 of the Baseline Requirements apply equally to EV Certificates subject to the additional more stringent ageing and updating requirement of [Section 3.2.2.14](#32214-requirements-for-re-use-of-existing-documentation). @@ -1033,63 +1034,63 @@ The following Applicant roles are required for the issuance of an EV Certificate The Applicant MAY authorize one individual to occupy two or more of these roles. The Applicant MAY authorize more than one individual to occupy any of these roles. ### 4.2.2 Approval or rejection of certificate applications -### 4.2.3 Time to process certificate applications +### 4.2.3 Time to process certificate applications -## 4.3 Certificate issuance +## 4.3 Certificate issuance -### 4.3.1 CA actions during certificate issuance +### 4.3.1 CA actions during certificate issuance Certificate issuance by the Root CA SHALL require an individual authorized by the CA (i.e. the CA system operator, system officer, or PKI administrator) to deliberately issue a direct command in order for the Root CA to perform a certificate signing operation. Root CA Private Keys MUST NOT be used to sign EV Certificates. -### 4.3.2 Notification to subscriber by the CA of issuance of certificate +### 4.3.2 Notification to subscriber by the CA of issuance of certificate -## 4.4 Certificate acceptance -### 4.4.1 Conduct constituting certificate acceptance -### 4.4.2 Publication of the certificate by the CA -### 4.4.3 Notification of certificate issuance by the CA to other entities +## 4.4 Certificate acceptance +### 4.4.1 Conduct constituting certificate acceptance +### 4.4.2 Publication of the certificate by the CA +### 4.4.3 Notification of certificate issuance by the CA to other entities ## 4.5 Key pair and certificate usage -### 4.5.1 Subscriber private key and certificate usage -### 4.5.2 Relying party public key and certificate usage - -## 4.6 Certificate renewal -### 4.6.1 Circumstance for certificate renewal -### 4.6.2 Who may request renewal -### 4.6.3 Processing certificate renewal requests -### 4.6.4 Notification of new certificate issuance to subscriber -### 4.6.5 Conduct constituting acceptance of a renewal certificate -### 4.6.6 Publication of the renewal certificate by the CA -### 4.6.7 Notification of certificate issuance by the CA to other entities - -## 4.7 Certificate re-key -### 4.7.1 Circumstance for certificate re-key -### 4.7.2 Who may request certification of a new public key -### 4.7.3 Processing certificate re-keying requests -### 4.7.4 Notification of new certificate issuance to subscriber -### 4.7.5 Conduct constituting acceptance of a re-keyed certificate -### 4.7.6 Publication of the re-keyed certificate by the CA -### 4.7.7 Notification of certificate issuance by the CA to other entities - -## 4.8 Certificate modification -### 4.8.1 Circumstance for certificate modification -### 4.8.2 Who may request certificate modification -### 4.8.3 Processing certificate modification requests -### 4.8.4 Notification of new certificate issuance to subscriber -### 4.8.5 Conduct constituting acceptance of modified certificate -### 4.8.6 Publication of the modified certificate by the CA -### 4.8.7 Notification of certificate issuance by the CA to other entities - -## 4.9 Certificate revocation and suspension -### 4.9.1 Circumstances for revocation -### 4.9.2 Who can request revocation -### 4.9.3 Procedure for revocation request -### 4.9.4 Revocation request grace period -### 4.9.5 Time within which CA must process the revocation request -### 4.9.6 Revocation checking requirement for relying parties +### 4.5.1 Subscriber private key and certificate usage +### 4.5.2 Relying party public key and certificate usage + +## 4.6 Certificate renewal +### 4.6.1 Circumstance for certificate renewal +### 4.6.2 Who may request renewal +### 4.6.3 Processing certificate renewal requests +### 4.6.4 Notification of new certificate issuance to subscriber +### 4.6.5 Conduct constituting acceptance of a renewal certificate +### 4.6.6 Publication of the renewal certificate by the CA +### 4.6.7 Notification of certificate issuance by the CA to other entities + +## 4.7 Certificate re-key +### 4.7.1 Circumstance for certificate re-key +### 4.7.2 Who may request certification of a new public key +### 4.7.3 Processing certificate re-keying requests +### 4.7.4 Notification of new certificate issuance to subscriber +### 4.7.5 Conduct constituting acceptance of a re-keyed certificate +### 4.7.6 Publication of the re-keyed certificate by the CA +### 4.7.7 Notification of certificate issuance by the CA to other entities + +## 4.8 Certificate modification +### 4.8.1 Circumstance for certificate modification +### 4.8.2 Who may request certificate modification +### 4.8.3 Processing certificate modification requests +### 4.8.4 Notification of new certificate issuance to subscriber +### 4.8.5 Conduct constituting acceptance of modified certificate +### 4.8.6 Publication of the modified certificate by the CA +### 4.8.7 Notification of certificate issuance by the CA to other entities + +## 4.9 Certificate revocation and suspension +### 4.9.1 Circumstances for revocation +### 4.9.2 Who can request revocation +### 4.9.3 Procedure for revocation request +### 4.9.4 Revocation request grace period +### 4.9.5 Time within which CA must process the revocation request +### 4.9.6 Revocation checking requirement for relying parties ### 4.9.7 CRL issuance frequency (if applicable) ### 4.9.8 Maximum latency for CRLs (if applicable) -### 4.9.9 On-line revocation/status checking availability +### 4.9.9 On-line revocation/status checking availability ### 4.9.10 On-line revocation checking requirements ### 4.9.11 Other forms of revocation advertisements available ### 4.9.12 Special requirements re key compromise @@ -1098,44 +1099,44 @@ Root CA Private Keys MUST NOT be used to sign EV Certificates. ### 4.9.15 Procedure for suspension request ### 4.9.16 Limits on suspension period -## 4.10 Certificate status services +## 4.10 Certificate status services ### 4.10.1 Operational characteristics ### 4.10.2 Service availability ### 4.10.3 Optional features -## 4.11 End of subscription +## 4.11 End of subscription -## 4.12 Key escrow and recovery +## 4.12 Key escrow and recovery ### 4.12.1 Key escrow and recovery policy and practices ### 4.12.2 Session key encapsulation and recovery policy and practices -# 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS +# 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS As specified in Section 5 of the Baseline Requirements. In addition, systems used to process and approve EV Certificate Requests MUST require actions by at least two trusted persons before creating an EV Certificate. -## 5.1 Physical controls -### 5.1.1 Site location and construction -### 5.1.2 Physical access -### 5.1.3 Power and air conditioning -### 5.1.4 Water exposures -### 5.1.5 Fire prevention and protection -### 5.1.6 Media storage -### 5.1.7 Waste disposal -### 5.1.8 Off-site backup - -## 5.2 Procedural controls -### 5.2.1 Trusted roles -### 5.2.2 Number of persons required per task -### 5.2.3 Identification and authentication for each role - -### 5.2.4 Roles requiring separation of duties +## 5.1 Physical controls +### 5.1.1 Site location and construction +### 5.1.2 Physical access +### 5.1.3 Power and air conditioning +### 5.1.4 Water exposures +### 5.1.5 Fire prevention and protection +### 5.1.6 Media storage +### 5.1.7 Waste disposal +### 5.1.8 Off-site backup + +## 5.2 Procedural controls +### 5.2.1 Trusted roles +### 5.2.2 Number of persons required per task +### 5.2.3 Identification and authentication for each role + +### 5.2.4 Roles requiring separation of duties 1. The CA MUST enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the issuance of an EV Certificate. The Final Cross-Correlation and Due Diligence steps, as outlined in [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence), MAY be performed by one of the persons. For example, one Validation Specialist MAY review and verify all the Applicant information and a second Validation Specialist MAY approve issuance of the EV Certificate. 2. Such controls MUST be auditable. -## 5.3 Personnel controls +## 5.3 Personnel controls -### 5.3.1 Qualifications, experience, and clearance requirements +### 5.3.1 Qualifications, experience, and clearance requirements -### 5.3.2 Background check procedures +### 5.3.2 Background check procedures Prior to the commencement of employment of any person by the CA for engagement in the EV Processes, whether as an employee, agent, or an independent contractor of the CA, the CA MUST: 1. **Verify the Identity of Such Person**: Verification of identity MUST be performed through: @@ -1156,55 +1157,55 @@ Prior to the commencement of employment of any person by the CA for engagement i 3. In the case of employees already in the employ of the CA at the time of adoption of these Guidelines whose identity and background has not previously been verified as set forth above, the CA SHALL conduct such verification within three months of the date of adoption of these Guidelines. -### 5.3.3 Training requirements +### 5.3.3 Training requirements The requirements in Section 5.3.3 of the Baseline Requirements apply equally to EV Certificates and these Guidelines. The required internal examination must relate to the EV Certificate validation criteria outlined in these Guidelines. -### 5.3.4 Retraining frequency and requirements +### 5.3.4 Retraining frequency and requirements -### 5.3.5 Job rotation frequency and sequence +### 5.3.5 Job rotation frequency and sequence -### 5.3.6 Sanctions for unauthorized actions +### 5.3.6 Sanctions for unauthorized actions -### 5.3.7 Independent contractor requirements +### 5.3.7 Independent contractor requirements -### 5.3.8 Documentation supplied to personnel +### 5.3.8 Documentation supplied to personnel -## 5.4 Audit logging procedures +## 5.4 Audit logging procedures As specified in Section 5.4 of the Baseline Requirements. -### 5.4.1 Types of events recorded -### 5.4.2 Frequency of processing log -### 5.4.3 Retention period for audit log -### 5.4.4 Protection of audit log -### 5.4.5 Audit log backup procedures -### 5.4.6 Audit collection system (internal vs. external) -### 5.4.7 Notification to event-causing subject -### 5.4.8 Vulnerability assessments +### 5.4.1 Types of events recorded +### 5.4.2 Frequency of processing log +### 5.4.3 Retention period for audit log +### 5.4.4 Protection of audit log +### 5.4.5 Audit log backup procedures +### 5.4.6 Audit collection system (internal vs. external) +### 5.4.7 Notification to event-causing subject +### 5.4.8 Vulnerability assessments -## 5.5 Records archival -### 5.5.1 Types of records archived -### 5.5.2 Retention period for archive -### 5.5.3 Protection of archive -### 5.5.4 Archive backup procedures -### 5.5.5 Requirements for time-stamping of records -### 5.5.6 Archive collection system (internal or external) -### 5.5.7 Procedures to obtain and verify archive information +## 5.5 Records archival +### 5.5.1 Types of records archived +### 5.5.2 Retention period for archive +### 5.5.3 Protection of archive +### 5.5.4 Archive backup procedures +### 5.5.5 Requirements for time-stamping of records +### 5.5.6 Archive collection system (internal or external) +### 5.5.7 Procedures to obtain and verify archive information -## 5.6 Key changeover +## 5.6 Key changeover -## 5.7 Compromise and disaster recovery -### 5.7.1 Incident and compromise handling procedures -### 5.7.2 Computing resources, software, and/or data are corrupted -### 5.7.3 Entity private key compromise procedures -### 5.7.4 Business continuity capabilities after a disaster +## 5.7 Compromise and disaster recovery +### 5.7.1 Incident and compromise handling procedures +### 5.7.2 Computing resources, software, and/or data are corrupted +### 5.7.3 Entity private key compromise procedures +### 5.7.4 Business continuity capabilities after a disaster -## 5.8 CA or RA termination +## 5.8 CA or RA termination -# 6. TECHNICAL SECURITY CONTROLS +# 6. TECHNICAL SECURITY CONTROLS -## 6.1 Key pair generation and installation +## 6.1 Key pair generation and installation -### 6.1.1 Key pair generation +### 6.1.1 Key pair generation All requirements in Section 6.1.1.1 of the Baseline Requirements apply equally to EV Certificates. However, for Root CA Key Pairs generated after the release of these Guidelines, the Root CA Key Pair generation ceremony MUST be witnessed by the CA's Qualified Auditor in order to observe the process and the controls over the integrity and confidentiality of the Root CA Key Pairs produced. The Qualified Auditor MUST then issue a report opining that the CA, during its Root CA Key Pair and Certificate generation process: 1. Documented its Root CA key generation and protection procedures in its Certificate Policy, and its Certification Practices Statement; @@ -1212,60 +1213,60 @@ All requirements in Section 6.1.1.1 of the Baseline Requirements apply equally t 3. Maintained effective controls to provide reasonable assurance that the Root CA key pair was generated and protected in conformity with the procedures described in its CP/CPS and with its Root Key Generation Script; 4. Performed, during the Root CA key generation process, all the procedures required by its Root Key Generation Script. -### 6.1.2 Private key delivery to subscriber -### 6.1.3 Public key delivery to certificate issuer -### 6.1.4 CA public key delivery to relying parties -### 6.1.5 Key sizes -### 6.1.6 Public key parameters generation and quality checking -### 6.1.7 Key usage purposes (as per X.509 v3 key usage field) - -## 6.2 Private Key Protection and Cryptographic Module Engineering Controls -### 6.2.1 Cryptographic module standards and controls -### 6.2.2 Private key (n out of m) multi-person control -### 6.2.3 Private key escrow -### 6.2.4 Private key backup -### 6.2.5 Private key archival -### 6.2.6 Private key transfer into or from a cryptographic module -### 6.2.7 Private key storage on cryptographic module -### 6.2.8 Method of activating private key -### 6.2.9 Method of deactivating private key +### 6.1.2 Private key delivery to subscriber +### 6.1.3 Public key delivery to certificate issuer +### 6.1.4 CA public key delivery to relying parties +### 6.1.5 Key sizes +### 6.1.6 Public key parameters generation and quality checking +### 6.1.7 Key usage purposes (as per X.509 v3 key usage field) + +## 6.2 Private Key Protection and Cryptographic Module Engineering Controls +### 6.2.1 Cryptographic module standards and controls +### 6.2.2 Private key (n out of m) multi-person control +### 6.2.3 Private key escrow +### 6.2.4 Private key backup +### 6.2.5 Private key archival +### 6.2.6 Private key transfer into or from a cryptographic module +### 6.2.7 Private key storage on cryptographic module +### 6.2.8 Method of activating private key +### 6.2.9 Method of deactivating private key ### 6.2.10 Method of destroying private key ### 6.2.11 Cryptographic Module Rating -## 6.3 Other aspects of key pair management -### 6.3.1 Public key archival +## 6.3 Other aspects of key pair management +### 6.3.1 Public key archival -### 6.3.2 Certificate operational periods and key pair usage periods +### 6.3.2 Certificate operational periods and key pair usage periods 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. -## 6.4 Activation data -### 6.4.1 Activation data generation and installation -### 6.4.2 Activation data protection -### 6.4.3 Other aspects of activation data +## 6.4 Activation data +### 6.4.1 Activation data generation and installation +### 6.4.2 Activation data protection +### 6.4.3 Other aspects of activation data -## 6.5 Computer security controls -### 6.5.1 Specific computer security technical requirements -### 6.5.2 Computer security rating +## 6.5 Computer security controls +### 6.5.1 Specific computer security technical requirements +### 6.5.2 Computer security rating -## 6.6 Life cycle technical controls -### 6.6.1 System development controls -### 6.6.2 Security management controls -### 6.6.3 Life cycle security controls +## 6.6 Life cycle technical controls +### 6.6.1 System development controls +### 6.6.2 Security management controls +### 6.6.3 Life cycle security controls -## 6.7 Network security controls +## 6.7 Network security controls -## 6.8 Time-stamping +## 6.8 Time-stamping -# 7. CERTIFICATE, CRL, AND OCSP PROFILES +# 7. CERTIFICATE, CRL, AND OCSP PROFILES -## 7.1 Certificate profile +## 7.1 Certificate profile This section sets forth minimum requirements for the content of the EV Certificate as they relate to the identity of the CA and the Subject of the EV Certificate. -### 7.1.1 Version number(s) +### 7.1.1 Version number(s) -### 7.1.2 Certificate extensions +### 7.1.2 Certificate extensions The extensions listed in [Section 7.1.2](#712-certificate-extensions) are recommended for maximum interoperability between certificates and browsers / applications, but are not mandatory on the CAs except where indicated as “Required”. CAs may use other extensions that are not listed in [Section 7.1.2](#712-certificate-extensions), but are encouraged to add them to this section by ballot from time to time to help increase extension standardization across the industry. If a CA includes an extension in a certificate that has a Certificate field which is named in [Section 7.1.2](#712-certificate-extensions), the CA must follow the format specified in that subsection. However, no extension or extension format shall be mandatory on a CA unless specifically stated as “Required” in the subsection that describes the extension. @@ -1310,8 +1311,8 @@ CABFOrganizationIdentifier ::= SEQUENCE { where the subfields have the same values, meanings, and restrictions described in [Section 7.1.4.2.8](#71428-subject-organization-identifier-field). The CA SHALL validate the contents using the requirements in [Section 7.1.4.2.8](#71428-subject-organization-identifier-field). -### 7.1.3 Algorithm object identifiers -### 7.1.4 Name forms +### 7.1.3 Algorithm object identifiers +### 7.1.4 Name forms #### 7.1.4.1 Issuer Information Issuer Information listed in an EV Certificate MUST comply with Section 7.1.4.1 of the Baseline Requirements. @@ -1445,9 +1446,9 @@ All provisions of the Baseline Requirements concerning Minimum Cryptographic Alg 3. The `cRLDistributionPoints` extension MUST be present in Subscriber Certificates if the certificate does not specify OCSP responder locations in an `authorityInformationAccess` extension. -### 7.1.5 Name constraints +### 7.1.5 Name constraints -### 7.1.6 Certificate policy object identifier +### 7.1.6 Certificate policy object identifier This section sets forth minimum requirements for the contents of EV Certificates as they relate to the identification of EV Certificate Policy. #### 7.1.6.1 EV Subscriber Certificates @@ -1474,21 +1475,21 @@ The Application Software Supplier identifies Root CAs that are approved to issue A Certificate issued to a Subscriber MUST contain one or more policy identifier(s), defined by the Issuing CA, in the Certificate's `certificatePolicies` extension that indicates adherence to and compliance with these Guidelines. Each CA SHALL document in its Certificate Policy or Certification Practice Statement that the Certificates it issues containing the specified policy identifier(s) are managed in accordance with these Guidelines. -### 7.1.7 Usage of Policy Constraints extension +### 7.1.7 Usage of Policy Constraints extension -### 7.1.8 Policy qualifiers syntax and semantics +### 7.1.8 Policy qualifiers syntax and semantics ### 7.1.9 Processing semantics for the critical Certificate Policies extension -## 7.2 CRL profile -### 7.2.1 Version number(s) -### 7.2.2 CRL and CRL entry extensions +## 7.2 CRL profile +### 7.2.1 Version number(s) +### 7.2.2 CRL and CRL entry extensions -## 7.3 OCSP profile -### 7.3.1 Version number(s) -### 7.3.2 OCSP extensions +## 7.3 OCSP profile +### 7.3.1 Version number(s) +### 7.3.2 OCSP extensions -# 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS +# 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS A CA issuing EV Certificates SHALL undergo an audit in accordance with one of the following schemes: @@ -1498,23 +1499,23 @@ iii. ETSI EN 319 411-1 audit for EVCP policy. If the CA is a Government Entity, an audit of the CA by the appropriate internal government auditing agency is acceptable in lieu of the audits specified above, provided that such internal government auditing agency publicly certifies in writing that its audit addresses the criteria specified in one of the above audit schemes and certifies that the government CA has successfully passed the audit. -## 8.1 Frequency or circumstances of assessment +## 8.1 Frequency or circumstances of assessment CAs issuing EV Certificates MUST undergo an annual audit that meets the criteria of [Section 8](#8-compliance-audit-and-other-assessments). -### 8.1.1 Self audits +### 8.1.1 Self audits During the period in which it issues EV Certificates, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least three percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. For all EV Certificates where the Final Cross-Correlation and Due Diligence requirements of [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence) is performed by an RA, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least six percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. -## 8.2 Identity/qualifications of assessor +## 8.2 Identity/qualifications of assessor A Qualified Auditor (as defined in Section 8.2 of the Baseline Requirements) MUST perform the CA's audit. -## 8.3 Assessor's relationship to assessed entity -## 8.4 Topics covered by assessment -## 8.5 Actions taken as a result of deficiency +## 8.3 Assessor's relationship to assessed entity +## 8.4 Topics covered by assessment +## 8.5 Actions taken as a result of deficiency -## 8.6 Communication of results +## 8.6 Communication of results CAs SHOULD make its audit report publicly available no later than three months after the end of the audit period. If there is a delay greater than three months and if so requested by an Application Software Supplier, the CA MUST provide an explanatory letter signed by its auditor. -## 8.7 Pre-issuance Readiness Audit +## 8.7 Pre-issuance Readiness Audit 1. If the CA has a currently valid WebTrust Seal of Assurance for CAs, then, before issuing EV Certificates, the CA and its Root CA MUST successfully complete a point-in-time readiness assessment audit against the WebTrust EV Program. 2. If the CA has a currently valid ETSI 102 042 audit, then, before issuing EV Certificates, the CA and its Root CA MUST successfully complete a point-in-time readiness assessment audit against ETSI TS 102 042. @@ -1525,17 +1526,17 @@ CAs SHOULD make its audit report publicly available no later than three months a The CA MUST complete any required point-in-time readiness assessment no earlier than twelve (12) months prior to issuing an EV Certificate. The CA MUST undergo a complete audit under such scheme within ninety (90) days of issuing the first EV Certificate. -# 9. OTHER BUSINESS AND LEGAL MATTERS -## 9.1 Fees -### 9.1.1 Certificate issuance or renewal fees -### 9.1.2 Certificate access fees -### 9.1.3 Revocation or status information access fees -### 9.1.4 Fees for other services -### 9.1.5 Refund policy +# 9. OTHER BUSINESS AND LEGAL MATTERS +## 9.1 Fees +### 9.1.1 Certificate issuance or renewal fees +### 9.1.2 Certificate access fees +### 9.1.3 Revocation or status information access fees +### 9.1.4 Fees for other services +### 9.1.5 Refund policy -## 9.2 Financial responsibility +## 9.2 Financial responsibility -### 9.2.1 Insurance coverage +### 9.2.1 Insurance coverage Each CA SHALL maintain the following insurance related to their respective performance and obligations under these Guidelines: A. Commercial General Liability insurance (occurrence form) with policy limits of at least two million US dollars in coverage; and @@ -1548,24 +1549,24 @@ Such insurance must be with a company rated no less than A- as to Policy Holder' A CA MAY self-insure for liabilities that arise from such party's performance and obligations under these Guidelines provided that it has at least five hundred million US dollars in liquid assets based on audited financial statements in the past twelve months, and a quick ratio (ratio of liquid assets to current liabilities) of not less than 1.0. -### 9.2.2 Other assets -### 9.2.3 Insurance or warranty coverage for end-entities -## 9.3 Confidentiality of business information -### 9.3.1 Scope of confidential information -### 9.3.2 Information not within the scope of confidential information -### 9.3.3 Responsibility to protect confidential information -## 9.4 Privacy of personal information -### 9.4.1 Privacy plan -### 9.4.2 Information treated as private -### 9.4.3 Information not deemed private -### 9.4.4 Responsibility to protect private information -### 9.4.5 Notice and consent to use private information +### 9.2.2 Other assets +### 9.2.3 Insurance or warranty coverage for end-entities +## 9.3 Confidentiality of business information +### 9.3.1 Scope of confidential information +### 9.3.2 Information not within the scope of confidential information +### 9.3.3 Responsibility to protect confidential information +## 9.4 Privacy of personal information +### 9.4.1 Privacy plan +### 9.4.2 Information treated as private +### 9.4.3 Information not deemed private +### 9.4.4 Responsibility to protect private information +### 9.4.5 Notice and consent to use private information ### 9.4.6 Disclosure pursuant to judicial or administrative process -### 9.4.7 Other information disclosure circumstances -## 9.5 Intellectual property rights -## 9.6 Representations and warranties +### 9.4.7 Other information disclosure circumstances +## 9.5 Intellectual property rights +## 9.6 Representations and warranties -### 9.6.1 CA representations and warranties +### 9.6.1 CA representations and warranties When the CA issues an EV Certificate, the CA and its Root CA represent and warrant to the Certificate Beneficiaries listed in Section 9.6.1 of the Baseline Requirements, during the period when the EV Certificate is Valid, that the CA has followed the requirements of these Guidelines and its EV Policies in issuing and managing the EV Certificate and in verifying the accuracy of the information contained in the EV Certificate. The EV Certificate Warranties specifically include, but are not limited to, the following: A. **Legal Existence**: The CA has confirmed with the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration that, as of the date the EV Certificate was issued, the Subject named in the EV Certificate legally exists as a valid organization or entity in the Jurisdiction of Incorporation or Registration; @@ -1584,46 +1585,46 @@ G. **Status**: The CA will follow the requirements of these Guidelines and main H. **Revocation**: The CA will follow the requirements of these Guidelines and revoke the EV Certificate for any of the revocation reasons specified in these Guidelines. -### 9.6.2 RA representations and warranties +### 9.6.2 RA representations and warranties -### 9.6.3 Subscriber representations and warranties +### 9.6.3 Subscriber representations and warranties Section 9.6.3 of the Baseline Requirements applies equally to EV Certificates. In cases where the Certificate Request does not contain all necessary information about the Applicant, the CA MUST additionally confirm the data with the Certificate Approver or Contract Signer rather than the Certificate Requester. EV Certificate Applicants make the commitments and warranties set forth in Section 9.6.3 of the Baseline Requirements for the benefit of the CA and Certificate Beneficiaries. -### 9.6.4 Relying party representations and warranties -### 9.6.5 Representations and warranties of other participants -## 9.7 Disclaimers of warranties +### 9.6.4 Relying party representations and warranties +### 9.6.5 Representations and warranties of other participants +## 9.7 Disclaimers of warranties -## 9.8 Limitations of liability +## 9.8 Limitations of liability 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. -## 9.9 Indemnities +## 9.9 Indemnities 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. -## 9.10 Term and termination -### 9.10.1 Term -### 9.10.2 Termination -### 9.10.3 Effect of termination and survival -## 9.11 Individual notices and communications with participants -## 9.12 Amendments -### 9.12.1 Procedure for amendment -### 9.12.2 Notification mechanism and period -### 9.12.3 Circumstances under which OID must be changed -## 9.13 Dispute resolution provisions -## 9.14 Governing law -## 9.15 Compliance with applicable law -## 9.16 Miscellaneous provisions -### 9.16.1 Entire agreement -### 9.16.2 Assignment - -### 9.16.3 Severability +## 9.10 Term and termination +### 9.10.1 Term +### 9.10.2 Termination +### 9.10.3 Effect of termination and survival +## 9.11 Individual notices and communications with participants +## 9.12 Amendments +### 9.12.1 Procedure for amendment +### 9.12.2 Notification mechanism and period +### 9.12.3 Circumstances under which OID must be changed +## 9.13 Dispute resolution provisions +## 9.14 Governing law +## 9.15 Compliance with applicable law +## 9.16 Miscellaneous provisions +### 9.16.1 Entire agreement +### 9.16.2 Assignment + +### 9.16.3 Severability The CA MAY issue EV Certificates, provided that the CA and its Root CA satisfy the requirements in these Guidelines and the Baseline Requirements. Section 9.16.3 of the Baseline Requirements applies equally to EV Certificates. -### 9.16.4 Enforcement (attorneys' fees and waiver of rights) -### 9.16.5 Force Majeure -## 9.17 Other provisions +### 9.16.4 Enforcement (attorneys' fees and waiver of rights) +### 9.16.5 Force Majeure +## 9.17 Other provisions # Appendix A - User Agent Verification (Normative) The CA MUST host test Web pages that allow Application Software Suppliers to test their software with EV Certificates that chain up to each EV Root Certificate. At a minimum, the CA MUST host separate Web pages using certificates that are: From 3ef005832237a0b555bc6f143c9dfe594c8afd9e Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Sun, 23 Nov 2025 21:14:23 +0100 Subject: [PATCH 035/121] #432 headers - new lines --- docs/BR.md | 1 + docs/EVG.md | 211 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 212 insertions(+) diff --git a/docs/BR.md b/docs/BR.md index 43bd91ae..6c9a1ce5 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -3474,6 +3474,7 @@ Before including such an attribute, the CA SHALL: * Ensure that the contents contain information that has been verified by the CA, independent of the Applicant. ### 7.1.5 Name constraints + See Sections [7.1.2.5.2 Technically Constrained TLS Subordinate CA Name Constraints](#71252-technically-constrained-tls-subordinate-ca-name-constraints) and [7.1.2.10.8 CA Certificate Name Constraints](#712108-ca-certificate-name-constraints). ### 7.1.6 Certificate policy object identifier diff --git a/docs/EVG.md b/docs/EVG.md index f1d058c4..57476eb7 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -27,6 +27,7 @@ The Guidelines for the Issuance and Management of Extended Validation Certificat The CA/Browser Forum is a voluntary open organization of certification authorities and suppliers of Internet browsers and other relying-party software applications. Membership is listed at . ## 1.1 Overview + These Guidelines for the issuance and management of Extended Validation Certificates describe certain of the minimum requirements that a Certification Authority must meet in order to issue Extended Validation Certificates. Subject Organization information from Valid EV Certificates may be displayed 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 they are accessing. These Guidelines incorporate the Baseline Requirements established by the CA/Browser Forum by reference. A copy of the Baseline Requirements is available on the CA/Browser Forum's website at . These Guidelines address the basic issue of validating Subject identity information in EV Certificates and some related matters. They do not address all of the related matters, such as certain technical and operational ones. This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet. However, the Working Group encourages the re-use of these guidelines as a basis for similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. @@ -34,7 +35,9 @@ These Guidelines address the basic issue of validating Subject identity informat These Guidelines do not address the verification of information, or the issuance, use, maintenance, or revocation of EV Certificates by enterprises that operate their own Public Key Infrastructure for internal purposes only, where its Root CA Certificate is not distributed by any Application Software Supplier. ## 1.2 Document name and identification + ### 1.2.1 Revisions + | **Ver.** | **Ballot** | **Description** | **Adopted** | **Effective\*** | |-|-|-----|--|--| | 1.4.0 | 72 | Reorganize EV Documents | 29 May 2012 | 29 May 2012 | @@ -101,6 +104,7 @@ These Guidelines do not address the verification of information, or the issuance ### 1.3.1 Certification authorities ### 1.3.2 Registration authorities + The CA MAY delegate the performance of all or any part of a requirement of these Guidelines to an Affiliate or a Registration Authority (RA) or subcontractor, provided that the process employed by the CA fulfills all of the requirements of [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence). Affiliates and/or RAs must comply with the qualification requirements of [Section 5.3.2](#532-background-check-procedures). @@ -109,6 +113,7 @@ The CA SHALL verify that the Delegated Third Party's personnel involved in the i In all cases, the CA MUST contractually obligate each Affiliate, RA, subcontractor, and Enterprise RA to comply with all applicable requirements in these Guidelines and to perform them as required of the CA itself. The CA SHALL enforce these obligations and internally audit each Affiliate's, RA's, subcontractor's, and Enterprise RA's compliance with these Requirements on an annual basis. #### 1.3.2.1 Enterprise Registration authorities + 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; @@ -118,10 +123,15 @@ The CA MAY contractually authorize a Subscriber to perform the RA function and a Enterprise RAs that authorize the issuance of EV Certificates solely for its own organization are exempted from the audit requirements of [Section 8](#8-compliance-audit-and-other-assessments). In all other cases, the requirements of [Section 8](#8-compliance-audit-and-other-assessments) SHALL apply. ### 1.3.3 Subscribers + ### 1.3.4 Relying parties + ### 1.3.5 Other participants + ## 1.4 Certificate usage + ### 1.4.1 Appropriate certificate uses + EV Certificates are intended for establishing Web-based data communication conduits via the TLS/SSL protocols and for verifying the authenticity of executable code. #### 1.4.1.1 Primary Purposes @@ -141,6 +151,7 @@ The secondary purposes of an EV Certificate are to help establish the legitimacy 3. Assist law enforcement organizations in their investigations of phishing and other online identity fraud, including where appropriate, contacting, investigating, or taking legal action against the Subject. ### 1.4.2 Prohibited certificate uses + EV Certificates focus only on the identity of the Subject named in the Certificate, and not on the behavior of the Subject. As such, an EV Certificate is **not** intended to provide any assurances, or otherwise represent or warrant: 1. That the Subject named in the EV Certificate is actively engaged in doing business; @@ -149,14 +160,19 @@ EV Certificates focus only on the identity of the Subject named in the Certifica 4. That it is "safe" to do business with the Subject named in the EV Certificate. ## 1.5 Policy administration + ### 1.5.1 Organization administering the document + ### 1.5.2 Contact person + ### 1.5.3 Person determining CPS suitability for the policy + ### 1.5.4 CPS approval procedures ## 1.6 Definitions and acronyms ### 1.6.1 Definitions + Capitalized Terms are defined in the Baseline Requirements except where provided below: **Accounting Practitioner**: A certified public accountant, chartered accountant, or a person with an equivalent license within the country of the Applicant's Jurisdiction of Incorporation or Registration or any jurisdiction where the Applicant maintains an office or physical facility; provided that an accounting standards body in the jurisdiction maintains full (not "suspended" or "associate") membership status with the International Federation of Accountants. @@ -296,6 +312,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **WebTrust Seal of Assurance**: An affirmation of compliance resulting from the WebTrust Program for CAs. ### 1.6.2 Acronyms + Abbreviations and Acronyms are defined in the Baseline Requirements except as otherwise defined herein: | **Acronym** | **Meaning** | @@ -321,9 +338,11 @@ Abbreviations and Acronyms are defined in the Baseline Requirements except as ot | UTC(k) | National realization of Coordinated Universal Time | ### 1.6.3 References + See Baseline Requirements, which are available at . ### 1.6.4 Conventions + Terms not otherwise defined in these Guidelines shall be as defined in applicable agreements, user manuals, certification practice statements (CPS), and certificate policies (CP) of the CA issuing EV Certificates. The key words "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in these Guidelines shall be interpreted in accordance with RFC 2119. @@ -331,6 +350,7 @@ The key words "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMME By convention, this document omits time and timezones when listing effective requirements such as dates. Except when explicitly specified, the associated time with a date shall be 00:00:00 UTC. # 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES + Each CA must develop, implement, enforce, display prominently on its Web site, and periodically update as necessary its own auditable EV Certificate practices, policies and procedures, such as a Certification Practice Statement (CPS) and Certificate Policy (CP) that: A. Implement the requirements of these Guidelines as they are revised from time-to-time; @@ -343,7 +363,9 @@ B. Implement the requirements of C. Specify the CA's and its Root CA's entire root certificate hierarchy including all roots that its EV Certificates depend on for proof of those EV Certificates' authenticity. ## 2.1 Repositories + ## 2.2 Publication of certification information + Each CA MUST publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see [Section 8](#8-compliance-audit-and-other-assessments)). The CA's Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647. The Certificate Policy and/or Certification Practice Statement MUST include all material required by RFC 3647. @@ -355,14 +377,23 @@ Each CA SHALL publicly give effect to these Guidelines and represent that they w In addition, the CA MUST include (directly or by reference) the applicable requirements of these Guidelines in all contracts with Subordinate CAs, RAs, Enterprise RAs, and subcontractors that involve or relate to the issuance or maintenance of EV Certificates. The CA MUST enforce compliance with such terms. ## 2.3 Time or frequency of publication + ## 2.4 Access controls on repositories + # 3. IDENTIFICATION AND AUTHENTICATION + ## 3.1 Naming + ### 3.1.1 Types of names + ### 3.1.2 Need for names to be meaningful + ### 3.1.3 Anonymity or pseudonymity of subscribers + ### 3.1.4 Rules for interpreting various name forms + ### 3.1.5 Uniqueness of names + ### 3.1.6 Recognition, authentication, and role of trademarks ## 3.2 Initial identity validation @@ -938,12 +969,17 @@ A CA may rely on a previously verified certificate request to issue a replacemen 4. The CA MUST repeat the verification process required in these Guidelines for any information obtained outside the time limits specified above except when permitted otherwise under [Section 3.2.2.14.1](#322141-validation-for-existing-subscribers). ### 3.2.3 Authentication of individual identity + ### 3.2.4 Non-verified subscriber information + ### 3.2.5 Validation of authority + ### 3.2.6 Criteria for interoperation ## 3.3 Identification and authentication for re-key requests + ### 3.3.1 Identification and authentication for routine re-key + ### 3.3.2 Identification and authentication for re-key after revocation ## 3.4 Identification and authentication for revocation request @@ -953,6 +989,7 @@ A CA may rely on a previously verified certificate request to issue a replacemen ## 4.1 Certificate Application ### 4.1.1 Who can submit a certificate application + The CA MAY only issue EV Certificates to Applicants that meet the Private Organization, Government Entity, Business Entity and Non-Commercial Entity requirements specified below. #### 4.1.1.1 Private Organization Subjects @@ -1012,12 +1049,14 @@ An Applicant qualifies as a Non-Commercial Entity if: Subsidiary organizations or agencies of an entity that qualifies as a Non-Commercial Entity also qualifies for EV Certificates as a Non-Commercial Entity. ### 4.1.2 Enrollment process and responsibilities + The documentation requirements in Section 4.1.2 of the Baseline Requirements apply equally to EV Certificates. The Certificate Request requirements in Section 4.1.2 of the Baseline Requirements apply equally to EV Certificates subject to the additional more stringent ageing and updating requirement of [Section 3.2.2.14](#32214-requirements-for-re-use-of-existing-documentation). ## 4.2 Certificate application processing ### 4.2.1 Performing identification and authentication functions + The following Applicant roles are required for the issuance of an EV Certificate. 1. **Certificate Requester**: The EV Certificate Request MUST be submitted by an authorized Certificate Requester. A Certificate Requester is a natural person who is either the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or a third party (such as an ISP or hosting company) that completes and submits an EV Certificate Request on behalf of the Applicant. @@ -1034,11 +1073,13 @@ The following Applicant roles are required for the issuance of an EV Certificate The Applicant MAY authorize one individual to occupy two or more of these roles. The Applicant MAY authorize more than one individual to occupy any of these roles. ### 4.2.2 Approval or rejection of certificate applications + ### 4.2.3 Time to process certificate applications ## 4.3 Certificate issuance ### 4.3.1 CA actions during certificate issuance + Certificate issuance by the Root CA SHALL require an individual authorized by the CA (i.e. the CA system operator, system officer, or PKI administrator) to deliberately issue a direct command in order for the Root CA to perform a certificate signing operation. Root CA Private Keys MUST NOT be used to sign EV Certificates. @@ -1046,89 +1087,149 @@ Root CA Private Keys MUST NOT be used to sign EV Certificates. ### 4.3.2 Notification to subscriber by the CA of issuance of certificate ## 4.4 Certificate acceptance + ### 4.4.1 Conduct constituting certificate acceptance + ### 4.4.2 Publication of the certificate by the CA + ### 4.4.3 Notification of certificate issuance by the CA to other entities ## 4.5 Key pair and certificate usage + ### 4.5.1 Subscriber private key and certificate usage + ### 4.5.2 Relying party public key and certificate usage ## 4.6 Certificate renewal + ### 4.6.1 Circumstance for certificate renewal + ### 4.6.2 Who may request renewal + ### 4.6.3 Processing certificate renewal requests + ### 4.6.4 Notification of new certificate issuance to subscriber + ### 4.6.5 Conduct constituting acceptance of a renewal certificate + ### 4.6.6 Publication of the renewal certificate by the CA + ### 4.6.7 Notification of certificate issuance by the CA to other entities ## 4.7 Certificate re-key + ### 4.7.1 Circumstance for certificate re-key + ### 4.7.2 Who may request certification of a new public key + ### 4.7.3 Processing certificate re-keying requests + ### 4.7.4 Notification of new certificate issuance to subscriber + ### 4.7.5 Conduct constituting acceptance of a re-keyed certificate + ### 4.7.6 Publication of the re-keyed certificate by the CA + ### 4.7.7 Notification of certificate issuance by the CA to other entities ## 4.8 Certificate modification + ### 4.8.1 Circumstance for certificate modification + ### 4.8.2 Who may request certificate modification + ### 4.8.3 Processing certificate modification requests + ### 4.8.4 Notification of new certificate issuance to subscriber + ### 4.8.5 Conduct constituting acceptance of modified certificate + ### 4.8.6 Publication of the modified certificate by the CA + ### 4.8.7 Notification of certificate issuance by the CA to other entities ## 4.9 Certificate revocation and suspension + ### 4.9.1 Circumstances for revocation + ### 4.9.2 Who can request revocation + ### 4.9.3 Procedure for revocation request + ### 4.9.4 Revocation request grace period + ### 4.9.5 Time within which CA must process the revocation request + ### 4.9.6 Revocation checking requirement for relying parties + ### 4.9.7 CRL issuance frequency (if applicable) + ### 4.9.8 Maximum latency for CRLs (if applicable) + ### 4.9.9 On-line revocation/status checking availability + ### 4.9.10 On-line revocation checking requirements + ### 4.9.11 Other forms of revocation advertisements available + ### 4.9.12 Special requirements re key compromise + ### 4.9.13 Circumstances for suspension + ### 4.9.14 Who can request suspension + ### 4.9.15 Procedure for suspension request + ### 4.9.16 Limits on suspension period ## 4.10 Certificate status services + ### 4.10.1 Operational characteristics + ### 4.10.2 Service availability + ### 4.10.3 Optional features ## 4.11 End of subscription ## 4.12 Key escrow and recovery + ### 4.12.1 Key escrow and recovery policy and practices + ### 4.12.2 Session key encapsulation and recovery policy and practices # 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS + As specified in Section 5 of the Baseline Requirements. In addition, systems used to process and approve EV Certificate Requests MUST require actions by at least two trusted persons before creating an EV Certificate. ## 5.1 Physical controls + ### 5.1.1 Site location and construction + ### 5.1.2 Physical access + ### 5.1.3 Power and air conditioning + ### 5.1.4 Water exposures + ### 5.1.5 Fire prevention and protection + ### 5.1.6 Media storage + ### 5.1.7 Waste disposal + ### 5.1.8 Off-site backup ## 5.2 Procedural controls + ### 5.2.1 Trusted roles + ### 5.2.2 Number of persons required per task + ### 5.2.3 Identification and authentication for each role ### 5.2.4 Roles requiring separation of duties + 1. The CA MUST enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the issuance of an EV Certificate. The Final Cross-Correlation and Due Diligence steps, as outlined in [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence), MAY be performed by one of the persons. For example, one Validation Specialist MAY review and verify all the Applicant information and a second Validation Specialist MAY approve issuance of the EV Certificate. 2. Such controls MUST be auditable. @@ -1137,6 +1238,7 @@ As specified in Section 5 of the Baseline Requirements. In addition, systems use ### 5.3.1 Qualifications, experience, and clearance requirements ### 5.3.2 Background check procedures + Prior to the commencement of employment of any person by the CA for engagement in the EV Processes, whether as an employee, agent, or an independent contractor of the CA, the CA MUST: 1. **Verify the Identity of Such Person**: Verification of identity MUST be performed through: @@ -1158,6 +1260,7 @@ Prior to the commencement of employment of any person by the CA for engagement i 3. In the case of employees already in the employ of the CA at the time of adoption of these Guidelines whose identity and background has not previously been verified as set forth above, the CA SHALL conduct such verification within three months of the date of adoption of these Guidelines. ### 5.3.3 Training requirements + The requirements in Section 5.3.3 of the Baseline Requirements apply equally to EV Certificates and these Guidelines. The required internal examination must relate to the EV Certificate validation criteria outlined in these Guidelines. ### 5.3.4 Retraining frequency and requirements @@ -1171,32 +1274,51 @@ The requirements in Section 5.3.3 of the Baseline Requirements apply equally to ### 5.3.8 Documentation supplied to personnel ## 5.4 Audit logging procedures + As specified in Section 5.4 of the Baseline Requirements. ### 5.4.1 Types of events recorded + ### 5.4.2 Frequency of processing log + ### 5.4.3 Retention period for audit log + ### 5.4.4 Protection of audit log + ### 5.4.5 Audit log backup procedures + ### 5.4.6 Audit collection system (internal vs. external) + ### 5.4.7 Notification to event-causing subject + ### 5.4.8 Vulnerability assessments ## 5.5 Records archival + ### 5.5.1 Types of records archived + ### 5.5.2 Retention period for archive + ### 5.5.3 Protection of archive + ### 5.5.4 Archive backup procedures + ### 5.5.5 Requirements for time-stamping of records + ### 5.5.6 Archive collection system (internal or external) + ### 5.5.7 Procedures to obtain and verify archive information ## 5.6 Key changeover ## 5.7 Compromise and disaster recovery + ### 5.7.1 Incident and compromise handling procedures + ### 5.7.2 Computing resources, software, and/or data are corrupted + ### 5.7.3 Entity private key compromise procedures + ### 5.7.4 Business continuity capabilities after a disaster ## 5.8 CA or RA termination @@ -1206,6 +1328,7 @@ As specified in Section 5.4 of the Baseline Requirements. ## 6.1 Key pair generation and installation ### 6.1.1 Key pair generation + All requirements in Section 6.1.1.1 of the Baseline Requirements apply equally to EV Certificates. However, for Root CA Key Pairs generated after the release of these Guidelines, the Root CA Key Pair generation ceremony MUST be witnessed by the CA's Qualified Auditor in order to observe the process and the controls over the integrity and confidentiality of the Root CA Key Pairs produced. The Qualified Auditor MUST then issue a report opining that the CA, during its Root CA Key Pair and Certificate generation process: 1. Documented its Root CA key generation and protection procedures in its Certificate Policy, and its Certification Practices Statement; @@ -1214,45 +1337,71 @@ All requirements in Section 6.1.1.1 of the Baseline Requirements apply equally t 4. Performed, during the Root CA key generation process, all the procedures required by its Root Key Generation Script. ### 6.1.2 Private key delivery to subscriber + ### 6.1.3 Public key delivery to certificate issuer + ### 6.1.4 CA public key delivery to relying parties + ### 6.1.5 Key sizes + ### 6.1.6 Public key parameters generation and quality checking + ### 6.1.7 Key usage purposes (as per X.509 v3 key usage field) ## 6.2 Private Key Protection and Cryptographic Module Engineering Controls + ### 6.2.1 Cryptographic module standards and controls + ### 6.2.2 Private key (n out of m) multi-person control + ### 6.2.3 Private key escrow + ### 6.2.4 Private key backup + ### 6.2.5 Private key archival + ### 6.2.6 Private key transfer into or from a cryptographic module + ### 6.2.7 Private key storage on cryptographic module + ### 6.2.8 Method of activating private key + ### 6.2.9 Method of deactivating private key + ### 6.2.10 Method of destroying private key + ### 6.2.11 Cryptographic Module Rating ## 6.3 Other aspects of key pair management + ### 6.3.1 Public key archival ### 6.3.2 Certificate operational periods and key pair usage periods + 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. ## 6.4 Activation data + ### 6.4.1 Activation data generation and installation + ### 6.4.2 Activation data protection + ### 6.4.3 Other aspects of activation data ## 6.5 Computer security controls + ### 6.5.1 Specific computer security technical requirements + ### 6.5.2 Computer security rating ## 6.6 Life cycle technical controls + ### 6.6.1 System development controls + ### 6.6.2 Security management controls + ### 6.6.3 Life cycle security controls ## 6.7 Network security controls @@ -1262,11 +1411,13 @@ It is RECOMMENDED that EV Subscriber Certificates have a Maximum Validity Period # 7. CERTIFICATE, CRL, AND OCSP PROFILES ## 7.1 Certificate profile + This section sets forth minimum requirements for the content of the EV Certificate as they relate to the identity of the CA and the Subject of the EV Certificate. ### 7.1.1 Version number(s) ### 7.1.2 Certificate extensions + The extensions listed in [Section 7.1.2](#712-certificate-extensions) are recommended for maximum interoperability between certificates and browsers / applications, but are not mandatory on the CAs except where indicated as “Required”. CAs may use other extensions that are not listed in [Section 7.1.2](#712-certificate-extensions), but are encouraged to add them to this section by ballot from time to time to help increase extension standardization across the industry. If a CA includes an extension in a certificate that has a Certificate field which is named in [Section 7.1.2](#712-certificate-extensions), the CA must follow the format specified in that subsection. However, no extension or extension format shall be mandatory on a CA unless specifically stated as “Required” in the subsection that describes the extension. @@ -1312,7 +1463,9 @@ CABFOrganizationIdentifier ::= SEQUENCE { where the subfields have the same values, meanings, and restrictions described in [Section 7.1.4.2.8](#71428-subject-organization-identifier-field). The CA SHALL validate the contents using the requirements in [Section 7.1.4.2.8](#71428-subject-organization-identifier-field). ### 7.1.3 Algorithm object identifiers + ### 7.1.4 Name forms + #### 7.1.4.1 Issuer Information Issuer Information listed in an EV Certificate MUST comply with Section 7.1.4.1 of the Baseline Requirements. @@ -1449,6 +1602,7 @@ All provisions of the Baseline Requirements concerning Minimum Cryptographic Alg ### 7.1.5 Name constraints ### 7.1.6 Certificate policy object identifier + This section sets forth minimum requirements for the contents of EV Certificates as they relate to the identification of EV Certificate Policy. #### 7.1.6.1 EV Subscriber Certificates @@ -1482,11 +1636,15 @@ A Certificate issued to a Subscriber MUST contain one or more policy identifier( ### 7.1.9 Processing semantics for the critical Certificate Policies extension ## 7.2 CRL profile + ### 7.2.1 Version number(s) + ### 7.2.2 CRL and CRL entry extensions ## 7.3 OCSP profile + ### 7.3.1 Version number(s) + ### 7.3.2 OCSP extensions # 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS @@ -1500,19 +1658,25 @@ iii. ETSI EN 319 411-1 audit for EVCP policy. If the CA is a Government Entity, an audit of the CA by the appropriate internal government auditing agency is acceptable in lieu of the audits specified above, provided that such internal government auditing agency publicly certifies in writing that its audit addresses the criteria specified in one of the above audit schemes and certifies that the government CA has successfully passed the audit. ## 8.1 Frequency or circumstances of assessment + CAs issuing EV Certificates MUST undergo an annual audit that meets the criteria of [Section 8](#8-compliance-audit-and-other-assessments). ### 8.1.1 Self audits + During the period in which it issues EV Certificates, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least three percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. For all EV Certificates where the Final Cross-Correlation and Due Diligence requirements of [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence) is performed by an RA, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least six percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. ## 8.2 Identity/qualifications of assessor + A Qualified Auditor (as defined in Section 8.2 of the Baseline Requirements) MUST perform the CA's audit. ## 8.3 Assessor's relationship to assessed entity + ## 8.4 Topics covered by assessment + ## 8.5 Actions taken as a result of deficiency ## 8.6 Communication of results + CAs SHOULD make its audit report publicly available no later than three months after the end of the audit period. If there is a delay greater than three months and if so requested by an Application Software Supplier, the CA MUST provide an explanatory letter signed by its auditor. ## 8.7 Pre-issuance Readiness Audit @@ -1527,16 +1691,23 @@ CAs SHOULD make its audit report publicly available no later than three months a The CA MUST complete any required point-in-time readiness assessment no earlier than twelve (12) months prior to issuing an EV Certificate. The CA MUST undergo a complete audit under such scheme within ninety (90) days of issuing the first EV Certificate. # 9. OTHER BUSINESS AND LEGAL MATTERS + ## 9.1 Fees + ### 9.1.1 Certificate issuance or renewal fees + ### 9.1.2 Certificate access fees + ### 9.1.3 Revocation or status information access fees + ### 9.1.4 Fees for other services + ### 9.1.5 Refund policy ## 9.2 Financial responsibility ### 9.2.1 Insurance coverage + Each CA SHALL maintain the following insurance related to their respective performance and obligations under these Guidelines: A. Commercial General Liability insurance (occurrence form) with policy limits of at least two million US dollars in coverage; and @@ -1550,23 +1721,39 @@ Such insurance must be with a company rated no less than A- as to Policy Holder' A CA MAY self-insure for liabilities that arise from such party's performance and obligations under these Guidelines provided that it has at least five hundred million US dollars in liquid assets based on audited financial statements in the past twelve months, and a quick ratio (ratio of liquid assets to current liabilities) of not less than 1.0. ### 9.2.2 Other assets + ### 9.2.3 Insurance or warranty coverage for end-entities + ## 9.3 Confidentiality of business information + ### 9.3.1 Scope of confidential information + ### 9.3.2 Information not within the scope of confidential information + ### 9.3.3 Responsibility to protect confidential information + ## 9.4 Privacy of personal information + ### 9.4.1 Privacy plan + ### 9.4.2 Information treated as private + ### 9.4.3 Information not deemed private + ### 9.4.4 Responsibility to protect private information + ### 9.4.5 Notice and consent to use private information + ### 9.4.6 Disclosure pursuant to judicial or administrative process + ### 9.4.7 Other information disclosure circumstances + ## 9.5 Intellectual property rights + ## 9.6 Representations and warranties ### 9.6.1 CA representations and warranties + When the CA issues an EV Certificate, the CA and its Root CA represent and warrant to the Certificate Beneficiaries listed in Section 9.6.1 of the Baseline Requirements, during the period when the EV Certificate is Valid, that the CA has followed the requirements of these Guidelines and its EV Policies in issuing and managing the EV Certificate and in verifying the accuracy of the information contained in the EV Certificate. The EV Certificate Warranties specifically include, but are not limited to, the following: A. **Legal Existence**: The CA has confirmed with the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration that, as of the date the EV Certificate was issued, the Subject named in the EV Certificate legally exists as a valid organization or entity in the Jurisdiction of Incorporation or Registration; @@ -1588,45 +1775,69 @@ H. **Revocation**: The CA will follow the requirements of these Guidelines and ### 9.6.2 RA representations and warranties ### 9.6.3 Subscriber representations and warranties + Section 9.6.3 of the Baseline Requirements applies equally to EV Certificates. In cases where the Certificate Request does not contain all necessary information about the Applicant, the CA MUST additionally confirm the data with the Certificate Approver or Contract Signer rather than the Certificate Requester. EV Certificate Applicants make the commitments and warranties set forth in Section 9.6.3 of the Baseline Requirements for the benefit of the CA and Certificate Beneficiaries. + ### 9.6.4 Relying party representations and warranties + ### 9.6.5 Representations and warranties of other participants + ## 9.7 Disclaimers of warranties ## 9.8 Limitations of liability + 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. ## 9.9 Indemnities + 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. ## 9.10 Term and termination + ### 9.10.1 Term + ### 9.10.2 Termination + ### 9.10.3 Effect of termination and survival + ## 9.11 Individual notices and communications with participants + ## 9.12 Amendments + ### 9.12.1 Procedure for amendment + ### 9.12.2 Notification mechanism and period + ### 9.12.3 Circumstances under which OID must be changed + ## 9.13 Dispute resolution provisions + ## 9.14 Governing law + ## 9.15 Compliance with applicable law + ## 9.16 Miscellaneous provisions + ### 9.16.1 Entire agreement + ### 9.16.2 Assignment ### 9.16.3 Severability + The CA MAY issue EV Certificates, provided that the CA and its Root CA satisfy the requirements in these Guidelines and the Baseline Requirements. Section 9.16.3 of the Baseline Requirements applies equally to EV Certificates. ### 9.16.4 Enforcement (attorneys' fees and waiver of rights) + ### 9.16.5 Force Majeure + ## 9.17 Other provisions # Appendix A - User Agent Verification (Normative) + The CA MUST host test Web pages that allow Application Software Suppliers to test their software with EV Certificates that chain up to each EV Root Certificate. At a minimum, the CA MUST host separate Web pages using certificates that are: i. valid; From 9e3c2b755cbad8b002f5817cc8b0a81e464a355a Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Sun, 23 Nov 2025 21:24:41 +0100 Subject: [PATCH 036/121] #432 trailing spaces removed --- docs/BR.md | 60 ++++++++++++++++++++++++++--------------------------- docs/EVG.md | 16 +++++++------- 2 files changed, 38 insertions(+), 38 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 6c9a1ce5..daab9115 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -373,7 +373,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Linting**: A process in which the content of digitally signed data such as a Precertificate [RFC 6962], Certificate, Certificate Revocation List, or OCSP response, or data-to-be-signed object such as a `tbsCertificate` (as described in [RFC 5280, Section 4.1.1.1](https://tools.ietf.org/doc/html/rfc5280##section-4.1.1.1)) is checked for conformance with the profiles and requirements defined in these Requirements. -**Multi-Perspective Issuance Corroboration**: A process by which the determinations made during domain validation and CAA checking by the Primary Network Perspective are corroborated by other Network Perspectives before Certificate issuance. +**Multi-Perspective Issuance Corroboration**: A process by which the determinations made during domain validation and CAA checking by the Primary Network Perspective are corroborated by other Network Perspectives before Certificate issuance. **Network Perspective**: Related to Multi-Perspective Issuance Corroboration. A system (e.g., a cloud-hosted server instance) or collection of network components (e.g., a VPN and corresponding infrastructure) for sending outbound Internet traffic associated with a domain control validation method and/or CAA check. The location of a Network Perspective is determined by the point where unencapsulated outbound Internet traffic is typically first handed off to the network infrastructure providing Internet connectivity to that perspective. @@ -599,7 +599,7 @@ RFC8738, Request for Comments: 8738, Automated Certificate Management Environmen RFC8954, Request for Comments: 8954, Online Certificate Status Protocol (OCSP) Nonce Extension. M. Sahni, Ed. November 2020. -WebTrust for Certification Authorities, SSL Baseline with Network Security, available at +WebTrust for Certification Authorities, SSL Baseline with Network Security, available at [WebTrust Principles and Criteria for Certification Authorities – SSL Baseline](https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/principles-and-criteria) @@ -718,7 +718,7 @@ Completed validations of Applicant authority may be valid for the issuance of mu Effective March 15th, 2026: DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective MUST: * perform DNSSEC validation using the algorithm defined in [RFC 4035 Section 5](https://datatracker.ietf.org/doc/html/rfc4035#section-5); and -* support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and +* support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and * support SHA-2 as defined in [RFC 4509](https://datatracker.ietf.org/doc/html/rfc4509) and [RFC 5702](https://datatracker.ietf.org/doc/html/rfc5702); and * properly handle the security concerns enumerated in [RFC 6840 Section 4](https://datatracker.ietf.org/doc/html/rfc6840#section-4). @@ -794,8 +794,8 @@ This method has been retired and MUST NOT be used. Prior validations using this ##### 3.2.2.4.7 DNS Change -Confirming the Applicant's control over the FQDN by confirming the presence of a Random Value or Request Token in a DNS CNAME, TXT or CAA record for either - 1. an Authorization Domain Name; or +Confirming the Applicant's control over the FQDN by confirming the presence of a Random Value or Request Token in a DNS CNAME, TXT or CAA record for either + 1. an Authorization Domain Name; or 2. an Authorization Domain Name that is prefixed with a Domain Label that begins with an underscore character. 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 @@ -1110,7 +1110,7 @@ CAs MUST document potential issuances that were prevented by a CAA record in suf Effective March 15th, 2026: DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with CAA record lookups performed by the Primary Network Perspective MUST: * perform DNSSEC validation using the algorithm defined in [RFC 4035 Section 5](https://datatracker.ietf.org/doc/html/rfc4035#section-5); and -* support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and +* support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and * support SHA-2 as defined in [RFC 4509](https://datatracker.ietf.org/doc/html/rfc4509) and [RFC 5702](https://datatracker.ietf.org/doc/html/rfc5702); and * properly handle the security concerns enumerated in [RFC 6840 Section 4](https://datatracker.ietf.org/doc/html/rfc6840#section-4). @@ -1133,7 +1133,7 @@ The set of responses from the relied upon Network Perspectives MUST provide the * a. the presence of the expected 1) Random Value, 2) Request Token, 3) IP Address, or 4) Contact Address, as required by the relied upon validation method specified in Sections 3.2.2.4 and 3.2.2.5; and * b. the CA's authority to issue to the requested domain(s), as specified in Section 3.2.2.8. -[Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) and [Section 3.2.2.5](#3225-authentication-for-an-ip-address) describe the validation methods that require the use of Multi-Perspective Issuance Corroboration and how a Network Perspective can corroborate the outcomes determined by the Primary Network Perspective. +[Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) and [Section 3.2.2.5](#3225-authentication-for-an-ip-address) describe the validation methods that require the use of Multi-Perspective Issuance Corroboration and how a Network Perspective can corroborate the outcomes determined by the Primary Network Perspective. Results or information obtained from one Network Perspective MUST NOT be reused or cached when performing validation through subsequent Network Perspectives (e.g., different Network Perspectives cannot rely on a shared DNS cache to prevent an adversary with control of traffic from one Network Perspective from poisoning the DNS cache used by other Network Perspectives). The network infrastructure providing Internet connectivity to a Network Perspective MAY be administered by the same organization providing the computational services required to operate the Network Perspective. All communications between a remote Network Perspective and the CA MUST take place over an authenticated and encrypted channel relying on modern protocols (e.g., over HTTPS). @@ -1157,12 +1157,12 @@ Remote Network Perspectives performing Multi-Perspective Issuance Corroboration: MUST: - Network Hardening - - Rely upon networks (e.g., Internet Service Providers or Cloud Provider Networks) implementing measures to mitigate BGP routing incidents in the global Internet routing system for providing internet connectivity to the Network Perspective. + - Rely upon networks (e.g., Internet Service Providers or Cloud Provider Networks) implementing measures to mitigate BGP routing incidents in the global Internet routing system for providing internet connectivity to the Network Perspective. SHOULD: - Facility & Service Provider Requirements - - Be hosted from an ISO/IEC 27001 certified facility or equivalent security framework independently audited and certified or reported. + - Be hosted from an ISO/IEC 27001 certified facility or equivalent security framework independently audited and certified or reported. - Rely on services covered in one of the following reports: System and Organization Controls 2 (SOC 2), ISAE 3000, ENISA 715, FedRAMP Moderate, C5:2020, CSA STAR CCM, or equivalent services framework independently audited and certified or reported. - Vulnerability Detection and Patch Management - Implement intrusion detection and prevention controls to protect against common network and system threats. @@ -1177,13 +1177,13 @@ SHOULD: - Configure each network boundary control (firewall, switch, router, gateway, or other network control device or system) with rules that support only the services, protocols, ports, and communications identified as necessary to its operations. - Rely upon networks (e.g., Internet Service Providers) that: 1) use mechanisms based on Secure Inter-Domain Routing (RFC 6480), for example, BGP Prefix Origin Validation (RFC 6811), 2) make use of other non-RPKI route-leak prevention mechanisms (such as RFC 9234), and 3) apply current best practices described in BCP 194. While It is RECOMMENDED that under normal operating conditions Network Perspectives performing Multi-Perspective Issuance Corroboration forward all Internet traffic via a network or set of networks that filter RPKI-invalid BGP routes as defined by RFC 6811, it is NOT REQUIRED. -Beyond the above considerations, computing systems performing Multi-Perspective Issuance Corroboration are considered outside of the audit scope described in Section 8 of these Requirements. +Beyond the above considerations, computing systems performing Multi-Perspective Issuance Corroboration are considered outside of the audit scope described in Section 8 of these Requirements. If any of the above considerations are performed by a Delegated Third Party, the CA MAY obtain reasonable evidence from the Delegated Third Party to ascertain assurance that one or more of the above considerations are followed. As an exception to Section 1.3.2, Delegated Third Parties are not required to be within the audit scope described in Section 8 of these Requirements to satisfy the above considerations. Phased Implementation Timeline: -- *Effective September 15, 2024*, the CA SHOULD implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. +- *Effective September 15, 2024*, the CA SHOULD implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. - *Effective March 15, 2025*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MAY proceed with certificate issuance if the number of remote Network Perspectives that do not corroborate the determinations made by the Primary Network Perspective ("non-corroborations") is greater than allowed in the Quorum Requirements table. - *Effective September 15, 2025*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. - *Effective March 15, 2026*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least three (3) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. @@ -1307,14 +1307,14 @@ Methods used to produce a certificate containing the to-be-signed Certificate co 1. Sign the `tbsCertificate` with a "dummy" Private Key whose Public Key component is not certified by a Certificate that chains to a publicly-trusted CA Certificate; or 2. Specify a static value for the `signature` field of the Certificate ASN.1 SEQUENCE. -CAs MAY implement their own certificate Linting tools, but CAs SHOULD use the Linting tools that have been widely adopted by the industry (see https://cabforum.org/resources/tools/). +CAs MAY implement their own certificate Linting tools, but CAs SHOULD use the Linting tools that have been widely adopted by the industry (see https://cabforum.org/resources/tools/). CAs are encouraged to contribute to open-source Linting projects, such as by: - creating new or improving existing lints, - reporting potentially inaccurate linting results as bugs, - notifying maintainers of Linting software of checks that are not covered by existing lints, -- updating documentation of existing lints, and +- updating documentation of existing lints, and - generating test certificates for positive/negative tests of specific lints. #### 4.3.1.3 Linting of issued Certificates @@ -1521,9 +1521,9 @@ Within twenty-four (24) hours of issuing its first Certificate, the CA MUST gene - partitioned (i.e., "sharded") CRLs that, when aggregated, represent the equivalent of a full and complete CRL. CAs issuing Subscriber Certificates: -1. MUST update and publish a new CRL at least every: +1. MUST update and publish a new CRL at least every: - seven (7) days if all Certificates include an Authority Information Access extension with an id-ad-ocsp accessMethod ("AIA OCSP pointer"); or - - four (4) days in all other cases; + - four (4) days in all other cases; 2. MUST update and publish a new CRL within twenty-four (24) hours after recording a Certificate as revoked. CAs issuing CA Certificates: @@ -1744,8 +1744,8 @@ The CA SHALL record at least the following events: 1. Certificate requests, renewal, and re-key requests, and revocation; 2. All verification activities stipulated in these Requirements and the CA's Certification Practice Statement; 3. Approval and rejection of certificate requests; - 4. Issuance of Certificates; - 5. Generation of Certificate Revocation Lists; and + 4. Issuance of Certificates; + 5. Generation of Certificate Revocation Lists; and 6. Signing of OCSP Responses (as described in [Section 4.9](#49-certificate-revocation-and-suspension) and [Section 4.10](#410-certificate-status-services)). 7. Multi-Perspective Issuance Corroboration attempts from each Network Perspective, minimally recording the following information: 1. an identifier that uniquely identifies the Network Perspective used; @@ -2216,7 +2216,7 @@ The extKeyUsage extension MAY be "unrestricted" as described in the following ta - the organizationName represented in the Issuer and Subject names of the corresponding certificate are either: - the same, or - the organizationName represented in the Subject name is an affiliate of the organizationName represented in the Issuer name -- the corresponding CA represented by the Subject of the Cross-Certificate is operated by the same organization as the Issuing CA or an Affiliate of the Issuing CA organization. +- the corresponding CA represented by the Subject of the Cross-Certificate is operated by the same organization as the Issuing CA or an Affiliate of the Issuing CA organization. Table: Cross-Certified Subordinate CA with Unrestricted EKU @@ -2580,7 +2580,7 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in ##### 7.1.2.7.1 Subscriber Certificate Types -There are four types of Subscriber Certificates that may be issued, which vary based on the amount of Subject Information that is included. Each of these certificate types shares a common profile, with three exceptions: the `subject` name fields that may occur, how those fields are validated, and the contents of the `certificatePolicies` extension. +There are four types of Subscriber Certificates that may be issued, which vary based on the amount of Subject Information that is included. Each of these certificate types shares a common profile, with three exceptions: the `subject` name fields that may occur, how those fields are validated, and the contents of the `certificatePolicies` extension. | **Type** | **Description** | | ---- | ------ | @@ -2708,7 +2708,7 @@ In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '- | `subjectKeyIdentifier` | NOT RECOMMENDED | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | -**Notes**: +**Notes**: - whether or not the `subjectAltName` extension should be marked Critical depends on the contents of the Certificate's `subject` field, as detailed in [Section 7.1.2.7.12](#712712-subscriber-certificate-subject-alternative-name). - whether or not the CRL Distribution Points extension must be present depends on 1) whether the Certificate includes an Authority Information Access extension with an id-ad-ocsp accessMethod and 2) the Certificate's validity period, as detailed in [Section 7.1.2.11.2](#712112-crl-distribution-points). @@ -3507,7 +3507,7 @@ A full and complete CRL is a CRL whose scope includes all Certificates issued by A partitioned CRL (sometimes referred to as a "sharded CRL") is a CRL with a constrained scope, such as all Certificates issued by the CA during a certain period of time ("temporal sharding"). Aside from the presence of the Issuing Distribution Point extension (OID 2.5.29.28) in partitioned CRLs, both CRL formats are syntactically the same from the perspective of this profile. -Minimally, CAs MUST issue either a "full and complete" CRL or a set of "partitioned" CRLs which cover the complete set of Certificates issued by the CA within 7 days of such CA issuing its first certificate. In other words, if issuing only partitioned CRLs, the combined scope of those CRLs must be equivalent to that of a full and complete CRL. +Minimally, CAs MUST issue either a "full and complete" CRL or a set of "partitioned" CRLs which cover the complete set of Certificates issued by the CA within 7 days of such CA issuing its first certificate. In other words, if issuing only partitioned CRLs, the combined scope of those CRLs must be equivalent to that of a full and complete CRL. CAs MUST NOT issue indirect CRLs (i.e., the issuer of the CRL is not the issuer of all Certificates that are included in the scope of the CRL). @@ -3547,12 +3547,12 @@ Table: revokedCertificates Component | **Component** | **Presence** | **Description** | | ---- | - | ----- | | `serialNumber` | MUST | MUST be byte-for-byte identical to the serialNumber contained in the revoked Certificate. | -| `revocationDate` | MUST | Normally, the date and time revocation occurred. See the footnote following this table for circumstances where backdating is permitted. | +| `revocationDate` | MUST | Normally, the date and time revocation occurred. See the footnote following this table for circumstances where backdating is permitted. | | `crlEntryExtensions` | * | See the "crlEntryExtensions Component" table for additional requirements. | **Note:** The CA SHOULD update the revocation date in a CRL entry when it is determined that the private key of the Certificate was compromised prior to the revocation date that is indicated in the CRL entry for that Certificate. Backdating the revocationDate field is an exception to best practice described in RFC 5280 (Section 5.3.2); however, these requirements specify the use of the revocationDate field to support TLS implementations that process the revocationDate field as the date when the Certificate is first considered to be compromised. -Table: crlEntryExtensions Component +Table: crlEntryExtensions Component | **CRL Entry Extension** | **Presence** | **Description** | | --- | -- | ----- | @@ -3563,7 +3563,7 @@ Table: CRLReasons | **RFC 5280 reasonCode** | **RFC 5280 reasonCode value** | **Description** | | --- | - | ------ | -| unspecified | 0 | Represented by the omission of a reasonCode. MUST be omitted if the CRL entry is for a Certificate not technically capable of causing issuance unless the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to July 15, 2023. +| unspecified | 0 | Represented by the omission of a reasonCode. MUST be omitted if the CRL entry is for a Certificate not technically capable of causing issuance unless the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to July 15, 2023. | keyCompromise | 1 | Indicates that it is known or suspected that the Subscriber’s Private Key has been compromised. | | affiliationChanged | 3 | Indicates that the Subject's name or other Subject Identity Information in the Certificate has changed, but there is no cause to suspect that the Certificate's Private Key has been compromised. | | superseded | 4 | Indicates that the Certificate is being replaced because: the Subscriber has requested a new Certificate, the CA has reasonable evidence that the validation of domain authorization or control for any fully‐qualified domain name or IP address in the Certificate should not be relied upon, or the CA has revoked the Certificate for compliance reasons such as the Certificate does not comply with these Baseline Requirements or the CA's CP or CPS. | @@ -3571,11 +3571,11 @@ Table: CRLReasons | certificateHold | 6 | MUST NOT be included if the CRL entry is for 1) a Certificate subject to these Requirements, or 2) a Certificate not subject to these Requirements and was either A) issued on-or-after 2020-09-30 or B) has a `notBefore` on-or-after 2020-09-30. | privilegeWithdrawn | 9 | Indicates that there has been a subscriber-side infraction that has not resulted in keyCompromise, such as the Certificate Subscriber provided misleading information in their Certificate Request or has not upheld their material obligations under the Subscriber Agreement or Terms of Use. | -The Subscriber Agreement, or an online resource referenced therein, MUST inform Subscribers about the revocation reason options listed above and provide explanation about when to choose each option. Tools that the CA provides to the Subscriber MUST allow for these options to be easily specified when the Subscriber requests revocation of their Certificate, with the default value being that no revocation reason is provided (i.e. the default corresponds to the CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL). +The Subscriber Agreement, or an online resource referenced therein, MUST inform Subscribers about the revocation reason options listed above and provide explanation about when to choose each option. Tools that the CA provides to the Subscriber MUST allow for these options to be easily specified when the Subscriber requests revocation of their Certificate, with the default value being that no revocation reason is provided (i.e. the default corresponds to the CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL). The privilegeWithdrawn reasonCode SHOULD NOT be made available to the Subscriber as a revocation reason option, because the use of this reasonCode is determined by the CA and not the Subscriber. -When a CA obtains verifiable evidence of Key Compromise for a Certificate whose CRL entry does not contain a reasonCode extension or has a reasonCode extension with a non-keyCompromise reason, the CA SHOULD update the CRL entry to enter keyCompromise as the CRLReason in the reasonCode extension. +When a CA obtains verifiable evidence of Key Compromise for a Certificate whose CRL entry does not contain a reasonCode extension or has a reasonCode extension with a non-keyCompromise reason, the CA SHOULD update the CRL entry to enter keyCompromise as the CRLReason in the reasonCode extension. #### 7.2.2.1 CRL Issuing Distribution Point @@ -3587,11 +3587,11 @@ Partitioned CRLs MUST contain an Issuing Distribution Point extension. The `dist The `indirectCRL` and `onlyContainsAttributeCerts` fields MUST be set to `FALSE` (i.e., not asserted). -The CA MAY set either of the `onlyContainsUserCerts` and `onlyContainsCACerts` fields to `TRUE`, depending on the scope of the CRL. +The CA MAY set either of the `onlyContainsUserCerts` and `onlyContainsCACerts` fields to `TRUE`, depending on the scope of the CRL. -The CA MUST NOT assert both of the `onlyContainsUserCerts` and `onlyContainsCACerts` fields. +The CA MUST NOT assert both of the `onlyContainsUserCerts` and `onlyContainsCACerts` fields. -The `onlySomeReasons` field SHOULD NOT be included; if included, then the CA MUST provide another CRL whose scope encompasses all revocations regardless of reason code. +The `onlySomeReasons` field SHOULD NOT be included; if included, then the CA MUST provide another CRL whose scope encompasses all revocations regardless of reason code. This extension is NOT RECOMMENDED for full and complete CRLs. @@ -3690,7 +3690,7 @@ The Audit Report MUST be available as a PDF, and SHALL be text searchable for al ## 8.7 Self-Audits -During the period in which the CA issues Certificates, the CA SHALL monitor adherence to its Certificate Policy, Certification Practice Statement and these Requirements and strictly control its service quality by performing self audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken. +During the period in which the CA issues Certificates, the CA SHALL monitor adherence to its Certificate Policy, Certification Practice Statement and these Requirements and strictly control its service quality by performing self audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken. Effective 2025-03-15, the CA SHOULD use a Linting process to verify the technical accuracy of Certificates within the selected sample set independently of previous linting performed on the same Certificates. diff --git a/docs/EVG.md b/docs/EVG.md index 57476eb7..46d9d534 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -158,7 +158,7 @@ EV Certificates focus only on the identity of the Subject named in the Certifica 2. That the Subject named in the EV Certificate complies with applicable laws; 3. That the Subject named in the EV Certificate is trustworthy, honest, or reputable in its business dealings; or 4. That it is "safe" to do business with the Subject named in the EV Certificate. - + ## 1.5 Policy administration ### 1.5.1 Organization administering the document @@ -968,9 +968,9 @@ A CA may rely on a previously verified certificate request to issue a replacemen 3. The CA MAY reuse a previously submitted EV Certificate Request, Subscriber Agreement, or Terms of Use, including use of a single EV Certificate Request in support of multiple EV Certificates containing the same Subject to the extent permitted under [Section 3.2.2.9](#3229-verification-of-signature-on-subscriber-agreement-and-ev-certificate-requests) and [Section 3.2.2.10](#32210-verification-of-approval-of-ev-certificate-request). 4. The CA MUST repeat the verification process required in these Guidelines for any information obtained outside the time limits specified above except when permitted otherwise under [Section 3.2.2.14.1](#322141-validation-for-existing-subscribers). -### 3.2.3 Authentication of individual identity +### 3.2.3 Authentication of individual identity -### 3.2.4 Non-verified subscriber information +### 3.2.4 Non-verified subscriber information ### 3.2.5 Validation of authority @@ -1198,7 +1198,7 @@ Root CA Private Keys MUST NOT be used to sign EV Certificates. ### 4.12.2 Session key encapsulation and recovery policy and practices -# 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS +# 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS As specified in Section 5 of the Baseline Requirements. In addition, systems used to process and approve EV Certificate Requests MUST require actions by at least two trusted persons before creating an EV Certificate. @@ -1232,7 +1232,7 @@ As specified in Section 5 of the Baseline Requirements. In addition, systems use 1. The CA MUST enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the issuance of an EV Certificate. The Final Cross-Correlation and Due Diligence steps, as outlined in [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence), MAY be performed by one of the persons. For example, one Validation Specialist MAY review and verify all the Applicant information and a second Validation Specialist MAY approve issuance of the EV Certificate. 2. Such controls MUST be auditable. - + ## 5.3 Personnel controls ### 5.3.1 Qualifications, experience, and clearance requirements @@ -1323,7 +1323,7 @@ As specified in Section 5.4 of the Baseline Requirements. ## 5.8 CA or RA termination -# 6. TECHNICAL SECURITY CONTROLS +# 6. TECHNICAL SECURITY CONTROLS ## 6.1 Key pair generation and installation @@ -1541,7 +1541,7 @@ Effective as of 1 October 2020, if the CA has disclosed a set of acceptable form ##### 7.1.4.2.7 Subject Organizational Unit Name Field **Certificate Field**: `subject:organizationalUnitName` (OID: 2.5.4.11) -**Required/Optional/Prohibited**: **Prohibited**. +**Required/Optional/Prohibited**: **Prohibited**. ##### 7.1.4.2.8 Subject Organization Identifier Field @@ -2140,7 +2140,7 @@ The following Registration Schemes are currently recognized as valid under these Section 7.1.4.2.5](#71425-subject-registration-number-field)) within the context of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). - For the purpose of identifying tax authorities, the country prefix described in article 215 of + For the purpose of identifying tax authorities, the country prefix described in article 215 of EU Council Directive 2006/112/EC, as amended, MAY be used instead of the ISO 3166 2-letter country codes. * **PSD**: From 7fb83b4e17db098378c39a5a9127b6b489f2ee18 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 06:48:45 +0100 Subject: [PATCH 037/121] #432 table spaces removed, headers format changed --- docs/BR.md | 260 ++++++++++++++++++++++++++--------------------------- 1 file changed, 130 insertions(+), 130 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index daab9115..8ff473dc 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -45,140 +45,140 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse ### 1.2.1 Revisions -| **Ver.** | **Ballot** | **Description** | **Adopted** | **Effective\*** | -|-------------|-------------|---------------------------------------------------|---------------|-----------------| -| 1.0.0 | 62 | Version 1.0 of the Baseline Requirements Adopted | 22-Nov-11 | 01-Jul-12 | -| 1.0.1 | 71 | Revised Auditor Qualifications | 08-May-12 | 01-Jan-13 | -| 1.0.2 | 75 | Non-critical Name Constraints allowed as exception to RFC 5280 | 08-Jun-12 | 08-Jun-12 | -| 1.0.3 | 78 | Revised Domain/IP Address Validation, High Risk Requests, and Data Sources | 22-Jun-12 | 22-Jun-12 | -| 1.0.4 | 80 | OCSP responses for non-issued certificates | 02-Aug-12 | 01-Feb-13 01-Aug-13 | -| -- | 83 | Network and Certificate System Security Requirements adopted | 03-Aug-13 | 01-Jan-13 | -| 1.0.5 | 88 | User-assigned country code of XX allowed | 12-Sep-12 | 12-Sep-12 | -| 1.1.0 | -- | Published as Version 1.1 with no changes from 1.0.5 | 14-Sep-12 | 14-Sep-12 | -| 1.1.1 | 93 | Reasons for Revocation and Public Key Parameter checking | 07-Nov-12 | 07-Nov-12 01-Jan-13 | -| 1.1.2 | 96 | Wildcard certificates and new gTLDs | 20-Feb-13 | 20-Feb-13 01-Sep-13 | -| 1.1.3 | 97 | Prevention of Unknown Certificate Contents | 21-Feb-13 | 21-Feb-13 | -| 1.1.4 | 99 | Add DSA Keys (BR v.1.1.4) | 3-May-2013 | 3-May-2013 | -| 1.1.5 | 102 | Revision to subject domainComponent language in Section 9.2.3 | 31-May-2013 | 31-May-2013 | -| 1.1.6 | 105 | Technical Constraints for Subordinate Certificate Authorities | 29-Jul-2013 | 29-Jul-2013 | -| 1.1.7 | 112 | Replace Definition of "Internal Server Name" with "Internal Name" | 3-Apr-2014 | 3-Apr-2014 | -| 1.1.8 | 120 | Affiliate Authority to Verify Domain | 5-Jun-2014 | 5-Jun-2014 | -| 1.1.9 | 129 | Clarification of PSL mentioned in Section 11.1.3 | 4-Aug-2014 | 4-Aug-2014 | -| 1.2.0 | 125 | CAA Records | 14-Oct-2014 | 15-Apr-2015 | -| 1.2.1 | 118 | SHA-1 Sunset | 16-Oct-2014 | 16-Jan-2015 1-Jan-2016 1-Jan-2017 | -| 1.2.2 | 134 | Application of RFC 5280 to Pre-certificates | 16-Oct-2014 | 16-Oct-2014 | -| 1.2.3 | 135 | ETSI Auditor Qualifications | 16-Oct-2014 | 16-Oct-2014 | -| 1.2.4 | 144 | Validation Rules for .onion Names | 18-Feb-2015 | 18-Feb-2015 | -| 1.2.5 | 148 | Issuer Field Correction | 2-Apr-2015 | 2-Apr-2015 | -| 1.3.0 | 146 | Convert Baseline Requirements to RFC 3647 Framework | 16-Apr-2015 | 16-Apr-2015 | -| 1.3.1 | 151 | Addition of Optional OIDs for Indicating Level of Validation | 28-Sep-2015 | 28-Sep-2015 | -| 1.3.2 | 156 | Amend Sections 1 and 2 of Baseline Requirements | 3-Dec-2015 | 3-Dec-2016 | -| 1.3.3 | 160 | Amend Section 4 of Baseline Requirements | 4-Feb-2016 | 4-Feb-2016 | -| 1.3.4 | 162 | Sunset of Exceptions | 15-Mar-2016 | 15-Mar-2016 | -| 1.3.5 | 168 | Baseline Requirements Corrections (Revised) | 10-May-2016 | 10-May-2016 | -| 1.3.6 | 171 | Updating ETSI Standards in CABF documents | 1-Jul-2016 | 1-Jul-2016 | -| 1.3.7 | 164 | Certificate Serial Number Entropy | 8-Jul-2016 | 30-Sep-2016 | -| 1.3.8 | 169 | Revised Validation Requirements | 5-Aug-2016 | 1-Mar-2017 | -| 1.3.9 | 174 | Reform of Requirements Relating to Conflicts with Local Law | 29-Aug-2016 | 27-Nov-2016 | -| 1.4.0 | 173 | Removal of requirement to cease use of public key due to incorrect info | 28-Jul-2016 | 11-Sep-2016 | -| 1.4.1 | 175 | Addition of givenName and surname | 7-Sep-2016 | 7-Sep-2016 | -| 1.4.2 | 181 | Removal of some validation methods listed in Section 3.2.2.4 | 7-Jan-2017 | 7-Jan-2017 | -| 1.4.3 | 187 | Make CAA Checking Mandatory | 8-Mar-2017 | 8-Sep-2017 | -| 1.4.4 | 193 | 825-day Certificate Lifetimes | 17-Mar-2017 | 1-Mar-2018 | -| 1.4.5 | 189 | Amend Section 6.1.7 of Baseline Requirements | 14-Apr-2017 | 14-May-2017 | -| 1.4.6 | 195 | CAA Fixup | 17-Apr-2017 | 18-May-2017 | -| 1.4.7 | 196 | Define "Audit Period" | 17-Apr-2017 | 18-May-2017 | -| 1.4.8 | 199 | Require commonName in Root and Intermediate Certificates | 9-May-2017 | 8-Jun-2017 | -| 1.4.9 | 204 | Forbid DTPs from doing Domain/IP Ownership | 11-Jul-2017 | 11-Aug-2017 | -| 1.5.0 | 212 | Canonicalise formal name of the Baseline Requirements | 1-Sep-2017 | 1-Oct-2017 | -| 1.5.1 | 197 | Effective Date of Ballot 193 Provisions | 1-May-2017 | 2-Jun-2017 | -| 1.5.2 | 190 | Add Validation Methods with Minor Corrections | 19-Sep-2017 | 19-Oct-2017 | -| 1.5.3 | 214 | CAA Discovery CNAME Errata | 27-Sep-2017 | 27-Oct-2017 | -| 1.5.4 | 215 | Fix Ballot 190 Errata | 4‐Oct‐2017 | 5‐Nov‐2017 | -| 1.5.5 | 217 | Sunset RFC 2527 | 21‐Dec‐2017 | 9‐Mar‐2018 | -| 1.5.6 | 218 | Remove validation methods #1 and #5 | 5‐Feb‐2018 | 9‐Mar‐2018 | -| 1.5.7 | 220 | Minor Cleanups (Spring 2018) | 30‐Mar‐2018 | 29‐Apr‐2018 | -| 1.5.8 | 219 | Clarify handling of CAA Record Sets with no "issue"/"issuewild" property tag | 10-Apr-2018 | 10-May-2018 | -| 1.5.9 | 223 | Update BR Section 8.4 for CA audit criteria | 15-May-2018 | 14-June-2018 | -| 1.6.0 | 224 | WhoIs and RDAP | 22-May-2018 | 22-June-2018 | -| 1.6.1 | SC6 | Revocation Timeline Extension | 14-Sep-2018 | 14-Oct-2018 | -| 1.6.2 | SC12 | Sunset of Underscores in dNSNames | 9-Nov-2018 | 10-Dec-2018 | -| 1.6.3 | SC13 | CAA Contact Property and Associated E-mail Validation Methods | 25-Dec-2018 | 1-Feb-2019 | -| 1.6.4 | SC14 | Updated Phone Validation Methods | 31-Jan-2019 | 16-Mar-2019 | -| 1.6.4 | SC15 | Remove Validation Method Number 9 | 5-Feb-2019 | 16-Mar-2019 | -| 1.6.4 | SC7 | Update IP Address Validation Methods | 8-Feb-2019 | 16-Mar-2019 | -| 1.6.5 | SC16 | Other Subject Attributes | 15-Mar-2019 | 16-Apr-2019 | -| 1.6.6 | SC19 | Phone Contact with DNS CAA Phone Contact v2 | 20-May-2019 | 9-Sep-2019 | -| 1.6.7 | SC23 | Precertificates | 14-Nov-2019 | 19-Dec-2019 | -| 1.6.7 | SC24 | Fall Cleanup v2 | 12-Nov-2019 | 19-Dec-2019 | -| 1.6.8 | SC25 | Define New HTTP Domain Validation Methods v2 | 31-Jan-2020 | 3-Mar-2020 | -| 1.6.9 | SC27 | Version 3 Onion Certificates | 19-Feb-2020 | 27-Mar-2020 | -| 1.7.0 | SC29 | Pandoc-Friendly Markdown Formatting Changes | 20-Mar-2020 | 4-May-2020 | -| 1.7.1 | SC30 | Disclosure of Registration / Incorporating Agency | 13-Jul-2020 | 20-Aug-2020 | -| 1.7.1 | SC31 | Browser Alignment | 16-Jul-2020 | 20-Aug-2020 | -| 1.7.2 | SC33 | TLS Using ALPN Method | 14-Aug-2020 | 22-Sept-2020 | -| 1.7.3 | SC28 | Logging and Log Retention | 10-Sep-2020 | 19-Oct-2020 | -| 1.7.3 | SC35 | Cleanups and Clarifications | 9-Sep-2020 | 19-Oct-2020 | -| 1.7.4 | SC41 | Reformat the BRs, EVGs, and NCSSRs | 24-Feb-2021 | 5-Apr-2021 | -| 1.7.5 | SC42 | 398-day Re-use Period | 22-Apr-2021 | 2-Jun-2021 | -| 1.7.6 | SC44 | Clarify Acceptable Status Codes | 30-Apr-2021 | 3-Jun-2021 | -| 1.7.7 | SC46 | Sunset the CAA Exception for DNS Operator | 2-Jun-2021 | 12-Jul-2021 | -| 1.7.8 | SC45 | Wildcard Domain Validation | 2-Jun-2021 | 13-Jul-2021 | -| 1.7.9 | SC47 | Sunset subject:organizationalUnitName | 30-Jun-2021 | 16-Aug-2021 | -| 1.8.0 | SC48 | Domain Name and IP Address Encoding | 22-Jul-2021 | 25-Aug-2021 | -| 1.8.1 | SC50 | Remove the requirements of 4.1.1 | 22-Nov-2021 | 23-Dec-2021 | -| 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 | -| 1.8.7 | SC61 | New CRL entries must have a Revocation Reason Code | 1-Apr-2023 | 15-Jul-2023 | -| 2.0.0 | SC62 | Certificate Profiles Update | 22-Apr-2023 | 15-Sep-2023 | -| 2.0.1 | SC63 | Make OCSP optional, require CRLs, and incentivize automation | 17-Aug-2023 | 15-Mar-2024 | -| 2.0.2 | SC66 | 2023 Cleanup | 23-Nov-2023 | 8-Jan-2024 | -| 2.0.3 | SC69 | Clarify router and firewall logging requirements | 13-Mar-2024 | 15-Apr-2024 | -| 2.0.4 | SC65 | Convert EVGs into RFC 3647 format | 15-Mar-2024 | 15-May-2024 | -| 2.0.5 | SC73 | Compromised and weak keys | 3-May-2024 | 1-Jul-2024 | -| 2.0.6 | SC75 | Pre-sign linting | 28-Jun-2024 | 6-Aug-2024 | -| 2.0.7 | SC67 | Require Multi-Perspective Issuance Corroboration | 2-Aug-2024 | 6-Sep-2024 | -| 2.0.8 | SC77 | Update WebTrust Audit name in Section 8.4 and References | 2-Sep-2024 | 2-Oct-2024 | -| 2.0.9 | SC78 | Subject organizationName alignment for DBA / Assumed Name | 2-Oct-2024 | 8-Nov-2024 | -| 2.1.0 | SC76 | Clarify and improve OCSP requirements | 26-Sep-2024 | 14-Nov-2024 | -| 2.1.1 | SC79 | Allow more than one Certificate Policy in a Cross-Certified Subordinate CA Certificate | 30-Sep-2024 | 14-Nov-2024 | -| 2.1.2 | SC80 | Strengthen WHOIS lookups and Sunset Methods 3.2.2.4.2 and 3.2.2.4.15 | 7-Nov-2024 | 16-Dec-2024 | -| 2.1.3 | SC83 | Winter 2024-2025 Cleanup Ballot | 23-Jan-2025 | 24-Feb-2025 | -| 2.1.4 | SC84 | DNS Labeled with ACME Account ID Validation Method | 28-Jan-2025 | 1-Mar-2025 | -| 2.1.5 | SC81 | Introduce Schedule of Reducing Validity and Data Reuse Periods | 11-Apr-2025 | 16-May-2025 | -| 2.1.6 | SC85 | Require Validation of DNSSEC (when present) for CAA and DCV Lookups | 19-Jun-2025 | 21-Jul-2025 | -| 2.1.7 | SC089 | Mass Revocation Planning | 23-Jul-2025 | 25-Aug-2025 | +| Ver. | Ballot | **Description** | Adopted | Effective\* | +| :---: | --- | --- | --- | --- | +| 1.0.0 | 62 | Version 1.0 of the Baseline Requirements Adopted | 22-Nov-11 | 01-Jul-12 | +| 1.0.1 | 71 | Revised Auditor Qualifications | 08-May-12 | 01-Jan-13 | +| 1.0.2 | 75 | Non-critical Name Constraints allowed as exception to RFC 5280 | 08-Jun-12 | 08-Jun-12 | +| 1.0.3 | 78 | Revised Domain/IP Address Validation, High Risk Requests, and Data Sources | 22-Jun-12 | 22-Jun-12 | +| 1.0.4 | 80 | OCSP responses for non-issued certificates | 02-Aug-12 | 01-Feb-13 01-Aug-13 | +| -- | 83 | Network and Certificate System Security Requirements adopted | 03-Aug-13 | 01-Jan-13 | +| 1.0.5 | 88 | User-assigned country code of XX allowed | 12-Sep-12 | 12-Sep-12 | +| 1.1.0 | -- | Published as Version 1.1 with no changes from 1.0.5 | 14-Sep-12 | 14-Sep-12 | +| 1.1.1 | 93 | Reasons for Revocation and Public Key Parameter checking | 07-Nov-12 | 07-Nov-12 01-Jan-13 | +| 1.1.2 | 96 | Wildcard certificates and new gTLDs | 20-Feb-13 | 20-Feb-13 01-Sep-13 | +| 1.1.3 | 97 | Prevention of Unknown Certificate Contents | 21-Feb-13 | 21-Feb-13 | +| 1.1.4 | 99 | Add DSA Keys (BR v.1.1.4) | 3-May-2013 | 3-May-2013 | +| 1.1.5 | 102 | Revision to subject domainComponent language in Section 9.2.3 | 31-May-2013 | 31-May-2013 | +| 1.1.6 | 105 | Technical Constraints for Subordinate Certificate Authorities | 29-Jul-2013 | 29-Jul-2013 | +| 1.1.7 | 112 | Replace Definition of "Internal Server Name" with "Internal Name" | 3-Apr-2014 | 3-Apr-2014 | +| 1.1.8 | 120 | Affiliate Authority to Verify Domain | 5-Jun-2014 | 5-Jun-2014 | +| 1.1.9 | 129 | Clarification of PSL mentioned in Section 11.1.3 | 4-Aug-2014 | 4-Aug-2014 | +| 1.2.0 | 125 | CAA Records | 14-Oct-2014 | 15-Apr-2015 | +| 1.2.1 | 118 | SHA-1 Sunset | 16-Oct-2014 | 16-Jan-2015 1-Jan-2016 1-Jan-2017 | +| 1.2.2 | 134 | Application of RFC 5280 to Pre-certificates | 16-Oct-2014 | 16-Oct-2014 | +| 1.2.3 | 135 | ETSI Auditor Qualifications | 16-Oct-2014 | 16-Oct-2014 | +| 1.2.4 | 144 | Validation Rules for .onion Names | 18-Feb-2015 | 18-Feb-2015 | +| 1.2.5 | 148 | Issuer Field Correction | 2-Apr-2015 | 2-Apr-2015 | +| 1.3.0 | 146 | Convert Baseline Requirements to RFC 3647 Framework | 16-Apr-2015 | 16-Apr-2015 | +| 1.3.1 | 151 | Addition of Optional OIDs for Indicating Level of Validation | 28-Sep-2015 | 28-Sep-2015 | +| 1.3.2 | 156 | Amend Sections 1 and 2 of Baseline Requirements | 3-Dec-2015 | 3-Dec-2016 | +| 1.3.3 | 160 | Amend Section 4 of Baseline Requirements | 4-Feb-2016 | 4-Feb-2016 | +| 1.3.4 | 162 | Sunset of Exceptions | 15-Mar-2016 | 15-Mar-2016 | +| 1.3.5 | 168 | Baseline Requirements Corrections (Revised) | 10-May-2016 | 10-May-2016 | +| 1.3.6 | 171 | Updating ETSI Standards in CABF documents | 1-Jul-2016 | 1-Jul-2016 | +| 1.3.7 | 164 | Certificate Serial Number Entropy | 8-Jul-2016 | 30-Sep-2016 | +| 1.3.8 | 169 | Revised Validation Requirements | 5-Aug-2016 | 1-Mar-2017 | +| 1.3.9 | 174 | Reform of Requirements Relating to Conflicts with Local Law | 29-Aug-2016 | 27-Nov-2016 | +| 1.4.0 | 173 | Removal of requirement to cease use of public key due to incorrect info | 28-Jul-2016 | 11-Sep-2016 | +| 1.4.1 | 175 | Addition of givenName and surname | 7-Sep-2016 | 7-Sep-2016 | +| 1.4.2 | 181 | Removal of some validation methods listed in Section 3.2.2.4 | 7-Jan-2017 | 7-Jan-2017 | +| 1.4.3 | 187 | Make CAA Checking Mandatory | 8-Mar-2017 | 8-Sep-2017 | +| 1.4.4 | 193 | 825-day Certificate Lifetimes | 17-Mar-2017 | 1-Mar-2018 | +| 1.4.5 | 189 | Amend Section 6.1.7 of Baseline Requirements | 14-Apr-2017 | 14-May-2017 | +| 1.4.6 | 195 | CAA Fixup | 17-Apr-2017 | 18-May-2017 | +| 1.4.7 | 196 | Define "Audit Period" | 17-Apr-2017 | 18-May-2017 | +| 1.4.8 | 199 | Require commonName in Root and Intermediate Certificates | 9-May-2017 | 8-Jun-2017 | +| 1.4.9 | 204 | Forbid DTPs from doing Domain/IP Ownership | 11-Jul-2017 | 11-Aug-2017 | +| 1.5.0 | 212 | Canonicalise formal name of the Baseline Requirements | 1-Sep-2017 | 1-Oct-2017 | +| 1.5.1 | 197 | Effective Date of Ballot 193 Provisions | 1-May-2017 | 2-Jun-2017 | +| 1.5.2 | 190 | Add Validation Methods with Minor Corrections | 19-Sep-2017 | 19-Oct-2017 | +| 1.5.3 | 214 | CAA Discovery CNAME Errata | 27-Sep-2017 | 27-Oct-2017 | +| 1.5.4 | 215 | Fix Ballot 190 Errata | 4‐Oct‐2017 | 5‐Nov‐2017 | +| 1.5.5 | 217 | Sunset RFC 2527 | 21‐Dec‐2017 | 9‐Mar‐2018 | +| 1.5.6 | 218 | Remove validation methods #1 and #5 | 5‐Feb‐2018 | 9‐Mar‐2018 | +| 1.5.7 | 220 | Minor Cleanups (Spring 2018) | 30‐Mar‐2018 | 29‐Apr‐2018 | +| 1.5.8 | 219 | Clarify handling of CAA Record Sets with no "issue"/"issuewild" property tag | 10-Apr-2018 | 10-May-2018 | +| 1.5.9 | 223 | Update BR Section 8.4 for CA audit criteria | 15-May-2018 | 14-June-2018 | +| 1.6.0 | 224 | WhoIs and RDAP | 22-May-2018 | 22-June-2018 | +| 1.6.1 | SC6 | Revocation Timeline Extension | 14-Sep-2018 | 14-Oct-2018 | +| 1.6.2 | SC12 | Sunset of Underscores in dNSNames | 9-Nov-2018 | 10-Dec-2018 | +| 1.6.3 | SC13 | CAA Contact Property and Associated E-mail Validation Methods | 25-Dec-2018 | 1-Feb-2019 | +| 1.6.4 | SC14 | Updated Phone Validation Methods | 31-Jan-2019 | 16-Mar-2019 | +| 1.6.4 | SC15 | Remove Validation Method Number 9 | 5-Feb-2019 | 16-Mar-2019 | +| 1.6.4 | SC7 | Update IP Address Validation Methods | 8-Feb-2019 | 16-Mar-2019 | +| 1.6.5 | SC16 | Other Subject Attributes | 15-Mar-2019 | 16-Apr-2019 | +| 1.6.6 | SC19 | Phone Contact with DNS CAA Phone Contact v2 | 20-May-2019 | 9-Sep-2019 | +| 1.6.7 | SC23 | Precertificates | 14-Nov-2019 | 19-Dec-2019 | +| 1.6.7 | SC24 | Fall Cleanup v2 | 12-Nov-2019 | 19-Dec-2019 | +| 1.6.8 | SC25 | Define New HTTP Domain Validation Methods v2 | 31-Jan-2020 | 3-Mar-2020 | +| 1.6.9 | SC27 | Version 3 Onion Certificates | 19-Feb-2020 | 27-Mar-2020 | +| 1.7.0 | SC29 | Pandoc-Friendly Markdown Formatting Changes | 20-Mar-2020 | 4-May-2020 | +| 1.7.1 | SC30 | Disclosure of Registration / Incorporating Agency | 13-Jul-2020 | 20-Aug-2020 | +| 1.7.1 | SC31 | Browser Alignment | 16-Jul-2020 | 20-Aug-2020 | +| 1.7.2 | SC33 | TLS Using ALPN Method | 14-Aug-2020 | 22-Sept-2020 | +| 1.7.3 | SC28 | Logging and Log Retention | 10-Sep-2020 | 19-Oct-2020 | +| 1.7.3 | SC35 | Cleanups and Clarifications | 9-Sep-2020 | 19-Oct-2020 | +| 1.7.4 | SC41 | Reformat the BRs, EVGs, and NCSSRs | 24-Feb-2021 | 5-Apr-2021 | +| 1.7.5 | SC42 | 398-day Re-use Period | 22-Apr-2021 | 2-Jun-2021 | +| 1.7.6 | SC44 | Clarify Acceptable Status Codes | 30-Apr-2021 | 3-Jun-2021 | +| 1.7.7 | SC46 | Sunset the CAA Exception for DNS Operator | 2-Jun-2021 | 12-Jul-2021 | +| 1.7.8 | SC45 | Wildcard Domain Validation | 2-Jun-2021 | 13-Jul-2021 | +| 1.7.9 | SC47 | Sunset subject:organizationalUnitName | 30-Jun-2021 | 16-Aug-2021 | +| 1.8.0 | SC48 | Domain Name and IP Address Encoding | 22-Jul-2021 | 25-Aug-2021 | +| 1.8.1 | SC50 | Remove the requirements of 4.1.1 | 22-Nov-2021 | 23-Dec-2021 | +| 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 | +| 1.8.7 | SC61 | New CRL entries must have a Revocation Reason Code | 1-Apr-2023 | 15-Jul-2023 | +| 2.0.0 | SC62 | Certificate Profiles Update | 22-Apr-2023 | 15-Sep-2023 | +| 2.0.1 | SC63 | Make OCSP optional, require CRLs, and incentivize automation | 17-Aug-2023 | 15-Mar-2024 | +| 2.0.2 | SC66 | 2023 Cleanup | 23-Nov-2023 | 8-Jan-2024 | +| 2.0.3 | SC69 | Clarify router and firewall logging requirements | 13-Mar-2024 | 15-Apr-2024 | +| 2.0.4 | SC65 | Convert EVGs into RFC 3647 format | 15-Mar-2024 | 15-May-2024 | +| 2.0.5 | SC73 | Compromised and weak keys | 3-May-2024 | 1-Jul-2024 | +| 2.0.6 | SC75 | Pre-sign linting | 28-Jun-2024 | 6-Aug-2024 | +| 2.0.7 | SC67 | Require Multi-Perspective Issuance Corroboration | 2-Aug-2024 | 6-Sep-2024 | +| 2.0.8 | SC77 | Update WebTrust Audit name in Section 8.4 and References | 2-Sep-2024 | 2-Oct-2024 | +| 2.0.9 | SC78 | Subject organizationName alignment for DBA / Assumed Name | 2-Oct-2024 | 8-Nov-2024 | +| 2.1.0 | SC76 | Clarify and improve OCSP requirements | 26-Sep-2024 | 14-Nov-2024 | +| 2.1.1 | SC79 | Allow more than one Certificate Policy in a Cross-Certified Subordinate CA Certificate | 30-Sep-2024 | 14-Nov-2024 | +| 2.1.2 | SC80 | Strengthen WHOIS lookups and Sunset Methods 3.2.2.4.2 and 3.2.2.4.15 | 7-Nov-2024 | 16-Dec-2024 | +| 2.1.3 | SC83 | Winter 2024-2025 Cleanup Ballot | 23-Jan-2025 | 24-Feb-2025 | +| 2.1.4 | SC84 | DNS Labeled with ACME Account ID Validation Method | 28-Jan-2025 | 1-Mar-2025 | +| 2.1.5 | SC81 | Introduce Schedule of Reducing Validity and Data Reuse Periods | 11-Apr-2025 | 16-May-2025 | +| 2.1.6 | SC85 | Require Validation of DNSSEC (when present) for CAA and DCV Lookups | 19-Jun-2025 | 21-Jul-2025 | +| 2.1.7 | SC089 | Mass Revocation Planning | 23-Jul-2025 | 25-Aug-2025 | \* Effective Date and Additionally Relevant Compliance Date(s) ### 1.2.2 Relevant Dates -| **Compliance** | **Section(s)** | **Summary Description (See Full Text for Details)** | -|----------------|----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | -| 2024-09-15 | 4.3.1.2 | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | -| 2025-01-15 | 4.9.9 | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. | -| 2025-01-15 | 3.2.2.4 | CAs MUST NOT rely on HTTPS websites to identify Domain Contact information. CAs MUST rely on IANA resources for identifying Domain Contact information. | -| 2025-03-15 | 4.3.1.2 | The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | -| 2025-03-15 | 8.7 | The CA SHOULD use a Linting process to test the technical accuracy of already issued Certificates against the sample set chosen for Self-Audits. | -| 2025-03-15 | 3.2.2.9 | CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified. | -| 2025-07-15 | 3.2.2.4 | CAs MUST NOT rely on Methods 3.2.2.4.2 and 3.2.2.4.15 to issue Subscriber Certificates. | -| 2025-12-01 | 5.7.1.2 | CAs SHALL assert in section 5.7.1 of their CPS or combined CP/CPS their mass revocation plan, testing, and continuous improvements. | -| 2026-03-15 | 4.2.1 | Subject Identity Information validation maximum data reuse period is 398 days. | -| 2026-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 200 days. | -| 2026-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 200 days. | -| 2026-03-15 | 3.2.2.4 | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. | -| 2026-03-15 | 3.2.2.4 | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. | -| 2026-03-15 | 3.2.2.8.1 | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. | -| 2026-03-15 | 3.2.2.8.1 | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. | -| 2026-03-15 | 3.2.2.8.1 | DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. | -| 2027-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 100 days. | -| 2027-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 100 days. | -| 2029-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 10 days. | -| 2029-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 47 days. | +| **Compliance** | **Section(s)** | **Summary Description (See Full Text for Details)** | +| --- | --- | --- | +| 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | +| 2024-09-15 | 4.3.1.2 | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | +| 2025-01-15 | 4.9.9 | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. | +| 2025-01-15 | 3.2.2.4 | CAs MUST NOT rely on HTTPS websites to identify Domain Contact information. CAs MUST rely on IANA resources for identifying Domain Contact information. | +| 2025-03-15 | 4.3.1.2 | The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | +| 2025-03-15 | 8.7 | The CA SHOULD use a Linting process to test the technical accuracy of already issued Certificates against the sample set chosen for Self-Audits. | +| 2025-03-15 | 3.2.2.9 | CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified. | +| 2025-07-15 | 3.2.2.4 | CAs MUST NOT rely on Methods 3.2.2.4.2 and 3.2.2.4.15 to issue Subscriber Certificates. | +| 2025-12-01 | 5.7.1.2 | CAs SHALL assert in section 5.7.1 of their CPS or combined CP/CPS their mass revocation plan, testing, and continuous improvements. | +| 2026-03-15 | 4.2.1 | Subject Identity Information validation maximum data reuse period is 398 days. | +| 2026-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 200 days. | +| 2026-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 200 days. | +| 2026-03-15 | 3.2.2.4 | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. | +| 2026-03-15 | 3.2.2.4 | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. | +| 2026-03-15 | 3.2.2.8.1 | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. | +| 2026-03-15 | 3.2.2.8.1 | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. | +| 2026-03-15 | 3.2.2.8.1 | DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. | +| 2027-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 100 days. | +| 2027-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 100 days. | +| 2029-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 10 days. | +| 2029-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 47 days. | ## 1.3 PKI Participants @@ -507,7 +507,7 @@ The script outputs: ### 1.6.2 Acronyms | **Acronym** | **Meaning** | -| --- | ------- | +| --- | --- | | AICPA | American Institute of Certified Public Accountants | | ADN | Authorization Domain Name | | CA | Certification Authority | From d2704f3f6c4629ce5058fa43742b102d6a01d8ec Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 06:56:11 +0100 Subject: [PATCH 038/121] #432 headers format changed --- docs/BR.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 8ff473dc..326eb0c3 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -45,8 +45,8 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse ### 1.2.1 Revisions -| Ver. | Ballot | **Description** | Adopted | Effective\* | -| :---: | --- | --- | --- | --- | +| **Ver.** | **Ballot** | **Description** | **Adopted** | **Effective\*** | +| - | - | ----- | -- | -- | | 1.0.0 | 62 | Version 1.0 of the Baseline Requirements Adopted | 22-Nov-11 | 01-Jul-12 | | 1.0.1 | 71 | Revised Auditor Qualifications | 08-May-12 | 01-Jan-13 | | 1.0.2 | 75 | Non-critical Name Constraints allowed as exception to RFC 5280 | 08-Jun-12 | 08-Jun-12 | @@ -157,7 +157,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse ### 1.2.2 Relevant Dates | **Compliance** | **Section(s)** | **Summary Description (See Full Text for Details)** | -| --- | --- | --- | +| -- | -- | ----------| | 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | | 2024-09-15 | 4.3.1.2 | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | | 2025-01-15 | 4.9.9 | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. | @@ -507,7 +507,7 @@ The script outputs: ### 1.6.2 Acronyms | **Acronym** | **Meaning** | -| --- | --- | +| - | --- | | AICPA | American Institute of Certified Public Accountants | | ADN | Authorization Domain Name | | CA | Certification Authority | From 8bd4391c1fdc97850a0a0393c98a7fb267e3384c Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 07:18:46 +0100 Subject: [PATCH 039/121] #432 headers format changed --- docs/BR.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 326eb0c3..15583e30 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -46,7 +46,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse ### 1.2.1 Revisions | **Ver.** | **Ballot** | **Description** | **Adopted** | **Effective\*** | -| - | - | ----- | -- | -- | +| - | - | -------- | - | - | | 1.0.0 | 62 | Version 1.0 of the Baseline Requirements Adopted | 22-Nov-11 | 01-Jul-12 | | 1.0.1 | 71 | Revised Auditor Qualifications | 08-May-12 | 01-Jan-13 | | 1.0.2 | 75 | Non-critical Name Constraints allowed as exception to RFC 5280 | 08-Jun-12 | 08-Jun-12 | @@ -157,7 +157,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse ### 1.2.2 Relevant Dates | **Compliance** | **Section(s)** | **Summary Description (See Full Text for Details)** | -| -- | -- | ----------| +| - | - | ----------| | 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | | 2024-09-15 | 4.3.1.2 | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | | 2025-01-15 | 4.9.9 | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. | From 9a8252c2857ffc499d7882ae6652a7742f586c60 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 07:28:27 +0100 Subject: [PATCH 040/121] #432 headers format changed --- docs/BR.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 15583e30..56b5a7ee 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -46,7 +46,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse ### 1.2.1 Revisions | **Ver.** | **Ballot** | **Description** | **Adopted** | **Effective\*** | -| - | - | -------- | - | - | +| - | - | ------ | -- | -- | | 1.0.0 | 62 | Version 1.0 of the Baseline Requirements Adopted | 22-Nov-11 | 01-Jul-12 | | 1.0.1 | 71 | Revised Auditor Qualifications | 08-May-12 | 01-Jan-13 | | 1.0.2 | 75 | Non-critical Name Constraints allowed as exception to RFC 5280 | 08-Jun-12 | 08-Jun-12 | @@ -157,7 +157,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse ### 1.2.2 Relevant Dates | **Compliance** | **Section(s)** | **Summary Description (See Full Text for Details)** | -| - | - | ----------| +| -- | - | ------| | 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | | 2024-09-15 | 4.3.1.2 | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | | 2025-01-15 | 4.9.9 | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. | @@ -507,7 +507,7 @@ The script outputs: ### 1.6.2 Acronyms | **Acronym** | **Meaning** | -| - | --- | +| - | ------ | | AICPA | American Institute of Certified Public Accountants | | ADN | Authorization Domain Name | | CA | Certification Authority | From 690f957a9eeffb5beecf568a75f68fc7353d1be0 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 07:32:00 +0100 Subject: [PATCH 041/121] #432 headers format changed --- docs/BR.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 56b5a7ee..f3e8ddbf 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -157,7 +157,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse ### 1.2.2 Relevant Dates | **Compliance** | **Section(s)** | **Summary Description (See Full Text for Details)** | -| -- | - | ------| +| -- | - | -------- | | 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | | 2024-09-15 | 4.3.1.2 | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | | 2025-01-15 | 4.9.9 | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. | @@ -507,7 +507,7 @@ The script outputs: ### 1.6.2 Acronyms | **Acronym** | **Meaning** | -| - | ------ | +| - | -------- | | AICPA | American Institute of Certified Public Accountants | | ADN | Authorization Domain Name | | CA | Certification Authority | From d4ff19a0601337bdbe637c3ffe183273c42b8584 Mon Sep 17 00:00:00 2001 From: dzacharo Date: Mon, 24 Nov 2025 09:27:19 +0200 Subject: [PATCH 042/121] Addresses #512 --- docs/BR.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index f3e8ddbf..e06cbcd0 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -3623,8 +3623,6 @@ The period during which the CA issues Certificates SHALL be divided into an unbr If the CA has a currently valid Audit Report indicating compliance with an audit scheme listed in [Section 8.4](#84-topics-covered-by-assessment), then no pre-issuance readiness assessment is necessary. -If the CA does not have a currently valid Audit Report indicating compliance with one of the audit schemes listed in [Section 8.4](#84-topics-covered-by-assessment), then, before issuing Publicly-Trusted Certificates, the CA SHALL successfully complete a point-in-time readiness assessment performed in accordance with applicable standards under one of the audit schemes listed in [Section 8.4](#84-topics-covered-by-assessment). The point-in-time readiness assessment SHALL be completed no earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates and SHALL be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate. - ## 8.2 Identity/qualifications of assessor The CA's audit SHALL be performed by a Qualified Auditor. A Qualified Auditor means a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively possess the following qualifications and skills: From 1e8c7fedd901ed6ea44389d3e670c2729b0228dc Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 11:54:44 +0100 Subject: [PATCH 043/121] #576 removing bullets from a b list --- docs/BR.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index f3e8ddbf..f4b3dfa3 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1130,8 +1130,8 @@ The CA MAY use either the same set, or different sets of Network Perspectives wh The set of responses from the relied upon Network Perspectives MUST provide the CA with the necessary information to allow it to affirmatively assess: -* a. the presence of the expected 1) Random Value, 2) Request Token, 3) IP Address, or 4) Contact Address, as required by the relied upon validation method specified in Sections 3.2.2.4 and 3.2.2.5; and -* b. the CA's authority to issue to the requested domain(s), as specified in Section 3.2.2.8. + a. the presence of the expected 1) Random Value, 2) Request Token, 3) IP Address, or 4) Contact Address, as required by the relied upon validation method specified in Sections 3.2.2.4 and 3.2.2.5; and + b. the CA's authority to issue to the requested domain(s), as specified in Section 3.2.2.8. [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) and [Section 3.2.2.5](#3225-authentication-for-an-ip-address) describe the validation methods that require the use of Multi-Perspective Issuance Corroboration and how a Network Perspective can corroborate the outcomes determined by the Primary Network Perspective. From 4397cfca54b395dadb2a3c35d2a7a6ab87e217d0 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 12:26:01 +0100 Subject: [PATCH 044/121] #570 fixed spacing for list in 3.2.2.4.2 --- docs/BR.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index e4931865..5d39e3a6 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -752,13 +752,15 @@ The Random Value SHALL remain valid for use in a confirming response for no more **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. Effective January 15, 2025: + - When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. - When obtaining Domain Contact information for a requested Domain Name the CA: - - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. - - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. - - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. + - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. + - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. + - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. Effective July 15, 2025: + - The CA MUST NOT rely on this method. - Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates. From 666d4d4a4682057f6d69e9b06c4f38d2bfce042b Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 12:41:15 +0100 Subject: [PATCH 045/121] #570 fixed spacing for list in 3.2.2.4.12, 3.2.2.4.15, 4.9.7, 7.1.2.2.3, 7.1.2.7.4 --- docs/BR.md | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 5d39e3a6..89c0865c 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -836,11 +836,12 @@ Confirming the Applicant's control over the FQDN by validating the Applicant is **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. Effective January 15, 2025: + - When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. - When obtaining Domain Contact information for a requested Domain Name the CA: - - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. - - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. - - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. + - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. + - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. + - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. ##### 3.2.2.4.13 Email to DNS CAA Contact @@ -879,13 +880,15 @@ The Random Value SHALL remain valid for use in a confirming response for no more **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. Effective January 15, 2025: + - When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. - When obtaining Domain Contact information for a requested Domain Name the CA: - - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. - - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. - - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. + - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. + - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. + - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. Effective July 15, 2025: + - The CA MUST NOT rely on this method. - Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates. @@ -1519,6 +1522,7 @@ No stipulation. CRLs MUST be available via a publicly-accessible HTTP URL (i.e., "published"). Within twenty-four (24) hours of issuing its first Certificate, the CA MUST generate and publish either: + - a full and complete CRL; OR - partitioned (i.e., "sharded") CRLs that, when aggregated, represent the equivalent of a full and complete CRL. @@ -1533,10 +1537,10 @@ CAs issuing CA Certificates: 2. MUST update and publish a new CRL within twenty-four (24) hours after recording a Certificate as revoked. CAs MUST continue issuing CRLs until one of the following is true: + - all Subordinate CA Certificates containing the same Subject Public Key are expired or revoked; OR - the corresponding Subordinate CA Private Key is destroyed. - ### 4.9.8 Maximum latency for CRLs (if applicable) No stipulation. @@ -2215,9 +2219,10 @@ The `subject` MUST comply with the requirements of [Section 7.1.4](#714-name-for In addition to the above, extKeyUsage extension requirements vary based on the relationship between the Issuer and Subject organizations represented in the Cross-Certificate. The extKeyUsage extension MAY be "unrestricted" as described in the following table if: + - the organizationName represented in the Issuer and Subject names of the corresponding certificate are either: - - the same, or - - the organizationName represented in the Subject name is an affiliate of the organizationName represented in the Issuer name + - the same, or + - the organizationName represented in the Subject name is an affiliate of the organizationName represented in the Issuer name - the corresponding CA represented by the Subject of the Cross-Certificate is operated by the same organization as the Issuing CA or an Affiliate of the Issuing CA organization. Table: Cross-Certified Subordinate CA with Unrestricted EKU @@ -2711,6 +2716,7 @@ In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '- | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | **Notes**: + - whether or not the `subjectAltName` extension should be marked Critical depends on the contents of the Certificate's `subject` field, as detailed in [Section 7.1.2.7.12](#712712-subscriber-certificate-subject-alternative-name). - whether or not the CRL Distribution Points extension must be present depends on 1) whether the Certificate includes an Authority Information Access extension with an id-ad-ocsp accessMethod and 2) the Certificate's validity period, as detailed in [Section 7.1.2.11.2](#712112-crl-distribution-points). From 4632b8a3d59bee0330d9b8a52a220ee5b9a4b15e Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 14:24:46 +0100 Subject: [PATCH 046/121] #299 added links to 1.2.2 Relevant Dates sections BR --- docs/BR.md | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 89c0865c..b2531048 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -158,27 +158,27 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | **Compliance** | **Section(s)** | **Summary Description (See Full Text for Details)** | | -- | - | -------- | -| 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | -| 2024-09-15 | 4.3.1.2 | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | -| 2025-01-15 | 4.9.9 | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. | -| 2025-01-15 | 3.2.2.4 | CAs MUST NOT rely on HTTPS websites to identify Domain Contact information. CAs MUST rely on IANA resources for identifying Domain Contact information. | -| 2025-03-15 | 4.3.1.2 | The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | -| 2025-03-15 | 8.7 | The CA SHOULD use a Linting process to test the technical accuracy of already issued Certificates against the sample set chosen for Self-Audits. | -| 2025-03-15 | 3.2.2.9 | CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified. | -| 2025-07-15 | 3.2.2.4 | CAs MUST NOT rely on Methods 3.2.2.4.2 and 3.2.2.4.15 to issue Subscriber Certificates. | -| 2025-12-01 | 5.7.1.2 | CAs SHALL assert in section 5.7.1 of their CPS or combined CP/CPS their mass revocation plan, testing, and continuous improvements. | -| 2026-03-15 | 4.2.1 | Subject Identity Information validation maximum data reuse period is 398 days. | -| 2026-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 200 days. | -| 2026-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 200 days. | -| 2026-03-15 | 3.2.2.4 | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. | -| 2026-03-15 | 3.2.2.4 | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. | -| 2026-03-15 | 3.2.2.8.1 | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. | -| 2026-03-15 | 3.2.2.8.1 | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. | -| 2026-03-15 | 3.2.2.8.1 | DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. | -| 2027-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 100 days. | -| 2027-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 100 days. | -| 2029-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 10 days. | -| 2029-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 47 days. | +| 2024-03-15 | [4.9.7](#497-crl-issuance-frequency) | CAs MUST generate and publish CRLs. | +| 2024-09-15 | [4.3.1.2](#4312-linting-of-to-be-signed-certificate-content) | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | +| 2025-01-15 | [4.9.9](#499-on-line-revocationstatus-checking-availability) | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. | +| 2025-01-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | CAs MUST NOT rely on HTTPS websites to identify Domain Contact information. CAs MUST rely on IANA resources for identifying Domain Contact information. | +| 2025-03-15 | [4.3.1.2](#4312-linting-of-to-be-signed-certificate-content) | The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | +| 2025-03-15 | [8.7](#87-self-audits) | The CA SHOULD use a Linting process to test the technical accuracy of already issued Certificates against the sample set chosen for Self-Audits. | +| 2025-03-15 | [3.2.2.9](#3229-multi-perspective-issuance-corroboration) | CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified. | +| 2025-07-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | CAs MUST NOT rely on Methods 3.2.2.4.2 and 3.2.2.4.15 to issue Subscriber Certificates. | +| 2025-12-01 | [5.7.1.2](#5712-mass-revocation-plans) | CAs SHALL assert in section 5.7.1 of their CPS or combined CP/CPS their mass revocation plan, testing, and continuous improvements. | +| 2026-03-15 | [4.2.1](#421-performing-identification-and-authentication-functions) | Subject Identity Information validation maximum data reuse period is 398 days. | +| 2026-03-15 | [4.2.1](#421-performing-identification-and-authentication-functions) | Domain Name and IP Address validation maximum data reuse period is 200 days. | +| 2026-03-15 | [6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) | Maximum validity period of Subscriber Certificates is 200 days. | +| 2026-03-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. | +| 2026-03-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. | +| 2026-03-15 | [3.2.2.8.1](#32281-dnssec-validation-of-caa-records) | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. | +| 2026-03-15 | [3.2.2.8.1](#32281-dnssec-validation-of-caa-records) | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. | +| 2026-03-15 | [3.2.2.8.1](#32281-dnssec-validation-of-caa-records) | DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. | +| 2027-03-15 | [4.2.1](#421-performing-identification-and-authentication-functions) | Domain Name and IP Address validation maximum data reuse period is 100 days. | +| 2027-03-15 | [6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) | Maximum validity period of Subscriber Certificates is 100 days. | +| 2029-03-15 | [4.2.1](#421-performing-identification-and-authentication-functions) | Domain Name and IP Address validation maximum data reuse period is 10 days. | +| 2029-03-15 | [6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) | Maximum validity period of Subscriber Certificates is 47 days. | ## 1.3 PKI Participants From b1d11391e6ccdeb1daa4c766c6ba5b9d2426e0ac Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 14:30:56 +0100 Subject: [PATCH 047/121] #299 fixed links and numbers to 1.2.2 Relevant Dates sections EVG --- docs/EVG.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 46d9d534..32b74256 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -92,10 +92,10 @@ These Guidelines do not address the verification of information, or the issuance | **Compliance** | **Section(s)** | **Summary Description (See Full Text for Details)** | |--|--|----------| -| 2020-01-31 | [9.2.8] | If subject:organizationIdentifier is present, the CA/Browser Forum Organization Identifier Extension MUST be present | -| 2020-09-01 | [9.4] & Appendix F | Certificates issued MUST NOT have a Validity Period greater than 398 days. | -| 2020-10-01 | [11.1.3] | 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] | CAs MUST NOT include the organizationalUnitName field in the Subject | +| 2020-01-31 | [7.1.4.2.8](#71428-subject-organization-identifier-field) | If subject:organizationIdentifier is present, the CA/Browser Forum Organization Identifier Extension MUST be present | +| 2020-09-01 | [6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) & [Appendix F](#appendix-f--unused) | Certificates issued MUST NOT have a Validity Period greater than 398 days. | +| 2020-10-01 | [3.2.2.1.3](#32213-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 | [7.1.4.2.7](#71427-subject-organizationalunitname-field) | CAs MUST NOT include the organizationalUnitName field in the Subject | **Implementers' Note**: Version 1.3 of these EV Guidelines was published on 20 November 2010 and supplemented through May 2012 when version 1.4 was published. ETSI TS 102 042 and ETSI TR 101 564 Technical Report: Guidance on ETSI TS 102 042 for Issuing Extended Validation Certificates for Auditors and CSPs reference version 1.3 of these EV Guidelines, and ETSI Draft EN 319 411-1 references version 1.4. Version 1.4.5 of Webtrust(r) for Certification Authorities – Extended Validation Audit Criteria references version 1.4.5 of these EV Guidelines. As illustrated in the Document History table above, the CA/Browser Forum continues to improve relevant industry guidelines, including this document, the Baseline Requirements, and the Network and Certificate System Security Requirements. We encourage all CAs to conform to each revision 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. We will respond to implementation questions directed to questions@cabforum.org. 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. From e8dd34378782b40b09465fd812310725f479b92c Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 14:53:05 +0100 Subject: [PATCH 048/121] #299 fixed link 71427 --- docs/EVG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/EVG.md b/docs/EVG.md index 32b74256..88a36011 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -95,7 +95,7 @@ These Guidelines do not address the verification of information, or the issuance | 2020-01-31 | [7.1.4.2.8](#71428-subject-organization-identifier-field) | If subject:organizationIdentifier is present, the CA/Browser Forum Organization Identifier Extension MUST be present | | 2020-09-01 | [6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) & [Appendix F](#appendix-f--unused) | Certificates issued MUST NOT have a Validity Period greater than 398 days. | | 2020-10-01 | [3.2.2.1.3](#32213-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 | [7.1.4.2.7](#71427-subject-organizationalunitname-field) | CAs MUST NOT include the organizationalUnitName field in the Subject | +| 2022-09-01 | [7.1.4.2.7](#71427-subject-organizational-unit-name-field) | CAs MUST NOT include the organizationalUnitName field in the Subject | **Implementers' Note**: Version 1.3 of these EV Guidelines was published on 20 November 2010 and supplemented through May 2012 when version 1.4 was published. ETSI TS 102 042 and ETSI TR 101 564 Technical Report: Guidance on ETSI TS 102 042 for Issuing Extended Validation Certificates for Auditors and CSPs reference version 1.3 of these EV Guidelines, and ETSI Draft EN 319 411-1 references version 1.4. Version 1.4.5 of Webtrust(r) for Certification Authorities – Extended Validation Audit Criteria references version 1.4.5 of these EV Guidelines. As illustrated in the Document History table above, the CA/Browser Forum continues to improve relevant industry guidelines, including this document, the Baseline Requirements, and the Network and Certificate System Security Requirements. We encourage all CAs to conform to each revision 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. We will respond to implementation questions directed to questions@cabforum.org. 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. From 5e749c3d2534f4b9585fdb1ce160c9afd88b4389 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 19:08:17 +0100 Subject: [PATCH 049/121] #570 fixed spacing for other lists --- docs/BR.md | 184 +++++++++++++++++++++++++++-------------------------- 1 file changed, 95 insertions(+), 89 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 413557b3..b14630bf 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -765,10 +765,10 @@ Completed validations of Applicant authority may be valid for the issuance of mu Effective March 15th, 2026: DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective MUST: -* perform DNSSEC validation using the algorithm defined in [RFC 4035 Section 5](https://datatracker.ietf.org/doc/html/rfc4035#section-5); and -* support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and -* support SHA-2 as defined in [RFC 4509](https://datatracker.ietf.org/doc/html/rfc4509) and [RFC 5702](https://datatracker.ietf.org/doc/html/rfc5702); and -* properly handle the security concerns enumerated in [RFC 6840 Section 4](https://datatracker.ietf.org/doc/html/rfc6840#section-4). +- perform DNSSEC validation using the algorithm defined in [RFC 4035 Section 5](https://datatracker.ietf.org/doc/html/rfc4035#section-5); and +- support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and +- support SHA-2 as defined in [RFC 4509](https://datatracker.ietf.org/doc/html/rfc4509) and [RFC 5702](https://datatracker.ietf.org/doc/html/rfc5702); and +- properly handle the security concerns enumerated in [RFC 6840 Section 4](https://datatracker.ietf.org/doc/html/rfc6840#section-4). Effective March 15th, 2026: CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. @@ -845,6 +845,7 @@ This method has been retired and MUST NOT be used. Prior validations using this ##### 3.2.2.4.7 DNS Change Confirming the Applicant's control over the FQDN by confirming the presence of a Random Value or Request Token in a DNS CNAME, TXT or CAA record for either + 1. an Authorization Domain Name; or 2. an Authorization Domain Name that is prefixed with a Domain Label that begins with an underscore character. @@ -933,9 +934,9 @@ Effective January 15, 2025: - When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. - When obtaining Domain Contact information for a requested Domain Name the CA: - - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. - - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. - - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. + - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. + - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. + - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. Effective July 15, 2025: @@ -1182,14 +1183,14 @@ If the CA issues a certificate after processing a CAA record, it MUST do so with RFC 8659 requires that CAs "MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA RRset or (2) an exception specified in the relevant CP or CPS applies." For issuances conforming to these Baseline Requirements, CAs MUST NOT rely on any exceptions specified in their CP or CPS unless they are one of the following: -* CAA checking is optional for certificates for which a Certificate Transparency Precertificate (see [Section 7.1.2.9](#7129-precertificate-profile)) was created and logged in at least two public logs, and for which CAA was checked at time of Precertificate issuance. -* CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant. +- CAA checking is optional for certificates for which a Certificate Transparency Precertificate (see [Section 7.1.2.9](#7129-precertificate-profile)) was created and logged in at least two public logs, and for which CAA was checked at time of Precertificate issuance. +- CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant. CAs are permitted to treat a record lookup failure as permission to issue if: -* the failure is outside the CA's infrastructure; and -* the lookup has been retried at least once; and -* the CA has confirmed that the domain is "Insecure" as defined in [RFC 4035 Section 4.3](https://datatracker.ietf.org/doc/html/rfc4035#section-4.3). +- the failure is outside the CA's infrastructure; and +- the lookup has been retried at least once; and +- the CA has confirmed that the domain is "Insecure" as defined in [RFC 4035 Section 4.3](https://datatracker.ietf.org/doc/html/rfc4035#section-4.3). CAs MUST document potential issuances that were prevented by a CAA record in sufficient detail to provide feedback to the CA/Browser Forum on the circumstances, and SHOULD dispatch reports of such issuance requests to the contact(s) stipulated in the CAA iodef record(s), if present. CAs are not expected to support URL schemes in the iodef record other than mailto: or https:. @@ -1197,10 +1198,10 @@ CAs MUST document potential issuances that were prevented by a CAA record in suf Effective March 15th, 2026: DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with CAA record lookups performed by the Primary Network Perspective MUST: -* perform DNSSEC validation using the algorithm defined in [RFC 4035 Section 5](https://datatracker.ietf.org/doc/html/rfc4035#section-5); and -* support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and -* support SHA-2 as defined in [RFC 4509](https://datatracker.ietf.org/doc/html/rfc4509) and [RFC 5702](https://datatracker.ietf.org/doc/html/rfc5702); and -* properly handle the security concerns enumerated in [RFC 6840 Section 4](https://datatracker.ietf.org/doc/html/rfc6840#section-4). +- perform DNSSEC validation using the algorithm defined in [RFC 4035 Section 5](https://datatracker.ietf.org/doc/html/rfc4035#section-5); and +- support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and +- support SHA-2 as defined in [RFC 4509](https://datatracker.ietf.org/doc/html/rfc4509) and [RFC 5702](https://datatracker.ietf.org/doc/html/rfc5702); and +- properly handle the security concerns enumerated in [RFC 6840 Section 4](https://datatracker.ietf.org/doc/html/rfc6840#section-4). Effective March 15th, 2026: CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. @@ -1245,7 +1246,7 @@ Remote Network Perspectives performing Multi-Perspective Issuance Corroboration: MUST: - Network Hardening - - Rely upon networks (e.g., Internet Service Providers or Cloud Provider Networks) implementing measures to mitigate BGP routing incidents in the global Internet routing system for providing internet connectivity to the Network Perspective. + - Rely upon networks (e.g., Internet Service Providers or Cloud Provider Networks) implementing measures to mitigate BGP routing incidents in the global Internet routing system for providing internet connectivity to the Network Perspective. SHOULD: @@ -1609,13 +1610,15 @@ Within twenty-four (24) hours of issuing its first Certificate, the CA MUST gene - a full and complete CRL; OR - partitioned (i.e., "sharded") CRLs that, when aggregated, represent the equivalent of a full and complete CRL. -CAs issuing Subscriber Certificates: +CAs issuing Subscriber Certificates: + 1. MUST update and publish a new CRL at least every: - - seven (7) days if all Certificates include an Authority Information Access extension with an id-ad-ocsp accessMethod ("AIA OCSP pointer"); or - - four (4) days in all other cases; + - seven (7) days if all Certificates include an Authority Information Access extension with an id-ad-ocsp accessMethod ("AIA OCSP pointer"); or + - four (4) days in all other cases; 2. MUST update and publish a new CRL within twenty-four (24) hours after recording a Certificate as revoked. -CAs issuing CA Certificates: +CAs issuing CA Certificates: + 1. MUST update and publish a new CRL at least every twelve (12) months; 2. MUST update and publish a new CRL within twenty-four (24) hours after recording a Certificate as revoked. @@ -1903,6 +1906,7 @@ Additionally, the CA's security program MUST include an annual Risk Assessment t 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 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. @@ -1911,6 +1915,7 @@ Additionally, the CA and each Delegated Third 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 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 @@ -2049,12 +2054,12 @@ If the CA or any of its designated RAs become aware that a Subscriber's Private For RSA key pairs the CA SHALL: -* Ensure that the modulus size, when encoded, is at least 2048 bits, and; -* Ensure that the modulus size, in bits, is evenly divisible by 8. +- Ensure that the modulus size, when encoded, is at least 2048 bits, and; +- Ensure that the modulus size, in bits, is evenly divisible by 8. For ECDSA key pairs, the CA SHALL: -* Ensure that the key represents a valid point on the NIST P-256, NIST P-384 or NIST P-521 elliptic curve. +- Ensure that the key represents a valid point on the NIST P-256, NIST P-384 or NIST P-521 elliptic curve. No other algorithms or key sizes are permitted. @@ -2180,19 +2185,19 @@ Certificates MUST be of type X.509 v3. If the CA asserts compliance with these Baseline Requirements, all certificates that it issues MUST comply with one of the following certificate profiles, which incorporate, and are derived from [RFC 5280](https://tools.ietf.org/html/rfc5280). Except as explicitly noted, all normative requirements imposed by RFC 5280 shall apply, in addition to the normative requirements imposed by this document. CAs SHOULD examine [RFC 5280, Appendix B](https://tools.ietf.org/html/rfc5280#appendix-B) for further issues to be aware of. - * CA Certificates - * [Section 7.1.2.1 - Root CA Certificate Profile](#7121-root-ca-certificate-profile) - * Subordinate CA Certificates - * Cross Certificates - * [Section 7.1.2.2 - Cross-Certified Subordinate CA Certificate Profile](#7122-cross-certified-subordinate-ca-certificate-profile) - * Technically Constrained CA Certificates - * [Section 7.1.2.3 - Technically-Constrained Non-TLS Subordinate CA Certificate Profile](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) - * [Section 7.1.2.4 - Technically-Constrained Precertificate Signing CA Certificate Profile](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) - * [Section 7.1.2.5 - Technically-Constrained TLS Subordinate CA Certificate Profile](#7125-technically-constrained-tls-subordinate-ca-certificate-profile) - * [Section 7.1.2.6 - TLS Subordinate CA Certificate Profile](#7126-tls-subordinate-ca-certificate-profile) - * [Section 7.1.2.7 - Subscriber (End-Entity) Certificate Profile](#7127-subscriber-server-certificate-profile) - * [Section 7.1.2.8 - OCSP Responder Certificate Profile](#7128-ocsp-responder-certificate-profile) - * [Section 7.1.2.9 - Precertificate Profile](#7129-precertificate-profile) +- CA Certificates + - [Section 7.1.2.1 - Root CA Certificate Profile](#7121-root-ca-certificate-profile) + - Subordinate CA Certificates + - Cross Certificates + - [Section 7.1.2.2 - Cross-Certified Subordinate CA Certificate Profile](#7122-cross-certified-subordinate-ca-certificate-profile) + - Technically Constrained CA Certificates + - [Section 7.1.2.3 - Technically-Constrained Non-TLS Subordinate CA Certificate Profile](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) + - [Section 7.1.2.4 - Technically-Constrained Precertificate Signing CA Certificate Profile](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) + - [Section 7.1.2.5 - Technically-Constrained TLS Subordinate CA Certificate Profile](#7125-technically-constrained-tls-subordinate-ca-certificate-profile) + - [Section 7.1.2.6 - TLS Subordinate CA Certificate Profile](#7126-tls-subordinate-ca-certificate-profile) +- [Section 7.1.2.7 - Subscriber (End-Entity) Certificate Profile](#7127-subscriber-server-certificate-profile) +- [Section 7.1.2.8 - OCSP Responder Certificate Profile](#7128-ocsp-responder-certificate-profile) +- [Section 7.1.2.9 - Precertificate Profile](#7129-precertificate-profile) #### 7.1.2.1 Root CA Certificate Profile @@ -2515,6 +2520,7 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is | `signature` | | Effective March 15, 2026: + - This Certificate Profile MUST NOT be used. - Precertificate Signing CAs MUST NOT be used to issue Precertificates. @@ -3380,15 +3386,15 @@ When encoded, the `AlgorithmIdentifier` for RSA keys MUST be byte-for-byte ident The CA SHALL indicate an ECDSA key using the id-ecPublicKey (OID: 1.2.840.10045.2.1) algorithm identifier. The parameters MUST use the `namedCurve` encoding. -* For P-256 keys, the `namedCurve` MUST be secp256r1 (OID: 1.2.840.10045.3.1.7). -* For P-384 keys, the `namedCurve` MUST be secp384r1 (OID: 1.3.132.0.34). -* For P-521 keys, the `namedCurve` MUST be secp521r1 (OID: 1.3.132.0.35). +- For P-256 keys, the `namedCurve` MUST be secp256r1 (OID: 1.2.840.10045.3.1.7). +- For P-384 keys, the `namedCurve` MUST be secp384r1 (OID: 1.3.132.0.34). +- For P-521 keys, the `namedCurve` MUST be secp521r1 (OID: 1.3.132.0.35). When encoded, the `AlgorithmIdentifier` for ECDSA keys MUST be byte-for-byte identical with the following hex-encoded bytes: -* For P-256 keys, `301306072a8648ce3d020106082a8648ce3d030107`. -* For P-384 keys, `301006072a8648ce3d020106052b81040022`. -* For P-521 keys, `301006072a8648ce3d020106052b81040023`. +- For P-256 keys, `301306072a8648ce3d020106082a8648ce3d030107`. +- For P-384 keys, `301006072a8648ce3d020106052b81040022`. +- For P-521 keys, `301006072a8648ce3d020106052b81040023`. #### 7.1.3.2 Signature AlgorithmIdentifier @@ -3396,11 +3402,11 @@ All objects signed by a CA Private Key MUST conform to these requirements on the In particular, it applies to all of the following objects and fields: -* The `signatureAlgorithm` field of a Certificate or Precertificate. -* The `signature` field of a TBSCertificate (for example, as used by either a Certificate or Precertificate). -* The `signatureAlgorithm` field of a CertificateList -* The `signature` field of a TBSCertList -* The `signatureAlgorithm` field of a BasicOCSPResponse. +- The `signatureAlgorithm` field of a Certificate or Precertificate. +- The `signature` field of a TBSCertificate (for example, as used by either a Certificate or Precertificate). +- The `signatureAlgorithm` field of a CertificateList +- The `signature` field of a TBSCertList +- The `signatureAlgorithm` field of a BasicOCSPResponse. No other encodings are permitted for these fields. @@ -3408,22 +3414,22 @@ No other encodings are permitted for these fields. The CA SHALL use one of the following signature algorithms and encodings. When encoded, the `AlgorithmIdentifier` MUST be byte-for-byte identical with the specified hex-encoded bytes. -* RSASSA-PKCS1-v1_5 with SHA-256: +- RSASSA-PKCS1-v1_5 with SHA-256: Encoding: `300d06092a864886f70d01010b0500`. -* RSASSA-PKCS1-v1_5 with SHA-384: +- RSASSA-PKCS1-v1_5 with SHA-384: Encoding: `300d06092a864886f70d01010c0500`. -* RSASSA-PKCS1-v1_5 with SHA-512: +- RSASSA-PKCS1-v1_5 with SHA-512: Encoding: `300d06092a864886f70d01010d0500`. -* RSASSA-PSS with SHA-256, MGF-1 with SHA-256, and a salt length of 32 bytes: +- RSASSA-PSS with SHA-256, MGF-1 with SHA-256, and a salt length of 32 bytes: Encoding: @@ -3433,7 +3439,7 @@ The CA SHALL use one of the following signature algorithms and encodings. When e 0500a203020120 ``` -* RSASSA-PSS with SHA-384, MGF-1 with SHA-384, and a salt length of 48 bytes: +- RSASSA-PSS with SHA-384, MGF-1 with SHA-384, and a salt length of 48 bytes: Encoding: @@ -3443,7 +3449,7 @@ The CA SHALL use one of the following signature algorithms and encodings. When e 0500a203020130 ``` -* RSASSA-PSS with SHA-512, MGF-1 with SHA-512, and a salt length of 64 bytes: +- RSASSA-PSS with SHA-512, MGF-1 with SHA-512, and a salt length of 64 bytes: Encoding: @@ -3455,25 +3461,25 @@ The CA SHALL use one of the following signature algorithms and encodings. When e In addition, the CA MAY use the following signature algorithm and encoding if all of the following conditions are met: -* If used within a Certificate, such as the `signatureAlgorithm` field of a Certificate or the `signature` field of a TBSCertificate: - * The new Certificate is a Root CA Certificate or Subordinate CA Certificate that is a Cross-Certificate; and, - * There is an existing Certificate, issued by the same issuing CA Certificate, using the following encoding for the signature algorithm; and, - * The existing Certificate has a `serialNumber` that is at least 64-bits long; and, - * 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.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, - * All unexpired, un-revoked Certificates that contain the Public Key of the CA Key Pair and that have the same Subject Name MUST also contain an `extKeyUsage` extension with the only key usage present being the id-kp-ocspSigning (OID: 1.3.6.1.5.5.7.3.9) key usage. -* If used within a CRL, such as the `signatureAlgorithm` field of a CertificateList or the `signature` field of a TBSCertList: - * The CRL is referenced by one or more Root CA or Subordinate CA Certificates; and, - * The Root CA or Subordinate CA Certificate has issued one or more Certificates using the following encoding for the signature algorithm. +- If used within a Certificate, such as the `signatureAlgorithm` field of a Certificate or the `signature` field of a TBSCertificate: + - The new Certificate is a Root CA Certificate or Subordinate CA Certificate that is a Cross-Certificate; and, + - There is an existing Certificate, issued by the same issuing CA Certificate, using the following encoding for the signature algorithm; and, + - The existing Certificate has a `serialNumber` that is at least 64-bits long; and, + - 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.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, + - All unexpired, un-revoked Certificates that contain the Public Key of the CA Key Pair and that have the same Subject Name MUST also contain an `extKeyUsage` extension with the only key usage present being the id-kp-ocspSigning (OID: 1.3.6.1.5.5.7.3.9) key usage. +- If used within a CRL, such as the `signatureAlgorithm` field of a CertificateList or the `signature` field of a TBSCertList: + - The CRL is referenced by one or more Root CA or Subordinate CA Certificates; and, + - The Root CA or Subordinate CA Certificate has issued one or more Certificates using the following encoding for the signature algorithm. **Note**: The above requirements do not permit a CA to sign a Precertificate with this encoding. -* RSASSA-PKCS1-v1_5 with SHA-1: +- RSASSA-PKCS1-v1_5 with SHA-1: Encoding: `300d06092a864886f70d0101050500` @@ -3498,16 +3504,16 @@ The following requirements apply to all Certificates listed in [Section 7.1.2](# For every valid Certification Path (as defined by [RFC 5280, Section 6](https://tools.ietf.org/html/rfc5280#section-6)): -* For each Certificate in the Certification Path, the encoded content of the Issuer Distinguished Name field of a Certificate SHALL be byte-for-byte identical with the encoded form of the Subject Distinguished Name field of the Issuing CA certificate. -* For each CA Certificate in the Certification Path, the encoded content of the Subject Distinguished Name field of a Certificate SHALL be byte-for-byte identical among all Certificates whose Subject Distinguished Names can be compared as equal according to [RFC 5280, Section 7.1](https://tools.ietf.org/html/rfc5280#section-7.1), and including expired and revoked Certificates. +- For each Certificate in the Certification Path, the encoded content of the Issuer Distinguished Name field of a Certificate SHALL be byte-for-byte identical with the encoded form of the Subject Distinguished Name field of the Issuing CA certificate. +- For each CA Certificate in the Certification Path, the encoded content of the Subject Distinguished Name field of a Certificate SHALL be byte-for-byte identical among all Certificates whose Subject Distinguished Names can be compared as equal according to [RFC 5280, Section 7.1](https://tools.ietf.org/html/rfc5280#section-7.1), and including expired and revoked Certificates. When encoding a `Name`, the CA SHALL ensure that: - * Each `Name` MUST contain an `RDNSequence`. - * Each `RelativeDistinguishedName` MUST contain exactly one `AttributeTypeAndValue`. - * Each `RelativeDistinguishedName`, if present, is encoded within the `RDNSequence` in the order that it appears in [Section 7.1.4.2](#7142-subject-attribute-encoding). - * For example, a `RelativeDistinguishedName` that contains a `countryName` `AttributeTypeAndValue` pair MUST be encoded within the `RDNSequence` before a `RelativeDistinguishedName` that contains a `stateOrProvinceName` `AttributeTypeAndValue`. - * Each `Name` MUST NOT contain more than one instance of a given `AttributeTypeAndValue` across all `RelativeDistinguishedName`s unless explicitly allowed in these Requirements. +- Each `Name` MUST contain an `RDNSequence`. +- Each `RelativeDistinguishedName` MUST contain exactly one `AttributeTypeAndValue`. +- Each `RelativeDistinguishedName`, if present, is encoded within the `RDNSequence` in the order that it appears in [Section 7.1.4.2](#7142-subject-attribute-encoding). + - For example, a `RelativeDistinguishedName` that contains a `countryName` `AttributeTypeAndValue` pair MUST be encoded within the `RDNSequence` before a `RelativeDistinguishedName` that contains a `stateOrProvinceName` `AttributeTypeAndValue`. +- Each `Name` MUST NOT contain more than one instance of a given `AttributeTypeAndValue` across all `RelativeDistinguishedName`s unless explicitly allowed in these Requirements. **Note**: [Section 7.1.2.2.2](#71222-cross-certified-subordinate-ca-naming) provides an exception to the above `Name` encoding requirements when issuing a [Cross-Certified Subordinate CA Certificate](#7122-cross-certified-subordinate-ca-certificate-profile), as described within that section. @@ -3554,9 +3560,9 @@ Table: Encoding Requirements for Selected Attributes If present, this attribute MUST contain exactly one entry that is one of the values contained in the Certificate's `subjectAltName` extension (see [Section 7.1.2.7.12](#712712-subscriber-certificate-subject-alternative-name)). The value of the field MUST be encoded as follows: - * If the value is an IPv4 address, then the value MUST be encoded as an IPv4Address as specified in RFC 3986, Section 3.2.2. - * If the value is an IPv6 address, then the value MUST be encoded in the text representation specified in RFC 5952, Section 4. - * If the value is a Fully-Qualified Domain Name or Wildcard Domain Name, then the value MUST be encoded as a character-for-character copy of the `dNSName` entry value from the `subjectAltName` extension. Specifically, all Domain Labels of the Fully-Qualified Domain Name or FQDN portion of the Wildcard Domain Name must be encoded as LDH Labels, and P-Labels MUST NOT be converted to their Unicode representation. +- If the value is an IPv4 address, then the value MUST be encoded as an IPv4Address as specified in RFC 3986, Section 3.2.2. +- If the value is an IPv6 address, then the value MUST be encoded in the text representation specified in RFC 5952, Section 4. +- If the value is a Fully-Qualified Domain Name or Wildcard Domain Name, then the value MUST be encoded as a character-for-character copy of the `dNSName` entry value from the `subjectAltName` extension. Specifically, all Domain Labels of the Fully-Qualified Domain Name or FQDN portion of the Wildcard Domain Name must be encoded as LDH Labels, and P-Labels MUST NOT be converted to their Unicode representation. #### 7.1.4.4 Other Subject Attributes @@ -3564,8 +3570,8 @@ When explicitly stated as permitted by the relevant certificate profile specifie Before including such an attribute, the CA SHALL: - * Document the attributes within Section 7.1.4 of their CP or CPS, along with the applicable validation practices. - * Ensure that the contents contain information that has been verified by the CA, independent of the Applicant. +- Document the attributes within Section 7.1.4 of their CP or CPS, along with the applicable validation practices. +- Ensure that the contents contain information that has been verified by the CA, independent of the Applicant. ### 7.1.5 Name constraints @@ -3736,15 +3742,15 @@ The CA's audit SHALL be performed by a Qualified Auditor. A Qualified Auditor me The CA SHALL undergo an audit in accordance with one of the following schemes: 1. WebTrust: - * "Principles and Criteria for Certification Authorities" Version 2.2 or newer; and either - * "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security" Version 2.7 or newer; or - * "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline" Version 2.8 or newer and "WebTrust Principles and Criteria for Certification Authorities – Network Security" Version 1.0 or newer + - "Principles and Criteria for Certification Authorities" Version 2.2 or newer; and either + - "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security" Version 2.7 or newer; or + - "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline" Version 2.8 or newer and "WebTrust Principles and Criteria for Certification Authorities – Network Security" Version 1.0 or newer 2. ETSI: - * ETSI EN 319 411-1 v1.4.1 or newer, which includes normative references to ETSI EN 319 401 (the latest version of the referenced ETSI documents should be applied); or + - ETSI EN 319 411-1 v1.4.1 or newer, which includes normative references to ETSI EN 319 401 (the latest version of the referenced ETSI documents should be applied); or 3. Other: - * If a Government CA is required by its Certificate Policy to use a different internal audit scheme, it MAY use such scheme provided that the audit either - a. encompasses all requirements of one of the above schemes; or - b. consists of comparable criteria that are available for public review. + - If a Government CA is required by its Certificate Policy to use a different internal audit scheme, it MAY use such scheme provided that the audit either + a. encompasses all requirements of one of the above schemes; or + b. consists of comparable criteria that are available for public review. Whichever scheme is chosen, it MUST incorporate periodic monitoring and/or accountability procedures to ensure that its audits continue to be conducted in accordance with the requirements of the scheme. From 4b3506c64d122e1f8d3eedb54004ec01351cd31b Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 19:14:14 +0100 Subject: [PATCH 050/121] #432 empty lines removed --- docs/BR.md | 30 +++--------------------------- 1 file changed, 3 insertions(+), 27 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index b14630bf..08f36a19 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -353,7 +353,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Certification Practice Statement**: One of several documents forming the governance framework in which Certificates are created, issued, managed, and used. -**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%. +**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. @@ -1000,8 +1000,7 @@ If a Random Value is used, then: Except for Onion Domain Names, CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. Random Value or Request Token) as the Primary Network Perspective. -**Note**: - * The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs separate validations for each of those other FQDNs using authorized methods. This method is NOT suitable for validating Wildcard Domain Names. +**Note**: The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs separate validations for each of those other FQDNs using authorized methods. This method is NOT suitable for validating Wildcard Domain Names. ##### 3.2.2.4.19 Agreed-Upon Change to Website - ACME @@ -1021,8 +1020,7 @@ If the CA follows redirects, the following apply: Except for Onion Domain Names, CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. token) as the Primary Network Perspective. -**Note**: - * The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs separate validations for each of those other FQDNs using authorized methods. This method is NOT suitable for validating Wildcard Domain Names. +**Note**: The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs separate validations for each of those other FQDNs using authorized methods. This method is NOT suitable for validating Wildcard Domain Names. ##### 3.2.2.4.20 TLS Using ALPN @@ -2378,7 +2376,6 @@ CAs MUST NOT include additional key usage purposes unless the CA is aware of a r The Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile: - Table: No Policy Restrictions (Affiliated CA) | **Field** | **Presence** | **Contents** | @@ -2387,7 +2384,6 @@ Table: No Policy Restrictions (Affiliated CA) |     `anyPolicy` | MUST | | | `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | - Table: Policy Restricted | **Field** | **Presence** | **Contents** | @@ -2398,16 +2394,12 @@ Table: Policy Restricted |     Any other identifier | MAY | If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement. | | `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | - This Profile RECOMMENDS that the first `PolicyInformation` value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST include at least one Reserved Certificate Policy Identifier. If any Subscriber Certificates will chain up directly to the Certificate issued under this Certificate Profile, this Cross-Certified Subordinate CA Certificate MUST contain exactly one Reserved Certificate Policy Identifier. - **Note**: policyQualifiers is NOT RECOMMENDED to be present in any Certificate issued under this Certificate Profile because this information increases the size of the Certificate without providing any value to a typical Relying Party, and the information may be obtained by other means when necessary. - If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows: - Table: Permitted `policyQualifiers` | **Qualifier ID** | **Presence** | **Field Type** | **Contents** | @@ -2463,7 +2455,6 @@ Table: No Policy Restrictions (Affiliated CA) |     `anyPolicy` | MUST | | | `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | - Table: Policy Restricted | **Field** | **Presence** | **Contents** | @@ -2474,7 +2465,6 @@ Table: Policy Restricted |     Any other identifier | MAY | If present, MUST be documented by the CA in its Certificate Policy and/or Certification Practice Statement. | | `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | - Table: Permitted `policyQualifiers` | **Qualifier ID** | **Presence** | **Field Type** | **Contents** | @@ -2482,7 +2472,6 @@ Table: Permitted `policyQualifiers` | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | - ##### 7.1.2.3.3 Technically Constrained Non-TLS Subordinate CA Extended Key Usage The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to issue certificates for each included extended key usage purpose. Multiple, independent key purposes (e.g. `id-kp-timeStamping` and `id-kp-codeSigning`) are NOT RECOMMENDED. @@ -2844,10 +2833,8 @@ If present, the Certificate Policies extension MUST contain at least one `Policy |     Any other identifier | MAY | If present, MUST be defined and documented in the CA's Certificate Policy and/or Certification Practice Statement. | | `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | - This Profile RECOMMENDS that the first `PolicyInformation` value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier. - Table: Permitted `policyQualifiers` | **Qualifier ID** | **Presence** | **Field Type** | **Contents** | @@ -3035,7 +3022,6 @@ If present, the Certificate Policies extension MUST contain at least one `Policy |     Any other identifier | NOT RECOMMENDED | If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement. | | `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | - Table: Permitted `policyQualifiers` | **Qualifier ID** | **Presence** | **Field Type** | **Contents** | @@ -3075,7 +3061,6 @@ Table: When the Precertificate is issued directly by the Issuing CA | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | - Table: When the Precertificate is issued by a Precertificate Signing CA on behalf of an Issuing CA | **Field** | **Description** | @@ -3132,14 +3117,12 @@ For Precertificates issued by a Precertificate Signing CA, the contents of the ` 1. SHOULD be as defined in the profile below, or; 2. MAY be byte-for-byte identical with the contents of the `authorityKeyIdentifier` extension of the corresponding Certificate. - | **Field** | **Description** | | --- | ------- | | `keyIdentifier` | MUST be present. MUST be identical to the `subjectKeyIdentifier` field of the [Precertificate Signing CA Certificate](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) | | `authorityCertIssuer` | MUST NOT be present | | `authorityCertSerialNumber` | MUST NOT be present | - **Note**: [RFC 6962](https://datatracker.ietf.org/doc/html/rfc6962) describes how the `authorityKeyIdentifier` present on a Precertificate is transformed to contain the value of the Precertificate Signing CA's `authorityKeyIdentifier` extension (i.e. reflecting the actual issuer certificate's `keyIdentifier`), thus matching the corresponding Certificate when verified by clients. These Baseline Requirements RECOMMEND the use of the Precertificate Signing CA's `keyIdentifier` in Precertificates issued by it in order to ensure consistency between the `subjectKeyIdentifier` and `authorityKeyIdentifier` of all certificates in the chain. Although [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) does not strictly require such consistency, a number of client implementations enforce such consistency for Certificates, and this avoids any risks from Certificate Transparency Logs incorrectly implementing such checks. #### 7.1.2.10 Common CA Fields @@ -3194,7 +3177,6 @@ The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with t If present, the Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile: - Table: No Policy Restrictions (Affiliated CA) | **Field** | **Presence** | **Contents** | @@ -3203,7 +3185,6 @@ Table: No Policy Restrictions (Affiliated CA) |     `anyPolicy` | MUST | | | `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | - Table: Policy Restricted | **Field** | **Presence** | **Contents** | @@ -3214,16 +3195,12 @@ Table: Policy Restricted |     Any other identifier | MAY | If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement. | | `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | - The Policy Restricted profile RECOMMENDS that the first `PolicyInformation` value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier. - **Note**: policyQualifiers is NOT RECOMMENDED to be present in any Certificate issued under this Certificate Profile because this information increases the size of the Certificate without providing any value to a typical Relying Party, and the information may be obtained by other means when necessary. - If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows: - Table: Permitted `policyQualifiers` | **Qualifier ID** | **Presence** | **Field Type** | **Contents** | @@ -3265,7 +3242,6 @@ Table: Permitted `policyQualifiers` If present, the Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatibility with certain legacy applications that do not support Name Constraints is necessary. - Table: `nameConstraints` requirements | **Field** | **Description** | From 1ee0cf24c7fd0fbf89d6cbb4b183dee152bd0be0 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 19:15:31 +0100 Subject: [PATCH 051/121] #432 header bold from __ to ** --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 08f36a19..0ee1a241 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1065,7 +1065,7 @@ The following table shows how the `persistUntil` parameter affects whether a DNS Table: Examples of how the `persistUntil` parameter affects validation -| __Date/time of validation__ | __persistUntil__ | __Usable for validation__ | __Explanation__ | +| **Date/time of validation** | **persistUntil** | **Usable for validation** | **Explanation** | |----------------------------|------------------|--------------------------|----------------| | 2025-06-15T12:00:00Z | 2026-01-01T00:00:00Z (1767225600) | Yes | Validation time is before persistUntil timestamp, so record is usable | | 2025-06-15T12:00:00Z | 2025-01-01T00:00:00Z (1735689600) | No | Validation time is after persistUntil timestamp, so record is not usable | From a6eeb040fb6904a89df7079cc5192671d1848841 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 19:20:49 +0100 Subject: [PATCH 052/121] #432 added missing closing | in table --- docs/BR.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 0ee1a241..eb70dfb6 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2752,7 +2752,7 @@ Table: Organization Validated `subject` Attributes | **Attribute Name** | **Presence** | **Value** | **Verification** | | --- | -- | --- | -- | -| `domainComponent` | MAY | If present, this field MUST contain a Domain Label from a Domain Name. The `domainComponent` fields for the Domain Name MUST be in a single ordered sequence containing all Domain Labels from the Domain Name. The Domain Labels MUST be encoded in the reverse order to the on-wire representation of domain names in the DNS protocol, so that the Domain Label closest to the root is encoded first. Multiple instances MAY be present. | [Section 3.2] +| `domainComponent` | MAY | If present, this field MUST contain a Domain Label from a Domain Name. The `domainComponent` fields for the Domain Name MUST be in a single ordered sequence containing all Domain Labels from the Domain Name. The Domain Labels MUST be encoded in the reverse order to the on-wire representation of domain names in the DNS protocol, so that the Domain Label closest to the root is encoded first. Multiple instances MAY be present. | [Section 3.2] | | `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.2.1](#3221-identity) | | `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.2.1](#3221-identity) | | `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.2.1](#3221-identity) | @@ -3639,12 +3639,12 @@ Table: CRLReasons | **RFC 5280 reasonCode** | **RFC 5280 reasonCode value** | **Description** | | --- | - | ------ | -| unspecified | 0 | Represented by the omission of a reasonCode. MUST be omitted if the CRL entry is for a Certificate not technically capable of causing issuance unless the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to July 15, 2023. +| unspecified | 0 | Represented by the omission of a reasonCode. MUST be omitted if the CRL entry is for a Certificate not technically capable of causing issuance unless the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to July 15, 2023. | | keyCompromise | 1 | Indicates that it is known or suspected that the Subscriber’s Private Key has been compromised. | | affiliationChanged | 3 | Indicates that the Subject's name or other Subject Identity Information in the Certificate has changed, but there is no cause to suspect that the Certificate's Private Key has been compromised. | | superseded | 4 | Indicates that the Certificate is being replaced because: the Subscriber has requested a new Certificate, the CA has reasonable evidence that the validation of domain authorization or control for any fully‐qualified domain name or IP address in the Certificate should not be relied upon, or the CA has revoked the Certificate for compliance reasons such as the Certificate does not comply with these Baseline Requirements or the CA's CP or CPS. | -| cessationOfOperation | 5 | Indicates that the website with the Certificate is shut down prior to the expiration of the Certificate, or if the Subscriber no longer owns or controls the Domain Name in the Certificate prior to the expiration of the Certificate. -| certificateHold | 6 | MUST NOT be included if the CRL entry is for 1) a Certificate subject to these Requirements, or 2) a Certificate not subject to these Requirements and was either A) issued on-or-after 2020-09-30 or B) has a `notBefore` on-or-after 2020-09-30. +| cessationOfOperation | 5 | Indicates that the website with the Certificate is shut down prior to the expiration of the Certificate, or if the Subscriber no longer owns or controls the Domain Name in the Certificate prior to the expiration of the Certificate. | +| certificateHold | 6 | MUST NOT be included if the CRL entry is for 1) a Certificate subject to these Requirements, or 2) a Certificate not subject to these Requirements and was either A) issued on-or-after 2020-09-30 or B) has a `notBefore` on-or-after 2020-09-30. | | privilegeWithdrawn | 9 | Indicates that there has been a subscriber-side infraction that has not resulted in keyCompromise, such as the Certificate Subscriber provided misleading information in their Certificate Request or has not upheld their material obligations under the Subscriber Agreement or Terms of Use. | The Subscriber Agreement, or an online resource referenced therein, MUST inform Subscribers about the revocation reason options listed above and provide explanation about when to choose each option. Tools that the CA provides to the Subscriber MUST allow for these options to be easily specified when the Subscriber requests revocation of their Certificate, with the default value being that no revocation reason is provided (i.e. the default corresponds to the CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL). From 9f9fc086d65617ce1b8258c7fa2b9d2eb349224c Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 19:22:37 +0100 Subject: [PATCH 053/121] #432 missing section anchor --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index eb70dfb6..56fe5369 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2752,7 +2752,7 @@ Table: Organization Validated `subject` Attributes | **Attribute Name** | **Presence** | **Value** | **Verification** | | --- | -- | --- | -- | -| `domainComponent` | MAY | If present, this field MUST contain a Domain Label from a Domain Name. The `domainComponent` fields for the Domain Name MUST be in a single ordered sequence containing all Domain Labels from the Domain Name. The Domain Labels MUST be encoded in the reverse order to the on-wire representation of domain names in the DNS protocol, so that the Domain Label closest to the root is encoded first. Multiple instances MAY be present. | [Section 3.2] | +| `domainComponent` | MAY | If present, this field MUST contain a Domain Label from a Domain Name. The `domainComponent` fields for the Domain Name MUST be in a single ordered sequence containing all Domain Labels from the Domain Name. The Domain Labels MUST be encoded in the reverse order to the on-wire representation of domain names in the DNS protocol, so that the Domain Label closest to the root is encoded first. Multiple instances MAY be present. | [Section 3.2](#32-initial-identity-validation) | | `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.2.1](#3221-identity) | | `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.2.1](#3221-identity) | | `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.2.1](#3221-identity) | From 54b17d1d3efec8ae0ccb1c415742fec1a8a30b08 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 19:31:40 +0100 Subject: [PATCH 054/121] #432 aligned indentation of ordered lists --- docs/BR.md | 72 +++++++++++++++++++++++++++--------------------------- 1 file changed, 36 insertions(+), 36 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 56fe5369..a1b14043 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -846,13 +846,13 @@ This method has been retired and MUST NOT be used. Prior validations using this Confirming the Applicant's control over the FQDN by confirming the presence of a Random Value or Request Token in a DNS CNAME, TXT or CAA record for either - 1. an Authorization Domain Name; or - 2. an Authorization Domain Name that is prefixed with a Domain Label that begins with an underscore character. +1. an Authorization Domain Name; or +2. an Authorization Domain Name that is prefixed with a Domain Label that begins with an underscore character. 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 - 1. 30 days; or - 2. 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 3.2.2.14.3 of the EV Guidelines). +1. 30 days; or +2. 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 3.2.2.14.3 of the EV Guidelines). CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. Random Value or Request Token) as the Primary Network Perspective. @@ -1862,10 +1862,10 @@ Log records MUST include at least the following elements: Logging of router and firewall activities necessary to meet the requirements of Section 5.4.1, Subsection 3.6 MUST at a minimum include: - 1. Successful and unsuccessful login attempts to routers and firewalls; and - 2. Logging of all administrative actions performed on routers and firewalls, including configuration changes, firmware updates, and access control modifications; and - 3. Logging of all changes made to firewall rules, including additions, modifications, and deletions; and - 4. Logging of all system events and errors, including hardware failures, software crashes, and system restarts. +1. Successful and unsuccessful login attempts to routers and firewalls; and +2. Logging of all administrative actions performed on routers and firewalls, including configuration changes, firmware updates, and access control modifications; and +3. Logging of all changes made to firewall rules, including additions, modifications, and deletions; and +4. Logging of all system events and errors, including hardware failures, software crashes, and system restarts. ### 5.4.2 Frequency of processing audit log @@ -1873,11 +1873,11 @@ Logging of router and firewall activities necessary to meet the requirements of The CA and each Delegated Third Party SHALL retain, for at least two (2) years: - 1. CA certificate and key lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (1)) after the later occurrence of: - 1. the destruction of the CA Private Key; or - 2. the revocation or expiration of the final CA Certificate in that set of Certificates that have an X.509v3 `basicConstraints` extension with the `cA` field set to true and which share a common Public Key corresponding to the CA Private Key; - 2. Subscriber Certificate lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (2)) after the expiration of the Subscriber Certificate; - 3. Any security event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (3)) after the event occurred. +1. CA certificate and key lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (1)) after the later occurrence of: + 1. the destruction of the CA Private Key; or + 2. the revocation or expiration of the final CA Certificate in that set of Certificates that have an X.509v3 `basicConstraints` extension with the `cA` field set to true and which share a common Public Key corresponding to the CA Private Key; +2. Subscriber Certificate lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (2)) after the expiration of the Subscriber Certificate; +3. Any security event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (3)) after the event occurred. Note: While these Requirements set the minimum retention period, the CA MAY choose a greater value as more appropriate in order to be able to investigate possible security or other types of incidents that will require retrospection and examination of past audit log events. @@ -2030,9 +2030,9 @@ The CA SHALL reject a certificate request if one or more of the following condit 3. The CA is aware of a demonstrated or proven method that exposes the Applicant's Private Key to compromise; 4. The CA has previously been notified that the Applicant's Private Key has suffered a Key Compromise using the CA's procedure for revocation request as described in [Section 4.9.3](#493-procedure-for-revocation-request) and [Section 4.9.12](#4912-special-requirements-re-key-compromise); 5. The Public Key corresponds to an industry-demonstrated weak Private Key. For requests submitted on or after November 15, 2024, at least the following precautions SHALL be implemented: - 1. In the case of Debian weak keys vulnerability (https://wiki.debian.org/SSLkeys), the CA SHALL reject all keys found at https://github.com/cabforum/Debian-weak-keys/ for each key type (e.g. RSA, ECDSA) and size listed in the repository. For all other keys meeting the requirements of [Section 6.1.5](#615-key-sizes), with the exception of RSA key sizes greater than 8192 bits, the CA SHALL reject Debian weak keys. - 2. In the case of ROCA vulnerability, the CA SHALL reject keys identified by the tools available at https://github.com/crocs-muni/roca or equivalent. - 3. In the case of Close Primes vulnerability (https://fermatattack.secvuln.info/), the CA SHALL reject weak keys which can be factored within 100 rounds using Fermat’s factorization method. + 1. In the case of Debian weak keys vulnerability (https://wiki.debian.org/SSLkeys), the CA SHALL reject all keys found at https://github.com/cabforum/Debian-weak-keys/ for each key type (e.g. RSA, ECDSA) and size listed in the repository. For all other keys meeting the requirements of [Section 6.1.5](#615-key-sizes), with the exception of RSA key sizes greater than 8192 bits, the CA SHALL reject Debian weak keys. + 2. In the case of ROCA vulnerability, the CA SHALL reject keys identified by the tools available at https://github.com/crocs-muni/roca or equivalent. + 3. In the case of Close Primes vulnerability (https://fermatattack.secvuln.info/), the CA SHALL reject weak keys which can be factored within 100 rounds using Fermat’s factorization method. Suggested tools for checking for weak keys can be found here: https://cabforum.org/resources/tools/ @@ -2364,11 +2364,11 @@ Table: Restricted Non-TLS Cross-Certified Subordinate CA Extended Key Usage Purp Each included Extended Key Usage key usage purpose: - 1. MUST apply in the context of the public Internet (e.g. MUST NOT be for a service that is only valid in a privately managed network), unless: - a. the key usage purpose falls within an OID arc for which the Applicant demonstrates ownership; or, - b. the Applicant can otherwise demonstrate the right to assert the key usage purpose in a public context. - 2. MUST NOT include semantics that will mislead the Relying Party about the certificate information verified by the CA, such as including a key usage purpose asserting storage on a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance. - 3. MUST be verified by the Issuing CA (i.e. the Issuing CA MUST verify the Cross-Certified Subordinate CA is authorized to assert the key usage purpose). +1. MUST apply in the context of the public Internet (e.g. MUST NOT be for a service that is only valid in a privately managed network), unless: + a. the key usage purpose falls within an OID arc for which the Applicant demonstrates ownership; or, + b. the Applicant can otherwise demonstrate the right to assert the key usage purpose in a public context. +2. MUST NOT include semantics that will mislead the Relying Party about the certificate information verified by the CA, such as including a key usage purpose asserting storage on a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance. +3. MUST be verified by the Issuing CA (i.e. the Issuing CA MUST verify the Cross-Certified Subordinate CA is authorized to assert the key usage purpose). CAs MUST NOT include additional key usage purposes unless the CA is aware of a reason for including the key usage purpose in the Certificate. @@ -2605,11 +2605,11 @@ Table: `GeneralName` requirements for the `base` field Any `otherName`, if present: - 1. MUST apply in the context of the public Internet, unless: - a. the `type-id` falls within an OID arc for which the Applicant demonstrates ownership, or, - b. the Applicant can otherwise demonstrate the right to assert the data in a public context. - 2. MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA. - 3. MUST be DER encoded according to the relevant ASN.1 module defining the `otherName` `type-id` and `value`. +1. MUST apply in the context of the public Internet, unless: + a. the `type-id` falls within an OID arc for which the Applicant demonstrates ownership, or, + b. the Applicant can otherwise demonstrate the right to assert the data in a public context. +2. MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA. +3. MUST be DER encoded according to the relevant ASN.1 module defining the `otherName` `type-id` and `value`. CAs SHALL NOT include additional names unless the CA is aware of a reason for including the data in the Certificate. @@ -3272,11 +3272,11 @@ Table: `GeneralName` requirements for the `base` field Any `otherName`, if present: - 1. MUST apply in the context of the public Internet, unless: - a. the `type-id` falls within an OID arc for which the Applicant demonstrates ownership, or, - b. the Applicant can otherwise demonstrate the right to assert the data in a public context. - 2. MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA. - 3. MUST be DER encoded according to the relevant ASN.1 module defining the `otherName` `type-id` and `value`. +1. MUST apply in the context of the public Internet, unless: + a. the `type-id` falls within an OID arc for which the Applicant demonstrates ownership, or, + b. the Applicant can otherwise demonstrate the right to assert the data in a public context. +2. MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA. +3. MUST be DER encoded according to the relevant ASN.1 module defining the `otherName` `type-id` and `value`. CAs SHALL NOT include additional names unless the CA is aware of a reason for including the data in the Certificate. @@ -3337,11 +3337,11 @@ If present, the `subjectKeyIdentifier` MUST be set as defined within [RFC 5280, All extensions and extension values not directly addressed by the applicable certificate profile: - 1. MUST apply in the context of the public Internet, unless: - a. the extension OID falls within an OID arc for which the Applicant demonstrates ownership, or, - b. the Applicant can otherwise demonstrate the right to assert the data in a public context. - 2. MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA (such as including an extension that indicates a Private Key is stored on a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance). - 3. MUST be DER encoded according to the relevant ASN.1 module defining the extension and extension values. +1. MUST apply in the context of the public Internet, unless: + a. the extension OID falls within an OID arc for which the Applicant demonstrates ownership, or, + b. the Applicant can otherwise demonstrate the right to assert the data in a public context. +2. MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA (such as including an extension that indicates a Private Key is stored on a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance). +3. MUST be DER encoded according to the relevant ASN.1 module defining the extension and extension values. CAs SHALL NOT include additional extensions or values unless the CA is aware of a reason for including the data in the Certificate. From 1c8184de0deec11b9b1f59374fe838bd5771c036 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 19:53:30 +0100 Subject: [PATCH 055/121] #432 removed additional table cells - not visible in document --- docs/BR.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index a1b14043..e4480ea4 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -3266,9 +3266,9 @@ Table: `GeneralName` requirements for the `base` field | `dNSName` | MAY | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | | `iPAddress` | MAY | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the assignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | | `directoryName` | MAY | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | It is NOT RECOMMENDED to include values within `excludedSubtrees`. | -| `rfc822Name` | NOT RECOMMENDED | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | If no `rfc822Name` instance is present in the `permittedSubtrees`, then the CA MAY include a zero-length `rfc822Name` to indicate no mailboxes are permitted. | -| `otherName` | NOT RECOMMENDED | See below | See below | See below | -| Any other value | NOT RECOMMENDED | - | - | - | +| `rfc822Name` | NOT RECOMMENDED | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | +| `otherName` | NOT RECOMMENDED | See below | See below | +| Any other value | NOT RECOMMENDED | - | - | Any `otherName`, if present: From 1c8736c6d1ca829af17a72ec3105d37f36650333 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 19:57:07 +0100 Subject: [PATCH 056/121] #432 removed empty lines --- docs/EVG.md | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 88a36011..0af36502 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -579,10 +579,8 @@ To verify any assumed name under which the Applicant conducts business: 2. **Acceptable Methods of Verification** - A. **Place of Business in the Country of Incorporation or Registration** - i. For Applicants whose Place of Business is in the same country as the Applicant's Jurisdiction of Incorporation or Registration and whose Place of Business is NOT the same as that indicated in the relevant Qualified Government Information Source used in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) to verify legal existence: 1. For Applicants listed at the same Place of Business address in the current version of either at least one QGIS (other than that used to verify legal existence), QIIS or QTIS, the CA MUST confirm that the Applicant's address, as listed in the EV Certificate Request, is a valid business address for the Applicant or a Parent/Subsidiary Company by reference to such QGIS, QIIS, or QTIS, and MAY rely on the Applicant's representation that such address is its Place of Business; @@ -2161,12 +2159,3 @@ The following Registration Schemes are currently recognized as valid under these [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). The stated address of the organization combined with the organization name SHALL NOT be the only information used to disambiguate the organization. - - - - - - - - - From 38a98e32fa3f35571c95bc768d8467458e9078f1 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 24 Nov 2025 20:05:23 +0100 Subject: [PATCH 057/121] #299 added links to 1.2.2 Relevant Dates sections BR again after merge --- docs/BR.md | 88 ++++++++++++++---------------------------------------- 1 file changed, 22 insertions(+), 66 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index e4480ea4..4f960310 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -159,72 +159,28 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse ### 1.2.2 Relevant Dates | **Compliance** | **Section(s)** | **Summary Description (See Full Text for Details)** | -|---|--|-----| -| 2013-01-01 | 6.1.6 | For RSA public keys, CAs SHALL confirm that the value of the public exponent is an odd number equal to 3 or more. | -| 2013-01-01 | 4.9.10 | CAs SHALL support an OCSP capability using the GET method. | -| 2013-01-01 | 5 | CAs SHALL comply with the Network and Certificate System Security Requirements. | -| 2013-08-01 | 4.9.10 | OCSP Responders SHALL NOT respond "Good" for Unissued Certificates. | -| 2013-09-01 | 3.2.2.6 | CAs SHALL revoke any certificate where wildcard character occurs in the first label position immediately to the left of a "registry-controlled" label or "public suffix". | -| 2013-12-31 | 6.1.5 | CAs SHALL confirm that the RSA Public Key is at least 2048 bits or that one of the following ECC curves is used: P-256, P-384, or P-521. A Root CA Certificate issued prior to 31 Dec. 2010 with an RSA key size less than 2048 bits MAY still serve as a trust anchor. | -| 2015-01-16 | 7.1.3 | CAs SHOULD NOT issue Subscriber Certificates utilizing the SHA-1 algorithm with an Expiry Date greater than 1 January 2017. | -| 2015-04-01 | 6.3.2 | CAs SHALL NOT issue certificates with validity periods longer than 39 months, except under certain circumstances. | -| 2015-04-15 | 2.2 | A CA's CPS must state whether it reviews CAA Records, and if so, its policy or practice on processing CAA records for Fully-Qualified Domain Names. | -| 2015-11-01 | 7.1.4.2.1 | Issuance of Certificates with Reserved IP Address or Internal Name prohibited. | -| 2016-01-01 | 7.1.3 | CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA-1 hash algorithm. | -| 2016-06-30 | 6.1.7 | CAs MUST NOT issue Subscriber Certificates directly from Root CAs. | -| 2016-06-30 | 6.3.2 | CAs MUST NOT issue Subscriber Certificates with validity periods longer than 39 months, regardless of circumstance. | -| 2016-09-30 | 7.1 | CAs SHALL generate Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG | -| 2016-10-01 | 7.1.4.2.1 | All Certificates with Reserved IP Address or Internal Name must be revoked. | -| 2016-12-03 | 1 and 2 | Ballot 156 amendments to sections 1.5.2, 2.3, and 2.4 are applicable | -| 2017-01-01 | 7.1.3 | CAs MUST NOT issue OCSP responder certificates using SHA-1 (inferred). | -| 2017-03-01 | 3.2.2.4 | CAs MUST follow revised validation requirements in Section 3.2.2.4. | -| 2017-09-08 | 3.2.2.8 | CAs MUST check and process CAA records | -| 2018-03-01 | 4.2.1 and 6.3.2 | Certificates issued MUST have a Validity Period no greater than 825 days and re-use of validation information limited to 825 days | -| 2018-05-31 | 2.2 | CP and CPS must follow RFC 3647 format | -| 2018-08-01 | 3.2.2.4.1 and .5 | CAs must stop using domain validation methods BR 3.2.2.4.1 and 3.2.2.4.5, stop reusing validation data from those methods | -| 2019-01-15 | 7.1.4.2.1 | All certificates containing an underscore character in any dNSName entry and having a validity period of more than 30 days MUST be revoked prior to January 15, 2019 | -| 2019-05-01 | 7.1.4.2.1 | underscore characters (“_”) MUST NOT be present in dNSName entries | -| 2019-06-01 | 3.2.2.4.3 | 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. | -| 2019-08-01 | 3.2.2.5 | CAs SHALL maintain a record of which IP validation method, including the relevant BR version number, was used to validate every IP Address | -| 2019-08-01 | 3.2.2.5.4 | CAs SHALL NOT perform validations using this method after July 31, 2019. Completed validations using this method SHALL NOT be re-used for certificate issuance after July 31, 2019. Any certificate issued prior to August 1, 2019 containing an IP Address that was validated using any method that was permitted under the prior version of this Section 3.2.2.5 MAY continue to be used without revalidation until such certificate naturally expires | -| 2020-06-03 | 3.2.2.4.6 | CAs MUST NOT perform validation using this method after 3 months from the IPR review date of Ballot SC25 | -| 2020-08-01 | 8.6 | Audit Reports for periods on-or-after 2020-08-01 MUST be structured as defined. | -| 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 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. | -| 2021-10-01 | 7.1.4.2.1 | Fully-Qualified Domain Names MUST consist solely of P-Labels and Non-Reserved LDH Labels. | -| 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 | -| 2023-07-15 | 4.9.1.1 and 7.2.2 | New CRL entries MUST have a revocation reason code | -| 2023-09-15 | Section 7 (and others) | CAs MUST use the updated Certificate Profiles passed in Version 2.0.0 | -| 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | -| 2024-09-15 | 4.3.1.2 | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | -| 2025-01-15 | 4.9.9 | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. | -| 2025-01-15 | 3.2.2.4 | CAs MUST NOT rely on HTTPS websites to identify Domain Contact information. CAs MUST rely on IANA resources for identifying Domain Contact information. | -| 2025-03-15 | 4.3.1.2 | The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | -| 2025-03-15 | 8.7 | The CA SHOULD use a Linting process to test the technical accuracy of already issued Certificates against the sample set chosen for Self-Audits. | -| 2025-03-15 | 3.2.2.9 | CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified. | -| 2025-07-15 | 3.2.2.4 | CAs MUST NOT rely on Methods 3.2.2.4.2 and 3.2.2.4.15 to issue Subscriber Certificates. | -| 2025-12-01 | 5.7.1.2 | CAs SHALL assert in section 5.7.1 of their CPS or combined CP/CPS their mass revocation plan, testing, and continuous improvements. | -| 2026-03-15 | 3.2.2.4 | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network | -| 2026-03-15 | 3.2.2.4 | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. | -| 2026-03-15 | 3.2.2.8.1 | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. | -| 2026-03-15 | 3.2.2.8.1 | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. | -| 2026-03-15 | 3.2.2.8.1 | DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. | -| 2026-03-15 | 4.2.1 | Subject Identity Information validation maximum data reuse period is 398 days. | -| 2026-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 200 days. | -| 2026-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 200 days. | -| 2026-03-15 | 7.1.2.4 | CAs MUST NOT use Precertificate Signing CAs to issue Precertificates. CAs MUST NOT issue certificates using the Technically Constrained Precertificate Signing CA Certificate Profile specified in Section 7.1.2.4. | -| 2027-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 100 days. | -| 2027-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 100 days. | -| 2029-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 10 days. | -| 2029-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 47 days. | +| -- | - | -------- | +| 2024-03-15 | [4.9.7](#497-crl-issuance-frequency) | CAs MUST generate and publish CRLs. | +| 2024-09-15 | [4.3.1.2](#4312-linting-of-to-be-signed-certificate-content) | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | +| 2025-01-15 | [4.9.9](#499-on-line-revocationstatus-checking-availability) | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. | +| 2025-01-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | CAs MUST NOT rely on HTTPS websites to identify Domain Contact information. CAs MUST rely on IANA resources for identifying Domain Contact information. | +| 2025-03-15 | [4.3.1.2](#4312-linting-of-to-be-signed-certificate-content) | The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | +| 2025-03-15 | [8.7](#87-self-audits) | The CA SHOULD use a Linting process to test the technical accuracy of already issued Certificates against the sample set chosen for Self-Audits. | +| 2025-03-15 | [3.2.2.9](#3229-multi-perspective-issuance-corroboration) | CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified. | +| 2025-07-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | CAs MUST NOT rely on Methods 3.2.2.4.2 and 3.2.2.4.15 to issue Subscriber Certificates. | +| 2025-12-01 | [5.7.1.2](#5712-mass-revocation-plans) | CAs SHALL assert in section 5.7.1 of their CPS or combined CP/CPS their mass revocation plan, testing, and continuous improvements. | +| 2026-03-15 | [4.2.1](#421-performing-identification-and-authentication-functions) | Subject Identity Information validation maximum data reuse period is 398 days. | +| 2026-03-15 | [4.2.1](#421-performing-identification-and-authentication-functions) | Domain Name and IP Address validation maximum data reuse period is 200 days. | +| 2026-03-15 | [6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) | Maximum validity period of Subscriber Certificates is 200 days. | +| 2026-03-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. | +| 2026-03-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. | +| 2026-03-15 | [3.2.2.8.1](#32281-dnssec-validation-of-caa-records) | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. | +| 2026-03-15 | [3.2.2.8.1](#32281-dnssec-validation-of-caa-records) | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. | +| 2026-03-15 | [3.2.2.8.1](#32281-dnssec-validation-of-caa-records) | DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. | +| 2027-03-15 | [4.2.1](#421-performing-identification-and-authentication-functions) | Domain Name and IP Address validation maximum data reuse period is 100 days. | +| 2027-03-15 | [6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) | Maximum validity period of Subscriber Certificates is 100 days. | +| 2029-03-15 | [4.2.1](#421-performing-identification-and-authentication-functions) | Domain Name and IP Address validation maximum data reuse period is 10 days. | +| 2029-03-15 | [6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) | Maximum validity period of Subscriber Certificates is 47 days. | ## 1.3 PKI Participants From 12ed1716fbca5745adb940c16be9825954f080be Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 25 Nov 2025 08:20:38 +0100 Subject: [PATCH 058/121] #432 all urls as --- docs/BR.md | 18 +++++++++--------- docs/EVG.md | 4 ++-- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 4f960310..cdc95a6d 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -618,7 +618,6 @@ By convention, this document omits time and timezones when listing effective req # 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES -The CA SHALL develop, implement, enforce, and at least once every 366 days update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements. ## 2.1 Repositories @@ -626,7 +625,8 @@ The CA SHALL make revocation information for Subordinate Certificates and Subscr ## 2.2 Publication of information -The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see [Section 8.4](#84-topics-covered-by-assessment)). +The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see [Section 8.4](#84-topics-covered-by-assessmen +The CA SHALL develop, implement, enforce, and at least once every 366 days update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements.t)). The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and MUST include all material required by RFC 3647. @@ -1350,7 +1350,7 @@ Methods used to produce a certificate containing the to-be-signed Certificate co 1. Sign the `tbsCertificate` with a "dummy" Private Key whose Public Key component is not certified by a Certificate that chains to a publicly-trusted CA Certificate; or 2. Specify a static value for the `signature` field of the Certificate ASN.1 SEQUENCE. -CAs MAY implement their own certificate Linting tools, but CAs SHOULD use the Linting tools that have been widely adopted by the industry (see https://cabforum.org/resources/tools/). +CAs MAY implement their own certificate Linting tools, but CAs SHOULD use the Linting tools that have been widely adopted by the industry (see ). CAs are encouraged to contribute to open-source Linting projects, such as by: @@ -1986,11 +1986,11 @@ The CA SHALL reject a certificate request if one or more of the following condit 3. The CA is aware of a demonstrated or proven method that exposes the Applicant's Private Key to compromise; 4. The CA has previously been notified that the Applicant's Private Key has suffered a Key Compromise using the CA's procedure for revocation request as described in [Section 4.9.3](#493-procedure-for-revocation-request) and [Section 4.9.12](#4912-special-requirements-re-key-compromise); 5. The Public Key corresponds to an industry-demonstrated weak Private Key. For requests submitted on or after November 15, 2024, at least the following precautions SHALL be implemented: - 1. In the case of Debian weak keys vulnerability (https://wiki.debian.org/SSLkeys), the CA SHALL reject all keys found at https://github.com/cabforum/Debian-weak-keys/ for each key type (e.g. RSA, ECDSA) and size listed in the repository. For all other keys meeting the requirements of [Section 6.1.5](#615-key-sizes), with the exception of RSA key sizes greater than 8192 bits, the CA SHALL reject Debian weak keys. - 2. In the case of ROCA vulnerability, the CA SHALL reject keys identified by the tools available at https://github.com/crocs-muni/roca or equivalent. - 3. In the case of Close Primes vulnerability (https://fermatattack.secvuln.info/), the CA SHALL reject weak keys which can be factored within 100 rounds using Fermat’s factorization method. + 1. In the case of Debian weak keys vulnerability (), the CA SHALL reject all keys found at for each key type (e.g. RSA, ECDSA) and size listed in the repository. For all other keys meeting the requirements of [Section 6.1.5](#615-key-sizes), with the exception of RSA key sizes greater than 8192 bits, the CA SHALL reject Debian weak keys. + 2. In the case of ROCA vulnerability, the CA SHALL reject keys identified by the tools available at or equivalent. + 3. In the case of Close Primes vulnerability (), the CA SHALL reject weak keys which can be factored within 100 rounds using Fermat’s factorization method. - Suggested tools for checking for weak keys can be found here: https://cabforum.org/resources/tools/ + Suggested tools for checking for weak keys can be found here: If the Subscriber Certificate will contain an `extKeyUsage` extension containing either the values `id-kp-serverAuth` [RFC5280] or `anyExtendedKeyUsage` [RFC5280], the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA. @@ -2832,7 +2832,7 @@ Table: Key Usage for RSA Public Keys | `encipherOnly` | N | -- | | `decipherOnly` | N | -- | -**Note**: At least one Key Usage MUST be set for RSA Public Keys. The `digitalSignature` bit is REQUIRED for use with modern protocols, such as TLS 1.3, and secure ciphersuites, while the `keyEncipherment` bit MAY be asserted to support older protocols, such as TLS 1.2, when using insecure ciphersuites. Subscribers MAY wish to ensure key separation to limit the risk from such legacy protocols, and thus a CA MAY issue a Subscriber certificate that only asserts the `keyEncipherment` bit. For most Subscribers, the `digitalSignature` bit is sufficient, while Subscribers that want to mix insecure and secure ciphersuites with the same algorithm may choose to assert both `digitalSignature` and `keyEncipherment` within the same certificate, although this is NOT RECOMMENDED. The `dataEncipherment` bit is currently permitted, although setting it is NOT RECOMMENDED, as it is a Pending Prohibition (https://github.com/cabforum/servercert/issues/384). +**Note**: At least one Key Usage MUST be set for RSA Public Keys. The `digitalSignature` bit is REQUIRED for use with modern protocols, such as TLS 1.3, and secure ciphersuites, while the `keyEncipherment` bit MAY be asserted to support older protocols, such as TLS 1.2, when using insecure ciphersuites. Subscribers MAY wish to ensure key separation to limit the risk from such legacy protocols, and thus a CA MAY issue a Subscriber certificate that only asserts the `keyEncipherment` bit. For most Subscribers, the `digitalSignature` bit is sufficient, while Subscribers that want to mix insecure and secure ciphersuites with the same algorithm may choose to assert both `digitalSignature` and `keyEncipherment` within the same certificate, although this is NOT RECOMMENDED. The `dataEncipherment` bit is currently permitted, although setting it is NOT RECOMMENDED, as it is a Pending Prohibition (). Table: Key Usage for ECC Public Keys @@ -2848,7 +2848,7 @@ Table: Key Usage for ECC Public Keys | `encipherOnly` | N | -- | | `decipherOnly` | N | -- | -**Note**: The `keyAgreement` bit is currently permitted, although setting it is NOT RECOMMENDED, as it is a Pending Prohibition (https://github.com/cabforum/servercert/issues/384). +**Note**: The `keyAgreement` bit is currently permitted, although setting it is NOT RECOMMENDED, as it is a Pending Prohibition (). ##### 7.1.2.7.12 Subscriber Certificate Subject Alternative Name diff --git a/docs/EVG.md b/docs/EVG.md index 0af36502..d86eeb4f 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -97,7 +97,7 @@ These Guidelines do not address the verification of information, or the issuance | 2020-10-01 | [3.2.2.1.3](#32213-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 | [7.1.4.2.7](#71427-subject-organizational-unit-name-field) | CAs MUST NOT include the organizationalUnitName field in the Subject | -**Implementers' Note**: Version 1.3 of these EV Guidelines was published on 20 November 2010 and supplemented through May 2012 when version 1.4 was published. ETSI TS 102 042 and ETSI TR 101 564 Technical Report: Guidance on ETSI TS 102 042 for Issuing Extended Validation Certificates for Auditors and CSPs reference version 1.3 of these EV Guidelines, and ETSI Draft EN 319 411-1 references version 1.4. Version 1.4.5 of Webtrust(r) for Certification Authorities – Extended Validation Audit Criteria references version 1.4.5 of these EV Guidelines. As illustrated in the Document History table above, the CA/Browser Forum continues to improve relevant industry guidelines, including this document, the Baseline Requirements, and the Network and Certificate System Security Requirements. We encourage all CAs to conform to each revision 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. We will respond to implementation questions directed to questions@cabforum.org. 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. +**Implementers' Note**: Version 1.3 of these EV Guidelines was published on 20 November 2010 and supplemented through May 2012 when version 1.4 was published. ETSI TS 102 042 and ETSI TR 101 564 Technical Report: Guidance on ETSI TS 102 042 for Issuing Extended Validation Certificates for Auditors and CSPs reference version 1.3 of these EV Guidelines, and ETSI Draft EN 319 411-1 references version 1.4. Version 1.4.5 of Webtrust(r) for Certification Authorities – Extended Validation Audit Criteria references version 1.4.5 of these EV Guidelines. As illustrated in the Document History table above, the CA/Browser Forum continues to improve relevant industry guidelines, including this document, the Baseline Requirements, and the Network and Certificate System Security Requirements. We encourage all CAs to conform to each revision 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. 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. ## 1.3 PKI participants @@ -546,7 +546,7 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo A. With reference to the constituent document under which the International Organization was formed; or B. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or - C. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at www.cabforum.org. + C. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at . D. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency. 6. The CA may rely on a Verified Professional Letter to establish the Applicant's information listed in (1)-(5) above if: From d49b5cb4f0830fdb0b4a15b68d3c4ef0dec3e15f Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 25 Nov 2025 08:26:11 +0100 Subject: [PATCH 059/121] #623 changed as in comment --- docs/EVG.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index d86eeb4f..1f5c0d2b 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -1533,8 +1533,14 @@ Effective as of 1 October 2020, if the CA has disclosed a set of acceptable form State or province (where applicable): `subject:stateOrProvinceName` (OID: 2.5.4.8) Country: `subject:countryName` (OID: 2.5.4.6) Postal code: `subject:postalCode` (OID: 2.5.4.17) -**Required/Optional**: As stated in Section 7.1.4.2.2 d, e, f, g and h of the Baseline Requirements. -**Contents**: This field MUST contain the address of the physical location of the Subject's Place of Business. +**Required/Optional**: Required/Optional +**Contents**: These fields MUST contain the verified physical address of the Subject’s Place of Business. + +The `countryName` field MUST be present and MUST contain the applicable two-letter ISO 3166-1 country code. If the country is not represented by an official ISO 3166-1 code, the ISO 3166-1 user-assigned code "XX" MUST be used. + +The `localityName` and `stateOrProvinceName` fields are OPTIONAL, but at least one of them MUST be present. When included, these fields MUST accurately represent the locality and/or state or province information verified in accordance with Section 3.2.2.1 of the Baseline Requirements. + +The `streetAddress` and `postalCode` fields are OPTIONAL. If present, they MUST contain the verified street address and postal information of the Subject’s Place of Business as required by Section 3.2.2.1 of the Baseline Requirements. Multiple `streetAddress` attributes MAY be present. ##### 7.1.4.2.7 Subject Organizational Unit Name Field From 669fcde1df249d085ab762805b7851711ca2f787 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 25 Nov 2025 08:31:23 +0100 Subject: [PATCH 060/121] #432 fixed link --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index cdc95a6d..b4ceb0f4 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -625,7 +625,7 @@ The CA SHALL make revocation information for Subordinate Certificates and Subscr ## 2.2 Publication of information -The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see [Section 8.4](#84-topics-covered-by-assessmen +The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see [Section 8.4](#84-topics-covered-by-assessment)). The CA SHALL develop, implement, enforce, and at least once every 366 days update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements.t)). The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and MUST include all material required by RFC 3647. From 3a347211680bc81a7dfbb331e9b5960fc702b1cd Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 26 Nov 2025 18:43:29 +0100 Subject: [PATCH 061/121] #458 reverted removal of 2 and 3 --- docs/BR.md | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index b4ceb0f4..ece7671b 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1493,22 +1493,24 @@ The CA MAY support revocation of Short-lived Subscriber Certificates. With the exception of Short-lived Subscriber Certificates, the CA SHALL revoke a Certificate within 24 hours and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs: 1. The Subscriber requests in writing, without specifying a CRLreason, that the CA revoke the Certificate (CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL); -2. 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, including but not limited to those identified in [Section 6.1.1.3(5)](#6113-subscriber-key-pair-generation) (CRLReason #1, keyCompromise); -3. The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon (CRLReason #4, superseded). +2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization (CRLReason #9, privilegeWithdrawn); +3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise (CRLReason #1, keyCompromise); +4. 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, including but not limited to those identified in [Section 6.1.1.3(5)](#6113-subscriber-key-pair-generation) (CRLReason #1, keyCompromise); +5. The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon (CRLReason #4, superseded). With the exception of Short-lived Subscriber Certificates, the CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs: -4. 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) (CRLReason #4, superseded); -5. The CA obtains evidence that the Certificate was misused (CRLReason #9, privilegeWithdrawn); -6. 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 (CRLReason #9, privilegeWithdrawn); -7. 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) (CRLReason # 5, cessationOfOperation); -8. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name (CRLReason #9, privilegeWithdrawn); -9. The CA is made aware of a material change in the information contained in the Certificate (CRLReason #9, privilegeWithdrawn); -10. 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 (CRLReason #4, superseded); -11. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate (CRLReason #9, privilegeWithdrawn); -12. 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 (CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL); -13. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement for a reason that is not otherwise required to be specified by this section 4.9.1.1 (CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL); or -14. 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 (CRLReason #1, keyCompromise). +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) (CRLReason #4, superseded); +7. The CA obtains evidence that the Certificate was misused (CRLReason #9, privilegeWithdrawn); +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 (CRLReason #9, privilegeWithdrawn); +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) (CRLReason # 5, cessationOfOperation); +10. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name (CRLReason #9, privilegeWithdrawn); +11. The CA is made aware of a material change in the information contained in the Certificate (CRLReason #9, privilegeWithdrawn); +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 (CRLReason #4, superseded); +13. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate (CRLReason #9, privilegeWithdrawn); +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 (CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL); +15. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement for a reason that is not otherwise required to be specified by this section 4.9.1.1 (CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL); 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 (CRLReason #1, keyCompromise). #### 4.9.1.2 Reasons for Revoking a Subordinate CA Certificate From f851b93d3232c0afc9f084dce61dce1d15f25bd6 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 26 Nov 2025 19:07:06 +0100 Subject: [PATCH 062/121] #432 spaces removed --- docs/BR.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index ece7671b..c490acdb 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -220,7 +220,7 @@ In some situations, a CA acts as an Applicant or Subscriber, for instance, when ### 1.3.4 Relying Parties -"Relying Party" and "Application Software Supplier" are defined in [Section 1.6.1](#161-definitions). Current Members of the CA/Browser Forum who are Application Software Suppliers are listed here: +"Relying Party" and "Application Software Supplier" are defined in [Section 1.6.1](#161-definitions). Current Members of the CA/Browser Forum who are Application Software Suppliers are listed here: . ### 1.3.5 Other Participants @@ -618,7 +618,6 @@ By convention, this document omits time and timezones when listing effective req # 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES - ## 2.1 Repositories The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with this Policy. @@ -1227,7 +1226,7 @@ If any of the above considerations are performed by a Delegated Third Party, the Phased Implementation Timeline: - *Effective September 15, 2024*, the CA SHOULD implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. -- *Effective March 15, 2025*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MAY proceed with certificate issuance if the number of remote Network Perspectives that do not corroborate the determinations made by the Primary Network Perspective ("non-corroborations") is greater than allowed in the Quorum Requirements table. +- *Effective March 15, 2025*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MAY proceed with certificate issuance if the number of remote Network Perspectives that do not corroborate the determinations made by the Primary Network Perspective ("non-corroborations") is greater than allowed in the Quorum Requirements table. - *Effective September 15, 2025*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. - *Effective March 15, 2026*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least three (3) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. - *Effective June 15, 2026*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least four (4) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. @@ -1503,7 +1502,7 @@ With the exception of Short-lived Subscriber Certificates, the CA SHOULD revoke 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) (CRLReason #4, superseded); 7. The CA obtains evidence that the Certificate was misused (CRLReason #9, privilegeWithdrawn); 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 (CRLReason #9, privilegeWithdrawn); -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) (CRLReason # 5, cessationOfOperation); +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) (CRLReason #5, cessationOfOperation); 10. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name (CRLReason #9, privilegeWithdrawn); 11. The CA is made aware of a material change in the information contained in the Certificate (CRLReason #9, privilegeWithdrawn); 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 (CRLReason #4, superseded); @@ -1990,7 +1989,7 @@ The CA SHALL reject a certificate request if one or more of the following condit 5. The Public Key corresponds to an industry-demonstrated weak Private Key. For requests submitted on or after November 15, 2024, at least the following precautions SHALL be implemented: 1. In the case of Debian weak keys vulnerability (), the CA SHALL reject all keys found at for each key type (e.g. RSA, ECDSA) and size listed in the repository. For all other keys meeting the requirements of [Section 6.1.5](#615-key-sizes), with the exception of RSA key sizes greater than 8192 bits, the CA SHALL reject Debian weak keys. 2. In the case of ROCA vulnerability, the CA SHALL reject keys identified by the tools available at or equivalent. - 3. In the case of Close Primes vulnerability (), the CA SHALL reject weak keys which can be factored within 100 rounds using Fermat’s factorization method. + 3. In the case of Close Primes vulnerability (), the CA SHALL reject weak keys which can be factored within 100 rounds using Fermat’s factorization method. Suggested tools for checking for weak keys can be found here: From d2d5af6b4a2fac7074fe411d8a197dfc21a73c20 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 26 Nov 2025 19:32:44 +0100 Subject: [PATCH 063/121] #432 removed double spaces --- docs/EVG.md | 518 ++++++++++++++++++++++++---------------------------- 1 file changed, 242 insertions(+), 276 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 1f5c0d2b..b179e5bb 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -14,23 +14,23 @@ copyright: | # 1. INTRODUCTION -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 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. +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. **Notice to Readers** -The Guidelines for the Issuance and Management of Extended Validation Certificates present criteria established by the CA/Browser Forum for use by certification authorities when issuing, maintaining, and revoking certain digital certificates for use in Internet Web site commerce. These Guidelines may be revised from time to time, as appropriate, in accordance with procedures adopted by the CA/Browser Forum. Questions or suggestions concerning these guidelines may be directed to the CA/Browser Forum at . +The Guidelines for the Issuance and Management of Extended Validation Certificates present criteria established by the CA/Browser Forum for use by certification authorities when issuing, maintaining, and revoking certain digital certificates for use in Internet Web site commerce These Guidelines may be revised from time to time, as appropriate, in accordance with procedures adopted by the CA/Browser Forum. Questions or suggestions concerning these guidelines may be directed to the CA/Browser Forum at . **The CA/Browser Forum** -The CA/Browser Forum is a voluntary open organization of certification authorities and suppliers of Internet browsers and other relying-party software applications. Membership is listed at . +The CA/Browser Forum is a voluntary open organization of certification authorities and suppliers of Internet browsers and other relying-party software applications. Membership is listed at . ## 1.1 Overview -These Guidelines for the issuance and management of Extended Validation Certificates describe certain of the minimum requirements that a Certification Authority must meet in order to issue Extended Validation Certificates. Subject Organization information from Valid EV Certificates may be displayed 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 they are accessing. These Guidelines incorporate the Baseline Requirements established by the CA/Browser Forum by reference. A copy of the Baseline Requirements is available on the CA/Browser Forum's website at . +These Guidelines for the issuance and management of Extended Validation Certificates describe certain of the minimum requirements that a Certification Authority must meet in order to issue Extended Validation Certificates. Subject Organization information from Valid EV Certificates may be displayed 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 they are accessing. These Guidelines incorporate the Baseline Requirements established by the CA/Browser Forum by reference. A copy of the Baseline Requirements is available on the CA/Browser Forum's website at . -These Guidelines address the basic issue of validating Subject identity information in EV Certificates and some related matters. They do not address all of the related matters, such as certain technical and operational ones. This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet. However, the Working Group encourages the re-use of these guidelines as a basis for similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. +These Guidelines address the basic issue of validating Subject identity information in EV Certificates and some related matters. They do not address all of the related matters, such as certain technical and operational ones. This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet. However, the Working Group encourages the re-use of these guidelines as a basis for similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. These Guidelines do not address the verification of information, or the issuance, use, maintenance, or revocation of EV Certificates by enterprises that operate their own Public Key Infrastructure for internal purposes only, where its Root CA Certificate is not distributed by any Application Software Supplier. @@ -60,8 +60,8 @@ These Guidelines do not address the verification of information, or the issuance | 1.5.7 | 151 | Addition of Optional OIDs for Indicating Level of Validation | 28 Sept 2015 | 28 Sept 2015 | | 1.5.8 | 162 | Sunset of Exceptions | 15 Mar 2016 | 15 Mar 2016 | | 1.5.9 | 163 | Fix Errata in EV Guidelines 11.2.1 | 18 Mar 2016 | 18 Mar 2016 | -| 1.6.0 | 171 | Updating ETSI Standards | 1 July 2016 | 1 July 2016 | -| 1.6.1 | 180 | In EV 11.7.1, removed outdated cross-reference to BR 3.2.2.4(7) | 7 Jan. 2017 | 7 Jan. 2017 | +| 1.6.0 | 171 | Updating ETSI Standards | 1 July 2016 | 1 July 2016 | +| 1.6.1 | 180 | In EV 11.7.1, removed outdated cross-reference to BR 3.2.2.4(7) | 7 Jan. 2017 | 7 Jan. 2017 | | 1.6.2 | 103 | 825-day Certificate Lifetimes | 17 Mar. 2017 | 17 Mar. 2017 | | 1.6.3 | 198 | .Onion Revisions (declared invalid) | 7 May 2017 | 8 June 2017 | | 1.6.4 | 191 | Clarify Place of Business Information | 23 May 2017 | 23 June 2017 | @@ -97,7 +97,7 @@ These Guidelines do not address the verification of information, or the issuance | 2020-10-01 | [3.2.2.1.3](#32213-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 | [7.1.4.2.7](#71427-subject-organizational-unit-name-field) | CAs MUST NOT include the organizationalUnitName field in the Subject | -**Implementers' Note**: Version 1.3 of these EV Guidelines was published on 20 November 2010 and supplemented through May 2012 when version 1.4 was published. ETSI TS 102 042 and ETSI TR 101 564 Technical Report: Guidance on ETSI TS 102 042 for Issuing Extended Validation Certificates for Auditors and CSPs reference version 1.3 of these EV Guidelines, and ETSI Draft EN 319 411-1 references version 1.4. Version 1.4.5 of Webtrust(r) for Certification Authorities – Extended Validation Audit Criteria references version 1.4.5 of these EV Guidelines. As illustrated in the Document History table above, the CA/Browser Forum continues to improve relevant industry guidelines, including this document, the Baseline Requirements, and the Network and Certificate System Security Requirements. We encourage all CAs to conform to each revision 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. 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. +**Implementers' Note**: Version 1.3 of these EV Guidelines was published on 20 November 2010 and supplemented through May 2012 when version 1.4 was published. ETSI TS 102 042 and ETSI TR 101 564 Technical Report: Guidance on ETSI TS 102 042 for Issuing Extended Validation Certificates for Auditors and CSPs reference version 1.3 of these EV Guidelines, and ETSI Draft EN 319 411-1 references version 1.4. Version 1.4.5 of Webtrust(r) for Certification Authorities – Extended Validation Audit Criteria references version 1.4.5 of these EV Guidelines. As illustrated in the Document History table above, the CA/Browser Forum continues to improve relevant industry guidelines, including this document, the Baseline Requirements, and the Network and Certificate System Security Requirements. We encourage all CAs to conform to each revision 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. 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. ## 1.3 PKI participants @@ -110,11 +110,11 @@ Affiliates and/or RAs must comply with the qualification requirements of [Sectio The CA SHALL verify that the Delegated Third Party's personnel involved in the issuance of a Certificate meet the training and skills requirements of [Section 5.3](#53-personnel-controls) and the document retention and event logging requirements of [Section 5.4](#54-audit-logging-procedures). -In all cases, the CA MUST contractually obligate each Affiliate, RA, subcontractor, and Enterprise RA to comply with all applicable requirements in these Guidelines and to perform them as required of the CA itself. The CA SHALL enforce these obligations and internally audit each Affiliate's, RA's, subcontractor's, and Enterprise RA's compliance with these Requirements on an annual basis. +In all cases, the CA MUST contractually obligate each Affiliate, RA, subcontractor, and Enterprise RA to comply with all applicable requirements in these Guidelines and to perform them as required of the CA itself.The CA SHALL enforce these obligations and internally audit each Affiliate's, RA's, subcontractor's, and Enterprise RA's compliance with these Requirements on an annual basis. #### 1.3.2.1 Enterprise Registration authorities -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: +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 @@ -144,7 +144,7 @@ The primary purposes of an EV Certificate are to: #### 1.4.1.2 Secondary Purposes -The secondary purposes of an EV Certificate are to help establish the legitimacy of a business claiming to operate a Web site, and to provide a vehicle that can be used to assist in addressing problems related to phishing, and other forms of online identity fraud. By providing more reliable third-party verified identity and address information regarding the business, EV Certificates may help to: +The secondary purposes of an EV Certificate are to help establish the legitimacy of a business claiming to operate a Web site, and to provide a vehicle that can be used to assist in addressing problems related to phishing, and other forms of online identity fraud. By providing more reliable third-party verified identity and address information regarding the business, EV Certificates may help to: 1. Make it more difficult to mount phishing and other online identity fraud attacks using Certificates; 2. Assist companies that may be the target of phishing attacks or online identity fraud by providing them with a tool to better identify themselves to users; and @@ -152,7 +152,7 @@ The secondary purposes of an EV Certificate are to help establish the legitimacy ### 1.4.2 Prohibited certificate uses -EV Certificates focus only on the identity of the Subject named in the Certificate, and not on the behavior of the Subject. As such, an EV Certificate is **not** intended to provide any assurances, or otherwise represent or warrant: +EV Certificates focus only on the identity of the Subject named in the Certificate, and not on the behavior of the Subject. As such, an EV Certificate is **not** intended to provide any assurances, or otherwise represent or warrant: 1. That the Subject named in the EV Certificate is actively engaged in doing business; 2. That the Subject named in the EV Certificate complies with applicable laws; @@ -194,7 +194,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Contract Signer**: A natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements. -**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. +**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. **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. @@ -215,17 +215,17 @@ Capitalized Terms are defined in the Baseline Requirements except where provided i. indicates which CA policy statement relates to that certificate, and ii. is either the CA/Browser Forum EV policy identifier or a policy identifier that, by pre-agreement with one or more Application Software Supplier, marks the certificate as being an EV Certificate. -**EV Policies**: Auditable EV Certificate practices, policies and procedures, such as a certification practice statement and certificate policy, that are developed, implemented, and enforced by the CA and its Root CA. +**EV Policies**: Auditable EV Certificate practices, policies and procedures, such as a certification practice statement and certificate policy, that are developed, implemented, and enforced by the CA and its Root CA. **EV Processes**: The keys, software, processes, and procedures by which the CA verifies Certificate Data under this Guideline, issues EV Certificates, maintains a Repository, and revokes EV Certificates. **Extended Validation Certificate**: See EV Certificate. -**Government Agency**: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of Private Organizations is established (e.g., the government agency that issued the Certificate of Incorporation). In the context of Business Entities, the government agency in the jurisdiction of operation that registers business entities. In the case of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities. +**Government Agency**: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of Private Organizations is established (e.g., the government agency that issued the Certificate of Incorporation). In the context of Business Entities, the government agency in the jurisdiction of operation that registers business entities. In the case of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities. **Guidelines**: This document. -**Incorporating Agency**: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of the entity is registered (e.g., the government agency that issues certificates of formation or incorporation). In the context of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities. +**Incorporating Agency**: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of the entity is registered (e.g., the government agency that issues certificates of formation or incorporation). In the context of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities. **Independent Confirmation From Applicant**: Confirmation of a particular fact received by the CA pursuant to the provisions of the Guidelines or binding upon the Applicant. @@ -233,7 +233,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **International Organization**: An organization founded by a constituent document, e.g., a charter, treaty, convention or similar document, signed by, or on behalf of, a minimum of two Sovereign State governments. -**Jurisdiction of Incorporation**: In the context of a Private Organization, the country and (where applicable) the state or province or locality where the organization's legal existence was established by a filing with (or an act of) an appropriate government agency or entity (e.g., where it was incorporated). In the context of a Government Entity, the country and (where applicable) the state or province where the Entity's legal existence was created by law. +**Jurisdiction of Incorporation**: In the context of a Private Organization, the country and (where applicable) the state or province or locality where the organization's legal existence was established by a filing with (or an act of) an appropriate government agency or entity (e.g., where it was incorporated). In the context of a Government Entity, the country and (where applicable) the state or province where the Entity's legal existence was created by law. **Jurisdiction of Registration**: In the case of a Business Entity, the state, province, or locality where the organization has registered its business presence by means of filings by a Principal Individual involved in the business. @@ -266,7 +266,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Qualified Independent Information Source**: A regularly-updated and current, publicly available, database designed for the purpose of accurately providing the information for which it is consulted, and which is generally recognized as a dependable source of such information. -**Registration Agency**: A Governmental Agency that registers business information in connection with an entity's business formation or authorization to conduct business under a license, charter or other certification. A Registration Agency MAY include, but is not limited to +**Registration Agency**: A Governmental Agency that registers business information in connection with an entity's business formation or authorization to conduct business under a license, charter or other certification. A Registration Agency MAY include, but is not limited to i. a State Department of Corporations or a Secretary of State; ii. a licensing agency, such as a State Department of Insurance; or @@ -353,14 +353,14 @@ By convention, this document omits time and timezones when listing effective req Each CA must develop, implement, enforce, display prominently on its Web site, and periodically update as necessary its own auditable EV Certificate practices, policies and procedures, such as a Certification Practice Statement (CPS) and Certificate Policy (CP) that: -A. Implement the requirements of these Guidelines as they are revised from time-to-time; +A. Implement the requirements of these Guidelines as they are revised from time-to-time; -B. Implement the requirements of +B. Implement the requirements of i. the then-current WebTrust Program for CAs, and ii. the then-current WebTrust EV Program or ETSI TS 102 042 for EVCP or ETSI EN 319 411-1 for EVCP policy; and -C. Specify the CA's and its Root CA's entire root certificate hierarchy including all roots that its EV Certificates depend on for proof of those EV Certificates' authenticity. +C. Specify the CA's and its Root CA's entire root certificate hierarchy including all roots that its EV Certificates depend on for proof of those EV Certificates' authenticity. ## 2.1 Repositories @@ -372,9 +372,9 @@ The CA's Certificate Policy and/or Certification Practice Statement MUST be stru Each CA SHALL publicly give effect to these Guidelines and represent that they will adhere to the latest published version by incorporating them into their respective EV Policies, using a clause such as the following (which must include a link to the official version of these Guidelines): -> [Name of CA] conforms to the current version of the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates published at . In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document. +> [Name of CA] conforms to the current version of the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates published at . In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document. -In addition, the CA MUST include (directly or by reference) the applicable requirements of these Guidelines in all contracts with Subordinate CAs, RAs, Enterprise RAs, and subcontractors that involve or relate to the issuance or maintenance of EV Certificates. The CA MUST enforce compliance with such terms. +In addition, the CA MUST include (directly or by reference) the applicable requirements of these Guidelines in all contracts with Subordinate CAs, RAs, Enterprise RAs, and subcontractors that involve or relate to the issuance or maintenance of EV Certificates. The CA MUST enforce compliance with such terms. ## 2.3 Time or frequency of publication @@ -412,27 +412,25 @@ Before issuing an EV Certificate, the CA MUST ensure that all Subject organizati 1. Verify Applicant's existence and identity, including; - A. Verify the Applicant's legal existence and identity (as more fully set forth in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity)), + A. Verify the Applicant's legal existence and identity (as more fully set forth in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity)), - B. Verify the Applicant's physical existence (business presence at a physical address), and + B. Verify the Applicant's physical existence (business presence at a physical address), and - C. Verify the Applicant's operational existence (business activity). + C. Verify the Applicant's operational existence (business activity). 2. Verify the Applicant is a registered holder, or has control, of the Domain Name(s) to be included in the EV Certificate; - 3. Verify a reliable means of communication with the entity to be named as the Subject in the Certificate; - 4. Verify the Applicant's authorization for the EV Certificate, including; - A. Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester, + A. Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester, - B. Verify that a Contract Signer signed the Subscriber Agreement or that a duly authorized Applicant Representative acknowledged and agreed to the Terms of Use; and + B. Verify that a Contract Signer signed the Subscriber Agreement or that a duly authorized Applicant Representative acknowledged and agreed to the Terms of Use; and - C. Verify that a Certificate Approver has signed or otherwise approved the EV Certificate Request. + C. Verify that a Certificate Approver has signed or otherwise approved the EV Certificate Request. ##### 3.2.2.1.2 Acceptable Methods of Verification – Overview -As a general rule, the CA is responsible for taking all verification steps reasonably necessary to satisfy each of the Verification Requirements set forth in the subsections below. The Acceptable Methods of Verification set forth in each of Sections 3.2.2 through 3.2.14 (which usually include alternatives) are considered to be the minimum acceptable level of verification required of the CA. In all cases, however, the CA is responsible for taking any additional verification steps that may be reasonably necessary under the circumstances to satisfy the applicable Verification Requirement. +As a general rule, the CA is responsible for taking all verification steps reasonably necessary to satisfy each of the Verification Requirements set forth in the subsections below. The Acceptable Methods of Verification set forth in each of Sections 3.2.2 through 3.2.14 (which usually include alternatives) are considered to be the minimum acceptable level of verification required of the CA. In all cases, however, the CA is responsible for taking any additional verification steps that may be reasonably necessary under the circumstances to satisfy the applicable Verification Requirement. ##### 3.2.2.1.3 Disclosure of Verification Sources @@ -440,10 +438,10 @@ Effective as of 1 October 2020, prior to the use of an Incorporating Agency or R This Agency Information SHALL include at least the following: -* Sufficient information to unambiguously identify the Incorporating Agency or Registration Agency (such as a name, jurisdiction, and website); and, -* The accepted value or values for each of the `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1), `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2), and `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) fields, when a certificate is issued using information from that Incorporating Agency or Registration Agency, indicating the jurisdiction(s) that the Agency is appropriate for; and, -* The acceptable form or syntax of Registration Numbers used by the Incorporating Agency or Registration Agency, if the CA restricts such Numbers to an acceptable form or syntax; and, -* A revision history that includes a unique version number and date of publication for any additions, modifications, and/or removals from this list. +- Sufficient information to unambiguously identify the Incorporating Agency or Registration Agency (such as a name, jurisdiction, and website); and, +- The accepted value or values for each of the `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1), `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2), and `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) fields, when a certificate is issued using information from that Incorporating Agency or Registration Agency, indicating the jurisdiction(s) that the Agency is appropriate for; and, +- The acceptable form or syntax of Registration Numbers used by the Incorporating Agency or Registration Agency, if the CA restricts such Numbers to an acceptable form or syntax; and, +- A revision history that includes a unique version number and date of publication for any additions, modifications, and/or removals from this list. The CA MUST document where to obtain this information within Section 3.2 of the CA's Certificate Policy and/or Certification Practice Statement. @@ -455,29 +453,29 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo 1. **Private Organization Subjects** - A. **Legal Existence**: Verify that the Applicant is a legally recognized entity, in existence and validly formed (e.g., incorporated) with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration, and not designated on the records of the Incorporating or Registration Agency by labels such as "inactive", "invalid", "not current", or the equivalent. - B. **Organization Name**: Verify that the Applicant's formal legal name as recorded with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: Obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Incorporation or Registration. - D. **Registered Agent**: Obtain the identity and address of the Applicant's Registered Agent or Registered Office (as applicable in the Applicant's Jurisdiction of Incorporation or Registration). + A. **Legal Existence**: Verify that the Applicant is a legally recognized entity, in existence and validly formed (e.g., incorporated) with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration, and not designated on the records of the Incorporating or Registration Agency by labels such as "inactive", "invalid", "not current", or the equivalent. + B. **Organization Name**: Verify that the Applicant's formal legal name as recorded with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration matches the Applicant's name in the EV Certificate Request. + C. **Registration Number**: Obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Incorporation or Registration. + D. **Registered Agent**: Obtain the identity and address of the Applicant's Registered Agent or Registered Office (as applicable in the Applicant's Jurisdiction of Incorporation or Registration). 2. **Government Entity Subjects** - A. **Legal Existence**: Verify that the Applicant is a legally recognized Government Entity, in existence in the political subdivision in which such Government Entity operates. - B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of incorporation, registration, or formation, or the identifier for the legislative act that created the Government Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is a Government Entity. + A. **Legal Existence**: Verify that the Applicant is a legally recognized Government Entity, in existence in the political subdivision in which such Government Entity operates. + B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. + C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of incorporation, registration, or formation, or the identifier for the legislative act that created the Government Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is a Government Entity. 3. **Business Entity Subjects** - A. **Legal Existence**: Verify that the Applicant is engaged in business under the name submitted by the Applicant in the Application. - B. **Organization Name**: Verify that the Applicant's formal legal name as recognized by the Registration Agency in the Applicant's Jurisdiction of Registration matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: Attempt to obtain the specific unique Registration Number assigned to the Applicant by the Registration Agency in the Applicant's Jurisdiction of Registration. Where the Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Registration. - D. **Principal Individual**: Verify the identity of the identified Principal Individual. + A. **Legal Existence**: Verify that the Applicant is engaged in business under the name submitted by the Applicant in the Application. + B. **Organization Name**: Verify that the Applicant's formal legal name as recognized by the Registration Agency in the Applicant's Jurisdiction of Registration matches the Applicant's name in the EV Certificate Request. + C. **Registration Number**: Attempt to obtain the specific unique Registration Number assigned to the Applicant by the Registration Agency in the Applicant's Jurisdiction of Registration. Where the Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Registration. + D. **Principal Individual**: Verify the identity of the identified Principal Individual. 4. **Non-Commercial Entity Subjects (International Organizations)** - A. **Legal Existence**: Verify that the Applicant is a legally recognized International Organization Entity. - B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of formation, or the identifier for the legislative act that created the International Organization Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is an International Organization Entity. + A. **Legal Existence**: Verify that the Applicant is a legally recognized International Organization Entity. + B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. + C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of formation, or the identifier for the legislative act that created the International Organization Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is an International Organization Entity. ##### 3.2.2.2.2 Acceptable Method of Verification @@ -494,9 +492,9 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo 3. **Business Entity Subjects**: Unless verified under subsection (6), Items listed in [Section 3.2.2.2.1](#32221-verification-requirements) (3) (A) through (C) above, MUST be verified directly with, or obtained directly from, the Registration Agency in the Applicant's Jurisdiction of Registration. Such verification MAY be performed by means of a Qualified Government Information Source, a Qualified Governmental Tax Information Source, or by direct contact with the Registration Agency in person or via mail, e-mail, Web address, or telephone, using an address or phone number obtained directly from the Qualified Government Information Source, Qualified Governmental Tax Information Source or Registration Agency, or from a Qualified Independent Information Source. In addition, the CA MUST validate a Principal Individual associated with the Business Entity pursuant to the requirements in subsection (4), below. -4. **Principal Individual**: A Principal Individual associated with the Business Entity MUST be validated in a face-to-face setting. The CA MAY rely upon a face-to-face validation of the Principal Individual performed by the Registration Agency, provided that the CA has evaluated the validation procedure and concluded that it satisfies the requirements of the Guidelines for face-to-face validation procedures. Where no face-to-face validation was conducted by the Registration Agency, or the Registration Agency's face-to-face validation procedure does not satisfy the requirements of the Guidelines, the CA SHALL perform face-to-face validation. +4. **Principal Individual**: A Principal Individual associated with the Business Entity MUST be validated in a face-to-face setting. The CA MAY rely upon a face-to-face validation of the Principal Individual performed by the Registration Agency, provided that the CA has evaluated the validation procedure and concluded that it satisfies the requirements of the Guidelines for face-to-face validation procedures. Where no face-to-face validation was conducted by the Registration Agency, or the Registration Agency's face-to-face validation procedure does not satisfy the requirements of the Guidelines, the CA SHALL perform face-to-face validation. - A. **Face-To-Face Validation**: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicant's jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator: + A. **Face-To-Face Validation**: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicant's jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator: i. A Personal Statement that includes the following information: @@ -533,21 +531,21 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo The Third-Party Validator performing the face-to-face validation MUST: i. Attest to the signing of the Personal Statement and the identity of the signer; and - ii. Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original. + ii. Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original. B. **Verification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant's jurisdiction), lawyer, or accountant in the jurisdiction of the Individual's residency, and that the Third-Party Validator actually did perform the services and did attest to the signature of the Individual. - C. **Cross-checking of Information**: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that: + C. **Cross-checking of Information**: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that: i. the CA confirms their authenticity (not improperly modified when compared with the underlying original) with the Third-Party Validator; and ii. electronic copies of similar kinds of documents are recognized as legal substitutes for originals under the laws of the CA's jurisdiction. 5. **Non-Commercial Entity Subjects (International Organization)**: Unless verified under subsection (6), all items listed in [Section 3.2.2.2.1](#32221-verification-requirements) (4) MUST be verified either: - A. With reference to the constituent document under which the International Organization was formed; or - B. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or - C. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at . - D. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency. + A. With reference to the constituent document under which the International Organization was formed; or + B. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or + C. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at . + D. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency. 6. The CA may rely on a Verified Professional Letter to establish the Applicant's information listed in (1)-(5) above if: @@ -569,7 +567,7 @@ To verify any assumed name under which the Applicant conducts business: 1. The CA MAY verify the assumed name through use of a Qualified Government Information Source operated by, or on behalf of, an appropriate government agency in the jurisdiction of the Applicant's Place of Business, or by direct contact with such government agency in person or via mail, e-mail, Web address, or telephone; or 2. The CA MAY verify the assumed name through use of a Qualified Independent Information Source provided that the QIIS has verified the assumed name with the appropriate government agency. -3. The CA MAY rely on a Verified Professional Letter that indicates the assumed name under which the Applicant conducts business, the government agency with which the assumed name is registered, and that such filing continues to be valid. +3. The CA MAY rely on a Verified Professional Letter that indicates the assumed name under which the Applicant conducts business, the government agency with which the assumed name is registered, and that such filing continues to be valid. #### 3.2.2.4 Verification of Applicant's Physical Existence @@ -579,13 +577,13 @@ To verify any assumed name under which the Applicant conducts business: 2. **Acceptable Methods of Verification** - A. **Place of Business in the Country of Incorporation or Registration** + A. **Place of Business in the Country of Incorporation or Registration** i. For Applicants whose Place of Business is in the same country as the Applicant's Jurisdiction of Incorporation or Registration and whose Place of Business is NOT the same as that indicated in the relevant Qualified Government Information Source used in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) to verify legal existence: 1. For Applicants listed at the same Place of Business address in the current version of either at least one QGIS (other than that used to verify legal existence), QIIS or QTIS, the CA MUST confirm that the Applicant's address, as listed in the EV Certificate Request, is a valid business address for the Applicant or a Parent/Subsidiary Company by reference to such QGIS, QIIS, or QTIS, and MAY rely on the Applicant's representation that such address is its Place of Business; - 2. For Applicants who are not listed at the same Place of Business address in the current version of either at least one QIIS or QTIS, the CA MUST confirm that the address provided by the Applicant in the EV Certificate Request is the Applicant's or a Parent/Subsidiary Company's business address, by obtaining documentation of a site visit to the business address, which MUST be performed by a reliable individual or firm. The documentation of the site visit MUST: + 2. For Applicants who are not listed at the same Place of Business address in the current version of either at least one QIIS or QTIS, the CA MUST confirm that the address provided by the Applicant in the EV Certificate Request is the Applicant's or a Parent/Subsidiary Company's business address, by obtaining documentation of a site visit to the business address, which MUST be performed by a reliable individual or firm. The documentation of the site visit MUST: a. Verify that the Applicant's business is located at the exact address stated in the EV Certificate Request (e.g., via permanent signage, employee confirmation, etc.), b. Identify the type of facility (e.g., office in a commercial building, private residence, storefront, etc.) and whether it appears to be a permanent business location, @@ -599,7 +597,7 @@ To verify any assumed name under which the Applicant conducts business: iii. For Government Entity Applicants, the CA MAY rely on the address contained in the records of the QGIS in the Applicant's jurisdiction. iv. For Applicants whose Place of Business is in the same country as the Applicant's Jurisdiction of Incorporation or Registration and where the QGIS used in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) to verify legal existence contains a business address for the Applicant, the CA MAY rely on the address in the QGIS to confirm the Applicant's or a Parent/Subsidiary Company's address as listed in the EV Certificate Request, and MAY rely on the Applicant's representation that such address is its Place of Business. - B. **Place of Business not in the Country of Incorporation or Registration**: The CA MUST rely on a Verified Professional Letter that indicates the address of the Applicant's Place of Business and that business operations are conducted there. + B. **Place of Business not in the Country of Incorporation or Registration**: The CA MUST rely on a Verified Professional Letter that indicates the address of the Applicant's Place of Business and that business operations are conducted there. #### 3.2.2.5 Verified Method of Communication @@ -611,19 +609,19 @@ To assist in communicating with the Applicant and confirming that the Applicant To verify a Verified Method of Communication with the Applicant, the CA MUST: -A. Verify that the Verified Method of Communication belongs to the Applicant, or a Parent/Subsidiary or Affiliate of the Applicant, by matching it with one of the Applicant's Parent/Subsidiary or Affiliate's Places of Business in: +A. Verify that the Verified Method of Communication belongs to the Applicant, or a Parent/Subsidiary or Affiliate of the Applicant, by matching it with one of the Applicant's Parent/Subsidiary or Affiliate's Places of Business in: i. records provided by the applicable phone company; ii. a QGIS, QTIS, or QIIS; or iii. a Verified Professional Letter; and -B. Confirm the Verified Method of Communication by using it to obtain an affirmative response sufficient to enable a reasonable person to conclude that the Applicant, or a Parent/Subsidiary or Affiliate of Applicant, can be contacted reliably by using the Verified Method of Communication. +B. Confirm the Verified Method of Communication by using it to obtain an affirmative response sufficient to enable a reasonable person to conclude that the Applicant, or a Parent/Subsidiary or Affiliate of Applicant, can be contacted reliably by using the Verified Method of Communication. #### 3.2.2.6 Verification of Applicant's Operational Existence ##### 3.2.2.6.1 Verification Requirements -The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) as verification of a Government Entity's operational existence. +The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) as verification of a Government Entity's operational existence. ##### 3.2.2.6.2 Acceptable Methods of Verification @@ -643,7 +641,7 @@ To verify the Applicant's ability to engage in business, the CA MUST verify the 1. For each Fully-Qualified Domain Name listed in a Certificate which is not an Onion Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 3.2.2.4 of the Baseline Requirements. For a Certificate issued to an Onion Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the Onion Domain Name in accordance with Appendix B of the Baseline Requirements. -2. **Mixed Character Set Domain Names**: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. +2. **Mixed Character Set Domain Names**: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. #### 3.2.2.8 Verification of Name, Title, and Authority of Contract Signer and Certificate Approver @@ -651,13 +649,13 @@ To verify the Applicant's ability to engage in business, the CA MUST verify the For both the Contract Signer and the Certificate Approver, the CA MUST verify the following. -1. **Name, Title and Agency**: The CA MUST verify the name and title of the Contract Signer and the Certificate Approver, as applicable. The CA MUST also verify that the Contract Signer and the Certificate Approver are agents representing the Applicant. +1. **Name, Title and Agency**: The CA MUST verify the name and title of the Contract Signer and the Certificate Approver, as applicable. The CA MUST also verify that the Contract Signer and the Certificate Approver are agents representing the Applicant. 2. **Signing Authority of Contract Signer**: The CA MUST verify that the Contract Signer is authorized by the Applicant to enter into the Subscriber Agreement (and any other relevant contractual obligations) on behalf of the Applicant, including a contract that designates one or more Certificate Approvers on behalf of the Applicant. 3. **EV Authority of Certificate Approver**: The CA MUST verify, through a source other than the Certificate Approver him- or herself, that the Certificate Approver is expressly authorized by the Applicant to do the following, as of the date of the EV Certificate Request: - A. Submit, and, if applicable, authorize a Certificate Requester to submit, the EV Certificate Request on behalf of the Applicant; and - B. Provide, and, if applicable, authorize a Certificate Requester to provide, the information requested from the Applicant by the CA for issuance of the EV Certificate; and - C. Approve EV Certificate Requests submitted by a Certificate Requester. + A. Submit, and, if applicable, authorize a Certificate Requester to submit, the EV Certificate Request on behalf of the Applicant; and + B. Provide, and, if applicable, authorize a Certificate Requester to provide, the information requested from the Applicant by the CA for issuance of the EV Certificate; and + C. Approve EV Certificate Requests submitted by a Certificate Requester. ##### 3.2.2.8.2 Acceptable Methods of Verification – Name, Title and Agency @@ -667,9 +665,9 @@ Acceptable methods of verification of the name, title, and agency status of the 2. **Agency**: The CA MAY verify the agency of the Contract Signer and the Certificate Approver by: - A. Contacting the Applicant using a Verified Method of Communication for the Applicant, and obtaining confirmation that the Contract Signer and/or the Certificate Approver, as applicable, is an employee; - B. Obtaining an Independent Confirmation From the Applicant (as described in [Section 3.2.2.11.4](#322114-independent-confirmation-from-applicant)), or a Verified Professional Letter verifying that the Contract Signer and/or the Certificate Approver, as applicable, is either an employee or has otherwise been appointed as an agent of the Applicant; or - C. Obtaining confirmation from a QIIS or QGIS that the Contract Signer and/or Certificate Approver is an employee of the Applicant. + A. Contacting the Applicant using a Verified Method of Communication for the Applicant, and obtaining confirmation that the Contract Signer and/or the Certificate Approver, as applicable, is an employee; + B. Obtaining an Independent Confirmation From the Applicant (as described in [Section 3.2.2.11.4](#322114-independent-confirmation-from-applicant)), or a Verified Professional Letter verifying that the Contract Signer and/or the Certificate Approver, as applicable, is either an employee or has otherwise been appointed as an agent of the Applicant; or + C. Obtaining confirmation from a QIIS or QGIS that the Contract Signer and/or Certificate Approver is an employee of the Applicant. The CA MAY also verify the agency of the Certificate Approver via a certification from the Contract Signer (including in a contract between the CA and the Applicant signed by the Contract Signer), provided that the employment or agency status and Signing Authority of the Contract Signer has been verified. @@ -687,27 +685,27 @@ Acceptable methods of verification of the Signing Authority of the Contract Sign 4. **Contract between CA and Applicant**: The EV Authority of the Certificate Approver MAY be verified by reliance on a contract between the CA and the Applicant that designates the Certificate Approver with such EV Authority, provided that the contract is signed by the Contract Signer and provided that the agency and Signing Authority of the Contract Signer have been verified; 5. **Prior Equivalent Authority**: The signing authority of the Contract Signer, and/or the EV authority of the Certificate Approver, MAY be verified by relying on a demonstration of Prior Equivalent Authority. - A. Prior Equivalent Authority of a Contract Signer MAY be relied upon for confirmation or verification of the signing authority of the Contract Signer when the Contract Signer has executed a binding contract between the CA and the Applicant with a legally valid and enforceable seal or handwritten signature and only when the contract was executed more than 90 days prior to the EV Certificate application. The CA MUST record sufficient details of the previous agreement to correctly identify it and associate it with the EV application. Such details MAY include any of the following: + A. Prior Equivalent Authority of a Contract Signer MAY be relied upon for confirmation or verification of the signing authority of the Contract Signer when the Contract Signer has executed a binding contract between the CA and the Applicant with a legally valid and enforceable seal or handwritten signature and only when the contract was executed more than 90 days prior to the EV Certificate application. The CA MUST record sufficient details of the previous agreement to correctly identify it and associate it with the EV application. Such details MAY include any of the following: i. Agreement title, ii. Date of Contract Signer's signature, iii. Contract reference number, and iv. Filing location. - B. Prior Equivalent Authority of a Certificate Approver MAY be relied upon for confirmation or verification of the EV Authority of the Certificate Approver when the Certificate Approver has performed one or more of the following: + B. Prior Equivalent Authority of a Certificate Approver MAY be relied upon for confirmation or verification of the EV Authority of the Certificate Approver when the Certificate Approver has performed one or more of the following: i. Under contract to the CA, has served (or is serving) as an Enterprise RA for the Applicant, or - ii. Has participated in the approval of one or more certificate requests, for certificates issued by the CA and which are currently and verifiably in use by the Applicant. In this case the CA MUST have contacted the Certificate Approver by phone at a previously validated phone number or have accepted a signed and notarized letter approving the certificate request. + ii. Has participated in the approval of one or more certificate requests, for certificates issued by the CA and which are currently and verifiably in use by the Applicant. In this case the CA MUST have contacted the Certificate Approver by phone at a previously validated phone number or have accepted a signed and notarized letter approving the certificate request. 6. **QIIS or QGIS**: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by a QIIS or QGIS that identifies the Contract Signer and/or the Certificate Approver as a corporate officer, sole proprietor, or other senior official of the Applicant. 7. **Contract Signer's Representation/Warranty**: Provided that the CA verifies that the Contract Signer is an employee or agent of the Applicant, the CA MAY rely on the signing authority of the Contract Signer by obtaining a duly executed representation or warranty from the Contract Signer that includes the following acknowledgments: - A. That the Applicant authorizes the Contract Signer to sign the Subscriber Agreement on the Applicant's behalf, - B. That the Subscriber Agreement is a legally valid and enforceable agreement, - C. That, upon execution of the Subscriber Agreement, the Applicant will be bound by all of its terms and conditions, - D. That serious consequences attach to the misuse of an EV certificate, and - E. The contract signer has the authority to obtain the digital equivalent of a corporate seal, stamp or officer's signature to establish the authenticity of the company's Web site. + A. That the Applicant authorizes the Contract Signer to sign the Subscriber Agreement on the Applicant's behalf, + B. That the Subscriber Agreement is a legally valid and enforceable agreement, + C. That, upon execution of the Subscriber Agreement, the Applicant will be bound by all of its terms and conditions, + D. That serious consequences attach to the misuse of an EV certificate, and + E. The contract signer has the authority to obtain the digital equivalent of a corporate seal, stamp or officer's signature to establish the authenticity of the company's Web site. Note: An example of an acceptable representation/warranty appears in [Appendix E](#appendix-e---sample-contract-signers-representationwarranty-informative). @@ -730,7 +728,7 @@ Such an agreement MUST provide that the Applicant shall be obligated under the S #### 3.2.2.9 Verification of Signature on Subscriber Agreement and EV Certificate Requests -Both the Subscriber Agreement and each non-pre-authorized EV Certificate Request MUST be signed. The Subscriber Agreement MUST be signed by an authorized Contract Signer. The EV Certificate Request MUST be signed by the Certificate Requester submitting the document, unless the Certificate Request has been pre-authorized in line with [Section 3.2.2.8.4](#32284-pre-authorized-certificate-approver). If the Certificate Requester is not also an authorized Certificate Approver, then an authorized Certificate Approver MUST independently approve the EV Certificate Request. In all cases, applicable signatures MUST be a legally valid and contain an enforceable seal or handwritten signature (for a paper Subscriber Agreement and/or EV Certificate Request), or a legally valid and enforceable electronic signature (for an electronic Subscriber Agreement and/or EV Certificate Request), that binds the Applicant to the terms of each respective document. +Both the Subscriber Agreement and each non-pre-authorized EV Certificate Request MUST be signed. The Subscriber Agreement MUST be signed by an authorized Contract Signer. The EV Certificate Request MUST be signed by the Certificate Requester submitting the document, unless the Certificate Request has been pre-authorized in line with [Section 3.2.2.8.4](#32284-pre-authorized-certificate-approver). If the Certificate Requester is not also an authorized Certificate Approver, then an authorized Certificate Approver MUST independently approve the EV Certificate Request. In all cases, applicable signatures MUST be a legally valid and contain an enforceable seal or handwritten signature (for a paper Subscriber Agreement and/or EV Certificate Request), or a legally valid and enforceable electronic signature (for an electronic Subscriber Agreement and/or EV Certificate Request), that binds the Applicant to the terms of each respective document. ##### 3.2.2.9.1 Verification Requirements @@ -770,19 +768,19 @@ Acceptable methods of verifying the Certificate Approver's approval of an EV Cer 1. **Verification Requirements**: Before relying on a legal opinion submitted to the CA, the CA MUST verify that such legal opinion meets the following requirements: - A. **Status of Author**: The CA MUST verify that the legal opinion is authored by an independent legal practitioner retained by and representing the Applicant (or an in-house legal practitioner employed by the Applicant) (Legal Practitioner) who is either: + A. **Status of Author**: The CA MUST verify that the legal opinion is authored by an independent legal practitioner retained by and representing the Applicant (or an in-house legal practitioner employed by the Applicant) (Legal Practitioner) who is either: i. A lawyer (or solicitor, barrister, advocate, or equivalent) licensed to practice law in the country of the Applicant's Jurisdiction of Incorporation or Registration or any jurisdiction where the Applicant maintains an office or physical facility, or ii. A Latin Notary who is currently commissioned or licensed to practice in the country of the Applicant's Jurisdiction of Incorporation or Registration or any jurisdiction where the Applicant maintains an office or physical facility (and that such jurisdiction recognizes the role of the Latin Notary); - B. **Basis of Opinion**: The CA MUST verify that the Legal Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Legal Opinion are based on the Legal Practitioner's stated familiarity with the relevant facts and the exercise of the Legal Practitioner's professional judgment and expertise; - C. **Authenticity**: The CA MUST confirm the authenticity of the Verified Legal Opinion. + B. **Basis of Opinion**: The CA MUST verify that the Legal Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Legal Opinion are based on the Legal Practitioner's stated familiarity with the relevant facts and the exercise of the Legal Practitioner's professional judgment and expertise; + C. **Authenticity**: The CA MUST confirm the authenticity of the Verified Legal Opinion. 2. **Acceptable Methods of Verification**: Acceptable methods of establishing the foregoing requirements for a Verified Legal Opinion are: - A. **Status of Author**: The CA MUST verify the professional status of the author of the legal opinion by directly contacting the authority responsible for registering or licensing such Legal Practitioner(s) in the applicable jurisdiction; - B. **Basis of Opinion**: The text of the legal opinion MUST make it clear that the Legal Practitioner is acting on behalf of the Applicant and that the conclusions of the legal opinion are based on the Legal Practitioner's stated familiarity with the relevant facts and the exercise of the practitioner's professional judgment and expertise. The legal opinion MAY also include disclaimers and other limitations customary in the Legal Practitioner's jurisdiction, provided that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Legal Practitioner, should the legal opinion prove to be erroneous. An acceptable form of legal opinion is attached as [Appendix B](#appendix-b---sample-attorney-opinions-confirming-specified-information); - C. **Authenticity**: To confirm the authenticity of the legal opinion, the CA MUST make a telephone call or send a copy of the legal opinion back to the Legal Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Legal Practitioner listed with the authority responsible for registering or licensing such Legal Practitioner, and obtain confirmation from the Legal Practitioner or the Legal Practitioner's assistant that the legal opinion is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Legal Practitioner in records provided by the applicable phone company, QGIS, or QIIS. + A. **Status of Author**: The CA MUST verify the professional status of the author of the legal opinion by directly contacting the authority responsible for registering or licensing such Legal Practitioner(s) in the applicable jurisdiction; + B. **Basis of Opinion**: The text of the legal opinion MUST make it clear that the Legal Practitioner is acting on behalf of the Applicant and that the conclusions of the legal opinion are based on the Legal Practitioner's stated familiarity with the relevant facts and the exercise of the practitioner's professional judgment and expertise. The legal opinion MAY also include disclaimers and other limitations customary in the Legal Practitioner's jurisdiction, provided that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Legal Practitioner, should the legal opinion prove to be erroneous. An acceptable form of legal opinion is attached as [Appendix B](#appendix-b---sample-attorney-opinions-confirming-specified-information); + C. **Authenticity**: To confirm the authenticity of the legal opinion, the CA MUST make a telephone call or send a copy of the legal opinion back to the Legal Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Legal Practitioner listed with the authority responsible for registering or licensing such Legal Practitioner, and obtain confirmation from the Legal Practitioner or the Legal Practitioner's assistant that the legal opinion is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Legal Practitioner in records provided by the applicable phone company, QGIS, or QIIS. In circumstances where the opinion is digitally signed, in a manner that confirms the authenticity of the document and the identity of the signer, as verified by the CA in [Section 3.2.2.11.1](#322111-verified-legal-opinion) (2)(A), no further verification of authenticity is required. @@ -790,15 +788,15 @@ Acceptable methods of verifying the Certificate Approver's approval of an EV Cer 1. **Verification Requirements**: Before relying on an accountant letter submitted to the CA, the CA MUST verify that such accountant letter meets the following requirements: - A. **Status of Author**: The CA MUST verify that the accountant letter is authored by an Accounting Practitioner retained or employed by the Applicant and licensed within the country of the Applicant's Jurisdiction of Incorporation, Jurisdiction of Registration, or country where the Applicant maintains an office or physical facility. Verification of license MUST be through the member organization or regulatory organization in the Accounting Practitioner's country or jurisdiction that is appropriate to contact when verifying an accountant's license to practice in that country or jurisdiction. Such country or jurisdiction must have an accounting standards body that maintains full membership status with the International Federation of Accountants. - B. **Basis of Opinion**: The CA MUST verify that the Accounting Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Accountant Letter are based on the Accounting Practitioner's stated familiarity with the relevant facts and the exercise of the Accounting Practitioner's professional judgment and expertise; - C. **Authenticity**: The CA MUST confirm the authenticity of the Verified Accountant Letter. + A. **Status of Author**: The CA MUST verify that the accountant letter is authored by an Accounting Practitioner retained or employed by the Applicant and licensed within the country of the Applicant's Jurisdiction of Incorporation, Jurisdiction of Registration, or country where the Applicant maintains an office or physical facility. Verification of license MUST be through the member organization or regulatory organization in the Accounting Practitioner's country or jurisdiction that is appropriate to contact when verifying an accountant's license to practice in that country or jurisdiction. Such country or jurisdiction must have an accounting standards body that maintains full membership status with the International Federation of Accountants. + B. **Basis of Opinion**: The CA MUST verify that the Accounting Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Accountant Letter are based on the Accounting Practitioner's stated familiarity with the relevant facts and the exercise of the Accounting Practitioner's professional judgment and expertise; + C. **Authenticity**: The CA MUST confirm the authenticity of the Verified Accountant Letter. 2. **Acceptable Methods of Verification**: Acceptable methods of establishing the foregoing requirements for a Verified Accountant Letter are listed here. - A. **Status of Author**: The CA MUST verify the professional status of the author of the accountant letter by directly contacting the authority responsible for registering or licensing such Accounting Practitioners in the applicable jurisdiction. - B. **Basis of Opinion**: The text of the Verified Accountant Letter MUST make clear that the Accounting Practitioner is acting on behalf of the Applicant and that the information in the letter is based on the Accounting Practitioner's stated familiarity with the relevant facts and the exercise of the practitioner's professional judgment and expertise. The Verified Accountant Letter MAY also include disclaimers and other limitations customary in the Accounting Practitioner's jurisdiction, provided that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Accounting Practitioner, should the Verified Accountant Letter prove to be erroneous. Acceptable forms of Verified Accountant Letter are attached as [Appendix C](#appendix-c---sample-accountant-letters-confirming-specified-information). - C. **Authenticity**: To confirm the authenticity of the accountant's opinion, the CA MUST make a telephone call or send a copy of the Verified Accountant Letter back to the Accounting Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Accounting Practitioner listed with the authority responsible for registering or licensing such Accounting Practitioners and obtain confirmation from the Accounting Practitioner or the Accounting Practitioner's assistant that the accountant letter is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Accountant in records provided by the applicable phone company, QGIS, or QIIS. + A. **Status of Author**: The CA MUST verify the professional status of the author of the accountant letter by directly contacting the authority responsible for registering or licensing such Accounting Practitioners in the applicable jurisdiction. + B. **Basis of Opinion**: The text of the Verified Accountant Letter MUST make clear that the Accounting Practitioner is acting on behalf of the Applicant and that the information in the letter is based on the Accounting Practitioner's stated familiarity with the relevant facts and the exercise of the practitioner's professional judgment and expertise. The Verified Accountant Letter MAY also include disclaimers and other limitations customary in the Accounting Practitioner's jurisdiction, provided that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Accounting Practitioner, should the Verified Accountant Letter prove to be erroneous. Acceptable forms of Verified Accountant Letter are attached as [Appendix C](#appendix-c---sample-accountant-letters-confirming-specified-information). + C. **Authenticity**: To confirm the authenticity of the accountant's opinion, the CA MUST make a telephone call or send a copy of the Verified Accountant Letter back to the Accounting Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Accounting Practitioner listed with the authority responsible for registering or licensing such Accounting Practitioners and obtain confirmation from the Accounting Practitioner or the Accounting Practitioner's assistant that the accountant letter is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Accountant in records provided by the applicable phone company, QGIS, or QIIS. In circumstances where the opinion is digitally signed, in a manner that confirms the authenticity of the document and the identity of the signer, as verified by the CA in [Section 3.2.2.11.2](#322112-verified-accountant-letter) (2)(A), no further verification of authenticity is required. @@ -806,35 +804,35 @@ Acceptable methods of verifying the Certificate Approver's approval of an EV Cer 1. **Verification Requirements**: Before relying on face-to-face vetting documents submitted to the CA, the CA MUST verify that the Third-Party Validator meets the following requirements: - A. **Qualification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant's jurisdiction), Lawyer, or Accountant in the jurisdiction of the individual's residency; - B. **Document Chain of Custody**: The CA MUST verify that the Third-Party Validator viewed the Vetting Documents in a face-to-face meeting with the individual being validated; - C. **Verification of Attestation**: If the Third-Party Validator is not a Latin Notary, then the CA MUST confirm the authenticity of the attestation and vetting documents. + A. **Qualification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant's jurisdiction), Lawyer, or Accountant in the jurisdiction of the individual's residency; + B. **Document Chain of Custody**: The CA MUST verify that the Third-Party Validator viewed the Vetting Documents in a face-to-face meeting with the individual being validated; + C. **Verification of Attestation**: If the Third-Party Validator is not a Latin Notary, then the CA MUST confirm the authenticity of the attestation and vetting documents. 2. **Acceptable Methods of Verification**: Acceptable methods of establishing the foregoing requirements for vetting documents are: - A. **Qualification of Third-Party Validator**: The CA MUST verify the professional status of the Third-Party Validator by directly contacting the authority responsible for registering or licensing such Third-Party Validators in the applicable jurisdiction; - B. **Document Chain of Custody**: The Third-Party Validator MUST submit a statement to the CA which attests that they obtained the Vetting Documents submitted to the CA for the individual during a face-to-face meeting with the individual; - C. **Verification of Attestation**: If the Third-Party Validator is not a Latin Notary, then the CA MUST confirm the authenticity of the vetting documents received from the Third-Party Validator. The CA MUST make a telephone call to the Third-Party Validator and obtain confirmation from them or their assistant that they performed the face-to-face validation. The CA MAY rely upon self-reported information obtained from the Third-Party Validator for the sole purpose of performing this verification process. In circumstances where the attestation is digitally signed, in a manner that confirms the authenticity of the documents, and the identity of the signer as verified by the CA in [Section 3.2.2.11.3](#322113-face-to-face-validation) (1)(A), no further verification of authenticity is required. + A. **Qualification of Third-Party Validator**: The CA MUST verify the professional status of the Third-Party Validator by directly contacting the authority responsible for registering or licensing such Third-Party Validators in the applicable jurisdiction; + B. **Document Chain of Custody**: The Third-Party Validator MUST submit a statement to the CA which attests that they obtained the Vetting Documents submitted to the CA for the individual during a face-to-face meeting with the individual; + C. **Verification of Attestation**: If the Third-Party Validator is not a Latin Notary, then the CA MUST confirm the authenticity of the vetting documents received from the Third-Party Validator. The CA MUST make a telephone call to the Third-Party Validator and obtain confirmation from them or their assistant that they performed the face-to-face validation. The CA MAY rely upon self-reported information obtained from the Third-Party Validator for the sole purpose of performing this verification process. In circumstances where the attestation is digitally signed, in a manner that confirms the authenticity of the documents, and the identity of the signer as verified by the CA in [Section 3.2.2.11.3](#322113-face-to-face-validation) (1)(A), no further verification of authenticity is required. ##### 3.2.2.11.4 Independent Confirmation From Applicant An Independent Confirmation from the Applicant is a confirmation of a particular fact (e.g., confirmation of the employee or agency status of a Contract Signer or Certificate Approver, confirmation of the EV Authority of a Certificate Approver, etc.) that is: -A. Received by the CA from a Confirming Person (someone other than the person who is the subject of the inquiry) that has the appropriate authority to confirm such a fact, and who represents that he/she has confirmed such fact; -B. Received by the CA in a manner that authenticates and verifies the source of the confirmation; and -C. Binding on the Applicant. +A. Received by the CA from a Confirming Person (someone other than the person who is the subject of the inquiry) that has the appropriate authority to confirm such a fact, and who represents that he/she has confirmed such fact; +B. Received by the CA in a manner that authenticates and verifies the source of the confirmation; and +C. Binding on the Applicant. An Independent Confirmation from the Applicant MAY be obtained via the following procedure: 1. **Confirmation Request**: The CA MUST initiate a Confirmation Request via an appropriate out-of-band communication, requesting verification or confirmation of the particular fact at issue as follows: - A. **Addressee**: The Confirmation Request MUST be directed to: + A. **Addressee**: The Confirmation Request MUST be directed to: i. A position within the Applicant's organization that qualifies as a Confirming Person (e.g., Secretary, President, CEO, CFO, COO, CIO, CSO, Director, etc.) and is identified by name and title in a current QGIS, QIIS, QTIS, Verified Legal Opinion, Verified Accountant Letter, or by contacting the Applicant using a Verified Method of Communication; or ii. The Applicant's Registered Agent or Registered Office in the Jurisdiction of Incorporation as listed in the official records of the Incorporating Agency, with instructions that it be forwarded to an appropriate Confirming Person; or iii. A named individual verified to be in the direct line of management above the Contract Signer or Certificate Approver by contacting the Applicant's Human Resources Department by phone or mail (at the phone number or address for the Applicant's Place of Business, verified in accordance with these Guidelines). - B. **Means of Communication**: The Confirmation Request MUST be directed to the Confirming Person in a manner reasonably likely to reach such person. The following options are acceptable: + B. **Means of Communication**: The Confirmation Request MUST be directed to the Confirming Person in a manner reasonably likely to reach such person. The following options are acceptable: i. By paper mail addressed to the Confirming Person at: @@ -844,18 +842,18 @@ An Independent Confirmation from the Applicant MAY be obtained via the following ii. By e-mail addressed to the Confirming Person at the business e-mail address for such person listed in a current QGIS, QTIS, QIIS, Verified Legal Opinion, or Verified Accountant Letter; or iii. By telephone call to the Confirming Person, where such person is contacted by calling the main phone number of the Applicant's Place of Business (verified in accordance with these Guidelines) and asking to speak to such person, and a person taking the call identifies him- or herself as such person; or - iv. By facsimile to the Confirming Person at the Place of Business. The facsimile number must be listed in a current QGIS, QTIS, QIIS, Verified Legal Opinion, or Verified Accountant Letter. The cover page must be clearly addressed to the Confirming Person. + iv. By facsimile to the Confirming Person at the Place of Business. The facsimile number must be listed in a current QGIS, QTIS, QIIS, Verified Legal Opinion, or Verified Accountant Letter. The cover page must be clearly addressed to the Confirming Person. -2. **Confirmation Response**: The CA MUST receive a response to the Confirmation Request from a Confirming Person that confirms the particular fact at issue. Such response MAY be provided to the CA by telephone, by e-mail, or by paper mail, so long as the CA can reliably verify that it was provided by a Confirming Person in response to the Confirmation Request. +2. **Confirmation Response**: The CA MUST receive a response to the Confirmation Request from a Confirming Person that confirms the particular fact at issue. Such response MAY be provided to the CA by telephone, by e-mail, or by paper mail, so long as the CA can reliably verify that it was provided by a Confirming Person in response to the Confirmation Request. -3. The CA MAY rely on a verified Confirming Person to confirm their own contact information: email address, telephone number, and facsimile number. The CA MAY rely on this verified contact information for future correspondence with the Confirming Person if: +3. The CA MAY rely on a verified Confirming Person to confirm their own contact information: email address, telephone number, and facsimile number. The CA MAY rely on this verified contact information for future correspondence with the Confirming Person if: - A. The domain of the e-mail address is owned by the Applicant and is the Confirming Person's own e-mail address and not a group e-mail alias; - B. The Confirming Person's telephone/fax number is verified by the CA to be a telephone number that is part of the organization's telephone system, and is not the personal phone number for the person. + A. The domain of the e-mail address is owned by the Applicant and is the Confirming Person's own e-mail address and not a group e-mail alias; + B. The Confirming Person's telephone/fax number is verified by the CA to be a telephone number that is part of the organization's telephone system, and is not the personal phone number for the person. ##### 3.2.2.11.5 Qualified Independent Information Source -A Qualified Independent Information Source (QIIS) is a regularly-updated and publicly available database that is generally recognized as a dependable source for certain information. A database qualifies as a QIIS if the CA determines that: +A Qualified Independent Information Source (QIIS) is a regularly-updated and publicly available database that is generally recognized as a dependable source for certain information. A database qualifies as a QIIS if the CA determines that: 1. Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and @@ -886,21 +884,21 @@ The High Risk Certificate requirements of Section 4.2.1 of the Baseline Requirem 1. **Verification Requirements**: The CA MUST verify whether the Applicant, the Contract Signer, the Certificate Approver, the Applicant's Jurisdiction of Incorporation, Registration, or Place of Business: - A. Is identified on any government denied list, list of prohibited persons, or other list that prohibits doing business with such organization or person under the laws of the country of the CA's jurisdiction(s) of operation; or - B. Has its Jurisdiction of Incorporation, Registration, or Place of Business in any country with which the laws of the CA's jurisdiction prohibit doing business. + A. Is identified on any government denied list, list of prohibited persons, or other list that prohibits doing business with such organization or person under the laws of the country of the CA's jurisdiction(s) of operation; or + B. Has its Jurisdiction of Incorporation, Registration, or Place of Business in any country with which the laws of the CA's jurisdiction prohibit doing business. The CA MUST NOT issue any EV Certificate to the Applicant if either the Applicant, the Contract Signer, or Certificate Approver or if the Applicant's Jurisdiction of Incorporation or Registration or Place of Business is on any such list. -2. **Acceptable Methods of Verification** The CA MUST take reasonable steps to verify with the following lists and regulations: +2. **Acceptable Methods of Verification** The CA MUST take reasonable steps to verify with the following lists and regulations: - 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: + 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](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. + 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. ##### 3.2.2.12.3 Parent/Subsidiary/Affiliate Relationship @@ -917,14 +915,14 @@ A CA verifying an Applicant using information of the Applicant's Parent, Subsidi #### 3.2.2.13 Final Cross-Correlation and Due Diligence -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. +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. -4. In the case where some or all of the documentation used to support the application is in a language other than the CA's normal operating language, the CA or its Affiliate MUST perform the requirements of this Final Cross-Correlation and Due Diligence section using employees under its control and having appropriate training, experience, and judgment in confirming organizational identification and authorization and fulfilling all qualification requirements contained in [Section 5.3.2](#532-background-check-procedures). When employees under the control of the CA do not possess the language skills necessary to perform the Final Cross-Correlation and Due Diligence a CA MAY: +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. +4. In the case where some or all of the documentation used to support the application is in a language other than the CA's normal operating language, the CA or its Affiliate MUST perform the requirements of this Final Cross-Correlation and Due Diligence section using employees under its control and having appropriate training, experience, and judgment in confirming organizational identification and authorization and fulfilling all qualification requirements contained in [Section 5.3.2](#532-background-check-procedures). When employees under the control of the CA do not possess the language skills necessary to perform the Final Cross-Correlation and Due Diligence a CA MAY: - A. Rely on language translations of the relevant portions of the documentation, provided that the translations are received from a Translator; or - 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 3.2.2.13](#32213-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 8.1.1](#811-self-audits) and [Section 8.2](#82-identityqualifications-of-assessor). + A. Rely on language translations of the relevant portions of the documentation, provided that the translations are received from a Translator; or + 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 3.2.2.13](#32213-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 8.1.1](#811-self-audits) and [Section 8.2](#82-identityqualifications-of-assessor). In the case of EV Certificates to be issued in compliance with the requirements of [Section 1.3.2](#132-registration-authorities), the Enterprise RA MAY perform the requirements of this Final Cross-Correlation and Due Diligence section. @@ -947,20 +945,20 @@ If an Applicant has a currently valid EV Certificate issued by the CA, a CA MAY A CA may rely on a previously verified certificate request to issue a replacement certificate, so long as the certificate being referenced was not revoked due to fraud or other illegal conduct, if: -1. The expiration date of the replacement certificate is the same as the expiration date of the EV Certificate that is being replaced, and +1. The expiration date of the replacement certificate is the same as the expiration date of the EV Certificate that is being replaced, and 2. The Subject Information of the Certificate is the same as the Subject in the EV Certificate that is being replaced. ##### 3.2.2.14.3 Age of Validated Data 1. Except for reissuance of an EV Certificate under [Section 3.2.2.14.2](#322142-re-issuance-requests) and except when permitted otherwise in [Section 3.2.2.14.1](#322141-validation-for-existing-subscribers), the age of all data used to support issuance of an EV Certificate (before revalidation is required) SHALL NOT exceed the following limits: - A. Legal existence and identity – 398 days; - B. Assumed name – 398 days; - C. Address of Place of Business – 398 days; - D. Verified Method of Communication – 398 days; - E. Operational existence – 398 days; - F. Domain Name – 398 days; - G. Name, Title, Agency, and Authority – 398 days, unless a contract between the CA and the Applicant specifies a different term, in which case, the term specified in such contract controls. For example, the contract MAY include the perpetual assignment of EV roles until revoked by the Applicant or CA, or until the contract expires or is terminated. + A. Legal existence and identity – 398 days; + B. Assumed name – 398 days; + C. Address of Place of Business – 398 days; + D. Verified Method of Communication – 398 days; + E. Operational existence – 398 days; + F. Domain Name – 398 days; + G. Name, Title, Agency, and Authority – 398 days, unless a contract between the CA and the Applicant specifies a different term, in which case, the term specified in such contract controls. For example, the contract MAY include the perpetual assignment of EV roles until revoked by the Applicant or CA, or until the contract expires or is terminated. 2. The 398-day period set forth above SHALL begin to run on the date the information was collected by the CA. 3. The CA MAY reuse a previously submitted EV Certificate Request, Subscriber Agreement, or Terms of Use, including use of a single EV Certificate Request in support of multiple EV Certificates containing the same Subject to the extent permitted under [Section 3.2.2.9](#3229-verification-of-signature-on-subscriber-agreement-and-ev-certificate-requests) and [Section 3.2.2.10](#32210-verification-of-approval-of-ev-certificate-request). @@ -1038,7 +1036,7 @@ An Applicant qualifies as a Business Entity if: An Applicant qualifies as a Non-Commercial Entity if: -1. The Applicant is an International Organization Entity, created under a charter, treaty, convention or equivalent instrument that was signed by, or on behalf of, more than one country's government. The CA/Browser Forum may publish a listing of Applicants who qualify as an International Organization for EV eligibility; and +1. The Applicant is an International Organization Entity, created under a charter, treaty, convention or equivalent instrument that was signed by, or on behalf of, more than one country's government. The CA/Browser Forum may publish a listing of Applicants who qualify as an International Organization for EV eligibility; and 2. The Applicant is not headquartered in any country where the CA is prohibited from doing business or issuing a certificate by the laws of the CA's jurisdiction; and @@ -1057,16 +1055,16 @@ The Certificate Request requirements in Section 4.1.2 of the Baseline Requiremen The following Applicant roles are required for the issuance of an EV Certificate. -1. **Certificate Requester**: The EV Certificate Request MUST be submitted by an authorized Certificate Requester. A Certificate Requester is a natural person who is either the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or a third party (such as an ISP or hosting company) that completes and submits an EV Certificate Request on behalf of the Applicant. +1. **Certificate Requester**: The EV Certificate Request MUST be submitted by an authorized Certificate Requester. A Certificate Requester is a natural person who is either the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or a third party (such as an ISP or hosting company) that completes and submits an EV Certificate Request on behalf of the Applicant. -2. **Certificate Approver**: The EV Certificate Request MUST be approved by an authorized Certificate Approver. A Certificate Approver is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant to +2. **Certificate Approver**: The EV Certificate Request MUST be approved by an authorized Certificate Approver. A Certificate Approver is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant to i. act as a Certificate Requester and to authorize other employees or third parties to act as a Certificate Requester, and ii. to approve EV Certificate Requests submitted by other Certificate Requesters. -3. **Contract Signer**: A Subscriber Agreement applicable to the requested EV Certificate MUST be signed by an authorized Contract Signer. A Contract Signer is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements. +3. **Contract Signer**: A Subscriber Agreement applicable to the requested EV Certificate MUST be signed by an authorized Contract Signer. A Contract Signer is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements. -4. **Applicant Representative**: In the case where the CA and the Subscriber are affiliated, Terms of Use applicable to the requested EV Certificate MUST be acknowledged and agreed to by an authorized Applicant Representative. An Applicant Representative is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to acknowledge and agree to the Terms of Use. +4. **Applicant Representative**: In the case where the CA and the Subscriber are affiliated, Terms of Use applicable to the requested EV Certificate MUST be acknowledged and agreed to by an authorized Applicant Representative. An Applicant Representative is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to acknowledge and agree to the Terms of Use. The Applicant MAY authorize one individual to occupy two or more of these roles. The Applicant MAY authorize more than one individual to occupy any of these roles. @@ -1228,7 +1226,7 @@ As specified in Section 5 of the Baseline Requirements. In addition, systems use ### 5.2.4 Roles requiring separation of duties -1. The CA MUST enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the issuance of an EV Certificate. The Final Cross-Correlation and Due Diligence steps, as outlined in [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence), MAY be performed by one of the persons. For example, one Validation Specialist MAY review and verify all the Applicant information and a second Validation Specialist MAY approve issuance of the EV Certificate. +1. The CA MUST enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the issuance of an EV Certificate. The Final Cross-Correlation and Due Diligence steps, as outlined in [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence), MAY be performed by one of the persons. For example, one Validation Specialist MAY review and verify all the Applicant information and a second Validation Specialist MAY approve issuance of the EV Certificate. 2. Such controls MUST be auditable. ## 5.3 Personnel controls @@ -1241,17 +1239,17 @@ Prior to the commencement of employment of any person by the CA for engagement i 1. **Verify the Identity of Such Person**: Verification of identity MUST be performed through: - A. The personal (physical) presence of such person before trusted persons who perform human resource or security functions, and - B. The verification of well-recognized forms of government-issued photo identification (e.g., passports and/or drivers licenses); + A. The personal (physical) presence of such person before trusted persons who perform human resource or security functions, and + B. The verification of well-recognized forms of government-issued photo identification (e.g., passports and/or drivers licenses); and 2. **Verify the Trustworthiness of Such Person**: Verification of trustworthiness SHALL include background checks, which address at least the following, or their equivalent: - A. Confirmation of previous employment, - B. Check of professional references; - C. Confirmation of the highest or most-relevant educational qualification obtained; - D. Search of criminal records (local, state or provincial, and national) where allowed by the jurisdiction in which the person will be employed; + A. Confirmation of previous employment, + B. Check of professional references; + C. Confirmation of the highest or most-relevant educational qualification obtained; + D. Search of criminal records (local, state or provincial, and national) where allowed by the jurisdiction in which the person will be employed; and @@ -1259,7 +1257,7 @@ Prior to the commencement of employment of any person by the CA for engagement i ### 5.3.3 Training requirements -The requirements in Section 5.3.3 of the Baseline Requirements apply equally to EV Certificates and these Guidelines. The required internal examination must relate to the EV Certificate validation criteria outlined in these Guidelines. +The requirements in Section 5.3.3 of the Baseline Requirements apply equally to EV Certificates and these Guidelines. The required internal examination must relate to the EV Certificate validation criteria outlined in these Guidelines. ### 5.3.4 Retraining frequency and requirements @@ -1327,7 +1325,7 @@ As specified in Section 5.4 of the Baseline Requirements. ### 6.1.1 Key pair generation -All requirements in Section 6.1.1.1 of the Baseline Requirements apply equally to EV Certificates. However, for Root CA Key Pairs generated after the release of these Guidelines, the Root CA Key Pair generation ceremony MUST be witnessed by the CA's Qualified Auditor in order to observe the process and the controls over the integrity and confidentiality of the Root CA Key Pairs produced. The Qualified Auditor MUST then issue a report opining that the CA, during its Root CA Key Pair and Certificate generation process: +All requirements in Section 6.1.1.1 of the Baseline Requirements apply equally to EV Certificates. However, for Root CA Key Pairs generated after the release of these Guidelines, the Root CA Key Pair generation ceremony MUST be witnessed by the CA's Qualified Auditor in order to observe the process and the controls over the integrity and confidentiality of the Root CA Key Pairs produced. The Qualified Auditor MUST then issue a report opining that the CA, during its Root CA Key Pair and Certificate generation process: 1. Documented its Root CA key generation and protection procedures in its Certificate Policy, and its Certification Practices Statement; 2. Included appropriate detail in its Root Key Generation Script; @@ -1416,21 +1414,21 @@ This section sets forth minimum requirements for the content of the EV Certifica ### 7.1.2 Certificate extensions -The extensions listed in [Section 7.1.2](#712-certificate-extensions) are recommended for maximum interoperability between certificates and browsers / applications, but are not mandatory on the CAs except where indicated as “Required”. CAs may use other extensions that are not listed in [Section 7.1.2](#712-certificate-extensions), but are encouraged to add them to this section by ballot from time to time to help increase extension standardization across the industry. +The extensions listed in [Section 7.1.2](#712-certificate-extensions) are recommended for maximum interoperability between certificates and browsers / applications, but are not mandatory on the CAs except where indicated as “Required”. CAs may use other extensions that are not listed in [Section 7.1.2](#712-certificate-extensions), but are encouraged to add them to this section by ballot from time to time to help increase extension standardization across the industry. -If a CA includes an extension in a certificate that has a Certificate field which is named in [Section 7.1.2](#712-certificate-extensions), the CA must follow the format specified in that subsection. However, no extension or extension format shall be mandatory on a CA unless specifically stated as “Required” in the subsection that describes the extension. +If a CA includes an extension in a certificate that has a Certificate field which is named in [Section 7.1.2](#712-certificate-extensions), the CA must follow the format specified in that subsection. However, no extension or extension format shall be mandatory on a CA unless specifically stated as “Required” in the subsection that describes the extension. #### 7.1.2.1 Subject Alternative Name Extension -**Certificate Field**: `subjectAltName:dNSName` -**Required/Optional**: **Required** -**Contents**: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This extension MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. +**Certificate Field**: `subjectAltName:dNSName` +**Required/Optional**: **Required** +**Contents**: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This extension MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. #### 7.1.2.2 CA/Browser Forum Organization Identifier Extension -**Extension Name**: `cabfOrganizationIdentifier` (OID: 2.23.140.3.1) -**Verbose OID**: `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-extensions(3) cabf-organization-identifier(1) }` -**Required/Optional**: **Optional (but see below)** +**Extension Name**: `cabfOrganizationIdentifier` (OID: 2.23.140.3.1) +**Verbose OID**: `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-extensions(3) cabf-organization-identifier(1) }` +**Required/Optional**: **Optional (but see below)** **Contents**: If the subject:organizationIdentifier is present, this field MUST be present. If present, this extension MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. @@ -1474,8 +1472,8 @@ Subject to the requirements of these Guidelines, the EV Certificate and certific ##### 7.1.4.2.1 Subject Organization Name Field -**Certificate Field**: `subject:organizationName` (OID 2.5.4.10) -**Required/Optional**: Required +**Certificate Field**: `subject:organizationName` (OID 2.5.4.10) +**Required/Optional**: Required **Contents**: This field MUST contain the Subject's full legal organization name as listed in the official records of the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration or as otherwise verified by the CA as provided herein. A CA MAY abbreviate the organization prefixes or suffixes in the organization name, e.g., if the official record shows "Company Name Incorporated" the CA MAY include "Company Name, Inc." When abbreviating a Subject's full legal name as allowed by this subsection, the CA MUST use abbreviations that are not misleading in the Jurisdiction of Incorporation or Registration. @@ -1486,71 +1484,71 @@ If the combination of names or the organization name by itself exceeds 64 charac ##### 7.1.4.2.2 Subject Common Name Field -**Certificate Field**: `subject:commonName` (OID: 2.5.4.3) -**Required/Optional**: Deprecated (Discouraged, but not prohibited) -**Contents**: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This field MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. +**Certificate Field**: `subject:commonName` (OID: 2.5.4.3) +**Required/Optional**: Deprecated (Discouraged, but not prohibited) +**Contents**: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This field MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. ##### 7.1.4.2.3 Subject Business Category Field -**Certificate Field**: `subject:businessCategory` (OID: 2.5.4.15) -**Required/Optional**: Required +**Certificate Field**: `subject:businessCategory` (OID: 2.5.4.15) +**Required/Optional**: Required **Contents**: This field MUST contain one of the following strings: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity" depending upon whether the Subject qualifies under the terms of [Section 4.1.1.1](#4111-private-organization-subjects), [Section 4.1.1.2](#4112-government-entity-subjects), [Section 4.1.1.3](#4113-business-entity-subjects) or [Section 4.1.1.4](#4114-non-commercial-entity-subjects), respectively. ##### 7.1.4.2.4 Subject Jurisdiction of Incorporation or Registration Field **Certificate Fields**: -Locality (if required): +Locality (if required): `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1) -State or province (if required): +State or province (if required): `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2) -Country: +Country: `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) -**Required/Optional**: Required -**Contents**: These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. Country information MUST be specified using the applicable ISO country code. State or province or locality information (where applicable) for the Subject's Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction. +**Required/Optional**: Required +**Contents**: These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. Country information MUST be specified using the applicable ISO country code. State or province or locality information (where applicable) for the Subject's Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction. Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, the values within these fields have been disclosed within the latest publicly-available disclosure, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), as acceptable values for the applicable Incorporating Agency or Registration Agency. ##### 7.1.4.2.5 Subject Registration Number Field -**Certificate Field**: `subject:serialNumber` (OID: 2.5.4.5) -**Required/Optional**: **Required** -**Contents**: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). +**Certificate Field**: `subject:serialNumber` (OID: 2.5.4.5) +**Required/Optional**: **Required** +**Contents**: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). For Government Entities that do not have a Registration Number or readily verifiable date of creation, the CA SHALL enter appropriate language to indicate that the Subject is a Government Entity. -For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). +For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). Effective as of 1 October 2020, if the CA has disclosed a set of acceptable format or formats for Registration Numbers for the applicable Registration Agency or Incorporating Agency, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), the CA MUST ensure, prior to issuance, that the Registration Number is valid according to at least one currently disclosed format for that applicable Registration Agency or Incorporating agency. ##### 7.1.4.2.6 Subject Physical Address of Place of Business Field -**Certificate Fields**: - Number and street: `subject:streetAddress` (OID: 2.5.4.9) - City or town: `subject:localityName` (OID: 2.5.4.7) - State or province (where applicable): `subject:stateOrProvinceName` (OID: 2.5.4.8) - Country: `subject:countryName` (OID: 2.5.4.6) - Postal code: `subject:postalCode` (OID: 2.5.4.17) -**Required/Optional**: Required/Optional +**Certificate Fields**: + Number and street: `subject:streetAddress` (OID: 2.5.4.9) + City or town: `subject:localityName` (OID: 2.5.4.7) + State or province (where applicable): `subject:stateOrProvinceName` (OID: 2.5.4.8) + Country: `subject:countryName` (OID: 2.5.4.6) + Postal code: `subject:postalCode` (OID: 2.5.4.17) +**Required/Optional**: Required/Optional **Contents**: These fields MUST contain the verified physical address of the Subject’s Place of Business. -The `countryName` field MUST be present and MUST contain the applicable two-letter ISO 3166-1 country code. If the country is not represented by an official ISO 3166-1 code, the ISO 3166-1 user-assigned code "XX" MUST be used. +The `countryName` field MUST be present and MUST contain the applicable two-letter ISO 3166-1 country code. If the country is not represented by an official ISO 3166-1 code, the ISO 3166-1 user-assigned code "XX" MUST be used. -The `localityName` and `stateOrProvinceName` fields are OPTIONAL, but at least one of them MUST be present. When included, these fields MUST accurately represent the locality and/or state or province information verified in accordance with Section 3.2.2.1 of the Baseline Requirements. +The `localityName` and `stateOrProvinceName` fields are OPTIONAL, but at least one of them MUST be present. When included, these fields MUST accurately represent the locality and/or state or province information verified in accordance with Section 3.2.2.1 of the Baseline Requirements. The `streetAddress` and `postalCode` fields are OPTIONAL. If present, they MUST contain the verified street address and postal information of the Subject’s Place of Business as required by Section 3.2.2.1 of the Baseline Requirements. Multiple `streetAddress` attributes MAY be present. ##### 7.1.4.2.7 Subject Organizational Unit Name Field -**Certificate Field**: `subject:organizationalUnitName` (OID: 2.5.4.11) +**Certificate Field**: `subject:organizationalUnitName` (OID: 2.5.4.11) **Required/Optional/Prohibited**: **Prohibited**. ##### 7.1.4.2.8 Subject Organization Identifier Field -**Certificate Field**: `subject:organizationIdentifier` (OID: 2.5.4.97) -**Required/Optional**: Optional +**Certificate Field**: `subject:organizationIdentifier` (OID: 2.5.4.97) +**Required/Optional**: Optional **Contents**: If present, this field MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. The organizationIdentifier MUST be encoded as a PrintableString or UTF8String. @@ -1563,7 +1561,7 @@ The Registration Scheme MUST be identified using the using the following structu * a hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8)); * Registration Reference allocated in accordance with the identified Registration Scheme -Note: Registration References MAY contain hyphens, but Registration Schemes, ISO 3166 country codes, and ISO 3166-2 identifiers do not. Therefore if more than one hyphen appears in the structure, the leftmost hyphen is a separator, and the remaining hyphens are part of the Registration Reference. +Note: Registration References MAY contain hyphens, but Registration Schemes, ISO 3166 country codes, and ISO 3166-2 identifiers do not. Therefore if more than one hyphen appears in the structure, the leftmost hyphen is a separator, and the remaining hyphens are part of the Registration Reference. As in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field), the specified location information MUST match the scope of the registration being referenced. @@ -1631,7 +1629,7 @@ The Application Software Supplier identifies Root CAs that are approved to issue #### 7.1.6.4 Subscriber Certificates -A Certificate issued to a Subscriber MUST contain one or more policy identifier(s), defined by the Issuing CA, in the Certificate's `certificatePolicies` extension that indicates adherence to and compliance with these Guidelines. Each CA SHALL document in its Certificate Policy or Certification Practice Statement that the Certificates it issues containing the specified policy identifier(s) are managed in accordance with these Guidelines. +A Certificate issued to a Subscriber MUST contain one or more policy identifier(s), defined by the Issuing CA, in the Certificate's `certificatePolicies` extension that indicates adherence to and compliance with these Guidelines. Each CA SHALL document in its Certificate Policy or Certification Practice Statement that the Certificates it issues containing the specified policy identifier(s) are managed in accordance with these Guidelines. ### 7.1.7 Usage of Policy Constraints extension @@ -1667,7 +1665,7 @@ CAs issuing EV Certificates MUST undergo an annual audit that meets the criteria ### 8.1.1 Self audits -During the period in which it issues EV Certificates, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least three percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. For all EV Certificates where the Final Cross-Correlation and Due Diligence requirements of [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence) is performed by an RA, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least six percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. +During the period in which it issues EV Certificates, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least three percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. For all EV Certificates where the Final Cross-Correlation and Due Diligence requirements of [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence) is performed by an RA, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least six percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. ## 8.2 Identity/qualifications of assessor @@ -1681,7 +1679,7 @@ A Qualified Auditor (as defined in Section 8.2 of the Baseline Requirements) MUS ## 8.6 Communication of results -CAs SHOULD make its audit report publicly available no later than three months after the end of the audit period. If there is a delay greater than three months and if so requested by an Application Software Supplier, the CA MUST provide an explanatory letter signed by its auditor. +CAs SHOULD make its audit report publicly available no later than three months after the end of the audit period. If there is a delay greater than three months and if so requested by an Application Software Supplier, the CA MUST provide an explanatory letter signed by its auditor. ## 8.7 Pre-issuance Readiness Audit @@ -1692,7 +1690,7 @@ CAs SHOULD make its audit report publicly available no later than three months a i. a point-in-time readiness assessment audit against the WebTrust for CA Program, or ii. a point-in-time readiness assessment audit against the WebTrust EV Program, the ETSI TS 102 042 EVCP, or the ETSI EN 319 411-1 for EVCP policy. -The CA MUST complete any required point-in-time readiness assessment no earlier than twelve (12) months prior to issuing an EV Certificate. The CA MUST undergo a complete audit under such scheme within ninety (90) days of issuing the first EV Certificate. +The CA MUST complete any required point-in-time readiness assessment no earlier than twelve (12) months prior to issuing an EV Certificate. The CA MUST undergo a complete audit under such scheme within ninety (90) days of issuing the first EV Certificate. # 9. OTHER BUSINESS AND LEGAL MATTERS @@ -1714,9 +1712,9 @@ The CA MUST complete any required point-in-time readiness assessment no earlier Each CA SHALL maintain the following insurance related to their respective performance and obligations under these Guidelines: -A. Commercial General Liability insurance (occurrence form) with policy limits of at least two million US dollars in coverage; and +A. Commercial General Liability insurance (occurrence form) with policy limits of at least two million US dollars in coverage; and -B. Professional Liability/Errors and Omissions insurance, with policy limits of at least five million US dollars in coverage, and including coverage for: +B. Professional Liability/Errors and Omissions insurance, with policy limits of at least five million US dollars in coverage, and including coverage for: i. claims for damages arising out of an act, error, or omission, unintentional breach of contract, or neglect in issuing or maintaining EV Certificates, and; ii. claims for damages arising out of infringement of the proprietary rights of any third party (excluding copyright, and trademark infringement), and invasion of privacy and advertising injury. @@ -1760,27 +1758,27 @@ A CA MAY self-insure for liabilities that arise from such party's performance an When the CA issues an EV Certificate, the CA and its Root CA represent and warrant to the Certificate Beneficiaries listed in Section 9.6.1 of the Baseline Requirements, during the period when the EV Certificate is Valid, that the CA has followed the requirements of these Guidelines and its EV Policies in issuing and managing the EV Certificate and in verifying the accuracy of the information contained in the EV Certificate. The EV Certificate Warranties specifically include, but are not limited to, the following: -A. **Legal Existence**: The CA has confirmed with the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration that, as of the date the EV Certificate was issued, the Subject named in the EV Certificate legally exists as a valid organization or entity in the Jurisdiction of Incorporation or Registration; +A. **Legal Existence**: The CA has confirmed with the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration that, as of the date the EV Certificate was issued, the Subject named in the EV Certificate legally exists as a valid organization or entity in the Jurisdiction of Incorporation or Registration; -B. **Identity**: The CA has confirmed that, as of the date the EV Certificate was issued, the legal name of the Subject named in the EV Certificate matches the name on the official government records of the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration, and if an assumed name is also included, that the assumed name is properly registered by the Subject in the jurisdiction of its Place of Business; +B. **Identity**: The CA has confirmed that, as of the date the EV Certificate was issued, the legal name of the Subject named in the EV Certificate matches the name on the official government records of the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration, and if an assumed name is also included, that the assumed name is properly registered by the Subject in the jurisdiction of its Place of Business; -C. **Right to Use Domain Name**: The CA has taken all steps reasonably necessary to verify that, as of the date the EV Certificate was issued, the Subject named in the EV Certificate has the right to use all the Domain Name(s) listed in the EV Certificate; +C. **Right to Use Domain Name**: The CA has taken all steps reasonably necessary to verify that, as of the date the EV Certificate was issued, the Subject named in the EV Certificate has the right to use all the Domain Name(s) listed in the EV Certificate; -D. **Authorization for EV Certificate**: The CA has taken all steps reasonably necessary to verify that the Subject named in the EV Certificate has authorized the issuance of the EV Certificate; +D. **Authorization for EV Certificate**: The CA has taken all steps reasonably necessary to verify that the Subject named in the EV Certificate has authorized the issuance of the EV Certificate; -E. **Accuracy of Information**: The CA has taken all steps reasonably necessary to verify that all of the other information in the EV Certificate is accurate, as of the date the EV Certificate was issued; +E. **Accuracy of Information**: The CA has taken all steps reasonably necessary to verify that all of the other information in the EV Certificate is accurate, as of the date the EV Certificate was issued; -F. **Subscriber Agreement**: The Subject named in the EV Certificate has entered into a legally valid and enforceable Subscriber Agreement with the CA that satisfies the requirements of these Guidelines or, if they are affiliated, the Applicant Representative has acknowledged and accepted the Terms of Use; +F. **Subscriber Agreement**: The Subject named in the EV Certificate has entered into a legally valid and enforceable Subscriber Agreement with the CA that satisfies the requirements of these Guidelines or, if they are affiliated, the Applicant Representative has acknowledged and accepted the Terms of Use; -G. **Status**: The CA will follow the requirements of these Guidelines and maintain a 24 x 7 online-accessible Repository with current information regarding the status of the EV Certificate as Valid or revoked; and +G. **Status**: The CA will follow the requirements of these Guidelines and maintain a 24 x 7 online-accessible Repository with current information regarding the status of the EV Certificate as Valid or revoked; and -H. **Revocation**: The CA will follow the requirements of these Guidelines and revoke the EV Certificate for any of the revocation reasons specified in these Guidelines. +H. **Revocation**: The CA will follow the requirements of these Guidelines and revoke the EV Certificate for any of the revocation reasons specified in these Guidelines. ### 9.6.2 RA representations and warranties ### 9.6.3 Subscriber representations and warranties -Section 9.6.3 of the Baseline Requirements applies equally to EV Certificates. In cases where the Certificate Request does not contain all necessary information about the Applicant, the CA MUST additionally confirm the data with the Certificate Approver or Contract Signer rather than the Certificate Requester. +Section 9.6.3 of the Baseline Requirements applies equally to EV Certificates. In cases where the Certificate Request does not contain all necessary information about the Applicant, the CA MUST additionally confirm the data with the Certificate Approver or Contract Signer rather than the Certificate Requester. EV Certificate Applicants make the commitments and warranties set forth in Section 9.6.3 of the Baseline Requirements for the benefit of the CA and Certificate Beneficiaries. @@ -1842,7 +1840,7 @@ Section 9.16.3 of the Baseline Requirements applies equally to EV Certificates. # Appendix A - User Agent Verification (Normative) -The CA MUST host test Web pages that allow Application Software Suppliers to test their software with EV Certificates that chain up to each EV Root Certificate. At a minimum, the CA MUST host separate Web pages using certificates that are: +The CA MUST host test Web pages that allow Application Software Suppliers to test their software with EV Certificates that chain up to each EV Root Certificate. At a minimum, the CA MUST host separate Web pages using certificates that are: i. valid; ii. revoked; and @@ -1863,7 +1861,7 @@ The CA MUST host test Web pages that allow Application Software Suppliers to tes | Client Representative: | **(Exact name of Client Representative who signed the Application – see footnote 2)** | | Application Date: | **(Insert date of Client's Application to the Issuing CA)** | -This firm represents _[**exact** company name of Client]_ [^1] ("Client"), who has submitted the Application to you dated as of the Application Date shown above ("Application"). We have been asked by our Client to present you with our opinion as stated in this letter. +This firm represents _[**exact** company name of Client]_ [^1] ("Client"), who has submitted the Application to you dated as of the Application Date shown above ("Application"). We have been asked by our Client to present you with our opinion as stated in this letter. [Insert customary preliminary matters for opinion letters in your jurisdiction.] @@ -1873,7 +1871,7 @@ On this basis, we hereby offer the following opinion: 2. That Company conducts business under the assumed name or "DBA"_[assumed name of the Applicant]_ and has registered such name with the appropriate government agency in the jurisdiction of its place of business below. -3. That _[name of Client's Representative]_[^2] has authority to act on behalf of Company to: [_select as appropriate_] (a) provide the information about Company required for issuance of the EV Certificates as contained in the attached Application, (b) request one or more EV Certificates and to designate other persons to request EV Certificates, and (c) agree to the relevant contractual obligations contained in the Subscriber Agreement on behalf of Company. +3. That _[name of Client's Representative]_[^2] has authority to act on behalf of Company to: [_select as appropriate_] (a) provide the information about Company required for issuance of the EV Certificates as contained in the attached Application, (b) request one or more EV Certificates and to designate other persons to request EV Certificates, and (c) agree to the relevant contractual obligations contained in the Subscriber Agreement on behalf of Company. 4. That Company has a physical presence and its place of business is at the following location: @@ -1899,7 +1897,7 @@ _[Jurisdiction(s) in which attorney / Latin notary is admitted to practice]_[^3] cc: [Send copy to Client_]_ -[^1]: This must be the Client's exact corporate name, as registered with the relevant Incorporating Agency in the Client's Jurisdiction of Incorporation. This is the name that will be included in the EV Certificate. +[^1]: This must be the Client's exact corporate name, as registered with the relevant Incorporating Agency in the Client's Jurisdiction of Incorporation. This is the name that will be included in the EV Certificate. [^2]: If necessary to establish the Client Representative's actual authority, you may rely on a Power of Attorney from an officer of Client who has authority to delegate the authority to the Client Representative. @@ -1909,7 +1907,7 @@ cc: [Send copy to Client_]_ **(Informative)** -It is acceptable for professional accountants to provide letters that address specified matters. The letters would be provided in accordance with the professional standards in the jurisdiction in which the accountant practices. +It is acceptable for professional accountants to provide letters that address specified matters. The letters would be provided in accordance with the professional standards in the jurisdiction in which the accountant practices. Two examples of the letter that might be prepared by an accountant in the United States and in Canada follow: @@ -1917,9 +1915,9 @@ Two examples of the letter that might be prepared by an accountant in the United To the [Certification Authority] and Management of [Client]: -We have performed the procedures enumerated below, which were agreed to by the Managements of Client, solely to assist you in evaluating the company's application for an Extended Validation (EV) Certificate, dated......................., 20...... This agreed-upon procedures engagement was conducted in accordance with attestation standards established by the American Institute of Certified Public Accountants. The sufficiency of these procedures is solely the responsibility of those parties specified in this report. Consequently, we make no representation regarding the sufficiency of the procedures described below either for the purpose for which this report has been requested or for any other purpose. +We have performed the procedures enumerated below, which were agreed to by the Managements of Client, solely to assist you in evaluating the company's application for an Extended Validation (EV) Certificate, dated......................., 20...... This agreed-upon procedures engagement was conducted in accordance with attestation standards established by the American Institute of Certified Public Accountants. The sufficiency of these procedures is solely the responsibility of those parties specified in this report. Consequently, we make no representation regarding the sufficiency of the procedures described below either for the purpose for which this report has been requested or for any other purpose. -| Specified Information: | Procedure:(Note 1: These are illustrative of the procedures that would be undertaken and are designed to meet the needs of the Certification Authorities issuing Extended Validation Certificates) | Results: (Note 2: If you are unavailable to perform any of the stated procedure, this should be noted in this column. Any exceptions should be noted in a separate paragraph below) | +| Specified Information: | Procedure:(Note 1: These are illustrative of the procedures that would be undertaken and are designed to meet the needs of the Certification Authorities issuing Extended Validation Certificates) | Results: (Note 2: If you are unavailable to perform any of the stated procedure, this should be noted in this column. Any exceptions should be noted in a separate paragraph below) | | --- | --- | --- | | | | | | Legal Name - 123456 Delaware corporation | Agree legal name to permanent audit file information (If audit has been completed). | Legal name on the application agrees with the information contained in our permanent file with respect to Client.(If there is no permanent file, state this fact) | @@ -1928,7 +1926,7 @@ We have performed the procedures enumerated below, which were agreed to by the M | | | | | Physical location - "Address Information" | Visit the location at the address | Site visit completed at Address | | | | | -| Business Phone Number - 555 999 9999 | Phone the number provided and confirm that it was answered by the named organization | Phoned Business Number and noted that it was answered with the Doing Business As name. This would provided by the receptionist | +| Business Phone Number - 555 999 9999 | Phone the number provided and confirm that it was answered by the named organization | Phoned Business Number and noted that it was answered with the Doing Business As name. This would provided by the receptionist | | | | | | Bank Account – "Bank Name", "Account Number" | Request a letter directly from "the Bank" confirming the existence of the account for the benefit of "the Client" | Received letter directly from "the Bank" confirming the existence of the account for the benefit of "the Client" | | | | | @@ -1936,7 +1934,7 @@ We have performed the procedures enumerated below, which were agreed to by the M | | | | | Name of application signer and approver | Obtain letter from verified Officer confirming the names of the application signer and approver | Obtained letter from the President confirming the names of the duly authorized names of the application signer and approver as they appear in the application | -We were not engaged to and did not conduct an examination, the objective of which would be the expression of an opinion on the Application for Extended Validation Certificate. Accordingly, we do not express such an opinion. Had we performed additional procedures, other matters might have come to our attention that would have been reported to you. +We were not engaged to and did not conduct an examination, the objective of which would be the expression of an opinion on the Application for Extended Validation Certificate. Accordingly, we do not express such an opinion. Had we performed additional procedures, other matters might have come to our attention that would have been reported to you. This report is intended solely for the information and use of the Certification Authority and managements of Client, and is not intended to be and should not be used by anyone other than these specified parties. @@ -1950,9 +1948,9 @@ To: [Name of Certification Authority] Re: Client Limited [Applicant] -As specifically agreed, I/we have performed the following procedures in connection with the above company's application for an Extended Validation (EV) Certificate, dated ......................., 20.... with respect to the following specified information contained in the application +As specifically agreed, I/we have performed the following procedures in connection with the above company's application for an Extended Validation (EV) Certificate, dated ......................., 20.... with respect to the following specified information contained in the application -| Specified Information: | Procedure:(Note 1: These are illustrative of the procedures that would be undertaken and are designed to meet the needs of the Certification Authorities issuing Extended Validation Certificates) | Results: (Note 2: If you are unavailable to perform any of the stated procedure, this should be noted in this column. Any exceptions should be noted in a separate paragraph below) | +| Specified Information: | Procedure:(Note 1: These are illustrative of the procedures that would be undertaken and are designed to meet the needs of the Certification Authorities issuing Extended Validation Certificates) | Results: (Note 2: If you are unavailable to perform any of the stated procedure, this should be noted in this column. Any exceptions should be noted in a separate paragraph below) | | --- | --- | --- | | | | | | Legal Name - 123456 Ontario limited | Agree legal name to permanent audit file information (If audit has been completed) | Legal name on the application agrees with the information contained in our permanent file with respect to Client.(If there is no permanent file, state this fact) | @@ -1961,7 +1959,7 @@ As specifically agreed, I/we have performed the following procedures in connecti | | | | | Physical location - "Address Information" | Visit the location at the address | Site visit completed at Address | | | | | -| Business Phone Number - 555 999 9999 | Phone the number provided and confirm that it was answered by the named organization | Phoned Business Number and noted that it was answered with the Doing Business As name. This would provided by the receptionist | +| Business Phone Number - 555 999 9999 | Phone the number provided and confirm that it was answered by the named organization | Phoned Business Number and noted that it was answered with the Doing Business As name. This would provided by the receptionist | | | | | | Bank Account – "Bank Name", "Account Number" | Request a letter directly from "the Bank" confirming the existence of the account for the benefit of "the Client" | Received letter directly from "the Bank" confirming the existence of the account for the benefit of "the Client" | | | | | @@ -1969,7 +1967,7 @@ As specifically agreed, I/we have performed the following procedures in connecti | | | | | Name of application signer and approver | Obtain letter from verified Officer confirming the names of the application signer and approver | Obtained letter from the President confirming the names of the duly authorized names of the application signer and approver as they appear in the application | -As a result of applying the above procedures, I/we found [no / the following] exceptions [list of exceptions]. However, these procedures do not constitute an audit of the company's application for an EV Certificate, and therefore I express no opinion on the application dated ......................., 20..... +As a result of applying the above procedures, I/we found [no / the following] exceptions [list of exceptions]. However, these procedures do not constitute an audit of the company's application for an EV Certificate, and therefore I express no opinion on the application dated ......................., 20..... This letter is for use solely in connection with the application for an Extended Validation Certificate by [Client] dated ......................., 20...... @@ -1979,13 +1977,13 @@ City # Appendix D - Country-Specific Interpretative Guidelines (Normative) -NOTE: This appendix provides alternative interpretations of the EV Guidelines for countries that have a language, cultural, technical, or legal reason for deviating from a strict interpretation of the EV Guidelines. More specific information for particular countries may be added to this appendix in the future. +NOTE: This appendix provides alternative interpretations of the EV Guidelines for countries that have a language, cultural, technical, or legal reason for deviating from a strict interpretation of the EV Guidelines. More specific information for particular countries may be added to this appendix in the future. ## 1. Organization Names 1. Non-Latin Organization Name - Where an EV Applicant's organization name is not registered with a QGIS in _Latin_ characters and the Applicant's foreign character organization name and registration have been verified with a QGIS in accordance with these Guidelines, a CA MAY include a Latin character organization name in the EV Certificate. In such a case, the CA MUST follow the procedures laid down in this section. + Where an EV Applicant's organization name is not registered with a QGIS in _Latin_ characters and the Applicant's foreign character organization name and registration have been verified with a QGIS in accordance with these Guidelines, a CA MAY include a Latin character organization name in the EV Certificate. In such a case, the CA MUST follow the procedures laid down in this section. 2. Romanized Names @@ -1993,18 +1991,18 @@ NOTE: This appendix provides alternative interpretations of the EV Guidelines fo If the CA can not rely on a transliteration/Romanization of the registered name using a system officially recognized by the Government in the Applicant's Jurisdiction of Incorporation, then it MUST rely on one of the options below, in order of preference: - A. A system recognized by the International Organization for Standardization (ISO); - B. A system recognized by the United Nations; or - C. A Lawyer's Opinion or Accountant's Letter confirming the proper Romanization of the registered name. + A. A system recognized by the International Organization for Standardization (ISO); + B. A system recognized by the United Nations; or + C. A Lawyer's Opinion or Accountant's Letter confirming the proper Romanization of the registered name. 3. Translated Name - In order to include a Latin character name in the EV certificate that is not a direct Romanization of the registered name (e.g. an English Name) the CA MUST verify that the Latin character name is: + In order to include a Latin character name in the EV certificate that is not a direct Romanization of the registered name (e.g. an English Name) the CA MUST verify that the Latin character name is: - A. Included in the Articles of Incorporation (or equivalent document) filed as part of the organization registration; or - B. Recognized by a QTIS in the Applicant's Jurisdiction of Incorporation as the Applicant's recognized name for tax filings; or - C. Confirmed with a QIIS to be the name associated with the registered organization; or - D. Confirmed by a Verified Legal Opinion or Accountant's Letter to be a translated trading name associated with the registered organization. + A. Included in the Articles of Incorporation (or equivalent document) filed as part of the organization registration; or + B. Recognized by a QTIS in the Applicant's Jurisdiction of Incorporation as the Applicant's recognized name for tax filings; or + C. Confirmed with a QIIS to be the name associated with the registered organization; or + D. Confirmed by a Verified Legal Opinion or Accountant's Letter to be a translated trading name associated with the registered organization. ### Country-Specific Procedures @@ -2014,24 +2012,24 @@ As interpretation of the procedures set out above: 1. Organization Names - A. The Revised Hepburn method of Romanization, as well as Kunrei-shiki and Nihon-shiki methods described in ISO 3602, are acceptable for Japanese Romanizations. - B. The CA MAY verify the Romanized transliteration, language translation (e.g. English name), or other recognized Roman-letter substitute of the Applicant's formal legal name with either a QIIS, Verified Legal Opinion, or Verified Accountant Letter. - C. The CA MAY use the Financial Services Agency to verify a Romanized, translated, or other recognized Roman-letter substitute name. When used, the CA MUST verify that the translated English is recorded in the audited Financial Statements. - D. When relying on Articles of Incorporation to verify a Romanized, translated, or other recognized Roman-letter substitute name, the Articles of Incorporation MUST be accompanied either: by a document, signed with the original Japanese Corporate Stamp, that proves that the Articles of Incorporation are authentic and current, or by a Verified Legal Opinion or a Verified Accountant Letter. The CA MUST verify the authenticity of the Corporate Stamp. - E. A Romanized, translated, or other recognized Roman-lettered substitute name confirmed in accordance with this [Appendix D-1](#d-1-japan) stored in the ROBINS database operated by JIPDEC MAY be relied upon by a CA for determining the allowed organization name during any issuance or renewal process of an EV Certificate without the need to re-perform the above procedures. + A. The Revised Hepburn method of Romanization, as well as Kunrei-shiki and Nihon-shiki methods described in ISO 3602, are acceptable for Japanese Romanizations. + B. The CA MAY verify the Romanized transliteration, language translation (e.g. English name), or other recognized Roman-letter substitute of the Applicant's formal legal name with either a QIIS, Verified Legal Opinion, or Verified Accountant Letter. + C. The CA MAY use the Financial Services Agency to verify a Romanized, translated, or other recognized Roman-letter substitute name. When used, the CA MUST verify that the translated English is recorded in the audited Financial Statements. + D. When relying on Articles of Incorporation to verify a Romanized, translated, or other recognized Roman-letter substitute name, the Articles of Incorporation MUST be accompanied either: by a document, signed with the original Japanese Corporate Stamp, that proves that the Articles of Incorporation are authentic and current, or by a Verified Legal Opinion or a Verified Accountant Letter. The CA MUST verify the authenticity of the Corporate Stamp. + E. A Romanized, translated, or other recognized Roman-lettered substitute name confirmed in accordance with this [Appendix D-1](#d-1-japan) stored in the ROBINS database operated by JIPDEC MAY be relied upon by a CA for determining the allowed organization name during any issuance or renewal process of an EV Certificate without the need to re-perform the above procedures. 2. Accounting Practitioner In Japan: - A. Accounting Practitioner includes either a certified public accountant (公認会計士 - Konin-kaikei-shi) or a licensed tax accountant (税理士 – Zei-ri-shi). - B. The CA MUST verify the professional status of the Accounting Practitioner through direct contact with the relevant local member association that is affiliated with either the Japanese Institute of Certified Public Accountants ([http://www.hp.jicpa.or.jp](http://www.hp.jicpa.or.jp/)), the Japan Federation of Certified Tax Accountant's Associations ([http://www.nichizeiren.or.jp](http://www.nichizeiren.or.jp/)), or any other authoritative source recognized by the Japanese Ministry of Finance ([http://www.mof.go.jp](http://www.mof.go.jp/)) as providing the current registration status of such professionals. + A. Accounting Practitioner includes either a certified public accountant (公認会計士 - Konin-kaikei-shi) or a licensed tax accountant (税理士 – Zei-ri-shi). + B. The CA MUST verify the professional status of the Accounting Practitioner through direct contact with the relevant local member association that is affiliated with either the Japanese Institute of Certified Public Accountants ([http://www.hp.jicpa.or.jp](http://www.hp.jicpa.or.jp/)), the Japan Federation of Certified Tax Accountant's Associations ([http://www.nichizeiren.or.jp](http://www.nichizeiren.or.jp/)), or any other authoritative source recognized by the Japanese Ministry of Finance ([http://www.mof.go.jp](http://www.mof.go.jp/)) as providing the current registration status of such professionals. 3. Legal Practitioner In Japan: - A. Legal Practitioner includes any of the following: + A. Legal Practitioner includes any of the following: - a licensed lawyer (弁護士 - Ben-go-shi), - a judicial scrivener (司法書士 - Shiho-sho-shi lawyer), @@ -2040,7 +2038,7 @@ As interpretation of the procedures set out above: For purposes of the EV Guidelines, a Japanese Notary Public is considered equivalent to a Latin Notary. - B. The CA MUST verify the professional status of the Legal Practitioner by direct contact through the relevant local member association that is affiliated with one of the following national associations: + B. The CA MUST verify the professional status of the Legal Practitioner by direct contact through the relevant local member association that is affiliated with one of the following national associations: - the Japan Federation of Bar Associations ([http://www.nichibenren.or.jp](http://www.nichibenren.or.jp/)), - the Japan Federation of Shiho-Shoshi Lawyer's Associations ([http://www.shiho-shoshi.or.jp](http://www.shiho-shoshi.or.jp/)), @@ -2050,9 +2048,9 @@ As interpretation of the procedures set out above: # Appendix E - Sample Contract Signer's Representation/Warranty (Informative) -A CA may rely on the Contract Signer's authority to enter into the Subscriber Agreement using a representation/warranty executed by the Contract Signer. An example of an acceptable warranty is as follows: +A CA may rely on the Contract Signer's authority to enter into the Subscriber Agreement using a representation/warranty executed by the Contract Signer. An example of an acceptable warranty is as follows: -[CA] and Applicant are entering into a legally valid and enforceable Subscriber Agreement that creates extensive obligations on Applicant. An EV Certificate serves as a form of digital identity for Applicant. The loss or misuse of this identity can result in great harm to the Applicant. By signing this Subscriber Agreement, the contract signer acknowledges that they have the authority to obtain the digital equivalent of a company stamp, seal, or (where applicable) officer's signature to establish the authenticity of the company's website, and that [Applicant name] is responsible for all uses of its EV Certificate. By signing this Agreement on behalf of [Applicant name], the contract signer represents that the contract signer +[CA] and Applicant are entering into a legally valid and enforceable Subscriber Agreement that creates extensive obligations on Applicant. An EV Certificate serves as a form of digital identity for Applicant. The loss or misuse of this identity can result in great harm to the Applicant. By signing this Subscriber Agreement, the contract signer acknowledges that they have the authority to obtain the digital equivalent of a company stamp, seal, or (where applicable) officer's signature to establish the authenticity of the company's website, and that [Applicant name] is responsible for all uses of its EV Certificate. By signing this Agreement on behalf of [Applicant name], the contract signer represents that the contract signer i. is acting as an authorized representative of [Applicant name], ii. is expressly authorized by [Applicant name] to sign Subscriber Agreements and approve EV Certificate requests on Applicant's behalf, and @@ -2120,48 +2118,16 @@ END The following Registration Schemes are currently recognized as valid under these guidelines: -* **NTR**: - - The information carried in this field shall be the same as held in - Subject Registration Number Field as specified in - [Section 7.1.4.2.5](#71425-subject-registration-number-field) and the country code - used in the Registration Scheme identifier shall match that of the - subject’s jurisdiction as specified in - [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). - - Where the Subject Jurisdiction of Incorporation or Registration Field in 9.2.4 - includes more than the country code, the additional locality information shall - be included as specified in [Section 7.1.4.2.8](#71428-subject-organization-identifier-field) - and/or [Section 7.1.2.2](#7122-cabrowser-forum-organization-identifier-extension). - -* **VAT**: - - Reference allocated by the national tax authorities to a Legal Entity. This - information shall be validated using information provided by the national tax - authority against the organization as identified by the Subject Organization - Name Field (see [Section 7.1.4.2.1](#71421-subject-organization-name-field)) and - Subject Registration Number Field (see - Section 7.1.4.2.5](#71425-subject-registration-number-field)) within the context of - the subject’s jurisdiction as specified in - [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). - For the purpose of identifying tax authorities, the country prefix described in article 215 of - EU Council Directive 2006/112/EC, as amended, MAY be used instead of the ISO 3166 2-letter country codes. - - * **PSD**: - - Authorization number as specified in ETSI TS 119 495 clause 4.4 - allocated to a payment service provider and containing the information as - specified in ETSI TS 119 495 clause 5.2.1. This information SHALL be - obtained directly from the national competent authority register for - payment services or from an information source approved by a government - agency, regulatory body, or legislation for this purpose. This information - SHALL be validated by being matched directly or indirectly (for example, by - matching a globally unique registration number) against the organization as - identified by the Subject Organization Name Field (see - [Section 7.1.4.2.1](#71421-subject-organization-name-field)) and - Subject Registration Number Field (see - [Section 7.1.4.2.5](#71425-subject-registration-number-field)) within the context of - the subject’s jurisdiction as specified in - [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). - The stated address of the organization combined with the organization name - SHALL NOT be the only information used to disambiguate the organization. +- **NTR**: + + The information carried in this field shall be the same as held in Subject Registration Number Field as specified in [Section 7.1.4.2.5](#71425-subject-registration-number-field) and the country code used in the Registration Scheme identifier shall match that of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). + + Where the Subject Jurisdiction of Incorporation or Registration Field in 9.2.4 includes more than the country code, the additional locality information shall be included as specified in [Section 7.1.4.2.8](#71428-subject-organization-identifier-field) and/or [Section 7.1.2.2](#7122-cabrowser-forum-organization-identifier-extension). + +- **VAT**: + + Reference allocated by the national tax authorities to a Legal Entity. This information shall be validated using information provided by the national tax authority against the organization as identified by the Subject Organization Name Field (see [Section 7.1.4.2.1](#71421-subject-organization-name-field)) and Subject Registration Number Field (see Section 7.1.4.2.5](#71425-subject-registration-number-field)) within the context of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). For the purpose of identifying tax authorities, the country prefix described in article 215 of EU Council Directive 2006/112/EC, as amended, MAY be used instead of the ISO 3166 2-letter country codes. + +- **PSD**: + + Authorization number as specified in ETSI TS 119 495 clause 4.4 allocated to a payment service provider and containing the information as specified in ETSI TS 119 495 clause 5.2.1. This information SHALL be obtained directly from the national competent authority register for payment services or from an information source approved by a government agency, regulatory body, or legislation for this purpose. This information SHALL be validated by being matched directly or indirectly (for example, by matching a globally unique registration number) against the organization as identified by the Subject Organization Name Field (see [Section 7.1.4.2.1](#71421-subject-organization-name-field)) and Subject Registration Number Field (see [Section 7.1.4.2.5](#71425-subject-registration-number-field)) within the context of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). The stated address of the organization combined with the organization name SHALL NOT be the only information used to disambiguate the organization. From fdb166877619bfdedeb627c1da0950f23c8bc437 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 26 Nov 2025 19:42:36 +0100 Subject: [PATCH 064/121] #432 fixing numbering --- docs/EVG.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index b179e5bb..5bf51b6b 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -452,14 +452,12 @@ The CA MUST document where to obtain this information within Section 3.2 of the To verify the Applicant's legal existence and identity, the CA MUST do the following. 1. **Private Organization Subjects** - A. **Legal Existence**: Verify that the Applicant is a legally recognized entity, in existence and validly formed (e.g., incorporated) with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration, and not designated on the records of the Incorporating or Registration Agency by labels such as "inactive", "invalid", "not current", or the equivalent. B. **Organization Name**: Verify that the Applicant's formal legal name as recorded with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration matches the Applicant's name in the EV Certificate Request. C. **Registration Number**: Obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Incorporation or Registration. D. **Registered Agent**: Obtain the identity and address of the Applicant's Registered Agent or Registered Office (as applicable in the Applicant's Jurisdiction of Incorporation or Registration). 2. **Government Entity Subjects** - A. **Legal Existence**: Verify that the Applicant is a legally recognized Government Entity, in existence in the political subdivision in which such Government Entity operates. B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of incorporation, registration, or formation, or the identifier for the legislative act that created the Government Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is a Government Entity. From a9dc1eeb773a4407ecea51b9b965358d6e669434 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 26 Nov 2025 20:03:48 +0100 Subject: [PATCH 065/121] #432 reverted spaces --- docs/EVG.md | 520 ++++++++++++++++++++++++++++------------------------ 1 file changed, 278 insertions(+), 242 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 5bf51b6b..1f5c0d2b 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -14,23 +14,23 @@ copyright: | # 1. INTRODUCTION -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 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. +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. **Notice to Readers** -The Guidelines for the Issuance and Management of Extended Validation Certificates present criteria established by the CA/Browser Forum for use by certification authorities when issuing, maintaining, and revoking certain digital certificates for use in Internet Web site commerce These Guidelines may be revised from time to time, as appropriate, in accordance with procedures adopted by the CA/Browser Forum. Questions or suggestions concerning these guidelines may be directed to the CA/Browser Forum at . +The Guidelines for the Issuance and Management of Extended Validation Certificates present criteria established by the CA/Browser Forum for use by certification authorities when issuing, maintaining, and revoking certain digital certificates for use in Internet Web site commerce. These Guidelines may be revised from time to time, as appropriate, in accordance with procedures adopted by the CA/Browser Forum. Questions or suggestions concerning these guidelines may be directed to the CA/Browser Forum at . **The CA/Browser Forum** -The CA/Browser Forum is a voluntary open organization of certification authorities and suppliers of Internet browsers and other relying-party software applications. Membership is listed at . +The CA/Browser Forum is a voluntary open organization of certification authorities and suppliers of Internet browsers and other relying-party software applications. Membership is listed at . ## 1.1 Overview -These Guidelines for the issuance and management of Extended Validation Certificates describe certain of the minimum requirements that a Certification Authority must meet in order to issue Extended Validation Certificates. Subject Organization information from Valid EV Certificates may be displayed 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 they are accessing. These Guidelines incorporate the Baseline Requirements established by the CA/Browser Forum by reference. A copy of the Baseline Requirements is available on the CA/Browser Forum's website at . +These Guidelines for the issuance and management of Extended Validation Certificates describe certain of the minimum requirements that a Certification Authority must meet in order to issue Extended Validation Certificates. Subject Organization information from Valid EV Certificates may be displayed 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 they are accessing. These Guidelines incorporate the Baseline Requirements established by the CA/Browser Forum by reference. A copy of the Baseline Requirements is available on the CA/Browser Forum's website at . -These Guidelines address the basic issue of validating Subject identity information in EV Certificates and some related matters. They do not address all of the related matters, such as certain technical and operational ones. This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet. However, the Working Group encourages the re-use of these guidelines as a basis for similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. +These Guidelines address the basic issue of validating Subject identity information in EV Certificates and some related matters. They do not address all of the related matters, such as certain technical and operational ones. This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet. However, the Working Group encourages the re-use of these guidelines as a basis for similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. These Guidelines do not address the verification of information, or the issuance, use, maintenance, or revocation of EV Certificates by enterprises that operate their own Public Key Infrastructure for internal purposes only, where its Root CA Certificate is not distributed by any Application Software Supplier. @@ -60,8 +60,8 @@ These Guidelines do not address the verification of information, or the issuance | 1.5.7 | 151 | Addition of Optional OIDs for Indicating Level of Validation | 28 Sept 2015 | 28 Sept 2015 | | 1.5.8 | 162 | Sunset of Exceptions | 15 Mar 2016 | 15 Mar 2016 | | 1.5.9 | 163 | Fix Errata in EV Guidelines 11.2.1 | 18 Mar 2016 | 18 Mar 2016 | -| 1.6.0 | 171 | Updating ETSI Standards | 1 July 2016 | 1 July 2016 | -| 1.6.1 | 180 | In EV 11.7.1, removed outdated cross-reference to BR 3.2.2.4(7) | 7 Jan. 2017 | 7 Jan. 2017 | +| 1.6.0 | 171 | Updating ETSI Standards | 1 July 2016 | 1 July 2016 | +| 1.6.1 | 180 | In EV 11.7.1, removed outdated cross-reference to BR 3.2.2.4(7) | 7 Jan. 2017 | 7 Jan. 2017 | | 1.6.2 | 103 | 825-day Certificate Lifetimes | 17 Mar. 2017 | 17 Mar. 2017 | | 1.6.3 | 198 | .Onion Revisions (declared invalid) | 7 May 2017 | 8 June 2017 | | 1.6.4 | 191 | Clarify Place of Business Information | 23 May 2017 | 23 June 2017 | @@ -97,7 +97,7 @@ These Guidelines do not address the verification of information, or the issuance | 2020-10-01 | [3.2.2.1.3](#32213-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 | [7.1.4.2.7](#71427-subject-organizational-unit-name-field) | CAs MUST NOT include the organizationalUnitName field in the Subject | -**Implementers' Note**: Version 1.3 of these EV Guidelines was published on 20 November 2010 and supplemented through May 2012 when version 1.4 was published. ETSI TS 102 042 and ETSI TR 101 564 Technical Report: Guidance on ETSI TS 102 042 for Issuing Extended Validation Certificates for Auditors and CSPs reference version 1.3 of these EV Guidelines, and ETSI Draft EN 319 411-1 references version 1.4. Version 1.4.5 of Webtrust(r) for Certification Authorities – Extended Validation Audit Criteria references version 1.4.5 of these EV Guidelines. As illustrated in the Document History table above, the CA/Browser Forum continues to improve relevant industry guidelines, including this document, the Baseline Requirements, and the Network and Certificate System Security Requirements. We encourage all CAs to conform to each revision 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. 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. +**Implementers' Note**: Version 1.3 of these EV Guidelines was published on 20 November 2010 and supplemented through May 2012 when version 1.4 was published. ETSI TS 102 042 and ETSI TR 101 564 Technical Report: Guidance on ETSI TS 102 042 for Issuing Extended Validation Certificates for Auditors and CSPs reference version 1.3 of these EV Guidelines, and ETSI Draft EN 319 411-1 references version 1.4. Version 1.4.5 of Webtrust(r) for Certification Authorities – Extended Validation Audit Criteria references version 1.4.5 of these EV Guidelines. As illustrated in the Document History table above, the CA/Browser Forum continues to improve relevant industry guidelines, including this document, the Baseline Requirements, and the Network and Certificate System Security Requirements. We encourage all CAs to conform to each revision 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. 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. ## 1.3 PKI participants @@ -110,11 +110,11 @@ Affiliates and/or RAs must comply with the qualification requirements of [Sectio The CA SHALL verify that the Delegated Third Party's personnel involved in the issuance of a Certificate meet the training and skills requirements of [Section 5.3](#53-personnel-controls) and the document retention and event logging requirements of [Section 5.4](#54-audit-logging-procedures). -In all cases, the CA MUST contractually obligate each Affiliate, RA, subcontractor, and Enterprise RA to comply with all applicable requirements in these Guidelines and to perform them as required of the CA itself.The CA SHALL enforce these obligations and internally audit each Affiliate's, RA's, subcontractor's, and Enterprise RA's compliance with these Requirements on an annual basis. +In all cases, the CA MUST contractually obligate each Affiliate, RA, subcontractor, and Enterprise RA to comply with all applicable requirements in these Guidelines and to perform them as required of the CA itself. The CA SHALL enforce these obligations and internally audit each Affiliate's, RA's, subcontractor's, and Enterprise RA's compliance with these Requirements on an annual basis. #### 1.3.2.1 Enterprise Registration authorities -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: +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 @@ -144,7 +144,7 @@ The primary purposes of an EV Certificate are to: #### 1.4.1.2 Secondary Purposes -The secondary purposes of an EV Certificate are to help establish the legitimacy of a business claiming to operate a Web site, and to provide a vehicle that can be used to assist in addressing problems related to phishing, and other forms of online identity fraud. By providing more reliable third-party verified identity and address information regarding the business, EV Certificates may help to: +The secondary purposes of an EV Certificate are to help establish the legitimacy of a business claiming to operate a Web site, and to provide a vehicle that can be used to assist in addressing problems related to phishing, and other forms of online identity fraud. By providing more reliable third-party verified identity and address information regarding the business, EV Certificates may help to: 1. Make it more difficult to mount phishing and other online identity fraud attacks using Certificates; 2. Assist companies that may be the target of phishing attacks or online identity fraud by providing them with a tool to better identify themselves to users; and @@ -152,7 +152,7 @@ The secondary purposes of an EV Certificate are to help establish the legitimacy ### 1.4.2 Prohibited certificate uses -EV Certificates focus only on the identity of the Subject named in the Certificate, and not on the behavior of the Subject. As such, an EV Certificate is **not** intended to provide any assurances, or otherwise represent or warrant: +EV Certificates focus only on the identity of the Subject named in the Certificate, and not on the behavior of the Subject. As such, an EV Certificate is **not** intended to provide any assurances, or otherwise represent or warrant: 1. That the Subject named in the EV Certificate is actively engaged in doing business; 2. That the Subject named in the EV Certificate complies with applicable laws; @@ -194,7 +194,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Contract Signer**: A natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements. -**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. +**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. **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. @@ -215,17 +215,17 @@ Capitalized Terms are defined in the Baseline Requirements except where provided i. indicates which CA policy statement relates to that certificate, and ii. is either the CA/Browser Forum EV policy identifier or a policy identifier that, by pre-agreement with one or more Application Software Supplier, marks the certificate as being an EV Certificate. -**EV Policies**: Auditable EV Certificate practices, policies and procedures, such as a certification practice statement and certificate policy, that are developed, implemented, and enforced by the CA and its Root CA. +**EV Policies**: Auditable EV Certificate practices, policies and procedures, such as a certification practice statement and certificate policy, that are developed, implemented, and enforced by the CA and its Root CA. **EV Processes**: The keys, software, processes, and procedures by which the CA verifies Certificate Data under this Guideline, issues EV Certificates, maintains a Repository, and revokes EV Certificates. **Extended Validation Certificate**: See EV Certificate. -**Government Agency**: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of Private Organizations is established (e.g., the government agency that issued the Certificate of Incorporation). In the context of Business Entities, the government agency in the jurisdiction of operation that registers business entities. In the case of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities. +**Government Agency**: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of Private Organizations is established (e.g., the government agency that issued the Certificate of Incorporation). In the context of Business Entities, the government agency in the jurisdiction of operation that registers business entities. In the case of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities. **Guidelines**: This document. -**Incorporating Agency**: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of the entity is registered (e.g., the government agency that issues certificates of formation or incorporation). In the context of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities. +**Incorporating Agency**: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of the entity is registered (e.g., the government agency that issues certificates of formation or incorporation). In the context of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities. **Independent Confirmation From Applicant**: Confirmation of a particular fact received by the CA pursuant to the provisions of the Guidelines or binding upon the Applicant. @@ -233,7 +233,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **International Organization**: An organization founded by a constituent document, e.g., a charter, treaty, convention or similar document, signed by, or on behalf of, a minimum of two Sovereign State governments. -**Jurisdiction of Incorporation**: In the context of a Private Organization, the country and (where applicable) the state or province or locality where the organization's legal existence was established by a filing with (or an act of) an appropriate government agency or entity (e.g., where it was incorporated). In the context of a Government Entity, the country and (where applicable) the state or province where the Entity's legal existence was created by law. +**Jurisdiction of Incorporation**: In the context of a Private Organization, the country and (where applicable) the state or province or locality where the organization's legal existence was established by a filing with (or an act of) an appropriate government agency or entity (e.g., where it was incorporated). In the context of a Government Entity, the country and (where applicable) the state or province where the Entity's legal existence was created by law. **Jurisdiction of Registration**: In the case of a Business Entity, the state, province, or locality where the organization has registered its business presence by means of filings by a Principal Individual involved in the business. @@ -266,7 +266,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Qualified Independent Information Source**: A regularly-updated and current, publicly available, database designed for the purpose of accurately providing the information for which it is consulted, and which is generally recognized as a dependable source of such information. -**Registration Agency**: A Governmental Agency that registers business information in connection with an entity's business formation or authorization to conduct business under a license, charter or other certification. A Registration Agency MAY include, but is not limited to +**Registration Agency**: A Governmental Agency that registers business information in connection with an entity's business formation or authorization to conduct business under a license, charter or other certification. A Registration Agency MAY include, but is not limited to i. a State Department of Corporations or a Secretary of State; ii. a licensing agency, such as a State Department of Insurance; or @@ -353,14 +353,14 @@ By convention, this document omits time and timezones when listing effective req Each CA must develop, implement, enforce, display prominently on its Web site, and periodically update as necessary its own auditable EV Certificate practices, policies and procedures, such as a Certification Practice Statement (CPS) and Certificate Policy (CP) that: -A. Implement the requirements of these Guidelines as they are revised from time-to-time; +A. Implement the requirements of these Guidelines as they are revised from time-to-time; -B. Implement the requirements of +B. Implement the requirements of i. the then-current WebTrust Program for CAs, and ii. the then-current WebTrust EV Program or ETSI TS 102 042 for EVCP or ETSI EN 319 411-1 for EVCP policy; and -C. Specify the CA's and its Root CA's entire root certificate hierarchy including all roots that its EV Certificates depend on for proof of those EV Certificates' authenticity. +C. Specify the CA's and its Root CA's entire root certificate hierarchy including all roots that its EV Certificates depend on for proof of those EV Certificates' authenticity. ## 2.1 Repositories @@ -372,9 +372,9 @@ The CA's Certificate Policy and/or Certification Practice Statement MUST be stru Each CA SHALL publicly give effect to these Guidelines and represent that they will adhere to the latest published version by incorporating them into their respective EV Policies, using a clause such as the following (which must include a link to the official version of these Guidelines): -> [Name of CA] conforms to the current version of the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates published at . In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document. +> [Name of CA] conforms to the current version of the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates published at . In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document. -In addition, the CA MUST include (directly or by reference) the applicable requirements of these Guidelines in all contracts with Subordinate CAs, RAs, Enterprise RAs, and subcontractors that involve or relate to the issuance or maintenance of EV Certificates. The CA MUST enforce compliance with such terms. +In addition, the CA MUST include (directly or by reference) the applicable requirements of these Guidelines in all contracts with Subordinate CAs, RAs, Enterprise RAs, and subcontractors that involve or relate to the issuance or maintenance of EV Certificates. The CA MUST enforce compliance with such terms. ## 2.3 Time or frequency of publication @@ -412,25 +412,27 @@ Before issuing an EV Certificate, the CA MUST ensure that all Subject organizati 1. Verify Applicant's existence and identity, including; - A. Verify the Applicant's legal existence and identity (as more fully set forth in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity)), + A. Verify the Applicant's legal existence and identity (as more fully set forth in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity)), - B. Verify the Applicant's physical existence (business presence at a physical address), and + B. Verify the Applicant's physical existence (business presence at a physical address), and - C. Verify the Applicant's operational existence (business activity). + C. Verify the Applicant's operational existence (business activity). 2. Verify the Applicant is a registered holder, or has control, of the Domain Name(s) to be included in the EV Certificate; + 3. Verify a reliable means of communication with the entity to be named as the Subject in the Certificate; + 4. Verify the Applicant's authorization for the EV Certificate, including; - A. Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester, + A. Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester, - B. Verify that a Contract Signer signed the Subscriber Agreement or that a duly authorized Applicant Representative acknowledged and agreed to the Terms of Use; and + B. Verify that a Contract Signer signed the Subscriber Agreement or that a duly authorized Applicant Representative acknowledged and agreed to the Terms of Use; and - C. Verify that a Certificate Approver has signed or otherwise approved the EV Certificate Request. + C. Verify that a Certificate Approver has signed or otherwise approved the EV Certificate Request. ##### 3.2.2.1.2 Acceptable Methods of Verification – Overview -As a general rule, the CA is responsible for taking all verification steps reasonably necessary to satisfy each of the Verification Requirements set forth in the subsections below. The Acceptable Methods of Verification set forth in each of Sections 3.2.2 through 3.2.14 (which usually include alternatives) are considered to be the minimum acceptable level of verification required of the CA. In all cases, however, the CA is responsible for taking any additional verification steps that may be reasonably necessary under the circumstances to satisfy the applicable Verification Requirement. +As a general rule, the CA is responsible for taking all verification steps reasonably necessary to satisfy each of the Verification Requirements set forth in the subsections below. The Acceptable Methods of Verification set forth in each of Sections 3.2.2 through 3.2.14 (which usually include alternatives) are considered to be the minimum acceptable level of verification required of the CA. In all cases, however, the CA is responsible for taking any additional verification steps that may be reasonably necessary under the circumstances to satisfy the applicable Verification Requirement. ##### 3.2.2.1.3 Disclosure of Verification Sources @@ -438,10 +440,10 @@ Effective as of 1 October 2020, prior to the use of an Incorporating Agency or R This Agency Information SHALL include at least the following: -- Sufficient information to unambiguously identify the Incorporating Agency or Registration Agency (such as a name, jurisdiction, and website); and, -- The accepted value or values for each of the `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1), `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2), and `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) fields, when a certificate is issued using information from that Incorporating Agency or Registration Agency, indicating the jurisdiction(s) that the Agency is appropriate for; and, -- The acceptable form or syntax of Registration Numbers used by the Incorporating Agency or Registration Agency, if the CA restricts such Numbers to an acceptable form or syntax; and, -- A revision history that includes a unique version number and date of publication for any additions, modifications, and/or removals from this list. +* Sufficient information to unambiguously identify the Incorporating Agency or Registration Agency (such as a name, jurisdiction, and website); and, +* The accepted value or values for each of the `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1), `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2), and `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) fields, when a certificate is issued using information from that Incorporating Agency or Registration Agency, indicating the jurisdiction(s) that the Agency is appropriate for; and, +* The acceptable form or syntax of Registration Numbers used by the Incorporating Agency or Registration Agency, if the CA restricts such Numbers to an acceptable form or syntax; and, +* A revision history that includes a unique version number and date of publication for any additions, modifications, and/or removals from this list. The CA MUST document where to obtain this information within Section 3.2 of the CA's Certificate Policy and/or Certification Practice Statement. @@ -452,28 +454,30 @@ The CA MUST document where to obtain this information within Section 3.2 of the To verify the Applicant's legal existence and identity, the CA MUST do the following. 1. **Private Organization Subjects** - A. **Legal Existence**: Verify that the Applicant is a legally recognized entity, in existence and validly formed (e.g., incorporated) with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration, and not designated on the records of the Incorporating or Registration Agency by labels such as "inactive", "invalid", "not current", or the equivalent. - B. **Organization Name**: Verify that the Applicant's formal legal name as recorded with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: Obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Incorporation or Registration. - D. **Registered Agent**: Obtain the identity and address of the Applicant's Registered Agent or Registered Office (as applicable in the Applicant's Jurisdiction of Incorporation or Registration). + + A. **Legal Existence**: Verify that the Applicant is a legally recognized entity, in existence and validly formed (e.g., incorporated) with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration, and not designated on the records of the Incorporating or Registration Agency by labels such as "inactive", "invalid", "not current", or the equivalent. + B. **Organization Name**: Verify that the Applicant's formal legal name as recorded with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration matches the Applicant's name in the EV Certificate Request. + C. **Registration Number**: Obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Incorporation or Registration. + D. **Registered Agent**: Obtain the identity and address of the Applicant's Registered Agent or Registered Office (as applicable in the Applicant's Jurisdiction of Incorporation or Registration). 2. **Government Entity Subjects** - A. **Legal Existence**: Verify that the Applicant is a legally recognized Government Entity, in existence in the political subdivision in which such Government Entity operates. - B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of incorporation, registration, or formation, or the identifier for the legislative act that created the Government Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is a Government Entity. + + A. **Legal Existence**: Verify that the Applicant is a legally recognized Government Entity, in existence in the political subdivision in which such Government Entity operates. + B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. + C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of incorporation, registration, or formation, or the identifier for the legislative act that created the Government Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is a Government Entity. 3. **Business Entity Subjects** - A. **Legal Existence**: Verify that the Applicant is engaged in business under the name submitted by the Applicant in the Application. - B. **Organization Name**: Verify that the Applicant's formal legal name as recognized by the Registration Agency in the Applicant's Jurisdiction of Registration matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: Attempt to obtain the specific unique Registration Number assigned to the Applicant by the Registration Agency in the Applicant's Jurisdiction of Registration. Where the Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Registration. - D. **Principal Individual**: Verify the identity of the identified Principal Individual. + A. **Legal Existence**: Verify that the Applicant is engaged in business under the name submitted by the Applicant in the Application. + B. **Organization Name**: Verify that the Applicant's formal legal name as recognized by the Registration Agency in the Applicant's Jurisdiction of Registration matches the Applicant's name in the EV Certificate Request. + C. **Registration Number**: Attempt to obtain the specific unique Registration Number assigned to the Applicant by the Registration Agency in the Applicant's Jurisdiction of Registration. Where the Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Registration. + D. **Principal Individual**: Verify the identity of the identified Principal Individual. 4. **Non-Commercial Entity Subjects (International Organizations)** - A. **Legal Existence**: Verify that the Applicant is a legally recognized International Organization Entity. - B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of formation, or the identifier for the legislative act that created the International Organization Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is an International Organization Entity. + A. **Legal Existence**: Verify that the Applicant is a legally recognized International Organization Entity. + B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. + C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of formation, or the identifier for the legislative act that created the International Organization Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is an International Organization Entity. ##### 3.2.2.2.2 Acceptable Method of Verification @@ -490,9 +494,9 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo 3. **Business Entity Subjects**: Unless verified under subsection (6), Items listed in [Section 3.2.2.2.1](#32221-verification-requirements) (3) (A) through (C) above, MUST be verified directly with, or obtained directly from, the Registration Agency in the Applicant's Jurisdiction of Registration. Such verification MAY be performed by means of a Qualified Government Information Source, a Qualified Governmental Tax Information Source, or by direct contact with the Registration Agency in person or via mail, e-mail, Web address, or telephone, using an address or phone number obtained directly from the Qualified Government Information Source, Qualified Governmental Tax Information Source or Registration Agency, or from a Qualified Independent Information Source. In addition, the CA MUST validate a Principal Individual associated with the Business Entity pursuant to the requirements in subsection (4), below. -4. **Principal Individual**: A Principal Individual associated with the Business Entity MUST be validated in a face-to-face setting. The CA MAY rely upon a face-to-face validation of the Principal Individual performed by the Registration Agency, provided that the CA has evaluated the validation procedure and concluded that it satisfies the requirements of the Guidelines for face-to-face validation procedures. Where no face-to-face validation was conducted by the Registration Agency, or the Registration Agency's face-to-face validation procedure does not satisfy the requirements of the Guidelines, the CA SHALL perform face-to-face validation. +4. **Principal Individual**: A Principal Individual associated with the Business Entity MUST be validated in a face-to-face setting. The CA MAY rely upon a face-to-face validation of the Principal Individual performed by the Registration Agency, provided that the CA has evaluated the validation procedure and concluded that it satisfies the requirements of the Guidelines for face-to-face validation procedures. Where no face-to-face validation was conducted by the Registration Agency, or the Registration Agency's face-to-face validation procedure does not satisfy the requirements of the Guidelines, the CA SHALL perform face-to-face validation. - A. **Face-To-Face Validation**: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicant's jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator: + A. **Face-To-Face Validation**: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicant's jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator: i. A Personal Statement that includes the following information: @@ -529,21 +533,21 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo The Third-Party Validator performing the face-to-face validation MUST: i. Attest to the signing of the Personal Statement and the identity of the signer; and - ii. Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original. + ii. Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original. B. **Verification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant's jurisdiction), lawyer, or accountant in the jurisdiction of the Individual's residency, and that the Third-Party Validator actually did perform the services and did attest to the signature of the Individual. - C. **Cross-checking of Information**: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that: + C. **Cross-checking of Information**: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that: i. the CA confirms their authenticity (not improperly modified when compared with the underlying original) with the Third-Party Validator; and ii. electronic copies of similar kinds of documents are recognized as legal substitutes for originals under the laws of the CA's jurisdiction. 5. **Non-Commercial Entity Subjects (International Organization)**: Unless verified under subsection (6), all items listed in [Section 3.2.2.2.1](#32221-verification-requirements) (4) MUST be verified either: - A. With reference to the constituent document under which the International Organization was formed; or - B. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or - C. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at . - D. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency. + A. With reference to the constituent document under which the International Organization was formed; or + B. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or + C. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at . + D. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency. 6. The CA may rely on a Verified Professional Letter to establish the Applicant's information listed in (1)-(5) above if: @@ -565,7 +569,7 @@ To verify any assumed name under which the Applicant conducts business: 1. The CA MAY verify the assumed name through use of a Qualified Government Information Source operated by, or on behalf of, an appropriate government agency in the jurisdiction of the Applicant's Place of Business, or by direct contact with such government agency in person or via mail, e-mail, Web address, or telephone; or 2. The CA MAY verify the assumed name through use of a Qualified Independent Information Source provided that the QIIS has verified the assumed name with the appropriate government agency. -3. The CA MAY rely on a Verified Professional Letter that indicates the assumed name under which the Applicant conducts business, the government agency with which the assumed name is registered, and that such filing continues to be valid. +3. The CA MAY rely on a Verified Professional Letter that indicates the assumed name under which the Applicant conducts business, the government agency with which the assumed name is registered, and that such filing continues to be valid. #### 3.2.2.4 Verification of Applicant's Physical Existence @@ -575,13 +579,13 @@ To verify any assumed name under which the Applicant conducts business: 2. **Acceptable Methods of Verification** - A. **Place of Business in the Country of Incorporation or Registration** + A. **Place of Business in the Country of Incorporation or Registration** i. For Applicants whose Place of Business is in the same country as the Applicant's Jurisdiction of Incorporation or Registration and whose Place of Business is NOT the same as that indicated in the relevant Qualified Government Information Source used in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) to verify legal existence: 1. For Applicants listed at the same Place of Business address in the current version of either at least one QGIS (other than that used to verify legal existence), QIIS or QTIS, the CA MUST confirm that the Applicant's address, as listed in the EV Certificate Request, is a valid business address for the Applicant or a Parent/Subsidiary Company by reference to such QGIS, QIIS, or QTIS, and MAY rely on the Applicant's representation that such address is its Place of Business; - 2. For Applicants who are not listed at the same Place of Business address in the current version of either at least one QIIS or QTIS, the CA MUST confirm that the address provided by the Applicant in the EV Certificate Request is the Applicant's or a Parent/Subsidiary Company's business address, by obtaining documentation of a site visit to the business address, which MUST be performed by a reliable individual or firm. The documentation of the site visit MUST: + 2. For Applicants who are not listed at the same Place of Business address in the current version of either at least one QIIS or QTIS, the CA MUST confirm that the address provided by the Applicant in the EV Certificate Request is the Applicant's or a Parent/Subsidiary Company's business address, by obtaining documentation of a site visit to the business address, which MUST be performed by a reliable individual or firm. The documentation of the site visit MUST: a. Verify that the Applicant's business is located at the exact address stated in the EV Certificate Request (e.g., via permanent signage, employee confirmation, etc.), b. Identify the type of facility (e.g., office in a commercial building, private residence, storefront, etc.) and whether it appears to be a permanent business location, @@ -595,7 +599,7 @@ To verify any assumed name under which the Applicant conducts business: iii. For Government Entity Applicants, the CA MAY rely on the address contained in the records of the QGIS in the Applicant's jurisdiction. iv. For Applicants whose Place of Business is in the same country as the Applicant's Jurisdiction of Incorporation or Registration and where the QGIS used in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) to verify legal existence contains a business address for the Applicant, the CA MAY rely on the address in the QGIS to confirm the Applicant's or a Parent/Subsidiary Company's address as listed in the EV Certificate Request, and MAY rely on the Applicant's representation that such address is its Place of Business. - B. **Place of Business not in the Country of Incorporation or Registration**: The CA MUST rely on a Verified Professional Letter that indicates the address of the Applicant's Place of Business and that business operations are conducted there. + B. **Place of Business not in the Country of Incorporation or Registration**: The CA MUST rely on a Verified Professional Letter that indicates the address of the Applicant's Place of Business and that business operations are conducted there. #### 3.2.2.5 Verified Method of Communication @@ -607,19 +611,19 @@ To assist in communicating with the Applicant and confirming that the Applicant To verify a Verified Method of Communication with the Applicant, the CA MUST: -A. Verify that the Verified Method of Communication belongs to the Applicant, or a Parent/Subsidiary or Affiliate of the Applicant, by matching it with one of the Applicant's Parent/Subsidiary or Affiliate's Places of Business in: +A. Verify that the Verified Method of Communication belongs to the Applicant, or a Parent/Subsidiary or Affiliate of the Applicant, by matching it with one of the Applicant's Parent/Subsidiary or Affiliate's Places of Business in: i. records provided by the applicable phone company; ii. a QGIS, QTIS, or QIIS; or iii. a Verified Professional Letter; and -B. Confirm the Verified Method of Communication by using it to obtain an affirmative response sufficient to enable a reasonable person to conclude that the Applicant, or a Parent/Subsidiary or Affiliate of Applicant, can be contacted reliably by using the Verified Method of Communication. +B. Confirm the Verified Method of Communication by using it to obtain an affirmative response sufficient to enable a reasonable person to conclude that the Applicant, or a Parent/Subsidiary or Affiliate of Applicant, can be contacted reliably by using the Verified Method of Communication. #### 3.2.2.6 Verification of Applicant's Operational Existence ##### 3.2.2.6.1 Verification Requirements -The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) as verification of a Government Entity's operational existence. +The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) as verification of a Government Entity's operational existence. ##### 3.2.2.6.2 Acceptable Methods of Verification @@ -639,7 +643,7 @@ To verify the Applicant's ability to engage in business, the CA MUST verify the 1. For each Fully-Qualified Domain Name listed in a Certificate which is not an Onion Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 3.2.2.4 of the Baseline Requirements. For a Certificate issued to an Onion Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the Onion Domain Name in accordance with Appendix B of the Baseline Requirements. -2. **Mixed Character Set Domain Names**: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. +2. **Mixed Character Set Domain Names**: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. #### 3.2.2.8 Verification of Name, Title, and Authority of Contract Signer and Certificate Approver @@ -647,13 +651,13 @@ To verify the Applicant's ability to engage in business, the CA MUST verify the For both the Contract Signer and the Certificate Approver, the CA MUST verify the following. -1. **Name, Title and Agency**: The CA MUST verify the name and title of the Contract Signer and the Certificate Approver, as applicable. The CA MUST also verify that the Contract Signer and the Certificate Approver are agents representing the Applicant. +1. **Name, Title and Agency**: The CA MUST verify the name and title of the Contract Signer and the Certificate Approver, as applicable. The CA MUST also verify that the Contract Signer and the Certificate Approver are agents representing the Applicant. 2. **Signing Authority of Contract Signer**: The CA MUST verify that the Contract Signer is authorized by the Applicant to enter into the Subscriber Agreement (and any other relevant contractual obligations) on behalf of the Applicant, including a contract that designates one or more Certificate Approvers on behalf of the Applicant. 3. **EV Authority of Certificate Approver**: The CA MUST verify, through a source other than the Certificate Approver him- or herself, that the Certificate Approver is expressly authorized by the Applicant to do the following, as of the date of the EV Certificate Request: - A. Submit, and, if applicable, authorize a Certificate Requester to submit, the EV Certificate Request on behalf of the Applicant; and - B. Provide, and, if applicable, authorize a Certificate Requester to provide, the information requested from the Applicant by the CA for issuance of the EV Certificate; and - C. Approve EV Certificate Requests submitted by a Certificate Requester. + A. Submit, and, if applicable, authorize a Certificate Requester to submit, the EV Certificate Request on behalf of the Applicant; and + B. Provide, and, if applicable, authorize a Certificate Requester to provide, the information requested from the Applicant by the CA for issuance of the EV Certificate; and + C. Approve EV Certificate Requests submitted by a Certificate Requester. ##### 3.2.2.8.2 Acceptable Methods of Verification – Name, Title and Agency @@ -663,9 +667,9 @@ Acceptable methods of verification of the name, title, and agency status of the 2. **Agency**: The CA MAY verify the agency of the Contract Signer and the Certificate Approver by: - A. Contacting the Applicant using a Verified Method of Communication for the Applicant, and obtaining confirmation that the Contract Signer and/or the Certificate Approver, as applicable, is an employee; - B. Obtaining an Independent Confirmation From the Applicant (as described in [Section 3.2.2.11.4](#322114-independent-confirmation-from-applicant)), or a Verified Professional Letter verifying that the Contract Signer and/or the Certificate Approver, as applicable, is either an employee or has otherwise been appointed as an agent of the Applicant; or - C. Obtaining confirmation from a QIIS or QGIS that the Contract Signer and/or Certificate Approver is an employee of the Applicant. + A. Contacting the Applicant using a Verified Method of Communication for the Applicant, and obtaining confirmation that the Contract Signer and/or the Certificate Approver, as applicable, is an employee; + B. Obtaining an Independent Confirmation From the Applicant (as described in [Section 3.2.2.11.4](#322114-independent-confirmation-from-applicant)), or a Verified Professional Letter verifying that the Contract Signer and/or the Certificate Approver, as applicable, is either an employee or has otherwise been appointed as an agent of the Applicant; or + C. Obtaining confirmation from a QIIS or QGIS that the Contract Signer and/or Certificate Approver is an employee of the Applicant. The CA MAY also verify the agency of the Certificate Approver via a certification from the Contract Signer (including in a contract between the CA and the Applicant signed by the Contract Signer), provided that the employment or agency status and Signing Authority of the Contract Signer has been verified. @@ -683,27 +687,27 @@ Acceptable methods of verification of the Signing Authority of the Contract Sign 4. **Contract between CA and Applicant**: The EV Authority of the Certificate Approver MAY be verified by reliance on a contract between the CA and the Applicant that designates the Certificate Approver with such EV Authority, provided that the contract is signed by the Contract Signer and provided that the agency and Signing Authority of the Contract Signer have been verified; 5. **Prior Equivalent Authority**: The signing authority of the Contract Signer, and/or the EV authority of the Certificate Approver, MAY be verified by relying on a demonstration of Prior Equivalent Authority. - A. Prior Equivalent Authority of a Contract Signer MAY be relied upon for confirmation or verification of the signing authority of the Contract Signer when the Contract Signer has executed a binding contract between the CA and the Applicant with a legally valid and enforceable seal or handwritten signature and only when the contract was executed more than 90 days prior to the EV Certificate application. The CA MUST record sufficient details of the previous agreement to correctly identify it and associate it with the EV application. Such details MAY include any of the following: + A. Prior Equivalent Authority of a Contract Signer MAY be relied upon for confirmation or verification of the signing authority of the Contract Signer when the Contract Signer has executed a binding contract between the CA and the Applicant with a legally valid and enforceable seal or handwritten signature and only when the contract was executed more than 90 days prior to the EV Certificate application. The CA MUST record sufficient details of the previous agreement to correctly identify it and associate it with the EV application. Such details MAY include any of the following: i. Agreement title, ii. Date of Contract Signer's signature, iii. Contract reference number, and iv. Filing location. - B. Prior Equivalent Authority of a Certificate Approver MAY be relied upon for confirmation or verification of the EV Authority of the Certificate Approver when the Certificate Approver has performed one or more of the following: + B. Prior Equivalent Authority of a Certificate Approver MAY be relied upon for confirmation or verification of the EV Authority of the Certificate Approver when the Certificate Approver has performed one or more of the following: i. Under contract to the CA, has served (or is serving) as an Enterprise RA for the Applicant, or - ii. Has participated in the approval of one or more certificate requests, for certificates issued by the CA and which are currently and verifiably in use by the Applicant. In this case the CA MUST have contacted the Certificate Approver by phone at a previously validated phone number or have accepted a signed and notarized letter approving the certificate request. + ii. Has participated in the approval of one or more certificate requests, for certificates issued by the CA and which are currently and verifiably in use by the Applicant. In this case the CA MUST have contacted the Certificate Approver by phone at a previously validated phone number or have accepted a signed and notarized letter approving the certificate request. 6. **QIIS or QGIS**: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by a QIIS or QGIS that identifies the Contract Signer and/or the Certificate Approver as a corporate officer, sole proprietor, or other senior official of the Applicant. 7. **Contract Signer's Representation/Warranty**: Provided that the CA verifies that the Contract Signer is an employee or agent of the Applicant, the CA MAY rely on the signing authority of the Contract Signer by obtaining a duly executed representation or warranty from the Contract Signer that includes the following acknowledgments: - A. That the Applicant authorizes the Contract Signer to sign the Subscriber Agreement on the Applicant's behalf, - B. That the Subscriber Agreement is a legally valid and enforceable agreement, - C. That, upon execution of the Subscriber Agreement, the Applicant will be bound by all of its terms and conditions, - D. That serious consequences attach to the misuse of an EV certificate, and - E. The contract signer has the authority to obtain the digital equivalent of a corporate seal, stamp or officer's signature to establish the authenticity of the company's Web site. + A. That the Applicant authorizes the Contract Signer to sign the Subscriber Agreement on the Applicant's behalf, + B. That the Subscriber Agreement is a legally valid and enforceable agreement, + C. That, upon execution of the Subscriber Agreement, the Applicant will be bound by all of its terms and conditions, + D. That serious consequences attach to the misuse of an EV certificate, and + E. The contract signer has the authority to obtain the digital equivalent of a corporate seal, stamp or officer's signature to establish the authenticity of the company's Web site. Note: An example of an acceptable representation/warranty appears in [Appendix E](#appendix-e---sample-contract-signers-representationwarranty-informative). @@ -726,7 +730,7 @@ Such an agreement MUST provide that the Applicant shall be obligated under the S #### 3.2.2.9 Verification of Signature on Subscriber Agreement and EV Certificate Requests -Both the Subscriber Agreement and each non-pre-authorized EV Certificate Request MUST be signed. The Subscriber Agreement MUST be signed by an authorized Contract Signer. The EV Certificate Request MUST be signed by the Certificate Requester submitting the document, unless the Certificate Request has been pre-authorized in line with [Section 3.2.2.8.4](#32284-pre-authorized-certificate-approver). If the Certificate Requester is not also an authorized Certificate Approver, then an authorized Certificate Approver MUST independently approve the EV Certificate Request. In all cases, applicable signatures MUST be a legally valid and contain an enforceable seal or handwritten signature (for a paper Subscriber Agreement and/or EV Certificate Request), or a legally valid and enforceable electronic signature (for an electronic Subscriber Agreement and/or EV Certificate Request), that binds the Applicant to the terms of each respective document. +Both the Subscriber Agreement and each non-pre-authorized EV Certificate Request MUST be signed. The Subscriber Agreement MUST be signed by an authorized Contract Signer. The EV Certificate Request MUST be signed by the Certificate Requester submitting the document, unless the Certificate Request has been pre-authorized in line with [Section 3.2.2.8.4](#32284-pre-authorized-certificate-approver). If the Certificate Requester is not also an authorized Certificate Approver, then an authorized Certificate Approver MUST independently approve the EV Certificate Request. In all cases, applicable signatures MUST be a legally valid and contain an enforceable seal or handwritten signature (for a paper Subscriber Agreement and/or EV Certificate Request), or a legally valid and enforceable electronic signature (for an electronic Subscriber Agreement and/or EV Certificate Request), that binds the Applicant to the terms of each respective document. ##### 3.2.2.9.1 Verification Requirements @@ -766,19 +770,19 @@ Acceptable methods of verifying the Certificate Approver's approval of an EV Cer 1. **Verification Requirements**: Before relying on a legal opinion submitted to the CA, the CA MUST verify that such legal opinion meets the following requirements: - A. **Status of Author**: The CA MUST verify that the legal opinion is authored by an independent legal practitioner retained by and representing the Applicant (or an in-house legal practitioner employed by the Applicant) (Legal Practitioner) who is either: + A. **Status of Author**: The CA MUST verify that the legal opinion is authored by an independent legal practitioner retained by and representing the Applicant (or an in-house legal practitioner employed by the Applicant) (Legal Practitioner) who is either: i. A lawyer (or solicitor, barrister, advocate, or equivalent) licensed to practice law in the country of the Applicant's Jurisdiction of Incorporation or Registration or any jurisdiction where the Applicant maintains an office or physical facility, or ii. A Latin Notary who is currently commissioned or licensed to practice in the country of the Applicant's Jurisdiction of Incorporation or Registration or any jurisdiction where the Applicant maintains an office or physical facility (and that such jurisdiction recognizes the role of the Latin Notary); - B. **Basis of Opinion**: The CA MUST verify that the Legal Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Legal Opinion are based on the Legal Practitioner's stated familiarity with the relevant facts and the exercise of the Legal Practitioner's professional judgment and expertise; - C. **Authenticity**: The CA MUST confirm the authenticity of the Verified Legal Opinion. + B. **Basis of Opinion**: The CA MUST verify that the Legal Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Legal Opinion are based on the Legal Practitioner's stated familiarity with the relevant facts and the exercise of the Legal Practitioner's professional judgment and expertise; + C. **Authenticity**: The CA MUST confirm the authenticity of the Verified Legal Opinion. 2. **Acceptable Methods of Verification**: Acceptable methods of establishing the foregoing requirements for a Verified Legal Opinion are: - A. **Status of Author**: The CA MUST verify the professional status of the author of the legal opinion by directly contacting the authority responsible for registering or licensing such Legal Practitioner(s) in the applicable jurisdiction; - B. **Basis of Opinion**: The text of the legal opinion MUST make it clear that the Legal Practitioner is acting on behalf of the Applicant and that the conclusions of the legal opinion are based on the Legal Practitioner's stated familiarity with the relevant facts and the exercise of the practitioner's professional judgment and expertise. The legal opinion MAY also include disclaimers and other limitations customary in the Legal Practitioner's jurisdiction, provided that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Legal Practitioner, should the legal opinion prove to be erroneous. An acceptable form of legal opinion is attached as [Appendix B](#appendix-b---sample-attorney-opinions-confirming-specified-information); - C. **Authenticity**: To confirm the authenticity of the legal opinion, the CA MUST make a telephone call or send a copy of the legal opinion back to the Legal Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Legal Practitioner listed with the authority responsible for registering or licensing such Legal Practitioner, and obtain confirmation from the Legal Practitioner or the Legal Practitioner's assistant that the legal opinion is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Legal Practitioner in records provided by the applicable phone company, QGIS, or QIIS. + A. **Status of Author**: The CA MUST verify the professional status of the author of the legal opinion by directly contacting the authority responsible for registering or licensing such Legal Practitioner(s) in the applicable jurisdiction; + B. **Basis of Opinion**: The text of the legal opinion MUST make it clear that the Legal Practitioner is acting on behalf of the Applicant and that the conclusions of the legal opinion are based on the Legal Practitioner's stated familiarity with the relevant facts and the exercise of the practitioner's professional judgment and expertise. The legal opinion MAY also include disclaimers and other limitations customary in the Legal Practitioner's jurisdiction, provided that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Legal Practitioner, should the legal opinion prove to be erroneous. An acceptable form of legal opinion is attached as [Appendix B](#appendix-b---sample-attorney-opinions-confirming-specified-information); + C. **Authenticity**: To confirm the authenticity of the legal opinion, the CA MUST make a telephone call or send a copy of the legal opinion back to the Legal Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Legal Practitioner listed with the authority responsible for registering or licensing such Legal Practitioner, and obtain confirmation from the Legal Practitioner or the Legal Practitioner's assistant that the legal opinion is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Legal Practitioner in records provided by the applicable phone company, QGIS, or QIIS. In circumstances where the opinion is digitally signed, in a manner that confirms the authenticity of the document and the identity of the signer, as verified by the CA in [Section 3.2.2.11.1](#322111-verified-legal-opinion) (2)(A), no further verification of authenticity is required. @@ -786,15 +790,15 @@ Acceptable methods of verifying the Certificate Approver's approval of an EV Cer 1. **Verification Requirements**: Before relying on an accountant letter submitted to the CA, the CA MUST verify that such accountant letter meets the following requirements: - A. **Status of Author**: The CA MUST verify that the accountant letter is authored by an Accounting Practitioner retained or employed by the Applicant and licensed within the country of the Applicant's Jurisdiction of Incorporation, Jurisdiction of Registration, or country where the Applicant maintains an office or physical facility. Verification of license MUST be through the member organization or regulatory organization in the Accounting Practitioner's country or jurisdiction that is appropriate to contact when verifying an accountant's license to practice in that country or jurisdiction. Such country or jurisdiction must have an accounting standards body that maintains full membership status with the International Federation of Accountants. - B. **Basis of Opinion**: The CA MUST verify that the Accounting Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Accountant Letter are based on the Accounting Practitioner's stated familiarity with the relevant facts and the exercise of the Accounting Practitioner's professional judgment and expertise; - C. **Authenticity**: The CA MUST confirm the authenticity of the Verified Accountant Letter. + A. **Status of Author**: The CA MUST verify that the accountant letter is authored by an Accounting Practitioner retained or employed by the Applicant and licensed within the country of the Applicant's Jurisdiction of Incorporation, Jurisdiction of Registration, or country where the Applicant maintains an office or physical facility. Verification of license MUST be through the member organization or regulatory organization in the Accounting Practitioner's country or jurisdiction that is appropriate to contact when verifying an accountant's license to practice in that country or jurisdiction. Such country or jurisdiction must have an accounting standards body that maintains full membership status with the International Federation of Accountants. + B. **Basis of Opinion**: The CA MUST verify that the Accounting Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Accountant Letter are based on the Accounting Practitioner's stated familiarity with the relevant facts and the exercise of the Accounting Practitioner's professional judgment and expertise; + C. **Authenticity**: The CA MUST confirm the authenticity of the Verified Accountant Letter. 2. **Acceptable Methods of Verification**: Acceptable methods of establishing the foregoing requirements for a Verified Accountant Letter are listed here. - A. **Status of Author**: The CA MUST verify the professional status of the author of the accountant letter by directly contacting the authority responsible for registering or licensing such Accounting Practitioners in the applicable jurisdiction. - B. **Basis of Opinion**: The text of the Verified Accountant Letter MUST make clear that the Accounting Practitioner is acting on behalf of the Applicant and that the information in the letter is based on the Accounting Practitioner's stated familiarity with the relevant facts and the exercise of the practitioner's professional judgment and expertise. The Verified Accountant Letter MAY also include disclaimers and other limitations customary in the Accounting Practitioner's jurisdiction, provided that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Accounting Practitioner, should the Verified Accountant Letter prove to be erroneous. Acceptable forms of Verified Accountant Letter are attached as [Appendix C](#appendix-c---sample-accountant-letters-confirming-specified-information). - C. **Authenticity**: To confirm the authenticity of the accountant's opinion, the CA MUST make a telephone call or send a copy of the Verified Accountant Letter back to the Accounting Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Accounting Practitioner listed with the authority responsible for registering or licensing such Accounting Practitioners and obtain confirmation from the Accounting Practitioner or the Accounting Practitioner's assistant that the accountant letter is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Accountant in records provided by the applicable phone company, QGIS, or QIIS. + A. **Status of Author**: The CA MUST verify the professional status of the author of the accountant letter by directly contacting the authority responsible for registering or licensing such Accounting Practitioners in the applicable jurisdiction. + B. **Basis of Opinion**: The text of the Verified Accountant Letter MUST make clear that the Accounting Practitioner is acting on behalf of the Applicant and that the information in the letter is based on the Accounting Practitioner's stated familiarity with the relevant facts and the exercise of the practitioner's professional judgment and expertise. The Verified Accountant Letter MAY also include disclaimers and other limitations customary in the Accounting Practitioner's jurisdiction, provided that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Accounting Practitioner, should the Verified Accountant Letter prove to be erroneous. Acceptable forms of Verified Accountant Letter are attached as [Appendix C](#appendix-c---sample-accountant-letters-confirming-specified-information). + C. **Authenticity**: To confirm the authenticity of the accountant's opinion, the CA MUST make a telephone call or send a copy of the Verified Accountant Letter back to the Accounting Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Accounting Practitioner listed with the authority responsible for registering or licensing such Accounting Practitioners and obtain confirmation from the Accounting Practitioner or the Accounting Practitioner's assistant that the accountant letter is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Accountant in records provided by the applicable phone company, QGIS, or QIIS. In circumstances where the opinion is digitally signed, in a manner that confirms the authenticity of the document and the identity of the signer, as verified by the CA in [Section 3.2.2.11.2](#322112-verified-accountant-letter) (2)(A), no further verification of authenticity is required. @@ -802,35 +806,35 @@ Acceptable methods of verifying the Certificate Approver's approval of an EV Cer 1. **Verification Requirements**: Before relying on face-to-face vetting documents submitted to the CA, the CA MUST verify that the Third-Party Validator meets the following requirements: - A. **Qualification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant's jurisdiction), Lawyer, or Accountant in the jurisdiction of the individual's residency; - B. **Document Chain of Custody**: The CA MUST verify that the Third-Party Validator viewed the Vetting Documents in a face-to-face meeting with the individual being validated; - C. **Verification of Attestation**: If the Third-Party Validator is not a Latin Notary, then the CA MUST confirm the authenticity of the attestation and vetting documents. + A. **Qualification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant's jurisdiction), Lawyer, or Accountant in the jurisdiction of the individual's residency; + B. **Document Chain of Custody**: The CA MUST verify that the Third-Party Validator viewed the Vetting Documents in a face-to-face meeting with the individual being validated; + C. **Verification of Attestation**: If the Third-Party Validator is not a Latin Notary, then the CA MUST confirm the authenticity of the attestation and vetting documents. 2. **Acceptable Methods of Verification**: Acceptable methods of establishing the foregoing requirements for vetting documents are: - A. **Qualification of Third-Party Validator**: The CA MUST verify the professional status of the Third-Party Validator by directly contacting the authority responsible for registering or licensing such Third-Party Validators in the applicable jurisdiction; - B. **Document Chain of Custody**: The Third-Party Validator MUST submit a statement to the CA which attests that they obtained the Vetting Documents submitted to the CA for the individual during a face-to-face meeting with the individual; - C. **Verification of Attestation**: If the Third-Party Validator is not a Latin Notary, then the CA MUST confirm the authenticity of the vetting documents received from the Third-Party Validator. The CA MUST make a telephone call to the Third-Party Validator and obtain confirmation from them or their assistant that they performed the face-to-face validation. The CA MAY rely upon self-reported information obtained from the Third-Party Validator for the sole purpose of performing this verification process. In circumstances where the attestation is digitally signed, in a manner that confirms the authenticity of the documents, and the identity of the signer as verified by the CA in [Section 3.2.2.11.3](#322113-face-to-face-validation) (1)(A), no further verification of authenticity is required. + A. **Qualification of Third-Party Validator**: The CA MUST verify the professional status of the Third-Party Validator by directly contacting the authority responsible for registering or licensing such Third-Party Validators in the applicable jurisdiction; + B. **Document Chain of Custody**: The Third-Party Validator MUST submit a statement to the CA which attests that they obtained the Vetting Documents submitted to the CA for the individual during a face-to-face meeting with the individual; + C. **Verification of Attestation**: If the Third-Party Validator is not a Latin Notary, then the CA MUST confirm the authenticity of the vetting documents received from the Third-Party Validator. The CA MUST make a telephone call to the Third-Party Validator and obtain confirmation from them or their assistant that they performed the face-to-face validation. The CA MAY rely upon self-reported information obtained from the Third-Party Validator for the sole purpose of performing this verification process. In circumstances where the attestation is digitally signed, in a manner that confirms the authenticity of the documents, and the identity of the signer as verified by the CA in [Section 3.2.2.11.3](#322113-face-to-face-validation) (1)(A), no further verification of authenticity is required. ##### 3.2.2.11.4 Independent Confirmation From Applicant An Independent Confirmation from the Applicant is a confirmation of a particular fact (e.g., confirmation of the employee or agency status of a Contract Signer or Certificate Approver, confirmation of the EV Authority of a Certificate Approver, etc.) that is: -A. Received by the CA from a Confirming Person (someone other than the person who is the subject of the inquiry) that has the appropriate authority to confirm such a fact, and who represents that he/she has confirmed such fact; -B. Received by the CA in a manner that authenticates and verifies the source of the confirmation; and -C. Binding on the Applicant. +A. Received by the CA from a Confirming Person (someone other than the person who is the subject of the inquiry) that has the appropriate authority to confirm such a fact, and who represents that he/she has confirmed such fact; +B. Received by the CA in a manner that authenticates and verifies the source of the confirmation; and +C. Binding on the Applicant. An Independent Confirmation from the Applicant MAY be obtained via the following procedure: 1. **Confirmation Request**: The CA MUST initiate a Confirmation Request via an appropriate out-of-band communication, requesting verification or confirmation of the particular fact at issue as follows: - A. **Addressee**: The Confirmation Request MUST be directed to: + A. **Addressee**: The Confirmation Request MUST be directed to: i. A position within the Applicant's organization that qualifies as a Confirming Person (e.g., Secretary, President, CEO, CFO, COO, CIO, CSO, Director, etc.) and is identified by name and title in a current QGIS, QIIS, QTIS, Verified Legal Opinion, Verified Accountant Letter, or by contacting the Applicant using a Verified Method of Communication; or ii. The Applicant's Registered Agent or Registered Office in the Jurisdiction of Incorporation as listed in the official records of the Incorporating Agency, with instructions that it be forwarded to an appropriate Confirming Person; or iii. A named individual verified to be in the direct line of management above the Contract Signer or Certificate Approver by contacting the Applicant's Human Resources Department by phone or mail (at the phone number or address for the Applicant's Place of Business, verified in accordance with these Guidelines). - B. **Means of Communication**: The Confirmation Request MUST be directed to the Confirming Person in a manner reasonably likely to reach such person. The following options are acceptable: + B. **Means of Communication**: The Confirmation Request MUST be directed to the Confirming Person in a manner reasonably likely to reach such person. The following options are acceptable: i. By paper mail addressed to the Confirming Person at: @@ -840,18 +844,18 @@ An Independent Confirmation from the Applicant MAY be obtained via the following ii. By e-mail addressed to the Confirming Person at the business e-mail address for such person listed in a current QGIS, QTIS, QIIS, Verified Legal Opinion, or Verified Accountant Letter; or iii. By telephone call to the Confirming Person, where such person is contacted by calling the main phone number of the Applicant's Place of Business (verified in accordance with these Guidelines) and asking to speak to such person, and a person taking the call identifies him- or herself as such person; or - iv. By facsimile to the Confirming Person at the Place of Business. The facsimile number must be listed in a current QGIS, QTIS, QIIS, Verified Legal Opinion, or Verified Accountant Letter. The cover page must be clearly addressed to the Confirming Person. + iv. By facsimile to the Confirming Person at the Place of Business. The facsimile number must be listed in a current QGIS, QTIS, QIIS, Verified Legal Opinion, or Verified Accountant Letter. The cover page must be clearly addressed to the Confirming Person. -2. **Confirmation Response**: The CA MUST receive a response to the Confirmation Request from a Confirming Person that confirms the particular fact at issue. Such response MAY be provided to the CA by telephone, by e-mail, or by paper mail, so long as the CA can reliably verify that it was provided by a Confirming Person in response to the Confirmation Request. +2. **Confirmation Response**: The CA MUST receive a response to the Confirmation Request from a Confirming Person that confirms the particular fact at issue. Such response MAY be provided to the CA by telephone, by e-mail, or by paper mail, so long as the CA can reliably verify that it was provided by a Confirming Person in response to the Confirmation Request. -3. The CA MAY rely on a verified Confirming Person to confirm their own contact information: email address, telephone number, and facsimile number. The CA MAY rely on this verified contact information for future correspondence with the Confirming Person if: +3. The CA MAY rely on a verified Confirming Person to confirm their own contact information: email address, telephone number, and facsimile number. The CA MAY rely on this verified contact information for future correspondence with the Confirming Person if: - A. The domain of the e-mail address is owned by the Applicant and is the Confirming Person's own e-mail address and not a group e-mail alias; - B. The Confirming Person's telephone/fax number is verified by the CA to be a telephone number that is part of the organization's telephone system, and is not the personal phone number for the person. + A. The domain of the e-mail address is owned by the Applicant and is the Confirming Person's own e-mail address and not a group e-mail alias; + B. The Confirming Person's telephone/fax number is verified by the CA to be a telephone number that is part of the organization's telephone system, and is not the personal phone number for the person. ##### 3.2.2.11.5 Qualified Independent Information Source -A Qualified Independent Information Source (QIIS) is a regularly-updated and publicly available database that is generally recognized as a dependable source for certain information. A database qualifies as a QIIS if the CA determines that: +A Qualified Independent Information Source (QIIS) is a regularly-updated and publicly available database that is generally recognized as a dependable source for certain information. A database qualifies as a QIIS if the CA determines that: 1. Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and @@ -882,21 +886,21 @@ The High Risk Certificate requirements of Section 4.2.1 of the Baseline Requirem 1. **Verification Requirements**: The CA MUST verify whether the Applicant, the Contract Signer, the Certificate Approver, the Applicant's Jurisdiction of Incorporation, Registration, or Place of Business: - A. Is identified on any government denied list, list of prohibited persons, or other list that prohibits doing business with such organization or person under the laws of the country of the CA's jurisdiction(s) of operation; or - B. Has its Jurisdiction of Incorporation, Registration, or Place of Business in any country with which the laws of the CA's jurisdiction prohibit doing business. + A. Is identified on any government denied list, list of prohibited persons, or other list that prohibits doing business with such organization or person under the laws of the country of the CA's jurisdiction(s) of operation; or + B. Has its Jurisdiction of Incorporation, Registration, or Place of Business in any country with which the laws of the CA's jurisdiction prohibit doing business. The CA MUST NOT issue any EV Certificate to the Applicant if either the Applicant, the Contract Signer, or Certificate Approver or if the Applicant's Jurisdiction of Incorporation or Registration or Place of Business is on any such list. -2. **Acceptable Methods of Verification** The CA MUST take reasonable steps to verify with the following lists and regulations: +2. **Acceptable Methods of Verification** The CA MUST take reasonable steps to verify with the following lists and regulations: - 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: + 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](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. + 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. ##### 3.2.2.12.3 Parent/Subsidiary/Affiliate Relationship @@ -913,14 +917,14 @@ A CA verifying an Applicant using information of the Applicant's Parent, Subsidi #### 3.2.2.13 Final Cross-Correlation and Due Diligence -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. +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. -4. In the case where some or all of the documentation used to support the application is in a language other than the CA's normal operating language, the CA or its Affiliate MUST perform the requirements of this Final Cross-Correlation and Due Diligence section using employees under its control and having appropriate training, experience, and judgment in confirming organizational identification and authorization and fulfilling all qualification requirements contained in [Section 5.3.2](#532-background-check-procedures). When employees under the control of the CA do not possess the language skills necessary to perform the Final Cross-Correlation and Due Diligence a CA MAY: +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. +4. In the case where some or all of the documentation used to support the application is in a language other than the CA's normal operating language, the CA or its Affiliate MUST perform the requirements of this Final Cross-Correlation and Due Diligence section using employees under its control and having appropriate training, experience, and judgment in confirming organizational identification and authorization and fulfilling all qualification requirements contained in [Section 5.3.2](#532-background-check-procedures). When employees under the control of the CA do not possess the language skills necessary to perform the Final Cross-Correlation and Due Diligence a CA MAY: - A. Rely on language translations of the relevant portions of the documentation, provided that the translations are received from a Translator; or - 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 3.2.2.13](#32213-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 8.1.1](#811-self-audits) and [Section 8.2](#82-identityqualifications-of-assessor). + A. Rely on language translations of the relevant portions of the documentation, provided that the translations are received from a Translator; or + 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 3.2.2.13](#32213-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 8.1.1](#811-self-audits) and [Section 8.2](#82-identityqualifications-of-assessor). In the case of EV Certificates to be issued in compliance with the requirements of [Section 1.3.2](#132-registration-authorities), the Enterprise RA MAY perform the requirements of this Final Cross-Correlation and Due Diligence section. @@ -943,20 +947,20 @@ If an Applicant has a currently valid EV Certificate issued by the CA, a CA MAY A CA may rely on a previously verified certificate request to issue a replacement certificate, so long as the certificate being referenced was not revoked due to fraud or other illegal conduct, if: -1. The expiration date of the replacement certificate is the same as the expiration date of the EV Certificate that is being replaced, and +1. The expiration date of the replacement certificate is the same as the expiration date of the EV Certificate that is being replaced, and 2. The Subject Information of the Certificate is the same as the Subject in the EV Certificate that is being replaced. ##### 3.2.2.14.3 Age of Validated Data 1. Except for reissuance of an EV Certificate under [Section 3.2.2.14.2](#322142-re-issuance-requests) and except when permitted otherwise in [Section 3.2.2.14.1](#322141-validation-for-existing-subscribers), the age of all data used to support issuance of an EV Certificate (before revalidation is required) SHALL NOT exceed the following limits: - A. Legal existence and identity – 398 days; - B. Assumed name – 398 days; - C. Address of Place of Business – 398 days; - D. Verified Method of Communication – 398 days; - E. Operational existence – 398 days; - F. Domain Name – 398 days; - G. Name, Title, Agency, and Authority – 398 days, unless a contract between the CA and the Applicant specifies a different term, in which case, the term specified in such contract controls. For example, the contract MAY include the perpetual assignment of EV roles until revoked by the Applicant or CA, or until the contract expires or is terminated. + A. Legal existence and identity – 398 days; + B. Assumed name – 398 days; + C. Address of Place of Business – 398 days; + D. Verified Method of Communication – 398 days; + E. Operational existence – 398 days; + F. Domain Name – 398 days; + G. Name, Title, Agency, and Authority – 398 days, unless a contract between the CA and the Applicant specifies a different term, in which case, the term specified in such contract controls. For example, the contract MAY include the perpetual assignment of EV roles until revoked by the Applicant or CA, or until the contract expires or is terminated. 2. The 398-day period set forth above SHALL begin to run on the date the information was collected by the CA. 3. The CA MAY reuse a previously submitted EV Certificate Request, Subscriber Agreement, or Terms of Use, including use of a single EV Certificate Request in support of multiple EV Certificates containing the same Subject to the extent permitted under [Section 3.2.2.9](#3229-verification-of-signature-on-subscriber-agreement-and-ev-certificate-requests) and [Section 3.2.2.10](#32210-verification-of-approval-of-ev-certificate-request). @@ -1034,7 +1038,7 @@ An Applicant qualifies as a Business Entity if: An Applicant qualifies as a Non-Commercial Entity if: -1. The Applicant is an International Organization Entity, created under a charter, treaty, convention or equivalent instrument that was signed by, or on behalf of, more than one country's government. The CA/Browser Forum may publish a listing of Applicants who qualify as an International Organization for EV eligibility; and +1. The Applicant is an International Organization Entity, created under a charter, treaty, convention or equivalent instrument that was signed by, or on behalf of, more than one country's government. The CA/Browser Forum may publish a listing of Applicants who qualify as an International Organization for EV eligibility; and 2. The Applicant is not headquartered in any country where the CA is prohibited from doing business or issuing a certificate by the laws of the CA's jurisdiction; and @@ -1053,16 +1057,16 @@ The Certificate Request requirements in Section 4.1.2 of the Baseline Requiremen The following Applicant roles are required for the issuance of an EV Certificate. -1. **Certificate Requester**: The EV Certificate Request MUST be submitted by an authorized Certificate Requester. A Certificate Requester is a natural person who is either the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or a third party (such as an ISP or hosting company) that completes and submits an EV Certificate Request on behalf of the Applicant. +1. **Certificate Requester**: The EV Certificate Request MUST be submitted by an authorized Certificate Requester. A Certificate Requester is a natural person who is either the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or a third party (such as an ISP or hosting company) that completes and submits an EV Certificate Request on behalf of the Applicant. -2. **Certificate Approver**: The EV Certificate Request MUST be approved by an authorized Certificate Approver. A Certificate Approver is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant to +2. **Certificate Approver**: The EV Certificate Request MUST be approved by an authorized Certificate Approver. A Certificate Approver is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant to i. act as a Certificate Requester and to authorize other employees or third parties to act as a Certificate Requester, and ii. to approve EV Certificate Requests submitted by other Certificate Requesters. -3. **Contract Signer**: A Subscriber Agreement applicable to the requested EV Certificate MUST be signed by an authorized Contract Signer. A Contract Signer is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements. +3. **Contract Signer**: A Subscriber Agreement applicable to the requested EV Certificate MUST be signed by an authorized Contract Signer. A Contract Signer is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements. -4. **Applicant Representative**: In the case where the CA and the Subscriber are affiliated, Terms of Use applicable to the requested EV Certificate MUST be acknowledged and agreed to by an authorized Applicant Representative. An Applicant Representative is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to acknowledge and agree to the Terms of Use. +4. **Applicant Representative**: In the case where the CA and the Subscriber are affiliated, Terms of Use applicable to the requested EV Certificate MUST be acknowledged and agreed to by an authorized Applicant Representative. An Applicant Representative is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to acknowledge and agree to the Terms of Use. The Applicant MAY authorize one individual to occupy two or more of these roles. The Applicant MAY authorize more than one individual to occupy any of these roles. @@ -1224,7 +1228,7 @@ As specified in Section 5 of the Baseline Requirements. In addition, systems use ### 5.2.4 Roles requiring separation of duties -1. The CA MUST enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the issuance of an EV Certificate. The Final Cross-Correlation and Due Diligence steps, as outlined in [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence), MAY be performed by one of the persons. For example, one Validation Specialist MAY review and verify all the Applicant information and a second Validation Specialist MAY approve issuance of the EV Certificate. +1. The CA MUST enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the issuance of an EV Certificate. The Final Cross-Correlation and Due Diligence steps, as outlined in [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence), MAY be performed by one of the persons. For example, one Validation Specialist MAY review and verify all the Applicant information and a second Validation Specialist MAY approve issuance of the EV Certificate. 2. Such controls MUST be auditable. ## 5.3 Personnel controls @@ -1237,17 +1241,17 @@ Prior to the commencement of employment of any person by the CA for engagement i 1. **Verify the Identity of Such Person**: Verification of identity MUST be performed through: - A. The personal (physical) presence of such person before trusted persons who perform human resource or security functions, and - B. The verification of well-recognized forms of government-issued photo identification (e.g., passports and/or drivers licenses); + A. The personal (physical) presence of such person before trusted persons who perform human resource or security functions, and + B. The verification of well-recognized forms of government-issued photo identification (e.g., passports and/or drivers licenses); and 2. **Verify the Trustworthiness of Such Person**: Verification of trustworthiness SHALL include background checks, which address at least the following, or their equivalent: - A. Confirmation of previous employment, - B. Check of professional references; - C. Confirmation of the highest or most-relevant educational qualification obtained; - D. Search of criminal records (local, state or provincial, and national) where allowed by the jurisdiction in which the person will be employed; + A. Confirmation of previous employment, + B. Check of professional references; + C. Confirmation of the highest or most-relevant educational qualification obtained; + D. Search of criminal records (local, state or provincial, and national) where allowed by the jurisdiction in which the person will be employed; and @@ -1255,7 +1259,7 @@ Prior to the commencement of employment of any person by the CA for engagement i ### 5.3.3 Training requirements -The requirements in Section 5.3.3 of the Baseline Requirements apply equally to EV Certificates and these Guidelines. The required internal examination must relate to the EV Certificate validation criteria outlined in these Guidelines. +The requirements in Section 5.3.3 of the Baseline Requirements apply equally to EV Certificates and these Guidelines. The required internal examination must relate to the EV Certificate validation criteria outlined in these Guidelines. ### 5.3.4 Retraining frequency and requirements @@ -1323,7 +1327,7 @@ As specified in Section 5.4 of the Baseline Requirements. ### 6.1.1 Key pair generation -All requirements in Section 6.1.1.1 of the Baseline Requirements apply equally to EV Certificates. However, for Root CA Key Pairs generated after the release of these Guidelines, the Root CA Key Pair generation ceremony MUST be witnessed by the CA's Qualified Auditor in order to observe the process and the controls over the integrity and confidentiality of the Root CA Key Pairs produced. The Qualified Auditor MUST then issue a report opining that the CA, during its Root CA Key Pair and Certificate generation process: +All requirements in Section 6.1.1.1 of the Baseline Requirements apply equally to EV Certificates. However, for Root CA Key Pairs generated after the release of these Guidelines, the Root CA Key Pair generation ceremony MUST be witnessed by the CA's Qualified Auditor in order to observe the process and the controls over the integrity and confidentiality of the Root CA Key Pairs produced. The Qualified Auditor MUST then issue a report opining that the CA, during its Root CA Key Pair and Certificate generation process: 1. Documented its Root CA key generation and protection procedures in its Certificate Policy, and its Certification Practices Statement; 2. Included appropriate detail in its Root Key Generation Script; @@ -1412,21 +1416,21 @@ This section sets forth minimum requirements for the content of the EV Certifica ### 7.1.2 Certificate extensions -The extensions listed in [Section 7.1.2](#712-certificate-extensions) are recommended for maximum interoperability between certificates and browsers / applications, but are not mandatory on the CAs except where indicated as “Required”. CAs may use other extensions that are not listed in [Section 7.1.2](#712-certificate-extensions), but are encouraged to add them to this section by ballot from time to time to help increase extension standardization across the industry. +The extensions listed in [Section 7.1.2](#712-certificate-extensions) are recommended for maximum interoperability between certificates and browsers / applications, but are not mandatory on the CAs except where indicated as “Required”. CAs may use other extensions that are not listed in [Section 7.1.2](#712-certificate-extensions), but are encouraged to add them to this section by ballot from time to time to help increase extension standardization across the industry. -If a CA includes an extension in a certificate that has a Certificate field which is named in [Section 7.1.2](#712-certificate-extensions), the CA must follow the format specified in that subsection. However, no extension or extension format shall be mandatory on a CA unless specifically stated as “Required” in the subsection that describes the extension. +If a CA includes an extension in a certificate that has a Certificate field which is named in [Section 7.1.2](#712-certificate-extensions), the CA must follow the format specified in that subsection. However, no extension or extension format shall be mandatory on a CA unless specifically stated as “Required” in the subsection that describes the extension. #### 7.1.2.1 Subject Alternative Name Extension -**Certificate Field**: `subjectAltName:dNSName` -**Required/Optional**: **Required** -**Contents**: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This extension MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. +**Certificate Field**: `subjectAltName:dNSName` +**Required/Optional**: **Required** +**Contents**: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This extension MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. #### 7.1.2.2 CA/Browser Forum Organization Identifier Extension -**Extension Name**: `cabfOrganizationIdentifier` (OID: 2.23.140.3.1) -**Verbose OID**: `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-extensions(3) cabf-organization-identifier(1) }` -**Required/Optional**: **Optional (but see below)** +**Extension Name**: `cabfOrganizationIdentifier` (OID: 2.23.140.3.1) +**Verbose OID**: `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-extensions(3) cabf-organization-identifier(1) }` +**Required/Optional**: **Optional (but see below)** **Contents**: If the subject:organizationIdentifier is present, this field MUST be present. If present, this extension MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. @@ -1470,8 +1474,8 @@ Subject to the requirements of these Guidelines, the EV Certificate and certific ##### 7.1.4.2.1 Subject Organization Name Field -**Certificate Field**: `subject:organizationName` (OID 2.5.4.10) -**Required/Optional**: Required +**Certificate Field**: `subject:organizationName` (OID 2.5.4.10) +**Required/Optional**: Required **Contents**: This field MUST contain the Subject's full legal organization name as listed in the official records of the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration or as otherwise verified by the CA as provided herein. A CA MAY abbreviate the organization prefixes or suffixes in the organization name, e.g., if the official record shows "Company Name Incorporated" the CA MAY include "Company Name, Inc." When abbreviating a Subject's full legal name as allowed by this subsection, the CA MUST use abbreviations that are not misleading in the Jurisdiction of Incorporation or Registration. @@ -1482,71 +1486,71 @@ If the combination of names or the organization name by itself exceeds 64 charac ##### 7.1.4.2.2 Subject Common Name Field -**Certificate Field**: `subject:commonName` (OID: 2.5.4.3) -**Required/Optional**: Deprecated (Discouraged, but not prohibited) -**Contents**: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This field MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. +**Certificate Field**: `subject:commonName` (OID: 2.5.4.3) +**Required/Optional**: Deprecated (Discouraged, but not prohibited) +**Contents**: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This field MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. ##### 7.1.4.2.3 Subject Business Category Field -**Certificate Field**: `subject:businessCategory` (OID: 2.5.4.15) -**Required/Optional**: Required +**Certificate Field**: `subject:businessCategory` (OID: 2.5.4.15) +**Required/Optional**: Required **Contents**: This field MUST contain one of the following strings: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity" depending upon whether the Subject qualifies under the terms of [Section 4.1.1.1](#4111-private-organization-subjects), [Section 4.1.1.2](#4112-government-entity-subjects), [Section 4.1.1.3](#4113-business-entity-subjects) or [Section 4.1.1.4](#4114-non-commercial-entity-subjects), respectively. ##### 7.1.4.2.4 Subject Jurisdiction of Incorporation or Registration Field **Certificate Fields**: -Locality (if required): +Locality (if required): `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1) -State or province (if required): +State or province (if required): `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2) -Country: +Country: `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) -**Required/Optional**: Required -**Contents**: These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. Country information MUST be specified using the applicable ISO country code. State or province or locality information (where applicable) for the Subject's Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction. +**Required/Optional**: Required +**Contents**: These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. Country information MUST be specified using the applicable ISO country code. State or province or locality information (where applicable) for the Subject's Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction. Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, the values within these fields have been disclosed within the latest publicly-available disclosure, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), as acceptable values for the applicable Incorporating Agency or Registration Agency. ##### 7.1.4.2.5 Subject Registration Number Field -**Certificate Field**: `subject:serialNumber` (OID: 2.5.4.5) -**Required/Optional**: **Required** -**Contents**: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). +**Certificate Field**: `subject:serialNumber` (OID: 2.5.4.5) +**Required/Optional**: **Required** +**Contents**: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). For Government Entities that do not have a Registration Number or readily verifiable date of creation, the CA SHALL enter appropriate language to indicate that the Subject is a Government Entity. -For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). +For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). Effective as of 1 October 2020, if the CA has disclosed a set of acceptable format or formats for Registration Numbers for the applicable Registration Agency or Incorporating Agency, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), the CA MUST ensure, prior to issuance, that the Registration Number is valid according to at least one currently disclosed format for that applicable Registration Agency or Incorporating agency. ##### 7.1.4.2.6 Subject Physical Address of Place of Business Field -**Certificate Fields**: - Number and street: `subject:streetAddress` (OID: 2.5.4.9) - City or town: `subject:localityName` (OID: 2.5.4.7) - State or province (where applicable): `subject:stateOrProvinceName` (OID: 2.5.4.8) - Country: `subject:countryName` (OID: 2.5.4.6) - Postal code: `subject:postalCode` (OID: 2.5.4.17) -**Required/Optional**: Required/Optional +**Certificate Fields**: + Number and street: `subject:streetAddress` (OID: 2.5.4.9) + City or town: `subject:localityName` (OID: 2.5.4.7) + State or province (where applicable): `subject:stateOrProvinceName` (OID: 2.5.4.8) + Country: `subject:countryName` (OID: 2.5.4.6) + Postal code: `subject:postalCode` (OID: 2.5.4.17) +**Required/Optional**: Required/Optional **Contents**: These fields MUST contain the verified physical address of the Subject’s Place of Business. -The `countryName` field MUST be present and MUST contain the applicable two-letter ISO 3166-1 country code. If the country is not represented by an official ISO 3166-1 code, the ISO 3166-1 user-assigned code "XX" MUST be used. +The `countryName` field MUST be present and MUST contain the applicable two-letter ISO 3166-1 country code. If the country is not represented by an official ISO 3166-1 code, the ISO 3166-1 user-assigned code "XX" MUST be used. -The `localityName` and `stateOrProvinceName` fields are OPTIONAL, but at least one of them MUST be present. When included, these fields MUST accurately represent the locality and/or state or province information verified in accordance with Section 3.2.2.1 of the Baseline Requirements. +The `localityName` and `stateOrProvinceName` fields are OPTIONAL, but at least one of them MUST be present. When included, these fields MUST accurately represent the locality and/or state or province information verified in accordance with Section 3.2.2.1 of the Baseline Requirements. The `streetAddress` and `postalCode` fields are OPTIONAL. If present, they MUST contain the verified street address and postal information of the Subject’s Place of Business as required by Section 3.2.2.1 of the Baseline Requirements. Multiple `streetAddress` attributes MAY be present. ##### 7.1.4.2.7 Subject Organizational Unit Name Field -**Certificate Field**: `subject:organizationalUnitName` (OID: 2.5.4.11) +**Certificate Field**: `subject:organizationalUnitName` (OID: 2.5.4.11) **Required/Optional/Prohibited**: **Prohibited**. ##### 7.1.4.2.8 Subject Organization Identifier Field -**Certificate Field**: `subject:organizationIdentifier` (OID: 2.5.4.97) -**Required/Optional**: Optional +**Certificate Field**: `subject:organizationIdentifier` (OID: 2.5.4.97) +**Required/Optional**: Optional **Contents**: If present, this field MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. The organizationIdentifier MUST be encoded as a PrintableString or UTF8String. @@ -1559,7 +1563,7 @@ The Registration Scheme MUST be identified using the using the following structu * a hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8)); * Registration Reference allocated in accordance with the identified Registration Scheme -Note: Registration References MAY contain hyphens, but Registration Schemes, ISO 3166 country codes, and ISO 3166-2 identifiers do not. Therefore if more than one hyphen appears in the structure, the leftmost hyphen is a separator, and the remaining hyphens are part of the Registration Reference. +Note: Registration References MAY contain hyphens, but Registration Schemes, ISO 3166 country codes, and ISO 3166-2 identifiers do not. Therefore if more than one hyphen appears in the structure, the leftmost hyphen is a separator, and the remaining hyphens are part of the Registration Reference. As in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field), the specified location information MUST match the scope of the registration being referenced. @@ -1627,7 +1631,7 @@ The Application Software Supplier identifies Root CAs that are approved to issue #### 7.1.6.4 Subscriber Certificates -A Certificate issued to a Subscriber MUST contain one or more policy identifier(s), defined by the Issuing CA, in the Certificate's `certificatePolicies` extension that indicates adherence to and compliance with these Guidelines. Each CA SHALL document in its Certificate Policy or Certification Practice Statement that the Certificates it issues containing the specified policy identifier(s) are managed in accordance with these Guidelines. +A Certificate issued to a Subscriber MUST contain one or more policy identifier(s), defined by the Issuing CA, in the Certificate's `certificatePolicies` extension that indicates adherence to and compliance with these Guidelines. Each CA SHALL document in its Certificate Policy or Certification Practice Statement that the Certificates it issues containing the specified policy identifier(s) are managed in accordance with these Guidelines. ### 7.1.7 Usage of Policy Constraints extension @@ -1663,7 +1667,7 @@ CAs issuing EV Certificates MUST undergo an annual audit that meets the criteria ### 8.1.1 Self audits -During the period in which it issues EV Certificates, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least three percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. For all EV Certificates where the Final Cross-Correlation and Due Diligence requirements of [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence) is performed by an RA, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least six percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. +During the period in which it issues EV Certificates, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least three percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. For all EV Certificates where the Final Cross-Correlation and Due Diligence requirements of [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence) is performed by an RA, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least six percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. ## 8.2 Identity/qualifications of assessor @@ -1677,7 +1681,7 @@ A Qualified Auditor (as defined in Section 8.2 of the Baseline Requirements) MUS ## 8.6 Communication of results -CAs SHOULD make its audit report publicly available no later than three months after the end of the audit period. If there is a delay greater than three months and if so requested by an Application Software Supplier, the CA MUST provide an explanatory letter signed by its auditor. +CAs SHOULD make its audit report publicly available no later than three months after the end of the audit period. If there is a delay greater than three months and if so requested by an Application Software Supplier, the CA MUST provide an explanatory letter signed by its auditor. ## 8.7 Pre-issuance Readiness Audit @@ -1688,7 +1692,7 @@ CAs SHOULD make its audit report publicly available no later than three months a i. a point-in-time readiness assessment audit against the WebTrust for CA Program, or ii. a point-in-time readiness assessment audit against the WebTrust EV Program, the ETSI TS 102 042 EVCP, or the ETSI EN 319 411-1 for EVCP policy. -The CA MUST complete any required point-in-time readiness assessment no earlier than twelve (12) months prior to issuing an EV Certificate. The CA MUST undergo a complete audit under such scheme within ninety (90) days of issuing the first EV Certificate. +The CA MUST complete any required point-in-time readiness assessment no earlier than twelve (12) months prior to issuing an EV Certificate. The CA MUST undergo a complete audit under such scheme within ninety (90) days of issuing the first EV Certificate. # 9. OTHER BUSINESS AND LEGAL MATTERS @@ -1710,9 +1714,9 @@ The CA MUST complete any required point-in-time readiness assessment no earlier Each CA SHALL maintain the following insurance related to their respective performance and obligations under these Guidelines: -A. Commercial General Liability insurance (occurrence form) with policy limits of at least two million US dollars in coverage; and +A. Commercial General Liability insurance (occurrence form) with policy limits of at least two million US dollars in coverage; and -B. Professional Liability/Errors and Omissions insurance, with policy limits of at least five million US dollars in coverage, and including coverage for: +B. Professional Liability/Errors and Omissions insurance, with policy limits of at least five million US dollars in coverage, and including coverage for: i. claims for damages arising out of an act, error, or omission, unintentional breach of contract, or neglect in issuing or maintaining EV Certificates, and; ii. claims for damages arising out of infringement of the proprietary rights of any third party (excluding copyright, and trademark infringement), and invasion of privacy and advertising injury. @@ -1756,27 +1760,27 @@ A CA MAY self-insure for liabilities that arise from such party's performance an When the CA issues an EV Certificate, the CA and its Root CA represent and warrant to the Certificate Beneficiaries listed in Section 9.6.1 of the Baseline Requirements, during the period when the EV Certificate is Valid, that the CA has followed the requirements of these Guidelines and its EV Policies in issuing and managing the EV Certificate and in verifying the accuracy of the information contained in the EV Certificate. The EV Certificate Warranties specifically include, but are not limited to, the following: -A. **Legal Existence**: The CA has confirmed with the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration that, as of the date the EV Certificate was issued, the Subject named in the EV Certificate legally exists as a valid organization or entity in the Jurisdiction of Incorporation or Registration; +A. **Legal Existence**: The CA has confirmed with the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration that, as of the date the EV Certificate was issued, the Subject named in the EV Certificate legally exists as a valid organization or entity in the Jurisdiction of Incorporation or Registration; -B. **Identity**: The CA has confirmed that, as of the date the EV Certificate was issued, the legal name of the Subject named in the EV Certificate matches the name on the official government records of the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration, and if an assumed name is also included, that the assumed name is properly registered by the Subject in the jurisdiction of its Place of Business; +B. **Identity**: The CA has confirmed that, as of the date the EV Certificate was issued, the legal name of the Subject named in the EV Certificate matches the name on the official government records of the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration, and if an assumed name is also included, that the assumed name is properly registered by the Subject in the jurisdiction of its Place of Business; -C. **Right to Use Domain Name**: The CA has taken all steps reasonably necessary to verify that, as of the date the EV Certificate was issued, the Subject named in the EV Certificate has the right to use all the Domain Name(s) listed in the EV Certificate; +C. **Right to Use Domain Name**: The CA has taken all steps reasonably necessary to verify that, as of the date the EV Certificate was issued, the Subject named in the EV Certificate has the right to use all the Domain Name(s) listed in the EV Certificate; -D. **Authorization for EV Certificate**: The CA has taken all steps reasonably necessary to verify that the Subject named in the EV Certificate has authorized the issuance of the EV Certificate; +D. **Authorization for EV Certificate**: The CA has taken all steps reasonably necessary to verify that the Subject named in the EV Certificate has authorized the issuance of the EV Certificate; -E. **Accuracy of Information**: The CA has taken all steps reasonably necessary to verify that all of the other information in the EV Certificate is accurate, as of the date the EV Certificate was issued; +E. **Accuracy of Information**: The CA has taken all steps reasonably necessary to verify that all of the other information in the EV Certificate is accurate, as of the date the EV Certificate was issued; -F. **Subscriber Agreement**: The Subject named in the EV Certificate has entered into a legally valid and enforceable Subscriber Agreement with the CA that satisfies the requirements of these Guidelines or, if they are affiliated, the Applicant Representative has acknowledged and accepted the Terms of Use; +F. **Subscriber Agreement**: The Subject named in the EV Certificate has entered into a legally valid and enforceable Subscriber Agreement with the CA that satisfies the requirements of these Guidelines or, if they are affiliated, the Applicant Representative has acknowledged and accepted the Terms of Use; -G. **Status**: The CA will follow the requirements of these Guidelines and maintain a 24 x 7 online-accessible Repository with current information regarding the status of the EV Certificate as Valid or revoked; and +G. **Status**: The CA will follow the requirements of these Guidelines and maintain a 24 x 7 online-accessible Repository with current information regarding the status of the EV Certificate as Valid or revoked; and -H. **Revocation**: The CA will follow the requirements of these Guidelines and revoke the EV Certificate for any of the revocation reasons specified in these Guidelines. +H. **Revocation**: The CA will follow the requirements of these Guidelines and revoke the EV Certificate for any of the revocation reasons specified in these Guidelines. ### 9.6.2 RA representations and warranties ### 9.6.3 Subscriber representations and warranties -Section 9.6.3 of the Baseline Requirements applies equally to EV Certificates. In cases where the Certificate Request does not contain all necessary information about the Applicant, the CA MUST additionally confirm the data with the Certificate Approver or Contract Signer rather than the Certificate Requester. +Section 9.6.3 of the Baseline Requirements applies equally to EV Certificates. In cases where the Certificate Request does not contain all necessary information about the Applicant, the CA MUST additionally confirm the data with the Certificate Approver or Contract Signer rather than the Certificate Requester. EV Certificate Applicants make the commitments and warranties set forth in Section 9.6.3 of the Baseline Requirements for the benefit of the CA and Certificate Beneficiaries. @@ -1838,7 +1842,7 @@ Section 9.16.3 of the Baseline Requirements applies equally to EV Certificates. # Appendix A - User Agent Verification (Normative) -The CA MUST host test Web pages that allow Application Software Suppliers to test their software with EV Certificates that chain up to each EV Root Certificate. At a minimum, the CA MUST host separate Web pages using certificates that are: +The CA MUST host test Web pages that allow Application Software Suppliers to test their software with EV Certificates that chain up to each EV Root Certificate. At a minimum, the CA MUST host separate Web pages using certificates that are: i. valid; ii. revoked; and @@ -1859,7 +1863,7 @@ The CA MUST host test Web pages that allow Application Software Suppliers to tes | Client Representative: | **(Exact name of Client Representative who signed the Application – see footnote 2)** | | Application Date: | **(Insert date of Client's Application to the Issuing CA)** | -This firm represents _[**exact** company name of Client]_ [^1] ("Client"), who has submitted the Application to you dated as of the Application Date shown above ("Application"). We have been asked by our Client to present you with our opinion as stated in this letter. +This firm represents _[**exact** company name of Client]_ [^1] ("Client"), who has submitted the Application to you dated as of the Application Date shown above ("Application"). We have been asked by our Client to present you with our opinion as stated in this letter. [Insert customary preliminary matters for opinion letters in your jurisdiction.] @@ -1869,7 +1873,7 @@ On this basis, we hereby offer the following opinion: 2. That Company conducts business under the assumed name or "DBA"_[assumed name of the Applicant]_ and has registered such name with the appropriate government agency in the jurisdiction of its place of business below. -3. That _[name of Client's Representative]_[^2] has authority to act on behalf of Company to: [_select as appropriate_] (a) provide the information about Company required for issuance of the EV Certificates as contained in the attached Application, (b) request one or more EV Certificates and to designate other persons to request EV Certificates, and (c) agree to the relevant contractual obligations contained in the Subscriber Agreement on behalf of Company. +3. That _[name of Client's Representative]_[^2] has authority to act on behalf of Company to: [_select as appropriate_] (a) provide the information about Company required for issuance of the EV Certificates as contained in the attached Application, (b) request one or more EV Certificates and to designate other persons to request EV Certificates, and (c) agree to the relevant contractual obligations contained in the Subscriber Agreement on behalf of Company. 4. That Company has a physical presence and its place of business is at the following location: @@ -1895,7 +1899,7 @@ _[Jurisdiction(s) in which attorney / Latin notary is admitted to practice]_[^3] cc: [Send copy to Client_]_ -[^1]: This must be the Client's exact corporate name, as registered with the relevant Incorporating Agency in the Client's Jurisdiction of Incorporation. This is the name that will be included in the EV Certificate. +[^1]: This must be the Client's exact corporate name, as registered with the relevant Incorporating Agency in the Client's Jurisdiction of Incorporation. This is the name that will be included in the EV Certificate. [^2]: If necessary to establish the Client Representative's actual authority, you may rely on a Power of Attorney from an officer of Client who has authority to delegate the authority to the Client Representative. @@ -1905,7 +1909,7 @@ cc: [Send copy to Client_]_ **(Informative)** -It is acceptable for professional accountants to provide letters that address specified matters. The letters would be provided in accordance with the professional standards in the jurisdiction in which the accountant practices. +It is acceptable for professional accountants to provide letters that address specified matters. The letters would be provided in accordance with the professional standards in the jurisdiction in which the accountant practices. Two examples of the letter that might be prepared by an accountant in the United States and in Canada follow: @@ -1913,9 +1917,9 @@ Two examples of the letter that might be prepared by an accountant in the United To the [Certification Authority] and Management of [Client]: -We have performed the procedures enumerated below, which were agreed to by the Managements of Client, solely to assist you in evaluating the company's application for an Extended Validation (EV) Certificate, dated......................., 20...... This agreed-upon procedures engagement was conducted in accordance with attestation standards established by the American Institute of Certified Public Accountants. The sufficiency of these procedures is solely the responsibility of those parties specified in this report. Consequently, we make no representation regarding the sufficiency of the procedures described below either for the purpose for which this report has been requested or for any other purpose. +We have performed the procedures enumerated below, which were agreed to by the Managements of Client, solely to assist you in evaluating the company's application for an Extended Validation (EV) Certificate, dated......................., 20...... This agreed-upon procedures engagement was conducted in accordance with attestation standards established by the American Institute of Certified Public Accountants. The sufficiency of these procedures is solely the responsibility of those parties specified in this report. Consequently, we make no representation regarding the sufficiency of the procedures described below either for the purpose for which this report has been requested or for any other purpose. -| Specified Information: | Procedure:(Note 1: These are illustrative of the procedures that would be undertaken and are designed to meet the needs of the Certification Authorities issuing Extended Validation Certificates) | Results: (Note 2: If you are unavailable to perform any of the stated procedure, this should be noted in this column. Any exceptions should be noted in a separate paragraph below) | +| Specified Information: | Procedure:(Note 1: These are illustrative of the procedures that would be undertaken and are designed to meet the needs of the Certification Authorities issuing Extended Validation Certificates) | Results: (Note 2: If you are unavailable to perform any of the stated procedure, this should be noted in this column. Any exceptions should be noted in a separate paragraph below) | | --- | --- | --- | | | | | | Legal Name - 123456 Delaware corporation | Agree legal name to permanent audit file information (If audit has been completed). | Legal name on the application agrees with the information contained in our permanent file with respect to Client.(If there is no permanent file, state this fact) | @@ -1924,7 +1928,7 @@ We have performed the procedures enumerated below, which were agreed to by the M | | | | | Physical location - "Address Information" | Visit the location at the address | Site visit completed at Address | | | | | -| Business Phone Number - 555 999 9999 | Phone the number provided and confirm that it was answered by the named organization | Phoned Business Number and noted that it was answered with the Doing Business As name. This would provided by the receptionist | +| Business Phone Number - 555 999 9999 | Phone the number provided and confirm that it was answered by the named organization | Phoned Business Number and noted that it was answered with the Doing Business As name. This would provided by the receptionist | | | | | | Bank Account – "Bank Name", "Account Number" | Request a letter directly from "the Bank" confirming the existence of the account for the benefit of "the Client" | Received letter directly from "the Bank" confirming the existence of the account for the benefit of "the Client" | | | | | @@ -1932,7 +1936,7 @@ We have performed the procedures enumerated below, which were agreed to by the M | | | | | Name of application signer and approver | Obtain letter from verified Officer confirming the names of the application signer and approver | Obtained letter from the President confirming the names of the duly authorized names of the application signer and approver as they appear in the application | -We were not engaged to and did not conduct an examination, the objective of which would be the expression of an opinion on the Application for Extended Validation Certificate. Accordingly, we do not express such an opinion. Had we performed additional procedures, other matters might have come to our attention that would have been reported to you. +We were not engaged to and did not conduct an examination, the objective of which would be the expression of an opinion on the Application for Extended Validation Certificate. Accordingly, we do not express such an opinion. Had we performed additional procedures, other matters might have come to our attention that would have been reported to you. This report is intended solely for the information and use of the Certification Authority and managements of Client, and is not intended to be and should not be used by anyone other than these specified parties. @@ -1946,9 +1950,9 @@ To: [Name of Certification Authority] Re: Client Limited [Applicant] -As specifically agreed, I/we have performed the following procedures in connection with the above company's application for an Extended Validation (EV) Certificate, dated ......................., 20.... with respect to the following specified information contained in the application +As specifically agreed, I/we have performed the following procedures in connection with the above company's application for an Extended Validation (EV) Certificate, dated ......................., 20.... with respect to the following specified information contained in the application -| Specified Information: | Procedure:(Note 1: These are illustrative of the procedures that would be undertaken and are designed to meet the needs of the Certification Authorities issuing Extended Validation Certificates) | Results: (Note 2: If you are unavailable to perform any of the stated procedure, this should be noted in this column. Any exceptions should be noted in a separate paragraph below) | +| Specified Information: | Procedure:(Note 1: These are illustrative of the procedures that would be undertaken and are designed to meet the needs of the Certification Authorities issuing Extended Validation Certificates) | Results: (Note 2: If you are unavailable to perform any of the stated procedure, this should be noted in this column. Any exceptions should be noted in a separate paragraph below) | | --- | --- | --- | | | | | | Legal Name - 123456 Ontario limited | Agree legal name to permanent audit file information (If audit has been completed) | Legal name on the application agrees with the information contained in our permanent file with respect to Client.(If there is no permanent file, state this fact) | @@ -1957,7 +1961,7 @@ As specifically agreed, I/we have performed the following procedures in connecti | | | | | Physical location - "Address Information" | Visit the location at the address | Site visit completed at Address | | | | | -| Business Phone Number - 555 999 9999 | Phone the number provided and confirm that it was answered by the named organization | Phoned Business Number and noted that it was answered with the Doing Business As name. This would provided by the receptionist | +| Business Phone Number - 555 999 9999 | Phone the number provided and confirm that it was answered by the named organization | Phoned Business Number and noted that it was answered with the Doing Business As name. This would provided by the receptionist | | | | | | Bank Account – "Bank Name", "Account Number" | Request a letter directly from "the Bank" confirming the existence of the account for the benefit of "the Client" | Received letter directly from "the Bank" confirming the existence of the account for the benefit of "the Client" | | | | | @@ -1965,7 +1969,7 @@ As specifically agreed, I/we have performed the following procedures in connecti | | | | | Name of application signer and approver | Obtain letter from verified Officer confirming the names of the application signer and approver | Obtained letter from the President confirming the names of the duly authorized names of the application signer and approver as they appear in the application | -As a result of applying the above procedures, I/we found [no / the following] exceptions [list of exceptions]. However, these procedures do not constitute an audit of the company's application for an EV Certificate, and therefore I express no opinion on the application dated ......................., 20..... +As a result of applying the above procedures, I/we found [no / the following] exceptions [list of exceptions]. However, these procedures do not constitute an audit of the company's application for an EV Certificate, and therefore I express no opinion on the application dated ......................., 20..... This letter is for use solely in connection with the application for an Extended Validation Certificate by [Client] dated ......................., 20...... @@ -1975,13 +1979,13 @@ City # Appendix D - Country-Specific Interpretative Guidelines (Normative) -NOTE: This appendix provides alternative interpretations of the EV Guidelines for countries that have a language, cultural, technical, or legal reason for deviating from a strict interpretation of the EV Guidelines. More specific information for particular countries may be added to this appendix in the future. +NOTE: This appendix provides alternative interpretations of the EV Guidelines for countries that have a language, cultural, technical, or legal reason for deviating from a strict interpretation of the EV Guidelines. More specific information for particular countries may be added to this appendix in the future. ## 1. Organization Names 1. Non-Latin Organization Name - Where an EV Applicant's organization name is not registered with a QGIS in _Latin_ characters and the Applicant's foreign character organization name and registration have been verified with a QGIS in accordance with these Guidelines, a CA MAY include a Latin character organization name in the EV Certificate. In such a case, the CA MUST follow the procedures laid down in this section. + Where an EV Applicant's organization name is not registered with a QGIS in _Latin_ characters and the Applicant's foreign character organization name and registration have been verified with a QGIS in accordance with these Guidelines, a CA MAY include a Latin character organization name in the EV Certificate. In such a case, the CA MUST follow the procedures laid down in this section. 2. Romanized Names @@ -1989,18 +1993,18 @@ NOTE: This appendix provides alternative interpretations of the EV Guidelines fo If the CA can not rely on a transliteration/Romanization of the registered name using a system officially recognized by the Government in the Applicant's Jurisdiction of Incorporation, then it MUST rely on one of the options below, in order of preference: - A. A system recognized by the International Organization for Standardization (ISO); - B. A system recognized by the United Nations; or - C. A Lawyer's Opinion or Accountant's Letter confirming the proper Romanization of the registered name. + A. A system recognized by the International Organization for Standardization (ISO); + B. A system recognized by the United Nations; or + C. A Lawyer's Opinion or Accountant's Letter confirming the proper Romanization of the registered name. 3. Translated Name - In order to include a Latin character name in the EV certificate that is not a direct Romanization of the registered name (e.g. an English Name) the CA MUST verify that the Latin character name is: + In order to include a Latin character name in the EV certificate that is not a direct Romanization of the registered name (e.g. an English Name) the CA MUST verify that the Latin character name is: - A. Included in the Articles of Incorporation (or equivalent document) filed as part of the organization registration; or - B. Recognized by a QTIS in the Applicant's Jurisdiction of Incorporation as the Applicant's recognized name for tax filings; or - C. Confirmed with a QIIS to be the name associated with the registered organization; or - D. Confirmed by a Verified Legal Opinion or Accountant's Letter to be a translated trading name associated with the registered organization. + A. Included in the Articles of Incorporation (or equivalent document) filed as part of the organization registration; or + B. Recognized by a QTIS in the Applicant's Jurisdiction of Incorporation as the Applicant's recognized name for tax filings; or + C. Confirmed with a QIIS to be the name associated with the registered organization; or + D. Confirmed by a Verified Legal Opinion or Accountant's Letter to be a translated trading name associated with the registered organization. ### Country-Specific Procedures @@ -2010,24 +2014,24 @@ As interpretation of the procedures set out above: 1. Organization Names - A. The Revised Hepburn method of Romanization, as well as Kunrei-shiki and Nihon-shiki methods described in ISO 3602, are acceptable for Japanese Romanizations. - B. The CA MAY verify the Romanized transliteration, language translation (e.g. English name), or other recognized Roman-letter substitute of the Applicant's formal legal name with either a QIIS, Verified Legal Opinion, or Verified Accountant Letter. - C. The CA MAY use the Financial Services Agency to verify a Romanized, translated, or other recognized Roman-letter substitute name. When used, the CA MUST verify that the translated English is recorded in the audited Financial Statements. - D. When relying on Articles of Incorporation to verify a Romanized, translated, or other recognized Roman-letter substitute name, the Articles of Incorporation MUST be accompanied either: by a document, signed with the original Japanese Corporate Stamp, that proves that the Articles of Incorporation are authentic and current, or by a Verified Legal Opinion or a Verified Accountant Letter. The CA MUST verify the authenticity of the Corporate Stamp. - E. A Romanized, translated, or other recognized Roman-lettered substitute name confirmed in accordance with this [Appendix D-1](#d-1-japan) stored in the ROBINS database operated by JIPDEC MAY be relied upon by a CA for determining the allowed organization name during any issuance or renewal process of an EV Certificate without the need to re-perform the above procedures. + A. The Revised Hepburn method of Romanization, as well as Kunrei-shiki and Nihon-shiki methods described in ISO 3602, are acceptable for Japanese Romanizations. + B. The CA MAY verify the Romanized transliteration, language translation (e.g. English name), or other recognized Roman-letter substitute of the Applicant's formal legal name with either a QIIS, Verified Legal Opinion, or Verified Accountant Letter. + C. The CA MAY use the Financial Services Agency to verify a Romanized, translated, or other recognized Roman-letter substitute name. When used, the CA MUST verify that the translated English is recorded in the audited Financial Statements. + D. When relying on Articles of Incorporation to verify a Romanized, translated, or other recognized Roman-letter substitute name, the Articles of Incorporation MUST be accompanied either: by a document, signed with the original Japanese Corporate Stamp, that proves that the Articles of Incorporation are authentic and current, or by a Verified Legal Opinion or a Verified Accountant Letter. The CA MUST verify the authenticity of the Corporate Stamp. + E. A Romanized, translated, or other recognized Roman-lettered substitute name confirmed in accordance with this [Appendix D-1](#d-1-japan) stored in the ROBINS database operated by JIPDEC MAY be relied upon by a CA for determining the allowed organization name during any issuance or renewal process of an EV Certificate without the need to re-perform the above procedures. 2. Accounting Practitioner In Japan: - A. Accounting Practitioner includes either a certified public accountant (公認会計士 - Konin-kaikei-shi) or a licensed tax accountant (税理士 – Zei-ri-shi). - B. The CA MUST verify the professional status of the Accounting Practitioner through direct contact with the relevant local member association that is affiliated with either the Japanese Institute of Certified Public Accountants ([http://www.hp.jicpa.or.jp](http://www.hp.jicpa.or.jp/)), the Japan Federation of Certified Tax Accountant's Associations ([http://www.nichizeiren.or.jp](http://www.nichizeiren.or.jp/)), or any other authoritative source recognized by the Japanese Ministry of Finance ([http://www.mof.go.jp](http://www.mof.go.jp/)) as providing the current registration status of such professionals. + A. Accounting Practitioner includes either a certified public accountant (公認会計士 - Konin-kaikei-shi) or a licensed tax accountant (税理士 – Zei-ri-shi). + B. The CA MUST verify the professional status of the Accounting Practitioner through direct contact with the relevant local member association that is affiliated with either the Japanese Institute of Certified Public Accountants ([http://www.hp.jicpa.or.jp](http://www.hp.jicpa.or.jp/)), the Japan Federation of Certified Tax Accountant's Associations ([http://www.nichizeiren.or.jp](http://www.nichizeiren.or.jp/)), or any other authoritative source recognized by the Japanese Ministry of Finance ([http://www.mof.go.jp](http://www.mof.go.jp/)) as providing the current registration status of such professionals. 3. Legal Practitioner In Japan: - A. Legal Practitioner includes any of the following: + A. Legal Practitioner includes any of the following: - a licensed lawyer (弁護士 - Ben-go-shi), - a judicial scrivener (司法書士 - Shiho-sho-shi lawyer), @@ -2036,7 +2040,7 @@ As interpretation of the procedures set out above: For purposes of the EV Guidelines, a Japanese Notary Public is considered equivalent to a Latin Notary. - B. The CA MUST verify the professional status of the Legal Practitioner by direct contact through the relevant local member association that is affiliated with one of the following national associations: + B. The CA MUST verify the professional status of the Legal Practitioner by direct contact through the relevant local member association that is affiliated with one of the following national associations: - the Japan Federation of Bar Associations ([http://www.nichibenren.or.jp](http://www.nichibenren.or.jp/)), - the Japan Federation of Shiho-Shoshi Lawyer's Associations ([http://www.shiho-shoshi.or.jp](http://www.shiho-shoshi.or.jp/)), @@ -2046,9 +2050,9 @@ As interpretation of the procedures set out above: # Appendix E - Sample Contract Signer's Representation/Warranty (Informative) -A CA may rely on the Contract Signer's authority to enter into the Subscriber Agreement using a representation/warranty executed by the Contract Signer. An example of an acceptable warranty is as follows: +A CA may rely on the Contract Signer's authority to enter into the Subscriber Agreement using a representation/warranty executed by the Contract Signer. An example of an acceptable warranty is as follows: -[CA] and Applicant are entering into a legally valid and enforceable Subscriber Agreement that creates extensive obligations on Applicant. An EV Certificate serves as a form of digital identity for Applicant. The loss or misuse of this identity can result in great harm to the Applicant. By signing this Subscriber Agreement, the contract signer acknowledges that they have the authority to obtain the digital equivalent of a company stamp, seal, or (where applicable) officer's signature to establish the authenticity of the company's website, and that [Applicant name] is responsible for all uses of its EV Certificate. By signing this Agreement on behalf of [Applicant name], the contract signer represents that the contract signer +[CA] and Applicant are entering into a legally valid and enforceable Subscriber Agreement that creates extensive obligations on Applicant. An EV Certificate serves as a form of digital identity for Applicant. The loss or misuse of this identity can result in great harm to the Applicant. By signing this Subscriber Agreement, the contract signer acknowledges that they have the authority to obtain the digital equivalent of a company stamp, seal, or (where applicable) officer's signature to establish the authenticity of the company's website, and that [Applicant name] is responsible for all uses of its EV Certificate. By signing this Agreement on behalf of [Applicant name], the contract signer represents that the contract signer i. is acting as an authorized representative of [Applicant name], ii. is expressly authorized by [Applicant name] to sign Subscriber Agreements and approve EV Certificate requests on Applicant's behalf, and @@ -2116,16 +2120,48 @@ END The following Registration Schemes are currently recognized as valid under these guidelines: -- **NTR**: - - The information carried in this field shall be the same as held in Subject Registration Number Field as specified in [Section 7.1.4.2.5](#71425-subject-registration-number-field) and the country code used in the Registration Scheme identifier shall match that of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). - - Where the Subject Jurisdiction of Incorporation or Registration Field in 9.2.4 includes more than the country code, the additional locality information shall be included as specified in [Section 7.1.4.2.8](#71428-subject-organization-identifier-field) and/or [Section 7.1.2.2](#7122-cabrowser-forum-organization-identifier-extension). - -- **VAT**: - - Reference allocated by the national tax authorities to a Legal Entity. This information shall be validated using information provided by the national tax authority against the organization as identified by the Subject Organization Name Field (see [Section 7.1.4.2.1](#71421-subject-organization-name-field)) and Subject Registration Number Field (see Section 7.1.4.2.5](#71425-subject-registration-number-field)) within the context of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). For the purpose of identifying tax authorities, the country prefix described in article 215 of EU Council Directive 2006/112/EC, as amended, MAY be used instead of the ISO 3166 2-letter country codes. - -- **PSD**: - - Authorization number as specified in ETSI TS 119 495 clause 4.4 allocated to a payment service provider and containing the information as specified in ETSI TS 119 495 clause 5.2.1. This information SHALL be obtained directly from the national competent authority register for payment services or from an information source approved by a government agency, regulatory body, or legislation for this purpose. This information SHALL be validated by being matched directly or indirectly (for example, by matching a globally unique registration number) against the organization as identified by the Subject Organization Name Field (see [Section 7.1.4.2.1](#71421-subject-organization-name-field)) and Subject Registration Number Field (see [Section 7.1.4.2.5](#71425-subject-registration-number-field)) within the context of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). The stated address of the organization combined with the organization name SHALL NOT be the only information used to disambiguate the organization. +* **NTR**: + + The information carried in this field shall be the same as held in + Subject Registration Number Field as specified in + [Section 7.1.4.2.5](#71425-subject-registration-number-field) and the country code + used in the Registration Scheme identifier shall match that of the + subject’s jurisdiction as specified in + [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). + + Where the Subject Jurisdiction of Incorporation or Registration Field in 9.2.4 + includes more than the country code, the additional locality information shall + be included as specified in [Section 7.1.4.2.8](#71428-subject-organization-identifier-field) + and/or [Section 7.1.2.2](#7122-cabrowser-forum-organization-identifier-extension). + +* **VAT**: + + Reference allocated by the national tax authorities to a Legal Entity. This + information shall be validated using information provided by the national tax + authority against the organization as identified by the Subject Organization + Name Field (see [Section 7.1.4.2.1](#71421-subject-organization-name-field)) and + Subject Registration Number Field (see + Section 7.1.4.2.5](#71425-subject-registration-number-field)) within the context of + the subject’s jurisdiction as specified in + [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). + For the purpose of identifying tax authorities, the country prefix described in article 215 of + EU Council Directive 2006/112/EC, as amended, MAY be used instead of the ISO 3166 2-letter country codes. + + * **PSD**: + + Authorization number as specified in ETSI TS 119 495 clause 4.4 + allocated to a payment service provider and containing the information as + specified in ETSI TS 119 495 clause 5.2.1. This information SHALL be + obtained directly from the national competent authority register for + payment services or from an information source approved by a government + agency, regulatory body, or legislation for this purpose. This information + SHALL be validated by being matched directly or indirectly (for example, by + matching a globally unique registration number) against the organization as + identified by the Subject Organization Name Field (see + [Section 7.1.4.2.1](#71421-subject-organization-name-field)) and + Subject Registration Number Field (see + [Section 7.1.4.2.5](#71425-subject-registration-number-field)) within the context of + the subject’s jurisdiction as specified in + [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). + The stated address of the organization combined with the organization name + SHALL NOT be the only information used to disambiguate the organization. From 9ee21a449efb3259a8f6c8a373d3970c0d83d3df Mon Sep 17 00:00:00 2001 From: dzacharo Date: Mon, 1 Dec 2025 17:21:51 +0200 Subject: [PATCH 066/121] Addresses #580 and adds internal links to sections 3.2.2.8 and 7.2.2. --- docs/BR.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index c490acdb..115ef913 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1489,15 +1489,15 @@ No stipulation. The CA MAY support revocation of Short-lived Subscriber Certificates. -With the exception of Short-lived Subscriber Certificates, the CA SHALL revoke a Certificate within 24 hours and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs: +With the exception of Short-lived Subscriber Certificates, the CA SHALL revoke a Certificate within 24 hours and use the corresponding CRLReason (see [Section 7.2.2](#722-crl-and-crl-entry-extensions)) if one or more of the following occurs: 1. The Subscriber requests in writing, without specifying a CRLreason, that the CA revoke the Certificate (CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL); 2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization (CRLReason #9, privilegeWithdrawn); 3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise (CRLReason #1, keyCompromise); 4. 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, including but not limited to those identified in [Section 6.1.1.3(5)](#6113-subscriber-key-pair-generation) (CRLReason #1, keyCompromise); -5. The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon (CRLReason #4, superseded). +5. The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon, including cases where the CA failed to perform CAA checking correctly or where issuance was not permitted according to Section [3.2.2.8](#3228-caa-records) (CAA Records) (CRLReason '#'4, superseded). -With the exception of Short-lived Subscriber Certificates, the CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs: +With the exception of Short-lived Subscriber Certificates, the CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days and use the corresponding CRLReason (see [Section 7.2.2](#722-crl-and-crl-entry-extensions)) if one or more of the following occurs: 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) (CRLReason #4, superseded); 7. The CA obtains evidence that the Certificate was misused (CRLReason #9, privilegeWithdrawn); From c1d7ec1d588d17c4181c9c6daac588548b8e59da Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 19:56:44 +0100 Subject: [PATCH 067/121] #432 testing numbering change --- docs/EVG.md | 21 ++++++--------------- 1 file changed, 6 insertions(+), 15 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 1f5c0d2b..d7e09096 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -411,24 +411,15 @@ This part of the Guidelines sets forth Verification Requirements and Acceptable Before issuing an EV Certificate, the CA MUST ensure that all Subject organization information to be included in the EV Certificate conforms to the requirements of, and is verified in accordance with, these Guidelines and matches the information confirmed and documented by the CA pursuant to its verification processes. Such verification processes are intended to accomplish the following: 1. Verify Applicant's existence and identity, including; - - A. Verify the Applicant's legal existence and identity (as more fully set forth in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity)), - - B. Verify the Applicant's physical existence (business presence at a physical address), and - - C. Verify the Applicant's operational existence (business activity). - + a. Verify the Applicant's legal existence and identity (as more fully set forth in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity)), + a. Verify the Applicant's physical existence (business presence at a physical address), and + c. Verify the Applicant's operational existence (business activity). 2. Verify the Applicant is a registered holder, or has control, of the Domain Name(s) to be included in the EV Certificate; - 3. Verify a reliable means of communication with the entity to be named as the Subject in the Certificate; - 4. Verify the Applicant's authorization for the EV Certificate, including; - - A. Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester, - - B. Verify that a Contract Signer signed the Subscriber Agreement or that a duly authorized Applicant Representative acknowledged and agreed to the Terms of Use; and - - C. Verify that a Certificate Approver has signed or otherwise approved the EV Certificate Request. + a Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester, + b. Verify that a Contract Signer signed the Subscriber Agreement or that a duly authorized Applicant Representative acknowledged and agreed to the Terms of Use; and + c. Verify that a Certificate Approver has signed or otherwise approved the EV Certificate Request. ##### 3.2.2.1.2 Acceptable Methods of Verification – Overview From 18acd1f97b594cc2c8bc85131f9dcda21ce59b81 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 20:00:31 +0100 Subject: [PATCH 068/121] #432 testing numbering --- docs/EVG.md | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index d7e09096..63b8da2f 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -431,10 +431,10 @@ Effective as of 1 October 2020, prior to the use of an Incorporating Agency or R This Agency Information SHALL include at least the following: -* Sufficient information to unambiguously identify the Incorporating Agency or Registration Agency (such as a name, jurisdiction, and website); and, -* The accepted value or values for each of the `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1), `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2), and `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) fields, when a certificate is issued using information from that Incorporating Agency or Registration Agency, indicating the jurisdiction(s) that the Agency is appropriate for; and, -* The acceptable form or syntax of Registration Numbers used by the Incorporating Agency or Registration Agency, if the CA restricts such Numbers to an acceptable form or syntax; and, -* A revision history that includes a unique version number and date of publication for any additions, modifications, and/or removals from this list. +- Sufficient information to unambiguously identify the Incorporating Agency or Registration Agency (such as a name, jurisdiction, and website); and, +- The accepted value or values for each of the `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1), `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2), and `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) fields, when a certificate is issued using information from that Incorporating Agency or Registration Agency, indicating the jurisdiction(s) that the Agency is appropriate for; and, +- The acceptable form or syntax of Registration Numbers used by the Incorporating Agency or Registration Agency, if the CA restricts such Numbers to an acceptable form or syntax; and, +- A revision history that includes a unique version number and date of publication for any additions, modifications, and/or removals from this list. The CA MUST document where to obtain this information within Section 3.2 of the CA's Certificate Policy and/or Certification Practice Statement. @@ -446,29 +446,29 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo 1. **Private Organization Subjects** - A. **Legal Existence**: Verify that the Applicant is a legally recognized entity, in existence and validly formed (e.g., incorporated) with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration, and not designated on the records of the Incorporating or Registration Agency by labels such as "inactive", "invalid", "not current", or the equivalent. - B. **Organization Name**: Verify that the Applicant's formal legal name as recorded with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: Obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Incorporation or Registration. - D. **Registered Agent**: Obtain the identity and address of the Applicant's Registered Agent or Registered Office (as applicable in the Applicant's Jurisdiction of Incorporation or Registration). + a. **Legal Existence**: Verify that the Applicant is a legally recognized entity, in existence and validly formed (e.g., incorporated) with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration, and not designated on the records of the Incorporating or Registration Agency by labels such as "inactive", "invalid", "not current", or the equivalent. + b. **Organization Name**: Verify that the Applicant's formal legal name as recorded with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration matches the Applicant's name in the EV Certificate Request. + c. **Registration Number**: Obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Incorporation or Registration. + d. **Registered Agent**: Obtain the identity and address of the Applicant's Registered Agent or Registered Office (as applicable in the Applicant's Jurisdiction of Incorporation or Registration). 2. **Government Entity Subjects** - A. **Legal Existence**: Verify that the Applicant is a legally recognized Government Entity, in existence in the political subdivision in which such Government Entity operates. - B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of incorporation, registration, or formation, or the identifier for the legislative act that created the Government Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is a Government Entity. + a. **Legal Existence**: Verify that the Applicant is a legally recognized Government Entity, in existence in the political subdivision in which such Government Entity operates. + b. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. + c. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of incorporation, registration, or formation, or the identifier for the legislative act that created the Government Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is a Government Entity. 3. **Business Entity Subjects** - A. **Legal Existence**: Verify that the Applicant is engaged in business under the name submitted by the Applicant in the Application. - B. **Organization Name**: Verify that the Applicant's formal legal name as recognized by the Registration Agency in the Applicant's Jurisdiction of Registration matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: Attempt to obtain the specific unique Registration Number assigned to the Applicant by the Registration Agency in the Applicant's Jurisdiction of Registration. Where the Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Registration. - D. **Principal Individual**: Verify the identity of the identified Principal Individual. + a. **Legal Existence**: Verify that the Applicant is engaged in business under the name submitted by the Applicant in the Application. + b. **Organization Name**: Verify that the Applicant's formal legal name as recognized by the Registration Agency in the Applicant's Jurisdiction of Registration matches the Applicant's name in the EV Certificate Request. + c. **Registration Number**: Attempt to obtain the specific unique Registration Number assigned to the Applicant by the Registration Agency in the Applicant's Jurisdiction of Registration. Where the Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Registration. + d. **Principal Individual**: Verify the identity of the identified Principal Individual. 4. **Non-Commercial Entity Subjects (International Organizations)** - A. **Legal Existence**: Verify that the Applicant is a legally recognized International Organization Entity. - B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of formation, or the identifier for the legislative act that created the International Organization Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is an International Organization Entity. + a. **Legal Existence**: Verify that the Applicant is a legally recognized International Organization Entity. + b. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. + c. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of formation, or the identifier for the legislative act that created the International Organization Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is an International Organization Entity. ##### 3.2.2.2.2 Acceptable Method of Verification From f61daed0d7f8c179af879e816f7c9c0fe3fbf5af Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 20:07:15 +0100 Subject: [PATCH 069/121] #432 numbering 3.2.2.2.2 --- docs/EVG.md | 70 ++++++++++++++++++++++++++--------------------------- 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 63b8da2f..d85cb657 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -487,58 +487,58 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo 4. **Principal Individual**: A Principal Individual associated with the Business Entity MUST be validated in a face-to-face setting. The CA MAY rely upon a face-to-face validation of the Principal Individual performed by the Registration Agency, provided that the CA has evaluated the validation procedure and concluded that it satisfies the requirements of the Guidelines for face-to-face validation procedures. Where no face-to-face validation was conducted by the Registration Agency, or the Registration Agency's face-to-face validation procedure does not satisfy the requirements of the Guidelines, the CA SHALL perform face-to-face validation. - A. **Face-To-Face Validation**: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicant's jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator: + A. **Face-To-Face Validation**: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicant's jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator: - i. A Personal Statement that includes the following information: + i. A Personal Statement that includes the following information: - 1. Full name or names by which a person is, or has been, known (including all other names used); - 2. Residential Address at which he/she can be located; - 3. Date of birth; and - 4. An affirmation that all of the information contained in the Certificate Request is true and correct. + 1. Full name or names by which a person is, or has been, known (including all other names used); + 2. Residential Address at which he/she can be located; + 3. Date of birth; and + 4. An affirmation that all of the information contained in the Certificate Request is true and correct. - ii. A current signed government-issued identification document that includes a photo of the Individual and is signed by the Individual such as: + ii. A current signed government-issued identification document that includes a photo of the Individual and is signed by the Individual such as: - 1. A passport; - 2. A driver's license; - 3. A personal identification card; - 4. A concealed weapons permit; or - 5. A military ID. + 1. A passport; + 2. A driver's license; + 3. A personal identification card; + 4. A concealed weapons permit; or + 5. A military ID. - iii. At least two secondary documentary evidences to establish his/her identity that include the name of the Individual, one of which MUST be from a financial institution. + iii. At least two secondary documentary evidences to establish his/her identity that include the name of the Individual, one of which MUST be from a financial institution. - 1. Acceptable financial institution documents include: + 1. Acceptable financial institution documents include: - a. A major credit card, provided that it contains an expiration date and it has not expired' - b. A debit card from a regulated financial institution, provided that it contains an expiration date and it has not expired, - c. A mortgage statement from a recognizable lender that is less than six months old, - d. A bank statement from a regulated financial institution that is less than six months old. + a. A major credit card, provided that it contains an expiration date and it has not expired' + b. A debit card from a regulated financial institution, provided that it contains an expiration date and it has not expired, + c. A mortgage statement from a recognizable lender that is less than six months old, + d. A bank statement from a regulated financial institution that is less than six months old. - 2. Acceptable non-financial documents include: + 2. Acceptable non-financial documents include: - a. Recent original utility bills or certificates from a utility company confirming the arrangement to pay for the services at a fixed address (not a mobile/cellular telephone bill), - b. A copy of a statement for payment of a lease, provided that the statement is dated within the past six months, - c. A certified copy of a birth certificate, - d. A local authority tax bill for the current year, - e. A certified copy of a court order, such as a divorce certificate, annulment papers, or adoption papers. + a. Recent original utility bills or certificates from a utility company confirming the arrangement to pay for the services at a fixed address (not a mobile/cellular telephone bill), + b. A copy of a statement for payment of a lease, provided that the statement is dated within the past six months, + c. A certified copy of a birth certificate, + d. A local authority tax bill for the current year, + e. A certified copy of a court order, such as a divorce certificate, annulment papers, or adoption papers. - The Third-Party Validator performing the face-to-face validation MUST: + The Third-Party Validator performing the face-to-face validation MUST: - i. Attest to the signing of the Personal Statement and the identity of the signer; and - ii. Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original. + i. Attest to the signing of the Personal Statement and the identity of the signer; and + ii. Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original. - B. **Verification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant's jurisdiction), lawyer, or accountant in the jurisdiction of the Individual's residency, and that the Third-Party Validator actually did perform the services and did attest to the signature of the Individual. + B. **Verification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant's jurisdiction), lawyer, or accountant in the jurisdiction of the Individual's residency, and that the Third-Party Validator actually did perform the services and did attest to the signature of the Individual. - C. **Cross-checking of Information**: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that: + C. **Cross-checking of Information**: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that: - i. the CA confirms their authenticity (not improperly modified when compared with the underlying original) with the Third-Party Validator; and - ii. electronic copies of similar kinds of documents are recognized as legal substitutes for originals under the laws of the CA's jurisdiction. + i. the CA confirms their authenticity (not improperly modified when compared with the underlying original) with the Third-Party Validator; and + ii. electronic copies of similar kinds of documents are recognized as legal substitutes for originals under the laws of the CA's jurisdiction. 5. **Non-Commercial Entity Subjects (International Organization)**: Unless verified under subsection (6), all items listed in [Section 3.2.2.2.1](#32221-verification-requirements) (4) MUST be verified either: - A. With reference to the constituent document under which the International Organization was formed; or - B. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or - C. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at . - D. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency. + A. With reference to the constituent document under which the International Organization was formed; or + B. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or + C. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at . + D. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency. 6. The CA may rely on a Verified Professional Letter to establish the Applicant's information listed in (1)-(5) above if: From 244836c6111cb22fc9167a58c26f093fdfb7c3ef Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 20:12:10 +0100 Subject: [PATCH 070/121] #432 numbering 3.2.2.2.2 --- docs/EVG.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index d85cb657..23538aa9 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -491,29 +491,29 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo i. A Personal Statement that includes the following information: - 1. Full name or names by which a person is, or has been, known (including all other names used); - 2. Residential Address at which he/she can be located; - 3. Date of birth; and - 4. An affirmation that all of the information contained in the Certificate Request is true and correct. + 1. Full name or names by which a person is, or has been, known (including all other names used); + 2. Residential Address at which he/she can be located; + 3. Date of birth; and + 4. An affirmation that all of the information contained in the Certificate Request is true and correct. ii. A current signed government-issued identification document that includes a photo of the Individual and is signed by the Individual such as: - 1. A passport; - 2. A driver's license; - 3. A personal identification card; - 4. A concealed weapons permit; or - 5. A military ID. + 1. A passport; + 2. A driver's license; + 3. A personal identification card; + 4. A concealed weapons permit; or + 5. A military ID. iii. At least two secondary documentary evidences to establish his/her identity that include the name of the Individual, one of which MUST be from a financial institution. - 1. Acceptable financial institution documents include: + 1. Acceptable financial institution documents include: a. A major credit card, provided that it contains an expiration date and it has not expired' b. A debit card from a regulated financial institution, provided that it contains an expiration date and it has not expired, c. A mortgage statement from a recognizable lender that is less than six months old, d. A bank statement from a regulated financial institution that is less than six months old. - 2. Acceptable non-financial documents include: + 2. Acceptable non-financial documents include: a. Recent original utility bills or certificates from a utility company confirming the arrangement to pay for the services at a fixed address (not a mobile/cellular telephone bill), b. A copy of a statement for payment of a lease, provided that the statement is dated within the past six months, From 14d79e41810f25271dc6e0d75e1d68318b78405d Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 20:14:45 +0100 Subject: [PATCH 071/121] #432 numbering 3.2.2.2.2 --- docs/EVG.md | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 23538aa9..68ccef4b 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -487,33 +487,33 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo 4. **Principal Individual**: A Principal Individual associated with the Business Entity MUST be validated in a face-to-face setting. The CA MAY rely upon a face-to-face validation of the Principal Individual performed by the Registration Agency, provided that the CA has evaluated the validation procedure and concluded that it satisfies the requirements of the Guidelines for face-to-face validation procedures. Where no face-to-face validation was conducted by the Registration Agency, or the Registration Agency's face-to-face validation procedure does not satisfy the requirements of the Guidelines, the CA SHALL perform face-to-face validation. - A. **Face-To-Face Validation**: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicant's jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator: + a. **Face-To-Face Validation**: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicant's jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator: i. A Personal Statement that includes the following information: - 1. Full name or names by which a person is, or has been, known (including all other names used); - 2. Residential Address at which he/she can be located; - 3. Date of birth; and - 4. An affirmation that all of the information contained in the Certificate Request is true and correct. + 1. Full name or names by which a person is, or has been, known (including all other names used); + 2. Residential Address at which he/she can be located; + 3. Date of birth; and + 4. An affirmation that all of the information contained in the Certificate Request is true and correct. ii. A current signed government-issued identification document that includes a photo of the Individual and is signed by the Individual such as: - 1. A passport; - 2. A driver's license; - 3. A personal identification card; - 4. A concealed weapons permit; or - 5. A military ID. + 1. A passport; + 2. A driver's license; + 3. A personal identification card; + 4. A concealed weapons permit; or + 5. A military ID. iii. At least two secondary documentary evidences to establish his/her identity that include the name of the Individual, one of which MUST be from a financial institution. - 1. Acceptable financial institution documents include: + 1. Acceptable financial institution documents include: a. A major credit card, provided that it contains an expiration date and it has not expired' b. A debit card from a regulated financial institution, provided that it contains an expiration date and it has not expired, c. A mortgage statement from a recognizable lender that is less than six months old, d. A bank statement from a regulated financial institution that is less than six months old. - 2. Acceptable non-financial documents include: + 2. Acceptable non-financial documents include: a. Recent original utility bills or certificates from a utility company confirming the arrangement to pay for the services at a fixed address (not a mobile/cellular telephone bill), b. A copy of a statement for payment of a lease, provided that the statement is dated within the past six months, @@ -526,19 +526,19 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo i. Attest to the signing of the Personal Statement and the identity of the signer; and ii. Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original. - B. **Verification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant's jurisdiction), lawyer, or accountant in the jurisdiction of the Individual's residency, and that the Third-Party Validator actually did perform the services and did attest to the signature of the Individual. + b. **Verification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant's jurisdiction), lawyer, or accountant in the jurisdiction of the Individual's residency, and that the Third-Party Validator actually did perform the services and did attest to the signature of the Individual. - C. **Cross-checking of Information**: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that: + c. **Cross-checking of Information**: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that: i. the CA confirms their authenticity (not improperly modified when compared with the underlying original) with the Third-Party Validator; and ii. electronic copies of similar kinds of documents are recognized as legal substitutes for originals under the laws of the CA's jurisdiction. 5. **Non-Commercial Entity Subjects (International Organization)**: Unless verified under subsection (6), all items listed in [Section 3.2.2.2.1](#32221-verification-requirements) (4) MUST be verified either: - A. With reference to the constituent document under which the International Organization was formed; or - B. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or - C. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at . - D. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency. + a. With reference to the constituent document under which the International Organization was formed; or + b. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or + c. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at . + d. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency. 6. The CA may rely on a Verified Professional Letter to establish the Applicant's information listed in (1)-(5) above if: From 310b5ed6ff7ca84658145e5b37751fe43ba59bd8 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 20:16:51 +0100 Subject: [PATCH 072/121] #432 numbering 3.2.2.2.2 --- docs/EVG.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 68ccef4b..9cca5c85 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -491,29 +491,29 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo i. A Personal Statement that includes the following information: - 1. Full name or names by which a person is, or has been, known (including all other names used); - 2. Residential Address at which he/she can be located; - 3. Date of birth; and - 4. An affirmation that all of the information contained in the Certificate Request is true and correct. + 1. Full name or names by which a person is, or has been, known (including all other names used); + 2. Residential Address at which he/she can be located; + 3. Date of birth; and + 4. An affirmation that all of the information contained in the Certificate Request is true and correct. ii. A current signed government-issued identification document that includes a photo of the Individual and is signed by the Individual such as: - 1. A passport; - 2. A driver's license; - 3. A personal identification card; - 4. A concealed weapons permit; or - 5. A military ID. + 1. A passport; + 2. A driver's license; + 3. A personal identification card; + 4. A concealed weapons permit; or + 5. A military ID. iii. At least two secondary documentary evidences to establish his/her identity that include the name of the Individual, one of which MUST be from a financial institution. - 1. Acceptable financial institution documents include: + 1. Acceptable financial institution documents include: a. A major credit card, provided that it contains an expiration date and it has not expired' b. A debit card from a regulated financial institution, provided that it contains an expiration date and it has not expired, c. A mortgage statement from a recognizable lender that is less than six months old, d. A bank statement from a regulated financial institution that is less than six months old. - 2. Acceptable non-financial documents include: + 2. Acceptable non-financial documents include: a. Recent original utility bills or certificates from a utility company confirming the arrangement to pay for the services at a fixed address (not a mobile/cellular telephone bill), b. A copy of a statement for payment of a lease, provided that the statement is dated within the past six months, From 997af467d91fb970f09a25b24de0c48a70de2041 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 20:20:24 +0100 Subject: [PATCH 073/121] #432 numbering 3.2.2.2.2 --- docs/EVG.md | 62 ++++++++++++++++++++++++++--------------------------- 1 file changed, 31 insertions(+), 31 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 9cca5c85..63b8da2f 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -487,58 +487,58 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo 4. **Principal Individual**: A Principal Individual associated with the Business Entity MUST be validated in a face-to-face setting. The CA MAY rely upon a face-to-face validation of the Principal Individual performed by the Registration Agency, provided that the CA has evaluated the validation procedure and concluded that it satisfies the requirements of the Guidelines for face-to-face validation procedures. Where no face-to-face validation was conducted by the Registration Agency, or the Registration Agency's face-to-face validation procedure does not satisfy the requirements of the Guidelines, the CA SHALL perform face-to-face validation. - a. **Face-To-Face Validation**: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicant's jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator: + A. **Face-To-Face Validation**: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicant's jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator: - i. A Personal Statement that includes the following information: + i. A Personal Statement that includes the following information: 1. Full name or names by which a person is, or has been, known (including all other names used); 2. Residential Address at which he/she can be located; 3. Date of birth; and 4. An affirmation that all of the information contained in the Certificate Request is true and correct. - ii. A current signed government-issued identification document that includes a photo of the Individual and is signed by the Individual such as: + ii. A current signed government-issued identification document that includes a photo of the Individual and is signed by the Individual such as: - 1. A passport; - 2. A driver's license; - 3. A personal identification card; - 4. A concealed weapons permit; or - 5. A military ID. + 1. A passport; + 2. A driver's license; + 3. A personal identification card; + 4. A concealed weapons permit; or + 5. A military ID. - iii. At least two secondary documentary evidences to establish his/her identity that include the name of the Individual, one of which MUST be from a financial institution. + iii. At least two secondary documentary evidences to establish his/her identity that include the name of the Individual, one of which MUST be from a financial institution. - 1. Acceptable financial institution documents include: + 1. Acceptable financial institution documents include: - a. A major credit card, provided that it contains an expiration date and it has not expired' - b. A debit card from a regulated financial institution, provided that it contains an expiration date and it has not expired, - c. A mortgage statement from a recognizable lender that is less than six months old, - d. A bank statement from a regulated financial institution that is less than six months old. + a. A major credit card, provided that it contains an expiration date and it has not expired' + b. A debit card from a regulated financial institution, provided that it contains an expiration date and it has not expired, + c. A mortgage statement from a recognizable lender that is less than six months old, + d. A bank statement from a regulated financial institution that is less than six months old. - 2. Acceptable non-financial documents include: + 2. Acceptable non-financial documents include: - a. Recent original utility bills or certificates from a utility company confirming the arrangement to pay for the services at a fixed address (not a mobile/cellular telephone bill), - b. A copy of a statement for payment of a lease, provided that the statement is dated within the past six months, - c. A certified copy of a birth certificate, - d. A local authority tax bill for the current year, - e. A certified copy of a court order, such as a divorce certificate, annulment papers, or adoption papers. + a. Recent original utility bills or certificates from a utility company confirming the arrangement to pay for the services at a fixed address (not a mobile/cellular telephone bill), + b. A copy of a statement for payment of a lease, provided that the statement is dated within the past six months, + c. A certified copy of a birth certificate, + d. A local authority tax bill for the current year, + e. A certified copy of a court order, such as a divorce certificate, annulment papers, or adoption papers. - The Third-Party Validator performing the face-to-face validation MUST: + The Third-Party Validator performing the face-to-face validation MUST: - i. Attest to the signing of the Personal Statement and the identity of the signer; and - ii. Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original. + i. Attest to the signing of the Personal Statement and the identity of the signer; and + ii. Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original. - b. **Verification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant's jurisdiction), lawyer, or accountant in the jurisdiction of the Individual's residency, and that the Third-Party Validator actually did perform the services and did attest to the signature of the Individual. + B. **Verification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant's jurisdiction), lawyer, or accountant in the jurisdiction of the Individual's residency, and that the Third-Party Validator actually did perform the services and did attest to the signature of the Individual. - c. **Cross-checking of Information**: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that: + C. **Cross-checking of Information**: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that: - i. the CA confirms their authenticity (not improperly modified when compared with the underlying original) with the Third-Party Validator; and - ii. electronic copies of similar kinds of documents are recognized as legal substitutes for originals under the laws of the CA's jurisdiction. + i. the CA confirms their authenticity (not improperly modified when compared with the underlying original) with the Third-Party Validator; and + ii. electronic copies of similar kinds of documents are recognized as legal substitutes for originals under the laws of the CA's jurisdiction. 5. **Non-Commercial Entity Subjects (International Organization)**: Unless verified under subsection (6), all items listed in [Section 3.2.2.2.1](#32221-verification-requirements) (4) MUST be verified either: - a. With reference to the constituent document under which the International Organization was formed; or - b. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or - c. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at . - d. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency. + A. With reference to the constituent document under which the International Organization was formed; or + B. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or + C. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at . + D. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency. 6. The CA may rely on a Verified Professional Letter to establish the Applicant's information listed in (1)-(5) above if: From 1f6f0e7ab427f9897e71e5c9df8a185cac3b5eb8 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 20:24:41 +0100 Subject: [PATCH 074/121] #432 numbering 3.2.2.2.2 --- docs/EVG.md | 70 ++++++++++++++++++++++++++--------------------------- 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 63b8da2f..8c4379be 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -487,58 +487,58 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo 4. **Principal Individual**: A Principal Individual associated with the Business Entity MUST be validated in a face-to-face setting. The CA MAY rely upon a face-to-face validation of the Principal Individual performed by the Registration Agency, provided that the CA has evaluated the validation procedure and concluded that it satisfies the requirements of the Guidelines for face-to-face validation procedures. Where no face-to-face validation was conducted by the Registration Agency, or the Registration Agency's face-to-face validation procedure does not satisfy the requirements of the Guidelines, the CA SHALL perform face-to-face validation. - A. **Face-To-Face Validation**: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicant's jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator: + A. **Face-To-Face Validation**: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicant's jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator: - i. A Personal Statement that includes the following information: + i. A Personal Statement that includes the following information: - 1. Full name or names by which a person is, or has been, known (including all other names used); - 2. Residential Address at which he/she can be located; - 3. Date of birth; and - 4. An affirmation that all of the information contained in the Certificate Request is true and correct. + 1. Full name or names by which a person is, or has been, known (including all other names used); + 2. Residential Address at which he/she can be located; + 3. Date of birth; and + 4. An affirmation that all of the information contained in the Certificate Request is true and correct. - ii. A current signed government-issued identification document that includes a photo of the Individual and is signed by the Individual such as: + ii. A current signed government-issued identification document that includes a photo of the Individual and is signed by the Individual such as: - 1. A passport; - 2. A driver's license; - 3. A personal identification card; - 4. A concealed weapons permit; or - 5. A military ID. + 1. A passport; + 2. A driver's license; + 3. A personal identification card; + 4. A concealed weapons permit; or + 5. A military ID. - iii. At least two secondary documentary evidences to establish his/her identity that include the name of the Individual, one of which MUST be from a financial institution. + iii. At least two secondary documentary evidences to establish his/her identity that include the name of the Individual, one of which MUST be from a financial institution. - 1. Acceptable financial institution documents include: + 1. Acceptable financial institution documents include: - a. A major credit card, provided that it contains an expiration date and it has not expired' - b. A debit card from a regulated financial institution, provided that it contains an expiration date and it has not expired, - c. A mortgage statement from a recognizable lender that is less than six months old, - d. A bank statement from a regulated financial institution that is less than six months old. + a. A major credit card, provided that it contains an expiration date and it has not expired' + b. A debit card from a regulated financial institution, provided that it contains an expiration date and it has not expired, + c. A mortgage statement from a recognizable lender that is less than six months old, + d. A bank statement from a regulated financial institution that is less than six months old. - 2. Acceptable non-financial documents include: + 2. Acceptable non-financial documents include: - a. Recent original utility bills or certificates from a utility company confirming the arrangement to pay for the services at a fixed address (not a mobile/cellular telephone bill), - b. A copy of a statement for payment of a lease, provided that the statement is dated within the past six months, - c. A certified copy of a birth certificate, - d. A local authority tax bill for the current year, - e. A certified copy of a court order, such as a divorce certificate, annulment papers, or adoption papers. + a. Recent original utility bills or certificates from a utility company confirming the arrangement to pay for the services at a fixed address (not a mobile/cellular telephone bill), + b. A copy of a statement for payment of a lease, provided that the statement is dated within the past six months, + c. A certified copy of a birth certificate, + d. A local authority tax bill for the current year, + e. A certified copy of a court order, such as a divorce certificate, annulment papers, or adoption papers. - The Third-Party Validator performing the face-to-face validation MUST: + The Third-Party Validator performing the face-to-face validation MUST: - i. Attest to the signing of the Personal Statement and the identity of the signer; and - ii. Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original. + i. Attest to the signing of the Personal Statement and the identity of the signer; and + ii. Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original. - B. **Verification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant's jurisdiction), lawyer, or accountant in the jurisdiction of the Individual's residency, and that the Third-Party Validator actually did perform the services and did attest to the signature of the Individual. + B. **Verification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant's jurisdiction), lawyer, or accountant in the jurisdiction of the Individual's residency, and that the Third-Party Validator actually did perform the services and did attest to the signature of the Individual. - C. **Cross-checking of Information**: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that: + C. **Cross-checking of Information**: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that: - i. the CA confirms their authenticity (not improperly modified when compared with the underlying original) with the Third-Party Validator; and - ii. electronic copies of similar kinds of documents are recognized as legal substitutes for originals under the laws of the CA's jurisdiction. + i. the CA confirms their authenticity (not improperly modified when compared with the underlying original) with the Third-Party Validator; and + ii. electronic copies of similar kinds of documents are recognized as legal substitutes for originals under the laws of the CA's jurisdiction. 5. **Non-Commercial Entity Subjects (International Organization)**: Unless verified under subsection (6), all items listed in [Section 3.2.2.2.1](#32221-verification-requirements) (4) MUST be verified either: - A. With reference to the constituent document under which the International Organization was formed; or - B. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or - C. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at . - D. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency. + A. With reference to the constituent document under which the International Organization was formed; or + B. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or + C. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at . + D. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency. 6. The CA may rely on a Verified Professional Letter to establish the Applicant's information listed in (1)-(5) above if: From 128ee1879947b91c665d705074ca7250bd7ca8b8 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 20:37:42 +0100 Subject: [PATCH 075/121] #432 numbering 3.2.2.5.2 --- docs/EVG.md | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 8c4379be..150d7db4 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -570,27 +570,27 @@ To verify any assumed name under which the Applicant conducts business: 2. **Acceptable Methods of Verification** - A. **Place of Business in the Country of Incorporation or Registration** + A. **Place of Business in the Country of Incorporation or Registration** - i. For Applicants whose Place of Business is in the same country as the Applicant's Jurisdiction of Incorporation or Registration and whose Place of Business is NOT the same as that indicated in the relevant Qualified Government Information Source used in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) to verify legal existence: + i. For Applicants whose Place of Business is in the same country as the Applicant's Jurisdiction of Incorporation or Registration and whose Place of Business is NOT the same as that indicated in the relevant Qualified Government Information Source used in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) to verify legal existence: - 1. For Applicants listed at the same Place of Business address in the current version of either at least one QGIS (other than that used to verify legal existence), QIIS or QTIS, the CA MUST confirm that the Applicant's address, as listed in the EV Certificate Request, is a valid business address for the Applicant or a Parent/Subsidiary Company by reference to such QGIS, QIIS, or QTIS, and MAY rely on the Applicant's representation that such address is its Place of Business; + 1. For Applicants listed at the same Place of Business address in the current version of either at least one QGIS (other than that used to verify legal existence), QIIS or QTIS, the CA MUST confirm that the Applicant's address, as listed in the EV Certificate Request, is a valid business address for the Applicant or a Parent/Subsidiary Company by reference to such QGIS, QIIS, or QTIS, and MAY rely on the Applicant's representation that such address is its Place of Business; - 2. For Applicants who are not listed at the same Place of Business address in the current version of either at least one QIIS or QTIS, the CA MUST confirm that the address provided by the Applicant in the EV Certificate Request is the Applicant's or a Parent/Subsidiary Company's business address, by obtaining documentation of a site visit to the business address, which MUST be performed by a reliable individual or firm. The documentation of the site visit MUST: + 2. For Applicants who are not listed at the same Place of Business address in the current version of either at least one QIIS or QTIS, the CA MUST confirm that the address provided by the Applicant in the EV Certificate Request is the Applicant's or a Parent/Subsidiary Company's business address, by obtaining documentation of a site visit to the business address, which MUST be performed by a reliable individual or firm. The documentation of the site visit MUST: - a. Verify that the Applicant's business is located at the exact address stated in the EV Certificate Request (e.g., via permanent signage, employee confirmation, etc.), - b. Identify the type of facility (e.g., office in a commercial building, private residence, storefront, etc.) and whether it appears to be a permanent business location, - c. Indicate whether there is a permanent sign (that cannot be moved) that identifies the Applicant, - d. Indicate whether there is evidence that the Applicant is conducting ongoing business activities at the site (not that it is just, for example, a mail drop, P.O. box, etc.), and - e. Include one or more photos of - i. the exterior of the site (showing signage indicating the Applicant's name, if present, and showing the street address if possible), and - ii. the interior reception area or workspace. + a. Verify that the Applicant's business is located at the exact address stated in the EV Certificate Request (e.g., via permanent signage, employee confirmation, etc.), + b. Identify the type of facility (e.g., office in a commercial building, private residence, storefront, etc.) and whether it appears to be a permanent business location, + c. Indicate whether there is a permanent sign (that cannot be moved) that identifies the Applicant, + d. Indicate whether there is evidence that the Applicant is conducting ongoing business activities at the site (not that it is just, for example, a mail drop, P.O. box, etc.), and + e. Include one or more photos of + i. the exterior of the site (showing signage indicating the Applicant's name, if present, and showing the street address if possible), and + ii. the interior reception area or workspace. - ii. For all Applicants, the CA MAY alternatively rely on a Verified Professional Letter that indicates the address of the Applicant's or a Parent/Subsidiary Company's Place of Business and that business operations are conducted there. - iii. For Government Entity Applicants, the CA MAY rely on the address contained in the records of the QGIS in the Applicant's jurisdiction. - iv. For Applicants whose Place of Business is in the same country as the Applicant's Jurisdiction of Incorporation or Registration and where the QGIS used in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) to verify legal existence contains a business address for the Applicant, the CA MAY rely on the address in the QGIS to confirm the Applicant's or a Parent/Subsidiary Company's address as listed in the EV Certificate Request, and MAY rely on the Applicant's representation that such address is its Place of Business. + ii. For all Applicants, the CA MAY alternatively rely on a Verified Professional Letter that indicates the address of the Applicant's or a Parent/Subsidiary Company's Place of Business and that business operations are conducted there. + iii. For Government Entity Applicants, the CA MAY rely on the address contained in the records of the QGIS in the Applicant's jurisdiction. + iv. For Applicants whose Place of Business is in the same country as the Applicant's Jurisdiction of Incorporation or Registration and where the QGIS used in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) to verify legal existence contains a business address for the Applicant, the CA MAY rely on the address in the QGIS to confirm the Applicant's or a Parent/Subsidiary Company's address as listed in the EV Certificate Request, and MAY rely on the Applicant's representation that such address is its Place of Business. - B. **Place of Business not in the Country of Incorporation or Registration**: The CA MUST rely on a Verified Professional Letter that indicates the address of the Applicant's Place of Business and that business operations are conducted there. + B. **Place of Business not in the Country of Incorporation or Registration**: The CA MUST rely on a Verified Professional Letter that indicates the address of the Applicant's Place of Business and that business operations are conducted there. #### 3.2.2.5 Verified Method of Communication @@ -602,13 +602,13 @@ To assist in communicating with the Applicant and confirming that the Applicant To verify a Verified Method of Communication with the Applicant, the CA MUST: -A. Verify that the Verified Method of Communication belongs to the Applicant, or a Parent/Subsidiary or Affiliate of the Applicant, by matching it with one of the Applicant's Parent/Subsidiary or Affiliate's Places of Business in: + A. Verify that the Verified Method of Communication belongs to the Applicant, or a Parent/Subsidiary or Affiliate of the Applicant, by matching it with one of the Applicant's Parent/Subsidiary or Affiliate's Places of Business in: - i. records provided by the applicable phone company; - ii. a QGIS, QTIS, or QIIS; or - iii. a Verified Professional Letter; and + i. records provided by the applicable phone company; + ii. a QGIS, QTIS, or QIIS; or + iii. a Verified Professional Letter; and -B. Confirm the Verified Method of Communication by using it to obtain an affirmative response sufficient to enable a reasonable person to conclude that the Applicant, or a Parent/Subsidiary or Affiliate of Applicant, can be contacted reliably by using the Verified Method of Communication. + B. Confirm the Verified Method of Communication by using it to obtain an affirmative response sufficient to enable a reasonable person to conclude that the Applicant, or a Parent/Subsidiary or Affiliate of Applicant, can be contacted reliably by using the Verified Method of Communication. #### 3.2.2.6 Verification of Applicant's Operational Existence From c30ec4ba45a61bf9df8f390ce3de01656683e82d Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 20:42:42 +0100 Subject: [PATCH 076/121] 3.2.2.5.2 --- docs/EVG.md | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 150d7db4..5c1a1fb2 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -411,13 +411,18 @@ This part of the Guidelines sets forth Verification Requirements and Acceptable Before issuing an EV Certificate, the CA MUST ensure that all Subject organization information to be included in the EV Certificate conforms to the requirements of, and is verified in accordance with, these Guidelines and matches the information confirmed and documented by the CA pursuant to its verification processes. Such verification processes are intended to accomplish the following: 1. Verify Applicant's existence and identity, including; + a. Verify the Applicant's legal existence and identity (as more fully set forth in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity)), a. Verify the Applicant's physical existence (business presence at a physical address), and c. Verify the Applicant's operational existence (business activity). + 2. Verify the Applicant is a registered holder, or has control, of the Domain Name(s) to be included in the EV Certificate; + 3. Verify a reliable means of communication with the entity to be named as the Subject in the Certificate; + 4. Verify the Applicant's authorization for the EV Certificate, including; - a Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester, + + a. Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester, b. Verify that a Contract Signer signed the Subscriber Agreement or that a duly authorized Applicant Representative acknowledged and agreed to the Terms of Use; and c. Verify that a Certificate Approver has signed or otherwise approved the EV Certificate Request. @@ -475,6 +480,7 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo 1. **Private Organization Subjects**: Unless verified under subsection (6), all items listed in [Section 3.2.2.2.1](#32221-verification-requirements) (1) MUST be verified directly with, or obtained directly from, the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Such verification MAY be through use of a Qualified Government Information Source operated by, or on behalf of, the Incorporating or Registration Agency, or by direct contact with the Incorporating or Registration Agency in person or via mail, e-mail, Web address, or telephone, using an address or phone number obtained directly from the Qualified Government Information Source, Incorporating or Registration Agency, or from a Qualified Independent Information Source. 2. **Government Entity Subjects**: Unless verified under subsection (6), all items listed in [Section 3.2.2.2.1](#32221-verification-requirements) (2) MUST either be verified directly with, or obtained directly from, one of the following: + i. a Qualified Government Information Source in the political subdivision in which such Government Entity operates; ii. a superior governing Government Entity in the same political subdivision as the Applicant (e.g. a Secretary of State may verify the legal existence of a specific State Department), or iii. from a judge that is an active member of the federal, state or local judiciary within that political subdivision. @@ -559,7 +565,9 @@ If, in addition to the Applicant's formal legal name, as recorded with the appli To verify any assumed name under which the Applicant conducts business: 1. The CA MAY verify the assumed name through use of a Qualified Government Information Source operated by, or on behalf of, an appropriate government agency in the jurisdiction of the Applicant's Place of Business, or by direct contact with such government agency in person or via mail, e-mail, Web address, or telephone; or + 2. The CA MAY verify the assumed name through use of a Qualified Independent Information Source provided that the QIIS has verified the assumed name with the appropriate government agency. + 3. The CA MAY rely on a Verified Professional Letter that indicates the assumed name under which the Applicant conducts business, the government agency with which the assumed name is registered, and that such filing continues to be valid. #### 3.2.2.4 Verification of Applicant's Physical Existence @@ -602,13 +610,13 @@ To assist in communicating with the Applicant and confirming that the Applicant To verify a Verified Method of Communication with the Applicant, the CA MUST: - A. Verify that the Verified Method of Communication belongs to the Applicant, or a Parent/Subsidiary or Affiliate of the Applicant, by matching it with one of the Applicant's Parent/Subsidiary or Affiliate's Places of Business in: +A. Verify that the Verified Method of Communication belongs to the Applicant, or a Parent/Subsidiary or Affiliate of the Applicant, by matching it with one of the Applicant's Parent/Subsidiary or Affiliate's Places of Business in: - i. records provided by the applicable phone company; - ii. a QGIS, QTIS, or QIIS; or - iii. a Verified Professional Letter; and + i. records provided by the applicable phone company; + ii. a QGIS, QTIS, or QIIS; or + iii. a Verified Professional Letter; and - B. Confirm the Verified Method of Communication by using it to obtain an affirmative response sufficient to enable a reasonable person to conclude that the Applicant, or a Parent/Subsidiary or Affiliate of Applicant, can be contacted reliably by using the Verified Method of Communication. +B. Confirm the Verified Method of Communication by using it to obtain an affirmative response sufficient to enable a reasonable person to conclude that the Applicant, or a Parent/Subsidiary or Affiliate of Applicant, can be contacted reliably by using the Verified Method of Communication. #### 3.2.2.6 Verification of Applicant's Operational Existence From d0ef1cae328c7c9ad53e48279c72a9be10998b29 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 21:10:50 +0100 Subject: [PATCH 077/121] #432 numbering reverted --- docs/EVG.md | 157 ++++++++++++++++++++++++++-------------------------- 1 file changed, 79 insertions(+), 78 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 5c1a1fb2..25a736d6 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -412,9 +412,11 @@ Before issuing an EV Certificate, the CA MUST ensure that all Subject organizati 1. Verify Applicant's existence and identity, including; - a. Verify the Applicant's legal existence and identity (as more fully set forth in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity)), - a. Verify the Applicant's physical existence (business presence at a physical address), and - c. Verify the Applicant's operational existence (business activity). + A. Verify the Applicant's legal existence and identity (as more fully set forth in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity)), + + B. Verify the Applicant's physical existence (business presence at a physical address), and + + C. Verify the Applicant's operational existence (business activity). 2. Verify the Applicant is a registered holder, or has control, of the Domain Name(s) to be included in the EV Certificate; @@ -422,9 +424,11 @@ Before issuing an EV Certificate, the CA MUST ensure that all Subject organizati 4. Verify the Applicant's authorization for the EV Certificate, including; - a. Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester, - b. Verify that a Contract Signer signed the Subscriber Agreement or that a duly authorized Applicant Representative acknowledged and agreed to the Terms of Use; and - c. Verify that a Certificate Approver has signed or otherwise approved the EV Certificate Request. + A. Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester, + + B. Verify that a Contract Signer signed the Subscriber Agreement or that a duly authorized Applicant Representative acknowledged and agreed to the Terms of Use; and + + C. Verify that a Certificate Approver has signed or otherwise approved the EV Certificate Request. ##### 3.2.2.1.2 Acceptable Methods of Verification – Overview @@ -451,36 +455,35 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo 1. **Private Organization Subjects** - a. **Legal Existence**: Verify that the Applicant is a legally recognized entity, in existence and validly formed (e.g., incorporated) with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration, and not designated on the records of the Incorporating or Registration Agency by labels such as "inactive", "invalid", "not current", or the equivalent. - b. **Organization Name**: Verify that the Applicant's formal legal name as recorded with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration matches the Applicant's name in the EV Certificate Request. - c. **Registration Number**: Obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Incorporation or Registration. - d. **Registered Agent**: Obtain the identity and address of the Applicant's Registered Agent or Registered Office (as applicable in the Applicant's Jurisdiction of Incorporation or Registration). + A. **Legal Existence**: Verify that the Applicant is a legally recognized entity, in existence and validly formed (e.g., incorporated) with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration, and not designated on the records of the Incorporating or Registration Agency by labels such as "inactive", "invalid", "not current", or the equivalent. + B. **Organization Name**: Verify that the Applicant's formal legal name as recorded with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration matches the Applicant's name in the EV Certificate Request. + C. **Registration Number**: Obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Incorporation or Registration. + D. **Registered Agent**: Obtain the identity and address of the Applicant's Registered Agent or Registered Office (as applicable in the Applicant's Jurisdiction of Incorporation or Registration). 2. **Government Entity Subjects** - a. **Legal Existence**: Verify that the Applicant is a legally recognized Government Entity, in existence in the political subdivision in which such Government Entity operates. - b. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. - c. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of incorporation, registration, or formation, or the identifier for the legislative act that created the Government Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is a Government Entity. + A. **Legal Existence**: Verify that the Applicant is a legally recognized Government Entity, in existence in the political subdivision in which such Government Entity operates. + B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. + C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of incorporation, registration, or formation, or the identifier for the legislative act that created the Government Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is a Government Entity. 3. **Business Entity Subjects** - a. **Legal Existence**: Verify that the Applicant is engaged in business under the name submitted by the Applicant in the Application. - b. **Organization Name**: Verify that the Applicant's formal legal name as recognized by the Registration Agency in the Applicant's Jurisdiction of Registration matches the Applicant's name in the EV Certificate Request. - c. **Registration Number**: Attempt to obtain the specific unique Registration Number assigned to the Applicant by the Registration Agency in the Applicant's Jurisdiction of Registration. Where the Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Registration. - d. **Principal Individual**: Verify the identity of the identified Principal Individual. + A. **Legal Existence**: Verify that the Applicant is engaged in business under the name submitted by the Applicant in the Application. + B. **Organization Name**: Verify that the Applicant's formal legal name as recognized by the Registration Agency in the Applicant's Jurisdiction of Registration matches the Applicant's name in the EV Certificate Request. + C. **Registration Number**: Attempt to obtain the specific unique Registration Number assigned to the Applicant by the Registration Agency in the Applicant's Jurisdiction of Registration. Where the Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Registration. + D. **Principal Individual**: Verify the identity of the identified Principal Individual. 4. **Non-Commercial Entity Subjects (International Organizations)** - a. **Legal Existence**: Verify that the Applicant is a legally recognized International Organization Entity. - b. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. - c. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of formation, or the identifier for the legislative act that created the International Organization Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is an International Organization Entity. + A. **Legal Existence**: Verify that the Applicant is a legally recognized International Organization Entity. + B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. + C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of formation, or the identifier for the legislative act that created the International Organization Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is an International Organization Entity. ##### 3.2.2.2.2 Acceptable Method of Verification 1. **Private Organization Subjects**: Unless verified under subsection (6), all items listed in [Section 3.2.2.2.1](#32221-verification-requirements) (1) MUST be verified directly with, or obtained directly from, the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Such verification MAY be through use of a Qualified Government Information Source operated by, or on behalf of, the Incorporating or Registration Agency, or by direct contact with the Incorporating or Registration Agency in person or via mail, e-mail, Web address, or telephone, using an address or phone number obtained directly from the Qualified Government Information Source, Incorporating or Registration Agency, or from a Qualified Independent Information Source. 2. **Government Entity Subjects**: Unless verified under subsection (6), all items listed in [Section 3.2.2.2.1](#32221-verification-requirements) (2) MUST either be verified directly with, or obtained directly from, one of the following: - i. a Qualified Government Information Source in the political subdivision in which such Government Entity operates; ii. a superior governing Government Entity in the same political subdivision as the Applicant (e.g. a Secretary of State may verify the legal existence of a specific State Department), or iii. from a judge that is an active member of the federal, state or local judiciary within that political subdivision. @@ -493,58 +496,58 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo 4. **Principal Individual**: A Principal Individual associated with the Business Entity MUST be validated in a face-to-face setting. The CA MAY rely upon a face-to-face validation of the Principal Individual performed by the Registration Agency, provided that the CA has evaluated the validation procedure and concluded that it satisfies the requirements of the Guidelines for face-to-face validation procedures. Where no face-to-face validation was conducted by the Registration Agency, or the Registration Agency's face-to-face validation procedure does not satisfy the requirements of the Guidelines, the CA SHALL perform face-to-face validation. - A. **Face-To-Face Validation**: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicant's jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator: + A. **Face-To-Face Validation**: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicant's jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator: - i. A Personal Statement that includes the following information: + i. A Personal Statement that includes the following information: - 1. Full name or names by which a person is, or has been, known (including all other names used); - 2. Residential Address at which he/she can be located; - 3. Date of birth; and - 4. An affirmation that all of the information contained in the Certificate Request is true and correct. + 1. Full name or names by which a person is, or has been, known (including all other names used); + 2. Residential Address at which he/she can be located; + 3. Date of birth; and + 4. An affirmation that all of the information contained in the Certificate Request is true and correct. - ii. A current signed government-issued identification document that includes a photo of the Individual and is signed by the Individual such as: + ii. A current signed government-issued identification document that includes a photo of the Individual and is signed by the Individual such as: - 1. A passport; - 2. A driver's license; - 3. A personal identification card; - 4. A concealed weapons permit; or - 5. A military ID. + 1. A passport; + 2. A driver's license; + 3. A personal identification card; + 4. A concealed weapons permit; or + 5. A military ID. - iii. At least two secondary documentary evidences to establish his/her identity that include the name of the Individual, one of which MUST be from a financial institution. + iii. At least two secondary documentary evidences to establish his/her identity that include the name of the Individual, one of which MUST be from a financial institution. - 1. Acceptable financial institution documents include: + 1. Acceptable financial institution documents include: - a. A major credit card, provided that it contains an expiration date and it has not expired' - b. A debit card from a regulated financial institution, provided that it contains an expiration date and it has not expired, - c. A mortgage statement from a recognizable lender that is less than six months old, - d. A bank statement from a regulated financial institution that is less than six months old. + a. A major credit card, provided that it contains an expiration date and it has not expired' + b. A debit card from a regulated financial institution, provided that it contains an expiration date and it has not expired, + c. A mortgage statement from a recognizable lender that is less than six months old, + d. A bank statement from a regulated financial institution that is less than six months old. - 2. Acceptable non-financial documents include: + 2. Acceptable non-financial documents include: - a. Recent original utility bills or certificates from a utility company confirming the arrangement to pay for the services at a fixed address (not a mobile/cellular telephone bill), - b. A copy of a statement for payment of a lease, provided that the statement is dated within the past six months, - c. A certified copy of a birth certificate, - d. A local authority tax bill for the current year, - e. A certified copy of a court order, such as a divorce certificate, annulment papers, or adoption papers. + a. Recent original utility bills or certificates from a utility company confirming the arrangement to pay for the services at a fixed address (not a mobile/cellular telephone bill), + b. A copy of a statement for payment of a lease, provided that the statement is dated within the past six months, + c. A certified copy of a birth certificate, + d. A local authority tax bill for the current year, + e. A certified copy of a court order, such as a divorce certificate, annulment papers, or adoption papers. - The Third-Party Validator performing the face-to-face validation MUST: + The Third-Party Validator performing the face-to-face validation MUST: - i. Attest to the signing of the Personal Statement and the identity of the signer; and - ii. Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original. + i. Attest to the signing of the Personal Statement and the identity of the signer; and + ii. Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original. - B. **Verification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant's jurisdiction), lawyer, or accountant in the jurisdiction of the Individual's residency, and that the Third-Party Validator actually did perform the services and did attest to the signature of the Individual. + B. **Verification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant's jurisdiction), lawyer, or accountant in the jurisdiction of the Individual's residency, and that the Third-Party Validator actually did perform the services and did attest to the signature of the Individual. - C. **Cross-checking of Information**: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that: + C. **Cross-checking of Information**: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that: - i. the CA confirms their authenticity (not improperly modified when compared with the underlying original) with the Third-Party Validator; and - ii. electronic copies of similar kinds of documents are recognized as legal substitutes for originals under the laws of the CA's jurisdiction. + i. the CA confirms their authenticity (not improperly modified when compared with the underlying original) with the Third-Party Validator; and + ii. electronic copies of similar kinds of documents are recognized as legal substitutes for originals under the laws of the CA's jurisdiction. 5. **Non-Commercial Entity Subjects (International Organization)**: Unless verified under subsection (6), all items listed in [Section 3.2.2.2.1](#32221-verification-requirements) (4) MUST be verified either: - A. With reference to the constituent document under which the International Organization was formed; or - B. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or - C. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at . - D. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency. + A. With reference to the constituent document under which the International Organization was formed; or + B. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or + C. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at . + D. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency. 6. The CA may rely on a Verified Professional Letter to establish the Applicant's information listed in (1)-(5) above if: @@ -565,9 +568,7 @@ If, in addition to the Applicant's formal legal name, as recorded with the appli To verify any assumed name under which the Applicant conducts business: 1. The CA MAY verify the assumed name through use of a Qualified Government Information Source operated by, or on behalf of, an appropriate government agency in the jurisdiction of the Applicant's Place of Business, or by direct contact with such government agency in person or via mail, e-mail, Web address, or telephone; or - 2. The CA MAY verify the assumed name through use of a Qualified Independent Information Source provided that the QIIS has verified the assumed name with the appropriate government agency. - 3. The CA MAY rely on a Verified Professional Letter that indicates the assumed name under which the Applicant conducts business, the government agency with which the assumed name is registered, and that such filing continues to be valid. #### 3.2.2.4 Verification of Applicant's Physical Existence @@ -578,27 +579,27 @@ To verify any assumed name under which the Applicant conducts business: 2. **Acceptable Methods of Verification** - A. **Place of Business in the Country of Incorporation or Registration** + A. **Place of Business in the Country of Incorporation or Registration** - i. For Applicants whose Place of Business is in the same country as the Applicant's Jurisdiction of Incorporation or Registration and whose Place of Business is NOT the same as that indicated in the relevant Qualified Government Information Source used in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) to verify legal existence: + i. For Applicants whose Place of Business is in the same country as the Applicant's Jurisdiction of Incorporation or Registration and whose Place of Business is NOT the same as that indicated in the relevant Qualified Government Information Source used in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) to verify legal existence: - 1. For Applicants listed at the same Place of Business address in the current version of either at least one QGIS (other than that used to verify legal existence), QIIS or QTIS, the CA MUST confirm that the Applicant's address, as listed in the EV Certificate Request, is a valid business address for the Applicant or a Parent/Subsidiary Company by reference to such QGIS, QIIS, or QTIS, and MAY rely on the Applicant's representation that such address is its Place of Business; + 1. For Applicants listed at the same Place of Business address in the current version of either at least one QGIS (other than that used to verify legal existence), QIIS or QTIS, the CA MUST confirm that the Applicant's address, as listed in the EV Certificate Request, is a valid business address for the Applicant or a Parent/Subsidiary Company by reference to such QGIS, QIIS, or QTIS, and MAY rely on the Applicant's representation that such address is its Place of Business; - 2. For Applicants who are not listed at the same Place of Business address in the current version of either at least one QIIS or QTIS, the CA MUST confirm that the address provided by the Applicant in the EV Certificate Request is the Applicant's or a Parent/Subsidiary Company's business address, by obtaining documentation of a site visit to the business address, which MUST be performed by a reliable individual or firm. The documentation of the site visit MUST: + 2. For Applicants who are not listed at the same Place of Business address in the current version of either at least one QIIS or QTIS, the CA MUST confirm that the address provided by the Applicant in the EV Certificate Request is the Applicant's or a Parent/Subsidiary Company's business address, by obtaining documentation of a site visit to the business address, which MUST be performed by a reliable individual or firm. The documentation of the site visit MUST: - a. Verify that the Applicant's business is located at the exact address stated in the EV Certificate Request (e.g., via permanent signage, employee confirmation, etc.), - b. Identify the type of facility (e.g., office in a commercial building, private residence, storefront, etc.) and whether it appears to be a permanent business location, - c. Indicate whether there is a permanent sign (that cannot be moved) that identifies the Applicant, - d. Indicate whether there is evidence that the Applicant is conducting ongoing business activities at the site (not that it is just, for example, a mail drop, P.O. box, etc.), and - e. Include one or more photos of - i. the exterior of the site (showing signage indicating the Applicant's name, if present, and showing the street address if possible), and - ii. the interior reception area or workspace. + a. Verify that the Applicant's business is located at the exact address stated in the EV Certificate Request (e.g., via permanent signage, employee confirmation, etc.), + b. Identify the type of facility (e.g., office in a commercial building, private residence, storefront, etc.) and whether it appears to be a permanent business location, + c. Indicate whether there is a permanent sign (that cannot be moved) that identifies the Applicant, + d. Indicate whether there is evidence that the Applicant is conducting ongoing business activities at the site (not that it is just, for example, a mail drop, P.O. box, etc.), and + e. Include one or more photos of + i. the exterior of the site (showing signage indicating the Applicant's name, if present, and showing the street address if possible), and + ii. the interior reception area or workspace. - ii. For all Applicants, the CA MAY alternatively rely on a Verified Professional Letter that indicates the address of the Applicant's or a Parent/Subsidiary Company's Place of Business and that business operations are conducted there. - iii. For Government Entity Applicants, the CA MAY rely on the address contained in the records of the QGIS in the Applicant's jurisdiction. - iv. For Applicants whose Place of Business is in the same country as the Applicant's Jurisdiction of Incorporation or Registration and where the QGIS used in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) to verify legal existence contains a business address for the Applicant, the CA MAY rely on the address in the QGIS to confirm the Applicant's or a Parent/Subsidiary Company's address as listed in the EV Certificate Request, and MAY rely on the Applicant's representation that such address is its Place of Business. + ii. For all Applicants, the CA MAY alternatively rely on a Verified Professional Letter that indicates the address of the Applicant's or a Parent/Subsidiary Company's Place of Business and that business operations are conducted there. + iii. For Government Entity Applicants, the CA MAY rely on the address contained in the records of the QGIS in the Applicant's jurisdiction. + iv. For Applicants whose Place of Business is in the same country as the Applicant's Jurisdiction of Incorporation or Registration and where the QGIS used in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) to verify legal existence contains a business address for the Applicant, the CA MAY rely on the address in the QGIS to confirm the Applicant's or a Parent/Subsidiary Company's address as listed in the EV Certificate Request, and MAY rely on the Applicant's representation that such address is its Place of Business. - B. **Place of Business not in the Country of Incorporation or Registration**: The CA MUST rely on a Verified Professional Letter that indicates the address of the Applicant's Place of Business and that business operations are conducted there. + B. **Place of Business not in the Country of Incorporation or Registration**: The CA MUST rely on a Verified Professional Letter that indicates the address of the Applicant's Place of Business and that business operations are conducted there. #### 3.2.2.5 Verified Method of Communication @@ -610,13 +611,13 @@ To assist in communicating with the Applicant and confirming that the Applicant To verify a Verified Method of Communication with the Applicant, the CA MUST: -A. Verify that the Verified Method of Communication belongs to the Applicant, or a Parent/Subsidiary or Affiliate of the Applicant, by matching it with one of the Applicant's Parent/Subsidiary or Affiliate's Places of Business in: +A. Verify that the Verified Method of Communication belongs to the Applicant, or a Parent/Subsidiary or Affiliate of the Applicant, by matching it with one of the Applicant's Parent/Subsidiary or Affiliate's Places of Business in: - i. records provided by the applicable phone company; - ii. a QGIS, QTIS, or QIIS; or - iii. a Verified Professional Letter; and + i. records provided by the applicable phone company; + ii. a QGIS, QTIS, or QIIS; or + iii. a Verified Professional Letter; and -B. Confirm the Verified Method of Communication by using it to obtain an affirmative response sufficient to enable a reasonable person to conclude that the Applicant, or a Parent/Subsidiary or Affiliate of Applicant, can be contacted reliably by using the Verified Method of Communication. +B. Confirm the Verified Method of Communication by using it to obtain an affirmative response sufficient to enable a reasonable person to conclude that the Applicant, or a Parent/Subsidiary or Affiliate of Applicant, can be contacted reliably by using the Verified Method of Communication. #### 3.2.2.6 Verification of Applicant's Operational Existence From 560610970be9dad6ca58798256917126f4841cbd Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 21:20:37 +0100 Subject: [PATCH 078/121] #432 double spaces and - --- docs/EVG.md | 266 +++++++++++++++++++++++----------------------------- 1 file changed, 117 insertions(+), 149 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 25a736d6..77adcec1 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -14,23 +14,23 @@ copyright: | # 1. INTRODUCTION -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 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. +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. **Notice to Readers** -The Guidelines for the Issuance and Management of Extended Validation Certificates present criteria established by the CA/Browser Forum for use by certification authorities when issuing, maintaining, and revoking certain digital certificates for use in Internet Web site commerce. These Guidelines may be revised from time to time, as appropriate, in accordance with procedures adopted by the CA/Browser Forum. Questions or suggestions concerning these guidelines may be directed to the CA/Browser Forum at . +The Guidelines for the Issuance and Management of Extended Validation Certificates present criteria established by the CA/Browser Forum for use by certification authorities when issuing, maintaining, and revoking certain digital certificates for use in Internet Web site commerce. These Guidelines may be revised from time to time, as appropriate, in accordance with procedures adopted by the CA/Browser Forum. Questions or suggestions concerning these guidelines may be directed to the CA/Browser Forum at . **The CA/Browser Forum** -The CA/Browser Forum is a voluntary open organization of certification authorities and suppliers of Internet browsers and other relying-party software applications. Membership is listed at . +The CA/Browser Forum is a voluntary open organization of certification authorities and suppliers of Internet browsers and other relying-party software applications. Membership is listed at . ## 1.1 Overview -These Guidelines for the issuance and management of Extended Validation Certificates describe certain of the minimum requirements that a Certification Authority must meet in order to issue Extended Validation Certificates. Subject Organization information from Valid EV Certificates may be displayed 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 they are accessing. These Guidelines incorporate the Baseline Requirements established by the CA/Browser Forum by reference. A copy of the Baseline Requirements is available on the CA/Browser Forum's website at . +These Guidelines for the issuance and management of Extended Validation Certificates describe certain of the minimum requirements that a Certification Authority must meet in order to issue Extended Validation Certificates. Subject Organization information from Valid EV Certificates may be displayed 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 they are accessing. These Guidelines incorporate the Baseline Requirements established by the CA/Browser Forum by reference. A copy of the Baseline Requirements is available on the CA/Browser Forum's website at . -These Guidelines address the basic issue of validating Subject identity information in EV Certificates and some related matters. They do not address all of the related matters, such as certain technical and operational ones. This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet. However, the Working Group encourages the re-use of these guidelines as a basis for similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. +These Guidelines address the basic issue of validating Subject identity information in EV Certificates and some related matters. They do not address all of the related matters, such as certain technical and operational ones. This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet. However, the Working Group encourages the re-use of these guidelines as a basis for similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. These Guidelines do not address the verification of information, or the issuance, use, maintenance, or revocation of EV Certificates by enterprises that operate their own Public Key Infrastructure for internal purposes only, where its Root CA Certificate is not distributed by any Application Software Supplier. @@ -97,7 +97,7 @@ These Guidelines do not address the verification of information, or the issuance | 2020-10-01 | [3.2.2.1.3](#32213-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 | [7.1.4.2.7](#71427-subject-organizational-unit-name-field) | CAs MUST NOT include the organizationalUnitName field in the Subject | -**Implementers' Note**: Version 1.3 of these EV Guidelines was published on 20 November 2010 and supplemented through May 2012 when version 1.4 was published. ETSI TS 102 042 and ETSI TR 101 564 Technical Report: Guidance on ETSI TS 102 042 for Issuing Extended Validation Certificates for Auditors and CSPs reference version 1.3 of these EV Guidelines, and ETSI Draft EN 319 411-1 references version 1.4. Version 1.4.5 of Webtrust(r) for Certification Authorities – Extended Validation Audit Criteria references version 1.4.5 of these EV Guidelines. As illustrated in the Document History table above, the CA/Browser Forum continues to improve relevant industry guidelines, including this document, the Baseline Requirements, and the Network and Certificate System Security Requirements. We encourage all CAs to conform to each revision 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. 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. +**Implementers' Note**: Version 1.3 of these EV Guidelines was published on 20 November 2010 and supplemented through May 2012 when version 1.4 was published. ETSI TS 102 042 and ETSI TR 101 564 Technical Report: Guidance on ETSI TS 102 042 for Issuing Extended Validation Certificates for Auditors and CSPs reference version 1.3 of these EV Guidelines, and ETSI Draft EN 319 411-1 references version 1.4. Version 1.4.5 of Webtrust(r) for Certification Authorities – Extended Validation Audit Criteria references version 1.4.5 of these EV Guidelines. As illustrated in the Document History table above, the CA/Browser Forum continues to improve relevant industry guidelines, including this document, the Baseline Requirements, and the Network and Certificate System Security Requirements. We encourage all CAs to conform to each revision 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. 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. ## 1.3 PKI participants @@ -110,11 +110,11 @@ Affiliates and/or RAs must comply with the qualification requirements of [Sectio The CA SHALL verify that the Delegated Third Party's personnel involved in the issuance of a Certificate meet the training and skills requirements of [Section 5.3](#53-personnel-controls) and the document retention and event logging requirements of [Section 5.4](#54-audit-logging-procedures). -In all cases, the CA MUST contractually obligate each Affiliate, RA, subcontractor, and Enterprise RA to comply with all applicable requirements in these Guidelines and to perform them as required of the CA itself. The CA SHALL enforce these obligations and internally audit each Affiliate's, RA's, subcontractor's, and Enterprise RA's compliance with these Requirements on an annual basis. +In all cases, the CA MUST contractually obligate each Affiliate, RA, subcontractor, and Enterprise RA to comply with all applicable requirements in these Guidelines and to perform them as required of the CA itself. The CA SHALL enforce these obligations and internally audit each Affiliate's, RA's, subcontractor's, and Enterprise RA's compliance with these Requirements on an annual basis. #### 1.3.2.1 Enterprise Registration authorities -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: +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 @@ -144,7 +144,7 @@ The primary purposes of an EV Certificate are to: #### 1.4.1.2 Secondary Purposes -The secondary purposes of an EV Certificate are to help establish the legitimacy of a business claiming to operate a Web site, and to provide a vehicle that can be used to assist in addressing problems related to phishing, and other forms of online identity fraud. By providing more reliable third-party verified identity and address information regarding the business, EV Certificates may help to: +The secondary purposes of an EV Certificate are to help establish the legitimacy of a business claiming to operate a Web site, and to provide a vehicle that can be used to assist in addressing problems related to phishing, and other forms of online identity fraud. By providing more reliable third-party verified identity and address information regarding the business, EV Certificates may help to: 1. Make it more difficult to mount phishing and other online identity fraud attacks using Certificates; 2. Assist companies that may be the target of phishing attacks or online identity fraud by providing them with a tool to better identify themselves to users; and @@ -152,7 +152,7 @@ The secondary purposes of an EV Certificate are to help establish the legitimacy ### 1.4.2 Prohibited certificate uses -EV Certificates focus only on the identity of the Subject named in the Certificate, and not on the behavior of the Subject. As such, an EV Certificate is **not** intended to provide any assurances, or otherwise represent or warrant: +EV Certificates focus only on the identity of the Subject named in the Certificate, and not on the behavior of the Subject. As such, an EV Certificate is **not** intended to provide any assurances, or otherwise represent or warrant: 1. That the Subject named in the EV Certificate is actively engaged in doing business; 2. That the Subject named in the EV Certificate complies with applicable laws; @@ -194,7 +194,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Contract Signer**: A natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements. -**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. +**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. **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. @@ -221,11 +221,11 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Extended Validation Certificate**: See EV Certificate. -**Government Agency**: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of Private Organizations is established (e.g., the government agency that issued the Certificate of Incorporation). In the context of Business Entities, the government agency in the jurisdiction of operation that registers business entities. In the case of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities. +**Government Agency**: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of Private Organizations is established (e.g., the government agency that issued the Certificate of Incorporation). In the context of Business Entities, the government agency in the jurisdiction of operation that registers business entities. In the case of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities. **Guidelines**: This document. -**Incorporating Agency**: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of the entity is registered (e.g., the government agency that issues certificates of formation or incorporation). In the context of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities. +**Incorporating Agency**: In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of the entity is registered (e.g., the government agency that issues certificates of formation or incorporation). In the context of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities. **Independent Confirmation From Applicant**: Confirmation of a particular fact received by the CA pursuant to the provisions of the Guidelines or binding upon the Applicant. @@ -233,7 +233,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **International Organization**: An organization founded by a constituent document, e.g., a charter, treaty, convention or similar document, signed by, or on behalf of, a minimum of two Sovereign State governments. -**Jurisdiction of Incorporation**: In the context of a Private Organization, the country and (where applicable) the state or province or locality where the organization's legal existence was established by a filing with (or an act of) an appropriate government agency or entity (e.g., where it was incorporated). In the context of a Government Entity, the country and (where applicable) the state or province where the Entity's legal existence was created by law. +**Jurisdiction of Incorporation**: In the context of a Private Organization, the country and (where applicable) the state or province or locality where the organization's legal existence was established by a filing with (or an act of) an appropriate government agency or entity (e.g., where it was incorporated). In the context of a Government Entity, the country and (where applicable) the state or province where the Entity's legal existence was created by law. **Jurisdiction of Registration**: In the case of a Business Entity, the state, province, or locality where the organization has registered its business presence by means of filings by a Principal Individual involved in the business. @@ -266,7 +266,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Qualified Independent Information Source**: A regularly-updated and current, publicly available, database designed for the purpose of accurately providing the information for which it is consulted, and which is generally recognized as a dependable source of such information. -**Registration Agency**: A Governmental Agency that registers business information in connection with an entity's business formation or authorization to conduct business under a license, charter or other certification. A Registration Agency MAY include, but is not limited to +**Registration Agency**: A Governmental Agency that registers business information in connection with an entity's business formation or authorization to conduct business under a license, charter or other certification. A Registration Agency MAY include, but is not limited to i. a State Department of Corporations or a Secretary of State; ii. a licensing agency, such as a State Department of Insurance; or @@ -372,9 +372,9 @@ The CA's Certificate Policy and/or Certification Practice Statement MUST be stru Each CA SHALL publicly give effect to these Guidelines and represent that they will adhere to the latest published version by incorporating them into their respective EV Policies, using a clause such as the following (which must include a link to the official version of these Guidelines): -> [Name of CA] conforms to the current version of the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates published at . In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document. +> [Name of CA] conforms to the current version of the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates published at . In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document. -In addition, the CA MUST include (directly or by reference) the applicable requirements of these Guidelines in all contracts with Subordinate CAs, RAs, Enterprise RAs, and subcontractors that involve or relate to the issuance or maintenance of EV Certificates. The CA MUST enforce compliance with such terms. +In addition, the CA MUST include (directly or by reference) the applicable requirements of these Guidelines in all contracts with Subordinate CAs, RAs, Enterprise RAs, and subcontractors that involve or relate to the issuance or maintenance of EV Certificates. The CA MUST enforce compliance with such terms. ## 2.3 Time or frequency of publication @@ -408,7 +408,7 @@ This part of the Guidelines sets forth Verification Requirements and Acceptable ##### 3.2.2.1.1 Verification Requirements – Overview -Before issuing an EV Certificate, the CA MUST ensure that all Subject organization information to be included in the EV Certificate conforms to the requirements of, and is verified in accordance with, these Guidelines and matches the information confirmed and documented by the CA pursuant to its verification processes. Such verification processes are intended to accomplish the following: +Before issuing an EV Certificate, the CA MUST ensure that all Subject organization information to be included in the EV Certificate conforms to the requirements of, and is verified in accordance with, these Guidelines and matches the information confirmed and documented by the CA pursuant to its verification processes. Such verification processes are intended to accomplish the following: 1. Verify Applicant's existence and identity, including; @@ -432,7 +432,7 @@ Before issuing an EV Certificate, the CA MUST ensure that all Subject organizati ##### 3.2.2.1.2 Acceptable Methods of Verification – Overview -As a general rule, the CA is responsible for taking all verification steps reasonably necessary to satisfy each of the Verification Requirements set forth in the subsections below. The Acceptable Methods of Verification set forth in each of Sections 3.2.2 through 3.2.14 (which usually include alternatives) are considered to be the minimum acceptable level of verification required of the CA. In all cases, however, the CA is responsible for taking any additional verification steps that may be reasonably necessary under the circumstances to satisfy the applicable Verification Requirement. +As a general rule, the CA is responsible for taking all verification steps reasonably necessary to satisfy each of the Verification Requirements set forth in the subsections below. The Acceptable Methods of Verification set forth in each of Sections 3.2.2 through 3.2.14 (which usually include alternatives) are considered to be the minimum acceptable level of verification required of the CA. In all cases, however, the CA is responsible for taking any additional verification steps that may be reasonably necessary under the circumstances to satisfy the applicable Verification Requirement. ##### 3.2.2.1.3 Disclosure of Verification Sources @@ -457,27 +457,27 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo A. **Legal Existence**: Verify that the Applicant is a legally recognized entity, in existence and validly formed (e.g., incorporated) with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration, and not designated on the records of the Incorporating or Registration Agency by labels such as "inactive", "invalid", "not current", or the equivalent. B. **Organization Name**: Verify that the Applicant's formal legal name as recorded with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: Obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Incorporation or Registration. + C. **Registration Number**: Obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Incorporation or Registration. D. **Registered Agent**: Obtain the identity and address of the Applicant's Registered Agent or Registered Office (as applicable in the Applicant's Jurisdiction of Incorporation or Registration). 2. **Government Entity Subjects** A. **Legal Existence**: Verify that the Applicant is a legally recognized Government Entity, in existence in the political subdivision in which such Government Entity operates. B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of incorporation, registration, or formation, or the identifier for the legislative act that created the Government Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is a Government Entity. + C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of incorporation, registration, or formation, or the identifier for the legislative act that created the Government Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is a Government Entity. 3. **Business Entity Subjects** A. **Legal Existence**: Verify that the Applicant is engaged in business under the name submitted by the Applicant in the Application. B. **Organization Name**: Verify that the Applicant's formal legal name as recognized by the Registration Agency in the Applicant's Jurisdiction of Registration matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: Attempt to obtain the specific unique Registration Number assigned to the Applicant by the Registration Agency in the Applicant's Jurisdiction of Registration. Where the Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Registration. + C. **Registration Number**: Attempt to obtain the specific unique Registration Number assigned to the Applicant by the Registration Agency in the Applicant's Jurisdiction of Registration. Where the Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Registration. D. **Principal Individual**: Verify the identity of the identified Principal Individual. 4. **Non-Commercial Entity Subjects (International Organizations)** A. **Legal Existence**: Verify that the Applicant is a legally recognized International Organization Entity. B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of formation, or the identifier for the legislative act that created the International Organization Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is an International Organization Entity. + C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of formation, or the identifier for the legislative act that created the International Organization Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is an International Organization Entity. ##### 3.2.2.2.2 Acceptable Method of Verification @@ -494,9 +494,9 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo 3. **Business Entity Subjects**: Unless verified under subsection (6), Items listed in [Section 3.2.2.2.1](#32221-verification-requirements) (3) (A) through (C) above, MUST be verified directly with, or obtained directly from, the Registration Agency in the Applicant's Jurisdiction of Registration. Such verification MAY be performed by means of a Qualified Government Information Source, a Qualified Governmental Tax Information Source, or by direct contact with the Registration Agency in person or via mail, e-mail, Web address, or telephone, using an address or phone number obtained directly from the Qualified Government Information Source, Qualified Governmental Tax Information Source or Registration Agency, or from a Qualified Independent Information Source. In addition, the CA MUST validate a Principal Individual associated with the Business Entity pursuant to the requirements in subsection (4), below. -4. **Principal Individual**: A Principal Individual associated with the Business Entity MUST be validated in a face-to-face setting. The CA MAY rely upon a face-to-face validation of the Principal Individual performed by the Registration Agency, provided that the CA has evaluated the validation procedure and concluded that it satisfies the requirements of the Guidelines for face-to-face validation procedures. Where no face-to-face validation was conducted by the Registration Agency, or the Registration Agency's face-to-face validation procedure does not satisfy the requirements of the Guidelines, the CA SHALL perform face-to-face validation. +4. **Principal Individual**: A Principal Individual associated with the Business Entity MUST be validated in a face-to-face setting. The CA MAY rely upon a face-to-face validation of the Principal Individual performed by the Registration Agency, provided that the CA has evaluated the validation procedure and concluded that it satisfies the requirements of the Guidelines for face-to-face validation procedures. Where no face-to-face validation was conducted by the Registration Agency, or the Registration Agency's face-to-face validation procedure does not satisfy the requirements of the Guidelines, the CA SHALL perform face-to-face validation. - A. **Face-To-Face Validation**: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicant's jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator: + A. **Face-To-Face Validation**: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicant's jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator: i. A Personal Statement that includes the following information: @@ -533,11 +533,11 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo The Third-Party Validator performing the face-to-face validation MUST: i. Attest to the signing of the Personal Statement and the identity of the signer; and - ii. Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original. + ii. Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original. B. **Verification of Third-Party Validator**: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant's jurisdiction), lawyer, or accountant in the jurisdiction of the Individual's residency, and that the Third-Party Validator actually did perform the services and did attest to the signature of the Individual. - C. **Cross-checking of Information**: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that: + C. **Cross-checking of Information**: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that: i. the CA confirms their authenticity (not improperly modified when compared with the underlying original) with the Third-Party Validator; and ii. electronic copies of similar kinds of documents are recognized as legal substitutes for originals under the laws of the CA's jurisdiction. @@ -545,7 +545,7 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo 5. **Non-Commercial Entity Subjects (International Organization)**: Unless verified under subsection (6), all items listed in [Section 3.2.2.2.1](#32221-verification-requirements) (4) MUST be verified either: A. With reference to the constituent document under which the International Organization was formed; or - B. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or + B. Directly with a signatory country's government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country's government has a mission to represent it at the International Organization; or C. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at . D. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency. @@ -585,7 +585,7 @@ To verify any assumed name under which the Applicant conducts business: 1. For Applicants listed at the same Place of Business address in the current version of either at least one QGIS (other than that used to verify legal existence), QIIS or QTIS, the CA MUST confirm that the Applicant's address, as listed in the EV Certificate Request, is a valid business address for the Applicant or a Parent/Subsidiary Company by reference to such QGIS, QIIS, or QTIS, and MAY rely on the Applicant's representation that such address is its Place of Business; - 2. For Applicants who are not listed at the same Place of Business address in the current version of either at least one QIIS or QTIS, the CA MUST confirm that the address provided by the Applicant in the EV Certificate Request is the Applicant's or a Parent/Subsidiary Company's business address, by obtaining documentation of a site visit to the business address, which MUST be performed by a reliable individual or firm. The documentation of the site visit MUST: + 2. For Applicants who are not listed at the same Place of Business address in the current version of either at least one QIIS or QTIS, the CA MUST confirm that the address provided by the Applicant in the EV Certificate Request is the Applicant's or a Parent/Subsidiary Company's business address, by obtaining documentation of a site visit to the business address, which MUST be performed by a reliable individual or firm. The documentation of the site visit MUST: a. Verify that the Applicant's business is located at the exact address stated in the EV Certificate Request (e.g., via permanent signage, employee confirmation, etc.), b. Identify the type of facility (e.g., office in a commercial building, private residence, storefront, etc.) and whether it appears to be a permanent business location, @@ -623,7 +623,7 @@ B. Confirm the Verified Method of Communication by using it to obtain an affirm ##### 3.2.2.6.1 Verification Requirements -The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) as verification of a Government Entity's operational existence. +The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant's, or Affiliate/Parent/Subsidiary Company's, operational existence. The CA MAY rely on its verification of a Government Entity's legal existence under [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity) as verification of a Government Entity's operational existence. ##### 3.2.2.6.2 Acceptable Methods of Verification @@ -643,7 +643,7 @@ To verify the Applicant's ability to engage in business, the CA MUST verify the 1. For each Fully-Qualified Domain Name listed in a Certificate which is not an Onion Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 3.2.2.4 of the Baseline Requirements. For a Certificate issued to an Onion Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the Onion Domain Name in accordance with Appendix B of the Baseline Requirements. -2. **Mixed Character Set Domain Names**: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. +2. **Mixed Character Set Domain Names**: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. #### 3.2.2.8 Verification of Name, Title, and Authority of Contract Signer and Certificate Approver @@ -651,7 +651,7 @@ To verify the Applicant's ability to engage in business, the CA MUST verify the For both the Contract Signer and the Certificate Approver, the CA MUST verify the following. -1. **Name, Title and Agency**: The CA MUST verify the name and title of the Contract Signer and the Certificate Approver, as applicable. The CA MUST also verify that the Contract Signer and the Certificate Approver are agents representing the Applicant. +1. **Name, Title and Agency**: The CA MUST verify the name and title of the Contract Signer and the Certificate Approver, as applicable. The CA MUST also verify that the Contract Signer and the Certificate Approver are agents representing the Applicant. 2. **Signing Authority of Contract Signer**: The CA MUST verify that the Contract Signer is authorized by the Applicant to enter into the Subscriber Agreement (and any other relevant contractual obligations) on behalf of the Applicant, including a contract that designates one or more Certificate Approvers on behalf of the Applicant. 3. **EV Authority of Certificate Approver**: The CA MUST verify, through a source other than the Certificate Approver him- or herself, that the Certificate Approver is expressly authorized by the Applicant to do the following, as of the date of the EV Certificate Request: @@ -687,7 +687,7 @@ Acceptable methods of verification of the Signing Authority of the Contract Sign 4. **Contract between CA and Applicant**: The EV Authority of the Certificate Approver MAY be verified by reliance on a contract between the CA and the Applicant that designates the Certificate Approver with such EV Authority, provided that the contract is signed by the Contract Signer and provided that the agency and Signing Authority of the Contract Signer have been verified; 5. **Prior Equivalent Authority**: The signing authority of the Contract Signer, and/or the EV authority of the Certificate Approver, MAY be verified by relying on a demonstration of Prior Equivalent Authority. - A. Prior Equivalent Authority of a Contract Signer MAY be relied upon for confirmation or verification of the signing authority of the Contract Signer when the Contract Signer has executed a binding contract between the CA and the Applicant with a legally valid and enforceable seal or handwritten signature and only when the contract was executed more than 90 days prior to the EV Certificate application. The CA MUST record sufficient details of the previous agreement to correctly identify it and associate it with the EV application. Such details MAY include any of the following: + A. Prior Equivalent Authority of a Contract Signer MAY be relied upon for confirmation or verification of the signing authority of the Contract Signer when the Contract Signer has executed a binding contract between the CA and the Applicant with a legally valid and enforceable seal or handwritten signature and only when the contract was executed more than 90 days prior to the EV Certificate application. The CA MUST record sufficient details of the previous agreement to correctly identify it and associate it with the EV application. Such details MAY include any of the following: i. Agreement title, ii. Date of Contract Signer's signature, @@ -697,7 +697,7 @@ Acceptable methods of verification of the Signing Authority of the Contract Sign B. Prior Equivalent Authority of a Certificate Approver MAY be relied upon for confirmation or verification of the EV Authority of the Certificate Approver when the Certificate Approver has performed one or more of the following: i. Under contract to the CA, has served (or is serving) as an Enterprise RA for the Applicant, or - ii. Has participated in the approval of one or more certificate requests, for certificates issued by the CA and which are currently and verifiably in use by the Applicant. In this case the CA MUST have contacted the Certificate Approver by phone at a previously validated phone number or have accepted a signed and notarized letter approving the certificate request. + ii. Has participated in the approval of one or more certificate requests, for certificates issued by the CA and which are currently and verifiably in use by the Applicant. In this case the CA MUST have contacted the Certificate Approver by phone at a previously validated phone number or have accepted a signed and notarized letter approving the certificate request. 6. **QIIS or QGIS**: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by a QIIS or QGIS that identifies the Contract Signer and/or the Certificate Approver as a corporate officer, sole proprietor, or other senior official of the Applicant. @@ -730,7 +730,7 @@ Such an agreement MUST provide that the Applicant shall be obligated under the S #### 3.2.2.9 Verification of Signature on Subscriber Agreement and EV Certificate Requests -Both the Subscriber Agreement and each non-pre-authorized EV Certificate Request MUST be signed. The Subscriber Agreement MUST be signed by an authorized Contract Signer. The EV Certificate Request MUST be signed by the Certificate Requester submitting the document, unless the Certificate Request has been pre-authorized in line with [Section 3.2.2.8.4](#32284-pre-authorized-certificate-approver). If the Certificate Requester is not also an authorized Certificate Approver, then an authorized Certificate Approver MUST independently approve the EV Certificate Request. In all cases, applicable signatures MUST be a legally valid and contain an enforceable seal or handwritten signature (for a paper Subscriber Agreement and/or EV Certificate Request), or a legally valid and enforceable electronic signature (for an electronic Subscriber Agreement and/or EV Certificate Request), that binds the Applicant to the terms of each respective document. +Both the Subscriber Agreement and each non-pre-authorized EV Certificate Request MUST be signed. The Subscriber Agreement MUST be signed by an authorized Contract Signer. The EV Certificate Request MUST be signed by the Certificate Requester submitting the document, unless the Certificate Request has been pre-authorized in line with [Section 3.2.2.8.4](#32284-pre-authorized-certificate-approver). If the Certificate Requester is not also an authorized Certificate Approver, then an authorized Certificate Approver MUST independently approve the EV Certificate Request. In all cases, applicable signatures MUST be a legally valid and contain an enforceable seal or handwritten signature (for a paper Subscriber Agreement and/or EV Certificate Request), or a legally valid and enforceable electronic signature (for an electronic Subscriber Agreement and/or EV Certificate Request), that binds the Applicant to the terms of each respective document. ##### 3.2.2.9.1 Verification Requirements @@ -781,8 +781,8 @@ Acceptable methods of verifying the Certificate Approver's approval of an EV Cer 2. **Acceptable Methods of Verification**: Acceptable methods of establishing the foregoing requirements for a Verified Legal Opinion are: A. **Status of Author**: The CA MUST verify the professional status of the author of the legal opinion by directly contacting the authority responsible for registering or licensing such Legal Practitioner(s) in the applicable jurisdiction; - B. **Basis of Opinion**: The text of the legal opinion MUST make it clear that the Legal Practitioner is acting on behalf of the Applicant and that the conclusions of the legal opinion are based on the Legal Practitioner's stated familiarity with the relevant facts and the exercise of the practitioner's professional judgment and expertise. The legal opinion MAY also include disclaimers and other limitations customary in the Legal Practitioner's jurisdiction, provided that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Legal Practitioner, should the legal opinion prove to be erroneous. An acceptable form of legal opinion is attached as [Appendix B](#appendix-b---sample-attorney-opinions-confirming-specified-information); - C. **Authenticity**: To confirm the authenticity of the legal opinion, the CA MUST make a telephone call or send a copy of the legal opinion back to the Legal Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Legal Practitioner listed with the authority responsible for registering or licensing such Legal Practitioner, and obtain confirmation from the Legal Practitioner or the Legal Practitioner's assistant that the legal opinion is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Legal Practitioner in records provided by the applicable phone company, QGIS, or QIIS. + B. **Basis of Opinion**: The text of the legal opinion MUST make it clear that the Legal Practitioner is acting on behalf of the Applicant and that the conclusions of the legal opinion are based on the Legal Practitioner's stated familiarity with the relevant facts and the exercise of the practitioner's professional judgment and expertise. The legal opinion MAY also include disclaimers and other limitations customary in the Legal Practitioner's jurisdiction, provided that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Legal Practitioner, should the legal opinion prove to be erroneous. An acceptable form of legal opinion is attached as [Appendix B](#appendix-b---sample-attorney-opinions-confirming-specified-information); + C. **Authenticity**: To confirm the authenticity of the legal opinion, the CA MUST make a telephone call or send a copy of the legal opinion back to the Legal Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Legal Practitioner listed with the authority responsible for registering or licensing such Legal Practitioner, and obtain confirmation from the Legal Practitioner or the Legal Practitioner's assistant that the legal opinion is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Legal Practitioner in records provided by the applicable phone company, QGIS, or QIIS. In circumstances where the opinion is digitally signed, in a manner that confirms the authenticity of the document and the identity of the signer, as verified by the CA in [Section 3.2.2.11.1](#322111-verified-legal-opinion) (2)(A), no further verification of authenticity is required. @@ -790,15 +790,15 @@ Acceptable methods of verifying the Certificate Approver's approval of an EV Cer 1. **Verification Requirements**: Before relying on an accountant letter submitted to the CA, the CA MUST verify that such accountant letter meets the following requirements: - A. **Status of Author**: The CA MUST verify that the accountant letter is authored by an Accounting Practitioner retained or employed by the Applicant and licensed within the country of the Applicant's Jurisdiction of Incorporation, Jurisdiction of Registration, or country where the Applicant maintains an office or physical facility. Verification of license MUST be through the member organization or regulatory organization in the Accounting Practitioner's country or jurisdiction that is appropriate to contact when verifying an accountant's license to practice in that country or jurisdiction. Such country or jurisdiction must have an accounting standards body that maintains full membership status with the International Federation of Accountants. + A. **Status of Author**: The CA MUST verify that the accountant letter is authored by an Accounting Practitioner retained or employed by the Applicant and licensed within the country of the Applicant's Jurisdiction of Incorporation, Jurisdiction of Registration, or country where the Applicant maintains an office or physical facility. Verification of license MUST be through the member organization or regulatory organization in the Accounting Practitioner's country or jurisdiction that is appropriate to contact when verifying an accountant's license to practice in that country or jurisdiction. Such country or jurisdiction must have an accounting standards body that maintains full membership status with the International Federation of Accountants. B. **Basis of Opinion**: The CA MUST verify that the Accounting Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Accountant Letter are based on the Accounting Practitioner's stated familiarity with the relevant facts and the exercise of the Accounting Practitioner's professional judgment and expertise; C. **Authenticity**: The CA MUST confirm the authenticity of the Verified Accountant Letter. 2. **Acceptable Methods of Verification**: Acceptable methods of establishing the foregoing requirements for a Verified Accountant Letter are listed here. A. **Status of Author**: The CA MUST verify the professional status of the author of the accountant letter by directly contacting the authority responsible for registering or licensing such Accounting Practitioners in the applicable jurisdiction. - B. **Basis of Opinion**: The text of the Verified Accountant Letter MUST make clear that the Accounting Practitioner is acting on behalf of the Applicant and that the information in the letter is based on the Accounting Practitioner's stated familiarity with the relevant facts and the exercise of the practitioner's professional judgment and expertise. The Verified Accountant Letter MAY also include disclaimers and other limitations customary in the Accounting Practitioner's jurisdiction, provided that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Accounting Practitioner, should the Verified Accountant Letter prove to be erroneous. Acceptable forms of Verified Accountant Letter are attached as [Appendix C](#appendix-c---sample-accountant-letters-confirming-specified-information). - C. **Authenticity**: To confirm the authenticity of the accountant's opinion, the CA MUST make a telephone call or send a copy of the Verified Accountant Letter back to the Accounting Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Accounting Practitioner listed with the authority responsible for registering or licensing such Accounting Practitioners and obtain confirmation from the Accounting Practitioner or the Accounting Practitioner's assistant that the accountant letter is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Accountant in records provided by the applicable phone company, QGIS, or QIIS. + B. **Basis of Opinion**: The text of the Verified Accountant Letter MUST make clear that the Accounting Practitioner is acting on behalf of the Applicant and that the information in the letter is based on the Accounting Practitioner's stated familiarity with the relevant facts and the exercise of the practitioner's professional judgment and expertise. The Verified Accountant Letter MAY also include disclaimers and other limitations customary in the Accounting Practitioner's jurisdiction, provided that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Accounting Practitioner, should the Verified Accountant Letter prove to be erroneous. Acceptable forms of Verified Accountant Letter are attached as [Appendix C](#appendix-c---sample-accountant-letters-confirming-specified-information). + C. **Authenticity**: To confirm the authenticity of the accountant's opinion, the CA MUST make a telephone call or send a copy of the Verified Accountant Letter back to the Accounting Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Accounting Practitioner listed with the authority responsible for registering or licensing such Accounting Practitioners and obtain confirmation from the Accounting Practitioner or the Accounting Practitioner's assistant that the accountant letter is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Accountant in records provided by the applicable phone company, QGIS, or QIIS. In circumstances where the opinion is digitally signed, in a manner that confirms the authenticity of the document and the identity of the signer, as verified by the CA in [Section 3.2.2.11.2](#322112-verified-accountant-letter) (2)(A), no further verification of authenticity is required. @@ -814,7 +814,7 @@ Acceptable methods of verifying the Certificate Approver's approval of an EV Cer A. **Qualification of Third-Party Validator**: The CA MUST verify the professional status of the Third-Party Validator by directly contacting the authority responsible for registering or licensing such Third-Party Validators in the applicable jurisdiction; B. **Document Chain of Custody**: The Third-Party Validator MUST submit a statement to the CA which attests that they obtained the Vetting Documents submitted to the CA for the individual during a face-to-face meeting with the individual; - C. **Verification of Attestation**: If the Third-Party Validator is not a Latin Notary, then the CA MUST confirm the authenticity of the vetting documents received from the Third-Party Validator. The CA MUST make a telephone call to the Third-Party Validator and obtain confirmation from them or their assistant that they performed the face-to-face validation. The CA MAY rely upon self-reported information obtained from the Third-Party Validator for the sole purpose of performing this verification process. In circumstances where the attestation is digitally signed, in a manner that confirms the authenticity of the documents, and the identity of the signer as verified by the CA in [Section 3.2.2.11.3](#322113-face-to-face-validation) (1)(A), no further verification of authenticity is required. + C. **Verification of Attestation**: If the Third-Party Validator is not a Latin Notary, then the CA MUST confirm the authenticity of the vetting documents received from the Third-Party Validator. The CA MUST make a telephone call to the Third-Party Validator and obtain confirmation from them or their assistant that they performed the face-to-face validation. The CA MAY rely upon self-reported information obtained from the Third-Party Validator for the sole purpose of performing this verification process. In circumstances where the attestation is digitally signed, in a manner that confirms the authenticity of the documents, and the identity of the signer as verified by the CA in [Section 3.2.2.11.3](#322113-face-to-face-validation) (1)(A), no further verification of authenticity is required. ##### 3.2.2.11.4 Independent Confirmation From Applicant @@ -834,7 +834,7 @@ An Independent Confirmation from the Applicant MAY be obtained via the following ii. The Applicant's Registered Agent or Registered Office in the Jurisdiction of Incorporation as listed in the official records of the Incorporating Agency, with instructions that it be forwarded to an appropriate Confirming Person; or iii. A named individual verified to be in the direct line of management above the Contract Signer or Certificate Approver by contacting the Applicant's Human Resources Department by phone or mail (at the phone number or address for the Applicant's Place of Business, verified in accordance with these Guidelines). - B. **Means of Communication**: The Confirmation Request MUST be directed to the Confirming Person in a manner reasonably likely to reach such person. The following options are acceptable: + B. **Means of Communication**: The Confirmation Request MUST be directed to the Confirming Person in a manner reasonably likely to reach such person. The following options are acceptable: i. By paper mail addressed to the Confirming Person at: @@ -844,18 +844,18 @@ An Independent Confirmation from the Applicant MAY be obtained via the following ii. By e-mail addressed to the Confirming Person at the business e-mail address for such person listed in a current QGIS, QTIS, QIIS, Verified Legal Opinion, or Verified Accountant Letter; or iii. By telephone call to the Confirming Person, where such person is contacted by calling the main phone number of the Applicant's Place of Business (verified in accordance with these Guidelines) and asking to speak to such person, and a person taking the call identifies him- or herself as such person; or - iv. By facsimile to the Confirming Person at the Place of Business. The facsimile number must be listed in a current QGIS, QTIS, QIIS, Verified Legal Opinion, or Verified Accountant Letter. The cover page must be clearly addressed to the Confirming Person. + iv. By facsimile to the Confirming Person at the Place of Business. The facsimile number must be listed in a current QGIS, QTIS, QIIS, Verified Legal Opinion, or Verified Accountant Letter. The cover page must be clearly addressed to the Confirming Person. -2. **Confirmation Response**: The CA MUST receive a response to the Confirmation Request from a Confirming Person that confirms the particular fact at issue. Such response MAY be provided to the CA by telephone, by e-mail, or by paper mail, so long as the CA can reliably verify that it was provided by a Confirming Person in response to the Confirmation Request. +2. **Confirmation Response**: The CA MUST receive a response to the Confirmation Request from a Confirming Person that confirms the particular fact at issue. Such response MAY be provided to the CA by telephone, by e-mail, or by paper mail, so long as the CA can reliably verify that it was provided by a Confirming Person in response to the Confirmation Request. -3. The CA MAY rely on a verified Confirming Person to confirm their own contact information: email address, telephone number, and facsimile number. The CA MAY rely on this verified contact information for future correspondence with the Confirming Person if: +3. The CA MAY rely on a verified Confirming Person to confirm their own contact information: email address, telephone number, and facsimile number. The CA MAY rely on this verified contact information for future correspondence with the Confirming Person if: A. The domain of the e-mail address is owned by the Applicant and is the Confirming Person's own e-mail address and not a group e-mail alias; B. The Confirming Person's telephone/fax number is verified by the CA to be a telephone number that is part of the organization's telephone system, and is not the personal phone number for the person. ##### 3.2.2.11.5 Qualified Independent Information Source -A Qualified Independent Information Source (QIIS) is a regularly-updated and publicly available database that is generally recognized as a dependable source for certain information. A database qualifies as a QIIS if the CA determines that: +A Qualified Independent Information Source (QIIS) is a regularly-updated and publicly available database that is generally recognized as a dependable source for certain information. A database qualifies as a QIIS if the CA determines that: 1. Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and @@ -917,13 +917,13 @@ A CA verifying an Applicant using information of the Applicant's Parent, Subsidi #### 3.2.2.13 Final Cross-Correlation and Due Diligence -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. +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. -4. In the case where some or all of the documentation used to support the application is in a language other than the CA's normal operating language, the CA or its Affiliate MUST perform the requirements of this Final Cross-Correlation and Due Diligence section using employees under its control and having appropriate training, experience, and judgment in confirming organizational identification and authorization and fulfilling all qualification requirements contained in [Section 5.3.2](#532-background-check-procedures). When employees under the control of the CA do not possess the language skills necessary to perform the Final Cross-Correlation and Due Diligence a CA MAY: +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. +4. In the case where some or all of the documentation used to support the application is in a language other than the CA's normal operating language, the CA or its Affiliate MUST perform the requirements of this Final Cross-Correlation and Due Diligence section using employees under its control and having appropriate training, experience, and judgment in confirming organizational identification and authorization and fulfilling all qualification requirements contained in [Section 5.3.2](#532-background-check-procedures). When employees under the control of the CA do not possess the language skills necessary to perform the Final Cross-Correlation and Due Diligence a CA MAY: A. Rely on language translations of the relevant portions of the documentation, provided that the translations are received from a Translator; or - 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 3.2.2.13](#32213-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 + 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 3.2.2.13](#32213-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 8.1.1](#811-self-audits) and [Section 8.2](#82-identityqualifications-of-assessor). In the case of EV Certificates to be issued in compliance with the requirements of [Section 1.3.2](#132-registration-authorities), the Enterprise RA MAY perform the requirements of this Final Cross-Correlation and Due Diligence section. @@ -960,7 +960,7 @@ A CA may rely on a previously verified certificate request to issue a replacemen D. Verified Method of Communication – 398 days; E. Operational existence – 398 days; F. Domain Name – 398 days; - G. Name, Title, Agency, and Authority – 398 days, unless a contract between the CA and the Applicant specifies a different term, in which case, the term specified in such contract controls. For example, the contract MAY include the perpetual assignment of EV roles until revoked by the Applicant or CA, or until the contract expires or is terminated. + G. Name, Title, Agency, and Authority – 398 days, unless a contract between the CA and the Applicant specifies a different term, in which case, the term specified in such contract controls. For example, the contract MAY include the perpetual assignment of EV roles until revoked by the Applicant or CA, or until the contract expires or is terminated. 2. The 398-day period set forth above SHALL begin to run on the date the information was collected by the CA. 3. The CA MAY reuse a previously submitted EV Certificate Request, Subscriber Agreement, or Terms of Use, including use of a single EV Certificate Request in support of multiple EV Certificates containing the same Subject to the extent permitted under [Section 3.2.2.9](#3229-verification-of-signature-on-subscriber-agreement-and-ev-certificate-requests) and [Section 3.2.2.10](#32210-verification-of-approval-of-ev-certificate-request). @@ -1038,7 +1038,7 @@ An Applicant qualifies as a Business Entity if: An Applicant qualifies as a Non-Commercial Entity if: -1. The Applicant is an International Organization Entity, created under a charter, treaty, convention or equivalent instrument that was signed by, or on behalf of, more than one country's government. The CA/Browser Forum may publish a listing of Applicants who qualify as an International Organization for EV eligibility; and +1. The Applicant is an International Organization Entity, created under a charter, treaty, convention or equivalent instrument that was signed by, or on behalf of, more than one country's government. The CA/Browser Forum may publish a listing of Applicants who qualify as an International Organization for EV eligibility; and 2. The Applicant is not headquartered in any country where the CA is prohibited from doing business or issuing a certificate by the laws of the CA's jurisdiction; and @@ -1057,16 +1057,16 @@ The Certificate Request requirements in Section 4.1.2 of the Baseline Requiremen The following Applicant roles are required for the issuance of an EV Certificate. -1. **Certificate Requester**: The EV Certificate Request MUST be submitted by an authorized Certificate Requester. A Certificate Requester is a natural person who is either the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or a third party (such as an ISP or hosting company) that completes and submits an EV Certificate Request on behalf of the Applicant. +1. **Certificate Requester**: The EV Certificate Request MUST be submitted by an authorized Certificate Requester. A Certificate Requester is a natural person who is either the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or a third party (such as an ISP or hosting company) that completes and submits an EV Certificate Request on behalf of the Applicant. -2. **Certificate Approver**: The EV Certificate Request MUST be approved by an authorized Certificate Approver. A Certificate Approver is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant to +2. **Certificate Approver**: The EV Certificate Request MUST be approved by an authorized Certificate Approver. A Certificate Approver is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant to i. act as a Certificate Requester and to authorize other employees or third parties to act as a Certificate Requester, and ii. to approve EV Certificate Requests submitted by other Certificate Requesters. -3. **Contract Signer**: A Subscriber Agreement applicable to the requested EV Certificate MUST be signed by an authorized Contract Signer. A Contract Signer is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements. +3. **Contract Signer**: A Subscriber Agreement applicable to the requested EV Certificate MUST be signed by an authorized Contract Signer. A Contract Signer is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements. -4. **Applicant Representative**: In the case where the CA and the Subscriber are affiliated, Terms of Use applicable to the requested EV Certificate MUST be acknowledged and agreed to by an authorized Applicant Representative. An Applicant Representative is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to acknowledge and agree to the Terms of Use. +4. **Applicant Representative**: In the case where the CA and the Subscriber are affiliated, Terms of Use applicable to the requested EV Certificate MUST be acknowledged and agreed to by an authorized Applicant Representative. An Applicant Representative is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to acknowledge and agree to the Terms of Use. The Applicant MAY authorize one individual to occupy two or more of these roles. The Applicant MAY authorize more than one individual to occupy any of these roles. @@ -1228,7 +1228,7 @@ As specified in Section 5 of the Baseline Requirements. In addition, systems use ### 5.2.4 Roles requiring separation of duties -1. The CA MUST enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the issuance of an EV Certificate. The Final Cross-Correlation and Due Diligence steps, as outlined in [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence), MAY be performed by one of the persons. For example, one Validation Specialist MAY review and verify all the Applicant information and a second Validation Specialist MAY approve issuance of the EV Certificate. +1. The CA MUST enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the issuance of an EV Certificate. The Final Cross-Correlation and Due Diligence steps, as outlined in [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence), MAY be performed by one of the persons. For example, one Validation Specialist MAY review and verify all the Applicant information and a second Validation Specialist MAY approve issuance of the EV Certificate. 2. Such controls MUST be auditable. ## 5.3 Personnel controls @@ -1259,7 +1259,7 @@ Prior to the commencement of employment of any person by the CA for engagement i ### 5.3.3 Training requirements -The requirements in Section 5.3.3 of the Baseline Requirements apply equally to EV Certificates and these Guidelines. The required internal examination must relate to the EV Certificate validation criteria outlined in these Guidelines. +The requirements in Section 5.3.3 of the Baseline Requirements apply equally to EV Certificates and these Guidelines. The required internal examination must relate to the EV Certificate validation criteria outlined in these Guidelines. ### 5.3.4 Retraining frequency and requirements @@ -1327,7 +1327,7 @@ As specified in Section 5.4 of the Baseline Requirements. ### 6.1.1 Key pair generation -All requirements in Section 6.1.1.1 of the Baseline Requirements apply equally to EV Certificates. However, for Root CA Key Pairs generated after the release of these Guidelines, the Root CA Key Pair generation ceremony MUST be witnessed by the CA's Qualified Auditor in order to observe the process and the controls over the integrity and confidentiality of the Root CA Key Pairs produced. The Qualified Auditor MUST then issue a report opining that the CA, during its Root CA Key Pair and Certificate generation process: +All requirements in Section 6.1.1.1 of the Baseline Requirements apply equally to EV Certificates. However, for Root CA Key Pairs generated after the release of these Guidelines, the Root CA Key Pair generation ceremony MUST be witnessed by the CA's Qualified Auditor in order to observe the process and the controls over the integrity and confidentiality of the Root CA Key Pairs produced. The Qualified Auditor MUST then issue a report opining that the CA, during its Root CA Key Pair and Certificate generation process: 1. Documented its Root CA key generation and protection procedures in its Certificate Policy, and its Certification Practices Statement; 2. Included appropriate detail in its Root Key Generation Script; @@ -1416,15 +1416,15 @@ This section sets forth minimum requirements for the content of the EV Certifica ### 7.1.2 Certificate extensions -The extensions listed in [Section 7.1.2](#712-certificate-extensions) are recommended for maximum interoperability between certificates and browsers / applications, but are not mandatory on the CAs except where indicated as “Required”. CAs may use other extensions that are not listed in [Section 7.1.2](#712-certificate-extensions), but are encouraged to add them to this section by ballot from time to time to help increase extension standardization across the industry. +The extensions listed in [Section 7.1.2](#712-certificate-extensions) are recommended for maximum interoperability between certificates and browsers / applications, but are not mandatory on the CAs except where indicated as “Required”. CAs may use other extensions that are not listed in [Section 7.1.2](#712-certificate-extensions), but are encouraged to add them to this section by ballot from time to time to help increase extension standardization across the industry. -If a CA includes an extension in a certificate that has a Certificate field which is named in [Section 7.1.2](#712-certificate-extensions), the CA must follow the format specified in that subsection. However, no extension or extension format shall be mandatory on a CA unless specifically stated as “Required” in the subsection that describes the extension. +If a CA includes an extension in a certificate that has a Certificate field which is named in [Section 7.1.2](#712-certificate-extensions), the CA must follow the format specified in that subsection. However, no extension or extension format shall be mandatory on a CA unless specifically stated as “Required” in the subsection that describes the extension. #### 7.1.2.1 Subject Alternative Name Extension **Certificate Field**: `subjectAltName:dNSName` **Required/Optional**: **Required** -**Contents**: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This extension MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. +**Contents**: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This extension MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. #### 7.1.2.2 CA/Browser Forum Organization Identifier Extension @@ -1488,7 +1488,7 @@ If the combination of names or the organization name by itself exceeds 64 charac **Certificate Field**: `subject:commonName` (OID: 2.5.4.3) **Required/Optional**: Deprecated (Discouraged, but not prohibited) -**Contents**: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This field MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. +**Contents**: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This field MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. ##### 7.1.4.2.3 Subject Business Category Field @@ -1510,7 +1510,7 @@ Country: `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) **Required/Optional**: Required -**Contents**: These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. Country information MUST be specified using the applicable ISO country code. State or province or locality information (where applicable) for the Subject's Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction. +**Contents**: These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. Country information MUST be specified using the applicable ISO country code. State or province or locality information (where applicable) for the Subject's Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction. Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, the values within these fields have been disclosed within the latest publicly-available disclosure, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), as acceptable values for the applicable Incorporating Agency or Registration Agency. @@ -1518,10 +1518,10 @@ Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, t **Certificate Field**: `subject:serialNumber` (OID: 2.5.4.5) **Required/Optional**: **Required** -**Contents**: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). +**Contents**: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). For Government Entities that do not have a Registration Number or readily verifiable date of creation, the CA SHALL enter appropriate language to indicate that the Subject is a Government Entity. -For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). +For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). Effective as of 1 October 2020, if the CA has disclosed a set of acceptable format or formats for Registration Numbers for the applicable Registration Agency or Incorporating Agency, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), the CA MUST ensure, prior to issuance, that the Registration Number is valid according to at least one currently disclosed format for that applicable Registration Agency or Incorporating agency. @@ -1536,9 +1536,9 @@ Effective as of 1 October 2020, if the CA has disclosed a set of acceptable form **Required/Optional**: Required/Optional **Contents**: These fields MUST contain the verified physical address of the Subject’s Place of Business. -The `countryName` field MUST be present and MUST contain the applicable two-letter ISO 3166-1 country code. If the country is not represented by an official ISO 3166-1 code, the ISO 3166-1 user-assigned code "XX" MUST be used. +The `countryName` field MUST be present and MUST contain the applicable two-letter ISO 3166-1 country code. If the country is not represented by an official ISO 3166-1 code, the ISO 3166-1 user-assigned code "XX" MUST be used. -The `localityName` and `stateOrProvinceName` fields are OPTIONAL, but at least one of them MUST be present. When included, these fields MUST accurately represent the locality and/or state or province information verified in accordance with Section 3.2.2.1 of the Baseline Requirements. +The `localityName` and `stateOrProvinceName` fields are OPTIONAL, but at least one of them MUST be present. When included, these fields MUST accurately represent the locality and/or state or province information verified in accordance with Section 3.2.2.1 of the Baseline Requirements. The `streetAddress` and `postalCode` fields are OPTIONAL. If present, they MUST contain the verified street address and postal information of the Subject’s Place of Business as required by Section 3.2.2.1 of the Baseline Requirements. Multiple `streetAddress` attributes MAY be present. @@ -1557,22 +1557,22 @@ The organizationIdentifier MUST be encoded as a PrintableString or UTF8String. The Registration Scheme MUST be identified using the using the following structure in the presented order: -* 3 character Registration Scheme identifier; -* 2 character ISO 3166 country code for the nation in which the Registration Scheme is operated, or if the scheme is operated globally ISO 3166 code "XG" shall be used; -* For the NTR Registration Scheme identifier, where registrations are administrated at the subdivision (state or province) level, if required under [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field), a plus "+" (0x2B (ASCII), U+002B (UTF-8)) followed by an up-to-three alphanumeric character ISO 3166-2 identifier for the subdivision of the nation in which the Registration Scheme is operated; -* a hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8)); -* Registration Reference allocated in accordance with the identified Registration Scheme +- 3 character Registration Scheme identifier; +- 2 character ISO 3166 country code for the nation in which the Registration Scheme is operated, or if the scheme is operated globally ISO 3166 code "XG" shall be used; +- For the NTR Registration Scheme identifier, where registrations are administrated at the subdivision (state or province) level, if required under [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field), a plus "+" (0x2B (ASCII), U+002B (UTF-8)) followed by an up-to-three alphanumeric character ISO 3166-2 identifier for the subdivision of the nation in which the Registration Scheme is operated; +- a hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8)); +- Registration Reference allocated in accordance with the identified Registration Scheme -Note: Registration References MAY contain hyphens, but Registration Schemes, ISO 3166 country codes, and ISO 3166-2 identifiers do not. Therefore if more than one hyphen appears in the structure, the leftmost hyphen is a separator, and the remaining hyphens are part of the Registration Reference. +Note: Registration References MAY contain hyphens, but Registration Schemes, ISO 3166 country codes, and ISO 3166-2 identifiers do not. Therefore if more than one hyphen appears in the structure, the leftmost hyphen is a separator, and the remaining hyphens are part of the Registration Reference. As in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field), the specified location information MUST match the scope of the registration being referenced. Examples: -* `NTRGB-12345678` (NTR scheme, Great Britain, Unique Identifier at Country level is 12345678) -* `NTRUS+CA-12345678` (NTR Scheme, United States - California, Unique identifier at State level is 12345678) -* `VATDE-123456789` (VAT Scheme, Germany, Unique Identifier at Country Level is 12345678) -* `PSDBE-NBB-1234.567.890` (PSD Scheme, Belgium, NCA's identifier is NBB, Subject Unique Identifier assigned by the NCA is 1234.567.890) +- `NTRGB-12345678` (NTR scheme, Great Britain, Unique Identifier at Country level is 12345678) +- `NTRUS+CA-12345678` (NTR Scheme, United States - California, Unique identifier at State level is 12345678) +- `VATDE-123456789` (VAT Scheme, Germany, Unique Identifier at Country Level is 12345678) +- `PSDBE-NBB-1234.567.890` (PSD Scheme, Belgium, NCA's identifier is NBB, Subject Unique Identifier assigned by the NCA is 1234.567.890) Registration Schemes listed in [Appendix H](#appendix-h--registration-schemes) are currently recognized as valid under these guidelines. @@ -1597,7 +1597,7 @@ All provisions of the Baseline Requirements concerning Minimum Cryptographic Alg 2. The `certificatePolicies` extension in EV Certificates issued to Subscribers MUST include the following: - * `certificatePolicies:policyIdentifier` (Required) + - `certificatePolicies:policyIdentifier` (Required) The Issuer's EV policy identifier @@ -1631,7 +1631,7 @@ The Application Software Supplier identifies Root CAs that are approved to issue #### 7.1.6.4 Subscriber Certificates -A Certificate issued to a Subscriber MUST contain one or more policy identifier(s), defined by the Issuing CA, in the Certificate's `certificatePolicies` extension that indicates adherence to and compliance with these Guidelines. Each CA SHALL document in its Certificate Policy or Certification Practice Statement that the Certificates it issues containing the specified policy identifier(s) are managed in accordance with these Guidelines. +A Certificate issued to a Subscriber MUST contain one or more policy identifier(s), defined by the Issuing CA, in the Certificate's `certificatePolicies` extension that indicates adherence to and compliance with these Guidelines. Each CA SHALL document in its Certificate Policy or Certification Practice Statement that the Certificates it issues containing the specified policy identifier(s) are managed in accordance with these Guidelines. ### 7.1.7 Usage of Policy Constraints extension @@ -1667,7 +1667,7 @@ CAs issuing EV Certificates MUST undergo an annual audit that meets the criteria ### 8.1.1 Self audits -During the period in which it issues EV Certificates, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least three percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. For all EV Certificates where the Final Cross-Correlation and Due Diligence requirements of [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence) is performed by an RA, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least six percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. +During the period in which it issues EV Certificates, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least three percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. For all EV Certificates where the Final Cross-Correlation and Due Diligence requirements of [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence) is performed by an RA, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least six percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. ## 8.2 Identity/qualifications of assessor @@ -1681,7 +1681,7 @@ A Qualified Auditor (as defined in Section 8.2 of the Baseline Requirements) MUS ## 8.6 Communication of results -CAs SHOULD make its audit report publicly available no later than three months after the end of the audit period. If there is a delay greater than three months and if so requested by an Application Software Supplier, the CA MUST provide an explanatory letter signed by its auditor. +CAs SHOULD make its audit report publicly available no later than three months after the end of the audit period. If there is a delay greater than three months and if so requested by an Application Software Supplier, the CA MUST provide an explanatory letter signed by its auditor. ## 8.7 Pre-issuance Readiness Audit @@ -1692,7 +1692,7 @@ CAs SHOULD make its audit report publicly available no later than three months a i. a point-in-time readiness assessment audit against the WebTrust for CA Program, or ii. a point-in-time readiness assessment audit against the WebTrust EV Program, the ETSI TS 102 042 EVCP, or the ETSI EN 319 411-1 for EVCP policy. -The CA MUST complete any required point-in-time readiness assessment no earlier than twelve (12) months prior to issuing an EV Certificate. The CA MUST undergo a complete audit under such scheme within ninety (90) days of issuing the first EV Certificate. +The CA MUST complete any required point-in-time readiness assessment no earlier than twelve (12) months prior to issuing an EV Certificate. The CA MUST undergo a complete audit under such scheme within ninety (90) days of issuing the first EV Certificate. # 9. OTHER BUSINESS AND LEGAL MATTERS @@ -1758,7 +1758,7 @@ A CA MAY self-insure for liabilities that arise from such party's performance an ### 9.6.1 CA representations and warranties -When the CA issues an EV Certificate, the CA and its Root CA represent and warrant to the Certificate Beneficiaries listed in Section 9.6.1 of the Baseline Requirements, during the period when the EV Certificate is Valid, that the CA has followed the requirements of these Guidelines and its EV Policies in issuing and managing the EV Certificate and in verifying the accuracy of the information contained in the EV Certificate. The EV Certificate Warranties specifically include, but are not limited to, the following: +When the CA issues an EV Certificate, the CA and its Root CA represent and warrant to the Certificate Beneficiaries listed in Section 9.6.1 of the Baseline Requirements, during the period when the EV Certificate is Valid, that the CA has followed the requirements of these Guidelines and its EV Policies in issuing and managing the EV Certificate and in verifying the accuracy of the information contained in the EV Certificate. The EV Certificate Warranties specifically include, but are not limited to, the following: A. **Legal Existence**: The CA has confirmed with the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration that, as of the date the EV Certificate was issued, the Subject named in the EV Certificate legally exists as a valid organization or entity in the Jurisdiction of Incorporation or Registration; @@ -1780,7 +1780,7 @@ H. **Revocation**: The CA will follow the requirements of these Guidelines and ### 9.6.3 Subscriber representations and warranties -Section 9.6.3 of the Baseline Requirements applies equally to EV Certificates. In cases where the Certificate Request does not contain all necessary information about the Applicant, the CA MUST additionally confirm the data with the Certificate Approver or Contract Signer rather than the Certificate Requester. +Section 9.6.3 of the Baseline Requirements applies equally to EV Certificates. In cases where the Certificate Request does not contain all necessary information about the Applicant, the CA MUST additionally confirm the data with the Certificate Approver or Contract Signer rather than the Certificate Requester. EV Certificate Applicants make the commitments and warranties set forth in Section 9.6.3 of the Baseline Requirements for the benefit of the CA and Certificate Beneficiaries. @@ -1842,7 +1842,7 @@ Section 9.16.3 of the Baseline Requirements applies equally to EV Certificates. # Appendix A - User Agent Verification (Normative) -The CA MUST host test Web pages that allow Application Software Suppliers to test their software with EV Certificates that chain up to each EV Root Certificate. At a minimum, the CA MUST host separate Web pages using certificates that are: +The CA MUST host test Web pages that allow Application Software Suppliers to test their software with EV Certificates that chain up to each EV Root Certificate. At a minimum, the CA MUST host separate Web pages using certificates that are: i. valid; ii. revoked; and @@ -1863,7 +1863,7 @@ The CA MUST host test Web pages that allow Application Software Suppliers to tes | Client Representative: | **(Exact name of Client Representative who signed the Application – see footnote 2)** | | Application Date: | **(Insert date of Client's Application to the Issuing CA)** | -This firm represents _[**exact** company name of Client]_ [^1] ("Client"), who has submitted the Application to you dated as of the Application Date shown above ("Application"). We have been asked by our Client to present you with our opinion as stated in this letter. +This firm represents _[**exact** company name of Client]_ [^1] ("Client"), who has submitted the Application to you dated as of the Application Date shown above ("Application"). We have been asked by our Client to present you with our opinion as stated in this letter. [Insert customary preliminary matters for opinion letters in your jurisdiction.] @@ -1899,7 +1899,7 @@ _[Jurisdiction(s) in which attorney / Latin notary is admitted to practice]_[^3] cc: [Send copy to Client_]_ -[^1]: This must be the Client's exact corporate name, as registered with the relevant Incorporating Agency in the Client's Jurisdiction of Incorporation. This is the name that will be included in the EV Certificate. +[^1]: This must be the Client's exact corporate name, as registered with the relevant Incorporating Agency in the Client's Jurisdiction of Incorporation. This is the name that will be included in the EV Certificate. [^2]: If necessary to establish the Client Representative's actual authority, you may rely on a Power of Attorney from an officer of Client who has authority to delegate the authority to the Client Representative. @@ -1909,7 +1909,7 @@ cc: [Send copy to Client_]_ **(Informative)** -It is acceptable for professional accountants to provide letters that address specified matters. The letters would be provided in accordance with the professional standards in the jurisdiction in which the accountant practices. +It is acceptable for professional accountants to provide letters that address specified matters. The letters would be provided in accordance with the professional standards in the jurisdiction in which the accountant practices. Two examples of the letter that might be prepared by an accountant in the United States and in Canada follow: @@ -1917,9 +1917,9 @@ Two examples of the letter that might be prepared by an accountant in the United To the [Certification Authority] and Management of [Client]: -We have performed the procedures enumerated below, which were agreed to by the Managements of Client, solely to assist you in evaluating the company's application for an Extended Validation (EV) Certificate, dated......................., 20...... This agreed-upon procedures engagement was conducted in accordance with attestation standards established by the American Institute of Certified Public Accountants. The sufficiency of these procedures is solely the responsibility of those parties specified in this report. Consequently, we make no representation regarding the sufficiency of the procedures described below either for the purpose for which this report has been requested or for any other purpose. +We have performed the procedures enumerated below, which were agreed to by the Managements of Client, solely to assist you in evaluating the company's application for an Extended Validation (EV) Certificate, dated......................., 20...... This agreed-upon procedures engagement was conducted in accordance with attestation standards established by the American Institute of Certified Public Accountants. The sufficiency of these procedures is solely the responsibility of those parties specified in this report. Consequently, we make no representation regarding the sufficiency of the procedures described below either for the purpose for which this report has been requested or for any other purpose. -| Specified Information: | Procedure:(Note 1: These are illustrative of the procedures that would be undertaken and are designed to meet the needs of the Certification Authorities issuing Extended Validation Certificates) | Results: (Note 2: If you are unavailable to perform any of the stated procedure, this should be noted in this column. Any exceptions should be noted in a separate paragraph below) | +| Specified Information: | Procedure:(Note 1: These are illustrative of the procedures that would be undertaken and are designed to meet the needs of the Certification Authorities issuing Extended Validation Certificates) | Results: (Note 2: If you are unavailable to perform any of the stated procedure, this should be noted in this column. Any exceptions should be noted in a separate paragraph below) | | --- | --- | --- | | | | | | Legal Name - 123456 Delaware corporation | Agree legal name to permanent audit file information (If audit has been completed). | Legal name on the application agrees with the information contained in our permanent file with respect to Client.(If there is no permanent file, state this fact) | @@ -1928,7 +1928,7 @@ We have performed the procedures enumerated below, which were agreed to by the M | | | | | Physical location - "Address Information" | Visit the location at the address | Site visit completed at Address | | | | | -| Business Phone Number - 555 999 9999 | Phone the number provided and confirm that it was answered by the named organization | Phoned Business Number and noted that it was answered with the Doing Business As name. This would provided by the receptionist | +| Business Phone Number - 555 999 9999 | Phone the number provided and confirm that it was answered by the named organization | Phoned Business Number and noted that it was answered with the Doing Business As name. This would provided by the receptionist | | | | | | Bank Account – "Bank Name", "Account Number" | Request a letter directly from "the Bank" confirming the existence of the account for the benefit of "the Client" | Received letter directly from "the Bank" confirming the existence of the account for the benefit of "the Client" | | | | | @@ -1936,7 +1936,7 @@ We have performed the procedures enumerated below, which were agreed to by the M | | | | | Name of application signer and approver | Obtain letter from verified Officer confirming the names of the application signer and approver | Obtained letter from the President confirming the names of the duly authorized names of the application signer and approver as they appear in the application | -We were not engaged to and did not conduct an examination, the objective of which would be the expression of an opinion on the Application for Extended Validation Certificate. Accordingly, we do not express such an opinion. Had we performed additional procedures, other matters might have come to our attention that would have been reported to you. +We were not engaged to and did not conduct an examination, the objective of which would be the expression of an opinion on the Application for Extended Validation Certificate. Accordingly, we do not express such an opinion. Had we performed additional procedures, other matters might have come to our attention that would have been reported to you. This report is intended solely for the information and use of the Certification Authority and managements of Client, and is not intended to be and should not be used by anyone other than these specified parties. @@ -1950,9 +1950,9 @@ To: [Name of Certification Authority] Re: Client Limited [Applicant] -As specifically agreed, I/we have performed the following procedures in connection with the above company's application for an Extended Validation (EV) Certificate, dated ......................., 20.... with respect to the following specified information contained in the application +As specifically agreed, I/we have performed the following procedures in connection with the above company's application for an Extended Validation (EV) Certificate, dated ......................., 20.... with respect to the following specified information contained in the application -| Specified Information: | Procedure:(Note 1: These are illustrative of the procedures that would be undertaken and are designed to meet the needs of the Certification Authorities issuing Extended Validation Certificates) | Results: (Note 2: If you are unavailable to perform any of the stated procedure, this should be noted in this column. Any exceptions should be noted in a separate paragraph below) | +| Specified Information: | Procedure:(Note 1: These are illustrative of the procedures that would be undertaken and are designed to meet the needs of the Certification Authorities issuing Extended Validation Certificates) | Results: (Note 2: If you are unavailable to perform any of the stated procedure, this should be noted in this column. Any exceptions should be noted in a separate paragraph below) | | --- | --- | --- | | | | | | Legal Name - 123456 Ontario limited | Agree legal name to permanent audit file information (If audit has been completed) | Legal name on the application agrees with the information contained in our permanent file with respect to Client.(If there is no permanent file, state this fact) | @@ -1961,7 +1961,7 @@ As specifically agreed, I/we have performed the following procedures in connecti | | | | | Physical location - "Address Information" | Visit the location at the address | Site visit completed at Address | | | | | -| Business Phone Number - 555 999 9999 | Phone the number provided and confirm that it was answered by the named organization | Phoned Business Number and noted that it was answered with the Doing Business As name. This would provided by the receptionist | +| Business Phone Number - 555 999 9999 | Phone the number provided and confirm that it was answered by the named organization | Phoned Business Number and noted that it was answered with the Doing Business As name. This would provided by the receptionist | | | | | | Bank Account – "Bank Name", "Account Number" | Request a letter directly from "the Bank" confirming the existence of the account for the benefit of "the Client" | Received letter directly from "the Bank" confirming the existence of the account for the benefit of "the Client" | | | | | @@ -1969,7 +1969,7 @@ As specifically agreed, I/we have performed the following procedures in connecti | | | | | Name of application signer and approver | Obtain letter from verified Officer confirming the names of the application signer and approver | Obtained letter from the President confirming the names of the duly authorized names of the application signer and approver as they appear in the application | -As a result of applying the above procedures, I/we found [no / the following] exceptions [list of exceptions]. However, these procedures do not constitute an audit of the company's application for an EV Certificate, and therefore I express no opinion on the application dated ......................., 20..... +As a result of applying the above procedures, I/we found [no / the following] exceptions [list of exceptions]. However, these procedures do not constitute an audit of the company's application for an EV Certificate, and therefore I express no opinion on the application dated ......................., 20..... This letter is for use solely in connection with the application for an Extended Validation Certificate by [Client] dated ......................., 20...... @@ -1979,13 +1979,13 @@ City # Appendix D - Country-Specific Interpretative Guidelines (Normative) -NOTE: This appendix provides alternative interpretations of the EV Guidelines for countries that have a language, cultural, technical, or legal reason for deviating from a strict interpretation of the EV Guidelines. More specific information for particular countries may be added to this appendix in the future. +NOTE: This appendix provides alternative interpretations of the EV Guidelines for countries that have a language, cultural, technical, or legal reason for deviating from a strict interpretation of the EV Guidelines. More specific information for particular countries may be added to this appendix in the future. ## 1. Organization Names 1. Non-Latin Organization Name - Where an EV Applicant's organization name is not registered with a QGIS in _Latin_ characters and the Applicant's foreign character organization name and registration have been verified with a QGIS in accordance with these Guidelines, a CA MAY include a Latin character organization name in the EV Certificate. In such a case, the CA MUST follow the procedures laid down in this section. + Where an EV Applicant's organization name is not registered with a QGIS in _Latin_ characters and the Applicant's foreign character organization name and registration have been verified with a QGIS in accordance with these Guidelines, a CA MAY include a Latin character organization name in the EV Certificate. In such a case, the CA MUST follow the procedures laid down in this section. 2. Romanized Names @@ -2016,8 +2016,8 @@ As interpretation of the procedures set out above: A. The Revised Hepburn method of Romanization, as well as Kunrei-shiki and Nihon-shiki methods described in ISO 3602, are acceptable for Japanese Romanizations. B. The CA MAY verify the Romanized transliteration, language translation (e.g. English name), or other recognized Roman-letter substitute of the Applicant's formal legal name with either a QIIS, Verified Legal Opinion, or Verified Accountant Letter. - C. The CA MAY use the Financial Services Agency to verify a Romanized, translated, or other recognized Roman-letter substitute name. When used, the CA MUST verify that the translated English is recorded in the audited Financial Statements. - D. When relying on Articles of Incorporation to verify a Romanized, translated, or other recognized Roman-letter substitute name, the Articles of Incorporation MUST be accompanied either: by a document, signed with the original Japanese Corporate Stamp, that proves that the Articles of Incorporation are authentic and current, or by a Verified Legal Opinion or a Verified Accountant Letter. The CA MUST verify the authenticity of the Corporate Stamp. + C. The CA MAY use the Financial Services Agency to verify a Romanized, translated, or other recognized Roman-letter substitute name. When used, the CA MUST verify that the translated English is recorded in the audited Financial Statements. + D. When relying on Articles of Incorporation to verify a Romanized, translated, or other recognized Roman-letter substitute name, the Articles of Incorporation MUST be accompanied either: by a document, signed with the original Japanese Corporate Stamp, that proves that the Articles of Incorporation are authentic and current, or by a Verified Legal Opinion or a Verified Accountant Letter. The CA MUST verify the authenticity of the Corporate Stamp. E. A Romanized, translated, or other recognized Roman-lettered substitute name confirmed in accordance with this [Appendix D-1](#d-1-japan) stored in the ROBINS database operated by JIPDEC MAY be relied upon by a CA for determining the allowed organization name during any issuance or renewal process of an EV Certificate without the need to re-perform the above procedures. 2. Accounting Practitioner @@ -2050,9 +2050,9 @@ As interpretation of the procedures set out above: # Appendix E - Sample Contract Signer's Representation/Warranty (Informative) -A CA may rely on the Contract Signer's authority to enter into the Subscriber Agreement using a representation/warranty executed by the Contract Signer. An example of an acceptable warranty is as follows: +A CA may rely on the Contract Signer's authority to enter into the Subscriber Agreement using a representation/warranty executed by the Contract Signer. An example of an acceptable warranty is as follows: -[CA] and Applicant are entering into a legally valid and enforceable Subscriber Agreement that creates extensive obligations on Applicant. An EV Certificate serves as a form of digital identity for Applicant. The loss or misuse of this identity can result in great harm to the Applicant. By signing this Subscriber Agreement, the contract signer acknowledges that they have the authority to obtain the digital equivalent of a company stamp, seal, or (where applicable) officer's signature to establish the authenticity of the company's website, and that [Applicant name] is responsible for all uses of its EV Certificate. By signing this Agreement on behalf of [Applicant name], the contract signer represents that the contract signer +[CA] and Applicant are entering into a legally valid and enforceable Subscriber Agreement that creates extensive obligations on Applicant. An EV Certificate serves as a form of digital identity for Applicant. The loss or misuse of this identity can result in great harm to the Applicant. By signing this Subscriber Agreement, the contract signer acknowledges that they have the authority to obtain the digital equivalent of a company stamp, seal, or (where applicable) officer's signature to establish the authenticity of the company's website, and that [Applicant name] is responsible for all uses of its EV Certificate. By signing this Agreement on behalf of [Applicant name], the contract signer represents that the contract signer i. is acting as an authorized representative of [Applicant name], ii. is expressly authorized by [Applicant name] to sign Subscriber Agreements and approve EV Certificate requests on Applicant's behalf, and @@ -2120,48 +2120,16 @@ END The following Registration Schemes are currently recognized as valid under these guidelines: -* **NTR**: - - The information carried in this field shall be the same as held in - Subject Registration Number Field as specified in - [Section 7.1.4.2.5](#71425-subject-registration-number-field) and the country code - used in the Registration Scheme identifier shall match that of the - subject’s jurisdiction as specified in - [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). - - Where the Subject Jurisdiction of Incorporation or Registration Field in 9.2.4 - includes more than the country code, the additional locality information shall - be included as specified in [Section 7.1.4.2.8](#71428-subject-organization-identifier-field) - and/or [Section 7.1.2.2](#7122-cabrowser-forum-organization-identifier-extension). - -* **VAT**: - - Reference allocated by the national tax authorities to a Legal Entity. This - information shall be validated using information provided by the national tax - authority against the organization as identified by the Subject Organization - Name Field (see [Section 7.1.4.2.1](#71421-subject-organization-name-field)) and - Subject Registration Number Field (see - Section 7.1.4.2.5](#71425-subject-registration-number-field)) within the context of - the subject’s jurisdiction as specified in - [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). - For the purpose of identifying tax authorities, the country prefix described in article 215 of - EU Council Directive 2006/112/EC, as amended, MAY be used instead of the ISO 3166 2-letter country codes. - - * **PSD**: - - Authorization number as specified in ETSI TS 119 495 clause 4.4 - allocated to a payment service provider and containing the information as - specified in ETSI TS 119 495 clause 5.2.1. This information SHALL be - obtained directly from the national competent authority register for - payment services or from an information source approved by a government - agency, regulatory body, or legislation for this purpose. This information - SHALL be validated by being matched directly or indirectly (for example, by - matching a globally unique registration number) against the organization as - identified by the Subject Organization Name Field (see - [Section 7.1.4.2.1](#71421-subject-organization-name-field)) and - Subject Registration Number Field (see - [Section 7.1.4.2.5](#71425-subject-registration-number-field)) within the context of - the subject’s jurisdiction as specified in - [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). - The stated address of the organization combined with the organization name - SHALL NOT be the only information used to disambiguate the organization. +- **NTR**: + + The information carried in this field shall be the same as held in Subject Registration Number Field as specified in [Section 7.1.4.2.5](#71425-subject-registration-number-field) and the country code used in the Registration Scheme identifier shall match that of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). + + Where the Subject Jurisdiction of Incorporation or Registration Field in 9.2.4 includes more than the country code, the additional locality information shall be included as specified in [Section 7.1.4.2.8](#71428-subject-organization-identifier-field) and/or [Section 7.1.2.2](#7122-cabrowser-forum-organization-identifier-extension). + +- **VAT**: + + Reference allocated by the national tax authorities to a Legal Entity. This information shall be validated using information provided by the national tax authority against the organization as identified by the Subject Organization Name Field (see [Section 7.1.4.2.1](#71421-subject-organization-name-field)) and Subject Registration Number Field (see [Section 7.1.4.2.5](#71425-subject-registration-number-field)) within the context of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). For the purpose of identifying tax authorities, the country prefix described in article 215 of EU Council Directive 2006/112/EC, as amended, MAY be used instead of the ISO 3166 2-letter country codes. + +- **PSD**: + + Authorization number as specified in ETSI TS 119 495 clause 4.4 allocated to a payment service provider and containing the information as specified in ETSI TS 119 495 clause 5.2.1. This information SHALL be obtained directly from the national competent authority register for payment services or from an information source approved by a government agency, regulatory body, or legislation for this purpose. This information SHALL be validated by being matched directly or indirectly (for example, by matching a globally unique registration number) against the organization as identified by the Subject Organization Name Field (see [Section 7.1.4.2.1](#71421-subject-organization-name-field)) and Subject Registration Number Field (see [Section 7.1.4.2.5](#71425-subject-registration-number-field)) within the context of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). The stated address of the organization combined with the organization name SHALL NOT be the only information used to disambiguate the organization. From 2c07b1418374fde0a912abd9c76a347b9416941f Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 21:33:19 +0100 Subject: [PATCH 079/121] #432 double spaces --- docs/EVG.md | 80 ++++++++++++++++++++++++++--------------------------- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 77adcec1..31f8060d 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -30,7 +30,7 @@ The CA/Browser Forum is a voluntary open organization of certification authoriti These Guidelines for the issuance and management of Extended Validation Certificates describe certain of the minimum requirements that a Certification Authority must meet in order to issue Extended Validation Certificates. Subject Organization information from Valid EV Certificates may be displayed 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 they are accessing. These Guidelines incorporate the Baseline Requirements established by the CA/Browser Forum by reference. A copy of the Baseline Requirements is available on the CA/Browser Forum's website at . -These Guidelines address the basic issue of validating Subject identity information in EV Certificates and some related matters. They do not address all of the related matters, such as certain technical and operational ones. This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet. However, the Working Group encourages the re-use of these guidelines as a basis for similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. +These Guidelines address the basic issue of validating Subject identity information in EV Certificates and some related matters. They do not address all of the related matters, such as certain technical and operational ones. This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet. However, the Working Group encourages the re-use of these guidelines as a basis for similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. These Guidelines do not address the verification of information, or the issuance, use, maintenance, or revocation of EV Certificates by enterprises that operate their own Public Key Infrastructure for internal purposes only, where its Root CA Certificate is not distributed by any Application Software Supplier. @@ -60,8 +60,8 @@ These Guidelines do not address the verification of information, or the issuance | 1.5.7 | 151 | Addition of Optional OIDs for Indicating Level of Validation | 28 Sept 2015 | 28 Sept 2015 | | 1.5.8 | 162 | Sunset of Exceptions | 15 Mar 2016 | 15 Mar 2016 | | 1.5.9 | 163 | Fix Errata in EV Guidelines 11.2.1 | 18 Mar 2016 | 18 Mar 2016 | -| 1.6.0 | 171 | Updating ETSI Standards | 1 July 2016 | 1 July 2016 | -| 1.6.1 | 180 | In EV 11.7.1, removed outdated cross-reference to BR 3.2.2.4(7) | 7 Jan. 2017 | 7 Jan. 2017 | +| 1.6.0 | 171 | Updating ETSI Standards | 1 July 2016 | 1 July 2016 | +| 1.6.1 | 180 | In EV 11.7.1, removed outdated cross-reference to BR 3.2.2.4(7) | 7 Jan. 2017 | 7 Jan. 2017 | | 1.6.2 | 103 | 825-day Certificate Lifetimes | 17 Mar. 2017 | 17 Mar. 2017 | | 1.6.3 | 198 | .Onion Revisions (declared invalid) | 7 May 2017 | 8 June 2017 | | 1.6.4 | 191 | Clarify Place of Business Information | 23 May 2017 | 23 June 2017 | @@ -215,7 +215,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided i. indicates which CA policy statement relates to that certificate, and ii. is either the CA/Browser Forum EV policy identifier or a policy identifier that, by pre-agreement with one or more Application Software Supplier, marks the certificate as being an EV Certificate. -**EV Policies**: Auditable EV Certificate practices, policies and procedures, such as a certification practice statement and certificate policy, that are developed, implemented, and enforced by the CA and its Root CA. +**EV Policies**: Auditable EV Certificate practices, policies and procedures, such as a certification practice statement and certificate policy, that are developed, implemented, and enforced by the CA and its Root CA. **EV Processes**: The keys, software, processes, and procedures by which the CA verifies Certificate Data under this Guideline, issues EV Certificates, maintains a Repository, and revokes EV Certificates. @@ -569,7 +569,7 @@ To verify any assumed name under which the Applicant conducts business: 1. The CA MAY verify the assumed name through use of a Qualified Government Information Source operated by, or on behalf of, an appropriate government agency in the jurisdiction of the Applicant's Place of Business, or by direct contact with such government agency in person or via mail, e-mail, Web address, or telephone; or 2. The CA MAY verify the assumed name through use of a Qualified Independent Information Source provided that the QIIS has verified the assumed name with the appropriate government agency. -3. The CA MAY rely on a Verified Professional Letter that indicates the assumed name under which the Applicant conducts business, the government agency with which the assumed name is registered, and that such filing continues to be valid. +3. The CA MAY rely on a Verified Professional Letter that indicates the assumed name under which the Applicant conducts business, the government agency with which the assumed name is registered, and that such filing continues to be valid. #### 3.2.2.4 Verification of Applicant's Physical Existence @@ -613,9 +613,9 @@ To verify a Verified Method of Communication with the Applicant, the CA MUST: A. Verify that the Verified Method of Communication belongs to the Applicant, or a Parent/Subsidiary or Affiliate of the Applicant, by matching it with one of the Applicant's Parent/Subsidiary or Affiliate's Places of Business in: - i. records provided by the applicable phone company; - ii. a QGIS, QTIS, or QIIS; or - iii. a Verified Professional Letter; and + i. records provided by the applicable phone company; + ii. a QGIS, QTIS, or QIIS; or + iii. a Verified Professional Letter; and B. Confirm the Verified Method of Communication by using it to obtain an affirmative response sufficient to enable a reasonable person to conclude that the Applicant, or a Parent/Subsidiary or Affiliate of Applicant, can be contacted reliably by using the Verified Method of Communication. @@ -790,7 +790,7 @@ Acceptable methods of verifying the Certificate Approver's approval of an EV Cer 1. **Verification Requirements**: Before relying on an accountant letter submitted to the CA, the CA MUST verify that such accountant letter meets the following requirements: - A. **Status of Author**: The CA MUST verify that the accountant letter is authored by an Accounting Practitioner retained or employed by the Applicant and licensed within the country of the Applicant's Jurisdiction of Incorporation, Jurisdiction of Registration, or country where the Applicant maintains an office or physical facility. Verification of license MUST be through the member organization or regulatory organization in the Accounting Practitioner's country or jurisdiction that is appropriate to contact when verifying an accountant's license to practice in that country or jurisdiction. Such country or jurisdiction must have an accounting standards body that maintains full membership status with the International Federation of Accountants. + A. **Status of Author**: The CA MUST verify that the accountant letter is authored by an Accounting Practitioner retained or employed by the Applicant and licensed within the country of the Applicant's Jurisdiction of Incorporation, Jurisdiction of Registration, or country where the Applicant maintains an office or physical facility. Verification of license MUST be through the member organization or regulatory organization in the Accounting Practitioner's country or jurisdiction that is appropriate to contact when verifying an accountant's license to practice in that country or jurisdiction. Such country or jurisdiction must have an accounting standards body that maintains full membership status with the International Federation of Accountants. B. **Basis of Opinion**: The CA MUST verify that the Accounting Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Accountant Letter are based on the Accounting Practitioner's stated familiarity with the relevant facts and the exercise of the Accounting Practitioner's professional judgment and expertise; C. **Authenticity**: The CA MUST confirm the authenticity of the Verified Accountant Letter. @@ -891,7 +891,7 @@ The High Risk Certificate requirements of Section 4.2.1 of the Baseline Requirem The CA MUST NOT issue any EV Certificate to the Applicant if either the Applicant, the Contract Signer, or Certificate Approver or if the Applicant's Jurisdiction of Incorporation or Registration or Place of Business is on any such list. -2. **Acceptable Methods of Verification** The CA MUST take reasonable steps to verify with the following lists and regulations: +2. **Acceptable Methods of Verification** The CA MUST take reasonable steps to verify with the following lists and regulations: 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: @@ -1422,15 +1422,15 @@ If a CA includes an extension in a certificate that has a Certificate field whic #### 7.1.2.1 Subject Alternative Name Extension -**Certificate Field**: `subjectAltName:dNSName` -**Required/Optional**: **Required** +**Certificate Field**: `subjectAltName:dNSName` +**Required/Optional**: **Required** **Contents**: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This extension MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. #### 7.1.2.2 CA/Browser Forum Organization Identifier Extension -**Extension Name**: `cabfOrganizationIdentifier` (OID: 2.23.140.3.1) -**Verbose OID**: `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-extensions(3) cabf-organization-identifier(1) }` -**Required/Optional**: **Optional (but see below)** +**Extension Name**: `cabfOrganizationIdentifier` (OID: 2.23.140.3.1) +**Verbose OID**: `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-extensions(3) cabf-organization-identifier(1) }` +**Required/Optional**: **Optional (but see below)** **Contents**: If the subject:organizationIdentifier is present, this field MUST be present. If present, this extension MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. @@ -1474,8 +1474,8 @@ Subject to the requirements of these Guidelines, the EV Certificate and certific ##### 7.1.4.2.1 Subject Organization Name Field -**Certificate Field**: `subject:organizationName` (OID 2.5.4.10) -**Required/Optional**: Required +**Certificate Field**: `subject:organizationName` (OID 2.5.4.10) +**Required/Optional**: Required **Contents**: This field MUST contain the Subject's full legal organization name as listed in the official records of the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration or as otherwise verified by the CA as provided herein. A CA MAY abbreviate the organization prefixes or suffixes in the organization name, e.g., if the official record shows "Company Name Incorporated" the CA MAY include "Company Name, Inc." When abbreviating a Subject's full legal name as allowed by this subsection, the CA MUST use abbreviations that are not misleading in the Jurisdiction of Incorporation or Registration. @@ -1486,38 +1486,38 @@ If the combination of names or the organization name by itself exceeds 64 charac ##### 7.1.4.2.2 Subject Common Name Field -**Certificate Field**: `subject:commonName` (OID: 2.5.4.3) -**Required/Optional**: Deprecated (Discouraged, but not prohibited) +**Certificate Field**: `subject:commonName` (OID: 2.5.4.3) +**Required/Optional**: Deprecated (Discouraged, but not prohibited) **Contents**: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This field MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. ##### 7.1.4.2.3 Subject Business Category Field -**Certificate Field**: `subject:businessCategory` (OID: 2.5.4.15) -**Required/Optional**: Required +**Certificate Field**: `subject:businessCategory` (OID: 2.5.4.15) +**Required/Optional**: Required **Contents**: This field MUST contain one of the following strings: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity" depending upon whether the Subject qualifies under the terms of [Section 4.1.1.1](#4111-private-organization-subjects), [Section 4.1.1.2](#4112-government-entity-subjects), [Section 4.1.1.3](#4113-business-entity-subjects) or [Section 4.1.1.4](#4114-non-commercial-entity-subjects), respectively. ##### 7.1.4.2.4 Subject Jurisdiction of Incorporation or Registration Field **Certificate Fields**: -Locality (if required): +Locality (if required): `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1) -State or province (if required): +State or province (if required): `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2) -Country: +Country: `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) -**Required/Optional**: Required +**Required/Optional**: Required **Contents**: These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. Country information MUST be specified using the applicable ISO country code. State or province or locality information (where applicable) for the Subject's Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction. Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, the values within these fields have been disclosed within the latest publicly-available disclosure, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), as acceptable values for the applicable Incorporating Agency or Registration Agency. ##### 7.1.4.2.5 Subject Registration Number Field -**Certificate Field**: `subject:serialNumber` (OID: 2.5.4.5) -**Required/Optional**: **Required** +**Certificate Field**: `subject:serialNumber` (OID: 2.5.4.5) +**Required/Optional**: **Required** **Contents**: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). For Government Entities that do not have a Registration Number or readily verifiable date of creation, the CA SHALL enter appropriate language to indicate that the Subject is a Government Entity. @@ -1527,13 +1527,13 @@ Effective as of 1 October 2020, if the CA has disclosed a set of acceptable form ##### 7.1.4.2.6 Subject Physical Address of Place of Business Field -**Certificate Fields**: - Number and street: `subject:streetAddress` (OID: 2.5.4.9) - City or town: `subject:localityName` (OID: 2.5.4.7) - State or province (where applicable): `subject:stateOrProvinceName` (OID: 2.5.4.8) - Country: `subject:countryName` (OID: 2.5.4.6) - Postal code: `subject:postalCode` (OID: 2.5.4.17) -**Required/Optional**: Required/Optional +**Certificate Fields**: + Number and street: `subject:streetAddress` (OID: 2.5.4.9) + City or town: `subject:localityName` (OID: 2.5.4.7) + State or province (where applicable): `subject:stateOrProvinceName` (OID: 2.5.4.8) + Country: `subject:countryName` (OID: 2.5.4.6) + Postal code: `subject:postalCode` (OID: 2.5.4.17) +**Required/Optional**: Required/Optional **Contents**: These fields MUST contain the verified physical address of the Subject’s Place of Business. The `countryName` field MUST be present and MUST contain the applicable two-letter ISO 3166-1 country code. If the country is not represented by an official ISO 3166-1 code, the ISO 3166-1 user-assigned code "XX" MUST be used. @@ -1544,13 +1544,13 @@ The `streetAddress` and `postalCode` fields are OPTIONAL. If present, they MUST ##### 7.1.4.2.7 Subject Organizational Unit Name Field -**Certificate Field**: `subject:organizationalUnitName` (OID: 2.5.4.11) +**Certificate Field**: `subject:organizationalUnitName` (OID: 2.5.4.11) **Required/Optional/Prohibited**: **Prohibited**. ##### 7.1.4.2.8 Subject Organization Identifier Field -**Certificate Field**: `subject:organizationIdentifier` (OID: 2.5.4.97) -**Required/Optional**: Optional +**Certificate Field**: `subject:organizationIdentifier` (OID: 2.5.4.97) +**Required/Optional**: Optional **Contents**: If present, this field MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. The organizationIdentifier MUST be encoded as a PrintableString or UTF8String. @@ -1873,7 +1873,7 @@ On this basis, we hereby offer the following opinion: 2. That Company conducts business under the assumed name or "DBA"_[assumed name of the Applicant]_ and has registered such name with the appropriate government agency in the jurisdiction of its place of business below. -3. That _[name of Client's Representative]_[^2] has authority to act on behalf of Company to: [_select as appropriate_] (a) provide the information about Company required for issuance of the EV Certificates as contained in the attached Application, (b) request one or more EV Certificates and to designate other persons to request EV Certificates, and (c) agree to the relevant contractual obligations contained in the Subscriber Agreement on behalf of Company. +3. That _[name of Client's Representative]_[^2] has authority to act on behalf of Company to: [_select as appropriate_] (a) provide the information about Company required for issuance of the EV Certificates as contained in the attached Application, (b) request one or more EV Certificates and to designate other persons to request EV Certificates, and (c) agree to the relevant contractual obligations contained in the Subscriber Agreement on behalf of Company. 4. That Company has a physical presence and its place of business is at the following location: @@ -1999,7 +1999,7 @@ NOTE: This appendix provides alternative interpretations of the EV Guidelines fo 3. Translated Name - In order to include a Latin character name in the EV certificate that is not a direct Romanization of the registered name (e.g. an English Name) the CA MUST verify that the Latin character name is: + In order to include a Latin character name in the EV certificate that is not a direct Romanization of the registered name (e.g. an English Name) the CA MUST verify that the Latin character name is: A. Included in the Articles of Incorporation (or equivalent document) filed as part of the organization registration; or B. Recognized by a QTIS in the Applicant's Jurisdiction of Incorporation as the Applicant's recognized name for tax filings; or @@ -2122,7 +2122,7 @@ The following Registration Schemes are currently recognized as valid under these - **NTR**: - The information carried in this field shall be the same as held in Subject Registration Number Field as specified in [Section 7.1.4.2.5](#71425-subject-registration-number-field) and the country code used in the Registration Scheme identifier shall match that of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). + The information carried in this field shall be the same as held in Subject Registration Number Field as specified in [Section 7.1.4.2.5](#71425-subject-registration-number-field) and the country code used in the Registration Scheme identifier shall match that of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). Where the Subject Jurisdiction of Incorporation or Registration Field in 9.2.4 includes more than the country code, the additional locality information shall be included as specified in [Section 7.1.4.2.8](#71428-subject-organization-identifier-field) and/or [Section 7.1.2.2](#7122-cabrowser-forum-organization-identifier-extension). From 7f7359eaa4edc29b6e69cc10e7acdc8ffd8d6ae1 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 21:47:36 +0100 Subject: [PATCH 080/121] 3.2.2.5.2 indent 3.2.2.1.1 abc whiteline 3.2.2.8.4 whiteline 3.2.2.11.5 whiteline 5.2.4 whiteline 7.1.4 whiteline --- docs/EVG.md | 46 +++++++++++++++++++++++++++++++--------------- 1 file changed, 31 insertions(+), 15 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 31f8060d..9f0e452a 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -413,9 +413,7 @@ Before issuing an EV Certificate, the CA MUST ensure that all Subject organizati 1. Verify Applicant's existence and identity, including; A. Verify the Applicant's legal existence and identity (as more fully set forth in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity)), - B. Verify the Applicant's physical existence (business presence at a physical address), and - C. Verify the Applicant's operational existence (business activity). 2. Verify the Applicant is a registered holder, or has control, of the Domain Name(s) to be included in the EV Certificate; @@ -425,9 +423,7 @@ Before issuing an EV Certificate, the CA MUST ensure that all Subject organizati 4. Verify the Applicant's authorization for the EV Certificate, including; A. Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester, - B. Verify that a Contract Signer signed the Subscriber Agreement or that a duly authorized Applicant Representative acknowledged and agreed to the Terms of Use; and - C. Verify that a Certificate Approver has signed or otherwise approved the EV Certificate Request. ##### 3.2.2.1.2 Acceptable Methods of Verification – Overview @@ -613,9 +609,9 @@ To verify a Verified Method of Communication with the Applicant, the CA MUST: A. Verify that the Verified Method of Communication belongs to the Applicant, or a Parent/Subsidiary or Affiliate of the Applicant, by matching it with one of the Applicant's Parent/Subsidiary or Affiliate's Places of Business in: - i. records provided by the applicable phone company; - ii. a QGIS, QTIS, or QIIS; or - iii. a Verified Professional Letter; and + i. records provided by the applicable phone company; + ii. a QGIS, QTIS, or QIIS; or + iii. a Verified Professional Letter; and B. Confirm the Verified Method of Communication by using it to obtain an affirmative response sufficient to enable a reasonable person to conclude that the Applicant, or a Parent/Subsidiary or Affiliate of Applicant, can be contacted reliably by using the Verified Method of Communication. @@ -716,7 +712,6 @@ Note: An example of an acceptable representation/warranty appears in [Appendix E Where the CA and Applicant contemplate the submission of multiple future EV Certificate Requests, then, after the CA: 1. Has verified the name and title of the Contract Signer and that he/she is an employee or agent of the Applicant; and - 2. Has verified the Signing Authority of such Contract Signer in accordance with one of the procedures in [Section 3.2.2.8.3](#32283-acceptable-methods-of-verification--authority). The CA and the Applicant MAY enter into a written agreement, signed by the Contract Signer on behalf of the Applicant, whereby, for a specified term, the Applicant expressly authorizes one or more Certificate Approver(s) designated in such agreement to exercise EV Authority with respect to each future EV Certificate Request submitted on behalf of the Applicant and properly authenticated as originating with, or otherwise being approved by, such Certificate Approver(s). @@ -858,7 +853,6 @@ An Independent Confirmation from the Applicant MAY be obtained via the following A Qualified Independent Information Source (QIIS) is a regularly-updated and publicly available database that is generally recognized as a dependable source for certain information. A database qualifies as a QIIS if the CA determines that: 1. Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and - 2. The database provider updates its data on at least an annual basis. The CA SHALL use a documented process to check the accuracy of the database and ensure its data is acceptable, including reviewing the database provider's terms of use. The CA SHALL NOT use any data in a QIIS that the CA knows is @@ -1229,6 +1223,7 @@ As specified in Section 5 of the Baseline Requirements. In addition, systems use ### 5.2.4 Roles requiring separation of duties 1. The CA MUST enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the issuance of an EV Certificate. The Final Cross-Correlation and Due Diligence steps, as outlined in [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence), MAY be performed by one of the persons. For example, one Validation Specialist MAY review and verify all the Applicant information and a second Validation Specialist MAY approve issuance of the EV Certificate. + 2. Such controls MUST be auditable. ## 5.3 Personnel controls @@ -1423,14 +1418,19 @@ If a CA includes an extension in a certificate that has a Certificate field whic #### 7.1.2.1 Subject Alternative Name Extension **Certificate Field**: `subjectAltName:dNSName` + **Required/Optional**: **Required** + **Contents**: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This extension MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. #### 7.1.2.2 CA/Browser Forum Organization Identifier Extension **Extension Name**: `cabfOrganizationIdentifier` (OID: 2.23.140.3.1) + **Verbose OID**: `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-extensions(3) cabf-organization-identifier(1) }` + **Required/Optional**: **Optional (but see below)** + **Contents**: If the subject:organizationIdentifier is present, this field MUST be present. If present, this extension MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. @@ -1475,7 +1475,9 @@ Subject to the requirements of these Guidelines, the EV Certificate and certific ##### 7.1.4.2.1 Subject Organization Name Field **Certificate Field**: `subject:organizationName` (OID 2.5.4.10) + **Required/Optional**: Required + **Contents**: This field MUST contain the Subject's full legal organization name as listed in the official records of the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration or as otherwise verified by the CA as provided herein. A CA MAY abbreviate the organization prefixes or suffixes in the organization name, e.g., if the official record shows "Company Name Incorporated" the CA MAY include "Company Name, Inc." When abbreviating a Subject's full legal name as allowed by this subsection, the CA MUST use abbreviations that are not misleading in the Jurisdiction of Incorporation or Registration. @@ -1487,29 +1489,31 @@ If the combination of names or the organization name by itself exceeds 64 charac ##### 7.1.4.2.2 Subject Common Name Field **Certificate Field**: `subject:commonName` (OID: 2.5.4.3) + **Required/Optional**: Deprecated (Discouraged, but not prohibited) + **Contents**: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This field MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. ##### 7.1.4.2.3 Subject Business Category Field **Certificate Field**: `subject:businessCategory` (OID: 2.5.4.15) + **Required/Optional**: Required + **Contents**: This field MUST contain one of the following strings: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity" depending upon whether the Subject qualifies under the terms of [Section 4.1.1.1](#4111-private-organization-subjects), [Section 4.1.1.2](#4112-government-entity-subjects), [Section 4.1.1.3](#4113-business-entity-subjects) or [Section 4.1.1.4](#4114-non-commercial-entity-subjects), respectively. ##### 7.1.4.2.4 Subject Jurisdiction of Incorporation or Registration Field **Certificate Fields**: -Locality (if required): - `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1) +Locality (if required): `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1) -State or province (if required): - `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2) +State or province (if required): `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2) -Country: - `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) +Country: `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) **Required/Optional**: Required + **Contents**: These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. Country information MUST be specified using the applicable ISO country code. State or province or locality information (where applicable) for the Subject's Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction. Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, the values within these fields have been disclosed within the latest publicly-available disclosure, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), as acceptable values for the applicable Incorporating Agency or Registration Agency. @@ -1517,7 +1521,9 @@ Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, t ##### 7.1.4.2.5 Subject Registration Number Field **Certificate Field**: `subject:serialNumber` (OID: 2.5.4.5) + **Required/Optional**: **Required** + **Contents**: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). For Government Entities that do not have a Registration Number or readily verifiable date of creation, the CA SHALL enter appropriate language to indicate that the Subject is a Government Entity. @@ -1528,12 +1534,19 @@ Effective as of 1 October 2020, if the CA has disclosed a set of acceptable form ##### 7.1.4.2.6 Subject Physical Address of Place of Business Field **Certificate Fields**: + Number and street: `subject:streetAddress` (OID: 2.5.4.9) + City or town: `subject:localityName` (OID: 2.5.4.7) + State or province (where applicable): `subject:stateOrProvinceName` (OID: 2.5.4.8) + Country: `subject:countryName` (OID: 2.5.4.6) + Postal code: `subject:postalCode` (OID: 2.5.4.17) + **Required/Optional**: Required/Optional + **Contents**: These fields MUST contain the verified physical address of the Subject’s Place of Business. The `countryName` field MUST be present and MUST contain the applicable two-letter ISO 3166-1 country code. If the country is not represented by an official ISO 3166-1 code, the ISO 3166-1 user-assigned code "XX" MUST be used. @@ -1545,12 +1558,15 @@ The `streetAddress` and `postalCode` fields are OPTIONAL. If present, they MUST ##### 7.1.4.2.7 Subject Organizational Unit Name Field **Certificate Field**: `subject:organizationalUnitName` (OID: 2.5.4.11) + **Required/Optional/Prohibited**: **Prohibited**. ##### 7.1.4.2.8 Subject Organization Identifier Field **Certificate Field**: `subject:organizationIdentifier` (OID: 2.5.4.97) + **Required/Optional**: Optional + **Contents**: If present, this field MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. The organizationIdentifier MUST be encoded as a PrintableString or UTF8String. From 7fb4e37c5a0a33c6fd81303d143ddb1e6925c48c Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 21:51:08 +0100 Subject: [PATCH 081/121] #432 revert --- docs/EVG.md | 114 ++++++++++++++++++++++------------------------------ 1 file changed, 49 insertions(+), 65 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 9f0e452a..77adcec1 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -30,7 +30,7 @@ The CA/Browser Forum is a voluntary open organization of certification authoriti These Guidelines for the issuance and management of Extended Validation Certificates describe certain of the minimum requirements that a Certification Authority must meet in order to issue Extended Validation Certificates. Subject Organization information from Valid EV Certificates may be displayed 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 they are accessing. These Guidelines incorporate the Baseline Requirements established by the CA/Browser Forum by reference. A copy of the Baseline Requirements is available on the CA/Browser Forum's website at . -These Guidelines address the basic issue of validating Subject identity information in EV Certificates and some related matters. They do not address all of the related matters, such as certain technical and operational ones. This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet. However, the Working Group encourages the re-use of these guidelines as a basis for similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. +These Guidelines address the basic issue of validating Subject identity information in EV Certificates and some related matters. They do not address all of the related matters, such as certain technical and operational ones. This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet. However, the Working Group encourages the re-use of these guidelines as a basis for similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. These Guidelines do not address the verification of information, or the issuance, use, maintenance, or revocation of EV Certificates by enterprises that operate their own Public Key Infrastructure for internal purposes only, where its Root CA Certificate is not distributed by any Application Software Supplier. @@ -60,8 +60,8 @@ These Guidelines do not address the verification of information, or the issuance | 1.5.7 | 151 | Addition of Optional OIDs for Indicating Level of Validation | 28 Sept 2015 | 28 Sept 2015 | | 1.5.8 | 162 | Sunset of Exceptions | 15 Mar 2016 | 15 Mar 2016 | | 1.5.9 | 163 | Fix Errata in EV Guidelines 11.2.1 | 18 Mar 2016 | 18 Mar 2016 | -| 1.6.0 | 171 | Updating ETSI Standards | 1 July 2016 | 1 July 2016 | -| 1.6.1 | 180 | In EV 11.7.1, removed outdated cross-reference to BR 3.2.2.4(7) | 7 Jan. 2017 | 7 Jan. 2017 | +| 1.6.0 | 171 | Updating ETSI Standards | 1 July 2016 | 1 July 2016 | +| 1.6.1 | 180 | In EV 11.7.1, removed outdated cross-reference to BR 3.2.2.4(7) | 7 Jan. 2017 | 7 Jan. 2017 | | 1.6.2 | 103 | 825-day Certificate Lifetimes | 17 Mar. 2017 | 17 Mar. 2017 | | 1.6.3 | 198 | .Onion Revisions (declared invalid) | 7 May 2017 | 8 June 2017 | | 1.6.4 | 191 | Clarify Place of Business Information | 23 May 2017 | 23 June 2017 | @@ -215,7 +215,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided i. indicates which CA policy statement relates to that certificate, and ii. is either the CA/Browser Forum EV policy identifier or a policy identifier that, by pre-agreement with one or more Application Software Supplier, marks the certificate as being an EV Certificate. -**EV Policies**: Auditable EV Certificate practices, policies and procedures, such as a certification practice statement and certificate policy, that are developed, implemented, and enforced by the CA and its Root CA. +**EV Policies**: Auditable EV Certificate practices, policies and procedures, such as a certification practice statement and certificate policy, that are developed, implemented, and enforced by the CA and its Root CA. **EV Processes**: The keys, software, processes, and procedures by which the CA verifies Certificate Data under this Guideline, issues EV Certificates, maintains a Repository, and revokes EV Certificates. @@ -413,7 +413,9 @@ Before issuing an EV Certificate, the CA MUST ensure that all Subject organizati 1. Verify Applicant's existence and identity, including; A. Verify the Applicant's legal existence and identity (as more fully set forth in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity)), + B. Verify the Applicant's physical existence (business presence at a physical address), and + C. Verify the Applicant's operational existence (business activity). 2. Verify the Applicant is a registered holder, or has control, of the Domain Name(s) to be included in the EV Certificate; @@ -423,7 +425,9 @@ Before issuing an EV Certificate, the CA MUST ensure that all Subject organizati 4. Verify the Applicant's authorization for the EV Certificate, including; A. Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester, + B. Verify that a Contract Signer signed the Subscriber Agreement or that a duly authorized Applicant Representative acknowledged and agreed to the Terms of Use; and + C. Verify that a Certificate Approver has signed or otherwise approved the EV Certificate Request. ##### 3.2.2.1.2 Acceptable Methods of Verification – Overview @@ -565,7 +569,7 @@ To verify any assumed name under which the Applicant conducts business: 1. The CA MAY verify the assumed name through use of a Qualified Government Information Source operated by, or on behalf of, an appropriate government agency in the jurisdiction of the Applicant's Place of Business, or by direct contact with such government agency in person or via mail, e-mail, Web address, or telephone; or 2. The CA MAY verify the assumed name through use of a Qualified Independent Information Source provided that the QIIS has verified the assumed name with the appropriate government agency. -3. The CA MAY rely on a Verified Professional Letter that indicates the assumed name under which the Applicant conducts business, the government agency with which the assumed name is registered, and that such filing continues to be valid. +3. The CA MAY rely on a Verified Professional Letter that indicates the assumed name under which the Applicant conducts business, the government agency with which the assumed name is registered, and that such filing continues to be valid. #### 3.2.2.4 Verification of Applicant's Physical Existence @@ -609,9 +613,9 @@ To verify a Verified Method of Communication with the Applicant, the CA MUST: A. Verify that the Verified Method of Communication belongs to the Applicant, or a Parent/Subsidiary or Affiliate of the Applicant, by matching it with one of the Applicant's Parent/Subsidiary or Affiliate's Places of Business in: - i. records provided by the applicable phone company; - ii. a QGIS, QTIS, or QIIS; or - iii. a Verified Professional Letter; and + i. records provided by the applicable phone company; + ii. a QGIS, QTIS, or QIIS; or + iii. a Verified Professional Letter; and B. Confirm the Verified Method of Communication by using it to obtain an affirmative response sufficient to enable a reasonable person to conclude that the Applicant, or a Parent/Subsidiary or Affiliate of Applicant, can be contacted reliably by using the Verified Method of Communication. @@ -712,6 +716,7 @@ Note: An example of an acceptable representation/warranty appears in [Appendix E Where the CA and Applicant contemplate the submission of multiple future EV Certificate Requests, then, after the CA: 1. Has verified the name and title of the Contract Signer and that he/she is an employee or agent of the Applicant; and + 2. Has verified the Signing Authority of such Contract Signer in accordance with one of the procedures in [Section 3.2.2.8.3](#32283-acceptable-methods-of-verification--authority). The CA and the Applicant MAY enter into a written agreement, signed by the Contract Signer on behalf of the Applicant, whereby, for a specified term, the Applicant expressly authorizes one or more Certificate Approver(s) designated in such agreement to exercise EV Authority with respect to each future EV Certificate Request submitted on behalf of the Applicant and properly authenticated as originating with, or otherwise being approved by, such Certificate Approver(s). @@ -785,7 +790,7 @@ Acceptable methods of verifying the Certificate Approver's approval of an EV Cer 1. **Verification Requirements**: Before relying on an accountant letter submitted to the CA, the CA MUST verify that such accountant letter meets the following requirements: - A. **Status of Author**: The CA MUST verify that the accountant letter is authored by an Accounting Practitioner retained or employed by the Applicant and licensed within the country of the Applicant's Jurisdiction of Incorporation, Jurisdiction of Registration, or country where the Applicant maintains an office or physical facility. Verification of license MUST be through the member organization or regulatory organization in the Accounting Practitioner's country or jurisdiction that is appropriate to contact when verifying an accountant's license to practice in that country or jurisdiction. Such country or jurisdiction must have an accounting standards body that maintains full membership status with the International Federation of Accountants. + A. **Status of Author**: The CA MUST verify that the accountant letter is authored by an Accounting Practitioner retained or employed by the Applicant and licensed within the country of the Applicant's Jurisdiction of Incorporation, Jurisdiction of Registration, or country where the Applicant maintains an office or physical facility. Verification of license MUST be through the member organization or regulatory organization in the Accounting Practitioner's country or jurisdiction that is appropriate to contact when verifying an accountant's license to practice in that country or jurisdiction. Such country or jurisdiction must have an accounting standards body that maintains full membership status with the International Federation of Accountants. B. **Basis of Opinion**: The CA MUST verify that the Accounting Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Accountant Letter are based on the Accounting Practitioner's stated familiarity with the relevant facts and the exercise of the Accounting Practitioner's professional judgment and expertise; C. **Authenticity**: The CA MUST confirm the authenticity of the Verified Accountant Letter. @@ -853,6 +858,7 @@ An Independent Confirmation from the Applicant MAY be obtained via the following A Qualified Independent Information Source (QIIS) is a regularly-updated and publicly available database that is generally recognized as a dependable source for certain information. A database qualifies as a QIIS if the CA determines that: 1. Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and + 2. The database provider updates its data on at least an annual basis. The CA SHALL use a documented process to check the accuracy of the database and ensure its data is acceptable, including reviewing the database provider's terms of use. The CA SHALL NOT use any data in a QIIS that the CA knows is @@ -885,7 +891,7 @@ The High Risk Certificate requirements of Section 4.2.1 of the Baseline Requirem The CA MUST NOT issue any EV Certificate to the Applicant if either the Applicant, the Contract Signer, or Certificate Approver or if the Applicant's Jurisdiction of Incorporation or Registration or Place of Business is on any such list. -2. **Acceptable Methods of Verification** The CA MUST take reasonable steps to verify with the following lists and regulations: +2. **Acceptable Methods of Verification** The CA MUST take reasonable steps to verify with the following lists and regulations: 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: @@ -1223,7 +1229,6 @@ As specified in Section 5 of the Baseline Requirements. In addition, systems use ### 5.2.4 Roles requiring separation of duties 1. The CA MUST enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the issuance of an EV Certificate. The Final Cross-Correlation and Due Diligence steps, as outlined in [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence), MAY be performed by one of the persons. For example, one Validation Specialist MAY review and verify all the Applicant information and a second Validation Specialist MAY approve issuance of the EV Certificate. - 2. Such controls MUST be auditable. ## 5.3 Personnel controls @@ -1417,20 +1422,15 @@ If a CA includes an extension in a certificate that has a Certificate field whic #### 7.1.2.1 Subject Alternative Name Extension -**Certificate Field**: `subjectAltName:dNSName` - -**Required/Optional**: **Required** - +**Certificate Field**: `subjectAltName:dNSName` +**Required/Optional**: **Required** **Contents**: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This extension MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. #### 7.1.2.2 CA/Browser Forum Organization Identifier Extension -**Extension Name**: `cabfOrganizationIdentifier` (OID: 2.23.140.3.1) - -**Verbose OID**: `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-extensions(3) cabf-organization-identifier(1) }` - -**Required/Optional**: **Optional (but see below)** - +**Extension Name**: `cabfOrganizationIdentifier` (OID: 2.23.140.3.1) +**Verbose OID**: `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-extensions(3) cabf-organization-identifier(1) }` +**Required/Optional**: **Optional (but see below)** **Contents**: If the subject:organizationIdentifier is present, this field MUST be present. If present, this extension MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. @@ -1474,10 +1474,8 @@ Subject to the requirements of these Guidelines, the EV Certificate and certific ##### 7.1.4.2.1 Subject Organization Name Field -**Certificate Field**: `subject:organizationName` (OID 2.5.4.10) - -**Required/Optional**: Required - +**Certificate Field**: `subject:organizationName` (OID 2.5.4.10) +**Required/Optional**: Required **Contents**: This field MUST contain the Subject's full legal organization name as listed in the official records of the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration or as otherwise verified by the CA as provided herein. A CA MAY abbreviate the organization prefixes or suffixes in the organization name, e.g., if the official record shows "Company Name Incorporated" the CA MAY include "Company Name, Inc." When abbreviating a Subject's full legal name as allowed by this subsection, the CA MUST use abbreviations that are not misleading in the Jurisdiction of Incorporation or Registration. @@ -1488,42 +1486,38 @@ If the combination of names or the organization name by itself exceeds 64 charac ##### 7.1.4.2.2 Subject Common Name Field -**Certificate Field**: `subject:commonName` (OID: 2.5.4.3) - -**Required/Optional**: Deprecated (Discouraged, but not prohibited) - +**Certificate Field**: `subject:commonName` (OID: 2.5.4.3) +**Required/Optional**: Deprecated (Discouraged, but not prohibited) **Contents**: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This field MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. ##### 7.1.4.2.3 Subject Business Category Field -**Certificate Field**: `subject:businessCategory` (OID: 2.5.4.15) - -**Required/Optional**: Required - +**Certificate Field**: `subject:businessCategory` (OID: 2.5.4.15) +**Required/Optional**: Required **Contents**: This field MUST contain one of the following strings: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity" depending upon whether the Subject qualifies under the terms of [Section 4.1.1.1](#4111-private-organization-subjects), [Section 4.1.1.2](#4112-government-entity-subjects), [Section 4.1.1.3](#4113-business-entity-subjects) or [Section 4.1.1.4](#4114-non-commercial-entity-subjects), respectively. ##### 7.1.4.2.4 Subject Jurisdiction of Incorporation or Registration Field **Certificate Fields**: -Locality (if required): `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1) +Locality (if required): + `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1) -State or province (if required): `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2) +State or province (if required): + `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2) -Country: `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) - -**Required/Optional**: Required +Country: + `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) +**Required/Optional**: Required **Contents**: These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. Country information MUST be specified using the applicable ISO country code. State or province or locality information (where applicable) for the Subject's Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction. Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, the values within these fields have been disclosed within the latest publicly-available disclosure, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), as acceptable values for the applicable Incorporating Agency or Registration Agency. ##### 7.1.4.2.5 Subject Registration Number Field -**Certificate Field**: `subject:serialNumber` (OID: 2.5.4.5) - -**Required/Optional**: **Required** - +**Certificate Field**: `subject:serialNumber` (OID: 2.5.4.5) +**Required/Optional**: **Required** **Contents**: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). For Government Entities that do not have a Registration Number or readily verifiable date of creation, the CA SHALL enter appropriate language to indicate that the Subject is a Government Entity. @@ -1533,20 +1527,13 @@ Effective as of 1 October 2020, if the CA has disclosed a set of acceptable form ##### 7.1.4.2.6 Subject Physical Address of Place of Business Field -**Certificate Fields**: - - Number and street: `subject:streetAddress` (OID: 2.5.4.9) - - City or town: `subject:localityName` (OID: 2.5.4.7) - - State or province (where applicable): `subject:stateOrProvinceName` (OID: 2.5.4.8) - - Country: `subject:countryName` (OID: 2.5.4.6) - - Postal code: `subject:postalCode` (OID: 2.5.4.17) - -**Required/Optional**: Required/Optional - +**Certificate Fields**: + Number and street: `subject:streetAddress` (OID: 2.5.4.9) + City or town: `subject:localityName` (OID: 2.5.4.7) + State or province (where applicable): `subject:stateOrProvinceName` (OID: 2.5.4.8) + Country: `subject:countryName` (OID: 2.5.4.6) + Postal code: `subject:postalCode` (OID: 2.5.4.17) +**Required/Optional**: Required/Optional **Contents**: These fields MUST contain the verified physical address of the Subject’s Place of Business. The `countryName` field MUST be present and MUST contain the applicable two-letter ISO 3166-1 country code. If the country is not represented by an official ISO 3166-1 code, the ISO 3166-1 user-assigned code "XX" MUST be used. @@ -1557,16 +1544,13 @@ The `streetAddress` and `postalCode` fields are OPTIONAL. If present, they MUST ##### 7.1.4.2.7 Subject Organizational Unit Name Field -**Certificate Field**: `subject:organizationalUnitName` (OID: 2.5.4.11) - +**Certificate Field**: `subject:organizationalUnitName` (OID: 2.5.4.11) **Required/Optional/Prohibited**: **Prohibited**. ##### 7.1.4.2.8 Subject Organization Identifier Field -**Certificate Field**: `subject:organizationIdentifier` (OID: 2.5.4.97) - -**Required/Optional**: Optional - +**Certificate Field**: `subject:organizationIdentifier` (OID: 2.5.4.97) +**Required/Optional**: Optional **Contents**: If present, this field MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. The organizationIdentifier MUST be encoded as a PrintableString or UTF8String. @@ -1889,7 +1873,7 @@ On this basis, we hereby offer the following opinion: 2. That Company conducts business under the assumed name or "DBA"_[assumed name of the Applicant]_ and has registered such name with the appropriate government agency in the jurisdiction of its place of business below. -3. That _[name of Client's Representative]_[^2] has authority to act on behalf of Company to: [_select as appropriate_] (a) provide the information about Company required for issuance of the EV Certificates as contained in the attached Application, (b) request one or more EV Certificates and to designate other persons to request EV Certificates, and (c) agree to the relevant contractual obligations contained in the Subscriber Agreement on behalf of Company. +3. That _[name of Client's Representative]_[^2] has authority to act on behalf of Company to: [_select as appropriate_] (a) provide the information about Company required for issuance of the EV Certificates as contained in the attached Application, (b) request one or more EV Certificates and to designate other persons to request EV Certificates, and (c) agree to the relevant contractual obligations contained in the Subscriber Agreement on behalf of Company. 4. That Company has a physical presence and its place of business is at the following location: @@ -2015,7 +1999,7 @@ NOTE: This appendix provides alternative interpretations of the EV Guidelines fo 3. Translated Name - In order to include a Latin character name in the EV certificate that is not a direct Romanization of the registered name (e.g. an English Name) the CA MUST verify that the Latin character name is: + In order to include a Latin character name in the EV certificate that is not a direct Romanization of the registered name (e.g. an English Name) the CA MUST verify that the Latin character name is: A. Included in the Articles of Incorporation (or equivalent document) filed as part of the organization registration; or B. Recognized by a QTIS in the Applicant's Jurisdiction of Incorporation as the Applicant's recognized name for tax filings; or @@ -2138,7 +2122,7 @@ The following Registration Schemes are currently recognized as valid under these - **NTR**: - The information carried in this field shall be the same as held in Subject Registration Number Field as specified in [Section 7.1.4.2.5](#71425-subject-registration-number-field) and the country code used in the Registration Scheme identifier shall match that of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). + The information carried in this field shall be the same as held in Subject Registration Number Field as specified in [Section 7.1.4.2.5](#71425-subject-registration-number-field) and the country code used in the Registration Scheme identifier shall match that of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). Where the Subject Jurisdiction of Incorporation or Registration Field in 9.2.4 includes more than the country code, the additional locality information shall be included as specified in [Section 7.1.4.2.8](#71428-subject-organization-identifier-field) and/or [Section 7.1.2.2](#7122-cabrowser-forum-organization-identifier-extension). From e912a6a1f00c85740495e0c7c459f379ea3847fc Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 21:54:54 +0100 Subject: [PATCH 082/121] #432 3.2.2.5.2 indent 3.2.2.1.1 abc whiteline 3.2.2.8.4 whiteline 3.2.2.11.5 whiteline 5.2.4 whiteline 7.1.4 whiteline --- docs/EVG.md | 114 ++++++++++++++++++++++++++++++---------------------- 1 file changed, 65 insertions(+), 49 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 77adcec1..406b10be 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -30,7 +30,7 @@ The CA/Browser Forum is a voluntary open organization of certification authoriti These Guidelines for the issuance and management of Extended Validation Certificates describe certain of the minimum requirements that a Certification Authority must meet in order to issue Extended Validation Certificates. Subject Organization information from Valid EV Certificates may be displayed 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 they are accessing. These Guidelines incorporate the Baseline Requirements established by the CA/Browser Forum by reference. A copy of the Baseline Requirements is available on the CA/Browser Forum's website at . -These Guidelines address the basic issue of validating Subject identity information in EV Certificates and some related matters. They do not address all of the related matters, such as certain technical and operational ones. This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet. However, the Working Group encourages the re-use of these guidelines as a basis for similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. +These Guidelines address the basic issue of validating Subject identity information in EV Certificates and some related matters. They do not address all of the related matters, such as certain technical and operational ones. This version of the Guidelines addresses only requirements for EV Certificates intended to be used for SSL/TLS authentication on the Internet. However, the Working Group encourages the re-use of these guidelines as a basis for similar requirements for S/MIME, time-stamping, VoIP, IM, Web services, etc. These Guidelines do not address the verification of information, or the issuance, use, maintenance, or revocation of EV Certificates by enterprises that operate their own Public Key Infrastructure for internal purposes only, where its Root CA Certificate is not distributed by any Application Software Supplier. @@ -60,8 +60,8 @@ These Guidelines do not address the verification of information, or the issuance | 1.5.7 | 151 | Addition of Optional OIDs for Indicating Level of Validation | 28 Sept 2015 | 28 Sept 2015 | | 1.5.8 | 162 | Sunset of Exceptions | 15 Mar 2016 | 15 Mar 2016 | | 1.5.9 | 163 | Fix Errata in EV Guidelines 11.2.1 | 18 Mar 2016 | 18 Mar 2016 | -| 1.6.0 | 171 | Updating ETSI Standards | 1 July 2016 | 1 July 2016 | -| 1.6.1 | 180 | In EV 11.7.1, removed outdated cross-reference to BR 3.2.2.4(7) | 7 Jan. 2017 | 7 Jan. 2017 | +| 1.6.0 | 171 | Updating ETSI Standards | 1 July 2016 | 1 July 2016 | +| 1.6.1 | 180 | In EV 11.7.1, removed outdated cross-reference to BR 3.2.2.4(7) | 7 Jan. 2017 | 7 Jan. 2017 | | 1.6.2 | 103 | 825-day Certificate Lifetimes | 17 Mar. 2017 | 17 Mar. 2017 | | 1.6.3 | 198 | .Onion Revisions (declared invalid) | 7 May 2017 | 8 June 2017 | | 1.6.4 | 191 | Clarify Place of Business Information | 23 May 2017 | 23 June 2017 | @@ -215,7 +215,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided i. indicates which CA policy statement relates to that certificate, and ii. is either the CA/Browser Forum EV policy identifier or a policy identifier that, by pre-agreement with one or more Application Software Supplier, marks the certificate as being an EV Certificate. -**EV Policies**: Auditable EV Certificate practices, policies and procedures, such as a certification practice statement and certificate policy, that are developed, implemented, and enforced by the CA and its Root CA. +**EV Policies**: Auditable EV Certificate practices, policies and procedures, such as a certification practice statement and certificate policy, that are developed, implemented, and enforced by the CA and its Root CA. **EV Processes**: The keys, software, processes, and procedures by which the CA verifies Certificate Data under this Guideline, issues EV Certificates, maintains a Repository, and revokes EV Certificates. @@ -413,9 +413,7 @@ Before issuing an EV Certificate, the CA MUST ensure that all Subject organizati 1. Verify Applicant's existence and identity, including; A. Verify the Applicant's legal existence and identity (as more fully set forth in [Section 3.2.2.2](#3222-verification-of-applicants-legal-existence-and-identity)), - B. Verify the Applicant's physical existence (business presence at a physical address), and - C. Verify the Applicant's operational existence (business activity). 2. Verify the Applicant is a registered holder, or has control, of the Domain Name(s) to be included in the EV Certificate; @@ -425,9 +423,7 @@ Before issuing an EV Certificate, the CA MUST ensure that all Subject organizati 4. Verify the Applicant's authorization for the EV Certificate, including; A. Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester, - B. Verify that a Contract Signer signed the Subscriber Agreement or that a duly authorized Applicant Representative acknowledged and agreed to the Terms of Use; and - C. Verify that a Certificate Approver has signed or otherwise approved the EV Certificate Request. ##### 3.2.2.1.2 Acceptable Methods of Verification – Overview @@ -569,7 +565,7 @@ To verify any assumed name under which the Applicant conducts business: 1. The CA MAY verify the assumed name through use of a Qualified Government Information Source operated by, or on behalf of, an appropriate government agency in the jurisdiction of the Applicant's Place of Business, or by direct contact with such government agency in person or via mail, e-mail, Web address, or telephone; or 2. The CA MAY verify the assumed name through use of a Qualified Independent Information Source provided that the QIIS has verified the assumed name with the appropriate government agency. -3. The CA MAY rely on a Verified Professional Letter that indicates the assumed name under which the Applicant conducts business, the government agency with which the assumed name is registered, and that such filing continues to be valid. +3. The CA MAY rely on a Verified Professional Letter that indicates the assumed name under which the Applicant conducts business, the government agency with which the assumed name is registered, and that such filing continues to be valid. #### 3.2.2.4 Verification of Applicant's Physical Existence @@ -613,9 +609,9 @@ To verify a Verified Method of Communication with the Applicant, the CA MUST: A. Verify that the Verified Method of Communication belongs to the Applicant, or a Parent/Subsidiary or Affiliate of the Applicant, by matching it with one of the Applicant's Parent/Subsidiary or Affiliate's Places of Business in: - i. records provided by the applicable phone company; - ii. a QGIS, QTIS, or QIIS; or - iii. a Verified Professional Letter; and + i. records provided by the applicable phone company; + ii. a QGIS, QTIS, or QIIS; or + iii. a Verified Professional Letter; and B. Confirm the Verified Method of Communication by using it to obtain an affirmative response sufficient to enable a reasonable person to conclude that the Applicant, or a Parent/Subsidiary or Affiliate of Applicant, can be contacted reliably by using the Verified Method of Communication. @@ -716,7 +712,6 @@ Note: An example of an acceptable representation/warranty appears in [Appendix E Where the CA and Applicant contemplate the submission of multiple future EV Certificate Requests, then, after the CA: 1. Has verified the name and title of the Contract Signer and that he/she is an employee or agent of the Applicant; and - 2. Has verified the Signing Authority of such Contract Signer in accordance with one of the procedures in [Section 3.2.2.8.3](#32283-acceptable-methods-of-verification--authority). The CA and the Applicant MAY enter into a written agreement, signed by the Contract Signer on behalf of the Applicant, whereby, for a specified term, the Applicant expressly authorizes one or more Certificate Approver(s) designated in such agreement to exercise EV Authority with respect to each future EV Certificate Request submitted on behalf of the Applicant and properly authenticated as originating with, or otherwise being approved by, such Certificate Approver(s). @@ -790,7 +785,7 @@ Acceptable methods of verifying the Certificate Approver's approval of an EV Cer 1. **Verification Requirements**: Before relying on an accountant letter submitted to the CA, the CA MUST verify that such accountant letter meets the following requirements: - A. **Status of Author**: The CA MUST verify that the accountant letter is authored by an Accounting Practitioner retained or employed by the Applicant and licensed within the country of the Applicant's Jurisdiction of Incorporation, Jurisdiction of Registration, or country where the Applicant maintains an office or physical facility. Verification of license MUST be through the member organization or regulatory organization in the Accounting Practitioner's country or jurisdiction that is appropriate to contact when verifying an accountant's license to practice in that country or jurisdiction. Such country or jurisdiction must have an accounting standards body that maintains full membership status with the International Federation of Accountants. + A. **Status of Author**: The CA MUST verify that the accountant letter is authored by an Accounting Practitioner retained or employed by the Applicant and licensed within the country of the Applicant's Jurisdiction of Incorporation, Jurisdiction of Registration, or country where the Applicant maintains an office or physical facility. Verification of license MUST be through the member organization or regulatory organization in the Accounting Practitioner's country or jurisdiction that is appropriate to contact when verifying an accountant's license to practice in that country or jurisdiction. Such country or jurisdiction must have an accounting standards body that maintains full membership status with the International Federation of Accountants. B. **Basis of Opinion**: The CA MUST verify that the Accounting Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Accountant Letter are based on the Accounting Practitioner's stated familiarity with the relevant facts and the exercise of the Accounting Practitioner's professional judgment and expertise; C. **Authenticity**: The CA MUST confirm the authenticity of the Verified Accountant Letter. @@ -858,7 +853,6 @@ An Independent Confirmation from the Applicant MAY be obtained via the following A Qualified Independent Information Source (QIIS) is a regularly-updated and publicly available database that is generally recognized as a dependable source for certain information. A database qualifies as a QIIS if the CA determines that: 1. Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and - 2. The database provider updates its data on at least an annual basis. The CA SHALL use a documented process to check the accuracy of the database and ensure its data is acceptable, including reviewing the database provider's terms of use. The CA SHALL NOT use any data in a QIIS that the CA knows is @@ -891,7 +885,7 @@ The High Risk Certificate requirements of Section 4.2.1 of the Baseline Requirem The CA MUST NOT issue any EV Certificate to the Applicant if either the Applicant, the Contract Signer, or Certificate Approver or if the Applicant's Jurisdiction of Incorporation or Registration or Place of Business is on any such list. -2. **Acceptable Methods of Verification** The CA MUST take reasonable steps to verify with the following lists and regulations: +2. **Acceptable Methods of Verification** The CA MUST take reasonable steps to verify with the following lists and regulations: 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: @@ -1229,6 +1223,7 @@ As specified in Section 5 of the Baseline Requirements. In addition, systems use ### 5.2.4 Roles requiring separation of duties 1. The CA MUST enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the issuance of an EV Certificate. The Final Cross-Correlation and Due Diligence steps, as outlined in [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence), MAY be performed by one of the persons. For example, one Validation Specialist MAY review and verify all the Applicant information and a second Validation Specialist MAY approve issuance of the EV Certificate. + 2. Such controls MUST be auditable. ## 5.3 Personnel controls @@ -1422,15 +1417,20 @@ If a CA includes an extension in a certificate that has a Certificate field whic #### 7.1.2.1 Subject Alternative Name Extension -**Certificate Field**: `subjectAltName:dNSName` -**Required/Optional**: **Required** +**Certificate Field**: `subjectAltName:dNSName` + +**Required/Optional**: **Required** + **Contents**: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This extension MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. #### 7.1.2.2 CA/Browser Forum Organization Identifier Extension -**Extension Name**: `cabfOrganizationIdentifier` (OID: 2.23.140.3.1) -**Verbose OID**: `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-extensions(3) cabf-organization-identifier(1) }` -**Required/Optional**: **Optional (but see below)** +**Extension Name**: `cabfOrganizationIdentifier` (OID: 2.23.140.3.1) + +**Verbose OID**: `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-extensions(3) cabf-organization-identifier(1) }` + +**Required/Optional**: **Optional (but see below)** + **Contents**: If the subject:organizationIdentifier is present, this field MUST be present. If present, this extension MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. @@ -1474,8 +1474,10 @@ Subject to the requirements of these Guidelines, the EV Certificate and certific ##### 7.1.4.2.1 Subject Organization Name Field -**Certificate Field**: `subject:organizationName` (OID 2.5.4.10) -**Required/Optional**: Required +**Certificate Field**: `subject:organizationName` (OID 2.5.4.10) + +**Required/Optional**: Required + **Contents**: This field MUST contain the Subject's full legal organization name as listed in the official records of the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration or as otherwise verified by the CA as provided herein. A CA MAY abbreviate the organization prefixes or suffixes in the organization name, e.g., if the official record shows "Company Name Incorporated" the CA MAY include "Company Name, Inc." When abbreviating a Subject's full legal name as allowed by this subsection, the CA MUST use abbreviations that are not misleading in the Jurisdiction of Incorporation or Registration. @@ -1486,38 +1488,42 @@ If the combination of names or the organization name by itself exceeds 64 charac ##### 7.1.4.2.2 Subject Common Name Field -**Certificate Field**: `subject:commonName` (OID: 2.5.4.3) -**Required/Optional**: Deprecated (Discouraged, but not prohibited) +**Certificate Field**: `subject:commonName` (OID: 2.5.4.3) + +**Required/Optional**: Deprecated (Discouraged, but not prohibited) + **Contents**: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This field MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. ##### 7.1.4.2.3 Subject Business Category Field -**Certificate Field**: `subject:businessCategory` (OID: 2.5.4.15) -**Required/Optional**: Required +**Certificate Field**: `subject:businessCategory` (OID: 2.5.4.15) + +**Required/Optional**: Required + **Contents**: This field MUST contain one of the following strings: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity" depending upon whether the Subject qualifies under the terms of [Section 4.1.1.1](#4111-private-organization-subjects), [Section 4.1.1.2](#4112-government-entity-subjects), [Section 4.1.1.3](#4113-business-entity-subjects) or [Section 4.1.1.4](#4114-non-commercial-entity-subjects), respectively. ##### 7.1.4.2.4 Subject Jurisdiction of Incorporation or Registration Field **Certificate Fields**: -Locality (if required): - `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1) +Locality (if required): `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1) -State or province (if required): - `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2) +State or province (if required): `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2) -Country: - `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) +Country: `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) + +**Required/Optional**: Required -**Required/Optional**: Required **Contents**: These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. Country information MUST be specified using the applicable ISO country code. State or province or locality information (where applicable) for the Subject's Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction. Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, the values within these fields have been disclosed within the latest publicly-available disclosure, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), as acceptable values for the applicable Incorporating Agency or Registration Agency. ##### 7.1.4.2.5 Subject Registration Number Field -**Certificate Field**: `subject:serialNumber` (OID: 2.5.4.5) -**Required/Optional**: **Required** +**Certificate Field**: `subject:serialNumber` (OID: 2.5.4.5) + +**Required/Optional**: **Required** + **Contents**: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). For Government Entities that do not have a Registration Number or readily verifiable date of creation, the CA SHALL enter appropriate language to indicate that the Subject is a Government Entity. @@ -1527,13 +1533,20 @@ Effective as of 1 October 2020, if the CA has disclosed a set of acceptable form ##### 7.1.4.2.6 Subject Physical Address of Place of Business Field -**Certificate Fields**: - Number and street: `subject:streetAddress` (OID: 2.5.4.9) - City or town: `subject:localityName` (OID: 2.5.4.7) - State or province (where applicable): `subject:stateOrProvinceName` (OID: 2.5.4.8) - Country: `subject:countryName` (OID: 2.5.4.6) - Postal code: `subject:postalCode` (OID: 2.5.4.17) -**Required/Optional**: Required/Optional +**Certificate Fields**: + +Number and street: `subject:streetAddress` (OID: 2.5.4.9) + +City or town: `subject:localityName` (OID: 2.5.4.7) + +State or province (where applicable): `subject:stateOrProvinceName` (OID: 2.5.4.8) + +Country: `subject:countryName` (OID: 2.5.4.6) + +Postal code: `subject:postalCode` (OID: 2.5.4.17) + +**Required/Optional**: Required/Optional + **Contents**: These fields MUST contain the verified physical address of the Subject’s Place of Business. The `countryName` field MUST be present and MUST contain the applicable two-letter ISO 3166-1 country code. If the country is not represented by an official ISO 3166-1 code, the ISO 3166-1 user-assigned code "XX" MUST be used. @@ -1544,13 +1557,16 @@ The `streetAddress` and `postalCode` fields are OPTIONAL. If present, they MUST ##### 7.1.4.2.7 Subject Organizational Unit Name Field -**Certificate Field**: `subject:organizationalUnitName` (OID: 2.5.4.11) +**Certificate Field**: `subject:organizationalUnitName` (OID: 2.5.4.11) + **Required/Optional/Prohibited**: **Prohibited**. ##### 7.1.4.2.8 Subject Organization Identifier Field -**Certificate Field**: `subject:organizationIdentifier` (OID: 2.5.4.97) -**Required/Optional**: Optional +**Certificate Field**: `subject:organizationIdentifier` (OID: 2.5.4.97) + +**Required/Optional**: Optional + **Contents**: If present, this field MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. The organizationIdentifier MUST be encoded as a PrintableString or UTF8String. @@ -1873,7 +1889,7 @@ On this basis, we hereby offer the following opinion: 2. That Company conducts business under the assumed name or "DBA"_[assumed name of the Applicant]_ and has registered such name with the appropriate government agency in the jurisdiction of its place of business below. -3. That _[name of Client's Representative]_[^2] has authority to act on behalf of Company to: [_select as appropriate_] (a) provide the information about Company required for issuance of the EV Certificates as contained in the attached Application, (b) request one or more EV Certificates and to designate other persons to request EV Certificates, and (c) agree to the relevant contractual obligations contained in the Subscriber Agreement on behalf of Company. +3. That _[name of Client's Representative]_[^2] has authority to act on behalf of Company to: [_select as appropriate_] (a) provide the information about Company required for issuance of the EV Certificates as contained in the attached Application, (b) request one or more EV Certificates and to designate other persons to request EV Certificates, and (c) agree to the relevant contractual obligations contained in the Subscriber Agreement on behalf of Company. 4. That Company has a physical presence and its place of business is at the following location: @@ -1999,7 +2015,7 @@ NOTE: This appendix provides alternative interpretations of the EV Guidelines fo 3. Translated Name - In order to include a Latin character name in the EV certificate that is not a direct Romanization of the registered name (e.g. an English Name) the CA MUST verify that the Latin character name is: + In order to include a Latin character name in the EV certificate that is not a direct Romanization of the registered name (e.g. an English Name) the CA MUST verify that the Latin character name is: A. Included in the Articles of Incorporation (or equivalent document) filed as part of the organization registration; or B. Recognized by a QTIS in the Applicant's Jurisdiction of Incorporation as the Applicant's recognized name for tax filings; or @@ -2122,7 +2138,7 @@ The following Registration Schemes are currently recognized as valid under these - **NTR**: - The information carried in this field shall be the same as held in Subject Registration Number Field as specified in [Section 7.1.4.2.5](#71425-subject-registration-number-field) and the country code used in the Registration Scheme identifier shall match that of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). + The information carried in this field shall be the same as held in Subject Registration Number Field as specified in [Section 7.1.4.2.5](#71425-subject-registration-number-field) and the country code used in the Registration Scheme identifier shall match that of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). Where the Subject Jurisdiction of Incorporation or Registration Field in 9.2.4 includes more than the country code, the additional locality information shall be included as specified in [Section 7.1.4.2.8](#71428-subject-organization-identifier-field) and/or [Section 7.1.2.2](#7122-cabrowser-forum-organization-identifier-extension). From 84b2e63612c49e7d5acd122e18c1ca76e771dde6 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 22:06:53 +0100 Subject: [PATCH 083/121] # 432 7.1.4.2 reverted double spaces as eol --- docs/EVG.md | 86 ++++++++++++++++++----------------------------------- 1 file changed, 29 insertions(+), 57 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 406b10be..52488603 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -1417,20 +1417,15 @@ If a CA includes an extension in a certificate that has a Certificate field whic #### 7.1.2.1 Subject Alternative Name Extension -**Certificate Field**: `subjectAltName:dNSName` - -**Required/Optional**: **Required** - +**Certificate Field**: `subjectAltName:dNSName` +**Required/Optional**: **Required** **Contents**: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This extension MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. #### 7.1.2.2 CA/Browser Forum Organization Identifier Extension -**Extension Name**: `cabfOrganizationIdentifier` (OID: 2.23.140.3.1) - -**Verbose OID**: `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-extensions(3) cabf-organization-identifier(1) }` - -**Required/Optional**: **Optional (but see below)** - +**Extension Name**: `cabfOrganizationIdentifier` (OID: 2.23.140.3.1) +**Verbose OID**: `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-extensions(3) cabf-organization-identifier(1) }` +**Required/Optional**: **Optional (but see below)** **Contents**: If the subject:organizationIdentifier is present, this field MUST be present. If present, this extension MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. @@ -1474,10 +1469,8 @@ Subject to the requirements of these Guidelines, the EV Certificate and certific ##### 7.1.4.2.1 Subject Organization Name Field -**Certificate Field**: `subject:organizationName` (OID 2.5.4.10) - -**Required/Optional**: Required - +**Certificate Field**: `subject:organizationName` (OID 2.5.4.10) +**Required/Optional**: Required **Contents**: This field MUST contain the Subject's full legal organization name as listed in the official records of the Incorporating or Registration Agency in the Subject's Jurisdiction of Incorporation or Registration or as otherwise verified by the CA as provided herein. A CA MAY abbreviate the organization prefixes or suffixes in the organization name, e.g., if the official record shows "Company Name Incorporated" the CA MAY include "Company Name, Inc." When abbreviating a Subject's full legal name as allowed by this subsection, the CA MUST use abbreviations that are not misleading in the Jurisdiction of Incorporation or Registration. @@ -1488,42 +1481,31 @@ If the combination of names or the organization name by itself exceeds 64 charac ##### 7.1.4.2.2 Subject Common Name Field -**Certificate Field**: `subject:commonName` (OID: 2.5.4.3) - -**Required/Optional**: Deprecated (Discouraged, but not prohibited) - +**Certificate Field**: `subject:commonName` (OID: 2.5.4.3) +**Required/Optional**: Deprecated (Discouraged, but not prohibited) **Contents**: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This field MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. ##### 7.1.4.2.3 Subject Business Category Field -**Certificate Field**: `subject:businessCategory` (OID: 2.5.4.15) - -**Required/Optional**: Required - +**Certificate Field**: `subject:businessCategory` (OID: 2.5.4.15) +**Required/Optional**: Required **Contents**: This field MUST contain one of the following strings: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity" depending upon whether the Subject qualifies under the terms of [Section 4.1.1.1](#4111-private-organization-subjects), [Section 4.1.1.2](#4112-government-entity-subjects), [Section 4.1.1.3](#4113-business-entity-subjects) or [Section 4.1.1.4](#4114-non-commercial-entity-subjects), respectively. ##### 7.1.4.2.4 Subject Jurisdiction of Incorporation or Registration Field -**Certificate Fields**: - -Locality (if required): `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1) - -State or province (if required): `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2) - -Country: `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) - -**Required/Optional**: Required - +**Certificate Fields**: +Locality (if required): `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1) +State or province (if required): `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2) +Country: `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) +**Required/Optional**: Required **Contents**: These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. Country information MUST be specified using the applicable ISO country code. State or province or locality information (where applicable) for the Subject's Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction. Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, the values within these fields have been disclosed within the latest publicly-available disclosure, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), as acceptable values for the applicable Incorporating Agency or Registration Agency. ##### 7.1.4.2.5 Subject Registration Number Field -**Certificate Field**: `subject:serialNumber` (OID: 2.5.4.5) - -**Required/Optional**: **Required** - +**Certificate Field**: `subject:serialNumber` (OID: 2.5.4.5) +**Required/Optional**: **Required** **Contents**: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). For Government Entities that do not have a Registration Number or readily verifiable date of creation, the CA SHALL enter appropriate language to indicate that the Subject is a Government Entity. @@ -1533,20 +1515,13 @@ Effective as of 1 October 2020, if the CA has disclosed a set of acceptable form ##### 7.1.4.2.6 Subject Physical Address of Place of Business Field -**Certificate Fields**: - -Number and street: `subject:streetAddress` (OID: 2.5.4.9) - -City or town: `subject:localityName` (OID: 2.5.4.7) - -State or province (where applicable): `subject:stateOrProvinceName` (OID: 2.5.4.8) - -Country: `subject:countryName` (OID: 2.5.4.6) - -Postal code: `subject:postalCode` (OID: 2.5.4.17) - -**Required/Optional**: Required/Optional - +**Certificate Fields**: +Number and street: `subject:streetAddress` (OID: 2.5.4.9) +City or town: `subject:localityName` (OID: 2.5.4.7) +State or province (where applicable): `subject:stateOrProvinceName` (OID: 2.5.4.8) +Country: `subject:countryName` (OID: 2.5.4.6) +Postal code: `subject:postalCode` (OID: 2.5.4.17) +**Required/Optional**: Required/Optional **Contents**: These fields MUST contain the verified physical address of the Subject’s Place of Business. The `countryName` field MUST be present and MUST contain the applicable two-letter ISO 3166-1 country code. If the country is not represented by an official ISO 3166-1 code, the ISO 3166-1 user-assigned code "XX" MUST be used. @@ -1557,16 +1532,13 @@ The `streetAddress` and `postalCode` fields are OPTIONAL. If present, they MUST ##### 7.1.4.2.7 Subject Organizational Unit Name Field -**Certificate Field**: `subject:organizationalUnitName` (OID: 2.5.4.11) - -**Required/Optional/Prohibited**: **Prohibited**. +**Certificate Field**: `subject:organizationalUnitName` (OID: 2.5.4.11) +**Required/Optional/Prohibited**: **Prohibited** ##### 7.1.4.2.8 Subject Organization Identifier Field -**Certificate Field**: `subject:organizationIdentifier` (OID: 2.5.4.97) - -**Required/Optional**: Optional - +**Certificate Field**: `subject:organizationIdentifier` (OID: 2.5.4.97) +**Required/Optional**: Optional **Contents**: If present, this field MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. The organizationIdentifier MUST be encoded as a PrintableString or UTF8String. From 9da37c2ec735dc496062710b735e0339360c7dc3 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 22:10:56 +0100 Subject: [PATCH 084/121] #432 RFC links --- docs/EVG.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 52488603..f1e48c91 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -345,7 +345,7 @@ See Baseline Requirements, which are available at . Terms not otherwise defined in these Guidelines shall be as defined in applicable agreements, user manuals, certification practice statements (CPS), and certificate policies (CP) of the CA issuing EV Certificates. -The key words "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in these Guidelines shall be interpreted in accordance with RFC 2119. +The key words "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in these Guidelines shall be interpreted in accordance with [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119). By convention, this document omits time and timezones when listing effective requirements such as dates. Except when explicitly specified, the associated time with a date shall be 00:00:00 UTC. @@ -368,7 +368,7 @@ C. Specify the CA's and its Root CA's entire root certificate hierarchy includi Each CA MUST publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see [Section 8](#8-compliance-audit-and-other-assessments)). -The CA's Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647. The Certificate Policy and/or Certification Practice Statement MUST include all material required by RFC 3647. +The CA's Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with [RFC 3647](https://datatracker.ietf.org/doc/html/rfc3647). The Certificate Policy and/or Certification Practice Statement MUST include all material required by [RFC 3647](https://datatracker.ietf.org/doc/html/rfc3647). Each CA SHALL publicly give effect to these Guidelines and represent that they will adhere to the latest published version by incorporating them into their respective EV Policies, using a clause such as the following (which must include a link to the official version of these Guidelines): From ccfba32cc2d6118f09c2f0bbdfe3a934a31613a7 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 22:37:01 +0100 Subject: [PATCH 085/121] #432 spacing test based on EVG --- docs/BR.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 115ef913..9b869080 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -625,7 +625,7 @@ The CA SHALL make revocation information for Subordinate Certificates and Subscr ## 2.2 Publication of information The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see [Section 8.4](#84-topics-covered-by-assessment)). -The CA SHALL develop, implement, enforce, and at least once every 366 days update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements.t)). +The CA SHALL develop, implement, enforce, and at least once every 366 days update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements. The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and MUST include all material required by RFC 3647. @@ -758,6 +758,7 @@ Effective January 15, 2025: - When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. - When obtaining Domain Contact information for a requested Domain Name the CA: + - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. @@ -845,6 +846,7 @@ Effective January 15, 2025: - When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. - When obtaining Domain Contact information for a requested Domain Name the CA: + - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. @@ -889,6 +891,7 @@ Effective January 15, 2025: - When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. - When obtaining Domain Contact information for a requested Domain Name the CA: + - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. @@ -943,8 +946,10 @@ The file containing the Request Token or Random Value: If the CA follows redirects, the following apply: 1. Redirects MUST be initiated at the HTTP protocol layer. + a. For validations performed on or after July 1, 2021, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4), or a 308 HTTP status code response, as defined in [RFC 7538, Section 3](https://tools.ietf.org/html/rfc7538#section-3). Redirects MUST be to the final value of the Location HTTP response header, as defined in [RFC 7231, Section 7.1.2](https://tools.ietf.org/html/rfc7231#section-7.1.2). b. For validations performed prior to July 1, 2021, redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4). CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a. + 2. Redirects MUST be to resource URLs with either the "http" or "https" scheme. 3. Redirects MUST be to resource URLs accessed via Authorized Ports. @@ -968,8 +973,10 @@ The token (as defined in RFC 8555, Section 8.3) MUST NOT be used for more than 3 If the CA follows redirects, the following apply: 1. Redirects MUST be initiated at the HTTP protocol layer. + a. For validations performed on or after July 1, 2021, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4), or a 308 HTTP status code response, as defined in [RFC 7538, Section 3](https://tools.ietf.org/html/rfc7538#section-3). Redirects MUST be to the final value of the Location HTTP response header, as defined in [RFC 7231, Section 7.1.2](https://tools.ietf.org/html/rfc7231#section-7.1.2). b. For validations performed prior to July 1, 2021, redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4). CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a. + 2. Redirects MUST be to resource URLs with either the "http" or "https" scheme. 3. Redirects MUST be to resource URLs accessed via Authorized Ports. From 8dc0349784428b10c4159f73e10f0755a3f7406f Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 22:57:45 +0100 Subject: [PATCH 086/121] #432 spacing and maxlength ref --- docs/BR.md | 52 ++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 38 insertions(+), 14 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 9b869080..66bdc875 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -758,7 +758,6 @@ Effective January 15, 2025: - When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. - When obtaining Domain Contact information for a requested Domain Name the CA: - - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. @@ -846,7 +845,6 @@ Effective January 15, 2025: - When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. - When obtaining Domain Contact information for a requested Domain Name the CA: - - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. @@ -891,7 +889,6 @@ Effective January 15, 2025: - When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. - When obtaining Domain Contact information for a requested Domain Name the CA: - - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. @@ -946,10 +943,8 @@ The file containing the Request Token or Random Value: If the CA follows redirects, the following apply: 1. Redirects MUST be initiated at the HTTP protocol layer. - a. For validations performed on or after July 1, 2021, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4), or a 308 HTTP status code response, as defined in [RFC 7538, Section 3](https://tools.ietf.org/html/rfc7538#section-3). Redirects MUST be to the final value of the Location HTTP response header, as defined in [RFC 7231, Section 7.1.2](https://tools.ietf.org/html/rfc7231#section-7.1.2). b. For validations performed prior to July 1, 2021, redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4). CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a. - 2. Redirects MUST be to resource URLs with either the "http" or "https" scheme. 3. Redirects MUST be to resource URLs accessed via Authorized Ports. @@ -973,10 +968,8 @@ The token (as defined in RFC 8555, Section 8.3) MUST NOT be used for more than 3 If the CA follows redirects, the following apply: 1. Redirects MUST be initiated at the HTTP protocol layer. - a. For validations performed on or after July 1, 2021, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4), or a 308 HTTP status code response, as defined in [RFC 7538, Section 3](https://tools.ietf.org/html/rfc7538#section-3). Redirects MUST be to the final value of the Location HTTP response header, as defined in [RFC 7231, Section 7.1.2](https://tools.ietf.org/html/rfc7231#section-7.1.2). b. For validations performed prior to July 1, 2021, redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4). CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a. - 2. Redirects MUST be to resource URLs with either the "http" or "https" scheme. 3. Redirects MUST be to resource URLs accessed via Authorized Ports. @@ -1206,23 +1199,31 @@ Remote Network Perspectives performing Multi-Perspective Issuance Corroboration: MUST: - Network Hardening + - Rely upon networks (e.g., Internet Service Providers or Cloud Provider Networks) implementing measures to mitigate BGP routing incidents in the global Internet routing system for providing internet connectivity to the Network Perspective. SHOULD: - Facility & Service Provider Requirements + - Be hosted from an ISO/IEC 27001 certified facility or equivalent security framework independently audited and certified or reported. - Rely on services covered in one of the following reports: System and Organization Controls 2 (SOC 2), ISAE 3000, ENISA 715, FedRAMP Moderate, C5:2020, CSA STAR CCM, or equivalent services framework independently audited and certified or reported. + - Vulnerability Detection and Patch Management + - Implement intrusion detection and prevention controls to protect against common network and system threats. - Document and follow a vulnerability correction process that addresses the identification, review, response, and remediation of vulnerabilities. - Undergo or perform a Vulnerability Scan at least every three (3) months. - Undergo a Penetration Test on at least an annual basis. - Apply recommended security patches within six (6) months of the security patch's availability, unless the CA documents that the security patch would introduce additional vulnerabilities or instabilities that outweigh the benefits of applying the security patch. + - System Hardening + - Disable all accounts, applications, services, protocols, and ports that are not used. - Implement multi-factor authentication for all user accounts. + - Network Hardening + - Configure each network boundary control (firewall, switch, router, gateway, or other network control device or system) with rules that support only the services, protocols, ports, and communications identified as necessary to its operations. - Rely upon networks (e.g., Internet Service Providers) that: 1) use mechanisms based on Secure Inter-Domain Routing (RFC 6480), for example, BGP Prefix Origin Validation (RFC 6811), 2) make use of other non-RPKI route-leak prevention mechanisms (such as RFC 9234), and 3) apply current best practices described in BCP 194. While It is RECOMMENDED that under normal operating conditions Network Perspectives performing Multi-Perspective Issuance Corroboration forward all Internet traffic via a network or set of networks that filter RPKI-invalid BGP routes as defined by RFC 6811, it is NOT REQUIRED. @@ -1232,12 +1233,17 @@ If any of the above considerations are performed by a Delegated Third Party, the Phased Implementation Timeline: -- *Effective September 15, 2024*, the CA SHOULD implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. -- *Effective March 15, 2025*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MAY proceed with certificate issuance if the number of remote Network Perspectives that do not corroborate the determinations made by the Primary Network Perspective ("non-corroborations") is greater than allowed in the Quorum Requirements table. -- *Effective September 15, 2025*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. -- *Effective March 15, 2026*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least three (3) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. -- *Effective June 15, 2026*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least four (4) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. -- *Effective December 15, 2026*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least five (5) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. +- Effective September 15, 2024, the CA SHOULD implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. + +- Effective March 15, 2025, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MAY proceed with certificate issuance if the number of remote Network Perspectives that do not corroborate the determinations made by the Primary Network Perspective ("non-corroborations") is greater than allowed in the Quorum Requirements table. + +- Effective September 15, 2025, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. + +- Effective March 15, 2026, the CA MUST implement Multi-Perspective Issuance Corroboration using at least three (3) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. + +- Effective June 15, 2026, the CA MUST implement Multi-Perspective Issuance Corroboration using at least four (4) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. + +- Effective December 15, 2026, the CA MUST implement Multi-Perspective Issuance Corroboration using at least five (5) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. ### 3.2.3 Authentication of individual identity @@ -3479,6 +3485,8 @@ Table: Encoding and Order Requirements for Selected Attributes | `organizationalUnitName` | `2.5.4.11` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | | `commonName` | `2.5.4.3` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | +[^maxlength]: **Note**: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits. + [^surname_givenname]: **Note**: Although RFC 5280 specifies the upper bound as 32,768 characters, this was a transcription error from X.520 (08/2005). The effective (interoperable) upper bound is 64 characters. CAs that include attributes in the Certificate `subject` field that are listed in the table below SHALL follow the specified encoding requirements for the attribute. @@ -3494,7 +3502,6 @@ Table: Encoding Requirements for Selected Attributes | `serialNumber` | `2.5.4.5` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 64 | | `organizationIdentifier` | `2.5.4.97` | X.520 | MUST use `UTF8String` or `PrintableString` | None | -[^maxlength]: **Note**: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits. #### 7.1.4.3 Subscriber Certificate Common Name Attribute @@ -3800,23 +3807,33 @@ The CA represents and warrants to the Certificate Beneficiaries that, during the The Certificate Warranties specifically include, but are not limited to, the following: 1. **Right to Use Domain Name or IP Address**: That, at the time of issuance, the CA + i. implemented a procedure for verifying that the Applicant either had the right to use, or had control of, the Domain Name(s) and IP address(es) listed in the Certificate's `subject` field and `subjectAltName` extension (or, only in the case of Domain Names, was delegated such right or control by someone who had such right to use or control); 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; + 2. **Authorization for Certificate**: That, at the time of issuance, the CA + i. implemented a procedure for verifying that the Subject authorized the issuance of the Certificate and that the Applicant Representative is authorized to request the Certificate on behalf of the Subject; 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; 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. **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. **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 @@ -3839,15 +3856,22 @@ The CA SHALL implement a process to ensure that each Subscriber Agreement or Ter The Subscriber Agreement or Terms of Use MUST contain provisions imposing on the Applicant itself (or made by the Applicant on behalf of its principal or agent under a subcontractor or hosting service relationship) the following obligations and warranties: 1. **Accuracy of Information**: An obligation and warranty to provide accurate and complete information at all times to the CA, both in the certificate request and as otherwise requested by the CA in connection with the issuance of the Certificate(s) to be supplied by the CA; + 2. **Protection of Private Key**: An obligation and warranty by the Applicant to take all reasonable measures to assure control of, keep confidential, and properly protect at all times the Private Key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device, e.g. password or token); + 3. **Acceptance of Certificate**: An obligation and warranty that the Subscriber will review and verify the Certificate contents for accuracy; + 4. **Use of Certificate**: An obligation and warranty to install the Certificate only on servers that are accessible at the `subjectAltName`(s) listed in the Certificate, and to use the Certificate solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement or Terms of Use; + 5. **Reporting and Revocation**: An obligation and warranty to: + a. promptly request revocation of the Certificate, and cease using it and its associated Private Key, if there is any actual or suspected misuse or compromise of the Subscriber’s Private Key associated with the Public Key included in the Certificate, and b. promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate; 6. **Termination of Use of Certificate**: An obligation and warranty to promptly cease all use of the Private Key corresponding to the Public Key included in the Certificate upon revocation of that Certificate for reasons of Key Compromise. + 7. **Responsiveness**: An obligation to respond to the CA's instructions concerning Key Compromise or Certificate misuse within a specified time period. + 8. **Acknowledgment and Acceptance**: An acknowledgment and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber Agreement or Terms of Use or if revocation is required by the CA's CP, CPS, or these Baseline Requirements. ### 9.6.4 Relying party representations and warranties From b3e0ba178f5bfe86911a296f521ba5942dc827ae Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 23:07:00 +0100 Subject: [PATCH 087/121] #432 maxlenght in header replaced with * --- docs/BR.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 66bdc875..42595229 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -3471,7 +3471,7 @@ CAs that include attributes in the Certificate `subject` field that are listed i Table: Encoding and Order Requirements for Selected Attributes -| **Attribute** | **OID** | **Specification** | **Encoding Requirements** | **Max Length[^maxlength]** | +| **Attribute** | **OID** | **Specification** | **Encoding Requirements** | **Max Length\*** | | ---- | -- | --- | ---- | - | | `domainComponent` | `0.9.2342.19200300.100.1.25` | [RFC 4519](https://tools.ietf.org/html/rfc4519) | MUST use `IA5String` | 63 | | `countryName` | `2.5.4.6` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 2 | @@ -3485,7 +3485,7 @@ Table: Encoding and Order Requirements for Selected Attributes | `organizationalUnitName` | `2.5.4.11` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | | `commonName` | `2.5.4.3` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | -[^maxlength]: **Note**: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits. +\* **Note**: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits. [^surname_givenname]: **Note**: Although RFC 5280 specifies the upper bound as 32,768 characters, this was a transcription error from X.520 (08/2005). The effective (interoperable) upper bound is 64 characters. @@ -3493,7 +3493,7 @@ CAs that include attributes in the Certificate `subject` field that are listed i Table: Encoding Requirements for Selected Attributes -| **Attribute** | **OID** | **Specification** | **Encoding Requirements** | **Max Length[^maxlength]** | +| **Attribute** | **OID** | **Specification** | **Encoding Requirements** | **Max Length\*** | | ---- | -- | --- | ---- | - | | `businessCategory` | `2.5.4.15` | X.520 | MUST use `UTF8String` or `PrintableString` | 128 | | `jurisdictionCountry` | `1.3.6.1.4.1.311.60.2.1.3` | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `PrintableString` | 2 | @@ -3502,6 +3502,7 @@ Table: Encoding Requirements for Selected Attributes | `serialNumber` | `2.5.4.5` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 64 | | `organizationIdentifier` | `2.5.4.97` | X.520 | MUST use `UTF8String` or `PrintableString` | None | +\* **Note**: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits. #### 7.1.4.3 Subscriber Certificate Common Name Attribute From bf4575db2922396eb81b7000e2e23e6a6ed283f5 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 23:15:38 +0100 Subject: [PATCH 088/121] #432 7.1.2.2.5 tables test fix --- docs/BR.md | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 42595229..16fd3597 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1792,6 +1792,7 @@ The CA and each Delegated Third Party SHALL record events related to the securit The CA SHALL record at least the following events: 1. CA certificate and key lifecycle events, including: + 1. Key generation, backup, storage, recovery, archival, and destruction; 2. Certificate requests, renewal, and re-key requests, and revocation; 3. Approval and rejection of certificate requests; @@ -1801,6 +1802,7 @@ The CA SHALL record at least the following events: 7. Introduction of new Certificate Profiles and retirement of existing Certificate Profiles. 2. Subscriber Certificate lifecycle management events, including: + 1. Certificate requests, renewal, and re-key requests, and revocation; 2. All verification activities stipulated in these Requirements and the CA's Certification Practice Statement; 3. Approval and rejection of certificate requests; @@ -1814,6 +1816,7 @@ The CA SHALL record at least the following events: 8. Multi-Perspective Issuance Corroboration quorum results for each attempted domain name or IP address represented in a Certificate request (i.e., "3/4" which should be interpreted as "Three (3) out of four (4) attempted Network Perspectives corroborated the determinations made by the Primary Network Perspective). 3. Security events, including: + 1. Successful and unsuccessful PKI system access attempts; 2. PKI and security system actions performed; 3. Security profile changes; @@ -2316,21 +2319,21 @@ Table: Restricted TLS Cross-Certified Subordinate CA Extended Key Usage Purposes | **Key Purpose** | **Description** | | --- | ------- | -| `id-kp-serverAuth` | MUST be present.| -| `id-kp-clientAuth` | MAY be present.| -| `id-kp-emailProtection`| MUST NOT be present.| -| `id-kp-codeSigning` | MUST NOT be present.| -| `id-kp-timeStamping` | MUST NOT be present.| -| `anyExtendedKeyUsage` | MUST NOT be present.| -| Any other value | NOT RECOMMENDED.| +| `id-kp-serverAuth` | MUST be present. | +| `id-kp-clientAuth` | MAY be present. | +| `id-kp-emailProtection`| MUST NOT be present. | +| `id-kp-codeSigning` | MUST NOT be present. | +| `id-kp-timeStamping` | MUST NOT be present. | +| `anyExtendedKeyUsage` | MUST NOT be present. | +| Any other value | NOT RECOMMENDED. | Table: Restricted Non-TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs not issuing TLS certificates directly or transitively) | **Key Purpose** | **Description** | | --- | ------- | -| `id-kp-serverAuth` | MUST NOT be present.| -| `anyExtendedKeyUsage` | MUST NOT be present.| -| Any other value | MAY be present.| +| `id-kp-serverAuth` | MUST NOT be present. | +| `anyExtendedKeyUsage` | MUST NOT be present. | +| Any other value | MAY be present. | Each included Extended Key Usage key usage purpose: From d5730d42365cb23de0beec927d0de774143f06f5 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 23:22:46 +0100 Subject: [PATCH 089/121] #432 7.1.2.2.5 tables test fix --- docs/BR.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 16fd3597..3b658f51 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2317,23 +2317,23 @@ Alternatively, if the Issuing CA does not use this form, then the Extended Key U Table: Restricted TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs issuing TLS certificates directly or transitively) -| **Key Purpose** | **Description** | -| --- | ------- | -| `id-kp-serverAuth` | MUST be present. | -| `id-kp-clientAuth` | MAY be present. | -| `id-kp-emailProtection`| MUST NOT be present. | -| `id-kp-codeSigning` | MUST NOT be present. | -| `id-kp-timeStamping` | MUST NOT be present. | -| `anyExtendedKeyUsage` | MUST NOT be present. | -| Any other value | NOT RECOMMENDED. | +| **Key Purpose** | **Description** | +| --- | -------- | +| `id-kp-serverAuth` | MUST be present. | +| `id-kp-clientAuth` | MAY be present. | +| `id-kp-emailProtection` | MUST NOT be present. | +| `id-kp-codeSigning` | MUST NOT be present. | +| `id-kp-timeStamping` | MUST NOT be present. | +| `anyExtendedKeyUsage` | MUST NOT be present. | +| Any other value | NOT RECOMMENDED. | Table: Restricted Non-TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs not issuing TLS certificates directly or transitively) -| **Key Purpose** | **Description** | -| --- | ------- | -| `id-kp-serverAuth` | MUST NOT be present. | -| `anyExtendedKeyUsage` | MUST NOT be present. | -| Any other value | MAY be present. | +| **Key Purpose** | **Description** | +| --- | -------- | +| `id-kp-serverAuth` | MUST NOT be present. | +| `anyExtendedKeyUsage` | MUST NOT be present. | +| Any other value | MAY be present. | Each included Extended Key Usage key usage purpose: From 237a5a52bb516bb053c08161e5a50283787dfaf1 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 23:26:53 +0100 Subject: [PATCH 090/121] #432 7.1.2.2.5 tables test fix --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 3b658f51..a7fc4a1f 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2330,7 +2330,7 @@ Table: Restricted TLS Cross-Certified Subordinate CA Extended Key Usage Purposes Table: Restricted Non-TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs not issuing TLS certificates directly or transitively) | **Key Purpose** | **Description** | -| --- | -------- | +| - | -------- | | `id-kp-serverAuth` | MUST NOT be present. | | `anyExtendedKeyUsage` | MUST NOT be present. | | Any other value | MAY be present. | From b5513043887e0d3e99b8270402a0180eb047b15b Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 23:41:26 +0100 Subject: [PATCH 091/121] #432 fixing table again --- docs/BR.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index a7fc4a1f..5ad2f235 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2315,7 +2315,7 @@ Alternatively, if the Issuing CA does not use this form, then the Extended Key U ##### 7.1.2.2.5 Cross-Certified Subordinate CA Extended Key Usage - Restricted -Table: Restricted TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs issuing TLS certificates directly or transitively) +Restricted TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs issuing TLS certificates directly or transitively) | **Key Purpose** | **Description** | | --- | -------- | @@ -2327,7 +2327,7 @@ Table: Restricted TLS Cross-Certified Subordinate CA Extended Key Usage Purposes | `anyExtendedKeyUsage` | MUST NOT be present. | | Any other value | NOT RECOMMENDED. | -Table: Restricted Non-TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs not issuing TLS certificates directly or transitively) +Restricted Non-TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs not issuing TLS certificates directly or transitively) | **Key Purpose** | **Description** | | - | -------- | From 7a6953dda9430a19c08a60c80d4816ded2ce36ff Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Mon, 1 Dec 2025 23:51:14 +0100 Subject: [PATCH 092/121] #432 fixing table title --- docs/BR.md | 36 ++++++++++++++++++++---------------- 1 file changed, 20 insertions(+), 16 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 5ad2f235..3ac8a578 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2315,25 +2315,29 @@ Alternatively, if the Issuing CA does not use this form, then the Extended Key U ##### 7.1.2.2.5 Cross-Certified Subordinate CA Extended Key Usage - Restricted -Restricted TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs issuing TLS certificates directly or transitively) +Restricted TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs issuing TLS certificates directly or transitively). -| **Key Purpose** | **Description** | -| --- | -------- | -| `id-kp-serverAuth` | MUST be present. | -| `id-kp-clientAuth` | MAY be present. | -| `id-kp-emailProtection` | MUST NOT be present. | -| `id-kp-codeSigning` | MUST NOT be present. | -| `id-kp-timeStamping` | MUST NOT be present. | -| `anyExtendedKeyUsage` | MUST NOT be present. | -| Any other value | NOT RECOMMENDED. | +Table: TLS Cross-Certified Subordinate CA EKU -Restricted Non-TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs not issuing TLS certificates directly or transitively) +| **Key Purpose** | **Description** | +| --- | ------- | +| `id-kp-serverAuth` | MUST be present. | +| `id-kp-clientAuth` | MAY be present. | +| `id-kp-emailProtection`| MUST NOT be present. | +| `id-kp-codeSigning` | MUST NOT be present. | +| `id-kp-timeStamping` | MUST NOT be present. | +| `anyExtendedKeyUsage` | MUST NOT be present. | +| Any other value | NOT RECOMMENDED. | -| **Key Purpose** | **Description** | -| - | -------- | -| `id-kp-serverAuth` | MUST NOT be present. | -| `anyExtendedKeyUsage` | MUST NOT be present. | -| Any other value | MAY be present. | +Restricted Non-TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs not issuing TLS certificates directly or transitively). + +Table: Non-TLS Cross-Certified Subordinate CA EKU + +| **Key Purpose** | **Description** | +| --- | ------- | +| `id-kp-serverAuth` | MUST NOT be present. | +| `anyExtendedKeyUsage` | MUST NOT be present. | +| Any other value | MAY be present. | Each included Extended Key Usage key usage purpose: From c49aeaeaf981103d3da891860e8211c9a9f88419 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 2 Dec 2025 00:12:17 +0100 Subject: [PATCH 093/121] #432 quotes --- docs/BR.md | 4 ++-- docs/EVG.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 3ac8a578..1ae2734a 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -989,9 +989,9 @@ Except for Onion Domain Names, CAs performing validations using this method MUST ##### 3.2.2.4.21 DNS Labeled with Account ID - ACME -Confirming the Applicant's control over the FQDN by performing the procedure documented for a “dns-account-01” challenge in draft 00 of “Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge,” available at [https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account-label/](https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account-label/). +Confirming the Applicant's control over the FQDN by performing the procedure documented for a |"dns-account-01" challenge in draft 00 of "Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge," available at [https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account-label/](https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account-label/). -The token (as defined in draft 00 of “Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge,” Section 3.1) MUST NOT be used for more than 30 days from its creation. The CPS MAY specify a shorter validity period for the token, in which case the CA MUST follow its CPS. +The token (as defined in draft 00 of "Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge," Section 3.1) MUST NOT be used for more than 30 days from its creation. The CPS MAY specify a shorter validity period for the token, in which case the CA MUST follow its CPS. CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same token as the Primary Network Perspective. diff --git a/docs/EVG.md b/docs/EVG.md index f1e48c91..3870cec9 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -1411,9 +1411,9 @@ This section sets forth minimum requirements for the content of the EV Certifica ### 7.1.2 Certificate extensions -The extensions listed in [Section 7.1.2](#712-certificate-extensions) are recommended for maximum interoperability between certificates and browsers / applications, but are not mandatory on the CAs except where indicated as “Required”. CAs may use other extensions that are not listed in [Section 7.1.2](#712-certificate-extensions), but are encouraged to add them to this section by ballot from time to time to help increase extension standardization across the industry. +The extensions listed in [Section 7.1.2](#712-certificate-extensions) are recommended for maximum interoperability between certificates and browsers / applications, but are not mandatory on the CAs except where indicated as "Required". CAs may use other extensions that are not listed in [Section 7.1.2](#712-certificate-extensions), but are encouraged to add them to this section by ballot from time to time to help increase extension standardization across the industry. -If a CA includes an extension in a certificate that has a Certificate field which is named in [Section 7.1.2](#712-certificate-extensions), the CA must follow the format specified in that subsection. However, no extension or extension format shall be mandatory on a CA unless specifically stated as “Required” in the subsection that describes the extension. +If a CA includes an extension in a certificate that has a Certificate field which is named in [Section 7.1.2](#712-certificate-extensions), the CA must follow the format specified in that subsection. However, no extension or extension format shall be mandatory on a CA unless specifically stated as "Required" in the subsection that describes the extension. #### 7.1.2.1 Subject Alternative Name Extension From b986536085cc18199dfcb2417769eca64b2630ac Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 2 Dec 2025 00:14:35 +0100 Subject: [PATCH 094/121] #432 apostrophes --- docs/BR.md | 28 ++++++++++++++-------------- docs/EVG.md | 16 ++++++++-------- 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 1ae2734a..93b30b4f 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -301,7 +301,7 @@ 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 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. @@ -875,7 +875,7 @@ CAs performing validations using this method MUST implement Multi-Perspective Is ##### 3.2.2.4.15 Phone Contact with Domain Contact v2 -Confirm the Applicant's control over the FQDN by calling the Domain 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 Domain Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN. +Confirm the Applicant's control over the FQDN by calling the Domain 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 Domain Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN. In the event that someone other than a Domain Contact is reached, the CA MAY request to be transferred to the Domain Contact. @@ -900,7 +900,7 @@ Effective July 15, 2025: ##### 3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact -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. +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 MUST NOT knowingly be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation. @@ -914,7 +914,7 @@ CAs performing validations using this method MUST implement Multi-Perspective Is ##### 3.2.2.4.17 Phone Contact with DNS CAA Phone Contact -Confirm the Applicant's control over the FQDN by calling the DNS CAA 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 CAA Phone Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 8659 Section 3. +Confirm the Applicant's control over the FQDN by calling the DNS CAA 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 CAA Phone Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 8659 Section 3. The CA MUST NOT be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation. @@ -1001,7 +1001,7 @@ CAs performing validations using this method MUST implement Multi-Perspective Is Confirming the Applicant's control over a FQDN by verifying the presence of a Persistent DCV TXT Record identifying the Applicant. The record MUST be placed at the "`_validation-persist`" label prepended to the Authorization Domain Name being validated (i.e., "`_validation-persist.[Authorization Domain Name]`"). For this method, the CA MUST NOT use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. This prohibition overrides the Authorization Domain Name definition. CNAME records MAY be followed when resolving the Persistent DCV TXT Record. -The CA MUST confirm the Persistent DCV TXT Record’s RDATA value fulfills the following requirements: +The CA MUST confirm the Persistent DCV TXT Record's RDATA value fulfills the following requirements: 1. The RDATA value MUST conform to the `issue-value` syntax as defined in RFC 8659, Section 4.2; and 2. The `issuer-domain-name` value MUST be an Issuer Domain Name disclosed by the CA in Section 4.2 of the CA's Certificate Policy and/or Certification Practices Statement; and @@ -1032,7 +1032,7 @@ CAs performing validations using this method MUST implement Multi-Perspective Is #### 3.2.2.5 Authentication for an IP Address -This section defines the permitted processes and procedures for validating the Applicant’s ownership or control of an IP Address listed in a Certificate. +This section defines the permitted processes and procedures for validating the Applicant's ownership or control of an IP Address listed in a Certificate. The CA SHALL confirm that prior to issuance, the CA has validated each IP Address listed in the Certificate using at least one of the methods specified in this section. @@ -1067,7 +1067,7 @@ The Random Value SHALL remain valid for use in a confirming response for no more ##### 3.2.2.5.3 Reverse Address Lookup -Confirming the Applicant’s control over the IP Address by obtaining a Domain Name associated with the IP Address through a reverse-IP lookup on the IP Address and then verifying control over the FQDN using a method permitted under [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). +Confirming the Applicant's control over the IP Address by obtaining a Domain Name associated with the IP Address through a reverse-IP lookup on the IP Address and then verifying control over the FQDN using a method permitted under [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same FQDN as the Primary Network Perspective. @@ -1079,7 +1079,7 @@ CAs SHALL NOT perform validations using this method after July 31, 2019. Complet ##### 3.2.2.5.5 Phone Contact with IP Address Contact -Confirming the Applicant's control over the IP Address by calling the IP Address Contact’s phone number and obtaining a response confirming the Applicant's request for validation of the IP Address. The CA MUST place the call to a phone number identified by the IP Address Registration Authority as the IP Address Contact. Each phone call SHALL be made to a single number. +Confirming the Applicant's control over the IP Address by calling the IP Address Contact's phone number and obtaining a response confirming the Applicant's request for validation of the IP Address. The CA MUST place the call to a phone number identified by the IP Address Registration Authority as the IP Address Contact. Each phone call SHALL be made to a single number. In the event that someone other than an IP Address Contact is reached, the CA MAY request to be transferred to the IP Address Contact. @@ -1787,7 +1787,7 @@ The CA SHALL verify that the Delegated Third Party's personnel involved in the i ### 5.4.1 Types of events recorded -The CA and each Delegated Third Party SHALL record events related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems. The CA and each Delegated Third Party SHALL record events related to their actions taken to process a certificate request and to issue a Certificate, including all information generated and documentation received in connection with the certificate request; the time and date; and the personnel involved. The CA SHALL make these records available to its Qualified Auditor as proof of the CA’s compliance with these Requirements. +The CA and each Delegated Third Party SHALL record events related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems. The CA and each Delegated Third Party SHALL record events related to their actions taken to process a certificate request and to issue a Certificate, including all information generated and documentation received in connection with the certificate request; the time and date; and the personnel involved. The CA SHALL make these records available to its Qualified Auditor as proof of the CA's compliance with these Requirements. The CA SHALL record at least the following events: @@ -1942,7 +1942,7 @@ The CA's mass revocation plan MUST include clearly defined, actionable, and comp Mass revocation provisions MUST include: -1. Activation criteria – specific, objective, and measurable thresholds at which the mass revocation plan is triggered based on the CA’s risk profile, issuance volumes, and operational capabilities; +1. Activation criteria – specific, objective, and measurable thresholds at which the mass revocation plan is triggered based on the CA's risk profile, issuance volumes, and operational capabilities; 2. Customer contact information – how subscriber and customer contact details are stored, maintained, and kept up to date; 3. Automation points – processes that are automated or could be automated, and those processes that require manual intervention; 4. Targets and timelines – for incident triage, revocation initiation, certificate replacement, and post-event review; @@ -2005,7 +2005,7 @@ The CA SHALL reject a certificate request if one or more of the following condit 5. The Public Key corresponds to an industry-demonstrated weak Private Key. For requests submitted on or after November 15, 2024, at least the following precautions SHALL be implemented: 1. In the case of Debian weak keys vulnerability (), the CA SHALL reject all keys found at for each key type (e.g. RSA, ECDSA) and size listed in the repository. For all other keys meeting the requirements of [Section 6.1.5](#615-key-sizes), with the exception of RSA key sizes greater than 8192 bits, the CA SHALL reject Debian weak keys. 2. In the case of ROCA vulnerability, the CA SHALL reject keys identified by the tools available at or equivalent. - 3. In the case of Close Primes vulnerability (), the CA SHALL reject weak keys which can be factored within 100 rounds using Fermat’s factorization method. + 3. In the case of Close Primes vulnerability (), the CA SHALL reject weak keys which can be factored within 100 rounds using Fermat's factorization method. Suggested tools for checking for weak keys can be found here: @@ -3619,7 +3619,7 @@ Table: CRLReasons | **RFC 5280 reasonCode** | **RFC 5280 reasonCode value** | **Description** | | --- | - | ------ | | unspecified | 0 | Represented by the omission of a reasonCode. MUST be omitted if the CRL entry is for a Certificate not technically capable of causing issuance unless the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to July 15, 2023. | -| keyCompromise | 1 | Indicates that it is known or suspected that the Subscriber’s Private Key has been compromised. | +| keyCompromise | 1 | Indicates that it is known or suspected that the Subscriber's Private Key has been compromised. | | affiliationChanged | 3 | Indicates that the Subject's name or other Subject Identity Information in the Certificate has changed, but there is no cause to suspect that the Certificate's Private Key has been compromised. | | superseded | 4 | Indicates that the Certificate is being replaced because: the Subscriber has requested a new Certificate, the CA has reasonable evidence that the validation of domain authorization or control for any fully‐qualified domain name or IP address in the Certificate should not be relied upon, or the CA has revoked the Certificate for compliance reasons such as the Certificate does not comply with these Baseline Requirements or the CA's CP or CPS. | | cessationOfOperation | 5 | Indicates that the website with the Certificate is shut down prior to the expiration of the Certificate, or if the Subscriber no longer owns or controls the Domain Name in the Certificate prior to the expiration of the Certificate. | @@ -3873,7 +3873,7 @@ The Subscriber Agreement or Terms of Use MUST contain provisions imposing on the 5. **Reporting and Revocation**: An obligation and warranty to: - a. promptly request revocation of the Certificate, and cease using it and its associated Private Key, if there is any actual or suspected misuse or compromise of the Subscriber’s Private Key associated with the Public Key included in the Certificate, and + a. promptly request revocation of the Certificate, and cease using it and its associated Private Key, if there is any actual or suspected misuse or compromise of the Subscriber's Private Key associated with the Public Key included in the Certificate, and b. promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate; 6. **Termination of Use of Certificate**: An obligation and warranty to promptly cease all use of the Private Key corresponding to the Public Key included in the Certificate upon revocation of that Certificate for reasons of Key Compromise. @@ -3996,7 +3996,7 @@ This appendix defines permissible verification procedures for including one or m 1. The Domain Name MUST contain at least two Domain Labels, where the rightmost Domain Label is "onion", and the Domain Label immediately preceding the rightmost "onion" Domain Label is a valid Version 3 Onion Address, as defined in Section 6 of the Tor Rendezvous Specification - Version 3 located at . -2. The CA MUST verify the Applicant’s control over the Onion Domain Name using at least one of the methods listed below: +2. The CA MUST verify the Applicant's control over the Onion Domain Name using at least one of the methods listed below: 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): diff --git a/docs/EVG.md b/docs/EVG.md index 3870cec9..80922085 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -1522,13 +1522,13 @@ State or province (where applicable): `subject:stateOrProvinceName` (OID: 2.5.4. Country: `subject:countryName` (OID: 2.5.4.6) Postal code: `subject:postalCode` (OID: 2.5.4.17) **Required/Optional**: Required/Optional -**Contents**: These fields MUST contain the verified physical address of the Subject’s Place of Business. +**Contents**: These fields MUST contain the verified physical address of the Subject's Place of Business. The `countryName` field MUST be present and MUST contain the applicable two-letter ISO 3166-1 country code. If the country is not represented by an official ISO 3166-1 code, the ISO 3166-1 user-assigned code "XX" MUST be used. The `localityName` and `stateOrProvinceName` fields are OPTIONAL, but at least one of them MUST be present. When included, these fields MUST accurately represent the locality and/or state or province information verified in accordance with Section 3.2.2.1 of the Baseline Requirements. -The `streetAddress` and `postalCode` fields are OPTIONAL. If present, they MUST contain the verified street address and postal information of the Subject’s Place of Business as required by Section 3.2.2.1 of the Baseline Requirements. Multiple `streetAddress` attributes MAY be present. +The `streetAddress` and `postalCode` fields are OPTIONAL. If present, they MUST contain the verified street address and postal information of the Subject's Place of Business as required by Section 3.2.2.1 of the Baseline Requirements. Multiple `streetAddress` attributes MAY be present. ##### 7.1.4.2.7 Subject Organizational Unit Name Field @@ -1566,7 +1566,7 @@ Registration Schemes listed in [Appendix H](#appendix-h--registration-schemes) a The CA SHALL: -1. confirm that the organization represented by the Registration Reference is the same as the organization named in the `organizationName` field as specified in [Section 7.1.4.2.1](#71421-subject-organization-name-field) within the context of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field); +1. confirm that the organization represented by the Registration Reference is the same as the organization named in the `organizationName` field as specified in [Section 7.1.4.2.1](#71421-subject-organization-name-field) within the context of the subject's jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field); 2. further verify the Registration Reference matches other information verified in accordance with [Section 3.2](#32-initial-identity-validation); 3. take appropriate measures to disambiguate between different organizations as described in [Appendix H](#appendix-h--registration-schemes) for each Registration Scheme; 4. Apply the validation rules relevant to the Registration Scheme as specified in [Appendix H](#appendix-h--registration-schemes). @@ -1603,9 +1603,9 @@ Each EV Certificate issued by the CA to a Subscriber MUST contain a policy ident 1. indicates which CA policy statement relates to that Certificate, 2. asserts the CA's adherence to and compliance with these Guidelines, and -3. is either the CA/Browser Forum’s EV policy identifier or a policy identifier that, by pre-agreement with the Application Software Supplier, marks the Certificate as being an EV Certificate. +3. is either the CA/Browser Forum's EV policy identifier or a policy identifier that, by pre-agreement with the Application Software Supplier, marks the Certificate as being an EV Certificate. -The following Certificate Policy identifier is the CA/Browser Forum’s EV policy identifier: +The following Certificate Policy identifier is the CA/Browser Forum's EV policy identifier: `{joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140) certificate‐policies(1) ev-guidelines (1) } (2.23.140.1.1)`, if the Certificate complies with these Guidelines. #### 7.1.6.2 Root CA Certificates @@ -2110,14 +2110,14 @@ The following Registration Schemes are currently recognized as valid under these - **NTR**: - The information carried in this field shall be the same as held in Subject Registration Number Field as specified in [Section 7.1.4.2.5](#71425-subject-registration-number-field) and the country code used in the Registration Scheme identifier shall match that of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). + The information carried in this field shall be the same as held in Subject Registration Number Field as specified in [Section 7.1.4.2.5](#71425-subject-registration-number-field) and the country code used in the Registration Scheme identifier shall match that of the subject's jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). Where the Subject Jurisdiction of Incorporation or Registration Field in 9.2.4 includes more than the country code, the additional locality information shall be included as specified in [Section 7.1.4.2.8](#71428-subject-organization-identifier-field) and/or [Section 7.1.2.2](#7122-cabrowser-forum-organization-identifier-extension). - **VAT**: - Reference allocated by the national tax authorities to a Legal Entity. This information shall be validated using information provided by the national tax authority against the organization as identified by the Subject Organization Name Field (see [Section 7.1.4.2.1](#71421-subject-organization-name-field)) and Subject Registration Number Field (see [Section 7.1.4.2.5](#71425-subject-registration-number-field)) within the context of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). For the purpose of identifying tax authorities, the country prefix described in article 215 of EU Council Directive 2006/112/EC, as amended, MAY be used instead of the ISO 3166 2-letter country codes. + Reference allocated by the national tax authorities to a Legal Entity. This information shall be validated using information provided by the national tax authority against the organization as identified by the Subject Organization Name Field (see [Section 7.1.4.2.1](#71421-subject-organization-name-field)) and Subject Registration Number Field (see [Section 7.1.4.2.5](#71425-subject-registration-number-field)) within the context of the subject's jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). For the purpose of identifying tax authorities, the country prefix described in article 215 of EU Council Directive 2006/112/EC, as amended, MAY be used instead of the ISO 3166 2-letter country codes. - **PSD**: - Authorization number as specified in ETSI TS 119 495 clause 4.4 allocated to a payment service provider and containing the information as specified in ETSI TS 119 495 clause 5.2.1. This information SHALL be obtained directly from the national competent authority register for payment services or from an information source approved by a government agency, regulatory body, or legislation for this purpose. This information SHALL be validated by being matched directly or indirectly (for example, by matching a globally unique registration number) against the organization as identified by the Subject Organization Name Field (see [Section 7.1.4.2.1](#71421-subject-organization-name-field)) and Subject Registration Number Field (see [Section 7.1.4.2.5](#71425-subject-registration-number-field)) within the context of the subject’s jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). The stated address of the organization combined with the organization name SHALL NOT be the only information used to disambiguate the organization. + Authorization number as specified in ETSI TS 119 495 clause 4.4 allocated to a payment service provider and containing the information as specified in ETSI TS 119 495 clause 5.2.1. This information SHALL be obtained directly from the national competent authority register for payment services or from an information source approved by a government agency, regulatory body, or legislation for this purpose. This information SHALL be validated by being matched directly or indirectly (for example, by matching a globally unique registration number) against the organization as identified by the Subject Organization Name Field (see [Section 7.1.4.2.1](#71421-subject-organization-name-field)) and Subject Registration Number Field (see [Section 7.1.4.2.5](#71425-subject-registration-number-field)) within the context of the subject's jurisdiction as specified in [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field). The stated address of the organization combined with the organization name SHALL NOT be the only information used to disambiguate the organization. From ad2c32110884621b6d9188176f7eeedb5d4410b3 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 2 Dec 2025 00:23:52 +0100 Subject: [PATCH 095/121] #432 OID notation standard --- docs/BR.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 93b30b4f..7cb6e5c0 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -3480,17 +3480,17 @@ Table: Encoding and Order Requirements for Selected Attributes | **Attribute** | **OID** | **Specification** | **Encoding Requirements** | **Max Length\*** | | ---- | -- | --- | ---- | - | -| `domainComponent` | `0.9.2342.19200300.100.1.25` | [RFC 4519](https://tools.ietf.org/html/rfc4519) | MUST use `IA5String` | 63 | -| `countryName` | `2.5.4.6` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 2 | -| `stateOrProvinceName` | `2.5.4.8` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | -| `localityName` | `2.5.4.7` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | -| `postalCode` | `2.5.4.17` | X.520 | MUST use `UTF8String` or `PrintableString` | 40 | -| `streetAddress` | `2.5.4.9` | X.520 | MUST use `UTF8String` or `PrintableString` | 128 | -| `organizationName` | `2.5.4.10` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | -| `surname` | `2.5.4.4` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64[^surname_givenname] | -| `givenName` | `2.5.4.42` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64[^surname_givenname] | -| `organizationalUnitName` | `2.5.4.11` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | -| `commonName` | `2.5.4.3` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | +| `domainComponent` | 0.9.2342.19200300.100.1.25 | [RFC 4519](https://tools.ietf.org/html/rfc4519) | MUST use `IA5String` | 63 | +| `countryName` | 2.5.4.6 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 2 | +| `stateOrProvinceName` | 2.5.4.8 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | +| `localityName` | 2.5.4.7 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | +| `postalCode` | 2.5.4.17 | X.520 | MUST use `UTF8String` or `PrintableString` | 40 | +| `streetAddress` | 2.5.4.9 | X.520 | MUST use `UTF8String` or `PrintableString` | 128 | +| `organizationName` | 2.5.4.10 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | +| `surname` | 2.5.4.4 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64[^surname_givenname] | +| `givenName` | 2.5.4.42 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64[^surname_givenname] | +| `organizationalUnitName` | 2.5.4.11 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | +| `commonName` | 2.5.4.3 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | \* **Note**: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits. @@ -3502,12 +3502,12 @@ Table: Encoding Requirements for Selected Attributes | **Attribute** | **OID** | **Specification** | **Encoding Requirements** | **Max Length\*** | | ---- | -- | --- | ---- | - | -| `businessCategory` | `2.5.4.15` | X.520 | MUST use `UTF8String` or `PrintableString` | 128 | -| `jurisdictionCountry` | `1.3.6.1.4.1.311.60.2.1.3` | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `PrintableString` | 2 | -| `jurisdictionStateOrProvince` | `1.3.6.1.4.1.311.60.2.1.2` | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `UTF8String` or `PrintableString` | 128 | -| `jurisdictionLocality` | `1.3.6.1.4.1.311.60.2.1.1` | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `UTF8String` or `PrintableString` | 128 | -| `serialNumber` | `2.5.4.5` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 64 | -| `organizationIdentifier` | `2.5.4.97` | X.520 | MUST use `UTF8String` or `PrintableString` | None | +| `businessCategory` | 2.5.4.15 | X.520 | MUST use `UTF8String` or `PrintableString` | 128 | +| `jurisdictionCountry` | 1.3.6.1.4.1.311.60.2.1.3 | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `PrintableString` | 2 | +| `jurisdictionStateOrProvince` | 1.3.6.1.4.1.311.60.2.1.2 | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `UTF8String` or `PrintableString` | 128 | +| `jurisdictionLocality` | 1.3.6.1.4.1.311.60.2.1.1 | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `UTF8String` or `PrintableString` | 128 | +| `serialNumber` | 2.5.4.5 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 64 | +| `organizationIdentifier` | 2.5.4.97 | X.520 | MUST use `UTF8String` or `PrintableString` | None | \* **Note**: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits. From 36bc9d56686a07e1a0c45cb5d6980efbfe6d27cf Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 2 Dec 2025 00:32:45 +0100 Subject: [PATCH 096/121] #432 Maximum to Max to fix width --- docs/BR.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 7cb6e5c0..f6f17c29 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2785,8 +2785,8 @@ The `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. E The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. -| **Access Method** | **OID** | **Access Location** | **Presence** | **Maximum** | **Description** | -| -- | -- | --- | -- | -- | --- | +| **Access Method** | **OID** | **Access Location** | **Presence** | **Max** | **Description** | +| -- | -- | --- | -- | - | --- | | `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. | | `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | SHOULD | \* | A HTTP URL of the Issuing CA's certificate. | | Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | @@ -2944,7 +2944,7 @@ For OCSP Responder certificates, this extension is NOT RECOMMENDED, as the Relyi If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `AuthorityInfoAccessSyntax` MUST contain all required `AccessDescription`s. -| **Access Method** | **OID** | **Access Location** | **Presence** | **Maximum** | **Description** | +| **Access Method** | **OID** | **Access Location** | **Presence** | **Max** | **Description** | | - | - | -- | -- | - | --- | | `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | NOT RECOMMENDED | \* | A HTTP URL of the Issuing CA's OCSP responder. | | Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | @@ -3137,7 +3137,7 @@ If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDesc The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. -| **Access Method** | **OID** | **Access Location** | **Presence** | **Maximum** | **Description** | +| **Access Method** | **OID** | **Access Location** | **Presence** | **Max** | **Description** | | - | - | --- | - | - | --- | | `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. | | `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's certificate. | From ee0e509363b287f015d96058426bd67c8d707701 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 2 Dec 2025 00:44:59 +0100 Subject: [PATCH 097/121] #432 1.3.6.1.5.5.7.48 merge columns Access Method and OID --- docs/BR.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index f6f17c29..f0b8b5f7 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2785,11 +2785,11 @@ The `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. E The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. -| **Access Method** | **OID** | **Access Location** | **Presence** | **Max** | **Description** | -| -- | -- | --- | -- | - | --- | -| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. | -| `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | SHOULD | \* | A HTTP URL of the Issuing CA's certificate. | -| Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | +| **Access Method** | **Access Location** | **Presence** | **Maximum** | **Description** | +| -- | -- | --- | -- | -- | --- | +| `id-ad-ocsp` OID (1.3.6.1.5.5.7.48.1) | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. | +| `id-ad-caIssuers` OID (1.3.6.1.5.5.7.48.2) | `uniformResourceIdentifier` | SHOULD | \* | A HTTP URL of the Issuing CA's certificate. | +| Any other value | - | MUST NOT | - | No other `accessMethod`s may be used. | ##### 7.1.2.7.8 Subscriber Certificate Basic Constraints @@ -2944,10 +2944,10 @@ For OCSP Responder certificates, this extension is NOT RECOMMENDED, as the Relyi If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `AuthorityInfoAccessSyntax` MUST contain all required `AccessDescription`s. -| **Access Method** | **OID** | **Access Location** | **Presence** | **Max** | **Description** | -| - | - | -- | -- | - | --- | -| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | NOT RECOMMENDED | \* | A HTTP URL of the Issuing CA's OCSP responder. | -| Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | +| **Access Method** | **Access Location** | **Presence** | **Maximum** | **Description** | +| - | -- | -- | - | --- | +| `id-ad-ocsp` (OID: 1.3.6.1.5.5.7.48.1) | `uniformResourceIdentifier` | NOT RECOMMENDED | \* | A HTTP URL of the Issuing CA's OCSP responder. | +| Any other value | - | MUST NOT | - | No other `accessMethod`s may be used. | ##### 7.1.2.8.4 OCSP Responder Basic Constraints @@ -3137,11 +3137,11 @@ If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDesc The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. -| **Access Method** | **OID** | **Access Location** | **Presence** | **Max** | **Description** | -| - | - | --- | - | - | --- | -| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. | -| `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's certificate. | -| Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | +| **Access Method** | **Access Location** | **Presence** | **Maximum** | **Description** | +| - | --- | - | - | --- | +| `id-ad-ocsp` (OID: 1.3.6.1.5.5.7.48.1) | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. | +| `id-ad-caIssuers` (OID: 1.3.6.1.5.5.7.48.2) | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's certificate. | +| Any other value | - | MUST NOT | - | No other `accessMethod`s may be used. | ##### 7.1.2.10.4 CA Certificate Basic Constraints From 8a8470b9a07eae58ea9db57b96d77a50c79ca0d2 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 2 Dec 2025 00:49:48 +0100 Subject: [PATCH 098/121] #432 Access Method and OID table spacing --- docs/BR.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index f0b8b5f7..b5770c58 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2785,11 +2785,11 @@ The `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. E The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. -| **Access Method** | **Access Location** | **Presence** | **Maximum** | **Description** | -| -- | -- | --- | -- | -- | --- | -| `id-ad-ocsp` OID (1.3.6.1.5.5.7.48.1) | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. | -| `id-ad-caIssuers` OID (1.3.6.1.5.5.7.48.2) | `uniformResourceIdentifier` | SHOULD | \* | A HTTP URL of the Issuing CA's certificate. | -| Any other value | - | MUST NOT | - | No other `accessMethod`s may be used. | +| **Access Method** | **Access Location** | **Presence** | **Maximum** | **Description** | +| - | ---- | - | - | --- | +| `id-ad-ocsp` (OID: 1.3.6.1.5.5.7.48.1) | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. | +| `id-ad-caIssuers` (OID: 1.3.6.1.5.5.7.48.2) | `uniformResourceIdentifier` | SHOULD | \* | A HTTP URL of the Issuing CA's certificate. | +| Any other value | - | MUST NOT | - | No other `accessMethod`s may be used. | ##### 7.1.2.7.8 Subscriber Certificate Basic Constraints @@ -2944,8 +2944,8 @@ For OCSP Responder certificates, this extension is NOT RECOMMENDED, as the Relyi If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `AuthorityInfoAccessSyntax` MUST contain all required `AccessDescription`s. -| **Access Method** | **Access Location** | **Presence** | **Maximum** | **Description** | -| - | -- | -- | - | --- | +| **Access Method** | **Access Location** | **Presence** | **Maximum** | **Description** | +| - | ---- | - | - | --- | | `id-ad-ocsp` (OID: 1.3.6.1.5.5.7.48.1) | `uniformResourceIdentifier` | NOT RECOMMENDED | \* | A HTTP URL of the Issuing CA's OCSP responder. | | Any other value | - | MUST NOT | - | No other `accessMethod`s may be used. | @@ -3138,7 +3138,7 @@ If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDesc The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. | **Access Method** | **Access Location** | **Presence** | **Maximum** | **Description** | -| - | --- | - | - | --- | +| - | ---- | - | - | --- | | `id-ad-ocsp` (OID: 1.3.6.1.5.5.7.48.1) | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. | | `id-ad-caIssuers` (OID: 1.3.6.1.5.5.7.48.2) | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's certificate. | | Any other value | - | MUST NOT | - | No other `accessMethod`s may be used. | From 16721b974f0e175a0242062e6bb4632d1934ea01 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 2 Dec 2025 00:52:44 +0100 Subject: [PATCH 099/121] #432 Access Method and OID table spacing --- docs/BR.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index b5770c58..667c6aa6 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2786,7 +2786,7 @@ The `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. E The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. | **Access Method** | **Access Location** | **Presence** | **Maximum** | **Description** | -| - | ---- | - | - | --- | +| --- | ---- | - | - | --- | | `id-ad-ocsp` (OID: 1.3.6.1.5.5.7.48.1) | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. | | `id-ad-caIssuers` (OID: 1.3.6.1.5.5.7.48.2) | `uniformResourceIdentifier` | SHOULD | \* | A HTTP URL of the Issuing CA's certificate. | | Any other value | - | MUST NOT | - | No other `accessMethod`s may be used. | @@ -2945,7 +2945,7 @@ For OCSP Responder certificates, this extension is NOT RECOMMENDED, as the Relyi If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `AuthorityInfoAccessSyntax` MUST contain all required `AccessDescription`s. | **Access Method** | **Access Location** | **Presence** | **Maximum** | **Description** | -| - | ---- | - | - | --- | +| --- | ---- | - | - | --- | | `id-ad-ocsp` (OID: 1.3.6.1.5.5.7.48.1) | `uniformResourceIdentifier` | NOT RECOMMENDED | \* | A HTTP URL of the Issuing CA's OCSP responder. | | Any other value | - | MUST NOT | - | No other `accessMethod`s may be used. | @@ -3138,7 +3138,7 @@ If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDesc The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. | **Access Method** | **Access Location** | **Presence** | **Maximum** | **Description** | -| - | ---- | - | - | --- | +| --- | ---- | - | - | --- | | `id-ad-ocsp` (OID: 1.3.6.1.5.5.7.48.1) | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's OCSP responder. | | `id-ad-caIssuers` (OID: 1.3.6.1.5.5.7.48.2) | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's certificate. | | Any other value | - | MUST NOT | - | No other `accessMethod`s may be used. | From 366829014f7f20a71e024d8958270036b160661c Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 2 Dec 2025 19:43:08 +0100 Subject: [PATCH 100/121] #193 date format YYYY-MM-DD --- docs/BR.md | 87 +++++++++++++++++++++++++++--------------------------- 1 file changed, 43 insertions(+), 44 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 667c6aa6..7250c626 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -21,7 +21,7 @@ This document describes an integrated set of technologies, protocols, identity-p **Notice to Readers** -The CP for the Issuance and Management of Publicly-Trusted TLS Server Certificates describe a subset of the requirements that a Certification Authority must meet in order to issue Publicly Trusted TLS Server Certificates. This document serves two purposes: to specify Baseline Requirements and to provide guidance and requirements for what a CA should include in its CPS. Except where explicitly stated otherwise, these Requirements apply only to relevant events that occur on or after 1 July 2012 (the original effective date of these requirements). +The CP for the Issuance and Management of Publicly-Trusted TLS Server Certificates describe a subset of the requirements that a Certification Authority must meet in order to issue Publicly Trusted TLS Server Certificates. This document serves two purposes: to specify Baseline Requirements and to provide guidance and requirements for what a CA should include in its CPS. Except where explicitly stated otherwise, these Requirements apply only to relevant events that occur on or after 2012-07-01 (the original effective date of these requirements). These Requirements do not address all of the issues relevant to the issuance and management of Publicly-Trusted TLS Server Certificates. In accordance with RFC 3647 and to facilitate a comparison of other certificate policies and CPSs (e.g. for policy mapping), this document includes all sections of the RFC 3647 framework. However, rather than beginning with a "no stipulation" comment in all empty sections, the CA/Browser Forum is leaving such sections initially blank until a decision of "no stipulation" is made. The CA/Browser Forum may update these Requirements from time to time, in order to address both existing and emerging threats to online security. In particular, it is expected that a future version will contain more formal and comprehensive audit requirements for delegated functions. @@ -468,7 +468,7 @@ The script outputs: **Root Certificate**: The self-signed Certificate issued by the Root CA to identify itself and to facilitate verification of Certificates issued to its Subordinate CAs. -**Short-lived Subscriber Certificate**: For Certificates issued on or after 15 March 2024 and prior to 15 March 2026, a Subscriber Certificate with a Validity Period less than or equal to 10 days (864,000 seconds). For Certificates issued on or after 15 March 2026, a Subscriber Certificate with a Validity Period less than or equal to 7 days (604,800 seconds). +**Short-lived Subscriber Certificate**: For Certificates issued on or after 2024-03-15 and prior to 2026-03-15, a Subscriber Certificate with a Validity Period less than or equal to 10 days (864,000 seconds). For Certificates issued on or after 2026-03-15, a Subscriber Certificate with a Validity Period less than or equal to 7 days (604,800 seconds). **Sovereign State**: A state or country that administers its own government, and is not dependent upon, or subject to, another power. @@ -718,14 +718,14 @@ The CA SHALL confirm that prior to issuance, the CA has validated each Fully-Qua Completed validations of Applicant authority may be valid for the issuance of multiple Certificates over time. In all cases, the validation must have been initiated within the time period specified in the relevant requirement (such as [Section 4.2.1](#421-performing-identification-and-authentication-functions) of this document) prior to Certificate issuance. For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate. -Effective March 15th, 2026: DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective MUST: +Effective 2026-03-15: DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective MUST: - perform DNSSEC validation using the algorithm defined in [RFC 4035 Section 5](https://datatracker.ietf.org/doc/html/rfc4035#section-5); and - support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and - support SHA-2 as defined in [RFC 4509](https://datatracker.ietf.org/doc/html/rfc4509) and [RFC 5702](https://datatracker.ietf.org/doc/html/rfc5702); and - properly handle the security concerns enumerated in [RFC 6840 Section 4](https://datatracker.ietf.org/doc/html/rfc6840#section-4). -Effective March 15th, 2026: CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. +Effective 2026-03-15: CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. DNSSEC validation back to the IANA DNSSEC root trust anchor MAY be performed on all DNS queries associated with the validation of domain authorization or control by Remote Network Perspectives used for Multi-Perspective Issuance Corroboration. @@ -754,7 +754,7 @@ The Random Value SHALL remain valid for use in a confirming response for no more **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. -Effective January 15, 2025: +Effective 2025-01-15: - When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. - When obtaining Domain Contact information for a requested Domain Name the CA: @@ -762,7 +762,7 @@ Effective January 15, 2025: - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. -Effective July 15, 2025: +Effective 2025-07-15: - The CA MUST NOT rely on this method. - Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates. @@ -841,7 +841,7 @@ Confirming the Applicant's control over the FQDN by validating the Applicant is **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. -Effective January 15, 2025: +Effective 2025-01-15: - When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. - When obtaining Domain Contact information for a requested Domain Name the CA: @@ -885,7 +885,7 @@ The Random Value SHALL remain valid for use in a confirming response for no more **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. -Effective January 15, 2025: +Effective 2025-01-15: - When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. - When obtaining Domain Contact information for a requested Domain Name the CA: @@ -893,7 +893,7 @@ Effective January 15, 2025: - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. -Effective July 15, 2025: +Effective 2025-07-15: - The CA MUST NOT rely on this method. - Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates. @@ -943,8 +943,8 @@ The file containing the Request Token or Random Value: If the CA follows redirects, the following apply: 1. Redirects MUST be initiated at the HTTP protocol layer. - a. For validations performed on or after July 1, 2021, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4), or a 308 HTTP status code response, as defined in [RFC 7538, Section 3](https://tools.ietf.org/html/rfc7538#section-3). Redirects MUST be to the final value of the Location HTTP response header, as defined in [RFC 7231, Section 7.1.2](https://tools.ietf.org/html/rfc7231#section-7.1.2). - b. For validations performed prior to July 1, 2021, redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4). CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a. + a. For validations performed on or after 2021-07-01, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4), or a 308 HTTP status code response, as defined in [RFC 7538, Section 3](https://tools.ietf.org/html/rfc7538#section-3). Redirects MUST be to the final value of the Location HTTP response header, as defined in [RFC 7231, Section 7.1.2](https://tools.ietf.org/html/rfc7231#section-7.1.2). + b. For validations performed prior to 2021-07-01, redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4). CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a. 2. Redirects MUST be to resource URLs with either the "http" or "https" scheme. 3. Redirects MUST be to resource URLs accessed via Authorized Ports. @@ -968,8 +968,8 @@ The token (as defined in RFC 8555, Section 8.3) MUST NOT be used for more than 3 If the CA follows redirects, the following apply: 1. Redirects MUST be initiated at the HTTP protocol layer. - a. For validations performed on or after July 1, 2021, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4), or a 308 HTTP status code response, as defined in [RFC 7538, Section 3](https://tools.ietf.org/html/rfc7538#section-3). Redirects MUST be to the final value of the Location HTTP response header, as defined in [RFC 7231, Section 7.1.2](https://tools.ietf.org/html/rfc7231#section-7.1.2). - b. For validations performed prior to July 1, 2021, redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4). CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a. + a. For validations performed on or after 2021-07-01, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4), or a 308 HTTP status code response, as defined in [RFC 7538, Section 3](https://tools.ietf.org/html/rfc7538#section-3). Redirects MUST be to the final value of the Location HTTP response header, as defined in [RFC 7231, Section 7.1.2](https://tools.ietf.org/html/rfc7231#section-7.1.2). + b. For validations performed prior to 2021-07-01, redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4). CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a. 2. Redirects MUST be to resource URLs with either the "http" or "https" scheme. 3. Redirects MUST be to resource URLs accessed via Authorized Ports. @@ -1038,7 +1038,7 @@ The CA SHALL confirm that prior to issuance, the CA has validated each IP Addres Completed validations of Applicant authority may be valid for the issuance of multiple Certificates over time. In all cases, the validation must have been initiated within the time period specified in the relevant requirement (such as [Section 4.2.1](#421-performing-identification-and-authentication-functions) of this document) prior to Certificate issuance. For purposes of IP Address validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate. -After July 31, 2019, CAs SHALL maintain a record of which IP validation method, including the relevant BR version number, was used to validate every IP Address. +After 2019-07-31, CAs SHALL maintain a record of which IP validation method, including the relevant BR version number, was used to validate every IP Address. ##### 3.2.2.5.1 Agreed-Upon Change to Website @@ -1075,7 +1075,7 @@ CAs performing validations using this method MUST implement Multi-Perspective Is Using any other method of confirmation, including variations of the methods defined in [Section 3.2.2.5](#3225-authentication-for-an-ip-address), provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant has control over the IP Address to at least the same level of assurance as the methods previously described in version 1.6.2 of these Requirements. -CAs SHALL NOT perform validations using this method after July 31, 2019. Completed validations using this method SHALL NOT be re-used for certificate issuance after July 31, 2019. Any certificate issued prior to August 1, 2019 containing an IP Address that was validated using any method that was permitted under the prior version of this [Section 3.2.2.5](#3225-authentication-for-an-ip-address) MAY continue to be used without revalidation until such certificate naturally expires. +CAs SHALL NOT perform validations using this method after 2019-07-31. Completed validations using this method SHALL NOT be re-used for certificate issuance after 2019-07-31. Any certificate issued prior to 2019-08-01 containing an IP Address that was validated using any method that was permitted under the prior version of this [Section 3.2.2.5](#3225-authentication-for-an-ip-address) MAY continue to be used without revalidation until such certificate naturally expires. ##### 3.2.2.5.5 Phone Contact with IP Address Contact @@ -1149,16 +1149,16 @@ CAs MUST document potential issuances that were prevented by a CAA record in suf ##### 3.2.2.8.1 DNSSEC Validation of CAA Records -Effective March 15th, 2026: DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with CAA record lookups performed by the Primary Network Perspective MUST: +Effective 2026-03-15: DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with CAA record lookups performed by the Primary Network Perspective MUST: - perform DNSSEC validation using the algorithm defined in [RFC 4035 Section 5](https://datatracker.ietf.org/doc/html/rfc4035#section-5); and - support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and - support SHA-2 as defined in [RFC 4509](https://datatracker.ietf.org/doc/html/rfc4509) and [RFC 5702](https://datatracker.ietf.org/doc/html/rfc5702); and - properly handle the security concerns enumerated in [RFC 6840 Section 4](https://datatracker.ietf.org/doc/html/rfc6840#section-4). -Effective March 15th, 2026: CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. +Effective 2026-03-15: CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. -Effective March 15th, 2026: DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. +Effective 2026-03-15: DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. DNSSEC validation back to the IANA DNSSEC root trust anchor MAY be performed on all DNS queries associated with CAA record lookups performed by Remote Network Perspectives as part of Multi-Perspective Issuance Corroboration. @@ -1233,17 +1233,17 @@ If any of the above considerations are performed by a Delegated Third Party, the Phased Implementation Timeline: -- Effective September 15, 2024, the CA SHOULD implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. +- Effective 2024-09-15, the CA SHOULD implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. -- Effective March 15, 2025, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MAY proceed with certificate issuance if the number of remote Network Perspectives that do not corroborate the determinations made by the Primary Network Perspective ("non-corroborations") is greater than allowed in the Quorum Requirements table. +- Effective 2025-03-15, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MAY proceed with certificate issuance if the number of remote Network Perspectives that do not corroborate the determinations made by the Primary Network Perspective ("non-corroborations") is greater than allowed in the Quorum Requirements table. -- Effective September 15, 2025, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. +- Effective 2025-09-15, the CA MUST implement Multi-Perspective Issuance Corroboration using at least two (2) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. -- Effective March 15, 2026, the CA MUST implement Multi-Perspective Issuance Corroboration using at least three (3) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. +- Effective 2026-03-15, the CA MUST implement Multi-Perspective Issuance Corroboration using at least three (3) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. -- Effective June 15, 2026, the CA MUST implement Multi-Perspective Issuance Corroboration using at least four (4) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. +- Effective 2026-06-15, the CA MUST implement Multi-Perspective Issuance Corroboration using at least four (4) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. -- Effective December 15, 2026, the CA MUST implement Multi-Perspective Issuance Corroboration using at least five (5) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. +- Effective 2026-12-15, the CA MUST implement Multi-Perspective Issuance Corroboration using at least five (5) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate. ### 3.2.3 Authentication of individual identity @@ -1314,8 +1314,8 @@ Table: Subject Identity Information validation data reuse periods | **Certificate issued on or after** | **Certificate issued before** | **Maximum data reuse period** | | -- | -- | -- | -| | March 15, 2026 | 825 days | -| March 15, 2026 | | 398 days | +| | 2026-03-15 | 825 days | +| 2026-03-15 | | 398 days | For validation of Domain Names and IP Addresses according to [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) and [Section 3.2.2.5](#3225-authentication-for-an-ip-address), any data, document, or completed validation used MUST be obtained within the maximum number of days prior to issuing the Certificate, as defined in the following table: @@ -1323,10 +1323,10 @@ Table: Domain Name and IP Address validation data reuse periods | **Certificate issued on or after** | **Certificate issued before** | **Maximum data reuse period** | | -- | -- | -- | -| | March 15, 2026 | 398 days | -| March 15, 2026 | March 15, 2027 | 200 days | -| March 15, 2027 | March 15, 2029 | 100 days | -| March 15, 2029 | | 10 days | +| | 2026-03-15 | 398 days | +| 2026-03-15 | 2027-03-15 | 200 days | +| 2027-03-15 | 2029-03-15 | 100 days | +| 2029-03-15 | | 10 days | 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. @@ -1936,7 +1936,7 @@ The business continuity plan MUST include: #### 5.7.1.2 Mass Revocation Plans -CA organizations MUST have a mass revocation plan, and as of December 1, 2025, they SHALL assert in section 5.7.1 of their CPS or combined CP/CPS that they maintain a comprehensive and actionable plan for mass revocation events, that they perform annual testing of the mass revocation plan, and that they incorporate lessons learned into such plan in order to continually improve their preparedness for mass revocation events over time. +CA organizations MUST have a mass revocation plan, and as of 2025-12-01, they SHALL assert in section 5.7.1 of their CPS or combined CP/CPS that they maintain a comprehensive and actionable plan for mass revocation events, that they perform annual testing of the mass revocation plan, and that they incorporate lessons learned into such plan in order to continually improve their preparedness for mass revocation events over time. The CA's mass revocation plan MUST include clearly defined, actionable, and comprehensive procedures designed to ensure rapid, consistent, and reliable response to large-scale certificate revocation scenarios. The CA is not required to publicly disclose its mass revocation plan or procedures but MUST make them available to its auditors upon request. The CA SHALL annually test, review, and update its plan and such procedures. The CA's mass revocation plan MAY be integrated into the CA's incident response, business continuity, disaster recovery, or other similar plans or procedures, provided that provisions governing mass revocation events remain clearly identifiable and satisfy these requirements. @@ -2002,7 +2002,7 @@ The CA SHALL reject a certificate request if one or more of the following condit 2. There is clear evidence that the specific method used to generate the Private Key was flawed; 3. The CA is aware of a demonstrated or proven method that exposes the Applicant's Private Key to compromise; 4. The CA has previously been notified that the Applicant's Private Key has suffered a Key Compromise using the CA's procedure for revocation request as described in [Section 4.9.3](#493-procedure-for-revocation-request) and [Section 4.9.12](#4912-special-requirements-re-key-compromise); -5. The Public Key corresponds to an industry-demonstrated weak Private Key. For requests submitted on or after November 15, 2024, at least the following precautions SHALL be implemented: +5. The Public Key corresponds to an industry-demonstrated weak Private Key. For requests submitted on or after 2024-11-15, at least the following precautions SHALL be implemented: 1. In the case of Debian weak keys vulnerability (), the CA SHALL reject all keys found at for each key type (e.g. RSA, ECDSA) and size listed in the repository. For all other keys meeting the requirements of [Section 6.1.5](#615-key-sizes), with the exception of RSA key sizes greater than 8192 bits, the CA SHALL reject Debian weak keys. 2. In the case of ROCA vulnerability, the CA SHALL reject keys identified by the tools available at or equivalent. 3. In the case of Close Primes vulnerability (), the CA SHALL reject weak keys which can be factored within 100 rounds using Fermat's factorization method. @@ -2089,22 +2089,21 @@ The CA SHALL protect its Private Key in a system or device that has been validat ### 6.3.2 Certificate operational periods and key pair usage periods -Subscriber Certificates issued before 15 March 2026 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. +Subscriber Certificates issued before 2026-03-15 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. -Subscriber Certificates issued on or after 15 March 2026 and before 15 March 2027 SHOULD NOT have a Validity Period greater than 199 days and MUST NOT have a Validity Period greater than 200 days. +Subscriber Certificates issued on or after 2026-03-15 and before 2027-03-15 SHOULD NOT have a Validity Period greater than 199 days and MUST NOT have a Validity Period greater than 200 days. -Subscriber Certificates issued on or after 15 March 2027 and before 15 March 2029 SHOULD NOT have a Validity Period greater than 99 days and MUST NOT have a Validity Period greater than 100 days. - -Subscriber Certificates issued on or after 15 March 2029 SHOULD NOT have a Validity Period greater than 46 days and MUST NOT have a Validity Period greater than 47 days. +Subscriber Certificates issued on or after 2027-03-15 and before 2029-03-15 SHOULD NOT have a Validity Period greater than 99 days and MUST NOT have a Validity Period greater than 100 days. +Subscriber Certificates issued on or after 2029-03-15 SHOULD NOT have a Validity Period greater than 46 days and MUST NOT have a Validity Period greater than 47 days. Table: Reference for maximum Validity Periods of Subscriber Certificates | **Certificate issued on or after** | **Certificate issued before** | **Maximum Validity Period** | | -- | -- | -- | -| | March 15, 2026 | 398 days | -| March 15, 2026 | March 15, 2027 | 200 days | -| March 15, 2027 | March 15, 2029 | 100 days | -| March 15, 2029 | | 47 days | +| | 2026-03-15 | 398 days | +| 2026-03-15 | 2027-03-15 | 200 days | +| 2027-03-15 | 2029-03-15 | 100 days | +| 2029-03-15 | | 47 days | For the purpose of calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, shall represent an additional day. For this reason, Subscriber Certificates SHOULD NOT be issued for the maximum permissible time by default, in order to account for such adjustments. @@ -2485,7 +2484,7 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | -Effective March 15, 2026: +Effective 2026-03-15: - This Certificate Profile MUST NOT be used. - Precertificate Signing CAs MUST NOT be used to issue Precertificates. @@ -3611,14 +3610,14 @@ Table: crlEntryExtensions Component | **CRL Entry Extension** | **Presence** | **Description** | | --- | -- | ----- | -| `reasonCode` | * | When present (OID 2.5.29.21), MUST NOT be marked critical and MUST indicate the most appropriate reason for revocation of the Certificate.

MUST be present unless the CRL entry is for a Certificate not technically capable of causing issuance and either 1) the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to July 15, 2023 or 2) the reason for revocation (i.e., reasonCode) is unspecified (0).

See the "CRLReasons" table for additional requirements. | +| `reasonCode` | * | When present (OID 2.5.29.21), MUST NOT be marked critical and MUST indicate the most appropriate reason for revocation of the Certificate.

MUST be present unless the CRL entry is for a Certificate not technically capable of causing issuance and either 1) the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to 2023-07-15 or 2) the reason for revocation (i.e., reasonCode) is unspecified (0).

See the "CRLReasons" table for additional requirements. | | Any other value | NOT RECOMMENDED | - | Table: CRLReasons | **RFC 5280 reasonCode** | **RFC 5280 reasonCode value** | **Description** | | --- | - | ------ | -| unspecified | 0 | Represented by the omission of a reasonCode. MUST be omitted if the CRL entry is for a Certificate not technically capable of causing issuance unless the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to July 15, 2023. | +| unspecified | 0 | Represented by the omission of a reasonCode. MUST be omitted if the CRL entry is for a Certificate not technically capable of causing issuance unless the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to 2023-07-15. | | keyCompromise | 1 | Indicates that it is known or suspected that the Subscriber's Private Key has been compromised. | | affiliationChanged | 3 | Indicates that the Subject's name or other Subject Identity Information in the Certificate has changed, but there is no cause to suspect that the Certificate's Private Key has been compromised. | | superseded | 4 | Indicates that the Certificate is being replaced because: the Subscriber has requested a new Certificate, the CA has reasonable evidence that the validation of domain authorization or control for any fully‐qualified domain name or IP address in the Certificate should not be relied upon, or the CA has revoked the Certificate for compliance reasons such as the Certificate does not comply with these Baseline Requirements or the CA's CP or CPS. | From 9cb22436640d83b223a47ad6c293813a015f8ff1 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 2 Dec 2025 19:47:44 +0100 Subject: [PATCH 101/121] #193 date format YYYY-MM-DD --- docs/EVG.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 80922085..3ca93c02 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -97,7 +97,7 @@ These Guidelines do not address the verification of information, or the issuance | 2020-10-01 | [3.2.2.1.3](#32213-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 | [7.1.4.2.7](#71427-subject-organizational-unit-name-field) | CAs MUST NOT include the organizationalUnitName field in the Subject | -**Implementers' Note**: Version 1.3 of these EV Guidelines was published on 20 November 2010 and supplemented through May 2012 when version 1.4 was published. ETSI TS 102 042 and ETSI TR 101 564 Technical Report: Guidance on ETSI TS 102 042 for Issuing Extended Validation Certificates for Auditors and CSPs reference version 1.3 of these EV Guidelines, and ETSI Draft EN 319 411-1 references version 1.4. Version 1.4.5 of Webtrust(r) for Certification Authorities – Extended Validation Audit Criteria references version 1.4.5 of these EV Guidelines. As illustrated in the Document History table above, the CA/Browser Forum continues to improve relevant industry guidelines, including this document, the Baseline Requirements, and the Network and Certificate System Security Requirements. We encourage all CAs to conform to each revision 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. 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. +**Implementers' Note**: Version 1.3 of these EV Guidelines was published on 2010-11-20 and supplemented through 2012-05 when version 1.4 was published. ETSI TS 102 042 and ETSI TR 101 564 Technical Report: Guidance on ETSI TS 102 042 for Issuing Extended Validation Certificates for Auditors and CSPs reference version 1.3 of these EV Guidelines, and ETSI Draft EN 319 411-1 references version 1.4. Version 1.4.5 of Webtrust(r) for Certification Authorities – Extended Validation Audit Criteria references version 1.4.5 of these EV Guidelines. As illustrated in the Document History table above, the CA/Browser Forum continues to improve relevant industry guidelines, including this document, the Baseline Requirements, and the Network and Certificate System Security Requirements. We encourage all CAs to conform to each revision 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. 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. ## 1.3 PKI participants @@ -432,7 +432,7 @@ As a general rule, the CA is responsible for taking all verification steps reaso ##### 3.2.2.1.3 Disclosure of Verification Sources -Effective as of 1 October 2020, prior to the use of an Incorporating Agency or Registration Agency to fulfill these verification requirements, the CA MUST publicly disclose Agency Information about the Incorporating Agency or Registration Agency. This disclosure SHALL be through an appropriate and readily accessible online means. +Effective as of 2020-10-01, prior to the use of an Incorporating Agency or Registration Agency to fulfill these verification requirements, the CA MUST publicly disclose Agency Information about the Incorporating Agency or Registration Agency. This disclosure SHALL be through an appropriate and readily accessible online means. This Agency Information SHALL include at least the following: @@ -1500,7 +1500,7 @@ Country: `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) **Required/Optional**: Required **Contents**: These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. Country information MUST be specified using the applicable ISO country code. State or province or locality information (where applicable) for the Subject's Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction. -Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, the values within these fields have been disclosed within the latest publicly-available disclosure, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), as acceptable values for the applicable Incorporating Agency or Registration Agency. +Effective as of 2020-10-01, the CA SHALL ensure that, at time of issuance, the values within these fields have been disclosed within the latest publicly-available disclosure, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), as acceptable values for the applicable Incorporating Agency or Registration Agency. ##### 7.1.4.2.5 Subject Registration Number Field @@ -1511,7 +1511,7 @@ For Government Entities that do not have a Registration Number or readily verifi For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). -Effective as of 1 October 2020, if the CA has disclosed a set of acceptable format or formats for Registration Numbers for the applicable Registration Agency or Incorporating Agency, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), the CA MUST ensure, prior to issuance, that the Registration Number is valid according to at least one currently disclosed format for that applicable Registration Agency or Incorporating agency. +Effective as of 2020-10-01, if the CA has disclosed a set of acceptable format or formats for Registration Numbers for the applicable Registration Agency or Incorporating Agency, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), the CA MUST ensure, prior to issuance, that the Registration Number is valid according to at least one currently disclosed format for that applicable Registration Agency or Incorporating agency. ##### 7.1.4.2.6 Subject Physical Address of Place of Business Field From 447c81f2db7929142466017f35343aff1f76277c Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 2 Dec 2025 19:50:27 +0100 Subject: [PATCH 102/121] #193 date format YYYY-MM-DD --- docs/EVG.md | 90 ++++++++++++++++++++++++++--------------------------- 1 file changed, 45 insertions(+), 45 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 3ca93c02..56b0333f 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -40,51 +40,51 @@ These Guidelines do not address the verification of information, or the issuance | **Ver.** | **Ballot** | **Description** | **Adopted** | **Effective\*** | |-|-|-----|--|--| -| 1.4.0 | 72 | Reorganize EV Documents | 29 May 2012 | 29 May 2012 | -| 1.4.1 | 75 | NameConstraints Criticality Flag | 8 June 2012 | 8 June 2012 | -| 1.4.2 | 101 | EV 11.10.2 Accountants | 31 May 2013 | 31 May 2013 | -| 1.4.3 | 104 | Domain verification for EV Certificates | 9 July 2013 | 9 July 2013 | -| 1.4.4 | 113 | Revision to QIIS in EV Guidelines | 13 Jan 2014 | 13 Jan 2014 | -| 1.4.5 | 114 | Improvements to the EV Definitions | 28 Jan 2014 | 28 Jan 2014 | -| 1.4.6 | 119 | Remove "OfIncorporation" from OID descriptions in EVG 9.2.5 | 24 Mar 2014 | 24 Mar 2014 | -| 1.4.7 | 120 | Affiliate Authority to Verify Domain | 5 June 2014 | 5 June 2014 | -| 1.4.8 | 124 | Business Entity Clarification | 5 June 2014 | 5 June 2014 | -| 1.4.9 | 127 | Verification of Name, Title and Agency | 17 July 2014 | 17 July 2014 | -| 1.5.0 | 126 | Operational Existence | 24 July 2014 | 24 July 2014 | -| 1.5.1 | 131 | Verified Method of Communication | 12 Sept 2014 | 12 Sept 2014 | -| 1.5.2 | 123 | Reuse of Information | 16 Oct. 2014 | 16 Oct. 2014 | -| 1.5.3 | 144 | Validation rules for .onion names | 18 Feb. 2015 | 18 Feb. 2015 | -| 1.5.4 | 146 | Convert Baseline Requirements to RFC 3647 Framework | 16 Apr. 2015 | 16 Apr. 2015 | -| 1.5.5 | 145 | Operational Existence for Government Entities | 5 Mar. 2015 | 5 Mar. 2015 | -| 1.5.6 | 147 | Attorney-Accountant Letter Changes | 25 June 2015 | 25 June 2015 | -| 1.5.7 | 151 | Addition of Optional OIDs for Indicating Level of Validation | 28 Sept 2015 | 28 Sept 2015 | -| 1.5.8 | 162 | Sunset of Exceptions | 15 Mar 2016 | 15 Mar 2016 | -| 1.5.9 | 163 | Fix Errata in EV Guidelines 11.2.1 | 18 Mar 2016 | 18 Mar 2016 | -| 1.6.0 | 171 | Updating ETSI Standards | 1 July 2016 | 1 July 2016 | -| 1.6.1 | 180 | In EV 11.7.1, removed outdated cross-reference to BR 3.2.2.4(7) | 7 Jan. 2017 | 7 Jan. 2017 | -| 1.6.2 | 103 | 825-day Certificate Lifetimes | 17 Mar. 2017 | 17 Mar. 2017 | -| 1.6.3 | 198 | .Onion Revisions (declared invalid) | 7 May 2017 | 8 June 2017 | -| 1.6.4 | 191 | Clarify Place of Business Information | 23 May 2017 | 23 June 2017 | -| 1.6.5 | 201 | .onion Revisions | 8 June 2017 | 8 July 2017 | -| 1.6.6 | 192 | Notary revision | 28 June 2017 | 28 July 2017 | -| 1.6.7 | 207 | ASN.1 Jurisdiction | 23 October 2017 | 23 November 2017 | -| 1.6.8 | 217 | Sunset RFC 2527 | 21 Dec 2017 | 9 Mar 2018 | -| 1.6.9 | SC16 | Other Subject Attributes | 15 Mar 2019 | 16 Apr 2019 | -| 1.7.0 | SC17 | Alternative registration numbers for EV certificates | 21 May 2019 | 21 June 2019 | -| 1.7.1 | SC24 | Fall cleanup v2 | 12 Nov 2019 | 19 Dec 2019 | -| 1.7.2 | SC27 | Version 3 Onion Certificates | 19-Feb-2020 | 27-Mar-2020 | -| 1.7.3 | SC30 | Disclosure of Registration / Incorporating Agency | 13-Jul-2020 | 20-Aug-2020 | -| 1.7.3 | SC31 | Browser Alignment | 16-Jul-2020 | 20-Aug-2020 | -| 1.7.4 | SC35 | Cleanups and Clarifications | 9-Sep-2020 | 19-Oct-2020 | -| 1.7.5 | SC41 | Reformatting the BRs, EVGs, and NCSSRs | 24-Feb-2021 | 5-Apr-2021 | -| 1.7.6 | SC42 | 398-day Re-use Period | 22-Apr-2021 | 2-Jun-2021 | -| 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 | -| 1.8.1 | SC68 | Allow VATEL and VATXI for organizationIdentifier | 1-Feb-2024 | 4-Mar-2024 | -| 2.0.0 | SC65 | Convert EVGs into RFC 3647 format | 15-March-2024 | 15-May-2024 | -| 2.0.1 | SC72 | Delete except to policyQualifiers in EVGs; align with BRs by making them NOT RECOMMENDED | 3-April-2024 | 6-May-2024 | +| 1.4.0 | 72 | Reorganize EV Documents | 2012-05-29 | 2012-05-29 | +| 1.4.1 | 75 | NameConstraints Criticality Flag | 2012-06-08 | 2012-06-08 | +| 1.4.2 | 101 | EV 11.10.2 Accountants | 2013-05-31 | 2013-05-31 | +| 1.4.3 | 104 | Domain verification for EV Certificates | 2013-07-09 | 2013-07-09 | +| 1.4.4 | 113 | Revision to QIIS in EV Guidelines | 2014-01-13 | 2014-01-13 | +| 1.4.5 | 114 | Improvements to the EV Definitions | 2014-01-28 | 2014-01-28 | +| 1.4.6 | 119 | Remove "OfIncorporation" from OID descriptions in EVG 9.2.5 | 2014-03-24 | 2014-03-24 | +| 1.4.7 | 120 | Affiliate Authority to Verify Domain | 2014-06-05 | 2014-06-05 | +| 1.4.8 | 124 | Business Entity Clarification | 2014-06-05 | 2014-06-05 | +| 1.4.9 | 127 | Verification of Name, Title and Agency | 2014-07-17 | 2014-07-17 | +| 1.5.0 | 126 | Operational Existence | 2014-07-24 | 2014-07-24 | +| 1.5.1 | 131 | Verified Method of Communication | 2014-09-12 | 2014-09-12 | +| 1.5.2 | 123 | Reuse of Information | 2014-10-16 | 2014-10-16 | +| 1.5.3 | 144 | Validation rules for .onion names | 2015-02-18 | 2015-02-18 | +| 1.5.4 | 146 | Convert Baseline Requirements to RFC 3647 Framework | 2015-04-16 | 2015-04-16 | +| 1.5.5 | 145 | Operational Existence for Government Entities | 2015-03-05 | 2015-03-05 | +| 1.5.6 | 147 | Attorney-Accountant Letter Changes | 2015-06-25 | 2015-06-25 | +| 1.5.7 | 151 | Addition of Optional OIDs for Indicating Level of Validation | 2015-09-28 | 2015-09-28 | +| 1.5.8 | 162 | Sunset of Exceptions | 2016-03-15 | 2016-03-15 | +| 1.5.9 | 163 | Fix Errata in EV Guidelines 11.2.1 | 2016-03-18 | 2016-03-18 | +| 1.6.0 | 171 | Updating ETSI Standards | 2016-07-01 | 2016-07-01 | +| 1.6.1 | 180 | In EV 11.7.1, removed outdated cross-reference to BR 3.2.2.4(7) | 2017-01-07 | 2017-01-07 | +| 1.6.2 | 103 | 825-day Certificate Lifetimes | 2017-03-17 | 2017-03-17 | +| 1.6.3 | 198 | .Onion Revisions (declared invalid) | 2017-05-07 | 2017-06-08 | +| 1.6.4 | 191 | Clarify Place of Business Information | 2017-05-23 | 2017-06-23 | +| 1.6.5 | 201 | .onion Revisions | 2017-06-08 | 2017-07-08 | +| 1.6.6 | 192 | Notary revision | 2017-06-28 | 2017-07-28 | +| 1.6.7 | 207 | ASN.1 Jurisdiction | 2017-10-23 | 2017-11-23 | +| 1.6.8 | 217 | Sunset RFC 2527 | 2017-12-21 | 2018-03-09 | +| 1.6.9 | SC16 | Other Subject Attributes | 2019-03-15 | 2019-04-16 | +| 1.7.0 | SC17 | Alternative registration numbers for EV certificates | 2019-05-21 | 2019-06-21 | +| 1.7.1 | SC24 | Fall cleanup v2 | 2019-11-12 | 2019-12-19 | +| 1.7.2 | SC27 | Version 3 Onion Certificates | 2020-02-19 | 2020-03-27 | +| 1.7.3 | SC30 | Disclosure of Registration / Incorporating Agency | 2020-07-13 | 2020-08-20 | +| 1.7.3 | SC31 | Browser Alignment | 2020-07-16 | 2020-08-20 | +| 1.7.4 | SC35 | Cleanups and Clarifications | 2020-09-09 | 2020-10-19 | +| 1.7.5 | SC41 | Reformatting the BRs, EVGs, and NCSSRs | 2021-02-24 | 2021-04-05 | +| 1.7.6 | SC42 | 398-day Re-use Period | 2021-04-22 | 2021-06-02 | +| 1.7.7 | SC47 | Sunset subject:organizationalUnitName | 2021-06-30 | 2021-08-16 | +| 1.7.8 | SC48 | Domain Name and IP Address Encoding | 2021-07-22 | 2021-08-25 | +| 1.7.9 | SC54 | Onion Cleanup | 2022-03-24 | 2022-04-23 | +| 1.8.0 | SC56 | 2022 Cleanup | 2022-10-25 | 2022-11-30 | +| 1.8.1 | SC68 | Allow VATEL and VATXI for organizationIdentifier | 2024-02-01 | 2024-03-04 | +| 2.0.0 | SC65 | Convert EVGs into RFC 3647 format | 2024-03-15 | 2024-05-15 | +| 2.0.1 | SC72 | Delete except to policyQualifiers in EVGs; align with BRs by making them NOT RECOMMENDED | 2024-04-03 | 2024-05-06 | \* Effective Date and Additionally Relevant Compliance Date(s) From d72511bcb64153449b1b3421024c7475faa02157 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 2 Dec 2025 20:11:59 +0100 Subject: [PATCH 103/121] #432 table spacing --- docs/BR.md | 216 ++++++++++++++++++++++++++--------------------------- 1 file changed, 108 insertions(+), 108 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 7250c626..d93e25a0 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -45,114 +45,114 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse ### 1.2.1 Revisions -| **Ver.** | **Ballot** | **Description** | **Adopted** | **Effective\*** | -|----------|------------|---------------------------------------------------|-------------|-----------------------------------| -| 1.0.0 | 62 | Version 1.0 of the Baseline Requirements Adopted | 22-Nov-11 | 01-Jul-12 | -| 1.0.1 | 71 | Revised Auditor Qualifications | 08-May-12 | 01-Jan-13 | -| 1.0.2 | 75 | Non-critical Name Constraints allowed as exception to RFC 5280 | 08-Jun-12 | 08-Jun-12 | -| 1.0.3 | 78 | Revised Domain/IP Address Validation, High Risk Requests, and Data Sources | 22-Jun-12 | 22-Jun-12 | -| 1.0.4 | 80 | OCSP responses for non-issued certificates | 02-Aug-12 | 01-Feb-13 01-Aug-13 | -| -- | 83 | Network and Certificate System Security Requirements adopted | 03-Aug-13 | 01-Jan-13 | -| 1.0.5 | 88 | User-assigned country code of XX allowed | 12-Sep-12 | 12-Sep-12 | -| 1.1.0 | -- | Published as Version 1.1 with no changes from 1.0.5 | 14-Sep-12 | 14-Sep-12 | -| 1.1.1 | 93 | Reasons for Revocation and Public Key Parameter checking | 07-Nov-12 | 07-Nov-12 01-Jan-13 | -| 1.1.2 | 96 | Wildcard certificates and new gTLDs | 20-Feb-13 | 20-Feb-13 01-Sep-13 | -| 1.1.3 | 97 | Prevention of Unknown Certificate Contents | 21-Feb-13 | 21-Feb-13 | -| 1.1.4 | 99 | Add DSA Keys (BR v.1.1.4) | 3-May-2013 | 3-May-2013 | -| 1.1.5 | 102 | Revision to subject domainComponent language in Section 9.2.3 | 31-May-2013 | 31-May-2013 | -| 1.1.6 | 105 | Technical Constraints for Subordinate Certificate Authorities | 29-Jul-2013 | 29-Jul-2013 | -| 1.1.7 | 112 | Replace Definition of "Internal Server Name" with "Internal Name" | 3-Apr-2014 | 3-Apr-2014 | -| 1.1.8 | 120 | Affiliate Authority to Verify Domain | 5-Jun-2014 | 5-Jun-2014 | -| 1.1.9 | 129 | Clarification of PSL mentioned in Section 11.1.3 | 4-Aug-2014 | 4-Aug-2014 | -| 1.2.0 | 125 | CAA Records | 14-Oct-2014 | 15-Apr-2015 | -| 1.2.1 | 118 | SHA-1 Sunset | 16-Oct-2014 | 16-Jan-2015 1-Jan-2016 1-Jan-2017 | -| 1.2.2 | 134 | Application of RFC 5280 to Pre-certificates | 16-Oct-2014 | 16-Oct-2014 | -| 1.2.3 | 135 | ETSI Auditor Qualifications | 16-Oct-2014 | 16-Oct-2014 | -| 1.2.4 | 144 | Validation Rules for .onion Names | 18-Feb-2015 | 18-Feb-2015 | -| 1.2.5 | 148 | Issuer Field Correction | 2-Apr-2015 | 2-Apr-2015 | -| 1.3.0 | 146 | Convert Baseline Requirements to RFC 3647 Framework | 16-Apr-2015 | 16-Apr-2015 | -| 1.3.1 | 151 | Addition of Optional OIDs for Indicating Level of Validation | 28-Sep-2015 | 28-Sep-2015 | -| 1.3.2 | 156 | Amend Sections 1 and 2 of Baseline Requirements | 3-Dec-2015 | 3-Dec-2016 | -| 1.3.3 | 160 | Amend Section 4 of Baseline Requirements | 4-Feb-2016 | 4-Feb-2016 | -| 1.3.4 | 162 | Sunset of Exceptions | 15-Mar-2016 | 15-Mar-2016 | -| 1.3.5 | 168 | Baseline Requirements Corrections (Revised) | 10-May-2016 | 10-May-2016 | -| 1.3.6 | 171 | Updating ETSI Standards in CABF documents | 1-Jul-2016 | 1-Jul-2016 | -| 1.3.7 | 164 | Certificate Serial Number Entropy | 8-Jul-2016 | 30-Sep-2016 | -| 1.3.8 | 169 | Revised Validation Requirements | 5-Aug-2016 | 1-Mar-2017 | -| 1.3.9 | 174 | Reform of Requirements Relating to Conflicts with Local Law | 29-Aug-2016 | 27-Nov-2016 | -| 1.4.0 | 173 | Removal of requirement to cease use of public key due to incorrect info | 28-Jul-2016 | 11-Sep-2016 | -| 1.4.1 | 175 | Addition of givenName and surname | 7-Sep-2016 | 7-Sep-2016 | -| 1.4.2 | 181 | Removal of some validation methods listed in Section 3.2.2.4 | 7-Jan-2017 | 7-Jan-2017 | -| 1.4.3 | 187 | Make CAA Checking Mandatory | 8-Mar-2017 | 8-Sep-2017 | -| 1.4.4 | 193 | 825-day Certificate Lifetimes | 17-Mar-2017 | 1-Mar-2018 | -| 1.4.5 | 189 | Amend Section 6.1.7 of Baseline Requirements | 14-Apr-2017 | 14-May-2017 | -| 1.4.6 | 195 | CAA Fixup | 17-Apr-2017 | 18-May-2017 | -| 1.4.7 | 196 | Define "Audit Period" | 17-Apr-2017 | 18-May-2017 | -| 1.4.8 | 199 | Require commonName in Root and Intermediate Certificates | 9-May-2017 | 8-Jun-2017 | -| 1.4.9 | 204 | Forbid DTPs from doing Domain/IP Ownership | 11-Jul-2017 | 11-Aug-2017 | -| 1.5.0 | 212 | Canonicalise formal name of the Baseline Requirements | 1-Sep-2017 | 1-Oct-2017 | -| 1.5.1 | 197 | Effective Date of Ballot 193 Provisions | 1-May-2017 | 2-Jun-2017 | -| 1.5.2 | 190 | Add Validation Methods with Minor Corrections | 19-Sep-2017 | 19-Oct-2017 | -| 1.5.3 | 214 | CAA Discovery CNAME Errata | 27-Sep-2017 | 27-Oct-2017 | -| 1.5.4 | 215 | Fix Ballot 190 Errata | 4‐Oct‐2017 | 5‐Nov‐2017 | -| 1.5.5 | 217 | Sunset RFC 2527 | 21‐Dec‐2017 | 9‐Mar‐2018 | -| 1.5.6 | 218 | Remove validation methods #1 and #5 | 5‐Feb‐2018 | 9‐Mar‐2018 | -| 1.5.7 | 220 | Minor Cleanups (Spring 2018) | 30‐Mar‐2018 | 29‐Apr‐2018 | -| 1.5.8 | 219 | Clarify handling of CAA Record Sets with no "issue"/"issuewild" property tag | 10-Apr-2018 | 10-May-2018 | -| 1.5.9 | 223 | Update BR Section 8.4 for CA audit criteria | 15-May-2018 | 14-June-2018 | -| 1.6.0 | 224 | WhoIs and RDAP | 22-May-2018 | 22-June-2018 | -| 1.6.1 | SC006 | Revocation Timeline Extension | 14-Sep-2018 | 14-Oct-2018 | -| 1.6.2 | SC012 | Sunset of Underscores in dNSNames | 9-Nov-2018 | 10-Dec-2018 | -| 1.6.3 | SC013 | CAA Contact Property and Associated E-mail Validation Methods | 25-Dec-2018 | 1-Feb-2019 | -| 1.6.4 | SC014 | Updated Phone Validation Methods | 31-Jan-2019 | 16-Mar-2019 | -| 1.6.4 | SC015 | Remove Validation Method Number 9 | 5-Feb-2019 | 16-Mar-2019 | -| 1.6.4 | SC007 | Update IP Address Validation Methods | 8-Feb-2019 | 16-Mar-2019 | -| 1.6.5 | SC016 | Other Subject Attributes | 15-Mar-2019 | 16-Apr-2019 | -| 1.6.6 | SC019 | Phone Contact with DNS CAA Phone Contact v2 | 20-May-2019 | 9-Sep-2019 | -| 1.6.7 | SC023 | Precertificates | 14-Nov-2019 | 19-Dec-2019 | -| 1.6.7 | SC024 | Fall Cleanup v2 | 12-Nov-2019 | 19-Dec-2019 | -| 1.6.8 | SC025 | Define New HTTP Domain Validation Methods v2 | 31-Jan-2020 | 3-Mar-2020 | -| 1.6.9 | SC027 | Version 3 Onion Certificates | 19-Feb-2020 | 27-Mar-2020 | -| 1.7.0 | SC029 | Pandoc-Friendly Markdown Formatting Changes | 20-Mar-2020 | 4-May-2020 | -| 1.7.1 | SC030 | Disclosure of Registration / Incorporating Agency | 13-Jul-2020 | 20-Aug-2020 | -| 1.7.1 | SC031 | Browser Alignment | 16-Jul-2020 | 20-Aug-2020 | -| 1.7.2 | SC033 | TLS Using ALPN Method | 14-Aug-2020 | 22-Sept-2020 | -| 1.7.3 | SC028 | Logging and Log Retention | 10-Sep-2020 | 19-Oct-2020 | -| 1.7.3 | SC035 | Cleanups and Clarifications | 9-Sep-2020 | 19-Oct-2020 | -| 1.7.4 | SC041 | Reformat the BRs, EVGs, and NCSSRs | 24-Feb-2021 | 5-Apr-2021 | -| 1.7.5 | SC042 | 398-day Re-use Period | 22-Apr-2021 | 2-Jun-2021 | -| 1.7.6 | SC044 | Clarify Acceptable Status Codes | 30-Apr-2021 | 3-Jun-2021 | -| 1.7.7 | SC046 | Sunset the CAA Exception for DNS Operator | 2-Jun-2021 | 12-Jul-2021 | -| 1.7.8 | SC045 | Wildcard Domain Validation | 2-Jun-2021 | 13-Jul-2021 | -| 1.7.9 | SC047 | Sunset subject:organizationalUnitName | 30-Jun-2021 | 16-Aug-2021 | -| 1.8.0 | SC048 | Domain Name and IP Address Encoding | 22-Jul-2021 | 25-Aug-2021 | -| 1.8.1 | SC050 | Remove the requirements of 4.1.1 | 22-Nov-2021 | 23-Dec-2021 | -| 1.8.2 | SC053 | Sunset for SHA-1 OCSP Signing | 26-Jan-2022 | 4-Mar-2022 | -| 1.8.3 | SC051 | Reduce and Clarify Log and Records Archival Retention Requirements | 01-Mar-2022 | 15-Apr-2022 | -| 1.8.4 | SC054 | Onion Cleanup | 24-Mar-2022 | 23-Apr-2022 | -| 1.8.5 | SC056 | 2022 Cleanup | 25-Oct-2022 | 30-Nov-2022 | -| 1.8.6 | SC058 | Require distributionPoint in sharded CRLs | 7-Nov-2022 | 11-Dec-2022 | -| 1.8.7 | SC061 | New CRL entries must have a Revocation Reason Code | 1-Apr-2023 | 15-Jul-2023 | -| 2.0.0 | SC062 | Certificate Profiles Update | 22-Apr-2023 | 15-Sep-2023 | -| 2.0.1 | SC063 | Make OCSP optional, require CRLs, and incentivize automation | 17-Aug-2023 | 15-Mar-2024 | -| 2.0.2 | SC066 | 2023 Cleanup | 23-Nov-2023 | 8-Jan-2024 | -| 2.0.3 | SC069 | Clarify router and firewall logging requirements | 13-Mar-2024 | 15-Apr-2024 | -| 2.0.4 | SC065 | Convert EVGs into RFC 3647 format | 15-Mar-2024 | 15-May-2024 | -| 2.0.5 | SC073 | Compromised and weak keys | 3-May-2024 | 1-Jul-2024 | -| 2.0.6 | SC075 | Pre-sign linting | 28-Jun-2024 | 6-Aug-2024 | -| 2.0.7 | SC067 | Require Multi-Perspective Issuance Corroboration | 2-Aug-2024 | 6-Sep-2024 | -| 2.0.8 | SC077 | Update WebTrust Audit name in Section 8.4 and References | 2-Sep-2024 | 2-Oct-2024 | -| 2.0.9 | SC078 | Subject organizationName alignment for DBA / Assumed Name | 2-Oct-2024 | 8-Nov-2024 | -| 2.1.0 | SC076 | Clarify and improve OCSP requirements | 26-Sep-2024 | 14-Nov-2024 | -| 2.1.1 | SC079 | Allow more than one Certificate Policy in a Cross-Certified Subordinate CA Certificate | 30-Sep-2024 | 14-Nov-2024 | -| 2.1.2 | SC080 | Strengthen WHOIS lookups and Sunset Methods 3.2.2.4.2 and 3.2.2.4.15 | 7-Nov-2024 | 16-Dec-2024 | -| 2.1.3 | SC083 | Winter 2024-2025 Cleanup Ballot | 23-Jan-2025 | 24-Feb-2025 | -| 2.1.4 | SC084 | DNS Labeled with ACME Account ID Validation Method | 28-Jan-2025 | 1-Mar-2025 | -| 2.1.5 | SC081 | Introduce Schedule of Reducing Validity and Data Reuse Periods | 11-Apr-2025 | 16-May-2025 | -| 2.1.6 | SC085 | Require Validation of DNSSEC (when present) for CAA and DCV Lookups | 19-Jun-2025 | 21-Jul-2025 | -| 2.1.7 | SC089 | Mass Revocation Planning | 23-Jul-2025 | 25-Aug-2025 | -| 2.1.8 | SC092 | Sunset Precertificate Signing CAs | 03-Oct-2025 | 04-Nov-2025 | -| 2.1.9 | SC088 | DNS TXT Record with Persistent Value DCV Method | 09-Oct-2025 | 10-Nov-2025 | +| **Ver.** | **Ballot** | **Description** | **Adopted** | **Effective\*** | +|-|-|-----|--|--| +| 1.0.0 | 62 | Version 1.0 of the Baseline Requirements Adopted | 22-Nov-11 | 01-Jul-12 | +| 1.0.1 | 71 | Revised Auditor Qualifications | 08-May-12 | 01-Jan-13 | +| 1.0.2 | 75 | Non-critical Name Constraints allowed as exception to RFC 5280 | 08-Jun-12 | 08-Jun-12 | +| 1.0.3 | 78 | Revised Domain/IP Address Validation, High Risk Requests, and Data Sources | 22-Jun-12 | 22-Jun-12 | +| 1.0.4 | 80 | OCSP responses for non-issued certificates | 02-Aug-12 | 01-Feb-13 01-Aug-13 | +| -- | 83 | Network and Certificate System Security Requirements adopted | 03-Aug-13 | 01-Jan-13 | +| 1.0.5 | 88 | User-assigned country code of XX allowed | 12-Sep-12 | 12-Sep-12 | +| 1.1.0 | -- | Published as Version 1.1 with no changes from 1.0.5 | 14-Sep-12 | 14-Sep-12 | +| 1.1.1 | 93 | Reasons for Revocation and Public Key Parameter checking | 07-Nov-12 | 07-Nov-12 01-Jan-13 | +| 1.1.2 | 96 | Wildcard certificates and new gTLDs | 20-Feb-13 | 20-Feb-13 01-Sep-13 | +| 1.1.3 | 97 | Prevention of Unknown Certificate Contents | 21-Feb-13 | 21-Feb-13 | +| 1.1.4 | 99 | Add DSA Keys (BR v.1.1.4) | 3-May-2013 | 3-May-2013 | +| 1.1.5 | 102 | Revision to subject domainComponent language in Section 9.2.3 | 31-May-2013 | 31-May-2013 | +| 1.1.6 | 105 | Technical Constraints for Subordinate Certificate Authorities | 29-Jul-2013 | 29-Jul-2013 | +| 1.1.7 | 112 | Replace Definition of "Internal Server Name" with "Internal Name" | 3-Apr-2014 | 3-Apr-2014 | +| 1.1.8 | 120 | Affiliate Authority to Verify Domain | 5-Jun-2014 | 5-Jun-2014 | +| 1.1.9 | 129 | Clarification of PSL mentioned in Section 11.1.3 | 4-Aug-2014 | 4-Aug-2014 | +| 1.2.0 | 125 | CAA Records | 14-Oct-2014 | 15-Apr-2015 | +| 1.2.1 | 118 | SHA-1 Sunset | 16-Oct-2014 | 16-Jan-2015 1-Jan-2016 1-Jan-2017 | +| 1.2.2 | 134 | Application of RFC 5280 to Pre-certificates | 16-Oct-2014 | 16-Oct-2014 | +| 1.2.3 | 135 | ETSI Auditor Qualifications | 16-Oct-2014 | 16-Oct-2014 | +| 1.2.4 | 144 | Validation Rules for .onion Names | 18-Feb-2015 | 18-Feb-2015 | +| 1.2.5 | 148 | Issuer Field Correction | 2-Apr-2015 | 2-Apr-2015 | +| 1.3.0 | 146 | Convert Baseline Requirements to RFC 3647 Framework | 16-Apr-2015 | 16-Apr-2015 | +| 1.3.1 | 151 | Addition of Optional OIDs for Indicating Level of Validation | 28-Sep-2015 | 28-Sep-2015 | +| 1.3.2 | 156 | Amend Sections 1 and 2 of Baseline Requirements | 3-Dec-2015 | 3-Dec-2016 | +| 1.3.3 | 160 | Amend Section 4 of Baseline Requirements | 4-Feb-2016 | 4-Feb-2016 | +| 1.3.4 | 162 | Sunset of Exceptions | 15-Mar-2016 | 15-Mar-2016 | +| 1.3.5 | 168 | Baseline Requirements Corrections (Revised) | 10-May-2016 | 10-May-2016 | +| 1.3.6 | 171 | Updating ETSI Standards in CABF documents | 1-Jul-2016 | 1-Jul-2016 | +| 1.3.7 | 164 | Certificate Serial Number Entropy | 8-Jul-2016 | 30-Sep-2016 | +| 1.3.8 | 169 | Revised Validation Requirements | 5-Aug-2016 | 1-Mar-2017 | +| 1.3.9 | 174 | Reform of Requirements Relating to Conflicts with Local Law | 29-Aug-2016 | 27-Nov-2016 | +| 1.4.0 | 173 | Removal of requirement to cease use of public key due to incorrect info | 28-Jul-2016 | 11-Sep-2016 | +| 1.4.1 | 175 | Addition of givenName and surname | 7-Sep-2016 | 7-Sep-2016 | +| 1.4.2 | 181 | Removal of some validation methods listed in Section 3.2.2.4 | 7-Jan-2017 | 7-Jan-2017 | +| 1.4.3 | 187 | Make CAA Checking Mandatory | 8-Mar-2017 | 8-Sep-2017 | +| 1.4.4 | 193 | 825-day Certificate Lifetimes | 17-Mar-2017 | 1-Mar-2018 | +| 1.4.5 | 189 | Amend Section 6.1.7 of Baseline Requirements | 14-Apr-2017 | 14-May-2017 | +| 1.4.6 | 195 | CAA Fixup | 17-Apr-2017 | 18-May-2017 | +| 1.4.7 | 196 | Define "Audit Period" | 17-Apr-2017 | 18-May-2017 | +| 1.4.8 | 199 | Require commonName in Root and Intermediate Certificates | 9-May-2017 | 8-Jun-2017 | +| 1.4.9 | 204 | Forbid DTPs from doing Domain/IP Ownership | 11-Jul-2017 | 11-Aug-2017 | +| 1.5.0 | 212 | Canonicalise formal name of the Baseline Requirements | 1-Sep-2017 | 1-Oct-2017 | +| 1.5.1 | 197 | Effective Date of Ballot 193 Provisions | 1-May-2017 | 2-Jun-2017 | +| 1.5.2 | 190 | Add Validation Methods with Minor Corrections | 19-Sep-2017 | 19-Oct-2017 | +| 1.5.3 | 214 | CAA Discovery CNAME Errata | 27-Sep-2017 | 27-Oct-2017 | +| 1.5.4 | 215 | Fix Ballot 190 Errata | 4‐Oct‐2017 | 5‐Nov‐2017 | +| 1.5.5 | 217 | Sunset RFC 2527 | 21‐Dec‐2017 | 9‐Mar‐2018 | +| 1.5.6 | 218 | Remove validation methods #1 and #5 | 5‐Feb‐2018 | 9‐Mar‐2018 | +| 1.5.7 | 220 | Minor Cleanups (Spring 2018) | 30‐Mar‐2018 | 29‐Apr‐2018 | +| 1.5.8 | 219 | Clarify handling of CAA Record Sets with no "issue"/"issuewild" property tag | 10-Apr-2018 | 10-May-2018 | +| 1.5.9 | 223 | Update BR Section 8.4 for CA audit criteria | 15-May-2018 | 14-June-2018 | +| 1.6.0 | 224 | WhoIs and RDAP | 22-May-2018 | 22-June-2018 | +| 1.6.1 | SC006 | Revocation Timeline Extension | 14-Sep-2018 | 14-Oct-2018 | +| 1.6.2 | SC012 | Sunset of Underscores in dNSNames | 9-Nov-2018 | 10-Dec-2018 | +| 1.6.3 | SC013 | CAA Contact Property and Associated E-mail Validation Methods | 25-Dec-2018 | 1-Feb-2019 | +| 1.6.4 | SC014 | Updated Phone Validation Methods | 31-Jan-2019 | 16-Mar-2019 | +| 1.6.4 | SC015 | Remove Validation Method Number 9 | 5-Feb-2019 | 16-Mar-2019 | +| 1.6.4 | SC007 | Update IP Address Validation Methods | 8-Feb-2019 | 16-Mar-2019 | +| 1.6.5 | SC016 | Other Subject Attributes | 15-Mar-2019 | 16-Apr-2019 | +| 1.6.6 | SC019 | Phone Contact with DNS CAA Phone Contact v2 | 20-May-2019 | 9-Sep-2019 | +| 1.6.7 | SC023 | Precertificates | 14-Nov-2019 | 19-Dec-2019 | +| 1.6.7 | SC024 | Fall Cleanup v2 | 12-Nov-2019 | 19-Dec-2019 | +| 1.6.8 | SC025 | Define New HTTP Domain Validation Methods v2 | 31-Jan-2020 | 3-Mar-2020 | +| 1.6.9 | SC027 | Version 3 Onion Certificates | 19-Feb-2020 | 27-Mar-2020 | +| 1.7.0 | SC029 | Pandoc-Friendly Markdown Formatting Changes | 20-Mar-2020 | 4-May-2020 | +| 1.7.1 | SC030 | Disclosure of Registration / Incorporating Agency | 13-Jul-2020 | 20-Aug-2020 | +| 1.7.1 | SC031 | Browser Alignment | 16-Jul-2020 | 20-Aug-2020 | +| 1.7.2 | SC033 | TLS Using ALPN Method | 14-Aug-2020 | 22-Sept-2020 | +| 1.7.3 | SC028 | Logging and Log Retention | 10-Sep-2020 | 19-Oct-2020 | +| 1.7.3 | SC035 | Cleanups and Clarifications | 9-Sep-2020 | 19-Oct-2020 | +| 1.7.4 | SC041 | Reformat the BRs, EVGs, and NCSSRs | 24-Feb-2021 | 5-Apr-2021 | +| 1.7.5 | SC042 | 398-day Re-use Period | 22-Apr-2021 | 2-Jun-2021 | +| 1.7.6 | SC044 | Clarify Acceptable Status Codes | 30-Apr-2021 | 3-Jun-2021 | +| 1.7.7 | SC046 | Sunset the CAA Exception for DNS Operator | 2-Jun-2021 | 12-Jul-2021 | +| 1.7.8 | SC045 | Wildcard Domain Validation | 2-Jun-2021 | 13-Jul-2021 | +| 1.7.9 | SC047 | Sunset subject:organizationalUnitName | 30-Jun-2021 | 16-Aug-2021 | +| 1.8.0 | SC048 | Domain Name and IP Address Encoding | 22-Jul-2021 | 25-Aug-2021 | +| 1.8.1 | SC050 | Remove the requirements of 4.1.1 | 22-Nov-2021 | 23-Dec-2021 | +| 1.8.2 | SC053 | Sunset for SHA-1 OCSP Signing | 26-Jan-2022 | 4-Mar-2022 | +| 1.8.3 | SC051 | Reduce and Clarify Log and Records Archival Retention Requirements | 01-Mar-2022 | 15-Apr-2022 | +| 1.8.4 | SC054 | Onion Cleanup | 24-Mar-2022 | 23-Apr-2022 | +| 1.8.5 | SC056 | 2022 Cleanup | 25-Oct-2022 | 30-Nov-2022 | +| 1.8.6 | SC058 | Require distributionPoint in sharded CRLs | 7-Nov-2022 | 11-Dec-2022 | +| 1.8.7 | SC061 | New CRL entries must have a Revocation Reason Code | 1-Apr-2023 | 15-Jul-2023 | +| 2.0.0 | SC062 | Certificate Profiles Update | 22-Apr-2023 | 15-Sep-2023 | +| 2.0.1 | SC063 | Make OCSP optional, require CRLs, and incentivize automation | 17-Aug-2023 | 15-Mar-2024 | +| 2.0.2 | SC066 | 2023 Cleanup | 23-Nov-2023 | 8-Jan-2024 | +| 2.0.3 | SC069 | Clarify router and firewall logging requirements | 13-Mar-2024 | 15-Apr-2024 | +| 2.0.4 | SC065 | Convert EVGs into RFC 3647 format | 15-Mar-2024 | 15-May-2024 | +| 2.0.5 | SC073 | Compromised and weak keys | 3-May-2024 | 1-Jul-2024 | +| 2.0.6 | SC075 | Pre-sign linting | 28-Jun-2024 | 6-Aug-2024 | +| 2.0.7 | SC067 | Require Multi-Perspective Issuance Corroboration | 2-Aug-2024 | 6-Sep-2024 | +| 2.0.8 | SC077 | Update WebTrust Audit name in Section 8.4 and References | 2-Sep-2024 | 2-Oct-2024 | +| 2.0.9 | SC078 | Subject organizationName alignment for DBA / Assumed Name | 2-Oct-2024 | 8-Nov-2024 | +| 2.1.0 | SC076 | Clarify and improve OCSP requirements | 26-Sep-2024 | 14-Nov-2024 | +| 2.1.1 | SC079 | Allow more than one Certificate Policy in a Cross-Certified Subordinate CA Certificate | 30-Sep-2024 | 14-Nov-2024 | +| 2.1.2 | SC080 | Strengthen WHOIS lookups and Sunset Methods 3.2.2.4.2 and 3.2.2.4.15 | 7-Nov-2024 | 16-Dec-2024 | +| 2.1.3 | SC083 | Winter 2024-2025 Cleanup Ballot | 23-Jan-2025 | 24-Feb-2025 | +| 2.1.4 | SC084 | DNS Labeled with ACME Account ID Validation Method | 28-Jan-2025 | 1-Mar-2025 | +| 2.1.5 | SC081 | Introduce Schedule of Reducing Validity and Data Reuse Periods | 11-Apr-2025 | 16-May-2025 | +| 2.1.6 | SC085 | Require Validation of DNSSEC (when present) for CAA and DCV Lookups | 19-Jun-2025 | 21-Jul-2025 | +| 2.1.7 | SC089 | Mass Revocation Planning | 23-Jul-2025 | 25-Aug-2025 | +| 2.1.8 | SC092 | Sunset Precertificate Signing CAs | 03-Oct-2025 | 04-Nov-2025 | +| 2.1.9 | SC088 | DNS TXT Record with Persistent Value DCV Method | 09-Oct-2025 | 10-Nov-2025 | \* Effective Date and Additionally Relevant Compliance Date(s) From d4523747c51d5ecd5ebeb7a3da47bc094d02664d Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 2 Dec 2025 20:23:34 +0100 Subject: [PATCH 104/121] #193 date format YYYY-MM-DD --- docs/BR.md | 212 ++++++++++++++++++++++++++--------------------------- 1 file changed, 106 insertions(+), 106 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index d93e25a0..b923e222 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -47,112 +47,112 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | **Ver.** | **Ballot** | **Description** | **Adopted** | **Effective\*** | |-|-|-----|--|--| -| 1.0.0 | 62 | Version 1.0 of the Baseline Requirements Adopted | 22-Nov-11 | 01-Jul-12 | -| 1.0.1 | 71 | Revised Auditor Qualifications | 08-May-12 | 01-Jan-13 | -| 1.0.2 | 75 | Non-critical Name Constraints allowed as exception to RFC 5280 | 08-Jun-12 | 08-Jun-12 | -| 1.0.3 | 78 | Revised Domain/IP Address Validation, High Risk Requests, and Data Sources | 22-Jun-12 | 22-Jun-12 | -| 1.0.4 | 80 | OCSP responses for non-issued certificates | 02-Aug-12 | 01-Feb-13 01-Aug-13 | -| -- | 83 | Network and Certificate System Security Requirements adopted | 03-Aug-13 | 01-Jan-13 | -| 1.0.5 | 88 | User-assigned country code of XX allowed | 12-Sep-12 | 12-Sep-12 | -| 1.1.0 | -- | Published as Version 1.1 with no changes from 1.0.5 | 14-Sep-12 | 14-Sep-12 | -| 1.1.1 | 93 | Reasons for Revocation and Public Key Parameter checking | 07-Nov-12 | 07-Nov-12 01-Jan-13 | -| 1.1.2 | 96 | Wildcard certificates and new gTLDs | 20-Feb-13 | 20-Feb-13 01-Sep-13 | -| 1.1.3 | 97 | Prevention of Unknown Certificate Contents | 21-Feb-13 | 21-Feb-13 | -| 1.1.4 | 99 | Add DSA Keys (BR v.1.1.4) | 3-May-2013 | 3-May-2013 | -| 1.1.5 | 102 | Revision to subject domainComponent language in Section 9.2.3 | 31-May-2013 | 31-May-2013 | -| 1.1.6 | 105 | Technical Constraints for Subordinate Certificate Authorities | 29-Jul-2013 | 29-Jul-2013 | -| 1.1.7 | 112 | Replace Definition of "Internal Server Name" with "Internal Name" | 3-Apr-2014 | 3-Apr-2014 | -| 1.1.8 | 120 | Affiliate Authority to Verify Domain | 5-Jun-2014 | 5-Jun-2014 | -| 1.1.9 | 129 | Clarification of PSL mentioned in Section 11.1.3 | 4-Aug-2014 | 4-Aug-2014 | -| 1.2.0 | 125 | CAA Records | 14-Oct-2014 | 15-Apr-2015 | -| 1.2.1 | 118 | SHA-1 Sunset | 16-Oct-2014 | 16-Jan-2015 1-Jan-2016 1-Jan-2017 | -| 1.2.2 | 134 | Application of RFC 5280 to Pre-certificates | 16-Oct-2014 | 16-Oct-2014 | -| 1.2.3 | 135 | ETSI Auditor Qualifications | 16-Oct-2014 | 16-Oct-2014 | -| 1.2.4 | 144 | Validation Rules for .onion Names | 18-Feb-2015 | 18-Feb-2015 | -| 1.2.5 | 148 | Issuer Field Correction | 2-Apr-2015 | 2-Apr-2015 | -| 1.3.0 | 146 | Convert Baseline Requirements to RFC 3647 Framework | 16-Apr-2015 | 16-Apr-2015 | -| 1.3.1 | 151 | Addition of Optional OIDs for Indicating Level of Validation | 28-Sep-2015 | 28-Sep-2015 | -| 1.3.2 | 156 | Amend Sections 1 and 2 of Baseline Requirements | 3-Dec-2015 | 3-Dec-2016 | -| 1.3.3 | 160 | Amend Section 4 of Baseline Requirements | 4-Feb-2016 | 4-Feb-2016 | -| 1.3.4 | 162 | Sunset of Exceptions | 15-Mar-2016 | 15-Mar-2016 | -| 1.3.5 | 168 | Baseline Requirements Corrections (Revised) | 10-May-2016 | 10-May-2016 | -| 1.3.6 | 171 | Updating ETSI Standards in CABF documents | 1-Jul-2016 | 1-Jul-2016 | -| 1.3.7 | 164 | Certificate Serial Number Entropy | 8-Jul-2016 | 30-Sep-2016 | -| 1.3.8 | 169 | Revised Validation Requirements | 5-Aug-2016 | 1-Mar-2017 | -| 1.3.9 | 174 | Reform of Requirements Relating to Conflicts with Local Law | 29-Aug-2016 | 27-Nov-2016 | -| 1.4.0 | 173 | Removal of requirement to cease use of public key due to incorrect info | 28-Jul-2016 | 11-Sep-2016 | -| 1.4.1 | 175 | Addition of givenName and surname | 7-Sep-2016 | 7-Sep-2016 | -| 1.4.2 | 181 | Removal of some validation methods listed in Section 3.2.2.4 | 7-Jan-2017 | 7-Jan-2017 | -| 1.4.3 | 187 | Make CAA Checking Mandatory | 8-Mar-2017 | 8-Sep-2017 | -| 1.4.4 | 193 | 825-day Certificate Lifetimes | 17-Mar-2017 | 1-Mar-2018 | -| 1.4.5 | 189 | Amend Section 6.1.7 of Baseline Requirements | 14-Apr-2017 | 14-May-2017 | -| 1.4.6 | 195 | CAA Fixup | 17-Apr-2017 | 18-May-2017 | -| 1.4.7 | 196 | Define "Audit Period" | 17-Apr-2017 | 18-May-2017 | -| 1.4.8 | 199 | Require commonName in Root and Intermediate Certificates | 9-May-2017 | 8-Jun-2017 | -| 1.4.9 | 204 | Forbid DTPs from doing Domain/IP Ownership | 11-Jul-2017 | 11-Aug-2017 | -| 1.5.0 | 212 | Canonicalise formal name of the Baseline Requirements | 1-Sep-2017 | 1-Oct-2017 | -| 1.5.1 | 197 | Effective Date of Ballot 193 Provisions | 1-May-2017 | 2-Jun-2017 | -| 1.5.2 | 190 | Add Validation Methods with Minor Corrections | 19-Sep-2017 | 19-Oct-2017 | -| 1.5.3 | 214 | CAA Discovery CNAME Errata | 27-Sep-2017 | 27-Oct-2017 | -| 1.5.4 | 215 | Fix Ballot 190 Errata | 4‐Oct‐2017 | 5‐Nov‐2017 | -| 1.5.5 | 217 | Sunset RFC 2527 | 21‐Dec‐2017 | 9‐Mar‐2018 | -| 1.5.6 | 218 | Remove validation methods #1 and #5 | 5‐Feb‐2018 | 9‐Mar‐2018 | -| 1.5.7 | 220 | Minor Cleanups (Spring 2018) | 30‐Mar‐2018 | 29‐Apr‐2018 | -| 1.5.8 | 219 | Clarify handling of CAA Record Sets with no "issue"/"issuewild" property tag | 10-Apr-2018 | 10-May-2018 | -| 1.5.9 | 223 | Update BR Section 8.4 for CA audit criteria | 15-May-2018 | 14-June-2018 | -| 1.6.0 | 224 | WhoIs and RDAP | 22-May-2018 | 22-June-2018 | -| 1.6.1 | SC006 | Revocation Timeline Extension | 14-Sep-2018 | 14-Oct-2018 | -| 1.6.2 | SC012 | Sunset of Underscores in dNSNames | 9-Nov-2018 | 10-Dec-2018 | -| 1.6.3 | SC013 | CAA Contact Property and Associated E-mail Validation Methods | 25-Dec-2018 | 1-Feb-2019 | -| 1.6.4 | SC014 | Updated Phone Validation Methods | 31-Jan-2019 | 16-Mar-2019 | -| 1.6.4 | SC015 | Remove Validation Method Number 9 | 5-Feb-2019 | 16-Mar-2019 | -| 1.6.4 | SC007 | Update IP Address Validation Methods | 8-Feb-2019 | 16-Mar-2019 | -| 1.6.5 | SC016 | Other Subject Attributes | 15-Mar-2019 | 16-Apr-2019 | -| 1.6.6 | SC019 | Phone Contact with DNS CAA Phone Contact v2 | 20-May-2019 | 9-Sep-2019 | -| 1.6.7 | SC023 | Precertificates | 14-Nov-2019 | 19-Dec-2019 | -| 1.6.7 | SC024 | Fall Cleanup v2 | 12-Nov-2019 | 19-Dec-2019 | -| 1.6.8 | SC025 | Define New HTTP Domain Validation Methods v2 | 31-Jan-2020 | 3-Mar-2020 | -| 1.6.9 | SC027 | Version 3 Onion Certificates | 19-Feb-2020 | 27-Mar-2020 | -| 1.7.0 | SC029 | Pandoc-Friendly Markdown Formatting Changes | 20-Mar-2020 | 4-May-2020 | -| 1.7.1 | SC030 | Disclosure of Registration / Incorporating Agency | 13-Jul-2020 | 20-Aug-2020 | -| 1.7.1 | SC031 | Browser Alignment | 16-Jul-2020 | 20-Aug-2020 | -| 1.7.2 | SC033 | TLS Using ALPN Method | 14-Aug-2020 | 22-Sept-2020 | -| 1.7.3 | SC028 | Logging and Log Retention | 10-Sep-2020 | 19-Oct-2020 | -| 1.7.3 | SC035 | Cleanups and Clarifications | 9-Sep-2020 | 19-Oct-2020 | -| 1.7.4 | SC041 | Reformat the BRs, EVGs, and NCSSRs | 24-Feb-2021 | 5-Apr-2021 | -| 1.7.5 | SC042 | 398-day Re-use Period | 22-Apr-2021 | 2-Jun-2021 | -| 1.7.6 | SC044 | Clarify Acceptable Status Codes | 30-Apr-2021 | 3-Jun-2021 | -| 1.7.7 | SC046 | Sunset the CAA Exception for DNS Operator | 2-Jun-2021 | 12-Jul-2021 | -| 1.7.8 | SC045 | Wildcard Domain Validation | 2-Jun-2021 | 13-Jul-2021 | -| 1.7.9 | SC047 | Sunset subject:organizationalUnitName | 30-Jun-2021 | 16-Aug-2021 | -| 1.8.0 | SC048 | Domain Name and IP Address Encoding | 22-Jul-2021 | 25-Aug-2021 | -| 1.8.1 | SC050 | Remove the requirements of 4.1.1 | 22-Nov-2021 | 23-Dec-2021 | -| 1.8.2 | SC053 | Sunset for SHA-1 OCSP Signing | 26-Jan-2022 | 4-Mar-2022 | -| 1.8.3 | SC051 | Reduce and Clarify Log and Records Archival Retention Requirements | 01-Mar-2022 | 15-Apr-2022 | -| 1.8.4 | SC054 | Onion Cleanup | 24-Mar-2022 | 23-Apr-2022 | -| 1.8.5 | SC056 | 2022 Cleanup | 25-Oct-2022 | 30-Nov-2022 | -| 1.8.6 | SC058 | Require distributionPoint in sharded CRLs | 7-Nov-2022 | 11-Dec-2022 | -| 1.8.7 | SC061 | New CRL entries must have a Revocation Reason Code | 1-Apr-2023 | 15-Jul-2023 | -| 2.0.0 | SC062 | Certificate Profiles Update | 22-Apr-2023 | 15-Sep-2023 | -| 2.0.1 | SC063 | Make OCSP optional, require CRLs, and incentivize automation | 17-Aug-2023 | 15-Mar-2024 | -| 2.0.2 | SC066 | 2023 Cleanup | 23-Nov-2023 | 8-Jan-2024 | -| 2.0.3 | SC069 | Clarify router and firewall logging requirements | 13-Mar-2024 | 15-Apr-2024 | -| 2.0.4 | SC065 | Convert EVGs into RFC 3647 format | 15-Mar-2024 | 15-May-2024 | -| 2.0.5 | SC073 | Compromised and weak keys | 3-May-2024 | 1-Jul-2024 | -| 2.0.6 | SC075 | Pre-sign linting | 28-Jun-2024 | 6-Aug-2024 | -| 2.0.7 | SC067 | Require Multi-Perspective Issuance Corroboration | 2-Aug-2024 | 6-Sep-2024 | -| 2.0.8 | SC077 | Update WebTrust Audit name in Section 8.4 and References | 2-Sep-2024 | 2-Oct-2024 | -| 2.0.9 | SC078 | Subject organizationName alignment for DBA / Assumed Name | 2-Oct-2024 | 8-Nov-2024 | -| 2.1.0 | SC076 | Clarify and improve OCSP requirements | 26-Sep-2024 | 14-Nov-2024 | -| 2.1.1 | SC079 | Allow more than one Certificate Policy in a Cross-Certified Subordinate CA Certificate | 30-Sep-2024 | 14-Nov-2024 | -| 2.1.2 | SC080 | Strengthen WHOIS lookups and Sunset Methods 3.2.2.4.2 and 3.2.2.4.15 | 7-Nov-2024 | 16-Dec-2024 | -| 2.1.3 | SC083 | Winter 2024-2025 Cleanup Ballot | 23-Jan-2025 | 24-Feb-2025 | -| 2.1.4 | SC084 | DNS Labeled with ACME Account ID Validation Method | 28-Jan-2025 | 1-Mar-2025 | -| 2.1.5 | SC081 | Introduce Schedule of Reducing Validity and Data Reuse Periods | 11-Apr-2025 | 16-May-2025 | -| 2.1.6 | SC085 | Require Validation of DNSSEC (when present) for CAA and DCV Lookups | 19-Jun-2025 | 21-Jul-2025 | -| 2.1.7 | SC089 | Mass Revocation Planning | 23-Jul-2025 | 25-Aug-2025 | -| 2.1.8 | SC092 | Sunset Precertificate Signing CAs | 03-Oct-2025 | 04-Nov-2025 | -| 2.1.9 | SC088 | DNS TXT Record with Persistent Value DCV Method | 09-Oct-2025 | 10-Nov-2025 | +| 1.0.0 | 62 | Version 1.0 of the Baseline Requirements Adopted | 2011-11-22 | 2012-07-01 | +| 1.0.1 | 71 | Revised Auditor Qualifications | 2012-05-08 | 2013-01-01 | +| 1.0.2 | 75 | Non-critical Name Constraints allowed as exception to RFC 5280 | 2012-06-08 | 2012-06-08 | +| 1.0.3 | 78 | Revised Domain/IP Address Validation, High Risk Requests, and Data Sources | 2012-06-22 | 2012-06-22 | +| 1.0.4 | 80 | OCSP responses for non-issued certificates | 2012-08-02 | 2013-02-01 2013-08-01 | +| -- | 83 | Network and Certificate System Security Requirements adopted | 2013-08-03 | 2013-01-01 | +| 1.0.5 | 88 | User-assigned country code of XX allowed | 2012-09-12 | 2012-09-12 | +| 1.1.0 | -- | Published as Version 1.1 with no changes from 1.0.5 | 2012-09-14 | 2012-09-14 | +| 1.1.1 | 93 | Reasons for Revocation and Public Key Parameter checking | 2012-11-07 | 2012-11-07 2013-01-01 | +| 1.1.2 | 96 | Wildcard certificates and new gTLDs | 2013-02-20 | 2013-02-20 2013-09-01 | +| 1.1.3 | 97 | Prevention of Unknown Certificate Contents | 2013-02-21 | 2013-02-21 | +| 1.1.4 | 99 | Add DSA Keys (BR v.1.1.4) | 2013-05-03 | 2013-05-03 | +| 1.1.5 | 102 | Revision to subject domainComponent language in Section 9.2.3 | 2013-05-31 | 2013-05-31 | +| 1.1.6 | 105 | Technical Constraints for Subordinate Certificate Authorities | 2013-07-29 | 2013-07-29 | +| 1.1.7 | 112 | Replace Definition of "Internal Server Name" with "Internal Name" | 2014-04-03 | 2014-04-03 | +| 1.1.8 | 120 | Affiliate Authority to Verify Domain | 2014-06-05 | 2014-06-05 | +| 1.1.9 | 129 | Clarification of PSL mentioned in Section 11.1.3 | 2014-08-04 | 2014-08-04 | +| 1.2.0 | 125 | CAA Records | 2014-10-14 | 2015-04-15 | +| 1.2.1 | 118 | SHA-1 Sunset | 2014-10-16 | 2015-01-16 2016-01-01 2017-01-01 | +| 1.2.2 | 134 | Application of RFC 5280 to Pre-certificates | 2014-10-16 | 2014-10-16 | +| 1.2.3 | 135 | ETSI Auditor Qualifications | 2014-10-16 | 2014-10-16 | +| 1.2.4 | 144 | Validation Rules for .onion Names | 2015-02-18 | 2015-02-18 | +| 1.2.5 | 148 | Issuer Field Correction | 2015-04-02 | 2015-04-02 | +| 1.3.0 | 146 | Convert Baseline Requirements to RFC 3647 Framework | 2015-04-16 | 2015-04-16 | +| 1.3.1 | 151 | Addition of Optional OIDs for Indicating Level of Validation | 2015-09-28 | 2015-09-28 | +| 1.3.2 | 156 | Amend Sections 1 and 2 of Baseline Requirements | 2015-12-03 | 2016-12-03 | +| 1.3.3 | 160 | Amend Section 4 of Baseline Requirements | 2016-02-04 | 2016-02-04 | +| 1.3.4 | 162 | Sunset of Exceptions | 2016-03-15 | 2016-03-15 | +| 1.3.5 | 168 | Baseline Requirements Corrections (Revised) | 2016-05-10 | 2016-05-10 | +| 1.3.6 | 171 | Updating ETSI Standards in CABF documents | 2016-07-01 | 2016-07-01 | +| 1.3.7 | 164 | Certificate Serial Number Entropy | 2016-07-08 | 2016-09-30 | +| 1.3.8 | 169 | Revised Validation Requirements | 2016-08-05 | 2017-03-01 | +| 1.3.9 | 174 | Reform of Requirements Relating to Conflicts with Local Law | 2016-08-29 | 2016-11-27 | +| 1.4.0 | 173 | Removal of requirement to cease use of public key due to incorrect info | 2016-07-28 | 2016-09-11 | +| 1.4.1 | 175 | Addition of givenName and surname | 2016-09-07 | 2016-09-07 | +| 1.4.2 | 181 | Removal of some validation methods listed in Section 3.2.2.4 | 2017-01-07 | 2017-01-07 | +| 1.4.3 | 187 | Make CAA Checking Mandatory | 2017-03-08 | 2017-09-08 | +| 1.4.4 | 193 | 825-day Certificate Lifetimes | 2017-03-17 | 2018-03-01 | +| 1.4.5 | 189 | Amend Section 6.1.7 of Baseline Requirements | 2017-04-14 | 2017-05-14 | +| 1.4.6 | 195 | CAA Fixup | 2017-04-17 | 2017-05-18 | +| 1.4.7 | 196 | Define "Audit Period" | 2017-04-17 | 2017-05-18 | +| 1.4.8 | 199 | Require commonName in Root and Intermediate Certificates | 2017-05-09 | 2017-06-08 | +| 1.4.9 | 204 | Forbid DTPs from doing Domain/IP Ownership | 2017-07-11 | 2017-08-11 | +| 1.5.0 | 212 | Canonicalise formal name of the Baseline Requirements | 2017-09-01 | 2017-10-01 | +| 1.5.1 | 197 | Effective Date of Ballot 193 Provisions | 2017-05-01 | 2017-06-02 | +| 1.5.2 | 190 | Add Validation Methods with Minor Corrections | 2017-09-19 | 2017-10-19 | +| 1.5.3 | 214 | CAA Discovery CNAME Errata | 2017-09-27 | 2017-10-27 | +| 1.5.4 | 215 | Fix Ballot 190 Errata | 2017-10-04 | 2017-11-05 | +| 1.5.5 | 217 | Sunset RFC 2527 | 2017-12-21 | 2018-03-09 | +| 1.5.6 | 218 | Remove validation methods #1 and #5 | 2018-02-05 | 2018-03-09 | +| 1.5.7 | 220 | Minor Cleanups (Spring 2018) | 2018-03-30 | 2018-04-29 | +| 1.5.8 | 219 | Clarify handling of CAA Record Sets with no "issue"/"issuewild" property tag | 2018-04-10 | 2018-05-10 | +| 1.5.9 | 223 | Update BR Section 8.4 for CA audit criteria | 2018-05-15 | 2018-06-14 | +| 1.6.0 | 224 | WhoIs and RDAP | 2018-05-22 | 2018-06-22 | +| 1.6.1 | SC006 | Revocation Timeline Extension | 2018-09-14 | 2018-10-14 | +| 1.6.2 | SC012 | Sunset of Underscores in dNSNames | 2018-11-09 | 2018-12-10 | +| 1.6.3 | SC013 | CAA Contact Property and Associated E-mail Validation Methods | 2018-12-25 | 2019-02-01 | +| 1.6.4 | SC014 | Updated Phone Validation Methods | 2019-01-31 | 2019-03-16 | +| 1.6.4 | SC015 | Remove Validation Method Number 9 | 2019-02-05 | 2019-03-16 | +| 1.6.4 | SC007 | Update IP Address Validation Methods | 2019-02-08 | 2019-03-16 | +| 1.6.5 | SC016 | Other Subject Attributes | 2019-03-15 | 2019-04-16 | +| 1.6.6 | SC019 | Phone Contact with DNS CAA Phone Contact v2 | 2019-05-20 | 2019-09-09 | +| 1.6.7 | SC023 | Precertificates | 2019-11-14 | 2019-12-19 | +| 1.6.7 | SC024 | Fall Cleanup v2 | 2019-11-12 | 2019-12-19 | +| 1.6.8 | SC025 | Define New HTTP Domain Validation Methods v2 | 2020-01-31 | 2020-03-03 | +| 1.6.9 | SC027 | Version 3 Onion Certificates | 2020-02-19 | 2020-03-27 | +| 1.7.0 | SC029 | Pandoc-Friendly Markdown Formatting Changes | 2020-03-20 | 2020-05-04 | +| 1.7.1 | SC030 | Disclosure of Registration / Incorporating Agency | 2020-07-13 | 2020-08-20 | +| 1.7.1 | SC031 | Browser Alignment | 2020-07-16 | 2020-08-20 | +| 1.7.2 | SC033 | TLS Using ALPN Method | 2020-08-14 | 2020-09-22 | +| 1.7.3 | SC028 | Logging and Log Retention | 2020-09-10 | 2020-10-19 | +| 1.7.3 | SC035 | Cleanups and Clarifications | 2020-09-09 | 2020-10-19 | +| 1.7.4 | SC041 | Reformat the BRs, EVGs, and NCSSRs | 2021-02-24 | 2021-04-05 | +| 1.7.5 | SC042 | 398-day Re-use Period | 2021-04-22 | 2021-06-02 | +| 1.7.6 | SC044 | Clarify Acceptable Status Codes | 2021-04-30 | 2021-06-03 | +| 1.7.7 | SC046 | Sunset the CAA Exception for DNS Operator | 2021-06-02 | 2021-07-12 | +| 1.7.8 | SC045 | Wildcard Domain Validation | 2021-06-02 | 2021-07-13 | +| 1.7.9 | SC047 | Sunset subject:organizationalUnitName | 2021-06-30 | 2021-08-16 | +| 1.8.0 | SC048 | Domain Name and IP Address Encoding | 2021-07-22 | 2021-08-25 | +| 1.8.1 | SC050 | Remove the requirements of 4.1.1 | 2021-11-22 | 2021-12-23 | +| 1.8.2 | SC053 | Sunset for SHA-1 OCSP Signing | 2022-01-26 | 2022-03-04 | +| 1.8.3 | SC051 | Reduce and Clarify Log and Records Archival Retention Requirements | 2022-03-01 | 2022-04-15 | +| 1.8.4 | SC054 | Onion Cleanup | 2022-03-24 | 2022-04-23 | +| 1.8.5 | SC056 | 2022 Cleanup | 2022-10-25 | 2022-11-30 | +| 1.8.6 | SC058 | Require distributionPoint in sharded CRLs | 2022-11-07 | 2022-12-11 | +| 1.8.7 | SC061 | New CRL entries must have a Revocation Reason Code | 2023-04-01 | 2023-07-15 | +| 2.0.0 | SC062 | Certificate Profiles Update | 2023-04-22 | 2023-09-15 | +| 2.0.1 | SC063 | Make OCSP optional, require CRLs, and incentivize automation | 2023-08-17 | 2024-03-15 | +| 2.0.2 | SC066 | 2023 Cleanup | 2023-11-23 | 2024-01-08 | +| 2.0.3 | SC069 | Clarify router and firewall logging requirements | 2024-03-13 | 2024-04-15 | +| 2.0.4 | SC065 | Convert EVGs into RFC 3647 format | 2024-03-15 | 2024-05-15 | +| 2.0.5 | SC073 | Compromised and weak keys | 2024-05-03 | 2024-07-01 | +| 2.0.6 | SC075 | Pre-sign linting | 2024-06-28 | 2024-08-06 | +| 2.0.7 | SC067 | Require Multi-Perspective Issuance Corroboration | 2024-08-02 | 2024-09-06 | +| 2.0.8 | SC077 | Update WebTrust Audit name in Section 8.4 and References | 2024-09-02 | 2024-10-02 | +| 2.0.9 | SC078 | Subject organizationName alignment for DBA / Assumed Name | 2024-10-02 | 2024-11-08 | +| 2.1.0 | SC076 | Clarify and improve OCSP requirements | 2024-09-26 | 2024-11-14 | +| 2.1.1 | SC079 | Allow more than one Certificate Policy in a Cross-Certified Subordinate CA Certificate | 2024-09-30 | 2024-11-14 | +| 2.1.2 | SC080 | Strengthen WHOIS lookups and Sunset Methods 3.2.2.4.2 and 3.2.2.4.15 | 2024-11-07 | 2024-12-16 | +| 2.1.3 | SC083 | Winter 2024-2025 Cleanup Ballot | 2025-01-23 | 2025-02-24 | +| 2.1.4 | SC084 | DNS Labeled with ACME Account ID Validation Method | 2025-01-28 | 2025-03-01 | +| 2.1.5 | SC081 | Introduce Schedule of Reducing Validity and Data Reuse Periods | 2025-04-11 | 2025-05-16 | +| 2.1.6 | SC085 | Require Validation of DNSSEC (when present) for CAA and DCV Lookups | 2025-06-19 | 2025-07-21 | +| 2.1.7 | SC089 | Mass Revocation Planning | 2025-07-23 | 2025-08-25 | +| 2.1.8 | SC092 | Sunset Precertificate Signing CAs | 2025-10-03 | 2025-11-04 | +| 2.1.9 | SC088 | DNS TXT Record with Persistent Value DCV Method | 2025-10-09 | 2025-11-10 | \* Effective Date and Additionally Relevant Compliance Date(s) From 5d694339efb8f75e1affc7cfcffdab4336cd2d05 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 2 Dec 2025 21:04:28 +0100 Subject: [PATCH 105/121] #432 fixed and added links to RFC --- docs/BR.md | 224 ++++++++++++++++++++++++++--------------------------- 1 file changed, 112 insertions(+), 112 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index b923e222..c45b9da3 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -23,7 +23,7 @@ This document describes an integrated set of technologies, protocols, identity-p The CP for the Issuance and Management of Publicly-Trusted TLS Server Certificates describe a subset of the requirements that a Certification Authority must meet in order to issue Publicly Trusted TLS Server Certificates. This document serves two purposes: to specify Baseline Requirements and to provide guidance and requirements for what a CA should include in its CPS. Except where explicitly stated otherwise, these Requirements apply only to relevant events that occur on or after 2012-07-01 (the original effective date of these requirements). -These Requirements do not address all of the issues relevant to the issuance and management of Publicly-Trusted TLS Server Certificates. In accordance with RFC 3647 and to facilitate a comparison of other certificate policies and CPSs (e.g. for policy mapping), this document includes all sections of the RFC 3647 framework. However, rather than beginning with a "no stipulation" comment in all empty sections, the CA/Browser Forum is leaving such sections initially blank until a decision of "no stipulation" is made. The CA/Browser Forum may update these Requirements from time to time, in order to address both existing and emerging threats to online security. In particular, it is expected that a future version will contain more formal and comprehensive audit requirements for delegated functions. +These Requirements do not address all of the issues relevant to the issuance and management of Publicly-Trusted TLS Server Certificates. In accordance with [RFC 3647](https://datatracker.ietf.org/doc/html/rfc3647) and to facilitate a comparison of other certificate policies and CPSs (e.g. for policy mapping), this document includes all sections of the [RFC 3647](https://datatracker.ietf.org/doc/html/rfc3647) framework. However, rather than beginning with a "no stipulation" comment in all empty sections, the CA/Browser Forum is leaving such sections initially blank until a decision of "no stipulation" is made. The CA/Browser Forum may update these Requirements from time to time, in order to address both existing and emerging threats to online security. In particular, it is expected that a future version will contain more formal and comprehensive audit requirements for delegated functions. These Requirements only address Certificates intended to be used for authenticating servers accessible through the Internet. Similar requirements for code signing, S/MIME, time-stamping, VoIP, IM, Web services, etc. may be covered in future versions. @@ -287,7 +287,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Base Domain Name**: The portion of an applied-for FQDN that is the first Domain Name node left of a registry-controlled or public suffix plus the registry-controlled or public suffix (e.g. "example.co.uk" or "example.com"). For FQDNs where the right-most Domain Name node is a gTLD having ICANN Specification 13 in its registry agreement, the gTLD itself may be used as the Base Domain Name. -**CAA**: From RFC 8659 (): "The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue." +**CAA**: From [RFC 8659](https://datatracker.ietf.org/doc/html/rfc8659): "The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue." **CA Key Pair**: A Key Pair where the Public Key appears as the Subject Public Key Info in one or more Root CA Certificate(s) and/or Subordinate CA Certificate(s). @@ -329,7 +329,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **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." +**Domain Label**: From [RFC 8499](https://datatracker.ietf.org/doc/html/rfc8499): "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." **Domain Name**: An ordered list of one or more Domain Labels assigned to a node in the Domain Name System. @@ -369,23 +369,23 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Key Pair**: The Private Key and its associated Public Key. -**LDH Label**: From RFC 5890 (): "A string consisting of ASCII letters, digits, and the hyphen with the further restriction that the hyphen cannot appear at the beginning or end of the string. Like all DNS labels, its total length must not exceed 63 octets." +**LDH Label**: From [RFC 5890](https://datatracker.ietf.org/doc/html/rfc5890): "A string consisting of ASCII letters, digits, and the hyphen with the further restriction that the hyphen cannot appear at the beginning or end of the string. Like all DNS labels, its total length must not exceed 63 octets." **Legal Entity**: An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a country's legal system. -**Linting**: A process in which the content of digitally signed data such as a Precertificate [RFC 6962], Certificate, Certificate Revocation List, or OCSP response, or data-to-be-signed object such as a `tbsCertificate` (as described in [RFC 5280, Section 4.1.1.1](https://tools.ietf.org/doc/html/rfc5280##section-4.1.1.1)) is checked for conformance with the profiles and requirements defined in these Requirements. +**Linting**: A process in which the content of digitally signed data such as a Precertificate [RFC 6962](https://datatracker.ietf.org/doc/html/rfc6962), Certificate, Certificate Revocation List, or OCSP response, or data-to-be-signed object such as a `tbsCertificate` (as described in [RFC 5280, Section 4.1.1.1](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.1.1)) is checked for conformance with the profiles and requirements defined in these Requirements. **Multi-Perspective Issuance Corroboration**: A process by which the determinations made during domain validation and CAA checking by the Primary Network Perspective are corroborated by other Network Perspectives before Certificate issuance. **Network Perspective**: Related to Multi-Perspective Issuance Corroboration. A system (e.g., a cloud-hosted server instance) or collection of network components (e.g., a VPN and corresponding infrastructure) for sending outbound Internet traffic associated with a domain control validation method and/or CAA check. The location of a Network Perspective is determined by the point where unencapsulated outbound Internet traffic is typically first handed off to the network infrastructure providing Internet connectivity to that perspective. -**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](https://datatracker.ietf.org/doc/html/rfc5890): "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. **OCSP Responder**: An online server operated under the authority of the CA and connected to its Repository for processing Certificate status requests. See also, Online Certificate Status Protocol. -**Onion Domain Name**: A Fully Qualified Domain Name ending with the RFC 7686 ".onion" Special-Use Domain Name. For example, `2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion` is an Onion Domain Name, whereas `torproject.org` is not an Onion Domain Name. +**Onion Domain Name**: A Fully Qualified Domain Name ending with the [RFC 7686](https://datatracker.ietf.org/doc/html/rfc7686) ".onion" Special-Use Domain Name. For example, `2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion` is an Onion Domain Name, whereas `torproject.org` is not an Onion Domain Name. **Online Certificate Status Protocol**: An online Certificate-checking protocol that enables relying-party application software to determine the status of an identified Certificate. See also OCSP Responder. @@ -395,7 +395,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Persistent DCV TXT Record:** A DNS TXT record identifying an Applicant in accordance with [Section 3.2.2.4.22](#322422-dns-txt-record-with-persistent-value). -**Precertificate**: A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by RFC 6962 and containing the critical poison extension (OID 1.3.6.1.4.1.11129.2.4.3). +**Precertificate**: A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by [RFC 6962](https://datatracker.ietf.org/doc/html/rfc6962) and containing the critical poison extension (OID 1.3.6.1.4.1.11129.2.4.3). **Primary Network Perspective**: The Network Perspective used by the CA to make the determination of 1) the CA's authority to issue a Certificate for the requested domain(s) or IP address(es) and 2) the Applicant's authority and/or domain authorization or control of the requested domain(s) or IP address(es). @@ -407,7 +407,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Publicly-Trusted Certificate**: A Certificate that is trusted by virtue of the fact that its corresponding Root Certificate is distributed as a trust anchor in widely-available application software. -**P-Label**: A XN-Label that contains valid output of the Punycode algorithm (as defined in RFC 3492, Section 6.3) from the fifth and subsequent positions. +**P-Label**: A XN-Label that contains valid output of the Punycode algorithm (as defined in [RFC 3492, Section 6.3](https://datatracker.ietf.org/doc/html/rfc3492#section-6.3)) from the fifth and subsequent positions. **Qualified Auditor**: A natural person or Legal Entity that meets the requirements of [Section 8.2](#82-identityqualifications-of-assessor). @@ -494,19 +494,19 @@ The script outputs: **Unregistered Domain Name**: A Domain Name that is not a Registered Domain Name. -**Valid Certificate**: A Certificate that passes the validation procedure specified in RFC 5280. +**Valid Certificate**: A Certificate that passes the validation procedure specified in [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280). **Validation Specialist**: Someone who performs the information verification duties specified by these Requirements. -**Validity Period**: From RFC 5280 (): "The period of time from notBefore through notAfter, inclusive." +**Validity Period**: From [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280): "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 9082, or an HTTPS website. +**WHOIS**: Information retrieved directly from the Domain Name Registrar or registry operator via the protocol defined in [RFC 3912](https://datatracker.ietf.org/doc/html/rfc3912), the Registry Data Access Protocol defined in [RFC 9082](https://datatracker.ietf.org/doc/html/rfc9082), or an HTTPS website. **Wildcard Certificate**: A Certificate containing at least one Wildcard Domain Name in the Subject Alternative Names in the Certificate. **Wildcard Domain Name**: A string starting with "\*." (U+002A ASTERISK, U+002E FULL STOP) immediately followed by a Fully-Qualified Domain Name. -**XN-Label**: From RFC 5890 (): "The class of labels that begin with the prefix `"xn--"` (case independent), but otherwise conform to the rules for LDH labels." +**XN-Label**: From [RFC 5890](https://datatracker.ietf.org/doc/html/rfc5890): "The class of labels that begin with the prefix `"xn--"` (case independent), but otherwise conform to the rules for LDH labels." ### 1.6.2 Acronyms @@ -557,62 +557,62 @@ 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. S. Bradner. March 1997. +[RFC2119](https://datatracker.ietf.org/doc/html/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. +[RFC3492](https://datatracker.ietf.org/doc/html/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. S. Chokhani, et al. November 2003. +[RFC3647](https://datatracker.ietf.org/doc/html/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. L. Daigle. September 2004. +[RFC3912](https://datatracker.ietf.org/doc/html/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. +[RFC3986](https://datatracker.ietf.org/doc/html/rfc3986), Request for Comments: 3986, Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee, et al. January 2005. -RFC4035, Request for Comments: 4035, Protocol Modifications for the DNS Security Extensions. R. Arends, et al. March 2005. +[RFC4035](https://datatracker.ietf.org/doc/html/rfc4035), Request for Comments: 4035, Protocol Modifications for the DNS Security Extensions. R. Arends, et al. March 2005. -RFC4509, Request for Comments: 4509, Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs). W. Hardaker. May 2006. +[RFC4509](https://datatracker.ietf.org/doc/html/rfc4509), Request for Comments: 4509, Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs). W. Hardaker. May 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](https://datatracker.ietf.org/doc/html/rfc5019), Request for Comments: 5019, The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments. A. Deacon, et al. September 2007. -RFC5155, Request for Comments: 5155, DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. B. Laurie, et al. March 2008. +[RFC5155](https://datatracker.ietf.org/doc/html/rfc5155), Request for Comments: 5155, DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. B. Laurie, et al. March 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. +[RFC5280](https://datatracker.ietf.org/doc/html/rfc5280), Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile. D. Cooper, et al. May 2008. -RFC5702, Request for Comments: 5702, Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC. J. Jansen. October 2009. +[RFC5702](https://datatracker.ietf.org/doc/html/rfc5702), Request for Comments: 5702, Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC. J. Jansen. October 2009. -RFC5890, Request for Comments: 5890, Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. J. Klensin. August 2010. +[RFC5890](https://datatracker.ietf.org/doc/html/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. +[RFC5952](https://datatracker.ietf.org/doc/html/rfc5952), Request for Comments: 5952, A Recommendation for IPv6 Address Text Representation. S. Kawamura, et al. August 2010. -RFC6840, Request for Comments: 6840, Clarifications and Implementation Notes for DNS Security (DNSSEC). S. Weiler, et al. February 2013. +[RFC6840](https://datatracker.ietf.org/doc/html/rfc6840), Request for Comments: 6840, Clarifications and Implementation Notes for DNS Security (DNSSEC). S. Weiler, et al. February 2013. -RFC6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. S. Santesson, et al. June 2013. +[RFC6960](https://datatracker.ietf.org/doc/html/rfc6960), Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. S. Santesson, et al. June 2013. -RFC6962, Request for Comments: 6962, Certificate Transparency. B. Laurie, et al. June 2013. +[RFC6962](https://datatracker.ietf.org/doc/html/rfc6962), Request for Comments: 6962, Certificate Transparency. B. Laurie, et al. June 2013. -RFC7231, Request For Comments: 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, et al. June 2014. +[RFC7231](https://datatracker.ietf.org/doc/html/rfc7231), Request For Comments: 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, et al. June 2014. -RFC7482, Request for Comments: 7482, Registration Data Access Protocol (RDAP) Query Format. A. Newton, et al. March 2015. +[RFC7482](https://datatracker.ietf.org/doc/html/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. +[RFC7538](https://datatracker.ietf.org/doc/html/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. +[RFC8499](https://datatracker.ietf.org/doc/html/rfc8499), Request for Comments: 8499, DNS Terminology. P. Hoffman, et al. January 2019. -RFC8659, Request for Comments: 8659, DNS Certification Authority Authorization (CAA) Resource Record. P. Hallam-Baker, et al. November 2019. +[RFC8659](https://datatracker.ietf.org/doc/html/rfc8659), Request for Comments: 8659, DNS Certification Authority Authorization (CAA) Resource Record. P. Hallam-Baker, et al. November 2019. -RFC8738, Request for Comments: 8738, Automated Certificate Management Environment (ACME) IP Identifier Validation Extension. R.B.Shoemaker, Ed. February 2020. +[RFC8738](https://datatracker.ietf.org/doc/html/rfc8738), Request for Comments: 8738, Automated Certificate Management Environment (ACME) IP Identifier Validation Extension. R.B.Shoemaker, Ed. February 2020. -RFC8954, Request for Comments: 8954, Online Certificate Status Protocol (OCSP) Nonce Extension. M. Sahni, Ed. November 2020. +[RFC8954](https://datatracker.ietf.org/doc/html/rfc8954), Request for Comments: 8954, Online Certificate Status Protocol (OCSP) Nonce Extension. M. Sahni, Ed. November 2020. WebTrust for Certification Authorities, SSL Baseline with Network Security, available at [WebTrust Principles and Criteria for Certification Authorities – SSL Baseline](https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/principles-and-criteria) -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. +[X.509](https://www.itu.int/rec/T-REC-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 -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in these Requirements shall be interpreted in accordance with RFC 2119. +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in these Requirements shall be interpreted in accordance with [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119). By convention, this document omits time and timezones when listing effective requirements such as dates. Except when explicitly specified, the associated time with a date shall be 00:00:00 UTC. @@ -627,7 +627,7 @@ The CA SHALL make revocation information for Subordinate Certificates and Subscr The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see [Section 8.4](#84-topics-covered-by-assessment)). The CA SHALL develop, implement, enforce, and at least once every 366 days update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements. -The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and MUST include all material required by RFC 3647. +The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with [RFC 3647](https://datatracker.ietf.org/doc/html/rfc3647) and MUST include all material required by [RFC 3647](https://datatracker.ietf.org/doc/html/rfc3647). The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version. The CA MAY fulfill this requirement by incorporating these Requirements directly into its Certificate Policy and/or Certification Practice Statements or by incorporating them by reference using a clause such as the following (which MUST include a link to the official version of these Requirements): @@ -758,8 +758,8 @@ Effective 2025-01-15: - When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. - When obtaining Domain Contact information for a requested Domain Name the CA: - - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. - - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. + - if using the WHOIS protocol ([RFC 3912](https://datatracker.ietf.org/doc/html/rfc3912)), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. + - if using the Registry Data Access Protocol ([RFC 7482](https://datatracker.ietf.org/doc/html/rfc7482)), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. Effective 2025-07-15: @@ -845,13 +845,13 @@ Effective 2025-01-15: - When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. - When obtaining Domain Contact information for a requested Domain Name the CA: - - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. - - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. + - if using the WHOIS protocol ([RFC 3912](https://datatracker.ietf.org/doc/html/rfc3912)), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. + - if using the Registry Data Access Protocol ([RFC 7482](https://datatracker.ietf.org/doc/html/rfc7482)), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. ##### 3.2.2.4.13 Email to DNS CAA Contact -Confirming the Applicant's control over the FQDN by sending a Random Value via email and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to a DNS CAA Email Contact. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 8659, Section 3. +Confirming the Applicant's control over the FQDN by sending a Random Value via email and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to a DNS CAA Email Contact. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in [RFC 8659, Section 3](https://datatracker.ietf.org/doc/html/rfc8659#section-3). Each email MAY confirm control of multiple FQDNs, provided that each email address is a DNS CAA Email Contact for each Authorization Domain Name being validated. The same email MAY be sent to multiple recipients as long as all recipients are DNS CAA Email Contacts for each Authorization Domain Name being validated. @@ -889,8 +889,8 @@ Effective 2025-01-15: - When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period. - When obtaining Domain Contact information for a requested Domain Name the CA: - - if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. - - if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. + - if using the WHOIS protocol ([RFC 3912](https://datatracker.ietf.org/doc/html/rfc3912)), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server. + - if using the Registry Data Access Protocol ([RFC 7482](https://datatracker.ietf.org/doc/html/rfc7482)), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain. - MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information. Effective 2025-07-15: @@ -914,7 +914,7 @@ CAs performing validations using this method MUST implement Multi-Perspective Is ##### 3.2.2.4.17 Phone Contact with DNS CAA Phone Contact -Confirm the Applicant's control over the FQDN by calling the DNS CAA 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 CAA Phone Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 8659 Section 3. +Confirm the Applicant's control over the FQDN by calling the DNS CAA 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 CAA Phone Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in [RFC 8659, Section 3](https://datatracker.ietf.org/doc/html/rfc8659#section-3). The CA MUST NOT be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation. @@ -943,8 +943,8 @@ The file containing the Request Token or Random Value: If the CA follows redirects, the following apply: 1. Redirects MUST be initiated at the HTTP protocol layer. - a. For validations performed on or after 2021-07-01, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4), or a 308 HTTP status code response, as defined in [RFC 7538, Section 3](https://tools.ietf.org/html/rfc7538#section-3). Redirects MUST be to the final value of the Location HTTP response header, as defined in [RFC 7231, Section 7.1.2](https://tools.ietf.org/html/rfc7231#section-7.1.2). - b. For validations performed prior to 2021-07-01, redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4). CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a. + a. For validations performed on or after 2021-07-01, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in [RFC 7231, Section 6.4](https://datatracker.ietf.org/doc/html/rfc7231#section-6.4), or a 308 HTTP status code response, as defined in [RFC 7538, Section 3](https://datatracker.ietf.org/doc/html/rfc7538#section-3). Redirects MUST be to the final value of the Location HTTP response header, as defined in [RFC 7231, Section 7.1.2](https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.2). + b. For validations performed prior to 2021-07-01, redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in [RFC 7231, Section 6.4](https://datatracker.ietf.org/doc/html/rfc7231#section-6.4). CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a. 2. Redirects MUST be to resource URLs with either the "http" or "https" scheme. 3. Redirects MUST be to resource URLs accessed via Authorized Ports. @@ -959,17 +959,17 @@ Except for Onion Domain Names, CAs performing validations using this method MUST ##### 3.2.2.4.19 Agreed-Upon Change to Website - ACME -Confirming the Applicant's control over a FQDN by validating domain control of the FQDN using the ACME HTTP Challenge method defined in Section 8.3 of RFC 8555. The following are additive requirements to RFC 8555. +Confirming the Applicant's control over a FQDN by validating domain control of the FQDN using the ACME HTTP Challenge method defined in [RFC 8555, Section 8.3](https://datatracker.ietf.org/doc/html/rfc8555#section-8.3). The following are additive requirements to [RFC 8555](https://datatracker.ietf.org/doc/html/rfc8555). The CA MUST receive a successful HTTP response from the request (meaning a 2xx HTTP status code must be received). -The token (as defined in RFC 8555, Section 8.3) MUST NOT be used for 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. +The token (as defined in [RFC 8555, Section 8.3](https://datatracker.ietf.org/doc/html/rfc8555#section-8.3)) MUST NOT be used for 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. If the CA follows redirects, the following apply: 1. Redirects MUST be initiated at the HTTP protocol layer. - a. For validations performed on or after 2021-07-01, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4), or a 308 HTTP status code response, as defined in [RFC 7538, Section 3](https://tools.ietf.org/html/rfc7538#section-3). Redirects MUST be to the final value of the Location HTTP response header, as defined in [RFC 7231, Section 7.1.2](https://tools.ietf.org/html/rfc7231#section-7.1.2). - b. For validations performed prior to 2021-07-01, redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in [RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4). CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a. + a. For validations performed on or after 2021-07-01, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in [RFC 7231, Section 6.4](https://datatracker.ietf.org/doc/html/rfc7231#section-6.4), or a 308 HTTP status code response, as defined in [RFC 7538, Section 3](https://datatracker.ietf.org/doc/html/rfc7538#section-3). Redirects MUST be to the final value of the Location HTTP response header, as defined in [RFC 7231, Section 7.1.2](https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.2). + b. For validations performed prior to 2021-07-01, redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in [RFC 7231, Section 6.4](https://datatracker.ietf.org/doc/html/rfc7231#section-6.4). CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a. 2. Redirects MUST be to resource URLs with either the "http" or "https" scheme. 3. Redirects MUST be to resource URLs accessed via Authorized Ports. @@ -979,9 +979,9 @@ Except for Onion Domain Names, CAs performing validations using this method MUST ##### 3.2.2.4.20 TLS Using ALPN -Confirming the Applicant's control over a FQDN by validating domain control of the FQDN by negotiating a new application layer protocol using the TLS Application-Layer Protocol Negotiation (ALPN) Extension [RFC7301] as defined in RFC 8737. The following are additive requirements to RFC 8737. +Confirming the Applicant's control over a FQDN by validating domain control of the FQDN by negotiating a new application layer protocol using the TLS Application-Layer Protocol Negotiation (ALPN) Extension [RFC7301](https://datatracker.ietf.org/doc/html/rfc7301) as defined in [RFC 8737](https://datatracker.ietf.org/doc/html/rfc8737). The following are additive requirements to [RFC 8737](https://datatracker.ietf.org/doc/html/rfc8737). -The token (as defined in RFC 8737, Section 3) MUST NOT be used for more than 30 days from its creation. The CPS MAY specify a shorter validity period for the token, in which case the CA MUST follow its CPS. +The token (as defined in [RFC 8737, Section 3](https://datatracker.ietf.org/doc/html/rfc8737#section-3)) MUST NOT be used for more than 30 days from its creation. The CPS MAY specify a shorter validity period for the token, in which case the CA MUST follow its CPS. Except for Onion Domain Names, CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. token) as the Primary Network Perspective. @@ -1003,9 +1003,9 @@ Confirming the Applicant's control over a FQDN by verifying the presence of a Pe The CA MUST confirm the Persistent DCV TXT Record's RDATA value fulfills the following requirements: -1. The RDATA value MUST conform to the `issue-value` syntax as defined in RFC 8659, Section 4.2; and +1. The RDATA value MUST conform to the `issue-value` syntax as defined in [RFC 8659, Section 4.2](https://datatracker.ietf.org/doc/html/rfc8659#section-4.2); and 2. The `issuer-domain-name` value MUST be an Issuer Domain Name disclosed by the CA in Section 4.2 of the CA's Certificate Policy and/or Certification Practices Statement; and -3. The `issue-value` MUST contain an `accounturi` parameter, where the parameter value is a unique URI (as described by RFC 8657, Section 3) identifying the account of the Applicant which requested validation for this FQDN; and +3. The `issue-value` MUST contain an `accounturi` parameter, where the parameter value is a unique URI (as described by [RFC 8657, Section 3](https://datatracker.ietf.org/doc/html/rfc8657#section-3)) identifying the account of the Applicant which requested validation for this FQDN; and 4. The `issue-value` MAY contain a `persistUntil` parameter. If present, the parameter value MUST be a base-10 encoded integer representing a UNIX timestamp (the number of seconds since 1970-01-01T00:00:00Z ignoring leap seconds); and 5. The `issue-value` MAY contain additional parameters. CAs MUST ignore any unknown parameter keys. @@ -1089,20 +1089,20 @@ The Random Value SHALL remain valid for use in a confirming response for no more ##### 3.2.2.5.6 ACME "http-01" method for IP Addresses -Confirming the Applicant's control over the IP Address by performing the procedure documented for an "http-01" challenge in RFC 8738. +Confirming the Applicant's control over the IP Address by performing the procedure documented for an "http-01" challenge in [RFC 8738](https://datatracker.ietf.org/doc/html/rfc8738). CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. token) as the Primary Network Perspective. ##### 3.2.2.5.7 ACME "tls-alpn-01" method for IP Addresses -Confirming the Applicant's control over the IP Address by performing the procedure documented for a "tls-alpn-01" challenge in RFC 8738. +Confirming the Applicant's control over the IP Address by performing the procedure documented for a "tls-alpn-01" challenge in [RFC 8738](https://datatracker.ietf.org/doc/html/rfc8738). CAs performing validations using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same challenge information (i.e. token) as the Primary Network Perspective. #### 3.2.2.6 Wildcard Domain Validation Before issuing a Wildcard Certificate, the CA MUST establish and follow a documented procedure that determines if the FQDN portion of any -Wildcard Domain Name in the Certificate is "registry-controlled" or is a "public suffix" (e.g. "\*.com", "\*.co.uk", see RFC 6454 Section 8.2 for further explanation). +Wildcard Domain Name in the Certificate is "registry-controlled" or is a "public suffix" (e.g. "\*.com", "\*.co.uk", see [RFC 6454 Section 8.2](https://datatracker.ietf.org/doc/html/rfc6454#section-8.2) for further explanation). If the FQDN portion of any Wildcard Domain Name is "registry-controlled" or is a "public suffix", CAs MUST refuse issuance unless the Applicant proves its rightful control of the entire Domain Namespace. (e.g. CAs MUST NOT issue "\*.co.uk" or "\*.local", but MAY issue "\*.example.com" to Example Co.). @@ -1124,17 +1124,17 @@ Databases maintained by the CA, its owner, or its affiliated companies do not qu #### 3.2.2.8 CAA Records -As part of the Certificate issuance process, the CA MUST retrieve and process CAA records in accordance with RFC 8659 for each `dNSName` in the `subjectAltName` extension that does not contain an Onion Domain Name. These practices MUST be described in Section 4.2 of the CA's Certificate Policy and/or Certification Practice Statement, including specifying the set of Issuer Domain Names that the CA recognizes in CAA "issue" or "issuewild" records as permitting it to issue. +As part of the Certificate issuance process, the CA MUST retrieve and process CAA records in accordance with [RFC 8659](https://datatracker.ietf.org/doc/html/rfc8659) for each `dNSName` in the `subjectAltName` extension that does not contain an Onion Domain Name. These practices MUST be described in Section 4.2 of the CA's Certificate Policy and/or Certification Practice Statement, including specifying the set of Issuer Domain Names that the CA recognizes in CAA "issue" or "issuewild" records as permitting it to issue. Some methods relied upon for validating the Applicant's ownership or control of the subject domain(s) (see [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control)) or IP address(es) (see [Section 3.2.2.5](#3225-authentication-for-an-ip-address)) to be listed in a certificate require CAA records to be retrieved and processed from additional remote Network Perspectives before Certificate issuance (see [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration)). To corroborate the Primary Network Perspective, a remote Network Perspective's CAA check response MUST be interpreted as permission to issue, regardless of whether the responses from both Perspectives are byte-for-byte identical. Additionally, a CA MAY consider the response from a remote Network Perspective as corroborating if one or both of the Perspectives experience an acceptable CAA record lookup failure, as defined in this section. CAs MAY check CAA records at any other time. -When processing CAA records, CAs MUST process the issue, issuewild, and iodef property tags as specified in RFC 8659, although they are not required to act on the contents of the iodef property tag. Additional property tags MAY be supported, but MUST NOT conflict with or supersede the mandatory property tags set out in this document. CAs MUST respect the critical flag and not issue a certificate if they encounter an unrecognized property tag with this flag set. +When processing CAA records, CAs MUST process the issue, issuewild, and iodef property tags as specified in [RFC 8659](https://datatracker.ietf.org/doc/html/rfc8659), although they are not required to act on the contents of the iodef property tag. Additional property tags MAY be supported, but MUST NOT conflict with or supersede the mandatory property tags set out in this document. CAs MUST respect the critical flag and not issue a certificate if they encounter an unrecognized property tag with this flag set. If the CA issues a certificate after processing a CAA record, it MUST do so within the TTL of the CAA record, or 8 hours, whichever is greater. -RFC 8659 requires that CAs "MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA RRset or (2) an exception specified in the relevant CP or CPS applies." For issuances conforming to these Baseline Requirements, CAs MUST NOT rely on any exceptions specified in their CP or CPS unless they are one of the following: +[RFC 8659](https://datatracker.ietf.org/doc/html/rfc8659) requires that CAs "MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA RRset or (2) an exception specified in the relevant CP or CPS applies." For issuances conforming to these Baseline Requirements, CAs MUST NOT rely on any exceptions specified in their CP or CPS unless they are one of the following: - CAA checking is optional for certificates for which a Certificate Transparency Precertificate (see [Section 7.1.2.9](#7129-precertificate-profile)) was created and logged in at least two public logs, and for which CAA was checked at time of Precertificate issuance. - CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant. @@ -1143,7 +1143,7 @@ CAs are permitted to treat a record lookup failure as permission to issue if: - the failure is outside the CA's infrastructure; and - the lookup has been retried at least once; and -- the CA has confirmed that the domain is "Insecure" as defined in [RFC 4035 Section 4.3](https://datatracker.ietf.org/doc/html/rfc4035#section-4.3). +- the CA has confirmed that the domain is "Insecure" as defined in [RFC 4035, Section 4.3](https://datatracker.ietf.org/doc/html/rfc4035#section-4.3). CAs MUST document potential issuances that were prevented by a CAA record in sufficient detail to provide feedback to the CA/Browser Forum on the circumstances, and SHOULD dispatch reports of such issuance requests to the contact(s) stipulated in the CAA iodef record(s), if present. CAs are not expected to support URL schemes in the iodef record other than mailto: or https:. @@ -1151,10 +1151,10 @@ CAs MUST document potential issuances that were prevented by a CAA record in suf Effective 2026-03-15: DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with CAA record lookups performed by the Primary Network Perspective MUST: -- perform DNSSEC validation using the algorithm defined in [RFC 4035 Section 5](https://datatracker.ietf.org/doc/html/rfc4035#section-5); and +- perform DNSSEC validation using the algorithm defined in [RFC 4035, Section 5](https://datatracker.ietf.org/doc/html/rfc4035#section-5); and - support NSEC3 as defined in [RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155); and - support SHA-2 as defined in [RFC 4509](https://datatracker.ietf.org/doc/html/rfc4509) and [RFC 5702](https://datatracker.ietf.org/doc/html/rfc5702); and -- properly handle the security concerns enumerated in [RFC 6840 Section 4](https://datatracker.ietf.org/doc/html/rfc6840#section-4). +- properly handle the security concerns enumerated in [RFC 6840, Section 4](https://datatracker.ietf.org/doc/html/rfc6840#section-4). Effective 2026-03-15: CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. @@ -1225,7 +1225,7 @@ SHOULD: - Network Hardening - Configure each network boundary control (firewall, switch, router, gateway, or other network control device or system) with rules that support only the services, protocols, ports, and communications identified as necessary to its operations. - - Rely upon networks (e.g., Internet Service Providers) that: 1) use mechanisms based on Secure Inter-Domain Routing (RFC 6480), for example, BGP Prefix Origin Validation (RFC 6811), 2) make use of other non-RPKI route-leak prevention mechanisms (such as RFC 9234), and 3) apply current best practices described in BCP 194. While It is RECOMMENDED that under normal operating conditions Network Perspectives performing Multi-Perspective Issuance Corroboration forward all Internet traffic via a network or set of networks that filter RPKI-invalid BGP routes as defined by RFC 6811, it is NOT REQUIRED. + - Rely upon networks (e.g., Internet Service Providers) that: 1) use mechanisms based on Secure Inter-Domain Routing ([RFC 6480](https://datatracker.ietf.org/doc/html/rfc6480)), for example, BGP Prefix Origin Validation ([RFC 6811](https://datatracker.ietf.org/doc/html/rfc6811)), 2) make use of other non-RPKI route-leak prevention mechanisms (such as [RFC 9234](https://datatracker.ietf.org/doc/html/rfc9234)), and 3) apply current best practices described in BCP 194. While It is RECOMMENDED that under normal operating conditions Network Perspectives performing Multi-Perspective Issuance Corroboration forward all Internet traffic via a network or set of networks that filter RPKI-invalid BGP routes as defined by [RFC 6811](https://datatracker.ietf.org/doc/html/rfc6811), it is NOT REQUIRED. Beyond the above considerations, computing systems performing Multi-Perspective Issuance Corroboration are considered outside of the audit scope described in Section 8 of these Requirements. @@ -1354,7 +1354,7 @@ Certificate issuance by the Root CA SHALL require an individual authorized by th #### 4.3.1.2 Linting of to-be-signed Certificate content -Due to the complexity involved in implementing Certificate Profiles that conform to these Requirements, it is considered best practice for the CA to implement a Linting process to test the technical conformity of each to-be-signed artifact prior to signing it. When a Precertificate has undergone Linting, it is not necessary for the corresponding to-be-signed Certificate to also undergo Linting, provided that the CA has a technical control to verify that the to-be-signed Certificate corresponds to the to-be-signed Precertificate in the manner described by RFC 6962, Section 3.2. +Due to the complexity involved in implementing Certificate Profiles that conform to these Requirements, it is considered best practice for the CA to implement a Linting process to test the technical conformity of each to-be-signed artifact prior to signing it. When a Precertificate has undergone Linting, it is not necessary for the corresponding to-be-signed Certificate to also undergo Linting, provided that the CA has a technical control to verify that the to-be-signed Certificate corresponds to the to-be-signed Precertificate in the manner described by [RFC 6962, Section 3.2](https://datatracker.ietf.org/doc/html/rfc6962#section-3.2). Effective 2025-03-15, the CA SHALL implement such a Linting process. Methods used to produce a certificate containing the to-be-signed Certificate content include, but are not limited to: @@ -1612,7 +1612,7 @@ A certificate serial is "unassigned" if it is not "assigned". The following SHALL apply for communicating the status of Certificates and Precertificates which include an Authority Information Access extension with an id-ad-ocsp accessMethod. -OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019. The CA MAY process the Nonce extension (`1.3.6.1.5.5.7.48.1.2`) in accordance with RFC 8954. +OCSP responders operated by the CA SHALL support the HTTP GET method, as described in [RFC 6960](https://datatracker.ietf.org/doc/html/rfc6960) and/or [RFC 5019](https://datatracker.ietf.org/doc/html/rfc5019). The CA MAY process the Nonce extension (`1.3.6.1.5.5.7.48.1.2`) in accordance with [RFC 8954](https://datatracker.ietf.org/doc/html/rfc8954). For the status of a Subscriber Certificate or its corresponding Precertificate: @@ -1624,7 +1624,7 @@ For the status of a Subordinate CA Certificate, the CA SHALL provide an updated The following SHALL apply for communicating the status of *all* Certificates for which an OCSP responder is willing or required to respond. -OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST either: +OCSP responses MUST conform to [RFC 6960](https://datatracker.ietf.org/doc/html/rfc6960) and/or [RFC 5019](https://datatracker.ietf.org/doc/html/rfc5019). OCSP responses MUST either: 1. be signed by the CA that issued the Certificates whose revocation status is being checked, or 2. be signed by an OCSP Responder which complies with the OCSP Responder Certificate Profile in [Section 7.1.2.8](#7128-ocsp-responder-certificate-profile). @@ -2009,7 +2009,7 @@ The CA SHALL reject a certificate request if one or more of the following condit Suggested tools for checking for weak keys can be found here: -If the Subscriber Certificate will contain an `extKeyUsage` extension containing either the values `id-kp-serverAuth` [RFC5280] or `anyExtendedKeyUsage` [RFC5280], the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA. +If the Subscriber Certificate will contain an `extKeyUsage` extension containing either the values `id-kp-serverAuth` [RF 5280](https://datatracker.ietf.org/doc/html/rfc5280) or `anyExtendedKeyUsage` [RF 5280](https://datatracker.ietf.org/doc/html/rfc5280), the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA. ### 6.1.2 Private key delivery to subscriber @@ -2153,7 +2153,7 @@ Certificates MUST be of type X.509 v3. ### 7.1.2 Certificate Content and Extensions -If the CA asserts compliance with these Baseline Requirements, all certificates that it issues MUST comply with one of the following certificate profiles, which incorporate, and are derived from [RFC 5280](https://tools.ietf.org/html/rfc5280). Except as explicitly noted, all normative requirements imposed by RFC 5280 shall apply, in addition to the normative requirements imposed by this document. CAs SHOULD examine [RFC 5280, Appendix B](https://tools.ietf.org/html/rfc5280#appendix-B) for further issues to be aware of. +If the CA asserts compliance with these Baseline Requirements, all certificates that it issues MUST comply with one of the following certificate profiles, which incorporate, and are derived from [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280). Except as explicitly noted, all normative requirements imposed by [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) shall apply, in addition to the normative requirements imposed by this document. CAs SHOULD examine [RFC 5280, Appendix B](https://datatracker.ietf.org/doc/html/rfc5280#appendix-B) for further issues to be aware of. - CA Certificates - [Section 7.1.2.1 - Root CA Certificate Profile](#7121-root-ca-certificate-profile) @@ -2297,7 +2297,7 @@ Table: Cross-Certified Subordinate CA with Restricted EKU | --- | -- | -- | --- | | `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.2.5](#71225-cross-certified-subordinate-ca-extended-key-usage---restricted) | -[^eku_ca]: While [RFC 5280, Section 4.2.1.12](https://tools.ietf.org/html/rfc5280#section-4.2.1.12) notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers. +[^eku_ca]: While [RFC 5280, Section 4.2.1.12](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12) notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers. [^name_constraints]: See [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) for further requirements, including regarding criticality of this extension. @@ -2462,11 +2462,11 @@ The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to #### 7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile -This Certificate Profile MUST be used when issuing a CA Certificate that will be used as a Precertificate Signing CA, as described in [RFC 6962, Section 3.1](https://tools.ietf.org/html/rfc6962#section-3.1). If a CA Certificate conforms to this profile, it is considered Technically Constrained. +This Certificate Profile MUST be used when issuing a CA Certificate that will be used as a Precertificate Signing CA, as described in [RFC 6962, Section 3.1](https://datatracker.ietf.org/doc/html/rfc6962#section-3.1). If a CA Certificate conforms to this profile, it is considered Technically Constrained. -A Precertificate Signing CA MUST only be used to sign Precertificates, as defined in [Section 7.1.2.9](#7129-precertificate-profile). When a Precertificate Signing CA issues a Precertificate, it shall be interpreted as if the Issuing CA of the Precertificate Signing CA has issued a Certificate with a matching `tbsCertificate` of the Precertificate, after applying the modifications specified in [RFC 6962, Section 3.2](https://tools.ietf.org/html/rfc6962#section-3.2). +A Precertificate Signing CA MUST only be used to sign Precertificates, as defined in [Section 7.1.2.9](#7129-precertificate-profile). When a Precertificate Signing CA issues a Precertificate, it shall be interpreted as if the Issuing CA of the Precertificate Signing CA has issued a Certificate with a matching `tbsCertificate` of the Precertificate, after applying the modifications specified in [RFC 6962, Section 3.2](https://datatracker.ietf.org/doc/html/rfc6962#section-3.2). -As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is not altered as part of these modifications. As such, the Precertificate Signing CA MUST use the same signature algorithm as the Issuing CA when issuing Precertificates, and, correspondingly, MUST use a public key of the same public key algorithm as the Issuing CA, although MAY use a different CA Key Pair. +As noted in [RFC 6962, Section 3.2](https://datatracker.ietf.org/doc/html/rfc6962#section-3.2), the `signature` field of a Precertificate is not altered as part of these modifications. As such, the Precertificate Signing CA MUST use the same signature algorithm as the Issuing CA when issuing Precertificates, and, correspondingly, MUST use a public key of the same public key algorithm as the Issuing CA, although MAY use a different CA Key Pair. | **Field** | **Description** | | ---- | ------ | @@ -2550,7 +2550,7 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be ##### 7.1.2.5.2 Technically Constrained TLS Subordinate CA Name Constraints -For a TLS Subordinate CA to be Technically Constrained, Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatibility with certain legacy applications that do not support Name Constraints is necessary. +For a TLS Subordinate CA to be Technically Constrained, Name Constraints extension MUST be encoded as follows. As an explicit exception from [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280), this extension SHOULD be marked critical, but MAY be marked non-critical if compatibility with certain legacy applications that do not support Name Constraints is necessary. Table: `nameConstraints` requirements @@ -2818,7 +2818,7 @@ Table: Permitted `policyQualifiers` | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | -[^first_policy_note]: Although RFC 5280 allows `PolicyInformation`s to appear in any order, several client implementations have implemented logic that considers the `policyIdentifier` that matches a given filter. As such, ensuring the Reserved Certificate Policy Identifier is the first `PolicyInformation` reduces the risk of interoperability challenges. +[^first_policy_note]: Although [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) allows `PolicyInformation`s to appear in any order, several client implementations have implemented logic that considers the `policyIdentifier` that matches a given filter. As such, ensuring the Reserved Certificate Policy Identifier is the first `PolicyInformation` reduces the risk of interoperability challenges. ##### 7.1.2.7.10 Subscriber Certificate Extended Key Usage @@ -2874,7 +2874,7 @@ Table: Key Usage for ECC Public Keys For Subscriber Certificates, the Subject Alternative Name MUST be present and MUST contain at least one `dNSName` or `iPAddress` `GeneralName`. See below for further requirements about the permitted fields and their validation requirements. -If the `subject` field of the certificate is an empty SEQUENCE, this extension MUST be marked critical, as specified in [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6). Otherwise, this extension MUST NOT be marked critical. +If the `subject` field of the certificate is an empty SEQUENCE, this extension MUST be marked critical, as specified in [RFC 5280, Section 4.2.1.6](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6). Otherwise, this extension MUST NOT be marked critical. Table: `GeneralName` within a `subjectAltName` extension @@ -2890,11 +2890,11 @@ Table: `GeneralName` within a `subjectAltName` extension | `iPAddress` | Y | The entry MUST contain the IPv4 or IPv6 address that the CA has confirmed the Applicant controls or has been granted the right to use through a method specified in [Section 3.2.2.5](#3225-authentication-for-an-ip-address). The entry MUST NOT contain a Reserved IP Address. | | `registeredID` | N | - | -**Note**: As an explicit exception from RFC 5280, P-Labels are permitted to not conform to IDNA 2003. These Requirements allow for the inclusion of P-Labels that do not conform with IDNA 2003 to support newer versions of the Unicode character repertoire, among other improvements to the various IDNA standards. +**Note**: As an explicit exception from [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280), P-Labels are permitted to not conform to IDNA 2003. These Requirements allow for the inclusion of P-Labels that do not conform with IDNA 2003 to support newer versions of the Unicode character repertoire, among other improvements to the various IDNA standards. #### 7.1.2.8 OCSP Responder Certificate Profile -If the Issuing CA does not directly sign OCSP responses, it MAY make use of an OCSP Authorized Responder, as defined by [RFC 6960](https://tools.ietf.org/html/rfc6960#section-4.2.2.2). The Issuing CA of the Responder MUST be the same as the Issuing CA for the Certificates it provides responses for. +If the Issuing CA does not directly sign OCSP responses, it MAY make use of an OCSP Authorized Responder, as defined by [RFC 6960, Section 4.2.2.2](https://datatracker.ietf.org/doc/html/rfc6960#section-4.2.2.2). The Issuing CA of the Responder MUST be the same as the Issuing CA for the Certificates it provides responses for. | **Field** | **Description** | | --- | ------ | @@ -2970,7 +2970,7 @@ OCSP Responder certificates MUST NOT be CA certificates. The issuing CA may indi The CA MUST include the `id-pkix-ocsp-nocheck` extension (OID: 1.3.6.1.5.5.7.48.1.5). -This extension MUST have an `extnValue` `OCTET STRING` which is exactly the hex-encoded bytes `0500`, the encoded representation of the ASN.1 NULL value, as specified in [RFC 6960, Section 4.2.2.2.1](https://tools.ietf.org/html/rfc6960#section-4.2.2.2.1). +This extension MUST have an `extnValue` `OCTET STRING` which is exactly the hex-encoded bytes `0500`, the encoded representation of the ASN.1 NULL value, as specified in [RFC 6960, Section 4.2.2.2.1](https://datatracker.ietf.org/doc/html/rfc6960#section-4.2.2.2.1). ##### 7.1.2.8.7 OCSP Responder Key Usage @@ -3009,11 +3009,11 @@ Table: Permitted `policyQualifiers` #### 7.1.2.9 Precertificate Profile -A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by [RFC 6962](https://tools.ietf.org/doc/html/rfc6962). A Precertificate appears structurally identical to a Certificate, with the exception of a special critical poison extension in the `extensions` field, with the OID of `1.3.6.1.4.1.11129.2.4.3`. This extension ensures that the Precertificate will not be accepted as a Certificate by clients conforming to [RFC 5280](https://tools.ietf.org/doc/html/rfc5280). The existence of a signed Precertificate can be treated as evidence of a corresponding Certificate also existing, as the signature represents a binding commitment by the CA that it may issue such a Certificate. +A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by [RFC 6962](https://datatracker.ietf.org/doc/html/rfc6962). A Precertificate appears structurally identical to a Certificate, with the exception of a special critical poison extension in the `extensions` field, with the OID of `1.3.6.1.4.1.11129.2.4.3`. This extension ensures that the Precertificate will not be accepted as a Certificate by clients conforming to [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280). The existence of a signed Precertificate can be treated as evidence of a corresponding Certificate also existing, as the signature represents a binding commitment by the CA that it may issue such a Certificate. A Precertificate is created after a CA has decided to issue a Certificate, but prior to the actual signing of the Certificate. The CA MAY construct and sign a Precertificate corresponding to the Certificate, for purposes of submitting to Certificate Transparency Logs. The CA MAY use the returned Signed Certificate Timestamps to then alter the Certificate's `extensions` field, adding a Signed Certificate Timestamp List, as defined in [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) and as permitted by the relevant profile, prior to signing the Certificate. -Once a Precertificate is signed, relying parties are permitted to treat this as a binding commitment from the CA of the intent to issue a corresponding Certificate, or more commonly, that a corresponding Certificate exists. A Certificate is said to be corresponding to a Precertificate based upon the value of the `tbsCertificate` contents, as transformed by the process defined in [RFC 6962, Section 3.2](https://tools.ietf.org/doc/html/rfc6962#section-3.2). +Once a Precertificate is signed, relying parties are permitted to treat this as a binding commitment from the CA of the intent to issue a corresponding Certificate, or more commonly, that a corresponding Certificate exists. A Certificate is said to be corresponding to a Precertificate based upon the value of the `tbsCertificate` contents, as transformed by the process defined in [RFC 6962, Section 3.2](https://datatracker.ietf.org/doc/html/rfc6962#section-3.2). This profile describes the transformations that are permitted to a Certificate to construct a Precertificate. CAs MUST NOT issue a Precertificate unless they are willing to issue a corresponding Certificate, regardless of whether they have done so. Similarly, a CA MUST NOT issue a Precertificate unless the corresponding Certificate conforms to these Baseline Requirements, regardless of whether the CA signs the corresponding Certificate. @@ -3055,7 +3055,7 @@ Table: When the Precertificate is issued by a Precertificate Signing CA on behal | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | -**Note**: This profile requires that the `serialNumber` field of the Precertificate be identical to that of the corresponding Certificate. [RFC 5280, Section 4.1.2.2](https://tools.ietf.org/doc/html/rfc5280#section-4.1.2.2) requires that the `serialNumber` of certificates be unique. For the purposes of this document, a Precertificate shall not be considered a "certificate" subject to that requirement, and thus may have the same `serialNumber` of the corresponding Certificate. However, this does not permit two Precertificates to share the same `serialNumber`, unless they correspond to the same Certificate, as this would otherwise indicate there are two corresponding Certificates that share the same `serialNumber`. +**Note**: This profile requires that the `serialNumber` field of the Precertificate be identical to that of the corresponding Certificate. [RFC 5280, Section 4.1.2.2](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.2) requires that the `serialNumber` of certificates be unique. For the purposes of this document, a Precertificate shall not be considered a "certificate" subject to that requirement, and thus may have the same `serialNumber` of the corresponding Certificate. However, this does not permit two Precertificates to share the same `serialNumber`, unless they correspond to the same Certificate, as this would otherwise indicate there are two corresponding Certificates that share the same `serialNumber`. ##### 7.1.2.9.1 Precertificate Profile Extensions - Directly Issued @@ -3071,7 +3071,7 @@ These extensions apply in the context of a Precertificate directly issued from a ##### 7.1.2.9.2 Precertificate Profile Extensions - Precertificate CA Issued -These extensions apply in the context of a Precertificate from a Precertificate Signing CA Certificate, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile). For such Precertificates, the `authorityKeyIdentifier`, if present in the Certificate, is modified in the Precertificate, as described in [RFC 6962, Section 3.2](https://tools.ietf.org/doc/html/rfc6962#section-3.2). +These extensions apply in the context of a Precertificate from a Precertificate Signing CA Certificate, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile). For such Precertificates, the `authorityKeyIdentifier`, if present in the Certificate, is modified in the Precertificate, as described in [RFC 6962, Section 3.2](https://datatracker.ietf.org/doc/html/rfc6962#section-3.2). | **Extension** | **Presence** | **Critical** | **Description** | | ---- | - | - | ---- | @@ -3084,7 +3084,7 @@ These extensions apply in the context of a Precertificate from a Precertificate The Precertificate MUST contain the Precertificate Poison extension (OID: 1.3.6.1.4.1.11129.2.4.3). -This extension MUST have an `extnValue` `OCTET STRING` which is exactly the hex-encoded bytes `0500`, the encoded representation of the ASN.1 NULL value, as specified in [RFC 6962, Section 3.1](https://tools.ietf.org/doc/html/rfc6962#section-3.1). +This extension MUST have an `extnValue` `OCTET STRING` which is exactly the hex-encoded bytes `0500`, the encoded representation of the ASN.1 NULL value, as specified in [RFC 6962, Section 3.1](https://datatracker.ietf.org/doc/html/rfc6962#section-3.1). ##### 7.1.2.9.4 Precertificate Authority Key Identifier @@ -3216,7 +3216,7 @@ Table: Permitted `policyQualifiers` ##### 7.1.2.10.8 CA Certificate Name Constraints -If present, the Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatibility with certain legacy applications that do not support Name Constraints is necessary. +If present, the Name Constraints extension MUST be encoded as follows. As an explicit exception from [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280), this extension SHOULD be marked critical, but MAY be marked non-critical if compatibility with certain legacy applications that do not support Name Constraints is necessary. Table: `nameConstraints` requirements @@ -3242,7 +3242,7 @@ Table: `GeneralName` requirements for the `base` field | `dNSName` | MAY | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | | `iPAddress` | MAY | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the assignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | | `directoryName` | MAY | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | It is NOT RECOMMENDED to include values within `excludedSubtrees`. | -| `rfc822Name` | NOT RECOMMENDED | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | +| `rfc822Name` | NOT RECOMMENDED | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | | `otherName` | NOT RECOMMENDED | See below | See below | | Any other value | NOT RECOMMENDED | - | - | @@ -3301,13 +3301,13 @@ A `fullName` MUST contain at least one `GeneralName`; it MAY contain more than o ##### 7.1.2.11.3 Signed Certificate Timestamp List -If present, the Signed Certificate Timestamp List extension contents MUST be an `OCTET STRING` containing the encoded `SignedCertificateTimestampList`, as specified in [RFC 6962, Section 3.3](https://tools.ietf.org/html/rfc6962#section-3.3). +If present, the Signed Certificate Timestamp List extension contents MUST be an `OCTET STRING` containing the encoded `SignedCertificateTimestampList`, as specified in [RFC 6962, Section 3.3](https://datatracker.ietf.org/doc/html/rfc6962#section-3.3). Each `SignedCertificateTimestamp` included within the `SignedCertificateTimestampList` MUST be for a `PreCert` `LogEntryType` that corresponds to the current certificate. ##### 7.1.2.11.4 Subject Key Identifier -If present, the `subjectKeyIdentifier` MUST be set as defined within [RFC 5280, Section 4.2.1.2](https://tools.ietf.org/html/rfc5280#section-4.2.1.2). The CA MUST generate a `subjectKeyIdentifier` that is unique within the scope of all Certificates it has issued for each unique public key (the `subjectPublicKeyInfo` field of the `tbsCertificate`). For example, CAs may generate the subject key identifier using an algorithm derived from the public key, or may generate a sufficiently-large unique number, such as by using a CSPRNG. +If present, the `subjectKeyIdentifier` MUST be set as defined within [RFC 5280, Section 4.2.1.2](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.2). The CA MUST generate a `subjectKeyIdentifier` that is unique within the scope of all Certificates it has issued for each unique public key (the `subjectPublicKeyInfo` field of the `tbsCertificate`). For example, CAs may generate the subject key identifier using an algorithm derived from the public key, or may generate a sufficiently-large unique number, such as by using a CSPRNG. ##### 7.1.2.11.5 Other Extensions @@ -3454,10 +3454,10 @@ This section details encoding rules that apply to all Certificates issued by a C The following requirements apply to all Certificates listed in [Section 7.1.2](#712-certificate-content-and-extensions). Specifically, this includes Technically Constrained Non-TLS Subordinate CA Certificates, as defined in [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile), but does not include certificates issued by such CA Certificates, as they are out of scope of these Baseline Requirements. -For every valid Certification Path (as defined by [RFC 5280, Section 6](https://tools.ietf.org/html/rfc5280#section-6)): +For every valid Certification Path (as defined by [RFC 5280, Section 6](https://datatracker.ietf.org/doc/html/rfc5280#section-6)): - For each Certificate in the Certification Path, the encoded content of the Issuer Distinguished Name field of a Certificate SHALL be byte-for-byte identical with the encoded form of the Subject Distinguished Name field of the Issuing CA certificate. -- For each CA Certificate in the Certification Path, the encoded content of the Subject Distinguished Name field of a Certificate SHALL be byte-for-byte identical among all Certificates whose Subject Distinguished Names can be compared as equal according to [RFC 5280, Section 7.1](https://tools.ietf.org/html/rfc5280#section-7.1), and including expired and revoked Certificates. +- For each CA Certificate in the Certification Path, the encoded content of the Subject Distinguished Name field of a Certificate SHALL be byte-for-byte identical among all Certificates whose Subject Distinguished Names can be compared as equal according to [RFC 5280, Section 7.1](https://datatracker.ietf.org/doc/html/rfc5280#section-7.1), and including expired and revoked Certificates. When encoding a `Name`, the CA SHALL ensure that: @@ -3479,21 +3479,21 @@ Table: Encoding and Order Requirements for Selected Attributes | **Attribute** | **OID** | **Specification** | **Encoding Requirements** | **Max Length\*** | | ---- | -- | --- | ---- | - | -| `domainComponent` | 0.9.2342.19200300.100.1.25 | [RFC 4519](https://tools.ietf.org/html/rfc4519) | MUST use `IA5String` | 63 | -| `countryName` | 2.5.4.6 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 2 | -| `stateOrProvinceName` | 2.5.4.8 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | -| `localityName` | 2.5.4.7 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | +| `domainComponent` | 0.9.2342.19200300.100.1.25 | [RFC 4519](https://datatracker.ietf.org/doc/html/rfc4519) | MUST use `IA5String` | 63 | +| `countryName` | 2.5.4.6 | [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) | MUST use `PrintableString` | 2 | +| `stateOrProvinceName` | 2.5.4.8 | [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | +| `localityName` | 2.5.4.7 | [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | | `postalCode` | 2.5.4.17 | X.520 | MUST use `UTF8String` or `PrintableString` | 40 | | `streetAddress` | 2.5.4.9 | X.520 | MUST use `UTF8String` or `PrintableString` | 128 | -| `organizationName` | 2.5.4.10 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | -| `surname` | 2.5.4.4 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64[^surname_givenname] | -| `givenName` | 2.5.4.42 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64[^surname_givenname] | -| `organizationalUnitName` | 2.5.4.11 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | -| `commonName` | 2.5.4.3 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | +| `organizationName` | 2.5.4.10 | [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | +| `surname` | 2.5.4.4 | [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64[^surname_givenname] | +| `givenName` | 2.5.4.42 | [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64[^surname_givenname] | +| `organizationalUnitName` | 2.5.4.11 | [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | +| `commonName` | 2.5.4.3 | [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | \* **Note**: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits. -[^surname_givenname]: **Note**: Although RFC 5280 specifies the upper bound as 32,768 characters, this was a transcription error from X.520 (08/2005). The effective (interoperable) upper bound is 64 characters. +[^surname_givenname]: **Note**: Although [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) specifies the upper bound as 32,768 characters, this was a transcription error from X.520 (08/2005). The effective (interoperable) upper bound is 64 characters. CAs that include attributes in the Certificate `subject` field that are listed in the table below SHALL follow the specified encoding requirements for the attribute. @@ -3505,7 +3505,7 @@ Table: Encoding Requirements for Selected Attributes | `jurisdictionCountry` | 1.3.6.1.4.1.311.60.2.1.3 | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `PrintableString` | 2 | | `jurisdictionStateOrProvince` | 1.3.6.1.4.1.311.60.2.1.2 | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `UTF8String` or `PrintableString` | 128 | | `jurisdictionLocality` | 1.3.6.1.4.1.311.60.2.1.1 | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `UTF8String` or `PrintableString` | 128 | -| `serialNumber` | 2.5.4.5 | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 64 | +| `serialNumber` | 2.5.4.5 | [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) | MUST use `PrintableString` | 64 | | `organizationIdentifier` | 2.5.4.97 | X.520 | MUST use `UTF8String` or `PrintableString` | None | \* **Note**: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits. @@ -3514,8 +3514,8 @@ Table: Encoding Requirements for Selected Attributes If present, this attribute MUST contain exactly one entry that is one of the values contained in the Certificate's `subjectAltName` extension (see [Section 7.1.2.7.12](#712712-subscriber-certificate-subject-alternative-name)). The value of the field MUST be encoded as follows: -- If the value is an IPv4 address, then the value MUST be encoded as an IPv4Address as specified in RFC 3986, Section 3.2.2. -- If the value is an IPv6 address, then the value MUST be encoded in the text representation specified in RFC 5952, Section 4. +- If the value is an IPv4 address, then the value MUST be encoded as an IPv4Address as specified in [RFC 3986, Section 3.2.2](https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.2). +- If the value is an IPv6 address, then the value MUST be encoded in the text representation specified in [RFC 5952, Section 4](https://datatracker.ietf.org/doc/html/rfc5952#section-4). - If the value is a Fully-Qualified Domain Name or Wildcard Domain Name, then the value MUST be encoded as a character-for-character copy of the `dNSName` entry value from the `subjectAltName` extension. Specifically, all Domain Labels of the Fully-Qualified Domain Name or FQDN portion of the Wildcard Domain Name must be encoded as LDH Labels, and P-Labels MUST NOT be converted to their Unicode representation. #### 7.1.4.4 Other Subject Attributes @@ -3555,7 +3555,7 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o Prior to 2024‐03‐15, the CA SHALL issue CRLs in accordance with the profile specified in these Requirements or the profile specified in Version 1.8.7 of the Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates. Effective 2024‐03‐15, the CA SHALL issue CRLs in accordance with the profile specified in these Requirements. -If the CA asserts compliance with these Baseline Requirements, all CRLs that it issues MUST comply with the following CRL profile, which incorporates, and is derived from [RFC 5280](https://tools.ietf.org/html/rfc5280). Except as explicitly noted, all normative requirements imposed by RFC 5280 shall apply, in addition to the normative requirements imposed by this document. CAs SHOULD examine [RFC 5280, Appendix B](https://tools.ietf.org/html/rfc5280#appendix-B) for further issues to be aware of. +If the CA asserts compliance with these Baseline Requirements, all CRLs that it issues MUST comply with the following CRL profile, which incorporates, and is derived from [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280). Except as explicitly noted, all normative requirements imposed by [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) shall apply, in addition to the normative requirements imposed by this document. CAs SHOULD examine [RFC 5280, Appendix B](https://datatracker.ietf.org/doc/html/rfc5280#appendix-B) for further issues to be aware of. A full and complete CRL is a CRL whose scope includes all Certificates issued by the CA. @@ -3604,7 +3604,7 @@ Table: revokedCertificates Component | `revocationDate` | MUST | Normally, the date and time revocation occurred. See the footnote following this table for circumstances where backdating is permitted. | | `crlEntryExtensions` | * | See the "crlEntryExtensions Component" table for additional requirements. | -**Note:** The CA SHOULD update the revocation date in a CRL entry when it is determined that the private key of the Certificate was compromised prior to the revocation date that is indicated in the CRL entry for that Certificate. Backdating the revocationDate field is an exception to best practice described in RFC 5280 (Section 5.3.2); however, these requirements specify the use of the revocationDate field to support TLS implementations that process the revocationDate field as the date when the Certificate is first considered to be compromised. +**Note:** The CA SHOULD update the revocation date in a CRL entry when it is determined that the private key of the Certificate was compromised prior to the revocation date that is indicated in the CRL entry for that Certificate. Backdating the revocationDate field is an exception to best practice described in [RFC 5280, Section 5.3.2](https://datatracker.ietf.org/doc/html/rfc5280#section-5.3.2); however, these requirements specify the use of the revocationDate field to support TLS implementations that process the revocationDate field as the date when the Certificate is first considered to be compromised. Table: crlEntryExtensions Component @@ -3953,7 +3953,7 @@ These methods allow domain owners to publish contact information in DNS for the SYNTAX: `contactemail ` -The CAA contactemail property takes an email address as its parameter. The entire parameter value MUST be a valid email address as defined in RFC 6532, Section 3.2, with no additional padding or structure, or it cannot be used. +The CAA contactemail property takes an email address as its parameter. The entire parameter value MUST be a valid email address as defined in [RFC 6532, Section 3.2](https://datatracker.ietf.org/doc/html/rfc6532#section-3.2), with no additional padding or structure, or it cannot be used. The following is an example where the holder of the domain specified the contact property using an email address. @@ -3968,7 +3968,7 @@ The contactemail property MAY be critical, if the domain owner does not want CAs SYNTAX: `contactphone ` -The CAA contactphone property takes a phone number as its parameter. The entire parameter value MUST be a valid Global Number as defined in RFC 3966, Section 5.1.4, or it cannot be used. Global Numbers MUST have a preceding + and a country code and MAY contain spaces as visual separators. +The CAA contactphone property takes a phone number as its parameter. The entire parameter value MUST be a valid Global Number as defined in [RFC 3966, Section 5.1.4](https://datatracker.ietf.org/doc/html/rfc3966#section-5.1.4), or it cannot be used. Global Numbers MUST have a preceding + and a country code and MAY contain spaces as visual separators. The following is an example where the holder of the domain specified the contact property using a phone number. @@ -3983,11 +3983,11 @@ The contactphone property MAY be critical if the domain owner does not want CAs ### A.2.1. DNS TXT Record Email Contact -The DNS TXT record MUST be placed on the "`_validation-contactemail`" subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid email address as defined in RFC 6532, Section 3.2, with no additional padding or structure, or it cannot be used. +The DNS TXT record MUST be placed on the "`_validation-contactemail`" subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid email address as defined in [RFC 6532, Section 3.2](https://datatracker.ietf.org/doc/html/rfc6532#section-3.2), with no additional padding or structure, or it cannot be used. ### A.2.2. DNS TXT Record Phone Contact -The DNS TXT record MUST be placed on the "`_validation-contactphone`" subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid Global Number as defined in RFC 3966, Section 5.1.4, or it cannot be used. +The DNS TXT record MUST be placed on the "`_validation-contactphone`" subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid Global Number as defined in [RFC 3966, Section 5.1.4](https://datatracker.ietf.org/doc/html/rfc3966#section-5.1.4), or it cannot be used. # Appendix B – Issuance of Certificates for Onion Domain Names From c0402d4e9d3d55c8ba60b48a57468b7237481323 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Tue, 2 Dec 2025 21:08:20 +0100 Subject: [PATCH 106/121] #432 fixed link --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index c45b9da3..7ba090c5 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1106,7 +1106,7 @@ Wildcard Domain Name in the Certificate is "registry-controlled" or is a "public If the FQDN portion of any Wildcard Domain Name is "registry-controlled" or is a "public suffix", CAs MUST refuse issuance unless the Applicant proves its rightful control of the entire Domain Namespace. (e.g. CAs MUST NOT issue "\*.co.uk" or "\*.local", but MAY issue "\*.example.com" to Example Co.). -Determination of what is "registry-controlled" versus the registerable portion of a Country Code Top-Level Domain Namespace is not standardized at the time of writing and is not a property of the DNS itself. Current best practice is to consult a "public suffix list" such as the [Public Suffix List (PSL)](), and to retrieve a fresh copy regularly. +Determination of what is "registry-controlled" versus the registerable portion of a Country Code Top-Level Domain Namespace is not standardized at the time of writing and is not a property of the DNS itself. Current best practice is to consult a "public suffix list" such as the [Public Suffix List (PSL)](https://publicsuffix.org/), and to retrieve a fresh copy regularly. If using the PSL, a CA SHOULD consult the "ICANN DOMAINS" section only, not the "PRIVATE DOMAINS" section. The PSL is updated regularly to contain new gTLDs delegated by ICANN, which are listed in the "ICANN DOMAINS" section. A CA is not prohibited from issuing a Wildcard Certificate to the Registrant of an entire gTLD, provided that control of the entire namespace is demonstrated in an appropriate way. From 7ea5ac4cfd71e472de430a34f9bf22ad38c91e8c Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 3 Dec 2025 22:02:30 +0100 Subject: [PATCH 107/121] #432 punctuation and formatting changes --- docs/BR.md | 202 +++++++++++++++++++++++++++++------------------------ 1 file changed, 110 insertions(+), 92 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 7ba090c5..686b89a2 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -204,10 +204,10 @@ Before the CA authorizes a Delegated Third Party to perform a delegated function b. the Delegated Third Party's practice statement that the CA has verified complies with these Requirements. The CA MAY designate an Enterprise RA to verify certificate requests from the Enterprise RA's own organization. + The CA SHALL NOT accept certificate requests authorized by an Enterprise RA unless the following requirements are satisfied: -1. The CA SHALL confirm that the requested Fully-Qualified Domain Name(s) are within the Enterprise -RA's verified Domain Namespace. +1. The CA SHALL confirm that the requested Fully-Qualified Domain Name(s) are within the Enterprise RA's verified Domain Namespace. 2. If the certificate request includes a Subject name of a type other than a Fully-Qualified Domain Name, the CA SHALL confirm that the name is either that of the delegated enterprise, or an Affiliate of the delegated enterprise, or that the delegated enterprise is an agent of the named Subject. For example, the CA SHALL NOT issue a Certificate containing the Subject name "XYZ Co." on the authority of Enterprise RA "ABC Co.", unless the two companies are affiliated (see [Section 3.2](#32-initial-identity-validation)) or "ABC Co." is the agent of "XYZ Co". This requirement applies regardless of whether the accompanying requested Subject FQDN falls within the Domain Namespace of ABC Co.'s Registered Domain Name. The CA SHALL impose these limitations as a contractual requirement on the Enterprise RA and monitor compliance by the Enterprise RA. @@ -281,7 +281,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Audit Report**: A report from a Qualified Auditor stating the Qualified Auditor's opinion on whether an entity's processes and controls comply with the mandatory provisions of these Requirements. -**Authorization Domain Name**: The FQDN used to obtain authorization for a given FQDN to be included in a Certificate. The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. If a Wildcard Domain Name is to be included in a Certificate, then the CA MUST remove "`*.`" from the left-most portion of the Wildcard Domain Name to yield the corresponding FQDN. The CA may prune zero or more Domain Labels of the FQDN from left to right until encountering a Base Domain Name and may use any one of the values that were yielded by pruning (including the Base Domain Name itself) for the purpose of domain validation. +**Authorization Domain Name**: The FQDN used to obtain authorization for a given FQDN to be included in a Certificate. The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. If a Wildcard Domain Name is to be included in a Certificate, then the CA MUST remove "\*." from the left-most portion of the Wildcard Domain Name to yield the corresponding FQDN. The CA may prune zero or more Domain Labels of the FQDN from left to right until encountering a Base Domain Name and may use any one of the values that were yielded by pruning (including the Base Domain Name itself) for the purpose of domain validation. **Authorized Ports**: One of the following ports: 80 (http), 443 (https), 25 (smtp), 22 (ssh). @@ -393,9 +393,9 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Pending Prohibition**: The use of a behavior described with this label is highly discouraged, as it is planned to be deprecated and will likely be designated as MUST NOT in the future. -**Persistent DCV TXT Record:** A DNS TXT record identifying an Applicant in accordance with [Section 3.2.2.4.22](#322422-dns-txt-record-with-persistent-value). +**Persistent DCV TXT Record**: A DNS TXT record identifying an Applicant in accordance with [Section 3.2.2.4.22](#322422-dns-txt-record-with-persistent-value). -**Precertificate**: A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by [RFC 6962](https://datatracker.ietf.org/doc/html/rfc6962) and containing the critical poison extension (OID 1.3.6.1.4.1.11129.2.4.3). +**Precertificate**: A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by [RFC 6962](https://datatracker.ietf.org/doc/html/rfc6962) and containing the critical poison extension (OID: 1.3.6.1.4.1.11129.2.4.3). **Primary Network Perspective**: The Network Perspective used by the CA to make the determination of 1) the CA's authority to issue a Certificate for the requested domain(s) or IP address(es) and 2) the Applicant's authority and/or domain authorization or control of the requested domain(s) or IP address(es). @@ -444,7 +444,7 @@ The binding SHALL use a digital signature algorithm or a cryptographic hash algo **Note**: Examples of Request Tokens include, but are not limited to: i. a hash of the public key; or - ii. a hash of the Subject Public Key Info [X.509]; or + ii. a hash of the Subject Public Key Info X.509; or iii. a hash of a PKCS#10 CSR. A Request Token may also be concatenated with a timestamp or other data. If a CA wanted to always use a hash of a PKCS#10 CSR as a Request Token and did not want to incorporate a timestamp and did want to allow certificate key re-use then the applicant might use the challenge password in the creation of a CSR with OpenSSL to ensure uniqueness even if the subject and key are identical between subsequent requests. @@ -452,7 +452,7 @@ A Request Token may also be concatenated with a timestamp or other data. If a CA **Note**: This simplistic shell command produces a Request Token which has a timestamp and a hash of a CSR. ``echo `date -u +%Y%m%d%H%M` `sha256sum
MUST be present unless the CRL entry is for a Certificate not technically capable of causing issuance and either 1) the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to 2023-07-15 or 2) the reason for revocation (i.e., reasonCode) is unspecified (0).

See the "CRLReasons" table for additional requirements. | +| `reasonCode` | * | When present (OID 2.5.29.21), MUST NOT be marked critical and MUST indicate the most appropriate reason for revocation of the Certificate.

MUST be present unless the CRL entry is for a Certificate not technically capable of causing issuance and either 1) the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to 2023-07-15 or 2) the reason for revocation (i.e., reasonCode) is unspecified (0).

See the "CRLReasons" table for additional requirements. | | Any other value | NOT RECOMMENDED | - | Table: CRLReasons @@ -3633,15 +3646,15 @@ When a CA obtains verifiable evidence of Key Compromise for a Certificate whose #### 7.2.2.1 CRL Issuing Distribution Point -Partitioned CRLs MUST contain an Issuing Distribution Point extension. The `distributionPoint` field of the Issuing Distribution Point extension MUST be present. Additionally, the `fullName` field of the DistributionPointName value MUST be present, and its value MUST conform to the following requirements: +Partitioned CRLs MUST contain an Issuing Distribution Point extension. The `distributionPoint` field of the Issuing Distribution Point extension MUST be present. Additionally, the `fullName` field of the `DistributionPointName` value MUST be present, and its value MUST conform to the following requirements: 1. If a Certificate within the scope of the CRL contains a CRL Distribution Points extension, then at least one of the `uniformResourceIdentifiers` in the CRL Distribution Points's `fullName` field MUST be included in the `fullName` field of the CRL's Issuing Distribution Point extension. The encoding of the `uniformResourceIdentifier` value in the Issuing Distribution Point extension SHALL be byte-for-byte identical to the encoding used in the Certificate's CRL Distribution Points extension. 2. Other GeneralNames of type `uniformResourceIdentifier` MAY be included. 3. Non-`uniformResourceIdentifier` GeneralName types MUST NOT be included. -The `indirectCRL` and `onlyContainsAttributeCerts` fields MUST be set to `FALSE` (i.e., not asserted). +The `indirectCRL` and `onlyContainsAttributeCerts` fields MUST be set to FALSE (i.e., not asserted). -The CA MAY set either of the `onlyContainsUserCerts` and `onlyContainsCACerts` fields to `TRUE`, depending on the scope of the CRL. +The CA MAY set either of the `onlyContainsUserCerts` and `onlyContainsCACerts` fields to TRUE, depending on the scope of the CRL. The CA MUST NOT assert both of the `onlyContainsUserCerts` and `onlyContainsCACerts` fields. @@ -3671,7 +3684,7 @@ The CA SHALL at all times: ## 8.1 Frequency or circumstances of assessment -Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile), [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile), or [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), as well as audited in line with [Section 8.7](#87-self-audits) only, or Unconstrained and fully audited in line with all remaining requirements from this section. A Certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 `basicConstraints` extension, with the `cA` boolean set to true and is therefore by definition a Root CA Certificate or a Subordinate CA Certificate. +Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile), [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile), or [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), as well as audited in line with [Section 8.7](#87-self-audits) only, or Unconstrained and fully audited in line with all remaining requirements from this section. A Certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 `basicConstraints` extension, with the `cA` boolean set to TRUE and is therefore by definition a Root CA Certificate or a Subordinate CA Certificate. The period during which the CA issues Certificates SHALL be divided into an unbroken sequence of audit periods. An audit period MUST NOT exceed one year in duration. @@ -3809,6 +3822,7 @@ By issuing a Certificate, the CA makes the certificate warranties listed herein 1. The Subscriber that is a party to the Subscriber Agreement or Terms of Use for the Certificate; 2. All Application Software Suppliers with whom the Root CA has entered into a contract for inclusion of its Root Certificate in software distributed by such Application Software Supplier; and 3. All Relying Parties who reasonably rely on a Valid Certificate. + The CA represents and warrants to the Certificate Beneficiaries that, during the period when the Certificate is valid, the CA has complied with these Requirements and its Certificate Policy and/or Certification Practice Statement in issuing and managing the Certificate. The Certificate Warranties specifically include, but are not limited to, the following: @@ -3891,7 +3905,11 @@ The Subscriber Agreement or Terms of Use MUST contain provisions imposing on the For delegated tasks, the CA and any Delegated Third Party MAY allocate liability between themselves contractually as they determine, but the CA SHALL remain fully responsible for the performance of all parties in accordance with these Requirements, as if the tasks had not been delegated. -If the CA has issued and managed the Certificate in compliance with these Requirements and its Certificate Policy and/or Certification Practice Statement, the CA MAY disclaim liability to the Certificate Beneficiaries or any other third parties for any losses suffered as a result of use or reliance on such Certificate beyond those specified in the CA's Certificate Policy and/or Certification Practice Statement. If the CA has not issued or managed the Certificate in compliance with these Requirements and its Certificate Policy and/or Certification Practice Statement, the CA MAY seek to limit its liability to the Subscriber and to Relying Parties, regardless of the cause of action or legal theory involved, for any and all claims, losses or damages suffered as a result of the use or reliance on such Certificate by any appropriate means that the CA desires. If the CA chooses to limit its liability for Certificates that are not issued or managed in compliance with these Requirements or its Certificate Policy and/or Certification Practice Statement, then the CA SHALL include the limitations on liability in the CA's Certificate Policy and/or Certification Practice Statement. +If the CA has issued and managed the Certificate in compliance with these Requirements and its Certificate Policy and/or Certification Practice Statement, the CA MAY disclaim liability to the Certificate Beneficiaries or any other third parties for any losses suffered as a result of use or reliance on such Certificate beyond those specified in the CA's Certificate Policy and/or Certification Practice Statement. + +If the CA has not issued or managed the Certificate in compliance with these Requirements and its Certificate Policy and/or Certification Practice Statement, the CA MAY seek to limit its liability to the Subscriber and to Relying Parties, regardless of the cause of action or legal theory involved, for any and all claims, losses or damages suffered as a result of the use or reliance on such Certificate by any appropriate means that the CA desires. + +If the CA chooses to limit its liability for Certificates that are not issued or managed in compliance with these Requirements or its Certificate Policy and/or Certification Practice Statement, then the CA SHALL include the limitations on liability in the CA's Certificate Policy and/or Certification Practice Statement. ## 9.9 Indemnities @@ -3958,8 +3976,8 @@ The CAA contactemail property takes an email address as its parameter. The entir The following is an example where the holder of the domain specified the contact property using an email address. ```DNS Zone -$ORIGIN example.com. - CAA 0 contactemail "domainowner@example.com" +$ORIGIN example.com . +CAA 0 contactemail "domainowner@example.com" ``` The contactemail property MAY be critical, if the domain owner does not want CAs who do not understand it to issue certificates for the domain. @@ -3973,8 +3991,8 @@ The CAA contactphone property takes a phone number as its parameter. The entire The following is an example where the holder of the domain specified the contact property using a phone number. ```DNS Zone -$ORIGIN example.com. - CAA 0 contactphone "+1 555 123 4567" +$ORIGIN example.com . +CAA 0 contactphone "+1 555 123 4567" ``` The contactphone property MAY be critical if the domain owner does not want CAs who do not understand it to issue certificates for the domain. @@ -3999,9 +4017,9 @@ 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) - iii. [Section 3.2.2.4.20 - TLS Using ALPN](#322420-tls-using-alpn) + i. [Section 3.2.2.4.18](#322418-agreed-upon-change-to-website-v2) - Agreed-Upon Change to Website v2 + ii. [Section 3.2.2.4.19](#322419-agreed-upon-change-to-website---acme) - Agreed-Upon Change to Website - ACME + iii. [Section 3.2.2.4.20](#322420-tls-using-alpn) - 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. From 453fce34a45dc040da570d852ff560421424e4ad Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 3 Dec 2025 22:17:47 +0100 Subject: [PATCH 108/121] #432 standarized hyphens --- docs/BR.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 686b89a2..d906ba65 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1945,15 +1945,15 @@ The CA's mass revocation plan MUST include clearly defined, actionable, and comp Mass revocation provisions MUST include: -1. Activation criteria – specific, objective, and measurable thresholds at which the mass revocation plan is triggered based on the CA's risk profile, issuance volumes, and operational capabilities; -2. Customer contact information – how subscriber and customer contact details are stored, maintained, and kept up to date; -3. Automation points – processes that are automated or could be automated, and those processes that require manual intervention; -4. Targets and timelines – for incident triage, revocation initiation, certificate replacement, and post-event review; -5. Subscriber notification methods – mechanisms for notifying impacted Subscribers; -6. Role assignments – roles and responsibilities of personnel responsible for initiating, coordinating, and executing the plan; -7. Training and education – training, awareness, and readiness activities for personnel responsible for, or supporting, the plan; -8. Plan testing – annual operational testing to assess readiness and demonstrate implementation feasibility, using one or more of tabletop exercises, simulations, parallel testing, or controlled test environments that DO NOT involve the revocation of active Subscriber Certificates; and -9. Post-test analysis and update schedule – how lessons learned from testing or live incidents are incorporated into the plan, and how often it is reviewed and updated. +1. Activation criteria - specific, objective, and measurable thresholds at which the mass revocation plan is triggered based on the CA's risk profile, issuance volumes, and operational capabilities; +2. Customer contact information - how subscriber and customer contact details are stored, maintained, and kept up to date; +3. Automation points - processes that are automated or could be automated, and those processes that require manual intervention; +4. Targets and timelines - for incident triage, revocation initiation, certificate replacement, and post-event review; +5. Subscriber notification methods - mechanisms for notifying impacted Subscribers; +6. Role assignments - roles and responsibilities of personnel responsible for initiating, coordinating, and executing the plan; +7. Training and education - training, awareness, and readiness activities for personnel responsible for, or supporting, the plan; +8. Plan testing - annual operational testing to assess readiness and demonstrate implementation feasibility, using one or more of tabletop exercises, simulations, parallel testing, or controlled test environments that DO NOT involve the revocation of active Subscriber Certificates; and +9. Post-test analysis and update schedule - how lessons learned from testing or live incidents are incorporated into the plan, and how often it is reviewed and updated. ### 5.7.2 Recovery Procedures if Computing resources, software, and/or data are corrupted @@ -3556,7 +3556,7 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) individual-validated(3)} (2.23.140.1.2.3)` -`{joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140) certificate‐policies(1) ev-guidelines(1)} (2.23.140.1.1)` +`{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) ev-guidelines(1)} (2.23.140.1.1)` ### 7.1.7 Usage of Policy Constraints extension @@ -3566,7 +3566,7 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o ## 7.2 CRL profile -Prior to 2024‐03‐15, the CA SHALL issue CRLs in accordance with the profile specified in these Requirements or the profile specified in Version 1.8.7 of the Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates. Effective 2024‐03‐15, the CA SHALL issue CRLs in accordance with the profile specified in these Requirements. +Prior to 2024-03-15, the CA SHALL issue CRLs in accordance with the profile specified in these Requirements or the profile specified in Version 1.8.7 of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Effective 2024-03-15, the CA SHALL issue CRLs in accordance with the profile specified in these Requirements. If the CA asserts compliance with these Baseline Requirements, all CRLs that it issues MUST comply with the following CRL profile, which incorporates, and is derived from [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280). Except as explicitly noted, all normative requirements imposed by [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) shall apply, in addition to the normative requirements imposed by this document. CAs SHOULD examine [RFC 5280, Appendix B](https://datatracker.ietf.org/doc/html/rfc5280#appendix-B) for further issues to be aware of. @@ -3633,7 +3633,7 @@ Table: CRLReasons | unspecified | 0 | Represented by the omission of a reasonCode. MUST be omitted if the CRL entry is for a Certificate not technically capable of causing issuance unless the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to 2023-07-15. | | keyCompromise | 1 | Indicates that it is known or suspected that the Subscriber's Private Key has been compromised. | | affiliationChanged | 3 | Indicates that the Subject's name or other Subject Identity Information in the Certificate has changed, but there is no cause to suspect that the Certificate's Private Key has been compromised. | -| superseded | 4 | Indicates that the Certificate is being replaced because: the Subscriber has requested a new Certificate, the CA has reasonable evidence that the validation of domain authorization or control for any fully‐qualified domain name or IP address in the Certificate should not be relied upon, or the CA has revoked the Certificate for compliance reasons such as the Certificate does not comply with these Baseline Requirements or the CA's CP or CPS. | +| superseded | 4 | Indicates that the Certificate is being replaced because: the Subscriber has requested a new Certificate, the CA has reasonable evidence that the validation of domain authorization or control for any fully-qualified domain name or IP address in the Certificate should not be relied upon, or the CA has revoked the Certificate for compliance reasons such as the Certificate does not comply with these Baseline Requirements or the CA's CP or CPS. | | cessationOfOperation | 5 | Indicates that the website with the Certificate is shut down prior to the expiration of the Certificate, or if the Subscriber no longer owns or controls the Domain Name in the Certificate prior to the expiration of the Certificate. | | certificateHold | 6 | MUST NOT be included if the CRL entry is for 1) a Certificate subject to these Requirements, or 2) a Certificate not subject to these Requirements and was either A) issued on-or-after 2020-09-30 or B) has a `notBefore` on-or-after 2020-09-30. | | privilegeWithdrawn | 9 | Indicates that there has been a subscriber-side infraction that has not resulted in keyCompromise, such as the Certificate Subscriber provided misleading information in their Certificate Request or has not upheld their material obligations under the Subscriber Agreement or Terms of Use. | From 75687161a5911357eaa644c1b8f92300dcea1dde Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 3 Dec 2025 22:37:04 +0100 Subject: [PATCH 109/121] #432 standarized hyphens, punctuation and formatting changes --- docs/EVG.md | 41 ++++++++++++++++++++--------------------- 1 file changed, 20 insertions(+), 21 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 56b0333f..ce0b01f5 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -105,8 +105,7 @@ These Guidelines do not address the verification of information, or the issuance ### 1.3.2 Registration authorities -The CA MAY delegate the performance of all or any part of a requirement of these Guidelines to an Affiliate or a Registration Authority (RA) or subcontractor, provided that the process employed by the CA fulfills all of the requirements of [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence). -Affiliates and/or RAs must comply with the qualification requirements of [Section 5.3.2](#532-background-check-procedures). +The CA MAY delegate the performance of all or any part of a requirement of these Guidelines to an Affiliate or a Registration Authority (RA) or subcontractor, provided that the process employed by the CA fulfills all of the requirements of [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence). Affiliates and/or RAs must comply with the qualification requirements of [Section 5.3.2](#532-background-check-procedures). The CA SHALL verify that the Delegated Third Party's personnel involved in the issuance of a Certificate meet the training and skills requirements of [Section 5.3](#53-personnel-controls) and the document retention and event logging requirements of [Section 5.4](#54-audit-logging-procedures). @@ -948,13 +947,13 @@ A CA may rely on a previously verified certificate request to issue a replacemen 1. Except for reissuance of an EV Certificate under [Section 3.2.2.14.2](#322142-re-issuance-requests) and except when permitted otherwise in [Section 3.2.2.14.1](#322141-validation-for-existing-subscribers), the age of all data used to support issuance of an EV Certificate (before revalidation is required) SHALL NOT exceed the following limits: - A. Legal existence and identity – 398 days; - B. Assumed name – 398 days; - C. Address of Place of Business – 398 days; - D. Verified Method of Communication – 398 days; - E. Operational existence – 398 days; - F. Domain Name – 398 days; - G. Name, Title, Agency, and Authority – 398 days, unless a contract between the CA and the Applicant specifies a different term, in which case, the term specified in such contract controls. For example, the contract MAY include the perpetual assignment of EV roles until revoked by the Applicant or CA, or until the contract expires or is terminated. + A. Legal existence and identity - 398 days; + B. Assumed name - 398 days; + C. Address of Place of Business - 398 days; + D. Verified Method of Communication - 398 days; + E. Operational existence - 398 days; + F. Domain Name - 398 days; + G. Name, Title, Agency, and Authority - 398 days, unless a contract between the CA and the Applicant specifies a different term, in which case, the term specified in such contract controls. For example, the contract MAY include the perpetual assignment of EV roles until revoked by the Applicant or CA, or until the contract expires or is terminated. 2. The 398-day period set forth above SHALL begin to run on the date the information was collected by the CA. 3. The CA MAY reuse a previously submitted EV Certificate Request, Subscriber Agreement, or Terms of Use, including use of a single EV Certificate Request in support of multiple EV Certificates containing the same Subject to the extent permitted under [Section 3.2.2.9](#3229-verification-of-signature-on-subscriber-agreement-and-ev-certificate-requests) and [Section 3.2.2.10](#32210-verification-of-approval-of-ev-certificate-request). @@ -1042,8 +1041,7 @@ Subsidiary organizations or agencies of an entity that qualifies as a Non-Commer ### 4.1.2 Enrollment process and responsibilities -The documentation requirements in Section 4.1.2 of the Baseline Requirements apply equally to EV Certificates. -The Certificate Request requirements in Section 4.1.2 of the Baseline Requirements apply equally to EV Certificates subject to the additional more stringent ageing and updating requirement of [Section 3.2.2.14](#32214-requirements-for-re-use-of-existing-documentation). +The documentation requirements in Section 4.1.2 of the Baseline Requirements apply equally to EV Certificates. The Certificate Request requirements in Section 4.1.2 of the Baseline Requirements apply equally to EV Certificates subject to the additional more stringent ageing and updating requirement of [Section 3.2.2.14](#32214-requirements-for-re-use-of-existing-documentation). ## 4.2 Certificate application processing @@ -1507,6 +1505,7 @@ Effective as of 2020-10-01, the CA SHALL ensure that, at time of issuance, the v **Certificate Field**: `subject:serialNumber` (OID: 2.5.4.5) **Required/Optional**: **Required** **Contents**: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). + For Government Entities that do not have a Registration Number or readily verifiable date of creation, the CA SHALL enter appropriate language to indicate that the Subject is a Government Entity. For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). @@ -1606,7 +1605,7 @@ Each EV Certificate issued by the CA to a Subscriber MUST contain a policy ident 3. is either the CA/Browser Forum's EV policy identifier or a policy identifier that, by pre-agreement with the Application Software Supplier, marks the Certificate as being an EV Certificate. The following Certificate Policy identifier is the CA/Browser Forum's EV policy identifier: -`{joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140) certificate‐policies(1) ev-guidelines (1) } (2.23.140.1.1)`, if the Certificate complies with these Guidelines. +`{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) ev-guidelines (1) } (2.23.140.1.1)`, if the Certificate complies with these Guidelines. #### 7.1.6.2 Root CA Certificates @@ -1851,7 +1850,7 @@ The CA MUST host test Web pages that allow Application Software Suppliers to tes | Client Representative: | **(Exact name of Client Representative who signed the Application – see footnote 2)** | | Application Date: | **(Insert date of Client's Application to the Issuing CA)** | -This firm represents _[**exact** company name of Client]_ [^1] ("Client"), who has submitted the Application to you dated as of the Application Date shown above ("Application"). We have been asked by our Client to present you with our opinion as stated in this letter. +This firm represents *[**exact** company name of Client]* [^1] ("Client"), who has submitted the Application to you dated as of the Application Date shown above ("Application"). We have been asked by our Client to present you with our opinion as stated in this letter. [Insert customary preliminary matters for opinion letters in your jurisdiction.] @@ -1859,9 +1858,9 @@ On this basis, we hereby offer the following opinion: 1. That [exact company name of Client] ("Company") is a duly formed [corporation, LLC, etc.] that is "active," "valid," "current," or the equivalent under the laws of the state/province of [name of governing jurisdiction where Client is incorporated or registered] and is not under any legal disability known to the author of this letter. -2. That Company conducts business under the assumed name or "DBA"_[assumed name of the Applicant]_ and has registered such name with the appropriate government agency in the jurisdiction of its place of business below. +2. That Company conducts business under the assumed name or "DBA" *[assumed name of the Applicant]* and has registered such name with the appropriate government agency in the jurisdiction of its place of business below. -3. That _[name of Client's Representative]_[^2] has authority to act on behalf of Company to: [_select as appropriate_] (a) provide the information about Company required for issuance of the EV Certificates as contained in the attached Application, (b) request one or more EV Certificates and to designate other persons to request EV Certificates, and (c) agree to the relevant contractual obligations contained in the Subscriber Agreement on behalf of Company. +3. That *[name of Client's Representative]*[^2] has authority to act on behalf of Company to: *[select as appropriate]* (a) provide the information about Company required for issuance of the EV Certificates as contained in the attached Application, (b) request one or more EV Certificates and to designate other persons to request EV Certificates, and (c) agree to the relevant contractual obligations contained in the Subscriber Agreement on behalf of Company. 4. That Company has a physical presence and its place of business is at the following location: @@ -1883,9 +1882,9 @@ Insert customary limitations and disclaimers for opinion letters in your jurisdi (Name and signature) -_[Jurisdiction(s) in which attorney / Latin notary is admitted to practice]_[^3] +*[Jurisdiction(s) in which attorney / Latin notary is admitted to practice]*[^3] -cc: [Send copy to Client_]_ +cc: *[Send copy to Client]* [^1]: This must be the Client's exact corporate name, as registered with the relevant Incorporating Agency in the Client's Jurisdiction of Incorporation. This is the name that will be included in the EV Certificate. @@ -1973,7 +1972,7 @@ NOTE: This appendix provides alternative interpretations of the EV Guidelines fo 1. Non-Latin Organization Name - Where an EV Applicant's organization name is not registered with a QGIS in _Latin_ characters and the Applicant's foreign character organization name and registration have been verified with a QGIS in accordance with these Guidelines, a CA MAY include a Latin character organization name in the EV Certificate. In such a case, the CA MUST follow the procedures laid down in this section. + Where an EV Applicant's organization name is not registered with a QGIS in *Latin* characters and the Applicant's foreign character organization name and registration have been verified with a QGIS in accordance with these Guidelines, a CA MAY include a Latin character organization name in the EV Certificate. In such a case, the CA MUST follow the procedures laid down in this section. 2. Romanized Names @@ -2040,7 +2039,7 @@ As interpretation of the procedures set out above: A CA may rely on the Contract Signer's authority to enter into the Subscriber Agreement using a representation/warranty executed by the Contract Signer. An example of an acceptable warranty is as follows: -[CA] and Applicant are entering into a legally valid and enforceable Subscriber Agreement that creates extensive obligations on Applicant. An EV Certificate serves as a form of digital identity for Applicant. The loss or misuse of this identity can result in great harm to the Applicant. By signing this Subscriber Agreement, the contract signer acknowledges that they have the authority to obtain the digital equivalent of a company stamp, seal, or (where applicable) officer's signature to establish the authenticity of the company's website, and that [Applicant name] is responsible for all uses of its EV Certificate. By signing this Agreement on behalf of [Applicant name], the contract signer represents that the contract signer +CA and Applicant are entering into a legally valid and enforceable Subscriber Agreement that creates extensive obligations on Applicant. An EV Certificate serves as a form of digital identity for Applicant. The loss or misuse of this identity can result in great harm to the Applicant. By signing this Subscriber Agreement, the contract signer acknowledges that they have the authority to obtain the digital equivalent of a company stamp, seal, or (where applicable) officer's signature to establish the authenticity of the company's website, and that [Applicant name] is responsible for all uses of its EV Certificate. By signing this Agreement on behalf of [Applicant name], the contract signer represents that the contract signer i. is acting as an authorized representative of [Applicant name], ii. is expressly authorized by [Applicant name] to sign Subscriber Agreements and approve EV Certificate requests on Applicant's behalf, and @@ -2054,8 +2053,8 @@ This appendix is intentionally left blank. ```ASN.1 CABFSelectedAttributeTypes { - joint‐iso‐itu‐t(2) international‐organizations(23) - ca‐browser‐forum(140) module(4) + joint-iso-itu-t(2) international-organizations(23) + ca-browser-forum(140) module(4) cabfSelectedAttributeTypes(1) 1 } DEFINITIONS ::= BEGIN From dd62205c4896def92ce0e64f31f2e56a5864ee8a Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 3 Dec 2025 23:01:27 +0100 Subject: [PATCH 110/121] #432 punctuation : for lists --- docs/EVG.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index ce0b01f5..57c5619c 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -180,7 +180,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Business Entity**: Any entity that is not a Private Organization, Government Entity, or Non-Commercial Entity as defined herein. Examples include, but are not limited to, general partnerships, unincorporated associations, sole proprietorships, etc. -**Certificate Approver**: A natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant to +**Certificate Approver**: A natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant to: i. act as a Certificate Requester and to authorize other employees or third parties to act as a Certificate Requester, and ii. to approve EV Certificate Requests submitted by other Certificate Requesters. @@ -265,7 +265,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Qualified Independent Information Source**: A regularly-updated and current, publicly available, database designed for the purpose of accurately providing the information for which it is consulted, and which is generally recognized as a dependable source of such information. -**Registration Agency**: A Governmental Agency that registers business information in connection with an entity's business formation or authorization to conduct business under a license, charter or other certification. A Registration Agency MAY include, but is not limited to +**Registration Agency**: A Governmental Agency that registers business information in connection with an entity's business formation or authorization to conduct business under a license, charter or other certification. A Registration Agency MAY include, but is not limited to: i. a State Department of Corporations or a Secretary of State; ii. a licensing agency, such as a State Department of Insurance; or @@ -354,7 +354,7 @@ Each CA must develop, implement, enforce, display prominently on its Web site, a A. Implement the requirements of these Guidelines as they are revised from time-to-time; -B. Implement the requirements of +B. Implement the requirements of: i. the then-current WebTrust Program for CAs, and ii. the then-current WebTrust EV Program or ETSI TS 102 042 for EVCP or ETSI EN 319 411-1 for EVCP policy; and @@ -673,7 +673,7 @@ Acceptable methods of verification of the name, title, and agency status of the Acceptable methods of verification of the Signing Authority of the Contract Signer, and the EV Authority of the Certificate Approver, as applicable, include: 1. **Verified Professional Letter**: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by reliance on a Verified Professional Letter; -2. **Corporate Resolution**: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by reliance on a properly authenticated corporate resolution that confirms that the person has been granted such Signing Authority, provided that such resolution is +2. **Corporate Resolution**: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by reliance on a properly authenticated corporate resolution that confirms that the person has been granted such Signing Authority, provided that such resolution is: i. certified by the appropriate corporate officer (e.g., secretary), and ii. the CA can reliably verify that the certification was validly signed by such person, and that such person does have the requisite authority to provide such certification; @@ -834,7 +834,7 @@ An Independent Confirmation from the Applicant MAY be obtained via the following 1. The address of the Applicant's Place of Business as verified by the CA in accordance with these Guidelines, or 2. The business address for such Confirming Person specified in a current QGIS, QTIS, QIIS, Verified Professional Letter, or - 3. The address of the Applicant's Registered Agent or Registered Office listed in the official records of the Jurisdiction of Incorporation, or + 3. The address of the Applicant's Registered Agent or Registered Office listed in the official records of the Jurisdiction of Incorporation. ii. By e-mail addressed to the Confirming Person at the business e-mail address for such person listed in a current QGIS, QTIS, QIIS, Verified Legal Opinion, or Verified Accountant Letter; or iii. By telephone call to the Confirming Person, where such person is contacted by calling the main phone number of the Applicant's Place of Business (verified in accordance with these Guidelines) and asking to speak to such person, and a person taking the call identifies him- or herself as such person; or @@ -854,7 +854,7 @@ A Qualified Independent Information Source (QIIS) is a regularly-updated and pub 1. Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and 2. The database provider updates its data on at least an annual basis. -The CA SHALL use a documented process to check the accuracy of the database and ensure its data is acceptable, including reviewing the database provider's terms of use. The CA SHALL NOT use any data in a QIIS that the CA knows is +The CA SHALL use a documented process to check the accuracy of the database and ensure its data is acceptable, including reviewing the database provider's terms of use. The CA SHALL NOT use any data in a QIIS that the CA knows is: i. self-reported and ii. not verified by the QIIS as accurate. @@ -888,10 +888,10 @@ 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](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 + 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. @@ -1051,7 +1051,7 @@ The following Applicant roles are required for the issuance of an EV Certificate 1. **Certificate Requester**: The EV Certificate Request MUST be submitted by an authorized Certificate Requester. A Certificate Requester is a natural person who is either the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or a third party (such as an ISP or hosting company) that completes and submits an EV Certificate Request on behalf of the Applicant. -2. **Certificate Approver**: The EV Certificate Request MUST be approved by an authorized Certificate Approver. A Certificate Approver is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant to +2. **Certificate Approver**: The EV Certificate Request MUST be approved by an authorized Certificate Approver. A Certificate Approver is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant to: i. act as a Certificate Requester and to authorize other employees or third parties to act as a Certificate Requester, and ii. to approve EV Certificate Requests submitted by other Certificate Requesters. @@ -1548,7 +1548,7 @@ The Registration Scheme MUST be identified using the using the following structu - 2 character ISO 3166 country code for the nation in which the Registration Scheme is operated, or if the scheme is operated globally ISO 3166 code "XG" shall be used; - For the NTR Registration Scheme identifier, where registrations are administrated at the subdivision (state or province) level, if required under [Section 7.1.4.2.4](#71424-subject-jurisdiction-of-incorporation-or-registration-field), a plus "+" (0x2B (ASCII), U+002B (UTF-8)) followed by an up-to-three alphanumeric character ISO 3166-2 identifier for the subdivision of the nation in which the Registration Scheme is operated; - a hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8)); -- Registration Reference allocated in accordance with the identified Registration Scheme +- Registration Reference allocated in accordance with the identified Registration Scheme. Note: Registration References MAY contain hyphens, but Registration Schemes, ISO 3166 country codes, and ISO 3166-2 identifiers do not. Therefore if more than one hyphen appears in the structure, the leftmost hyphen is a separator, and the remaining hyphens are part of the Registration Reference. From 4154fb0c92ec50001aaf1aae5658c305b8fbe14a Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 3 Dec 2025 23:09:21 +0100 Subject: [PATCH 111/121] #432 punctuation : for lists --- docs/BR.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index d906ba65..ed01e256 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -541,9 +541,9 @@ The script outputs: ### 1.6.3 References -ETSI EN 319 403, Electronic Signatures and Infrastructures (ESI); Trust Service Provider Conformity Assessment - Requirements for conformity assessment bodies assessing Trust Service Providers +ETSI EN 319 403, Electronic Signatures and Infrastructures (ESI); Trust Service Provider Conformity Assessment - Requirements for conformity assessment bodies assessing Trust Service Providers. -ETSI EN 319 411-1, Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements +ETSI EN 319 411-1, Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements. 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. @@ -604,9 +604,9 @@ NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Ap [RFC8954](https://datatracker.ietf.org/doc/html/rfc8954), Request for Comments: 8954, Online Certificate Status Protocol (OCSP) Nonce Extension. M. Sahni, Ed. November 2020. WebTrust for Certification Authorities, SSL Baseline with Network Security, available at - +. -[WebTrust Principles and Criteria for Certification Authorities – SSL Baseline](https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/principles-and-criteria) +[WebTrust Principles and Criteria for Certification Authorities – SSL Baseline](https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/principles-and-criteria). 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. @@ -634,7 +634,7 @@ The CA SHALL publicly give effect to these Requirements and represent that it wi > [Name of CA] conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates published at . In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document. -The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are +The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are: i. valid, ii. revoked, and @@ -775,7 +775,7 @@ This method has been retired and MUST NOT be used. Prior validations using this ##### 3.2.2.4.4 Email to a Constructed Address -Confirm the Applicant's control over the FQDN by +Confirm the Applicant's control over the FQDN by: 1. Sending an email to one or more addresses created by using 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster' as the local part, followed by the at-sign ("@"), followed by an Authorization Domain Name; and 2. including a Random Value in the email; and @@ -801,12 +801,12 @@ This method has been retired and MUST NOT be used. Prior validations using this ##### 3.2.2.4.7 DNS Change -Confirming the Applicant's control over the FQDN by confirming the presence of a Random Value or Request Token in a DNS CNAME, TXT or CAA record for either +Confirming the Applicant's control over the FQDN by confirming the presence of a Random Value or Request Token in a DNS CNAME, TXT or CAA record for either: 1. an Authorization Domain Name; or 2. an Authorization Domain Name that is prefixed with a Domain Label that begins with an underscore character. -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 +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: 1. 30 days; or 2. 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 3.2.2.14.3 of the EV Guidelines). @@ -1046,7 +1046,7 @@ After 2019-07-31, CAs SHALL maintain a record of which IP validation method, inc Confirming the Applicant's control over the requested IP Address by confirming the presence of a Request Token or Random Value contained in the content of a file or webpage in the form of a meta tag under the "/.well-known/pki-validation" directory, or another path registered with IANA for the purpose of validating control of IP Addresses, on the IP Address that is accessible by the CA via HTTP/HTTPS over an Authorized Port. 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 +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 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). @@ -1971,7 +1971,7 @@ Mass revocation provisions MUST include: #### 6.1.1.1 CA Key Pair Generation -For CA Key Pairs that are either +For CA Key Pairs that are either: i. used as a CA Key Pair for a Root Certificate or ii. used as a CA Key Pair for a Subordinate CA Certificate, where the Subordinate CA is not the operator of the Root CA or an Affiliate of the Root CA, @@ -3700,7 +3700,7 @@ The CA's audit SHALL be performed by a Qualified Auditor. A Qualified Auditor me 4. (For audits conducted in accordance with any one of the ETSI standards) accredited in accordance with ISO 17065 applying the requirements specified in ETSI EN 319 403; 5. (For audits conducted in accordance with the WebTrust standard) licensed by WebTrust; 6. Bound by law, government regulation, or professional code of ethics; and -7. Except in the case of an Internal Government Auditing Agency, maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage +7. Except in the case of an Internal Government Auditing Agency, maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage. ## 8.3 Assessor's relationship to assessed entity @@ -3857,7 +3857,7 @@ The Certificate Warranties specifically include, but are not limited to, the fol 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 +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. ### 9.6.2 RA representations and warranties From 0e2688176ea7a530c9f031d89b40900ee8fb5832 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 3 Dec 2025 23:16:13 +0100 Subject: [PATCH 112/121] #432 fixed section links --- docs/BR.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index ed01e256..6f666cd8 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1174,7 +1174,7 @@ The CA MAY use either the same set, or different sets of Network Perspectives wh The set of responses from the relied upon Network Perspectives MUST provide the CA with the necessary information to allow it to affirmatively assess: a. the presence of the expected 1) Random Value, 2) Request Token, 3) IP Address, 4) Contact Address, or 5) Persistent DCV TXT Record, as required by the relied upon validation method specified in [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) and [Section 3.2.2.5](#3225-authentication-for-an-ip-address); and -b. the CA's authority to issue to the requested domain(s), as specified in [Section 3.2.2.8](#3228-caa-record-checks). +b. the CA's authority to issue to the requested domain(s), as specified in [Section 3.2.2.8](#3228-caa-records). [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) and [Section 3.2.2.5](#3225-authentication-for-an-ip-address) describe the validation methods that require the use of Multi-Perspective Issuance Corroboration and how a Network Perspective can corroborate the outcomes determined by the Primary Network Perspective. @@ -1228,9 +1228,9 @@ SHOULD: - Configure each network boundary control (firewall, switch, router, gateway, or other network control device or system) with rules that support only the services, protocols, ports, and communications identified as necessary to its operations. - Rely upon networks (e.g., Internet Service Providers) that: 1) use mechanisms based on Secure Inter-Domain Routing ([RFC 6480](https://datatracker.ietf.org/doc/html/rfc6480)), for example, BGP Prefix Origin Validation ([RFC 6811](https://datatracker.ietf.org/doc/html/rfc6811)), 2) make use of other non-RPKI route-leak prevention mechanisms (such as [RFC 9234](https://datatracker.ietf.org/doc/html/rfc9234)), and 3) apply current best practices described in [BCP 194](https://datatracker.ietf.org/doc/html/bcp194). While It is RECOMMENDED that under normal operating conditions Network Perspectives performing Multi-Perspective Issuance Corroboration forward all Internet traffic via a network or set of networks that filter RPKI-invalid BGP routes as defined by [RFC 6811](https://datatracker.ietf.org/doc/html/rfc6811), it is NOT REQUIRED. -Beyond the above considerations, computing systems performing Multi-Perspective Issuance Corroboration are considered outside of the audit scope described in [Section 8](#8-audit-requirements) of these Requirements. +Beyond the above considerations, computing systems performing Multi-Perspective Issuance Corroboration are considered outside of the audit scope described in [Section 8](#8-compliance-audit-and-other-assessments) of these Requirements. -If any of the above considerations are performed by a Delegated Third Party, the CA MAY obtain reasonable evidence from the Delegated Third Party to ascertain assurance that one or more of the above considerations are followed. As an exception to [Section 1.3.2](#132-delegated-third-parties), Delegated Third Parties are not required to be within the audit scope described in [Section 8](#8-audit-requirements) of these Requirements to satisfy the above considerations. +If any of the above considerations are performed by a Delegated Third Party, the CA MAY obtain reasonable evidence from the Delegated Third Party to ascertain assurance that one or more of the above considerations are followed. As an exception to [Section 1.3.2](#132-registration-authorities), Delegated Third Parties are not required to be within the audit scope described in [Section 8](#8-compliance-audit-and-other-assessments) of these Requirements to satisfy the above considerations. Phased Implementation Timeline: From 6774dd69e3ebbefc4b4a0cf76e465d680eeda866 Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 3 Dec 2025 23:22:32 +0100 Subject: [PATCH 113/121] #432 testing dns zone example --- docs/BR.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 6f666cd8..35b393d5 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1615,7 +1615,7 @@ A certificate serial is "unassigned" if it is not "assigned". The following SHALL apply for communicating the status of Certificates and Precertificates which include an Authority Information Access extension with an `id-ad-ocsp` accessMethod. -OCSP responders operated by the CA SHALL support the HTTP GET method, as described in [RFC 6960](https://datatracker.ietf.org/doc/html/rfc6960) and/or [RFC 5019](https://datatracker.ietf.org/doc/html/rfc5019). The CA MAY process the Nonce extension (`1.3.6.1.5.5.7.48.1.2`) in accordance with [RFC 8954](https://datatracker.ietf.org/doc/html/rfc8954). +OCSP responders operated by the CA SHALL support the HTTP GET method, as described in [RFC 6960](https://datatracker.ietf.org/doc/html/rfc6960) and/or [RFC 5019](https://datatracker.ietf.org/doc/html/rfc5019). The CA MAY process the Nonce extension (1.3.6.1.5.5.7.48.1.2) in accordance with [RFC 8954](https://datatracker.ietf.org/doc/html/rfc8954). For the status of a Subscriber Certificate or its corresponding Precertificate: @@ -3975,10 +3975,10 @@ The CAA contactemail property takes an email address as its parameter. The entir The following is an example where the holder of the domain specified the contact property using an email address. -```DNS Zone -$ORIGIN example.com . -CAA 0 contactemail "domainowner@example.com" -``` + ```DNS Zone + $ORIGIN example.com . + CAA 0 contactemail "domainowner@example.com" + ``` The contactemail property MAY be critical, if the domain owner does not want CAs who do not understand it to issue certificates for the domain. @@ -3990,10 +3990,10 @@ The CAA contactphone property takes a phone number as its parameter. The entire The following is an example where the holder of the domain specified the contact property using a phone number. -```DNS Zone -$ORIGIN example.com . -CAA 0 contactphone "+1 555 123 4567" -``` + ```DNS Zone + $ORIGIN example.com . + CAA 0 contactphone "+1 555 123 4567" + ``` The contactphone property MAY be critical if the domain owner does not want CAs who do not understand it to issue certificates for the domain. From f171a47e6fa13e9386805c29ffb5a6c56b60ba6c Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Wed, 3 Dec 2025 23:25:55 +0100 Subject: [PATCH 114/121] #432 testing dns zone example --- docs/BR.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 35b393d5..e61408b5 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -3975,10 +3975,10 @@ The CAA contactemail property takes an email address as its parameter. The entir The following is an example where the holder of the domain specified the contact property using an email address. - ```DNS Zone - $ORIGIN example.com . - CAA 0 contactemail "domainowner@example.com" - ``` +```DNSZone +$ORIGIN example.com . +CAA 0 contactemail "domainowner@example.com" +``` The contactemail property MAY be critical, if the domain owner does not want CAs who do not understand it to issue certificates for the domain. @@ -3990,10 +3990,10 @@ The CAA contactphone property takes a phone number as its parameter. The entire The following is an example where the holder of the domain specified the contact property using a phone number. - ```DNS Zone - $ORIGIN example.com . - CAA 0 contactphone "+1 555 123 4567" - ``` +```DNSZone +$ORIGIN example.com . +CAA 0 contactphone "+1 555 123 4567" +``` The contactphone property MAY be critical if the domain owner does not want CAs who do not understand it to issue certificates for the domain. From 92b05ce4f66cb3403406c2e3a7466367d0f3440b Mon Sep 17 00:00:00 2001 From: karolina-ads Date: Thu, 4 Dec 2025 08:51:44 +0100 Subject: [PATCH 115/121] #432 testing dns zone example --- docs/BR.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index e61408b5..e1f79dc2 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -3976,7 +3976,7 @@ The CAA contactemail property takes an email address as its parameter. The entir The following is an example where the holder of the domain specified the contact property using an email address. ```DNSZone -$ORIGIN example.com . +$ORIGIN example.com . CAA 0 contactemail "domainowner@example.com" ``` @@ -3991,7 +3991,7 @@ The CAA contactphone property takes a phone number as its parameter. The entire The following is an example where the holder of the domain specified the contact property using a phone number. ```DNSZone -$ORIGIN example.com . +$ORIGIN example.com . CAA 0 contactphone "+1 555 123 4567" ``` From 1b885f40a732760ee8eacc6c35190c8f320420b8 Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Fri, 12 Dec 2025 06:01:13 +0900 Subject: [PATCH 116/121] Align Certificate Profile definition with discussion on 2025-12-04 SCWG call (#639) Resolves #526. --- docs/BR.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index e1f79dc2..bac50ede 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -301,7 +301,7 @@ 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 Profile**: A set of documents or files that defines Certificate content and Certificate extensions, 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. @@ -2157,7 +2157,7 @@ Certificates MUST be of type X.509 v3. ### 7.1.2 Certificate Content and Extensions -If the CA asserts compliance with these Baseline Requirements, all certificates that it issues MUST comply with one of the following certificate profiles, which incorporate, and are derived from [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280). Except as explicitly noted, all normative requirements imposed by [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) shall apply, in addition to the normative requirements imposed by this document. CAs SHOULD examine [RFC 5280, Appendix B](https://datatracker.ietf.org/doc/html/rfc5280#appendix-B) for further issues to be aware of. +If the CA asserts compliance with these Baseline Requirements, all certificates that it issues MUST comply with one of the following Certificate Profiles, which incorporate, and are derived from [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280). Except as explicitly noted, all normative requirements imposed by [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) shall apply, in addition to the normative requirements imposed by this document. CAs SHOULD examine [RFC 5280, Appendix B](https://datatracker.ietf.org/doc/html/rfc5280#appendix-B) for further issues to be aware of. - CA Certificates - [Section 7.1.2.1](#7121-root-ca-certificate-profile) - Root CA Certificate Profile From 6bfbe3add826c549d655c583f87536c41934feb2 Mon Sep 17 00:00:00 2001 From: dzacharo Date: Fri, 12 Dec 2025 09:34:28 +0200 Subject: [PATCH 117/121] Addresses #642 --- docs/EVG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/EVG.md b/docs/EVG.md index 57c5619c..3f4c13b8 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -934,7 +934,7 @@ If an Applicant has a currently valid EV Certificate issued by the CA, a CA MAY 3. The Applicant's Verified Method of Communication required by [Section 3.2.2.5](#3225-verified-method-of-communication) but still MUST perform the verification required by [Section 3.2.2.5.2](#32252-acceptable-methods-of-verification) (B); 4. The Applicant's Operational Existence under [Section 3.2.2.6](#3226-verification-of-applicants-operational-existence); 5. The Name, Title, Agency and Authority of the Contract Signer, and Certificate Approver, under [Section 3.2.2.8](#3228-verification-of-name-title-and-authority-of-contract-signer-and-certificate-approver); and -6. The Applicant's right to use the specified Domain Name under [Section 3.2.2.7](#3227-verification-of-applicants-domain-name), provided that the CA verifies that the WHOIS record still shows the same registrant as when the CA verified the specified Domain Name for the initial EV Certificate. +6. The Applicant's right to use the specified Domain Name under [Section 3.2.2.7](#3227-verification-of-applicants-domain-name), provided that the CA verifies that the WHOIS record or RDAP registry data still shows the same registrant as when the CA verified the specified Domain Name for the initial EV Certificate. ##### 3.2.2.14.2 Re-issuance Requests From decf4e9bd6835f36b848ba00d79e84a00b98cc4e Mon Sep 17 00:00:00 2001 From: dzacharo Date: Fri, 12 Dec 2025 09:56:22 +0200 Subject: [PATCH 118/121] This is actually a reference to the ITU-T X.509 standard. Reverting --- docs/BR.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index bac50ede..7af4db47 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -444,7 +444,7 @@ The binding SHALL use a digital signature algorithm or a cryptographic hash algo **Note**: Examples of Request Tokens include, but are not limited to: i. a hash of the public key; or - ii. a hash of the Subject Public Key Info X.509; or + ii. a hash of the Subject Public Key Info [X.509]; or iii. a hash of a PKCS#10 CSR. A Request Token may also be concatenated with a timestamp or other data. If a CA wanted to always use a hash of a PKCS#10 CSR as a Request Token and did not want to incorporate a timestamp and did want to allow certificate key re-use then the applicant might use the challenge password in the creation of a CSR with OpenSSL to ensure uniqueness even if the subject and key are identical between subsequent requests. @@ -1493,7 +1493,7 @@ No stipulation. No stipulation. ### 4.8.7 Notification of certificate issuance by the CA to other entities - +2 No stipulation. ## 4.9 Certificate revocation and suspension From bbd8bbbc75915b6d0be561ec0f4ee16b3e0fb508 Mon Sep 17 00:00:00 2001 From: dzacharo Date: Fri, 12 Dec 2025 10:01:06 +0200 Subject: [PATCH 119/121] Since RFC 7482 was replaced with RFC 9082 in the WHOIS definition, the references section should also be updated. --- docs/BR.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 7af4db47..f4fd7ac4 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -591,8 +591,6 @@ NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Ap [RFC7231](https://datatracker.ietf.org/doc/html/rfc7231), Request For Comments: 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, et al. June 2014. -[RFC7482](https://datatracker.ietf.org/doc/html/rfc7482), Request for Comments: 7482, Registration Data Access Protocol (RDAP) Query Format. A. Newton, et al. March 2015. - [RFC7538](https://datatracker.ietf.org/doc/html/rfc7538), Request For Comments: 7538, The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). J. Reschke. April 2015. [RFC8499](https://datatracker.ietf.org/doc/html/rfc8499), Request for Comments: 8499, DNS Terminology. P. Hoffman, et al. January 2019. @@ -603,6 +601,8 @@ NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Ap [RFC8954](https://datatracker.ietf.org/doc/html/rfc8954), Request for Comments: 8954, Online Certificate Status Protocol (OCSP) Nonce Extension. M. Sahni, Ed. November 2020. +[RFC9082](https://datatracker.ietf.org/doc/html/rfc9082), Request for Comments: 9082, Registration Data Access Protocol (RDAP) Query Format. S. Hollenbeck, A. Newton, et al. June 2021. + WebTrust for Certification Authorities, SSL Baseline with Network Security, available at . From ce6778d9d611306642ed5fefec12b202fe58d211 Mon Sep 17 00:00:00 2001 From: dzacharo Date: Fri, 12 Dec 2025 10:07:02 +0200 Subject: [PATCH 120/121] Updated RFC references to have a space after the word "RFC" for consistency --- docs/BR.md | 48 ++++++++++++++++++++++++------------------------ 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index f4fd7ac4..c5934e18 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -557,51 +557,51 @@ Network and Certificate System Security Requirements, Version 1.7, available at NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications, . -[RFC2119](https://datatracker.ietf.org/doc/html/rfc2119), Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. +[RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119), Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. -[RFC3492](https://datatracker.ietf.org/doc/html/rfc3492), Request for Comments: 3492, Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). A. Costello. March 2003. +[RFC 3492](https://datatracker.ietf.org/doc/html/rfc3492), Request for Comments: 3492, Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). A. Costello. March 2003. -[RFC3647](https://datatracker.ietf.org/doc/html/rfc3647), Request for Comments: 3647, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework. S. Chokhani, et al. November 2003. +[RFC 3647](https://datatracker.ietf.org/doc/html/rfc3647), Request for Comments: 3647, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework. S. Chokhani, et al. November 2003. -[RFC3912](https://datatracker.ietf.org/doc/html/rfc3912), Request for Comments: 3912, WHOIS Protocol Specification. L. Daigle. September 2004. +[RFC 3912](https://datatracker.ietf.org/doc/html/rfc3912), Request for Comments: 3912, WHOIS Protocol Specification. L. Daigle. September 2004. -[RFC3986](https://datatracker.ietf.org/doc/html/rfc3986), Request for Comments: 3986, Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee, et al. January 2005. +[RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986), Request for Comments: 3986, Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee, et al. January 2005. -[RFC4035](https://datatracker.ietf.org/doc/html/rfc4035), Request for Comments: 4035, Protocol Modifications for the DNS Security Extensions. R. Arends, et al. March 2005. +[RFC 4035](https://datatracker.ietf.org/doc/html/rfc4035), Request for Comments: 4035, Protocol Modifications for the DNS Security Extensions. R. Arends, et al. March 2005. -[RFC4509](https://datatracker.ietf.org/doc/html/rfc4509), Request for Comments: 4509, Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs). W. Hardaker. May 2006. +[RFC 4509](https://datatracker.ietf.org/doc/html/rfc4509), Request for Comments: 4509, Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs). W. Hardaker. May 2006. -[RFC5019](https://datatracker.ietf.org/doc/html/rfc5019), Request for Comments: 5019, The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments. A. Deacon, et al. September 2007. +[RFC 5019](https://datatracker.ietf.org/doc/html/rfc5019), Request for Comments: 5019, The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments. A. Deacon, et al. September 2007. -[RFC5155](https://datatracker.ietf.org/doc/html/rfc5155), Request for Comments: 5155, DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. B. Laurie, et al. March 2008. +[RFC 5155](https://datatracker.ietf.org/doc/html/rfc5155), Request for Comments: 5155, DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. B. Laurie, et al. March 2008. -[RFC5280](https://datatracker.ietf.org/doc/html/rfc5280), Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile. D. Cooper, et al. May 2008. +[RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280), Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile. D. Cooper, et al. May 2008. -[RFC5702](https://datatracker.ietf.org/doc/html/rfc5702), Request for Comments: 5702, Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC. J. Jansen. October 2009. +[RFC 5702](https://datatracker.ietf.org/doc/html/rfc5702), Request for Comments: 5702, Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC. J. Jansen. October 2009. -[RFC5890](https://datatracker.ietf.org/doc/html/rfc5890), Request for Comments: 5890, Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. J. Klensin. August 2010. +[RFC 5890](https://datatracker.ietf.org/doc/html/rfc5890), Request for Comments: 5890, Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. J. Klensin. August 2010. -[RFC5952](https://datatracker.ietf.org/doc/html/rfc5952), Request for Comments: 5952, A Recommendation for IPv6 Address Text Representation. S. Kawamura, et al. August 2010. +[RFC 5952](https://datatracker.ietf.org/doc/html/rfc5952), Request for Comments: 5952, A Recommendation for IPv6 Address Text Representation. S. Kawamura, et al. August 2010. -[RFC6840](https://datatracker.ietf.org/doc/html/rfc6840), Request for Comments: 6840, Clarifications and Implementation Notes for DNS Security (DNSSEC). S. Weiler, et al. February 2013. +[RFC 6840](https://datatracker.ietf.org/doc/html/rfc6840), Request for Comments: 6840, Clarifications and Implementation Notes for DNS Security (DNSSEC). S. Weiler, et al. February 2013. -[RFC6960](https://datatracker.ietf.org/doc/html/rfc6960), Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. S. Santesson, et al. June 2013. +[RFC 6960](https://datatracker.ietf.org/doc/html/rfc6960), Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. S. Santesson, et al. June 2013. -[RFC6962](https://datatracker.ietf.org/doc/html/rfc6962), Request for Comments: 6962, Certificate Transparency. B. Laurie, et al. June 2013. +[RFC 6962](https://datatracker.ietf.org/doc/html/rfc6962), Request for Comments: 6962, Certificate Transparency. B. Laurie, et al. June 2013. -[RFC7231](https://datatracker.ietf.org/doc/html/rfc7231), Request For Comments: 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, et al. June 2014. +[RFC 7231](https://datatracker.ietf.org/doc/html/rfc7231), Request For Comments: 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, et al. June 2014. -[RFC7538](https://datatracker.ietf.org/doc/html/rfc7538), Request For Comments: 7538, The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). J. Reschke. April 2015. +[RFC 7538](https://datatracker.ietf.org/doc/html/rfc7538), Request For Comments: 7538, The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). J. Reschke. April 2015. -[RFC8499](https://datatracker.ietf.org/doc/html/rfc8499), Request for Comments: 8499, DNS Terminology. P. Hoffman, et al. January 2019. +[RFC 8499](https://datatracker.ietf.org/doc/html/rfc8499), Request for Comments: 8499, DNS Terminology. P. Hoffman, et al. January 2019. -[RFC8659](https://datatracker.ietf.org/doc/html/rfc8659), Request for Comments: 8659, DNS Certification Authority Authorization (CAA) Resource Record. P. Hallam-Baker, et al. November 2019. +[RFC 8659](https://datatracker.ietf.org/doc/html/rfc8659), Request for Comments: 8659, DNS Certification Authority Authorization (CAA) Resource Record. P. Hallam-Baker, et al. November 2019. -[RFC8738](https://datatracker.ietf.org/doc/html/rfc8738), Request for Comments: 8738, Automated Certificate Management Environment (ACME) IP Identifier Validation Extension. R.B.Shoemaker, Ed. February 2020. +[RFC 8738](https://datatracker.ietf.org/doc/html/rfc8738), Request for Comments: 8738, Automated Certificate Management Environment (ACME) IP Identifier Validation Extension. R.B.Shoemaker, Ed. February 2020. -[RFC8954](https://datatracker.ietf.org/doc/html/rfc8954), Request for Comments: 8954, Online Certificate Status Protocol (OCSP) Nonce Extension. M. Sahni, Ed. November 2020. +[RFC 8954](https://datatracker.ietf.org/doc/html/rfc8954), Request for Comments: 8954, Online Certificate Status Protocol (OCSP) Nonce Extension. M. Sahni, Ed. November 2020. -[RFC9082](https://datatracker.ietf.org/doc/html/rfc9082), Request for Comments: 9082, Registration Data Access Protocol (RDAP) Query Format. S. Hollenbeck, A. Newton, et al. June 2021. +[RFC 9082](https://datatracker.ietf.org/doc/html/rfc9082), Request for Comments: 9082, Registration Data Access Protocol (RDAP) Query Format. S. Hollenbeck, A. Newton, et al. June 2021. WebTrust for Certification Authorities, SSL Baseline with Network Security, available at . @@ -981,7 +981,7 @@ Except for Onion Domain Names, CAs performing validations using this method MUST ##### 3.2.2.4.20 TLS Using ALPN -Confirming the Applicant's control over a FQDN by validating domain control of the FQDN by negotiating a new application layer protocol using the TLS Application-Layer Protocol Negotiation (ALPN) Extension [RFC7301](https://datatracker.ietf.org/doc/html/rfc7301) as defined in [RFC 8737](https://datatracker.ietf.org/doc/html/rfc8737). The following are additive requirements to [RFC 8737](https://datatracker.ietf.org/doc/html/rfc8737). +Confirming the Applicant's control over a FQDN by validating domain control of the FQDN by negotiating a new application layer protocol using the TLS Application-Layer Protocol Negotiation (ALPN) Extension [RFC 7301](https://datatracker.ietf.org/doc/html/rfc7301) as defined in [RFC 8737](https://datatracker.ietf.org/doc/html/rfc8737). The following are additive requirements to [RFC 8737](https://datatracker.ietf.org/doc/html/rfc8737). The token (as defined in [RFC 8737, Section 3](https://datatracker.ietf.org/doc/html/rfc8737#section-3)) MUST NOT be used for more than 30 days from its creation. The CPS MAY specify a shorter validity period for the token, in which case the CA MUST follow its CPS. From 351f2755443ff78093d1b62b0b8a251ef6d8fc2d Mon Sep 17 00:00:00 2001 From: dzacharo Date: Fri, 12 Dec 2025 10:18:05 +0200 Subject: [PATCH 121/121] Removed old effective dates --- docs/EVG.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 3f4c13b8..c2451038 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -431,7 +431,7 @@ As a general rule, the CA is responsible for taking all verification steps reaso ##### 3.2.2.1.3 Disclosure of Verification Sources -Effective as of 2020-10-01, prior to the use of an Incorporating Agency or Registration Agency to fulfill these verification requirements, the CA MUST publicly disclose Agency Information about the Incorporating Agency or Registration Agency. This disclosure SHALL be through an appropriate and readily accessible online means. +Prior to the use of an Incorporating Agency or Registration Agency to fulfill these verification requirements, the CA MUST publicly disclose Agency Information about the Incorporating Agency or Registration Agency. This disclosure SHALL be through an appropriate and readily accessible online means. This Agency Information SHALL include at least the following: @@ -1498,7 +1498,7 @@ Country: `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) **Required/Optional**: Required **Contents**: These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. Country information MUST be specified using the applicable ISO country code. State or province or locality information (where applicable) for the Subject's Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction. -Effective as of 2020-10-01, the CA SHALL ensure that, at time of issuance, the values within these fields have been disclosed within the latest publicly-available disclosure, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), as acceptable values for the applicable Incorporating Agency or Registration Agency. +The CA SHALL ensure that, at time of issuance, the values within these fields have been disclosed within the latest publicly-available disclosure, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), as acceptable values for the applicable Incorporating Agency or Registration Agency. ##### 7.1.4.2.5 Subject Registration Number Field @@ -1510,7 +1510,7 @@ For Government Entities that do not have a Registration Number or readily verifi For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in using the ISO 8601 Complete Date format (YYYY-MM-DD, e.g., 2025-01-23). -Effective as of 2020-10-01, if the CA has disclosed a set of acceptable format or formats for Registration Numbers for the applicable Registration Agency or Incorporating Agency, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), the CA MUST ensure, prior to issuance, that the Registration Number is valid according to at least one currently disclosed format for that applicable Registration Agency or Incorporating agency. +If the CA has disclosed a set of acceptable format or formats for Registration Numbers for the applicable Registration Agency or Incorporating Agency, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), the CA MUST ensure, prior to issuance, that the Registration Number is valid according to at least one currently disclosed format for that applicable Registration Agency or Incorporating agency. ##### 7.1.4.2.6 Subject Physical Address of Place of Business Field