From d5b258ac45419cf861dbf486d62dd8463ef2fb89 Mon Sep 17 00:00:00 2001 From: Aaron Gable Date: Tue, 7 May 2024 15:12:12 -0700 Subject: [PATCH] Update CP/CPS to exactly match RFC 3647, Section 6 (#216) Change the phrasing and capitalization of a few CP/CPS section headings to exactly match those suggested by RFC 3647, Section 6. These section titles will be mandatory as of 2024-09-15, per CA/BF Ballot SC-074. Also add a new linting tool which enforces some of the requirements imposed by Ballot SC-074. And fix the old "Test Tools" job, which was broken because it only ran for PRs targeting "master". --- .github/workflows/lint.yml | 19 +++ .github/workflows/pr_tools.yml | 10 +- CP-CPS.md | 86 +++++------ tools/lint/README.md | 61 ++++++++ tools/lint/go.mod | 3 + tools/lint/main.go | 115 ++++++++++++++ tools/lint/outline.txt | 270 +++++++++++++++++++++++++++++++++ 7 files changed, 516 insertions(+), 48 deletions(-) create mode 100644 .github/workflows/lint.yml create mode 100644 tools/lint/README.md create mode 100644 tools/lint/go.mod create mode 100644 tools/lint/main.go create mode 100644 tools/lint/outline.txt diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml new file mode 100644 index 0000000..e15c79f --- /dev/null +++ b/.github/workflows/lint.yml @@ -0,0 +1,19 @@ +name: Lint CP/CPS + +on: + push: + branches: + - main + pull_request: + branches: + - '**' +jobs: + lint: + + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + - uses: actions/setup-go@v5 + - name: Run linter + working-directory: ./tools/lint + run: go run . ../../CP-CPS.md diff --git a/.github/workflows/pr_tools.yml b/.github/workflows/pr_tools.yml index 8a3d414..baa38d7 100644 --- a/.github/workflows/pr_tools.yml +++ b/.github/workflows/pr_tools.yml @@ -3,22 +3,22 @@ name: Test Tools on: push: branches: - - master + - main pull_request: branches: - - master + - '**' jobs: build: runs-on: ubuntu-latest strategy: matrix: - python-version: [3.6, 3.7, 3.8, 3.9] + python-version: [3.8, 3.12.3] steps: - - uses: actions/checkout@v2 + - uses: actions/checkout@v4 - name: Set up Python ${{ matrix.python-version }} - uses: actions/setup-python@v2 + uses: actions/setup-python@v5 with: python-version: ${{ matrix.python-version }} - name: Install dependencies diff --git a/CP-CPS.md b/CP-CPS.md index d5bbd20..1bc09d6 100644 --- a/CP-CPS.md +++ b/CP-CPS.md @@ -40,13 +40,13 @@ The following revisions have been made: | Feb 7, 2024 | Add CRL Distribution Point to subscriber certificate profile. Add IssuingDistributionPoint to subordinate CRL profile. Remove id-qt-cps from subscriber certificate profile, make it optional for subordinate certificate profile. Clarify waste disposal procedure. | 5.2 | | Mar 22, 2024 | Improve accuracy of information regarding subscriber key compromise in sections 4.9.3 and 4.9.12. | 5.3 | -## 1.3 PKI Participants +## 1.3 PKI participants -### 1.3.1 Certification Authorities +### 1.3.1 Certification authorities This CP/CPS applies to the ISRG CA. -### 1.3.2 Registration Authorities +### 1.3.2 Registration authorities ISRG does not delegate any of the Section 3.2 requirements to a Delegated Third Party. ISRG serves as its own RA. @@ -54,23 +54,23 @@ ISRG does not delegate any of the Section 3.2 requirements to a Delegated Third See definition of "Subscriber" in Section 1.6.1 Definitions. -### 1.3.4 Relying Parties +### 1.3.4 Relying parties See definition of "Relying Party" in Section 1.6.1 Definitions. -### 1.3.5 Other Participants +### 1.3.5 Other participants Other participants include CAs that cross-sign or issue subordinates to the ISRG PKI. ISRG PKI vendors and service providers with access to confidential information or privileged systems are required to operate in compliance with this ISRG CP/CPS. -## 1.4 Certificate Usage +## 1.4 Certificate usage -### 1.4.1 Appropriate Certificate Uses +### 1.4.1 Appropriate certificate uses No stipulation. -### 1.4.2 Prohibited Certificate Uses +### 1.4.2 Prohibited certificate uses Certificates may not be used: @@ -81,11 +81,11 @@ Note that Certificates do not guarantee anything regarding reputation, honesty, ## 1.5 Policy administration -### 1.5.1 Organization Administering the Document +### 1.5.1 Organization administering the document The ISRG PMA maintains this document. -### 1.5.2 Contact Person +### 1.5.2 Contact person The ISRG PMA can be contacted at: @@ -105,15 +105,15 @@ Issues can be filed via the GitHub repository where this document is maintained: -### 1.5.3 Person Determining CP/CPS suitability for the policy +### 1.5.3 Person determining CPS suitability for the policy The ISRG PMA is responsible for determining the suitability of this CP/CPS. ISRG policy is informed by results and recommendations received from an independent auditor. -### 1.5.4 CP/CPS approval procedures +### 1.5.4 CPS approval procedures The ISRG PMA approves any revisions to this CP/CPS after formal review. -## 1.6 Definitions and Acronyms +## 1.6 Definitions and acronyms ### 1.6.1 Definitions @@ -172,7 +172,7 @@ ISRG Combined CP/CPS, Privacy Policy, Subscriber Agreement, and WebTrust audit d -## 2.2 Publication of information +## 2.2 Publication of certification information Records of all ISRG Root and Subordinate CA certificates, including those that have been revoked, are available in the Certificate Repository: @@ -234,7 +234,7 @@ ISRG may elect not to issue any certificate at its sole discretion. Applicants are required to prove possession of the Private Key corresponding to the Public Key in a Certificate request by signing the CSR provided to the Finalize method of the ACME Protocol defined in RFC 8555, Section 7.4. -### 3.2.2 Authentication of Organization and Domain Identity +### 3.2.2 Authentication of organization identity ISRG only issues Domain Validation (DV) certificates. All FQDNs which will be listed in the Common Name and list of SANs in the certificate are fully validated prior to issuance. @@ -260,7 +260,7 @@ Non-verified Applicant information is not included in ISRG certificates. ISRG does not issue Subscriber Certificates containing Subject Identity Information, and thus does not validate any natural person's authority to request certificates on behalf of organizations. -### 3.2.6 Criteria for Interoperation or Certification +### 3.2.6 Criteria for interoperation ISRG discloses Cross Certificates in its Certificate Repository. @@ -575,9 +575,9 @@ Not applicable. Not applicable. -# 5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS +# 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS -## 5.1 PHYSICAL SECURITY CONTROLS +## 5.1 Physical controls ### 5.1.1 Site location and construction @@ -646,7 +646,7 @@ Trusted Roles include, but are not limited to: Each Trusted Role requires an appropriate level of training and legal obligation. -### 5.2.2 Number of Individuals Required per Task +### 5.2.2 Number of persons required per task A number of tasks, such as key generation and entering areas physically containing operating ISRG PKI systems, require at least two people in Trusted Roles to be present. @@ -672,7 +672,7 @@ Trusted Contributors must undergo a background check prior to performing in a tr Background checks include, without limitation, criminal background and employment history. -### 5.3.3 Training Requirements and Procedures +### 5.3.3 Training requirements Trusted Contributors must be trained on topics relevant to the role in which they will perform. @@ -696,7 +696,7 @@ Actions taken in response to non-compliance may include termination, removal fro Once management becomes aware of non-compliance the Trusted Contributor(s) in question will be removed from trusted roles until a review of their actions is complete. -### 5.3.7 Independent Contractor Controls +### 5.3.7 Independent contractor requirements Independent contractors who are assigned to perform Trusted Roles are subject to the duties and requirements specified for such roles in this CP/CPS. This includes those described in Section 5.3. Potential sanctions for unauthorized activities by independent contractors are described in Section 5.3.6. @@ -716,23 +716,23 @@ At a minimum, each audit record includes: * Identity of the person (or machine) making the entry; and * Description of the entry. -### 5.4.2 Frequency for Processing and Archiving Audit Logs +### 5.4.2 Frequency of processing log No stipulation. -### 5.4.3 Retention Period for Audit Logs +### 5.4.3 Retention period for audit log Audit logs are retained for at least the period required by Section 5.4.3 of the Baseline Requirements. -### 5.4.4 Protection of Audit Log +### 5.4.4 Protection of audit log Audit logs, whether in production or archived, are protected using both physical and logical access controls. -### 5.4.5 Audit Log Backup Procedures +### 5.4.5 Audit log backup procedures ISRG makes regular backup copies of audit logs. -### 5.4.6 Audit Log Accumulation System (internal vs. external) +### 5.4.6 Audit collection system (internal vs. external) Audit data is automatically generated and reported/recorded by operating systems, CA software applications, and network devices. Systems are in place to ensure proper reporting and recording of audit data, and the failure of such systems may lead to suspension of CA services until proper audit log reporting is restored. @@ -806,11 +806,11 @@ When a CA certificate is nearing expiration, a key changeover procedure is used ISRG has created and maintains incident response procedures for a range of potential compromise and disaster situations. Such situations include, but are not limited to, natural disasters, security incidents, and equipment failure. Incident response plans are reviewed, potentially updated, and tested on at least an annual basis. -### 5.7.2 Recovery Procedures if Computing resources, software, and/or data are corrupted +### 5.7.2 Computing resources, software, and/or data are corrupted In the event that computing resources, software, and/or data are corrupted or otherwise damaged, ISRG will assess the situation, including its impact on CA integrity and security, and take appropriate action. CA operations may be suspended until mitigation is complete. Subscribers may be notified if corruption or damage has a material impact on the service provided to them. -### 5.7.3 Recovery Procedures after Key Compromise +### 5.7.3 Entity private key compromise procedures In the event that an ISRG CA Private Key is compromised, or suspected to be compromised, ISRG will immediately launch a thorough investigation. Forensic evidence will be collected and secured as quickly as possible. If it cannot be determined with a high degree of certainty that the private key in question was not compromised, then the following steps may be taken in whatever order ISRG Security Officers deem most appropriate: @@ -880,8 +880,8 @@ ISRG uses HSMs conforming to FIPS 186-4, capable of providing random number gene Per NIST SP 800‐89 (), section 5.3.3, the CA ensures that: - - the public exponent of any RSA key used in a DV-SSL Certificate is in the range between 216+1 and 2256-1, and - - the modulus of such a certificate is an odd number, not the power of a prime, and has no factors smaller than 752. +* the public exponent of any RSA key used in a DV-SSL Certificate is in the range between 216+1 and 2256-1, and +* the modulus of such a certificate is an odd number, not the power of a prime, and has no factors smaller than 752. ### 6.1.7 Key usage purposes (as per X.509 v3 key usage field) @@ -917,21 +917,21 @@ ISRG CA Private Keys are generated inside HSMs and are only transferred between ISRG CA Private Keys are stored on HSMs meeting the requirements stated in Section 6.2.1. -### 6.2.8 Activating Private Keys +### 6.2.8 Method of activating private key ISRG CA Private Keys are always stored on HSMs and activated using the mechanisms provided by the HSM manufacturer. -### 6.2.9 Deactivating Private Keys +### 6.2.9 Method of deactivating private key ISRG CA Private Keys are always stored on HSMs and deactivated using the mechanisms provided by the HSM manufacturer. -### 6.2.10 Destroying Private Keys +### 6.2.10 Method of destroying private key ISRG CA Private Keys are destroyed by Trusted Contributors using a FIPS 140-2 (or higher) validated zeroize method provided by the HSMs storing the keys. Physical destruction of the HSM is not required. See the Let's Encrypt Subscriber Agreement for information regarding Subscriber private key destruction. -### 6.2.11 Cryptographic Module Capabilities +### 6.2.11 Cryptographic Module Rating See Section 6.2.1. @@ -1081,7 +1081,7 @@ Signed by a Root CA Certificate, these Certificates may sign OCSP responses for All certificates use X.509 version 3. -### 7.1.2 Certificate Content and Extensions; Application of RFC 5280 +### 7.1.2 Certificate extensions See section 7.1. @@ -1341,14 +1341,14 @@ Each Relying Party represents and warrants that, prior to relying on an ISRG cer 4. Verified both the ISRG certificate and the certificates in the certificate chain using the relevant CRL or OCSP, 5. Will not use an ISRG certificate if the certificate has expired or been revoked, and 6. Will take all reasonable steps to minimize the risk associated with relying on a digital signature, including only relying on an ISRG certificate after considering: - * Applicable law and the legal requirements for identification of a party, protection of the confidentiality or privacy of information, and enforceability of the transaction; - * The intended use of the certificate as listed in the certificate or this CP/CPS, - * The data listed in the certificate, - * The economic value of the transaction or communication, - * The potential loss or damage that would be caused by an erroneous identification or a loss of confidentiality or privacy of information in the application, transaction, or communication, - * The Relying Party's previous course of dealing with the Subscriber, - * The Relying Party's understanding of trade, including experience with computer-based methods of trade, and - * Any other indicia of reliability or unreliability pertaining to the Subscriber and/or the application, communication, or transaction. + * Applicable law and the legal requirements for identification of a party, protection of the confidentiality or privacy of information, and enforceability of the transaction; + * The intended use of the certificate as listed in the certificate or this CP/CPS, + * The data listed in the certificate, + * The economic value of the transaction or communication, + * The potential loss or damage that would be caused by an erroneous identification or a loss of confidentiality or privacy of information in the application, transaction, or communication, + * The Relying Party's previous course of dealing with the Subscriber, + * The Relying Party's understanding of trade, including experience with computer-based methods of trade, and + * Any other indicia of reliability or unreliability pertaining to the Subscriber and/or the application, communication, or transaction. Any unauthorized reliance on a certificate is at a party's own risk. diff --git a/tools/lint/README.md b/tools/lint/README.md new file mode 100644 index 0000000..30b7553 --- /dev/null +++ b/tools/lint/README.md @@ -0,0 +1,61 @@ +# CP/CPS Linter + +This tool performs a variety of simple checks on the CP/CPS to ensure that it +is in compliance with the Baseline Requirements. It is superficial: a clean +lint check is a necessary but not sufficient condition for full compliance. + +Usage: + +```sh +$ go run . /path/to/cps.md +heading "### 3.1.3 Anonymity or pseudonymity of subscribers" found out-of-order on line 199 +heading "### 4.4.2 Publication of the certificate by the CA" not found +empty section found at line 71 +empty section found at line 272 +exit status 1 +``` + +This tool is used by GitHub Actions to check every PR against this repo. + +## Checks + +The linter looks for compliance with Ballot SC-074, which added the following +text to the Baseline Requirements, Section 2.2: + +> the Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with section 6 of RFC 3647 and MUST: +> +> * include at least every section and subsection defined in section 6 of RFC 3647; +> * only use the words "No Stipulation" to mean that the particular document imposes no requirements related to that section; and +> * contain no sections that are blank and have no subsections. + +### RFC 3647 Outline + +A significant portion of this linter's work is confirming that the structure of +the CP/CPS matches the outline laid out in [RFC 3647, Section +6](https://datatracker.ietf.org/doc/html/rfc3647#section-6). This outline is +reproduced in [outline.txt](outline.txt), which was produced using the following +procedure: + +1. Copy-paste the whole of Section 6 into a plaintext document. +2. Remove the leading text, and the page headers and footers. +3. Unwrap all section titles which were broken onto multiple lines. +4. Replace all sequences of more than one space (` `) with a single space. +5. Remove the `(11)` footnote indicator which follows some entries. +6. Prepend each line with a number of `#` equal to its section depth. + +The lint tool then ensures that every line in this file appears in the CP/CPS, +exactly as written, in order. + +### No Empty Sections + +The linter also looks for any places where two section header lines separated +only by whitespace have the same or decreasing section depth (e.g. "1.2.3" +followed by "1.3"), indicating that the first of the two sections has no +content. + +### Use of "No Stipulation" + +This linter does **not** check whether the phrase "No Stipulation" has been used +to mean anything other than that "that the particular document imposes no +requirements related to that section", since doing so is a semantic (not +syntactic) matter. diff --git a/tools/lint/go.mod b/tools/lint/go.mod new file mode 100644 index 0000000..17f4768 --- /dev/null +++ b/tools/lint/go.mod @@ -0,0 +1,3 @@ +module github.com/letsencrypt/cp-cps/tools/lint + +go 1.22.2 diff --git a/tools/lint/main.go b/tools/lint/main.go new file mode 100644 index 0000000..9a59462 --- /dev/null +++ b/tools/lint/main.go @@ -0,0 +1,115 @@ +package main + +import ( + "bufio" + _ "embed" + "fmt" + "os" + "slices" + "strings" +) + +//go:embed outline.txt +var outline string + +func main() { + if len(os.Args) < 2 { + fmt.Fprintln(os.Stderr, "must provide path to document to check") + os.Exit(1) + } + + file, err := os.Open(os.Args[1]) + if err != nil { + fmt.Fprintln(os.Stderr, "opening document:", err) + os.Exit(1) + } + defer file.Close() + scanner := bufio.NewScanner(file) + + var lines []string + for scanner.Scan() { + lines = append(lines, scanner.Text()) + } + if err := scanner.Err(); err != nil { + fmt.Fprintln(os.Stderr, "reading document:", err) + os.Exit(1) + } + + anyErr := false + + errs := make(chan error) + go func() { + lintHeadings(lines, errs) + close(errs) + }() + for err = range errs { + anyErr = true + fmt.Fprintln(os.Stderr, err) + } + + errs = make(chan error) + go func() { + lintEmptySections(lines, errs) + close(errs) + }() + for err = range errs { + anyErr = true + fmt.Fprintln(os.Stderr, err) + } + + if anyErr { + os.Exit(1) + } + + fmt.Println("lint checks complete; no findings") +} + +// lintHeadings tries to locate every heading that we expect to exist, and +// checks that they appear in the correct order. +func lintHeadings(lines []string, errs chan<- error) { + outline = strings.TrimSpace(outline) + headings := strings.Split(outline, "\n") + headingLines := make([]int, len(headings)) + + for i, heading := range headings { + headingLines[i] = slices.Index(lines, heading) + } + + for i, lineNo := range headingLines { + if lineNo == -1 { + errs <- fmt.Errorf("heading %q not found", headings[i]) + continue + } + + if i > 0 && lineNo <= headingLines[i-1] { + errs <- fmt.Errorf("heading %q found out-of-order on line %d", headings[i], lineNo) + continue + } + } +} + +// lintEmptySections looks for places where two section headings occur with +// nothing other than empty lines between them, and the second section is of +// equal or lesser depth (being of greater depth is fine, that's a subsection). +func lintEmptySections(lines []string, errs chan<- error) { + lastHeadingDepth := 0 + sectionBodySeen := false + for i, line := range lines { + if line == "" { + continue + } + + if strings.HasPrefix(line, "#") { + currHeadingDepth := len(line) - len(strings.TrimLeft(line, "#")) + if currHeadingDepth <= lastHeadingDepth && !sectionBodySeen { + errs <- fmt.Errorf("empty section found at line %d", i) + } + + lastHeadingDepth = currHeadingDepth + sectionBodySeen = false + continue + } + + sectionBodySeen = true + } +} diff --git a/tools/lint/outline.txt b/tools/lint/outline.txt new file mode 100644 index 0000000..7a14138 --- /dev/null +++ b/tools/lint/outline.txt @@ -0,0 +1,270 @@ +# 1. INTRODUCTION +## 1.1 Overview +## 1.2 Document name and identification +## 1.3 PKI participants +### 1.3.1 Certification authorities +### 1.3.2 Registration authorities +### 1.3.3 Subscribers +### 1.3.4 Relying parties +### 1.3.5 Other participants +## 1.4 Certificate usage +### 1.4.1 Appropriate certificate uses +### 1.4.2 Prohibited certificate uses +## 1.5 Policy administration +### 1.5.1 Organization administering the document +### 1.5.2 Contact person +### 1.5.3 Person determining CPS suitability for the policy +### 1.5.4 CPS approval procedures +## 1.6 Definitions and acronyms +# 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES +## 2.1 Repositories +## 2.2 Publication of certification information +## 2.3 Time or frequency of publication +## 2.4 Access controls on repositories +# 3. IDENTIFICATION AND AUTHENTICATION +## 3.1 Naming +### 3.1.1 Types of names +### 3.1.2 Need for names to be meaningful +### 3.1.3 Anonymity or pseudonymity of subscribers +### 3.1.4 Rules for interpreting various name forms +### 3.1.5 Uniqueness of names +### 3.1.6 Recognition, authentication, and role of trademarks +## 3.2 Initial identity validation +### 3.2.1 Method to prove possession of private key +### 3.2.2 Authentication of organization identity +### 3.2.3 Authentication of individual identity +### 3.2.4 Non-verified subscriber information +### 3.2.5 Validation of authority +### 3.2.6 Criteria for interoperation +## 3.3 Identification and authentication for re-key requests +### 3.3.1 Identification and authentication for routine re-key +### 3.3.2 Identification and authentication for re-key after revocation +## 3.4 Identification and authentication for revocation request +# 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS +## 4.1 Certificate Application +### 4.1.1 Who can submit a certificate application +### 4.1.2 Enrollment process and responsibilities +## 4.2 Certificate application processing +### 4.2.1 Performing identification and authentication functions +### 4.2.2 Approval or rejection of certificate applications +### 4.2.3 Time to process certificate applications +## 4.3 Certificate issuance +### 4.3.1 CA actions during certificate issuance +### 4.3.2 Notification to subscriber by the CA of issuance of certificate +## 4.4 Certificate acceptance +### 4.4.1 Conduct constituting certificate acceptance +### 4.4.2 Publication of the certificate by the CA +### 4.4.3 Notification of certificate issuance by the CA to other entities +## 4.5 Key pair and certificate usage +### 4.5.1 Subscriber private key and certificate usage +### 4.5.2 Relying party public key and certificate usage +## 4.6 Certificate renewal +### 4.6.1 Circumstance for certificate renewal +### 4.6.2 Who may request renewal +### 4.6.3 Processing certificate renewal requests +### 4.6.4 Notification of new certificate issuance to subscriber +### 4.6.5 Conduct constituting acceptance of a renewal certificate +### 4.6.6 Publication of the renewal certificate by the CA +### 4.6.7 Notification of certificate issuance by the CA to other entities +## 4.7 Certificate re-key +### 4.7.1 Circumstance for certificate re-key +### 4.7.2 Who may request certification of a new public key +### 4.7.3 Processing certificate re-keying requests +### 4.7.4 Notification of new certificate issuance to subscriber +### 4.7.5 Conduct constituting acceptance of a re-keyed certificate +### 4.7.6 Publication of the re-keyed certificate by the CA +### 4.7.7 Notification of certificate issuance by the CA to other entities +## 4.8 Certificate modification +### 4.8.1 Circumstance for certificate modification +### 4.8.2 Who may request certificate modification +### 4.8.3 Processing certificate modification requests +### 4.8.4 Notification of new certificate issuance to subscriber +### 4.8.5 Conduct constituting acceptance of modified certificate +### 4.8.6 Publication of the modified certificate by the CA +### 4.8.7 Notification of certificate issuance by the CA to other entities +## 4.9 Certificate revocation and suspension +### 4.9.1 Circumstances for revocation +### 4.9.2 Who can request revocation +### 4.9.3 Procedure for revocation request +### 4.9.4 Revocation request grace period +### 4.9.5 Time within which CA must process the revocation request +### 4.9.6 Revocation checking requirement for relying parties +### 4.9.7 CRL issuance frequency (if applicable) +### 4.9.8 Maximum latency for CRLs (if applicable) +### 4.9.9 On-line revocation/status checking availability +### 4.9.10 On-line revocation checking requirements +### 4.9.11 Other forms of revocation advertisements available +### 4.9.12 Special requirements re key compromise +### 4.9.13 Circumstances for suspension +### 4.9.14 Who can request suspension +### 4.9.15 Procedure for suspension request +### 4.9.16 Limits on suspension period +## 4.10 Certificate status services +### 4.10.1 Operational characteristics +### 4.10.2 Service availability +### 4.10.3 Optional features +## 4.11 End of subscription +## 4.12 Key escrow and recovery +### 4.12.1 Key escrow and recovery policy and practices +### 4.12.2 Session key encapsulation and recovery policy and practices +# 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS +## 5.1 Physical controls +### 5.1.1 Site location and construction +### 5.1.2 Physical access +### 5.1.3 Power and air conditioning +### 5.1.4 Water exposures +### 5.1.5 Fire prevention and protection +### 5.1.6 Media storage +### 5.1.7 Waste disposal +### 5.1.8 Off-site backup +## 5.2 Procedural controls +### 5.2.1 Trusted roles +### 5.2.2 Number of persons required per task +### 5.2.3 Identification and authentication for each role +### 5.2.4 Roles requiring separation of duties +## 5.3 Personnel controls +### 5.3.1 Qualifications, experience, and clearance requirements +### 5.3.2 Background check procedures +### 5.3.3 Training requirements +### 5.3.4 Retraining frequency and requirements +### 5.3.5 Job rotation frequency and sequence +### 5.3.6 Sanctions for unauthorized actions +### 5.3.7 Independent contractor requirements +### 5.3.8 Documentation supplied to personnel +## 5.4 Audit logging procedures +### 5.4.1 Types of events recorded +### 5.4.2 Frequency of processing log +### 5.4.3 Retention period for audit log +### 5.4.4 Protection of audit log +### 5.4.5 Audit log backup procedures +### 5.4.6 Audit collection system (internal vs. external) +### 5.4.7 Notification to event-causing subject +### 5.4.8 Vulnerability assessments +## 5.5 Records archival +### 5.5.1 Types of records archived +### 5.5.2 Retention period for archive +### 5.5.3 Protection of archive +### 5.5.4 Archive backup procedures +### 5.5.5 Requirements for time-stamping of records +### 5.5.6 Archive collection system (internal or external) +### 5.5.7 Procedures to obtain and verify archive information +## 5.6 Key changeover +## 5.7 Compromise and disaster recovery +### 5.7.1 Incident and compromise handling procedures +### 5.7.2 Computing resources, software, and/or data are corrupted +### 5.7.3 Entity private key compromise procedures +### 5.7.4 Business continuity capabilities after a disaster +## 5.8 CA or RA termination +# 6. TECHNICAL SECURITY CONTROLS +## 6.1 Key pair generation and installation +### 6.1.1 Key pair generation +### 6.1.2 Private key delivery to subscriber +### 6.1.3 Public key delivery to certificate issuer +### 6.1.4 CA public key delivery to relying parties +### 6.1.5 Key sizes +### 6.1.6 Public key parameters generation and quality checking +### 6.1.7 Key usage purposes (as per X.509 v3 key usage field) +## 6.2 Private Key Protection and Cryptographic Module Engineering Controls +### 6.2.1 Cryptographic module standards and controls +### 6.2.2 Private key (n out of m) multi-person control +### 6.2.3 Private key escrow +### 6.2.4 Private key backup +### 6.2.5 Private key archival +### 6.2.6 Private key transfer into or from a cryptographic module +### 6.2.7 Private key storage on cryptographic module +### 6.2.8 Method of activating private key +### 6.2.9 Method of deactivating private key +### 6.2.10 Method of destroying private key +### 6.2.11 Cryptographic Module Rating +## 6.3 Other aspects of key pair management +### 6.3.1 Public key archival +### 6.3.2 Certificate operational periods and key pair usage periods +## 6.4 Activation data +### 6.4.1 Activation data generation and installation +### 6.4.2 Activation data protection +### 6.4.3 Other aspects of activation data +## 6.5 Computer security controls +### 6.5.1 Specific computer security technical requirements +### 6.5.2 Computer security rating +## 6.6 Life cycle technical controls +### 6.6.1 System development controls +### 6.6.2 Security management controls +### 6.6.3 Life cycle security controls +## 6.7 Network security controls +## 6.8 Time-stamping +# 7. CERTIFICATE, CRL, AND OCSP PROFILES +## 7.1 Certificate profile +### 7.1.1 Version number(s) +### 7.1.2 Certificate extensions +### 7.1.3 Algorithm object identifiers +### 7.1.4 Name forms +### 7.1.5 Name constraints +### 7.1.6 Certificate policy object identifier +### 7.1.7 Usage of Policy Constraints extension +### 7.1.8 Policy qualifiers syntax and semantics +### 7.1.9 Processing semantics for the critical Certificate Policies extension +## 7.2 CRL profile +### 7.2.1 Version number(s) +### 7.2.2 CRL and CRL entry extensions +## 7.3 OCSP profile +### 7.3.1 Version number(s) +### 7.3.2 OCSP extensions +# 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS +## 8.1 Frequency or circumstances of assessment +## 8.2 Identity/qualifications of assessor +## 8.3 Assessor's relationship to assessed entity +## 8.4 Topics covered by assessment +## 8.5 Actions taken as a result of deficiency +## 8.6 Communication of results +# 9. OTHER BUSINESS AND LEGAL MATTERS +## 9.1 Fees +### 9.1.1 Certificate issuance or renewal fees +### 9.1.2 Certificate access fees +### 9.1.3 Revocation or status information access fees +### 9.1.4 Fees for other services +### 9.1.5 Refund policy +## 9.2 Financial responsibility +### 9.2.1 Insurance coverage +### 9.2.2 Other assets +### 9.2.3 Insurance or warranty coverage for end-entities +## 9.3 Confidentiality of business information +### 9.3.1 Scope of confidential information +### 9.3.2 Information not within the scope of confidential information +### 9.3.3 Responsibility to protect confidential information +## 9.4 Privacy of personal information +### 9.4.1 Privacy plan +### 9.4.2 Information treated as private +### 9.4.3 Information not deemed private +### 9.4.4 Responsibility to protect private information +### 9.4.5 Notice and consent to use private information +### 9.4.6 Disclosure pursuant to judicial or administrative process +### 9.4.7 Other information disclosure circumstances +## 9.5 Intellectual property rights +## 9.6 Representations and warranties +### 9.6.1 CA representations and warranties +### 9.6.2 RA representations and warranties +### 9.6.3 Subscriber representations and warranties +### 9.6.4 Relying party representations and warranties +### 9.6.5 Representations and warranties of other participants +## 9.7 Disclaimers of warranties +## 9.8 Limitations of liability +## 9.9 Indemnities +## 9.10 Term and termination +### 9.10.1 Term +### 9.10.2 Termination +### 9.10.3 Effect of termination and survival +## 9.11 Individual notices and communications with participants +## 9.12 Amendments +### 9.12.1 Procedure for amendment +### 9.12.2 Notification mechanism and period +### 9.12.3 Circumstances under which OID must be changed +## 9.13 Dispute resolution provisions +## 9.14 Governing law +## 9.15 Compliance with applicable law +## 9.16 Miscellaneous provisions +### 9.16.1 Entire agreement +### 9.16.2 Assignment +### 9.16.3 Severability +### 9.16.4 Enforcement (attorneys' fees and waiver of rights) +### 9.16.5 Force Majeure +## 9.17 Other provisions