From 66fc74e32be6c868b26eaa2dc69f6622b838b1a8 Mon Sep 17 00:00:00 2001 From: Rich Smith Date: Wed, 2 Sep 2026 10:37:40 -0500 Subject: [PATCH] First pass EVG/BR sync and cleanup --- docs/BR.md | 245 +++++++++++++++++++++++++- docs/EVG.md | 499 +++++----------------------------------------------- 2 files changed, 284 insertions(+), 460 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 5c13e270..45c18778 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1,11 +1,11 @@ --- title: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates -subtitle: Version 2.2.9 +subtitle: Version 2.2.X author: - CA/Browser Forum -date: 6-Aug-2026 +date: TBD copyright: | Copyright 2026 CA/Browser Forum @@ -164,6 +164,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2.2.7 | SC099 | Improve Recording of Validation Method | 2026-04-18 | 2026-05-19 | | 2.2.8 | SC098 | Process RFC 8657 CAA Parameters | 2026-05-13 | 2026-06-16 | | 2.2.9 | SC101 | Clarify Authorization Domain Names | 2026-07-02 | 2026-08-06 | +| 2.2.X | SC1XX | EVG Cleanup and BR Sync | TBD | TBD | \* Effective Date and Additionally Relevant Compliance Date(s) @@ -198,6 +199,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2027-03-15 | [6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) | Maximum validity period of Subscriber Certificates is 100 days. | | 2027-03-15 | [4.2.2.1.2](#42212-caa-parameters) | CAs MUST process the `accounturi` and `validationmethods` parameters as specified in [RFC 8657](https://datatracker.ietf.org/doc/html/rfc8657). | | 2027-03-15 | [4.2.2.1.2](#42212-caa-parameters) | If the CA does not identify the Subscriber account via an ACME Account URL as described in [RFC 8555](https://datatracker.ietf.org/doc/html/rfc8555), the CA MUST define the supported format of the `accounturi` in Section 4.2 of their CP and/or CPS, and SHOULD comply with the `acct` URI scheme defined in [RFC 7565](https://datatracker.ietf.org/doc/html/rfc7565) | +| 2027-09-15 | [7.1.4.7](#7147-extended-validation-subject-registration-number) | If the CA includes the Date of Formation in the `subject:serialNumber` attribute of an Extended Validation Certificate, then the CA MUST use the Canonical Date Representation. | | 2028-03-15 | [3.2.2.4](#3224-validation-of-domain-authorization-or-control) and [3.2.2.5](#3225-authentication-for-an-ip-address) | CAs MUST NOT rely on Methods 3.2.2.4.4, 3.2.2.4.13, and 3.2.2.4.14 to issue Subscriber Certificates. | | 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. | @@ -311,6 +313,8 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **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). +**Canonical Date Representation**: A date that is formatted as YYYY-MM-DD, where "YYYY" is the four-digit year, "MM" is the two-digit month, and "DD" is the two-digit day of the month. Each element of the date is separated with a single hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8)). Each element is padded with leading zeroes as needed to ensure that year values consist of four digits and month and day of the month values consist of two digits. Example dates in this representation: "0748-04-02", "2024-10-14". + **Certificate**: An electronic document that uses a digital signature to bind a public key and an identity. **Certificate Data**: Certificate requests and data related thereto (whether obtained from the Applicant or otherwise) in the CA's possession or control or to which the CA has access. @@ -437,6 +441,10 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Registration Authority (RA)**: Any Legal Entity that is responsible for identification and authentication of subjects of Certificates, but is not a CA, and hence does not sign or issue Certificates. An RA may assist in the certificate application process or revocation process or both. When "RA" is used as an adjective to describe a role or function, it does not necessarily imply a separate body, but can be part of the CA. +**Registration Reference**: A unique identifier assigned to a Legal Entity. + +**Registration Scheme**: A scheme for assigning a Registration Reference meeting the requirements identified in [Appendix D](#appendix-d--registration-schemes). + **Reliable Data Source**: An identification document or source of data used to verify Subject Identity Information that is generally recognized among commercial enterprises and governments as reliable, and which was created by a third party for a purpose other than the Applicant obtaining a Certificate. **Reliable Method of Communication**: A method of communication, such as a postal/courier delivery address, telephone number, or email address, that was verified using a source other than the Applicant Representative. @@ -2802,15 +2810,50 @@ In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '- ##### 7.1.2.7.5 Extended Validation -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. +For a Subscriber Certificate to be Extended Validation, the Subject Information in the Certificate MUST have been validated in accordance with the then-current version of the Guidelines for the Issuance and Management of Extended Validation Certificates ("EV Guidelines"). In addition, it MUST meet the following profile: | **Field** | **Requirements** | | --- | ------- | -| `subject` | See Guidelines for the Issuance and Management of Extended Validation Certificates, Section 7.1.4.2. | +| `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.1` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). | -| All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) and the Guidelines for the Issuance and Management of Extended Validation Certificates. | +| All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | + +Capitalized terms used in this profile and in [Section 7.1.2.7.13](#712713-subscriber-certificate-cabrowser-forum-organization-identifier) and Sections [7.1.4.5](#7145-extended-validation-subject-organization-name) through [7.1.4.8](#7148-extended-validation-subject-organization-identifier) that are not defined in these Requirements are defined in the EV Guidelines. + +All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). + +The `subjectAltName` extension is subject to [Section 7.1.2.7.12](#712712-subscriber-certificate-subject-alternative-name), with the following additional requirements: + +- The extension MUST contain one or more `dNSName` entries containing 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). +- The extension MUST NOT contain an `iPAddress` `GeneralName`. +- A `dNSName` entry 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](#appendix-b--issuance-of-certificates-for-onion-domain-names). + +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. + +Table: Extended Validation `subject` Attributes + +| **Attribute Name** | **Presence** | **Value** | **Verification** | +| --- | -- | --- | -- | +| `countryName` | MUST | The two-letter ISO 3166-1 country code of the Subject's verified physical address of its Place of Business. 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.4 of the EV Guidelines | +| `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the state or province information of the Subject's verified physical address of its Place of Business. | Section 3.2.2.4 of the EV Guidelines | +| `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the locality information of the Subject's verified physical address of its Place of Business. | Section 3.2.2.4 of the EV Guidelines | +| `postalCode` | MAY | If present, MUST contain the zip or postal information of the Subject's verified physical address of its Place of Business. | Section 3.2.2.4 of the EV Guidelines | +| `streetAddress` | MAY | If present, MUST contain the street address information of the Subject's verified physical address of its Place of Business. Multiple instances MAY be present. | Section 3.2.2.4 of the EV Guidelines | +| `organizationName` | MUST | The Subject's full legal organization name, subject to the requirements of [Section 7.1.4.5](#7145-extended-validation-subject-organization-name). | Sections 3.2.2.2 and 3.2.2.3 of the EV Guidelines | +| `businessCategory` | MUST | One of the strings "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity", depending upon whether the Subject qualifies under Section 4.1.1.1, 4.1.1.2, 4.1.1.3, or 4.1.1.4 of the EV Guidelines, respectively. | Section 4.1.1 of the EV Guidelines | +| `jurisdictionCountry` | MUST | See [Section 7.1.4.6](#7146-extended-validation-subject-jurisdiction-of-incorporation-or-registration). | Sections 3.2.2.1.3 and 3.2.2.2 of the EV Guidelines | +| `jurisdictionStateOrProvince` | MUST / MUST NOT | Whether this attribute MUST or MUST NOT be present depends on the level at which the applicable Incorporating Agency or Registration Agency operates. See [Section 7.1.4.6](#7146-extended-validation-subject-jurisdiction-of-incorporation-or-registration). | Sections 3.2.2.1.3 and 3.2.2.2 of the EV Guidelines | +| `jurisdictionLocality` | MUST / MUST NOT | Whether this attribute MUST or MUST NOT be present depends on the level at which the applicable Incorporating Agency or Registration Agency operates. See [Section 7.1.4.6](#7146-extended-validation-subject-jurisdiction-of-incorporation-or-registration). | Sections 3.2.2.1.3 and 3.2.2.2 of the EV Guidelines | +| `serialNumber` | MUST | The Subject's Registration Number, or its Date of Formation or other value where permitted, as specified in [Section 7.1.4.7](#7147-extended-validation-subject-registration-number). | Section 3.2.2.2.1 of the EV Guidelines | +| `organizationIdentifier` | MAY | If present, MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme, as specified in [Section 7.1.4.8](#7148-extended-validation-subject-organization-identifier). If present, the `cabfOrganizationIdentifier` extension MUST be present (see [Section 7.1.2.7.13](#712713-subscriber-certificate-cabrowser-forum-organization-identifier)). | [Section 7.1.4.8](#7148-extended-validation-subject-organization-identifier) | +| `domainComponent` | MUST NOT | - | - | +| `surname` | MUST NOT | - | - | +| `givenName` | MUST NOT | - | - | +| `organizationalUnitName` | MUST NOT | - | - | +| `commonName` | NOT RECOMMENDED | If present, MUST contain exactly one Fully-Qualified Domain Name or Wildcard Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension, encoded according to [Section 7.1.4.3](#7143-subscriber-certificate-common-name-attribute). This attribute MUST NOT contain an IP address. This attribute MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name. | | +| Any other attribute | MUST NOT | - | - | In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. @@ -2829,12 +2872,14 @@ In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '- | `crlDistributionPoints` | * | 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) | | `subjectKeyIdentifier` | NOT RECOMMENDED | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `cabfOrganizationIdentifier` | * | N | See [Section 7.1.2.7.13](#712713-subscriber-certificate-cabrowser-forum-organization-identifier) | | 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). +- for Extended Validation Certificates, the `cabfOrganizationIdentifier` extension MUST be present if the `subject:organizationIdentifier` attribute is present, and MAY be present otherwise, as detailed in [Section 7.1.2.7.13](#712713-subscriber-certificate-cabrowser-forum-organization-identifier). For all other Certificate types, this extension is NOT RECOMMENDED. ##### 7.1.2.7.7 Subscriber Certificate Authority Information Access @@ -2950,6 +2995,40 @@ Table: `GeneralName` within a `subjectAltName` extension **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.7.13 Subscriber Certificate CA/Browser Forum Organization Identifier + +**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) }` + +In an Extended Validation Certificate, if the `subject:organizationIdentifier` attribute is present, this extension MUST be present. + +If present, this extension MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme. + +The Registration Scheme MUST be encoded as described by the following ASN.1 grammar: + +```ASN.1 +id-CABFOrganizationIdentifier OBJECT IDENTIFIER ::= { + joint-iso-itu-t(2) international-organizations(23) + ca-browser-forum(140) certificate-extensions(3) + cabf-organizationIdentifier(1) +} + +ext-CABFOrganizationIdentifier EXTENSION ::= { + SYNTAX CABFOrganizationIdentifier + IDENTIFIED BY id-CABFOrganizationIdentifier +} + +CABFOrganizationIdentifier ::= SEQUENCE { + registrationSchemeIdentifier PrintableString (SIZE(3)), + registrationCountry PrintableString (SIZE(2)), + registrationStateOrProvince [0] IMPLICIT PrintableString + (SIZE(1..128)) OPTIONAL, + registrationReference UTF8String +} +``` + +where the subfields have the same values, meanings, and restrictions described in [Section 7.1.4.8](#7148-extended-validation-subject-organization-identifier). The CA SHALL validate the contents using the requirements in [Section 7.1.4.8](#7148-extended-validation-subject-organization-identifier). + #### 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, 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. @@ -3188,6 +3267,8 @@ The following table details the acceptable `AttributeType`s that may appear with | `commonName` | MUST | The contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate. | | | Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.4](#7144-other-subject-attributes) | +If the Certificate is issued to a Subordinate CA that is not controlled by the same entity as the Issuing CA and the Certificate asserts the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.1` (see [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies)), then, in addition to the requirements of this section, the Subject organization information in the `countryName`, `stateOrProvinceName`, `localityName`, `postalCode`, `streetAddress`, `organizationName`, `businessCategory`, `jurisdictionCountry`, `jurisdictionStateOrProvince`, `jurisdictionLocality`, `serialNumber`, and `organizationIdentifier` attributes MUST meet the requirements of, and MUST be present where required by, the Extended Validation `subject` Attributes table in [Section 7.1.2.7.5](#71275-extended-validation), validated in accordance with the EV Guidelines. + ##### 7.1.2.10.3 CA Certificate Authority Information Access If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `accessLocation` MUST be encoded as the specified `GeneralName` type. @@ -3570,9 +3651,9 @@ 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 | +| `jurisdictionCountry` | 1.3.6.1.4.1.311.60.2.1.3 | [Section 7.1.4.6](#7146-extended-validation-subject-jurisdiction-of-incorporation-or-registration) and [Appendix C](#appendix-c--abstract-syntax-notation-one-module-for-ev-certificates) | MUST use `PrintableString` | 2 | +| `jurisdictionStateOrProvince` | 1.3.6.1.4.1.311.60.2.1.2 | [Section 7.1.4.6](#7146-extended-validation-subject-jurisdiction-of-incorporation-or-registration) and [Appendix C](#appendix-c--abstract-syntax-notation-one-module-for-ev-certificates) | MUST use `UTF8String` or `PrintableString` | 128 | +| `jurisdictionLocality` | 1.3.6.1.4.1.311.60.2.1.1 | [Section 7.1.4.6](#7146-extended-validation-subject-jurisdiction-of-incorporation-or-registration) and [Appendix C](#appendix-c--abstract-syntax-notation-one-module-for-ev-certificates) | MUST use `UTF8String` or `PrintableString` | 128 | | `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 | @@ -3586,6 +3667,8 @@ If present, this attribute MUST contain exactly one entry that is one of the val - 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. +**Note**: For Extended Validation Certificates, additional restrictions on this attribute apply, as detailed in [Section 7.1.2.7.5](#71275-extended-validation). + #### 7.1.4.4 Other Subject Attributes When explicitly stated as permitted by the relevant certificate profile specified within [Section 7.1.2](#712-certificate-content-and-extensions), CAs MAY include additional attributes within the `AttributeTypeAndValue` beyond those specified in [Section 7.1.4.2](#7142-subject-attribute-encoding). @@ -3595,6 +3678,80 @@ 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. +#### 7.1.4.5 Extended Validation Subject Organization Name + +This section applies to the `subject:organizationName` (OID 2.5.4.10) attribute of Extended Validation Certificates (see [Section 7.1.2.7.5](#71275-extended-validation)). + +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 in the EV Guidelines. 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. + +In addition, an assumed name or DBA name used by the Subject MAY be included at the beginning of this field, provided that it is followed by the full legal organization name in parenthesis. + +If the combination of names or the organization name by itself exceeds 64 characters, the CA MAY abbreviate parts of the organization name, and/or omit non-material words in the organization name in such a way that the text in this field does not exceed the 64-character limit; provided that the CA checks this field in accordance with [Section 4.2.1](#421-performing-identification-and-authentication-functions) and a Relying Party will not be misled into thinking that they are dealing with a different organization. In cases where this is not possible, the CA MUST NOT issue the EV Certificate. + +#### 7.1.4.6 Extended Validation Subject Jurisdiction of Incorporation or Registration + +This section applies to the following attributes of Extended Validation Certificates (see [Section 7.1.2.7.5](#71275-extended-validation)): + +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) + +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. + +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 of the EV Guidelines, as acceptable values for the applicable Incorporating Agency or Registration Agency. + +#### 7.1.4.7 Extended Validation Subject Registration Number + +This section applies to the `subject:serialNumber` (OID: 2.5.4.5) attribute of Extended Validation Certificates (see [Section 7.1.2.7.5](#71275-extended-validation)). + +For Private Organizations, the CA SHALL include the Registration Number that it obtained and verified in accordance with Section 3.2.2.2.1 (1.C) of the EV Guidelines. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the CA SHALL include the Date of Formation in any one of the common date formats. Effective 2027-09-15, if the CA includes the Date of Formation, then the CA MUST use the Canonical Date Representation. + +For Government Entities, the CA SHALL include the Registration Number that it obtained and verified in accordance with Section 3.2.2.2.1 (2.C) of the EV Guidelines. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the CA SHALL include the Date of Formation in any one of the common date formats. If the Jurisdiction of Incorporation or Registration does not provide a Date of Formation for the Applicant, then the CA SHALL indicate that the Subject is a Government Entity by including the string "Government Entity" or another appropriate value. Effective 2027-09-15, if the CA includes the Date of Formation, then the CA MUST use the Canonical Date Representation. + +For Business Entities, the CA SHALL include the Registration Number that it obtained and verified in accordance with Section 3.2.2.2.1 (3.C) of the EV Guidelines. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the CA SHALL include the Date of Formation in any one of the common date formats. Effective 2027-09-15, if the CA includes the Date of Formation, then the CA MUST use the Canonical Date Representation. + +For Non-Commercial Entity Subjects (International Organizations), the CA SHALL include the Date of Formation as obtained and verified in accordance with Section 3.2.2.2.1 (4.C) of the EV Guidelines, using any one of the common date formats. If the Jurisdiction of Incorporation or Registration does not provide a Date of Formation for the Applicant, then the CA SHALL indicate that the Subject is a Non-Commercial Entity by including the string "Non-Commercial Entity" or another appropriate value. Effective 2027-09-15, if the CA includes the Date of Formation, then the CA MUST use the Canonical Date Representation. + +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 of the EV Guidelines, 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.8 Extended Validation Subject Organization Identifier + +This section applies to the `subject:organizationIdentifier` (OID: 2.5.4.97) attribute of Extended Validation Certificates (see [Section 7.1.2.7.5](#71275-extended-validation)). + +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. + +The Registration Scheme MUST be identified 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.6](#7146-extended-validation-subject-jurisdiction-of-incorporation-or-registration), 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. + +As in [Section 7.1.4.6](#7146-extended-validation-subject-jurisdiction-of-incorporation-or-registration), 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) + +Registration Schemes listed in [Appendix D](#appendix-d--registration-schemes) are currently recognized as valid under these Requirements. + +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.5](#7145-extended-validation-subject-organization-name) within the context of the subject's jurisdiction as specified in [Section 7.1.4.6](#7146-extended-validation-subject-jurisdiction-of-incorporation-or-registration); +2. further verify the Registration Reference matches other information verified in accordance with Section 3.2 of the EV Guidelines; +3. take appropriate measures to disambiguate between different organizations as described in [Appendix D](#appendix-d--registration-schemes) for each Registration Scheme; +4. Apply the validation rules relevant to the Registration Scheme as specified in [Appendix D](#appendix-d--registration-schemes). + ### 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). @@ -4108,3 +4265,75 @@ This appendix defines permissible verification procedures for including one or m The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values. 3. When a Certificate includes an Onion Domain Name, the Domain Name shall not be considered an Internal Name provided that the Certificate was issued in compliance with this [Appendix B](#appendix-b--issuance-of-certificates-for-onion-domain-names). + +# Appendix C – Abstract Syntax Notation One module for EV certificates + +```ASN.1 +CABFSelectedAttributeTypes { + joint-iso-itu-t(2) international-organizations(23) + ca-browser-forum(140) module(4) + cabfSelectedAttributeTypes(1) 1 } +DEFINITIONS ::= +BEGIN +-- EXPORTS All +IMPORTS + -- from Rec. ITU-T X.501 | ISO/IEC 9594-2 + selectedAttributeTypes, ID, ldap-enterprise + FROM UsefulDefinitions {joint-iso-itu-t ds(5) module(1) + usefulDefinitions(0) 7} + + -- from the X.500 series + ub-locality-name, ub-state-name + FROM UpperBounds {joint-iso-itu-t ds(5) module(1) upperBounds(10) 7} + + -- from Rec. ITU-T X.520 | ISO/IEC 9594-6 + DirectoryString{}, CountryName + FROM SelectedAttributeTypes selectedAttributeTypes; + +id-evat-jurisdiction ID ::= {ldap-enterprise 311 ev(60) 2 1} +id-evat-jurisdiction-localityName ID ::= {id-evat-jurisdiction 1} +id-evat-jurisdiction-stateOrProvinceName ID ::= {id-evat-jurisdiction 2} +id-evat-jurisdiction-countryName ID ::= {id-evat-jurisdiction 3} + +jurisdictionLocalityName ATTRIBUTE ::= { + SUBTYPE OF name + WITH SYNTAX DirectoryString{ub-locality-name} + LDAP-SYNTAX directoryString.&id + LDAP-NAME {"jurisdictionL"} + ID id-evat-jurisdiction-localityName } + +jurisdictionStateOrProvinceName ATTRIBUTE ::= { + SUBTYPE OF name + WITH SYNTAX DirectoryString{ub-state-name} + LDAP-SYNTAX directoryString.&id + LDAP-NAME {"jurisdictionST"} + ID id-evat-jurisdiction-stateOrProvinceName } + +jurisdictionCountryName ATTRIBUTE ::= { + SUBTYPE OF name + WITH SYNTAX CountryName + SINGLE VALUE TRUE + LDAP-SYNTAX countryString.&id + LDAP-NAME {"jurisdictionC"} + ID id-evat-jurisdiction-countryName } + +END +``` + +# Appendix D – Registration Schemes + +The following Registration Schemes are currently recognized as valid under these Requirements: + +- **NTR**: + + The information carried in this field shall be the same as held in the Subject Registration Number attribute as specified in [Section 7.1.4.7](#7147-extended-validation-subject-registration-number) 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.6](#7146-extended-validation-subject-jurisdiction-of-incorporation-or-registration). + + Where the Subject Jurisdiction of Incorporation or Registration attributes specified in [Section 7.1.4.6](#7146-extended-validation-subject-jurisdiction-of-incorporation-or-registration) include more than the country code, the additional locality information shall be included as specified in [Section 7.1.4.8](#7148-extended-validation-subject-organization-identifier) and/or [Section 7.1.2.7.13](#712713-subscriber-certificate-cabrowser-forum-organization-identifier). + +- **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 attribute (see [Section 7.1.4.5](#7145-extended-validation-subject-organization-name)) and Subject Registration Number attribute (see [Section 7.1.4.7](#7147-extended-validation-subject-registration-number)) within the context of the subject's jurisdiction as specified in [Section 7.1.4.6](#7146-extended-validation-subject-jurisdiction-of-incorporation-or-registration). 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 attribute (see [Section 7.1.4.5](#7145-extended-validation-subject-organization-name)) and Subject Registration Number attribute (see [Section 7.1.4.7](#7147-extended-validation-subject-registration-number)) within the context of the subject's jurisdiction as specified in [Section 7.1.4.6](#7146-extended-validation-subject-jurisdiction-of-incorporation-or-registration). The stated address of the organization combined with the organization name SHALL NOT be the only information used to disambiguate the organization. diff --git a/docs/EVG.md b/docs/EVG.md index 00b95946..a971f2f1 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -1,10 +1,10 @@ --- title: Guidelines for the Issuance and Management of Extended Validation Certificates -subtitle: Version 2.0.4 +subtitle: Version 2.0.X author: - CA/Browser Forum -date: 13 August, 2026 +date: TBD copyright: | Copyright 2026 CA/Browser Forum @@ -30,6 +30,8 @@ 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 . +The CA MAY issue EV Certificates, provided that the CA and its Root CA satisfy the requirements in these Guidelines and the Baseline Requirements. + 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. @@ -88,6 +90,7 @@ These Guidelines do not address the verification of information, or the issuance | 2.0.2 | SC095 | Clean-up 2025 | 2026-02-27 | 2026-05-04 | | 2.0.3 | SC087 | Registration Number Improvement for EV Certificates | 2026-06-03 | 2026-07-06 | | 2.0.4 | SC102 | EV Domain Reuse and Validity Alignment | 2026-07-14 | 2026-08-13 | +| 2.0.5 | SC1XX | EVG Cleanup and BR Sync | TBD | TBD | \* Effective Date and Additionally Relevant Compliance Date(s) @@ -95,13 +98,9 @@ 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 | [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-organizational-unit-name-field) | CAs MUST NOT include the organizationalUnitName field in the Subject | -| 2027-09-15 | [7.1.4.2.5](#71425-subject-registration-number-field) | If the CA includes the Date of Formation in the `subject:serialNumber` field, then the CA MUST use the Canonical Date Representation. | -**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. +**Implementers' Note**: 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 @@ -109,19 +108,14 @@ 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 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. +Delegation is governed by Section 1.3.2 of the Baseline Requirements. For the purposes of Section 1.3.2 of the Baseline Requirements, the Section 3.2 requirements that MAY be delegated include the EV validation requirements of [Section 3.2.2](#322-authentication-of-organization-identity) of these Guidelines. Affiliates and/or RAs must comply with the qualification requirements of [Section 5.3.2](#532-background-check-procedures). #### 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; -2. The CA MUST impose these limitations as a contractual requirement with the Enterprise RA and monitor compliance by the Enterprise RA; and -3. The Final Cross-Correlation and Due Diligence requirements of [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence) MAY be performed by a single person representing the Enterprise RA. +1. In all cases, the Subscriber MUST be an organization verified by the CA in accordance with these Guidelines; and +2. The Final Cross-Correlation and Due Diligence requirements of [Section 3.2.2.13](#32213-final-cross-correlation-and-due-diligence) MAY be performed by a single person representing the Enterprise RA. 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. @@ -135,7 +129,7 @@ Enterprise RAs that authorize the issuance of EV Certificates solely for its own ### 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. +EV Certificates are intended for establishing Web-based data communication conduits via the TLS/SSL protocols. #### 1.4.1.1 Primary Purposes @@ -184,8 +178,6 @@ 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. -**Canonical Date Representation**: A date that is formatted as YYYY-MM-DD, where "YYYY" is the four-digit year, "MM" is the two-digit month, and "DD" is the two-digit day of the month. Each element of the date is separated with a single hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8)). Each element is padded with leading zeroes as needed to ensure that year values consist of four digits and month and day of the month values consist of two digits. Example dates in this representation: "0748-04-02", "2024-10-14". - **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 @@ -207,21 +199,10 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **EV Certificate**: A certificate that contains subject information specified in these Guidelines and that has been validated in accordance with these Guidelines. -**EV Certificate Beneficiaries**: Persons to whom the CA and its Root CA make specified EV Certificate Warranties. - -**EV Certificate Renewal**: The process whereby an Applicant who has a valid unexpired and non-revoked EV Certificate makes an application, to the CA that issued the original certificate, for a newly issued EV Certificate for the same organizational name and Domain Name prior to the expiration of the Applicant's existing EV Certificate but with a new 'valid to' date beyond the expiry of the current EV Certificate. - -**EV Certificate Reissuance**: The process whereby an Applicant who has a valid unexpired and non-revoked EV Certificate makes an application, to the CA that issued the original certificate, for a newly issued EV Certificate for the same organizational name and Domain Name prior to the expiration of the Applicant's existing EV Certificate but with a 'valid to' date that matches that of the current EV Certificate. - **EV Certificate Request**: A request from an Applicant to the CA requesting that the CA issue an EV Certificate to the Applicant, which request is validly authorized by the Applicant and signed by the Applicant Representative. **EV Certificate Warranties**: In conjunction with the CA issuing an EV Certificate, the CA and its Root CA, during the period when the EV Certificate is Valid, promise that the CA has followed the requirements of these Guidelines and the CA's EV Policies in issuing the EV Certificate and in verifying the accuracy of the information contained in the EV Certificate. -**EV OID**: An identifying number, in the form of an "object identifier," that is included in the `certificatePolicies` field of a certificate that: - - 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 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. @@ -246,8 +227,6 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Latin Notary**: A person with legal training whose commission under applicable law not only includes authority to authenticate the execution of a signature on a document but also responsibility for the correctness and content of the document. A Latin Notary is sometimes referred to as a Civil Law Notary. -**Legal Entity**: A Private Organization, Government Entity, Business Entity, or Non-Commercial Entity. - **Legal Existence**: A Private Organization, Government Entity, or Business Entity has Legal Existence if it has been validly formed and not otherwise terminated, dissolved, or abandoned. **Legal Practitioner**: A person who is either a lawyer or a Latin Notary as described in these Guidelines and competent to render an opinion on factual claims of the Applicant. @@ -265,11 +244,9 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Private Organization**: A non-governmental legal entity (whether ownership interests are privately held or publicly traded) whose existence was created by a filing with (or an act of) the Incorporating Agency or equivalent in its Jurisdiction of Incorporation. -**Qualified Auditor**: An independent public accounting firm that meets the auditing qualification requirements specified in [Section 8.2](#82-identityqualifications-of-assessor). - -**Qualified Government Information Source**: A database maintained by a Government Entity (e.g. SEC filings) that meets the requirements of [Section 3.2.2.11.6](#322116-qualified-government-information-source). +**Qualified Government 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, provided that it is maintained by a Government Entity, the reporting of data is required by law, and false or misleading reporting is punishable with criminal or civil penalties. Nothing in these Guidelines shall prohibit the use of third-party vendors to obtain the information from the Government Entity provided that the third party obtains the information directly from the Government Entity. -**Qualified Government Tax Information Source**: A Qualified Governmental Information Source that specifically contains tax information relating to Private Organizations, Business Entities, or Individuals. +**Qualified Government Tax Information Source**: A Qualified Government Information Source that specifically contains tax information relating to Private Organizations, Business Entities, or Individuals (e.g., the IRS in the United States). **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. @@ -279,10 +256,6 @@ Capitalized Terms are defined in the Baseline Requirements except where provided ii. a licensing agency, such as a State Department of Insurance; or iii. a chartering agency, such as a state office or department of financial regulation, banking or finance, or a federal agency such as the Office of the Comptroller of the Currency or Office of Thrift Supervision. -**Registration Reference**: A unique identifier assigned to a Legal Entity. - -**Registration Scheme**: A scheme for assigning a Registration Reference meeting the requirements identified in [Appendix H](#appendix-h--registration-schemes). - **Registered Agent**: An individual or entity that is: i. authorized by the Applicant to receive service of process and business communications on behalf of the Applicant; and @@ -294,14 +267,8 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Regulated Financial Institution**: A financial institution that is regulated, supervised, and examined by governmental, national, state or provincial, or local authorities. -**Root Key Generation Script**: A documented plan of procedures to be performed for the generation of the Root CA Key Pair. - **Signing Authority**: One or more Certificate Approvers designated to act on behalf of the Applicant. -**Superior Government Entity**: Based on the structure of government in a political subdivision, the Government Entity or Entities that have the ability to manage, direct and control the activities of the Applicant. - -**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**: 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). @@ -324,30 +291,23 @@ Abbreviations and Acronyms are defined in the Baseline Requirements except as ot | **Acronym** | **Meaning** | | --- | --- | -| BIPM | International Bureau of Weights and Measures | | BIS | (US Government) Bureau of Industry and Security | | CEO | Chief Executive Officer | | CFO | Chief Financial Officer | | CIO | Chief Information Officer | -| CISO | Chief Information Security Officer | | COO | Chief Operating Officer | | CPA | Chartered Professional Accountant | | CSO | Chief Security Officer | | EV | Extended Validation | -| gTLD | Generic Top-Level Domain | -| IFAC | International Federation of Accountants | | IRS | Internal Revenue Service | | ISP | Internet Service Provider | | QGIS | Qualified Government Information Source | | QTIS | Qualified Government Tax Information Source | | QIIS | Qualified Independent Information Source | | SEC | (US Government) Securities and Exchange Commission | -| 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. @@ -358,25 +318,12 @@ By convention, this document omits time and timezones when listing effective req # 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; - -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. +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 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](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): > [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. @@ -423,9 +370,9 @@ Before issuing an EV Certificate, the CA MUST ensure that all Subject organizati 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; +2. Verify the Applicant is a registered holder, or has control, of the Domain Name(s) to be included in the EV Certificate, in accordance with Section 3.2.2.4 or Appendix B of the Baseline Requirements; -3. Verify a reliable means of communication with the entity to be named as the Subject in the Certificate; +3. In addition to the requirements of Section 3.2.5 of the Baseline Requirements, 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; @@ -435,7 +382,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.2 through 3.2.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 @@ -520,7 +467,7 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo 1. Acceptable financial institution documents include: - a. A major credit card, provided that it contains an expiration date and it has not expired' + 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. @@ -538,7 +485,7 @@ 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 verify the Third-Party Validator in accordance with [Section 3.2.2.11.3](#322113-face-to-face-validation). 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: @@ -640,11 +587,11 @@ To verify the Applicant's ability to engage in business, the CA MUST verify the 4. Relying on a Verified Professional Letter to the effect that the Applicant has an active current Demand Deposit Account with a Regulated Financial Institution. -##### 3.2.2.7 Verification of Applicant's Domain Name +#### 3.2.2.7 Verification of Applicant's Domain Name ##### 3.2.2.7.1 Verification Requirements -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. +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 ownership or control of the FQDN by the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) has been validated in accordance with Section 3.2.2.4 of the Baseline Requirements. For a Certificate issued to an Onion Domain Name, the CA SHALL confirm 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. @@ -857,12 +804,12 @@ An Independent Confirmation from the Applicant MAY be obtained via the following ##### 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 database qualifies as a Qualified Independent Information Source (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: +In addition to the requirements of Section 3.2.2.7 of the Baseline Requirements, the CA SHALL review 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. @@ -871,18 +818,16 @@ Databases in which the CA or its owners or affiliated companies maintain a contr ##### 3.2.2.11.6 Qualified Government Information Source -A Qualified Government Information Source (QGIS) is 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 provided that it is maintained by a Government Entity, the reporting of data is required by law, and false or misleading reporting is punishable with criminal or civil penalties. Nothing in these Guidelines shall prohibit the use of third-party vendors to obtain the information from the Government Entity provided that the third party obtains the information directly from the Government Entity. +A Qualified Government Information Source (QGIS) is defined in [Section 1.6.1](#161-definitions). ##### 3.2.2.11.7 Qualified Government Tax Information Source -A Qualified Government Tax Information Source is a Qualified Government Information Source that specifically contains tax information relating to Private Organizations, Business Entities or Individuals (e.g., the IRS in the United States). +A Qualified Government Tax Information Source (QTIS) is defined in [Section 1.6.1](#161-definitions). #### 3.2.2.12 Other Verification Requirements ##### 3.2.2.12.1 High Risk Status -The High Risk Certificate requirements of Section 4.2.1 of the Baseline Requirements apply equally to EV Certificates. - ##### 3.2.2.12.2 Denied Lists and Other Legal Block Lists 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: @@ -920,7 +865,7 @@ A CA verifying an Applicant using information of the Applicant's Parent, Subsidi 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. +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 @@ -941,8 +886,7 @@ If an Applicant has a currently valid EV Certificate issued by the CA, a CA MAY 2. The Applicant's Place of Business under [Section 3.2.2.4.1](#32241-address-of-applicants-place-of-business); 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). +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). ##### 3.2.2.14.2 Re-issuance Requests @@ -953,19 +897,12 @@ A CA may rely on a previously verified certificate request to issue a replacemen ##### 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: +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 maximum reuse periods specified in Section 4.2.1 of the Baseline Requirements, except as follows: - 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 - the maximum data reuse period specified for Domain Names in Section 4.2.1 of the Baseline Requirements; - 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. 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. Each period set forth above SHALL begin to run on the date the relevant 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). -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 @@ -1049,27 +986,26 @@ 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 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. +In addition to the requirements of Section 3.2.5 of the Baseline Requirements, the following Applicant roles, as defined in [Section 1.6.1](#161-definitions) and in Section 1.6.1 of the Baseline Requirements, are required for the issuance of an EV Certificate. -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: +1. **Certificate Requester**: The EV Certificate Request MUST be submitted by an authorized Certificate Requester. - 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. +2. **Certificate Approver**: The EV Certificate Request MUST be approved by an authorized Certificate Approver. -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. -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. 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. +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. + ### 4.2.2 Approval or rejection of certificate applications ### 4.2.3 Time to process certificate applications @@ -1078,8 +1014,6 @@ The Applicant MAY authorize one individual to occupy two or more of these roles. ### 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 @@ -1198,8 +1132,6 @@ Root CA Private Keys MUST NOT be used to sign EV Certificates. # 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 @@ -1228,6 +1160,8 @@ As specified in Section 5 of the Baseline Requirements. In addition, systems use ### 5.2.4 Roles requiring separation of duties +Systems used to process and approve EV Certificate Requests MUST require actions by at least two trusted persons before creating an 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. @@ -1252,15 +1186,11 @@ Prior to the commencement of employment of any person by the CA for engagement i 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 - -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. + D. Search of criminal records (local, state or provincial, and national) where allowed by the jurisdiction in which the person will be employed. ### 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 required internal examination must relate to the EV Certificate validation criteria outlined in these Guidelines. ### 5.3.4 Retraining frequency and requirements @@ -1274,8 +1204,6 @@ The requirements in Section 5.3.3 of the Baseline Requirements apply equally to ## 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 @@ -1328,12 +1256,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: - - 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; - 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. +For Root CA Key Pairs, the option to record a video of the CA Key Pair generation process in lieu of a Qualified Auditor witnessing the process, as permitted by Section 6.1.1.1 of the Baseline Requirements, is not available. ### 6.1.2 Private key delivery to subscriber @@ -1377,8 +1300,6 @@ All requirements in Section 6.1.1.1 of the Baseline Requirements apply equally t ### 6.3.2 Certificate operational periods and key pair usage periods -EV Certificates are subject to the Validity Period requirements of Section 6.3.2 of the Baseline Requirements. - ## 6.4 Activation data ### 6.4.1 Activation data generation and installation @@ -1409,225 +1330,18 @@ EV Certificates are subject to the Validity Period requirements of Section 6.3.2 ## 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. - -#### 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. - -The Registration Scheme MUST be encoded as described by the following ASN.1 grammar: - -```ASN.1 -id-CABFOrganizationIdentifier OBJECT IDENTIFIER ::= { - joint-iso-itu-t(2) international-organizations(23) - ca-browser-forum(140) certificate-extensions(3) - cabf-organizationIdentifier(1) -} - -ext-CABFOrganizationIdentifier EXTENSION ::= { - SYNTAX CABFOrganizationIdentifier - IDENTIFIED BY id-CABFOrganizationIdentifier -} - -CABFOrganizationIdentifier ::= SEQUENCE { - registrationSchemeIdentifier PrintableString (SIZE(3)), - registrationCountry PrintableString (SIZE(2)), - registrationStateOrProvince [0] IMPLICIT PrintableString - (SIZE(1..128)) OPTIONAL, - registrationReference UTF8String -} -``` - -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. - -#### 7.1.4.2 Subject Distinguished Name Fields - -Subject to the requirements of these Guidelines, the EV Certificate and certificates issued to Subordinate CAs that are not controlled by the same entity as the CA MUST include the following information about the Subject organization in the fields listed: - -##### 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. - -In addition, an assumed name or DBA name used by the Subject MAY be included at the beginning of this field, provided that it is followed by the full legal organization name in parenthesis. - -If the combination of names or the organization name by itself exceeds 64 characters, the CA MAY abbreviate parts of the organization name, and/or omit non-material words in the organization name in such a way that the text in this field does not exceed the 64-character limit; provided that the CA checks this field in accordance with [Section 3.2.2.12.1](#322121-high-risk-status) and a Relying Party will not be misled into thinking that they are dealing with a different organization. In cases where this is not possible, the CA MUST NOT issue the EV Certificate. - -##### 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) -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. - -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, the CA SHALL include the Registration Number that it obtained and verified in accordance with [Section 3.2.2.2.1](#32221-verification-requirements) (1.A). If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the CA SHALL include the Date of Formation in any one of the common date formats. Effective 2027-09-15, if the CA includes the Date of Formation, then the CA MUST use the Canonical Date Representation. - -For Government Entities, the CA SHALL include the Registration Number that it obtained and verified in accordance with [Section 3.2.2.2.1](#32221-verification-requirements) (1.B). If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the CA SHALL include the Date of Formation in any one of the common date formats. If the Jurisdiction of Incorporation or Registration does not provide a Date of Formation for the Applicant, then the CA SHALL indicate that the Subject is a Government Entity by including the string "Government Entity" or another appropriate value. Effective 2027-09-15, if the CA includes the Date of Formation, then the CA MUST use the Canonical Date Representation. - -For Business Entities, the CA SHALL include the Registration Number that it obtained and verified in accordance with [Section 3.2.2.2.1](#32221-verification-requirements) (1.C). If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the CA SHALL include the Date of Formation in any one of the common date formats. Effective 2027-09-15, if the CA includes the Date of Formation, then the CA MUST use the Canonical Date Representation. - -For Non‐Commercial Entity Subjects (International Organizations), the CA SHALL include the Date of Formation as obtained and verified in accordance with [Section 3.2.2.2.1](#32221-verification-requirements) (1.D), using any one of the common date formats. If the Jurisdiction of Incorporation or Registration does not provide a Date of Formation for the Applicant, then the CA SHALL indicate that the Subject is a Non-Commercial Entity by including the string "Non-Commercial Entity" or another appropriate value. Effective 2027-09-15, if the CA includes the Date of Formation, then the CA MUST use the Canonical Date Representation. - -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 -**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 - -**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. - -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. - -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) - -Registration Schemes listed in [Appendix H](#appendix-h--registration-schemes) are currently recognized as valid under these guidelines. - -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); -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). - -##### 7.1.4.2.9 Other Subject Attributes - -CAs SHALL NOT include any Subject Distinguished Name attributes except as specified in [Section 7.1.4.2](#7142-subject-distinguished-name-fields). - -#### 7.1.4.3 Additional Technical Requirements for EV Certificates - -All provisions of the Baseline Requirements concerning Minimum Cryptographic Algorithms, Key Sizes, and Certificate Extensions apply to EV Certificates with the following exceptions: - -1. If a Subordinate CA Certificates is issued to a Subordinate CA not controlled by the entity that controls the Root CA, the policy identifiers in the `certificatePolicies` extension MUST include the CA's Extended Validation policy identifier. - - Otherwise, it MAY contain the anyPolicy identifier. - -2. The `certificatePolicies` extension in EV Certificates issued to Subscribers MUST include the following: - - - `certificatePolicies:policyIdentifier` (Required) - - The Issuer's EV policy identifier - -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.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 - -Each EV Certificate issued by the CA to a Subscriber MUST contain a policy identifier that is either defined by these Guidelines or the CA in the certificate's `certificatePolicies` extension that: - -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. - -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 - -The Application Software Supplier identifies Root CAs that are approved to issue EV Certificates by storing EV policy identifiers in metadata associated with Root CA Certificates. - -#### 7.1.6.3 EV Subordinate CA Certificates - -1. Certificates issued to Subordinate CAs that are not controlled by the issuing CA MUST contain one or more policy identifiers defined by the issuing CA that explicitly identify the EV Policies that are implemented by the Subordinate CA. -2. Certificates issued to Subordinate CAs that are controlled by the Root CA MAY contain the special `anyPolicy` identifier (OID: 2.5.29.32.0). - -#### 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. - ### 7.1.7 Usage of Policy Constraints extension ### 7.1.8 Policy qualifiers syntax and semantics @@ -1648,26 +1362,19 @@ A Certificate issued to a Subscriber MUST contain one or more policy identifier( # 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS -A CA issuing EV Certificates SHALL undergo an audit in accordance with one of the following schemes: +In addition to the audit required by Section 8.4 of the Baseline Requirements, a CA issuing EV Certificates SHALL undergo an audit in accordance with one of the following schemes: -i. WebTrust Program for CAs audit and WebTrust EV Program audit, -ii. ETSI TS 102 042 audit for EVCP, or -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. +i. WebTrust EV Program audit, or +ii. ETSI EN 319 411-1 audit for EVCP policy. ## 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. +In addition to the Self-Audits required by Section 8.7 of the Baseline Requirements, 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 @@ -1676,16 +1383,10 @@ 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. - ## 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. -3. If the CA has a currently valid ETSI EN 319 411-1 audit for EVCP policy, then, before issuing EV Certificates, the CA and its Root CA MUST successfully complete a point-in-time readiness assessment audit against ETSI EN 319 411-1 for EVCP. -4. If the CA does not have a currently valid WebTrust Seal of Assurance for CAs or an ETSI TS 102 042 EVCP audit or an ETSI EN 319 411-1 audit for EVCP policy, then, before issuing EV Certificates, the CA and its Root CA MUST successfully complete either: - 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. +2. If the CA has a currently valid ETSI EN 319 411-1 audit for EVCP policy, then, before issuing EV Certificates, the CA and its Root CA MUST successfully complete a point-in-time readiness assessment audit against ETSI EN 319 411-1 for EVCP. 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. @@ -1757,28 +1458,12 @@ When the CA issues an EV Certificate, the CA and its Root CA represent and warra 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; - -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; - -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; - -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. +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. ### 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 @@ -1791,8 +1476,6 @@ CAs MAY limit their liability as described in Section 9.8 of the Baseline Requir ## 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 @@ -1825,24 +1508,12 @@ 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. - -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; - ii. revoked; and - iii. expired. - # Appendix B - Sample Attorney Opinions Confirming Specified Information **(Informative)** @@ -2052,79 +1723,3 @@ CA and Applicant are entering into a legally valid and enforceable Subscriber Ag 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 iii. has confirmed Applicant's right to use the domain(s) to be included in EV Certificates. - -# Appendix F – Unused - -This appendix is intentionally left blank. - -# Appendix G – Abstract Syntax Notation One module for EV certificates - -```ASN.1 -CABFSelectedAttributeTypes { - joint-iso-itu-t(2) international-organizations(23) - ca-browser-forum(140) module(4) - cabfSelectedAttributeTypes(1) 1 } -DEFINITIONS ::= -BEGIN --- EXPORTS All -IMPORTS - -- from Rec. ITU-T X.501 | ISO/IEC 9594-2 - selectedAttributeTypes, ID, ldap-enterprise - FROM UsefulDefinitions {joint-iso-itu-t ds(5) module(1) - usefulDefinitions(0) 7} - - -- from the X.500 series - ub-locality-name, ub-state-name - FROM UpperBounds {joint-iso-itu-t ds(5) module(1) upperBounds(10) 7} - - -- from Rec. ITU-T X.520 | ISO/IEC 9594-6 - DirectoryString{}, CountryName - FROM SelectedAttributeTypes selectedAttributeTypes; - -id-evat-jurisdiction ID ::= {ldap-enterprise 311 ev(60) 2 1} -id-evat-jurisdiction-localityName ID ::= {id-evat-jurisdiction 1} -id-evat-jurisdiction-stateOrProvinceName ID ::= {id-evat-jurisdiction 2} -id-evat-jurisdiction-countryName ID ::= {id-evat-jurisdiction 3} - -jurisdictionLocalityName ATTRIBUTE ::= { - SUBTYPE OF name - WITH SYNTAX DirectoryString{ub-locality-name} - LDAP-SYNTAX directoryString.&id - LDAP-NAME {"jurisdictionL"} - ID id-evat-jurisdiction-localityName } - -jurisdictionStateOrProvinceName ATTRIBUTE ::= { - SUBTYPE OF name - WITH SYNTAX DirectoryString{ub-state-name} - LDAP-SYNTAX directoryString.&id - LDAP-NAME {"jurisdictionST"} - ID id-evat-jurisdiction-stateOrProvinceName } - -jurisdictionCountryName ATTRIBUTE ::= { - SUBTYPE OF name - WITH SYNTAX CountryName - SINGLE VALUE TRUE - LDAP-SYNTAX countryString.&id - LDAP-NAME {"jurisdictionC"} - ID id-evat-jurisdiction-countryName } - -END -``` - -# Appendix H – Registration Schemes - -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.