From 3e19d5ca15e506856094ac531a66f1668e7bcc15 Mon Sep 17 00:00:00 2001 From: bcmorton Date: Thu, 19 Dec 2024 10:34:57 -0500 Subject: [PATCH 01/12] sc-069 alignment --- docs/CSBR.md | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/docs/CSBR.md b/docs/CSBR.md index 09f1a16..145b39e 100644 --- a/docs/CSBR.md +++ b/docs/CSBR.md @@ -1699,13 +1699,13 @@ The CA SHALL record at least the following events: 2. PKI and security system actions performed; 3. Security profile changes; 4. System crashes, hardware failures, and other anomalies; - 5. Firewall and router activities; and + 5. Relevant router and firewall activities (as described in [Section 5.4.1.3](#5413-router-and-firewall-activities-logs)); and 6. Entries to and exits from the CA facility. -Log records MUST include the following elements: +Log records MUST include the at least following elements: 1. Date and time of event; -2. Identity of the person making the journal record; and +2. Identity of the person making the journal record (when applicable); and 3. Description of the event. #### 5.4.1.2 Types of events recorded for Timestamp Authorities @@ -1720,11 +1720,20 @@ The Timestamp Authority MUST log the following information and make these record 2. Timestamp Authority server actions performed; 3. Security profile changes; 4. System crashes and other anomalies; and - 5. Firewall and router activities; + 5. Firewall and router activities(as described in [Section 5.4.1.3](#5413-router-and-firewall-activities-logs)); 5. Revocation of a timestamp certificate, 6. Major changes to the timestamp server's time, and 7. System startup and shutdown. +#### 5.4.1.3 Router and firewall activities logs + +Logging of router and firewall activities necessary to meet the requirements of Section 5.4.1.1, Subsection 3.6 and Section 5.4.1.2, Subsection 4.5 MUST at a minimum include: + + 1. Successful and unsuccessful login attempts to routers and firewalls; and + 2. Logging of all administrative actions performed on routers and firewalls, including configuration changes, firmware updates, and access control modifications; and + 3. Logging of all changes made to firewall rules, including additions, modifications, and deletions; and + 4. Logging of all system events and errors, including hardware failures, software crashes, and system restarts. + ### 5.4.2 Frequency of processing log ### 5.4.3 Retention period for audit log From 0930e4406c2b69f7d3c43a33c246bd6056717842 Mon Sep 17 00:00:00 2001 From: bcmorton Date: Thu, 19 Dec 2024 10:54:05 -0500 Subject: [PATCH 02/12] sc-073 alignment --- docs/CSBR.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/docs/CSBR.md b/docs/CSBR.md index 145b39e..3cf847e 100644 --- a/docs/CSBR.md +++ b/docs/CSBR.md @@ -1377,7 +1377,7 @@ The CA SHALL revoke a Certificate within 24 hours if one or more of the followin 1. The Subscriber requests in writing that the CA revoke the Certificate; 2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization; 3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise; -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; +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); 5. The CA is made aware of a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed; or 6. The CA has reasonable assurance that a Certificate was used to sign Suspect Code. @@ -1879,8 +1879,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 June 15 2025, 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/ ### 6.1.2 Private key delivery to subscriber From 1e3119590a4446b465497a42378767cae27c9dcd Mon Sep 17 00:00:00 2001 From: bcmorton Date: Thu, 19 Dec 2024 11:33:43 -0500 Subject: [PATCH 03/12] sc-075 alignment --- docs/CSBR.md | 38 +++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git a/docs/CSBR.md b/docs/CSBR.md index 3cf847e..b7d90d7 100644 --- a/docs/CSBR.md +++ b/docs/CSBR.md @@ -315,6 +315,8 @@ Capitalized Terms are as defined below and in the EV SSL Guidelines: **Lifetime Signing OID:** An optional extended key usage OID (`1.3.6.1.4.1.311.10.3.13`) used by Microsoft Authenticode to limit the lifetime of the code signature to the expiration of the code signing certificate. +**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-EV Code Signing Certificate:** Term used to signify requirements that are applicable to Code Signing Certificates which do not have to meet the EV requirements. **Notary**: A person whose commission under applicable law includes authority to authenticate the execution of a signature on a document. @@ -1242,8 +1244,34 @@ 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 MUST 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 2025-06-15, the CA SHOULD 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. @@ -2071,6 +2099,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 @@ -2608,7 +2640,11 @@ The Audit Report MUST be available as a PDF, and SHALL be text searchable for al ## 8.7 Self-audits -CAs must abide by the self-audit requirements of these Guidelines. During the period in which it issues Code Signing 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 Non-EV Code Signing Certificates and at least three percent of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken. For all Code Signing Certificates where the final cross-correlation and due diligence requirements of Section 8 of these Guidelines 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 Non-EV Code Signing Certificates and at least six percent of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken. +During the period in which the CA issues Certificates, the CA SHALL monitor adherence to its Certificate Policy, Certification Practice Statement and these Requirements and strictly control its service quality by performing self audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or at least six percent of the Non-EV Code Signing Certificates and at least six percent of the EV Code Signing Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken. + +Effective 2025-06-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 six percent of the Non-EV Code Signing Certificates and at least six percent of the EV Code Signing 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. # 9. OTHER BUSINESS AND LEGAL MATTERS From ed6e21c6e042549ae6351f563c0cfef43ba8b138 Mon Sep 17 00:00:00 2001 From: bcmorton Date: Thu, 19 Dec 2024 11:54:12 -0500 Subject: [PATCH 04/12] sc-076 alignment --- docs/CSBR.md | 37 ++++++++++++++----------------------- 1 file changed, 14 insertions(+), 23 deletions(-) diff --git a/docs/CSBR.md b/docs/CSBR.md index b7d90d7..c50789b 100644 --- a/docs/CSBR.md +++ b/docs/CSBR.md @@ -1493,40 +1493,31 @@ No stipulation. ### 4.9.9 On-line revocation/status checking availability -OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST either: +The validity interval of an OCSP response is the difference in time between the `thisUpdate` and `nextUpdate` field, inclusive. For purposes of computing differences, a difference of 3,600 seconds shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day, ignoring leap-seconds. -1. Be signed by the CA that issued the Certificates whose revocation status is being checked, or -2. Be signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose - revocation status is being checked. +A certificate serial is "assigned" if: -In the latter case, the OCSP signing Certificate MUST contain an extension of type `id-pkix-ocsp-nocheck`, as -defined by RFC6960. +- a Certificate with that serial number has been issued by the Issuing CA. -### 4.9.10 On-line revocation checking requirements - -Effective 2023-09-15, OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019. - -Effective 2023-09-15, the validity interval of an OCSP response is the difference in time between the `thisUpdate` and `nextUpdate` field, inclusive. For purposes of computing differences, a difference of 3,600 seconds shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day, ignoring leap-seconds. - -CAs MAY provide OCSP responses for Code Signing Certificates and Timestamp Certificates for the time period specified in their CPS, which MAY be at least 10 years after the expiration of the certificate. +A certificate serial is "unassigned" if it is not "assigned". -If the CA provides OCSP responses, the CA SHALL support an OCSP capability using the GET method for Certificates issued in accordance with these Requirements. +The following SHALL apply for communicating the status of Certificates which include an Authority Information Access extension with an id-ad-ocsp accessMethod. -For the status of Subordinate CA Certificates: +OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019. The CA MAY process the Nonce extension (`1.3.6.1.5.5.7.48.1.2`) in accordance with RFC 8954. -* If the Issuing CA provides OCSP responses, the Issuing CA SHALL update information provided via an OCSP response at least every twelve months and within 24 hours after revoking a Subordinate CA Certificate. +For the status of a Code Signing Certificate: -For the status of Code Signing Certificates: - -* If the Subordinate CA provides OCSP responses, the CA SHALL update information provided via an OCSP response at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days. +- Effective 2025-06-15, an authoritative OCSP response MUST be available (i.e. the responder MUST NOT respond with the "unknown" status) starting no more than 15 minutes after the Certificate is first published or otherwise made available. +- For OCSP responses with validity intervals less than sixteen hours, the CA SHALL provide an updated OCSP response prior to one-half of the validity period before the nextUpdate. +- For OCSP responses with validity intervals greater than or equal to sixteen hours, the CA SHALL provide an updated OCSP response at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate. -For the status of Timestamp Certificates: +For the status of a Subordinate CA Certificate, the CA SHALL provide an updated OCSP response at least every twelve months, and within 24 hours after revoking the Certificate. -* If the Subordinate CA provides OCSP responses, the Subordinate CA SHALL update information provided via an OCSP response at least every twelve months and within 24 hours after revoking a Timestamp Certificate. +For the status of a Timestamp Certificate, the CA SHALL provide an updated OCSP response at least every twelve months, and within 24 hours after revoking the Certificate. -A certificate serial number within an OCSP request is "assigned" if a Certificate with that serial number has been issued by the Issuing CA, using any current or previous key associated with that CA subject. +### 4.9.10 On-line revocation checking requirements -If the OCSP responder receives a request for the status of a certificate serial number that is not "assigned", then the responder MUST NOT respond with a "good" status. +No Stipulation. ### 4.9.11 Other forms of revocation advertisements available From ea750419851f25e1cf7284b263c4675dfc374ac9 Mon Sep 17 00:00:00 2001 From: bcmorton Date: Thu, 19 Dec 2024 12:12:47 -0500 Subject: [PATCH 05/12] sc-078 alignment --- docs/CSBR.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/CSBR.md b/docs/CSBR.md index c50789b..18c0fff 100644 --- a/docs/CSBR.md +++ b/docs/CSBR.md @@ -2381,7 +2381,9 @@ d. __Certificate Field:__ Other subject attributes a. __Certificate Field:__ `subject:organizationName` (OID 2.5.4.10) __Required/Optional:__ Required - __Contents:__ The `subject:organizationName` field MUST contain either the Subject's name or DBA as verified under BR Section 3.2. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". Because subject name attributes for individuals (e.g. `subject:givenName` (2.5.4.42) and `subject:surname` (2.5.4.4)) are not broadly supported by application software, the CA MAY use the `subject:organizationName` field to convey a natural person Subject's name or DBA. The CA MUST have a documented process for verifying that the information included in the `subject:organizationName` field is not misleading to a Relying Party. + __Contents:__ The `subject:organizationName` field MUST contain either the Subject's name and/or DBA/tradename as verified under Section 3.2. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". If both are included, the DBA/tradename SHALL appear first, followed by the Subject's name in parentheses. + + Because subject name attributes for individuals (e.g. `subject:givenName` (2.5.4.42) and `subject:surname` (2.5.4.4)) are not broadly supported by application software, the CA MAY use the `subject:organizationName` field to convey a natural person Subject's name or DBA. The CA MUST have a documented process for verifying that the information included in the `subject:organizationName` field is not misleading to a Relying Party. b. __Certificate Field:__ `subject:streetAddress` (OID: 2.5.4.9) __Required/Optional:__ Optional From ef342e1a97e16f68fc23b44a43c87400dfd0a415 Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Thu, 23 Jan 2025 16:04:25 -0500 Subject: [PATCH 06/12] Remove precerts --- docs/CSBR.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/CSBR.md b/docs/CSBR.md index 18c0fff..bb29d3e 100644 --- a/docs/CSBR.md +++ b/docs/CSBR.md @@ -315,7 +315,7 @@ Capitalized Terms are as defined below and in the EV SSL Guidelines: **Lifetime Signing OID:** An optional extended key usage OID (`1.3.6.1.4.1.311.10.3.13`) used by Microsoft Authenticode to limit the lifetime of the code signature to the expiration of the code signing certificate. -**Linting**: A process in which the content of digitally signed data such as a Precertificate [RFC 6962], Certificate, Certificate Revocation List, or OCSP response, or data-to-be-signed object such as a `tbsCertificate` (as described in [RFC 5280, Section 4.1.1.1](https://tools.ietf.org/doc/html/rfc5280##section-4.1.1.1)) is checked for conformance with the profiles and requirements defined in these Requirements. +**Linting**: A process in which the content of digitally signed data such as a 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-EV Code Signing Certificate:** Term used to signify requirements that are applicable to Code Signing Certificates which do not have to meet the EV requirements. @@ -1250,8 +1250,7 @@ Certificate issuance by the Root CA MUST require an individual authorized by the #### 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 2025-06-15, the CA SHOULD implement such a Linting process. +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. Effective 2025-06-15, the CA SHOULD implement such a Linting process. Methods used to produce a certificate containing the to-be-signed Certificate content include, but are not limited to: From d6fe8b801ba3be9fc3cc7120b1f0910544abbc02 Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Thu, 23 Jan 2025 16:16:42 -0500 Subject: [PATCH 07/12] Attempt to improve readability --- docs/CSBR.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/docs/CSBR.md b/docs/CSBR.md index bb29d3e..f80d290 100644 --- a/docs/CSBR.md +++ b/docs/CSBR.md @@ -1500,19 +1500,17 @@ A certificate serial is "assigned" if: A certificate serial is "unassigned" if it is not "assigned". -The following SHALL apply for communicating the status of Certificates which include an Authority Information Access extension with an id-ad-ocsp accessMethod. - OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019. The CA MAY process the Nonce extension (`1.3.6.1.5.5.7.48.1.2`) in accordance with RFC 8954. -For the status of a Code Signing Certificate: +For the status of a Code Signing Certificate which includes an Authority Information Access extension with an id-ad-ocsp accessMethod: - Effective 2025-06-15, an authoritative OCSP response MUST be available (i.e. the responder MUST NOT respond with the "unknown" status) starting no more than 15 minutes after the Certificate is first published or otherwise made available. - For OCSP responses with validity intervals less than sixteen hours, the CA SHALL provide an updated OCSP response prior to one-half of the validity period before the nextUpdate. - For OCSP responses with validity intervals greater than or equal to sixteen hours, the CA SHALL provide an updated OCSP response at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate. -For the status of a Subordinate CA Certificate, the CA SHALL provide an updated OCSP response at least every twelve months, and within 24 hours after revoking the Certificate. +For the status of a Subordinate CA Certificate which includes an Authority Information Access extension with an id-ad-ocsp accessMethod, the CA SHALL provide an updated OCSP response at least every twelve months, and within 24 hours after revoking the Certificate. -For the status of a Timestamp Certificate, the CA SHALL provide an updated OCSP response at least every twelve months, and within 24 hours after revoking the Certificate. +For the status of a Timestamp Certificate which includes an Authority Information Access extension with an id-ad-ocsp accessMethod, the CA SHALL provide an updated OCSP response at least every twelve months, and within 24 hours after revoking the Certificate. ### 4.9.10 On-line revocation checking requirements From 6aafad7726aa9bca96fa449652870f761f1ad9d0 Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Wed, 5 Mar 2025 13:47:16 -0500 Subject: [PATCH 08/12] Restore original CSBR requirements on sample size --- docs/CSBR.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/docs/CSBR.md b/docs/CSBR.md index f80d290..6a92856 100644 --- a/docs/CSBR.md +++ b/docs/CSBR.md @@ -2630,12 +2630,10 @@ 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 six percent of the Non-EV Code Signing Certificates and at least six percent of the EV Code Signing Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken. +CAs must abide by the self-audit requirements of these Guidelines. During the period in which it issues Code Signing 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 Non-EV Code Signing Certificates and at least three percent of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken. For all Code Signing Certificates where the final cross-correlation and due diligence requirements of Section 8 of these Guidelines 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 Non-EV Code Signing Certificates and at least six percent of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken. Effective 2025-06-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 six percent of the Non-EV Code Signing Certificates and at least six percent of the EV Code Signing 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. - # 9. OTHER BUSINESS AND LEGAL MATTERS ## 9.1 Fees From 8d0ff82b7d5940347789d40b30190723e04be028 Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Wed, 5 Mar 2025 13:48:16 -0500 Subject: [PATCH 09/12] Use numbers too --- docs/CSBR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/CSBR.md b/docs/CSBR.md index 6a92856..2bcfbd5 100644 --- a/docs/CSBR.md +++ b/docs/CSBR.md @@ -2630,7 +2630,7 @@ The Audit Report MUST be available as a PDF, and SHALL be text searchable for al ## 8.7 Self-audits -CAs must abide by the self-audit requirements of these Guidelines. During the period in which it issues Code Signing 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 Non-EV Code Signing Certificates and at least three percent of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken. For all Code Signing Certificates where the final cross-correlation and due diligence requirements of Section 8 of these Guidelines 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 Non-EV Code Signing Certificates and at least six percent of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken. +CAs must abide by the self-audit requirements of these Guidelines. During the period in which it issues Code Signing Certificates, the CA MUST strictly control its service quality by performing ongoing self-audits against a randomly selected sample of at least three percent (3%) of the Non-EV Code Signing Certificates and at least three percent (3%) of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken. For all Code Signing Certificates where the final cross-correlation and due diligence requirements of Section 8 of these Guidelines 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 (6%) of the Non-EV Code Signing Certificates and at least six percent (6%) of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken. Effective 2025-06-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. From dcf7b90a557cd7f6c92199ebe77b6ba1363b5440 Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Thu, 17 Apr 2025 21:08:23 -0400 Subject: [PATCH 10/12] Push back effective dates --- docs/CSBR.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/CSBR.md b/docs/CSBR.md index 2bcfbd5..6c74b23 100644 --- a/docs/CSBR.md +++ b/docs/CSBR.md @@ -1250,7 +1250,7 @@ Certificate issuance by the Root CA MUST require an individual authorized by the #### 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. Effective 2025-06-15, the CA SHOULD implement such a Linting process. +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. Effective 2025-09-15, the CA SHOULD implement such a Linting process. Methods used to produce a certificate containing the to-be-signed Certificate content include, but are not limited to: @@ -1504,7 +1504,7 @@ OCSP responders operated by the CA SHALL support the HTTP GET method, as describ For the status of a Code Signing Certificate which includes an Authority Information Access extension with an id-ad-ocsp accessMethod: -- Effective 2025-06-15, an authoritative OCSP response MUST be available (i.e. the responder MUST NOT respond with the "unknown" status) starting no more than 15 minutes after the Certificate is first published or otherwise made available. +- Effective 2025-09-15, an authoritative OCSP response MUST be available (i.e. the responder MUST NOT respond with the "unknown" status) starting no more than 15 minutes after the Certificate is first published or otherwise made available. - For OCSP responses with validity intervals less than sixteen hours, the CA SHALL provide an updated OCSP response prior to one-half of the validity period before the nextUpdate. - For OCSP responses with validity intervals greater than or equal to sixteen hours, the CA SHALL provide an updated OCSP response at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate. @@ -2632,7 +2632,7 @@ The Audit Report MUST be available as a PDF, and SHALL be text searchable for al CAs must abide by the self-audit requirements of these Guidelines. During the period in which it issues Code Signing Certificates, the CA MUST strictly control its service quality by performing ongoing self-audits against a randomly selected sample of at least three percent (3%) of the Non-EV Code Signing Certificates and at least three percent (3%) of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken. For all Code Signing Certificates where the final cross-correlation and due diligence requirements of Section 8 of these Guidelines 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 (6%) of the Non-EV Code Signing Certificates and at least six percent (6%) of the EV Code Signing Certificates it has issued in the period beginning immediately after the last sample was taken. -Effective 2025-06-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. +Effective 2025-09-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. # 9. OTHER BUSINESS AND LEGAL MATTERS From e54b3ab3938af6ae98312675672f83a5677d1906 Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Thu, 17 Apr 2025 21:09:10 -0400 Subject: [PATCH 11/12] Fix link --- docs/CSBR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/CSBR.md b/docs/CSBR.md index 6c74b23..cd6a613 100644 --- a/docs/CSBR.md +++ b/docs/CSBR.md @@ -1626,7 +1626,7 @@ The CA Private Key SHALL be backed up, stored, and recovered only by personnel i ### 5.2.4 Roles requiring separation of duties -1. The CA MUST enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the issuance of an EV Code Signing Certificate. The Final Cross-Correlation and Due Diligence steps, as outlined in [Section 3.2.9](#32229-verification-of-approval-of-ev-code-signing-certificate-request), 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 Code Signing 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 Code Signing Certificate. The Final Cross-Correlation and Due Diligence steps, as outlined in [Section 3.2.9](#329-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 Code Signing Certificate. 2. Such controls MUST be auditable. ## 5.3 Personnel controls From d9f17523301486f983ddec8767d1f75ec776dd0d Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Thu, 17 Apr 2025 21:10:12 -0400 Subject: [PATCH 12/12] Bump ubuntu --- .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 edb1178..35d8ad4 100644 --- a/.github/workflows/build-draft-docs.yml +++ b/.github/workflows/build-draft-docs.yml @@ -7,7 +7,7 @@ jobs: document: - 'CSBR.md' name: Build ${{ matrix.document }} - runs-on: ubuntu-20.04 + runs-on: ubuntu-latest steps: - name: Checkout the code uses: actions/checkout@v4