From f6de26d56d2adb0b1b9c7433437cec1b03732190 Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Tue, 14 May 2024 17:12:34 -0400 Subject: [PATCH 01/12] First stab at the language --- docs/EVG.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index c76e1e697..84b0da3c9 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.1 +subtitle: Version 2.0.X author: - CA/Browser Forum -date: 6 May, 2024 +date: X YY, 2024 copyright: | Copyright 2024 CA/Browser Forum @@ -1366,13 +1366,17 @@ Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, t __Certificate Field__: `subject:serialNumber` (OID: 2.5.4.5) __Required/Optional__: __Required__ -__Contents__: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field in any one of the common date formats. +__Contents__: For Private Organizations, this field MUST contain the Registration Number (or similar value) assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field in any one of the common date formats. -For Government Entities that do not have a Registration Number or readily verifiable date of creation, the CA SHALL enter appropriate language to indicate that the Subject is a Government Entity. +For Government Entities, this field MUST contain a value that conforms to one of the following options: + +1. A Registration Number (or similar value) assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate; or +2. If the Government Entity does not have a Registration Number: the readily verifiable date of creation of the Government Entity; or +3. If both a Registration Number (or similar) has not been assigned and the readily verifiable date of creation is not available: appropriate language to indicate that the Subject is a Government Entity. For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in any one of the common date formats. -Effective as of 1 October 2020, if the CA has disclosed a set of acceptable format or formats for Registration Numbers for the applicable Registration Agency or Incorporating Agency, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), the CA MUST ensure, prior to issuance, that the Registration Number is valid according to at least one currently disclosed format for that applicable Registration Agency or Incorporating agency. +If the CA has disclosed a set of acceptable format or formats for Registration Numbers for the applicable Registration Agency or Incorporating Agency, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), the CA MUST ensure, prior to issuance, that the Registration Number is valid according to at least one currently disclosed format for that applicable Registration Agency or Incorporating agency. ##### 7.1.4.2.6 Subject Physical Address of Place of Business Field From cca75411b7308bc06c4fe5db0ba595a02556e39d Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Thu, 16 May 2024 07:36:03 -0400 Subject: [PATCH 02/12] Update docs/EVG.md --- docs/EVG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/EVG.md b/docs/EVG.md index 84b0da3c9..0d60dc69b 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -1372,7 +1372,7 @@ For Government Entities, this field MUST contain a value that conforms to one of 1. A Registration Number (or similar value) assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate; or 2. If the Government Entity does not have a Registration Number: the readily verifiable date of creation of the Government Entity; or -3. If both a Registration Number (or similar) has not been assigned and the readily verifiable date of creation is not available: appropriate language to indicate that the Subject is a Government Entity. +3. If both a Registration Number (or similar value) has not been assigned and the readily verifiable date of creation is not available: appropriate language to indicate that the Subject is a Government Entity. For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in any one of the common date formats. From 1b814bdfbc569e8e21dd1eeb611429146d03ef1c Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Wed, 22 May 2024 15:51:50 -0400 Subject: [PATCH 03/12] Update EVG.md --- docs/EVG.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 0d60dc69b..aef7d4a8b 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -1371,8 +1371,8 @@ __Contents__: For Private Organizations, this field MUST contain the Registratio For Government Entities, this field MUST contain a value that conforms to one of the following options: 1. A Registration Number (or similar value) assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate; or -2. If the Government Entity does not have a Registration Number: the readily verifiable date of creation of the Government Entity; or -3. If both a Registration Number (or similar value) has not been assigned and the readily verifiable date of creation is not available: appropriate language to indicate that the Subject is a Government Entity. +2. If a Registration Number (or similar value) assigned to the Subject is not available: the readily verifiable date of creation of the Government Entity; or +3. If both a Registration Number (or similar value) and the readily verifiable date of creation are not available: appropriate language to indicate that the Subject is a Government Entity. For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in any one of the common date formats. From 706ea6b02b0b8fbc9a50ccf27ce646b7815220f7 Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Thu, 23 May 2024 15:46:38 -0400 Subject: [PATCH 04/12] Take 2 --- docs/EVG.md | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index aef7d4a8b..2c084e9c3 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -266,7 +266,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Registered Office**: The official address of a company, as recorded with the Incorporating Agency, to which official documents are sent and at which legal notices are received. -**Registration Number**: The unique number assigned to a Private Organization by the Incorporating Agency in such entity's Jurisdiction of Incorporation. +**Registration Number**: A number or identifier assigned to a Legal Entity. **Regulated Financial Institution**: A financial institution that is regulated, supervised, and examined by governmental, national, state or provincial, or local authorities. @@ -425,14 +425,14 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo A. **Legal Existence**: Verify that the Applicant is a legally recognized entity, in existence and validly formed (e.g., incorporated) with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration, and not designated on the records of the Incorporating or Registration Agency by labels such as "inactive", "invalid", "not current", or the equivalent. B. **Organization Name**: Verify that the Applicant's formal legal name as recorded with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: Obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Incorporation or Registration. + C. **Registration Number**: Attempt to obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Incorporation or Registration. D. **Registered Agent**: Obtain the identity and address of the Applicant's Registered Agent or Registered Office (as applicable in the Applicant's Jurisdiction of Incorporation or Registration). 2. **Government Entity Subjects** A. **Legal Existence**: Verify that the Applicant is a legally recognized Government Entity, in existence in the political subdivision in which such Government Entity operates. B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of incorporation, registration, or formation, or the identifier for the legislative act that created the Government Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is a Government Entity. + C. **Registration Number**: Attempt to obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Registration Agency does assign a Registration Number, the CA SHALL attempt to obtain the Applicant's date of incorporation, registration, or formation that created the Government Entity. 3. **Business Entity Subjects** @@ -445,7 +445,7 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo A. **Legal Existence**: Verify that the Applicant is a legally recognized International Organization Entity. B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: The CA MUST attempt to obtain the Applicant's date of formation, or the identifier for the legislative act that created the International Organization Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is an International Organization Entity. + C. **Registration Number**: Attempt to obtain the Applicant's date of formation. ##### 3.2.2.2.2 Acceptable Method of Verification @@ -1366,15 +1366,13 @@ Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, t __Certificate Field__: `subject:serialNumber` (OID: 2.5.4.5) __Required/Optional__: __Required__ -__Contents__: For Private Organizations, this field MUST contain the Registration Number (or similar value) assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field in any one of the common date formats. +__Contents__: For Private Organizations, 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 Registration Number is a date of Incorporation or Registration, then the CA SHALL include that date in any one of the common date formats. -For Government Entities, this field MUST contain a value that conforms to one of the following options: +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 Registration Number is a date of incorporation, registration, or formation, then the CA SHALL include that date in any one of the common date formats. If no verifiable Registration Number could be obtained for the Applicant, then the CA SHALL include appropriate language to indicate that the Subject is a Government Entity. -1. A Registration Number (or similar value) assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate; or -2. If a Registration Number (or similar value) assigned to the Subject is not available: the readily verifiable date of creation of the Government Entity; or -3. If both a Registration Number (or similar value) and the readily verifiable date of creation are not available: appropriate language to indicate that the Subject is a Government Entity. +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 Registration Number is a date of Registration, then the CA SHALL include that date in any one of the common date formats. -For Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in any one of the common date formats. +For Non‐Commercial Entity Subjects (International Organizations), the CA SHALL include the Registration Number 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 CA has disclosed a set of acceptable format or formats for Registration Numbers for the applicable Registration Agency or Incorporating Agency, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), the CA MUST ensure, prior to issuance, that the Registration Number is valid according to at least one currently disclosed format for that applicable Registration Agency or Incorporating agency. From b363557f3e00a6a4da2ae42ad8e4f991f6a8a9c3 Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Thu, 23 May 2024 17:30:26 -0400 Subject: [PATCH 05/12] Fix date of creation language for Govt entity --- docs/EVG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/EVG.md b/docs/EVG.md index 2c084e9c3..bbd0649ec 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -432,7 +432,7 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo A. **Legal Existence**: Verify that the Applicant is a legally recognized Government Entity, in existence in the political subdivision in which such Government Entity operates. B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: Attempt to obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Registration Agency does assign a Registration Number, the CA SHALL attempt to obtain the Applicant's date of incorporation, registration, or formation that created the Government Entity. + C. **Registration Number**: Attempt to obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Registration Agency does assign a Registration Number, the CA SHALL attempt to obtain the Applicant's date of incorporation, registration, or formation. 3. **Business Entity Subjects** From b9ac3697f6c8484e3bb98ee08f043e67ca039a9d Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Thu, 23 May 2024 17:48:28 -0400 Subject: [PATCH 06/12] Clean up disclosure req --- docs/EVG.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index bbd0649ec..6ab9effb1 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -404,13 +404,13 @@ As a general rule, the CA is responsible for taking all verification steps reaso ##### 3.2.2.1.3 Disclosure of Verification Sources -Effective as of 1 October 2020, prior to the use of an Incorporating Agency or Registration Agency to fulfill these verification requirements, the CA MUST publicly disclose Agency Information about the Incorporating Agency or Registration Agency. This disclosure SHALL be through an appropriate and readily accessible online means. +Prior to the use of an Incorporating Agency or Registration Agency to fulfill these verification requirements, the CA MUST publicly disclose Agency Information about the Incorporating Agency or Registration Agency. This disclosure SHALL be through an appropriate and readily accessible online means. This Agency Information SHALL include at least the following: * Sufficient information to unambiguously identify the Incorporating Agency or Registration Agency (such as a name, jurisdiction, and website); and, * The accepted value or values for each of the `subject:jurisdictionLocalityName` (OID: 1.3.6.1.4.1.311.60.2.1.1), `subject:jurisdictionStateOrProvinceName` (OID: 1.3.6.1.4.1.311.60.2.1.2), and `subject:jurisdictionCountryName` (OID: 1.3.6.1.4.1.311.60.2.1.3) fields, when a certificate is issued using information from that Incorporating Agency or Registration Agency, indicating the jurisdiction(s) that the Agency is appropriate for; and, -* The acceptable form or syntax of Registration Numbers used by the Incorporating Agency or Registration Agency, if the CA restricts such Numbers to an acceptable form or syntax; and, +* The acceptable form or syntax of Registration Numbers that are assigned by the Incorporating Agency or Registration Agency, if the CA restricts such Numbers to an acceptable form or syntax; and, * A revision history that includes a unique version number and date of publication for any additions, modifications, and/or removals from this list. The CA MUST document where to obtain this information within Section 3.2 of the CA's Certificate Policy and/or Certification Practice Statement. @@ -1374,7 +1374,7 @@ For Business Entities, the CA SHALL include the Registration Number that it obta For Non‐Commercial Entity Subjects (International Organizations), the CA SHALL include the Registration Number 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 CA has disclosed a set of acceptable format or formats for Registration Numbers for the applicable Registration Agency or Incorporating Agency, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), the CA MUST ensure, prior to issuance, that the Registration Number is valid according to at least one currently disclosed format for that applicable Registration Agency or Incorporating agency. +If the CA has disclosed a set of acceptable format or formats for Registration Numbers for the applicable Registration Agency or Incorporating Agency, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), the CA MUST ensure, prior to issuance, that the Registration Number is valid according to at least one currently disclosed format for that applicable Registration Agency or Incorporating Agency. ##### 7.1.4.2.6 Subject Physical Address of Place of Business Field From c71e1fa7f4314e4e3ba36024e9c9226781b4c040 Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Fri, 24 May 2024 07:44:50 -0400 Subject: [PATCH 07/12] More fixes, new term --- docs/EVG.md | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 6ab9effb1..0b9c11ba2 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -177,6 +177,8 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Contract Signer**: A natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements. +**Date of Formation**: The date on which a Legal Entity is first recognized by the jurisdiction in which it was created. + **Demand Deposit Account**: A deposit account held at a bank or other financial institution, the funds deposited in which are payable on demand. The primary purpose of demand accounts is to facilitate cashless payments by means of check, bank draft, direct debit, electronic funds transfer, etc. Usage varies among countries, but a demand deposit account is commonly known as a share draft account, a current account, or a checking account. **EV Authority**: A source other than the Certificate Approver, through which verification occurs that the Certificate Approver is expressly authorized by the Applicant, as of the date of the EV Certificate Request, to take the Request actions described in these Guidelines. @@ -266,7 +268,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Registered Office**: The official address of a company, as recorded with the Incorporating Agency, to which official documents are sent and at which legal notices are received. -**Registration Number**: A number or identifier assigned to a Legal Entity. +**Registration Number**: The unique number assigned to a Business Entity, Private Organization, or Government Entity by the Incorporating Agency in such entity's Jurisdiction of Incorporation or Registration. **Regulated Financial Institution**: A financial institution that is regulated, supervised, and examined by governmental, national, state or provincial, or local authorities. @@ -425,27 +427,27 @@ To verify the Applicant's legal existence and identity, the CA MUST do the follo A. **Legal Existence**: Verify that the Applicant is a legally recognized entity, in existence and validly formed (e.g., incorporated) with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration, and not designated on the records of the Incorporating or Registration Agency by labels such as "inactive", "invalid", "not current", or the equivalent. B. **Organization Name**: Verify that the Applicant's formal legal name as recorded with the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: Attempt to obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Incorporation or Registration. + C. **Registration Number or Date of Formation**: Attempt to obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's Date of Formation. D. **Registered Agent**: Obtain the identity and address of the Applicant's Registered Agent or Registered Office (as applicable in the Applicant's Jurisdiction of Incorporation or Registration). 2. **Government Entity Subjects** A. **Legal Existence**: Verify that the Applicant is a legally recognized Government Entity, in existence in the political subdivision in which such Government Entity operates. B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: Attempt to obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Registration Agency does assign a Registration Number, the CA SHALL attempt to obtain the Applicant's date of incorporation, registration, or formation. + C. **Registration Number or Date of Formation**: Attempt to obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Where the Registration Agency does not assign a Registration Number, the CA SHALL attempt to obtain the Applicant's Date of Formation. 3. **Business Entity Subjects** A. **Legal Existence**: Verify that the Applicant is engaged in business under the name submitted by the Applicant in the Application. B. **Organization Name**: Verify that the Applicant's formal legal name as recognized by the Registration Agency in the Applicant's Jurisdiction of Registration matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: Attempt to obtain the specific unique Registration Number assigned to the Applicant by the Registration Agency in the Applicant's Jurisdiction of Registration. Where the Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's date of Registration. + C. **Registration Number or Date of Formation**: Attempt to obtain the specific unique Registration Number assigned to the Applicant by the Registration Agency in the Applicant's Jurisdiction of Registration. Where the Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant's Date of Formation. D. **Principal Individual**: Verify the identity of the identified Principal Individual. 4. **Non-Commercial Entity Subjects (International Organizations)** A. **Legal Existence**: Verify that the Applicant is a legally recognized International Organization Entity. B. **Entity Name**: Verify that the Applicant's formal legal name matches the Applicant's name in the EV Certificate Request. - C. **Registration Number**: Attempt to obtain the Applicant's date of formation. + C. **Date of Formation**: Attempt to obtain the Applicant's Date of Formation. ##### 3.2.2.2.2 Acceptable Method of Verification @@ -1366,13 +1368,13 @@ Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, t __Certificate Field__: `subject:serialNumber` (OID: 2.5.4.5) __Required/Optional__: __Required__ -__Contents__: For Private Organizations, 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 Registration Number is a date of Incorporation or Registration, then the CA SHALL include that date in any one of the common date formats. +__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. -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 Registration Number is a date of incorporation, registration, or formation, then the CA SHALL include that date in any one of the common date formats. If no verifiable Registration Number could be obtained for the Applicant, then the CA SHALL include appropriate language to indicate that the Subject is a Government Entity. +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 no verifiable Date of Formation could be obtained for the Applicant, then the CA SHALL include appropriate language to indicate that the Subject is a Government Entity (e.g., the string "Government Entity", the name or identifier of the legislative act that created the Government Entity, etc.). -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 Registration Number is a date of Registration, then the CA SHALL include that date in any one of the common date formats. +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. -For Non‐Commercial Entity Subjects (International Organizations), the CA SHALL include the Registration Number 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. +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 no verifiable Date of Formation could be obtained for the Applicant, then the CA SHALL include appropriate language to indicate that the Subject is a Non-Commercial Entity (e.g., the string "Non-Commercial Entity", the name or identifier of the legislative act that created the Non-Commercial Entity, etc.). If the CA has disclosed a set of acceptable format or formats for Registration Numbers for the applicable Registration Agency or Incorporating Agency, as described in [Section 3.2.2.1.3](#32213-disclosure-of-verification-sources), the CA MUST ensure, prior to issuance, that the Registration Number is valid according to at least one currently disclosed format for that applicable Registration Agency or Incorporating Agency. From 136fd0ccaf030e5c6e98cfaf6f5ffebb7c572e25 Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Fri, 9 Aug 2024 11:42:15 -0400 Subject: [PATCH 08/12] Add "formed" to "Date of Formation" Defined Term --- docs/EVG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/EVG.md b/docs/EVG.md index 0b9c11ba2..378d6a23b 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -177,7 +177,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Contract Signer**: A natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements. -**Date of Formation**: The date on which a Legal Entity is first recognized by the jurisdiction in which it was created. +**Date of Formation**: The date on which a Legal Entity is first recognized by the jurisdiction in which it was created or formed. **Demand Deposit Account**: A deposit account held at a bank or other financial institution, the funds deposited in which are payable on demand. The primary purpose of demand accounts is to facilitate cashless payments by means of check, bank draft, direct debit, electronic funds transfer, etc. Usage varies among countries, but a demand deposit account is commonly known as a share draft account, a current account, or a checking account. From 561d84a2bb8e4baeda98479c84a1ff87f9088d32 Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Fri, 9 Aug 2024 11:47:38 -0400 Subject: [PATCH 09/12] Bump to latest (#7) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Ballot SC-073: Compromised and Weak Keys (#500) (#509) * Ballot SC-073: Compromised and Weak Keys (#500) * Draft SC-073 language * Fix link * Update BR.md Updated version, date and revisions --------- Co-authored-by: Wayne Thayer * Auto-comment on new issues stating which TLS BR and EVG versions were active at the time (#521) * Ballot SC-75 - Pre-sign linting (#527) * Ballot SC-75 - Pre-sign linting (#518) * Define "Linting" and relevant language in 4.3.1.2. * Addresses https://github.com/cabforum/servercert/pull/518#discussion_r1611584438 * Addressing comments of the email thread https://lists.cabforum.org/pipermail/servercert-wg/2024-May/004603.html up to 2024-06-05. * Delete duplicate text * Update to-be-issued with to-be-signed for consistency * Fix based on https://github.com/cabforum/servercert/commit/ff98db748736ed19c0c4fc41e59ced4d1ff97b3e#r142754475 * Second fix based on https://github.com/cabforum/servercert/commit/ff98db748736ed19c0c4fc41e59ced4d1ff97b3e#r142754475 * Language improvements * Language improvements * Fix capital first letter Co-authored-by: Corey Bonnell * Fix capital first letter Co-authored-by: Corey Bonnell * fix capitalization Co-authored-by: Corey Bonnell * Moving to a more appropriate section based on https://github.com/cabforum/servercert/pull/518#discussion_r1629665087 * Moving to a more appropriate section based on https://github.com/cabforum/servercert/pull/518#discussion_r1629666352 * Adding suggestion for CAs to report inaccurate linting results in open-source linting projects. * Language improvements * Improved language for the need of Linting Co-authored-by: Rob Stradling * Remove double space * Improve language * Clarify language for linting during self-audits Co-authored-by: Martijn Katerbarg * Fix typo * Small language improvement * Fix table formatting * Fix table formatting --------- Co-authored-by: Corey Bonnell Co-authored-by: Rob Stradling Co-authored-by: Martijn Katerbarg * Update BR.md changed version and dates as per SC75 --------- Co-authored-by: Dimitris Zacharopoulos Co-authored-by: Corey Bonnell Co-authored-by: Rob Stradling Co-authored-by: Martijn Katerbarg --------- Co-authored-by: Iñigo Barreira <92998585+barrini@users.noreply.github.com> Co-authored-by: Wayne Thayer Co-authored-by: Martijn Katerbarg Co-authored-by: Dimitris Zacharopoulos Co-authored-by: Rob Stradling --- .../tag-version-at-issue-creation.yml | 36 +++++ docs/BR.md | 151 ++++++++++++------ 2 files changed, 135 insertions(+), 52 deletions(-) create mode 100644 .github/workflows/tag-version-at-issue-creation.yml diff --git a/.github/workflows/tag-version-at-issue-creation.yml b/.github/workflows/tag-version-at-issue-creation.yml new file mode 100644 index 000000000..89cc74126 --- /dev/null +++ b/.github/workflows/tag-version-at-issue-creation.yml @@ -0,0 +1,36 @@ +name: Reference TLS BR and EVG version upon issue creation +on: + issues: + types: [opened] + +jobs: + tls-evg-version: + name: Reference TLS BR and EVG version upon issue creation + runs-on: ubuntu-latest + + steps: + - name: Checkout repository + uses: actions/checkout@v4 + + - name: Read version from TLS BR + id: read_tlsbr_version + run: | + subtitle=$(grep -Po '(?<=subtitle:\s).*$' docs/BR.md | tr -d '\r') + echo "tlsbr_version=$subtitle" >> $GITHUB_OUTPUT + + - name: Read version from EVG + id: read_evg_version + run: | + subtitle=$(grep -Po '(?<=subtitle:\s).*$' docs/EVG.md | tr -d '\r') + echo "evg_version=$subtitle" >> $GITHUB_OUTPUT + + - name: Add comment to issue + uses: peter-evans/create-or-update-comment@v4 + with: + token: ${{ secrets.GITHUB_TOKEN }} + issue-number: ${{ github.event.issue.number }} + body: | + This issue was created based on: + - TLS BR ${{ steps.read_tlsbr_version.outputs.tlsbr_version }} + - EVG ${{ steps.read_evg_version.outputs.evg_version }} + diff --git a/docs/BR.md b/docs/BR.md index e4dcc98e1..795ae352c 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1,10 +1,10 @@ --- title: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates -subtitle: Version 2.0.4 +subtitle: Version 2.0.6 author: - CA/Browser Forum -date: 17-April-2024 +date: 5-August-2024 @@ -139,57 +139,62 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2.0.2 | SC66 | 2023 Cleanup | 23-Nov-2023 | 8-Jan-2024 | | 2.0.3 | SC69 | Clarify router and firewall logging requirements | 13-March-2024 | 15-April-2024 | | 2.0.4 | SC65 | Convert EVGs into RFC 3647 format | 15-March-2024 | 15-May-2024 | +| 2.0.5 | SC73 | Compromised and weak keys | 3-May-2024 | 1-July-2024 | +| 2.0.6 | SC75 | Pre-sign linting | 28-June-2024 | 6-August-2024 | \* Effective Date and Additionally Relevant Compliance Date(s) ### 1.2.2 Relevant Dates -| **Compliance** | **Section(s)** | **Summary Description (See Full Text for Details)** | -|--|--|----------| -| 2013-01-01 | 6.1.6 | For RSA public keys, CAs SHALL confirm that the value of the public exponent is an odd number equal to 3 or more. | -| 2013-01-01 | 4.9.10 | CAs SHALL support an OCSP capability using the GET method. | -| 2013-01-01 | 5 | CAs SHALL comply with the Network and Certificate System Security Requirements. | -| 2013-08-01 | 4.9.10 | OCSP Responders SHALL NOT respond "Good" for Unissued Certificates. | -| 2013-09-01 | 3.2.2.6 | CAs SHALL revoke any certificate where wildcard character occurs in the first label position immediately to the left of a "registry-controlled" label or "public suffix". | -| 2013-12-31 | 6.1.5 | CAs SHALL confirm that the RSA Public Key is at least 2048 bits or that one of the following ECC curves is used: P-256, P-384, or P-521. A Root CA Certificate issued prior to 31 Dec. 2010 with an RSA key size less than 2048 bits MAY still serve as a trust anchor. | -| 2015-01-16 | 7.1.3 | CAs SHOULD NOT issue Subscriber Certificates utilizing the SHA-1 algorithm with an Expiry Date greater than 1 January 2017. | -| 2015-04-01 | 6.3.2 | CAs SHALL NOT issue certificates with validity periods longer than 39 months, except under certain circumstances. | -| 2015-04-15 | 2.2 | A CA's CPS must state whether it reviews CAA Records, and if so, its policy or practice on processing CAA records for Fully-Qualified Domain Names. | -| 2015-11-01 | 7.1.4.2.1 | Issuance of Certificates with Reserved IP Address or Internal Name prohibited. | -| 2016-01-01 | 7.1.3 | CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA-1 hash algorithm. | -| 2016-06-30 | 6.1.7 | CAs MUST NOT issue Subscriber Certificates directly from Root CAs. | -| 2016-06-30 | 6.3.2 | CAs MUST NOT issue Subscriber Certificates with validity periods longer than 39 months, regardless of circumstance. | -| 2016‐09‐30 | 7.1 | CAs SHALL generate Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG | -| 2016-10-01 | 7.1.4.2.1 | All Certificates with Reserved IP Address or Internal Name must be revoked. | -| 2016-12-03 | 1 and 2 | Ballot 156 amendments to sections 1.5.2, 2.3, and 2.4 are applicable | -| 2017-01-01 | 7.1.3 | CAs MUST NOT issue OCSP responder certificates using SHA-1 (inferred). | -| 2017-03-01 | 3.2.2.4 | CAs MUST follow revised validation requirements in Section 3.2.2.4. | -| 2017-09-08 | 3.2.2.8 | CAs MUST check and process CAA records | -| 2018-03-01 | 4.2.1 and 6.3.2 | Certificates issued MUST have a Validity Period no greater than 825 days and re-use of validation information limited to 825 days | -| 2018-05-31 | 2.2 | CP and CPS must follow RFC 3647 format | -| 2018-08-01 | 3.2.2.4.1 and .5 | CAs must stop using domain validation methods BR 3.2.2.4.1 and 3.2.2.4.5, stop reusing validation data from those methods | -| 2019-01-15 | 7.1.4.2.1 | All certificates containing an underscore character in any dNSName entry and having a validity period of more than 30 days MUST be revoked prior to January 15, 2019 | -| 2019-05-01 | 7.1.4.2.1 | underscore characters (“_”) MUST NOT be present in dNSName entries | -| 2019-06-01 | 3.2.2.4.3 | CAs SHALL NOT perform validations using this method after May 31, 2019. Completed validations using this method SHALL continue to be valid for subsequent issuance per the applicable certificate data reuse periods. -| 2019-08-01 | 3.2.2.5 | CAs SHALL maintain a record of which IP validation method, including the relevant BR version number, was used to validate every IP Address | -| 2019-08-01 | 3.2.2.5.4 | CAs SHALL NOT perform validations using this method after July 31, 2019. Completed validations using this method SHALL NOT be re-used for certificate issuance after July 31, 2019. Any certificate issued prior to August 1, 2019 containing an IP Address that was validated using any method that was permitted under the prior version of this Section 3.2.2.5 MAY continue to be used without revalidation until such certificate naturally expires | -| 2020-06-03 | 3.2.2.4.6 | CAs MUST NOT perform validation using this method after 3 months from the IPR review date of Ballot SC25 | -| 2020-08-01 | 8.6 | Audit Reports for periods on-or-after 2020-08-01 MUST be structured as defined. | -| 2020-09-01 | 6.3.2 | Certificates issued SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. | -| 2020-09-30 | 4.9.10 | OCSP responses MUST conform to the validity period requirements specified. | -| 2020-09-30 | 7.1.4.1 | Subject and Issuer Names for all possible certification paths MUST be byte-for-byte identical. | -| 2020-09-30 | 7.1.6.4 | Subscriber Certificates MUST include a CA/Browser Forum Reserved Policy Identifier in the Certificate Policies extension. | -| 2020-09-30 | 7.2 and 7.3 | All OCSP and CRL responses for Subordinate CA Certificates MUST include a meaningful reason code. | -| 2021-07-01 | 3.2.2.8 | CAA checking is no longer optional if the CA is the DNS Operator or an Affiliate. | -| 2021-07-01 | 3.2.2.4.18 and 3.2.2.4.19 | Redirects MUST be the result of one of the HTTP status code responses defined. | -| 2021-10-01 | 7.1.4.2.1 | Fully-Qualified Domain Names MUST consist solely of P-Labels and Non-Reserved LDH Labels. | -| 2021-12-01 | 3.2.2.4 | CAs MUST NOT use methods 3.2.2.4.6, 3.2.2.4.18, or 3.2.2.4.19 to issue wildcard certificates or with Authorization Domain Names other than the FQDN. | -| 2022-06-01 | 7.1.3.2.1 | CAs MUST NOT sign OCSP responses using the SHA-1 hash algorithm. | -| 2022-09-01 | 7.1.4.2.2 | CAs MUST NOT include the organizationalUnitName field in the Subject | -| 2023-01-15 | 7.2.2 | Sharded or partitioned CRLs MUST have a distributionPoint | -| 2023-07-15 | 4.9.1.1 and 7.2.2 | New CRL entries MUST have a revocation reason code | -| 2023-09-15 | Section 7 (and others) | CAs MUST use the updated Certificate Profiles passed in Version 2.0.0 | -| 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | +| **Compliance** | **Section(s)** | **Summary Description (See Full Text for Details)** | +|----------------|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 2013-01-01 | 6.1.6 | For RSA public keys, CAs SHALL confirm that the value of the public exponent is an odd number equal to 3 or more. | +| 2013-01-01 | 4.9.10 | CAs SHALL support an OCSP capability using the GET method. | +| 2013-01-01 | 5 | CAs SHALL comply with the Network and Certificate System Security Requirements. | +| 2013-08-01 | 4.9.10 | OCSP Responders SHALL NOT respond "Good" for Unissued Certificates. | +| 2013-09-01 | 3.2.2.6 | CAs SHALL revoke any certificate where wildcard character occurs in the first label position immediately to the left of a "registry-controlled" label or "public suffix". | +| 2013-12-31 | 6.1.5 | CAs SHALL confirm that the RSA Public Key is at least 2048 bits or that one of the following ECC curves is used: P-256, P-384, or P-521. A Root CA Certificate issued prior to 31 Dec. 2010 with an RSA key size less than 2048 bits MAY still serve as a trust anchor. | +| 2015-01-16 | 7.1.3 | CAs SHOULD NOT issue Subscriber Certificates utilizing the SHA-1 algorithm with an Expiry Date greater than 1 January 2017. | +| 2015-04-01 | 6.3.2 | CAs SHALL NOT issue certificates with validity periods longer than 39 months, except under certain circumstances. | +| 2015-04-15 | 2.2 | A CA's CPS must state whether it reviews CAA Records, and if so, its policy or practice on processing CAA records for Fully-Qualified Domain Names. | +| 2015-11-01 | 7.1.4.2.1 | Issuance of Certificates with Reserved IP Address or Internal Name prohibited. | +| 2016-01-01 | 7.1.3 | CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA-1 hash algorithm. | +| 2016-06-30 | 6.1.7 | CAs MUST NOT issue Subscriber Certificates directly from Root CAs. | +| 2016-06-30 | 6.3.2 | CAs MUST NOT issue Subscriber Certificates with validity periods longer than 39 months, regardless of circumstance. | +| 2016‐09‐30 | 7.1 | CAs SHALL generate Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG | +| 2016-10-01 | 7.1.4.2.1 | All Certificates with Reserved IP Address or Internal Name must be revoked. | +| 2016-12-03 | 1 and 2 | Ballot 156 amendments to sections 1.5.2, 2.3, and 2.4 are applicable | +| 2017-01-01 | 7.1.3 | CAs MUST NOT issue OCSP responder certificates using SHA-1 (inferred). | +| 2017-03-01 | 3.2.2.4 | CAs MUST follow revised validation requirements in Section 3.2.2.4. | +| 2017-09-08 | 3.2.2.8 | CAs MUST check and process CAA records | +| 2018-03-01 | 4.2.1 and 6.3.2 | Certificates issued MUST have a Validity Period no greater than 825 days and re-use of validation information limited to 825 days | +| 2018-05-31 | 2.2 | CP and CPS must follow RFC 3647 format | +| 2018-08-01 | 3.2.2.4.1 and .5 | CAs must stop using domain validation methods BR 3.2.2.4.1 and 3.2.2.4.5, stop reusing validation data from those methods | +| 2019-01-15 | 7.1.4.2.1 | All certificates containing an underscore character in any dNSName entry and having a validity period of more than 30 days MUST be revoked prior to January 15, 2019 | +| 2019-05-01 | 7.1.4.2.1 | underscore characters (“_”) MUST NOT be present in dNSName entries | +| 2019-06-01 | 3.2.2.4.3 | CAs SHALL NOT perform validations using this method after May 31, 2019. Completed validations using this method SHALL continue to be valid for subsequent issuance per the applicable certificate data reuse periods. | +| 2019-08-01 | 3.2.2.5 | CAs SHALL maintain a record of which IP validation method, including the relevant BR version number, was used to validate every IP Address | +| 2019-08-01 | 3.2.2.5.4 | CAs SHALL NOT perform validations using this method after July 31, 2019. Completed validations using this method SHALL NOT be re-used for certificate issuance after July 31, 2019. Any certificate issued prior to August 1, 2019 containing an IP Address that was validated using any method that was permitted under the prior version of this Section 3.2.2.5 MAY continue to be used without revalidation until such certificate naturally expires | +| 2020-06-03 | 3.2.2.4.6 | CAs MUST NOT perform validation using this method after 3 months from the IPR review date of Ballot SC25 | +| 2020-08-01 | 8.6 | Audit Reports for periods on-or-after 2020-08-01 MUST be structured as defined. | +| 2020-09-01 | 6.3.2 | Certificates issued SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. | +| 2020-09-30 | 4.9.10 | OCSP responses MUST conform to the validity period requirements specified. | +| 2020-09-30 | 7.1.4.1 | Subject and Issuer Names for all possible certification paths MUST be byte-for-byte identical. | +| 2020-09-30 | 7.1.6.4 | Subscriber Certificates MUST include a CA/Browser Forum Reserved Policy Identifier in the Certificate Policies extension. | +| 2020-09-30 | 7.2 and 7.3 | All OCSP and CRL responses for Subordinate CA Certificates MUST include a meaningful reason code. | +| 2021-07-01 | 3.2.2.8 | CAA checking is no longer optional if the CA is the DNS Operator or an Affiliate. | +| 2021-07-01 | 3.2.2.4.18 and 3.2.2.4.19 | Redirects MUST be the result of one of the HTTP status code responses defined. | +| 2021-10-01 | 7.1.4.2.1 | Fully-Qualified Domain Names MUST consist solely of P-Labels and Non-Reserved LDH Labels. | +| 2021-12-01 | 3.2.2.4 | CAs MUST NOT use methods 3.2.2.4.6, 3.2.2.4.18, or 3.2.2.4.19 to issue wildcard certificates or with Authorization Domain Names other than the FQDN. | +| 2022-06-01 | 7.1.3.2.1 | CAs MUST NOT sign OCSP responses using the SHA-1 hash algorithm. | +| 2022-09-01 | 7.1.4.2.2 | CAs MUST NOT include the organizationalUnitName field in the Subject | +| 2023-01-15 | 7.2.2 | Sharded or partitioned CRLs MUST have a distributionPoint | +| 2023-07-15 | 4.9.1.1 and 7.2.2 | New CRL entries MUST have a revocation reason code | +| 2023-09-15 | Section 7 (and others) | CAs MUST use the updated Certificate Profiles passed in Version 2.0.0 | +| 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | +| 2024-09-15 | 4.3.1.2 | The CA SHOULD implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | +| 2025-03-15 | 4.3.1.2 | The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. | +| 2025-03-15 | 8.7 | The CA SHOULD use a Linting process to test the technical accuracy of already issued Certificates against the sample set chosen for Self-Audits. | ## 1.3 PKI Participants @@ -382,6 +387,8 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Legal Entity**: An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a country's legal system. +**Linting**: A process in which the content of digitally signed data such as a Precertificate [RFC 6962], Certificate, Certificate Revocation List, or OCSP response, or data-to-be-signed object such as a `tbsCertificate` (as described in [RFC 5280, Section 4.1.1.1](https://tools.ietf.org/doc/html/rfc5280##section-4.1.1.1)) is checked for conformance with the profiles and requirements defined in these Requirements. + **Non-Reserved LDH Label**: From RFC 5890 (): "The set of valid LDH labels that do not have '`--`' in the third and fourth positions." **Object Identifier**: A unique alphanumeric or numeric identifier registered under the International Organization for Standardization's applicable standard for a specific object or object class. @@ -1099,8 +1106,35 @@ No stipulation. ### 4.3.1 CA actions during certificate issuance +#### 4.3.1.1 Manual authorization of certificate issuance for Root CAs + 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. +#### 4.3.1.2 Linting of to-be-signed Certificate content + +Due to the complexity involved in implementing Certificate Profiles that conform to these Requirements, it is considered best practice for the CA to implement a Linting process to test the technical conformity of each to-be-signed artifact prior to signing it. When a Precertificate has undergone Linting, it is not necessary for the corresponding to-be-signed Certificate to also undergo Linting, provided that the CA has a technical control to verify that the to-be-signed Certificate corresponds to the to-be-signed Precertificate in the manner described by RFC 6962, Section 3.2. +Effective 2024-09-15, the CA SHOULD implement such a Linting process. +Effective 2025-03-15, the CA SHALL implement such a Linting process. + +Methods used to produce a certificate containing the to-be-signed Certificate content include, but are not limited to: + +1. Sign the `tbsCertificate` with a "dummy" Private Key whose Public Key component is not certified by a Certificate that chains to a publicly-trusted CA Certificate; or +2. Specify a static value for the `signature` field of the Certificate ASN.1 SEQUENCE. + +CAs MAY implement their own certificate Linting tools, but CAs SHOULD use the Linting tools that have been widely adopted by the industry (see https://cabforum.org/resources/tools/). + +CAs are encouraged to contribute to open-source Linting projects, such as by: + +- creating new or improving existing lints, +- reporting potentially inaccurate linting results as bugs, +- notifying maintainers of Linting software of checks that are not covered by existing lints, +- updating documentation of existing lints, and +- generating test certificates for positive/negative tests of specific lints. + +#### 4.3.1.3 Linting of issued Certificates + +CAs MAY use a Linting process to test each issued Certificate. + ### 4.3.2 Notification to subscriber by the CA of issuance of certificate No stipulation. @@ -1232,7 +1266,7 @@ With the exception of Short-lived Subscriber Certificates, the CA SHALL revoke a 1. The Subscriber requests in writing, without specifying a CRLreason, that the CA revoke the Certificate (CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL); 2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization (CRLReason #9, privilegeWithdrawn); 3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise (CRLReason #1, keyCompromise); -4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate (such as a Debian weak key, see ) (CRLReason #1, keyCompromise); +4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate, including but not limited to those identified in [Section 6.1.1.3(5)](#6113-subscriber-key-pair-generation) (CRLReason #1, keyCompromise); 5. The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon (CRLReason #4, superseded). With the exception of Short-lived Subscriber Certificates, the CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs: @@ -1702,8 +1736,13 @@ The CA SHALL reject a certificate request if one or more of the following condit 1. The Key Pair does not meet the requirements set forth in [Section 6.1.5](#615-key-sizes) and/or [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking); 2. There is clear evidence that the specific method used to generate the Private Key was flawed; 3. The CA is aware of a demonstrated or proven method that exposes the Applicant's Private Key to compromise; -4. The CA has previously been made aware that the Applicant's Private Key has suffered a Key Compromise, such as through the provisions of [Section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate); -5. The CA is aware of a demonstrated or proven method to easily compute the Applicant's Private Key based on the Public Key (such as a Debian weak key, see ). +4. The CA has previously been notified that the Applicant's Private Key has suffered a Key Compromise using the CA's procedure for revocation request as described in [Section 4.9.3](#493-procedure-for-revocation-request) and [Section 4.9.12](#4912-special-requirements-re-key-compromise); +5. The Public Key corresponds to an industry-demonstrated weak Private Key. For requests submitted on or after November 15, 2024, at least the following precautions SHALL be implemented: + 1. In the case of Debian weak keys vulnerability (https://wiki.debian.org/SSLkeys), the CA SHALL reject all keys found at https://github.com/cabforum/Debian-weak-keys/ for each key type (e.g. RSA, ECDSA) and size listed in the repository. For all other keys meeting the requirements of [Section 6.1.5](#615-key-sizes), with the exception of RSA key sizes greater than 8192 bits, the CA SHALL reject Debian weak keys. + 2. In the case of ROCA vulnerability, the CA SHALL reject keys identified by the tools available at https://github.com/crocs-muni/roca or equivalent. + 3. In the case of Close Primes vulnerability (https://fermatattack.secvuln.info/), the CA SHALL reject weak keys which can be factored within 100 rounds using Fermat’s factorization method. + + Suggested tools for checking for weak keys can be found here: https://cabforum.org/resources/tools/ If the Subscriber Certificate will contain an `extKeyUsage` extension containing either the values `id-kp-serverAuth` [RFC5280] or `anyExtendedKeyUsage` [RFC5280], the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA. @@ -1809,6 +1848,10 @@ The CA SHALL enforce multi-factor authentication for all accounts capable of dir ### 6.6.1 System development controls +If a CA uses Linting software developed by third parties, it SHOULD monitor for updated versions of that software and plan for updates no later than three (3) months from the release of the update. + +The CA MAY perform Linting on the corpus of its unexpired, un-revoked Subscriber Certificates whenever it updates the Linting software. + ### 6.6.2 Security management controls ### 6.6.3 Life cycle security controls @@ -3387,7 +3430,11 @@ The Audit Report MUST be available as a PDF, and SHALL be text searchable for al ## 8.7 Self-Audits -During the period in which the CA issues Certificates, the CA SHALL monitor adherence to its Certificate Policy, Certification Practice Statement and these Requirements and strictly control its service quality by performing self audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken. Except for Delegated Third Parties that undergo an annual audit that meets the criteria specified in [Section 8.4](#84-topics-covered-by-assessment), the CA SHALL strictly control the service quality of Certificates issued or containing information verified by a Delegated Third Party by having a Validation Specialist employed by the CA perform ongoing quarterly audits against a randomly selected sample of at least the greater of one certificate or three percent of the Certificates verified by the Delegated Third Party in the period beginning immediately after the last sample was taken. The CA SHALL review each Delegated Third Party's practices and procedures to ensure that the Delegated Third Party is in compliance with these Requirements and the relevant Certificate Policy and/or Certification Practice Statement. +During the period in which the CA issues Certificates, the CA SHALL monitor adherence to its Certificate Policy, Certification Practice Statement and these Requirements and strictly control its service quality by performing self audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken. + +Effective 2025-03-15, the CA SHOULD use a Linting process to verify the technical accuracy of Certificates within the selected sample set independently of previous linting performed on the same Certificates. + +Except for Delegated Third Parties that undergo an annual audit that meets the criteria specified in [Section 8.4](#84-topics-covered-by-assessment), the CA SHALL strictly control the service quality of Certificates issued or containing information verified by a Delegated Third Party by having a Validation Specialist employed by the CA perform ongoing quarterly audits against a randomly selected sample of at least the greater of one certificate or three percent of the Certificates verified by the Delegated Third Party in the period beginning immediately after the last sample was taken. The CA SHALL review each Delegated Third Party's practices and procedures to ensure that the Delegated Third Party is in compliance with these Requirements and the relevant Certificate Policy and/or Certification Practice Statement. The CA SHALL internally audit each Delegated Third Party's compliance with these Requirements on an annual basis. From a75d51c0193566ed151efb6ad085ee16ec9e0117 Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Mon, 14 Oct 2024 14:24:01 -0400 Subject: [PATCH 10/12] Add Defined Term and future effective date --- docs/EVG.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 378d6a23b..0e6e5ecf0 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -164,6 +164,8 @@ 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 @@ -218,6 +220,7 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **International Organization**: An organization founded by a constituent document, e.g., a charter, treaty, convention or similar document, signed by, or on behalf of, a minimum of two Sovereign State governments. + **Jurisdiction of Incorporation**: In the context of a Private Organization, the country and (where applicable) the state or province or locality where the organization's legal existence was established by a filing with (or an act of) an appropriate government agency or entity (e.g., where it was incorporated). In the context of a Government Entity, the country and (where applicable) the state or province where the Entity's legal existence was created by law. **Jurisdiction of Registration**: In the case of a Business Entity, the state, province, or locality where the organization has registered its business presence by means of filings by a Principal Individual involved in the business. @@ -1368,13 +1371,13 @@ Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, t __Certificate Field__: `subject:serialNumber` (OID: 2.5.4.5) __Required/Optional__: __Required__ -__Contents__: For Private Organizations, 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. +__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 2025-06-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 no verifiable Date of Formation could be obtained for the Applicant, then the CA SHALL include appropriate language to indicate that the Subject is a Government Entity (e.g., the string "Government Entity", the name or identifier of the legislative act that created the Government Entity, etc.). +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 no verifiable Date of Formation could be obtained for the Applicant, then the CA SHALL include appropriate language to indicate that the Subject is a Government Entity (e.g., the string "Government Entity", the name or identifier of the legislative act that created the Government Entity, etc.). Effective 2025-06-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. +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 2025-06-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 no verifiable Date of Formation could be obtained for the Applicant, then the CA SHALL include appropriate language to indicate that the Subject is a Non-Commercial Entity (e.g., the string "Non-Commercial Entity", the name or identifier of the legislative act that created the Non-Commercial Entity, etc.). +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 no verifiable Date of Formation could be obtained for the Applicant, then the CA SHALL include appropriate language to indicate that the Subject is a Non-Commercial Entity (e.g., the string "Non-Commercial Entity", the name or identifier of the legislative act that created the Non-Commercial Entity, etc.). Effective 2025-06-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. From c660ef625de251a9bbb8603e961c4ba04576290f Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Mon, 28 Apr 2025 08:29:48 -0400 Subject: [PATCH 11/12] Update Ubuntu runner version --- .github/workflows/build-draft-docs.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/build-draft-docs.yml b/.github/workflows/build-draft-docs.yml index a8af8a55c..cefeeaf77 100644 --- a/.github/workflows/build-draft-docs.yml +++ b/.github/workflows/build-draft-docs.yml @@ -9,7 +9,7 @@ jobs: - 'EVG' - 'NSR' name: Build ${{ matrix.document }} - runs-on: ubuntu-20.04 + runs-on: ubuntu-latest steps: - name: Checkout the code uses: actions/checkout@v3 From 4a6da0eaa3bad93d55d2d463743c4bac2b3b336a Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Tue, 29 Apr 2025 08:33:47 -0400 Subject: [PATCH 12/12] Move effective date back --- docs/EVG.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/docs/EVG.md b/docs/EVG.md index 0e6e5ecf0..167b7a44e 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -92,6 +92,7 @@ These Guidelines do not address the verification of information, or the issuance | 2020-09-01 | [9.4] & Appendix F | Certificates issued MUST NOT have a Validity Period greater than 398 days. | | 2020-10-01 | [11.1.3] | Prior to using an Incorporating Agency or Registration Agency, the CA MUST ensure the agency has been publicly disclosed | | 2022-09-01 | [9.2.7] | CAs MUST NOT include the organizationalUnitName field in the Subject | +| 2026-06-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 20 November 2010 and supplemented through May 2012 when version 1.4 was published. ETSI TS 102 042 and ETSI TR 101 564 Technical Report: Guidance on ETSI TS 102 042 for Issuing Extended Validation Certificates for Auditors and CSPs reference version 1.3 of these EV Guidelines, and ETSI Draft EN 319 411-1 references version 1.4. Version 1.4.5 of Webtrust(r) for Certification Authorities – Extended Validation Audit Criteria references version 1.4.5 of these EV Guidelines. As illustrated in the Document History table above, the CA/Browser Forum continues to improve relevant industry guidelines, including this document, the Baseline Requirements, and the Network and Certificate System Security Requirements. We encourage all CAs to conform to each revision on the date specified without awaiting a corresponding update to an applicable audit criterion. In the event of a conflict between an existing audit criterion and a guideline revision, we will communicate with the audit community and attempt to resolve any uncertainty. We will respond to implementation questions directed to questions@cabforum.org. Our coordination with compliance auditors will continue as we develop guideline revision cycles that harmonize with the revision cycles for audit criteria, the compliance auditing periods and cycles of CAs, and the CA/Browser Forum's guideline implementation dates. @@ -1371,13 +1372,13 @@ Effective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, t __Certificate Field__: `subject:serialNumber` (OID: 2.5.4.5) __Required/Optional__: __Required__ -__Contents__: For Private Organizations, 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 2025-06-15, if the CA includes the Date of Formation, then the CA MUST use the Canonical Date Representation. +__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 2026-06-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 no verifiable Date of Formation could be obtained for the Applicant, then the CA SHALL include appropriate language to indicate that the Subject is a Government Entity (e.g., the string "Government Entity", the name or identifier of the legislative act that created the Government Entity, etc.). Effective 2025-06-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 no verifiable Date of Formation could be obtained for the Applicant, then the CA SHALL include appropriate language to indicate that the Subject is a Government Entity (e.g., the string "Government Entity", the name or identifier of the legislative act that created the Government Entity, etc.). Effective 2026-06-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 2025-06-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 2026-06-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 no verifiable Date of Formation could be obtained for the Applicant, then the CA SHALL include appropriate language to indicate that the Subject is a Non-Commercial Entity (e.g., the string "Non-Commercial Entity", the name or identifier of the legislative act that created the Non-Commercial Entity, etc.). Effective 2025-06-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 no verifiable Date of Formation could be obtained for the Applicant, then the CA SHALL include appropriate language to indicate that the Subject is a Non-Commercial Entity (e.g., the string "Non-Commercial Entity", the name or identifier of the legislative act that created the Non-Commercial Entity, etc.). Effective 2026-06-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.