# X.509 Certificate Policy for [ORG]

**Version:** 0.5 (DRAFT: not approved, not in force)
**Date:** 2026-08-29 (rev. two-person control)
**Status:** Draft for PMA review. No CA may operate under this document until the PMA votes it approved.

---

## About this draft

Structured per **RFC 3647**. Every subcomponent of the nine-section outline appears, using
*"No stipulation"* where this policy imposes no requirement; RFC 3647 §4 requires this so that
another PKI's CP can be compared to ours section-by-section, which is what makes policy mapping
(§1.2, §4.9, cross-certification) possible at all.

**`[DECIDE]`** marks a choice this draft cannot make for you. Grep for it. Each one names the
options and the consequence. The document is not approvable while any remain.

This CP is normative on *what* and *why*. It deliberately does not duplicate:

| For | See |
|---|---|
| Why the hierarchy is shaped this way | [architecture.md](architecture.md) |
| Field-by-field certificate and CRL contents | [profiles.md](profiles.md) |
| Components, trust boundaries, flows, sequencing | [components.md](components.md) |
| How a specific CA meets this policy | that CA's CPS |

---

# 1. Introduction

## 1.1 Overview

This Certificate Policy (CP) is the single policy under which every Certification Authority in the
[ORG] PKI is established and operates, whether operated by [ORG], by a subordinate organization, or
by a third party admitted under §1.3.

It defines the creation and management of X.509 version 3 public key certificates for applications
requiring authenticated, integrity-protected and confidential communication between networked
systems: authentication of people and workloads, signature of documents and code, encryption of mail
and data at rest, and authentication of infrastructure components.

This CP does **not** define a particular implementation. It does not name a CA product, a hardware
security module, or a deployment topology. Those belong in a Certification Practice Statement (CPS)
and in [architecture.md](architecture.md). This separation is deliberate: it is what allows CAs
operated by different organizations on different software to interoperate under one assurance
standard, and what allows the implementation to change without reopening the policy.

The stipulations here are **minimum** requirements. A system owner may require higher assurance than
this CP specifies for a given application; none may accept lower.

> **RESOLVED.** Captured at initialization. `./certauth init` collects the legal
> entity name, country and program, validates them as PrintableString-safe
> (§3.1.4), and writes them to `certauth.conf`, from which every DN in the system
> is derived in one place. It is asked first and marked permanent, because the
> `O=` value is signed into a root valid for 25 years.

## 1.2 Document Name and Identification

This document is the *X.509 Certificate Policy for [ORG]*.

This CP defines multiple policies. Each is assigned an object identifier (OID) asserted in
certificates issued by CAs that comply with the stipulations attached to that OID. OIDs are
registered under the [ORG] Private Enterprise Number arc:

```
id-org-arc  ::= { iso(1) identified-organization(3) dod(6) internet(1)
                  private(4) enterprise(1) [PEN] }
id-org-cp   ::= { id-org-arc 1 }        -- certificate policies
```

| OID | Name | Assurance | Key | Launch |
|---|---|---|---|---|
| `{id-org-cp 1}` | `id-org-medium-128` | Software key, remote proofing | EC P-256 | later |
| `{id-org-cp 2}` | `id-org-hardware-112` | FIPS 140-3 L2 token, in-person proofing | **RSA 2048** | **yes** |
| `{id-org-cp 3}` | `id-org-hardware-128` | FIPS 140-3 L2 token, in-person proofing | EC P-256 | later |
| `{id-org-cp 8}` | `id-org-hardware-192` | FIPS 140-3 L2 token, in-person proofing | **EC P-384** | **yes** |
| `{id-org-cp 4}` | `id-org-device-128` | Non-person entity, sponsor-attested | EC P-256 | **yes** |
| `{id-org-cp 5}` | `id-org-internal-device-128` | NPE, no multi-person control, internal root only | EC P-256 | later |
| `{id-org-cp 6}` | `id-org-admin` | Privileged operators | EC P-384 | later |
| `{id-org-cp 7}` | `id-org-peerInterop` | **Cross-certificates only**, at PMA direction | - | later |

Rules governing these OIDs:

1. **An OID is never redefined.** If the assurance associated with an OID would materially change, a
   new OID is assigned and the old one deprecated (§9.12.3). Deprecated OIDs are listed in the
   Deprecated Practices Register and are not acceptable policies for relying parties.
2. **Strength is a dimension of the OID, not a separate field.** `hardware-112`, `-128` and `-192`
   differ only in cryptographic strength. A relying party requiring 128-bit security expresses that
   as a *policy OID set*, which RFC 5280 path validation computes for it. See
   [profiles.md §1.2b](profiles.md) for how token capability selects the OID.
3. **`id-org-peerInterop` is asserted only in cross-certificates**, only at PMA direction, and never
   in an end-entity certificate.
4. **`id-org-admin` is issued only to subscribers designated to perform privileged system
   administration** within their organization.
5. A CA certificate shall carry **every** OID under which that CA issues, and no others. An OCSP
   responder certificate shall carry every OID used by the CA for which it is authoritative.

> **DEFERRED (2026-08-30): operating on an unregistered arc.** An IANA Private
> Enterprise Number is not obtainable at this stage, so the PKI runs on a
> placeholder arc.
>
> What this costs, stated plainly: the arc is **not registered to anyone**, so
> nothing prevents another party using the same numbers. Certificates asserting
> these OIDs are safe to rely on *inside* this organization, where the trust
> anchor is ours and collision is not a threat. They are **not** safe to present
> to any relying party outside it, and no external PKI can map to these policies.
>
> Migration is not free. Policy OIDs are signed into every certificate and every
> CA certificate. Moving to a registered arc means reissuing the entire
> population, not editing a config. The cost grows with every certificate issued,
> so register the PEN before the population does.
>
> `./certauth config` warns while the placeholder is in use.

**Launch policy set: three.** `id-org-hardware-112` (people on RSA-only token stock),
`id-org-hardware-192` (people on ECC tokens) and `id-org-device-128` (workloads). The remaining OIDs
are reserved and unissued. Adding an OID later is cheap; retiring one already in certificates is not.

## 1.3 PKI Participants

### 1.3.1 Certification Authorities

A Certification Authority (CA) is an entity authorized by the PMA to create, sign and issue public
key certificates. A CA is responsible for every aspect of issuance and management: control of the
registration process, identification and authentication, certificate generation, publication,
revocation, re-key, and where applicable key escrow and recovery. A CA is responsible for ensuring
that all CA services, operations and infrastructure relating to certificates issued under this
policy conform to this CP.

"CA" is inclusive: it covers root CAs, issuing CAs, interoperability root CAs, and the component
parts (databases, web front ends, escrow systems, internal directories) within a CA's security
boundary. Every requirement stated for a CA applies to its components unless stated otherwise.

Together, CAs and Registration Authorities are **Certificate Management Authorities (CMAs)**. This
CP uses "CMA" wherever a requirement applies to both, or where a function may be assigned to either.
An OCSP responder holding a certificate issued under this CP is also a CMA.

The [ORG] PKI operates multiple independent trust anchors. Their number, split rationale and
parameters are in [architecture.md §2](architecture.md). This CP governs all of them.

### 1.3.2 Registration Authorities

A Registration Authority (RA) verifies subscriber identity and authorization and communicates
certificate requests to a CA. "RA" includes Local Registration Authorities (LRAs) and Trusted Agents
operating under an RA's authority. An RA's responsibilities are:

- verifying initial identity per §3.2;
- entering subscriber information and verifying its correctness;
- securely communicating requests to, and responses from, the CA;
- receiving and distributing subscriber certificates;
- verifying the identity and authorization of entities requesting recovery of escrowed keys;
- authorizing and facilitating recovery of escrowed key material.

The division of registration responsibility between CA and RA varies by implementation and **shall
be described in the CA's CPS**.

A Card Management System that holds credentials permitting it to request certificate issuance or
revocation is an RA for the purposes of this CP, and the privileged users who direct it are RAs.

### 1.3.3 Subscribers

A subscriber is the entity whose name appears as the subject of a certificate and who holds the
corresponding private key. Subscribers are:

- **People** affiliated with [ORG]: employees, contractors, and affiliates authorized under §3.2.3.
- **Non-person entities (NPEs)**: devices, workloads, applications, groups and roles. An NPE
  subscriber is represented by a **PKI Sponsor** (§5.2.1.4), a named person who holds the
  subscriber's obligations.

CAs are subscribers of their superior CA. A CA is not a subscriber of itself.

**Eligibility.** Employees and contractors of [ORG] are eligible. External partners are **not**
issued certificates directly; they are reached by cross-certification under §3.2.6, so that a
partner's population remains that partner's responsibility to proof and revoke. The authority
determining affiliation is the Identity Source of Record (§1.3.5).

### 1.3.4 Relying Parties

A relying party is any entity that uses a certificate issued under this CP to verify a signature,
authenticate a counterparty, or establish a confidential channel. A relying party is obliged to
perform the checks in §4.5.2. Relying on a certificate without validating it is outside this CP and
carries no warranty.

### 1.3.5 Other Participants

- **Policy Management Authority (PMA)**: §1.5.1.
- **Compliance Auditor**: §8.
- **Key Recovery Agent (KRA) and Key Recovery Official (KRO)**: §4.12, where escrow is operated.
- **Identity Source of Record**: the authoritative system for subscriber affiliation and the unique
  identifier of §3.1.5, operated outside the PKI under an agreement per §9.

## 1.4 Certificate Usage

### 1.4.1 Appropriate Certificate Uses

Certificates issued under this CP may be used for authentication, digital signature, non-repudiation,
key establishment and encryption, consistent with the `keyUsage` and `extendedKeyUsage` of the
certificate and the assurance of its policy OID, as specified in [profiles.md](profiles.md).

A relying party shall make its access decision on the **policy OID that survives RFC 5280 path
validation**, not on the fact that a chain validated. Certificates asserting `id-org-medium-128` are
not acceptable where `id-org-hardware-192` is required.

### 1.4.2 Prohibited Certificate Uses

Certificates shall not be used:

- for any purpose inconsistent with their `keyUsage` or `extendedKeyUsage`;
- contrary to law;
- to secure systems whose accreditor requires assurance higher than the asserted policy OID;
- as trust anchors, except for root CA certificates distributed per §6.1.4.

Certificates asserting `id-org-peerInterop` shall not be used to authorize access to any [ORG]
system. That OID indicates a cross-certification relationship, not an assurance level.

## 1.5 Policy Administration

### 1.5.1 Organization Administering the Document

The **[ORG] Policy Management Authority (PMA)** owns this CP. The PMA:

- approves this CP and every change to it (§9.12);
- reviews and approves the CPS of every CA operating under this CP, before that CA is certified;
- reviews compliance audit results and directs corrective action, up to and including revoking a
  CA's certificate;
- determines whether an external policy is sufficient to be mapped to one of ours, and approves
  every cross-certification (§4.9 and [architecture.md §4](architecture.md));
- maintains the Deprecated Practices Register, the Waiver Register (if §1.5.5 permits waivers), and
  the Approved External PKI register;
- advises system owners on which policy OIDs are appropriate for which application.

The PMA is a body, not an individual. Its decision authority rests with **[PMA EXECUTIVE]** and may
be delegated in writing.

> `[DECIDE]` **PMA composition and charter.** Name the accountable executive, the voting members,
> the quorum, and the individual with unilateral emergency revocation authority (§4.9.2). Nothing in
> this PKI can be approved until this body exists and can say no.
>
> **DEFERRED (2026-08-30).** Tabled by decision; this is organizational and
> legal work, not technical, and it does not block building or operating the
> system. It **does** block the CP being approved and therefore blocks issuing
> credentials anyone else is expected to rely on. Revisit before that point.

### 1.5.2 Contact Person

`[PMA CONTACT: role title, postal address, email, and a monitored 24×7 channel for compromise
reports per §4.9.3]`

### 1.5.3 Person Determining CPS Suitability for the Policy

The PMA determines whether a CPS satisfies this CP, on the basis of a written CPS-to-CP compliance
analysis mapping each section of this CP to the corresponding CPS provision.

### 1.5.4 CPS Approval Procedures

1. The CA operator submits its CPS and compliance analysis to the PMA.
2. The PMA reviews and either approves, or returns with findings.
3. On approval, the CA may perform its key ceremony (§6.1.1) and be issued a CA certificate.
4. The CA undergoes an initial compliance audit (§8) before issuing to subscribers.
5. The CPS is re-approved on material change, and reviewed at least **annually**.

No CA shall issue any certificate under this CP before its CPS is approved.

### 1.5.5 Waivers

**No waivers.** CAs issuing under this CP are required to meet all of its requirements. The PMA does
not issue waivers, and there is no exception register.

Where a requirement genuinely cannot be met, the only remedy is a CP amendment under §9.12. So that
this does not become a route to silent non-compliance, §9.12.2 provides an **expedited amendment
path** for an active security deficiency: the PMA may shorten or waive the comment period, with the
reasons recorded and published.

The distinction matters. A waiver exempts one CA from a rule the rule still claims to impose. An
expedited amendment changes the rule for everyone, in the open, on the record. The first accumulates
undisclosed assurance debt; the second does not.

## 1.6 Definitions and Acronyms

| Term | Meaning |
|---|---|
| **aCAK** | Asymmetric Card Authentication Key |
| **AIA** | Authority Information Access extension |
| **CMA** | Certificate Management Authority: a CA, RA or OCSP responder |
| **CMS** | Card Management System |
| **CP / CPS** | Certificate Policy / Certification Practice Statement |
| **CRLDP** | CRL Distribution Points extension |
| **IRCA** | Interoperability Root CA; holds cross-certificates only |
| **ISSO** | Information System Security Officer |
| **KED / KRA / KRO** | Key Escrow Database / Key Recovery Agent / Key Recovery Official |
| **NPE** | Non-Person Entity |
| **PDS** | PKI Disclosure Statement |
| **PKI Sponsor** | Person holding subscriber obligations for an NPE |
| **PMA** | Policy Management Authority |
| **RA / LRA** | Registration Authority / Local Registration Authority |
| **SIA** | Subject Information Access extension |

References: RFC 3647, RFC 5280, RFC 6960, RFC 8555, FIPS 140-3, FIPS 201, FIPS 203/204/205,
NIST SP 800-57 Pt.1, NIST SP 800-63-4.

---

# 2. Publication and Repository Responsibilities

## 2.1 Repositories

Every CA shall operate, or cause to be operated, a repository publishing its CA certificates, CRLs
and policy documents. The repository shall be **available 24×7** with a target availability of
**99.9%** and shall be reachable over HTTP from the
public Internet.

The **first** entry of the `AIA.caIssuers` field and of `CRLDistributionPoints` in every issued
certificate shall be an HTTP URL reachable from the public Internet
([profiles.md §1.3](profiles.md)). Additional entries may follow. This is the single most
consequential availability rule in this policy: path building fails in the field far more often than
signature verification does.

Repository URIs are frozen before the first certificate is signed and are registrar-locked. A URI
embedded in a root certificate must remain resolvable for the life of that root, up to 25 years.

## 2.2 Publication of Certification Information

Each CA shall publish:

- its own CA certificate and the certificates issued to it;
- all CRLs it issues, per the schedule in §4.9.7;
- this CP;
- an abridged version of its CPS, sufficient for a relying party to assess the CA, with detail whose
  disclosure would harm security withheld;
- a PKI Disclosure Statement summarizing terms for subscribers and relying parties;
- the Deprecated Practices Register and the list of currently acceptable policy OIDs.

Certificates issued to people shall **not** be published to a public repository. Encryption
certificates may be published to an **authenticated** directory to permit correspondents to encrypt
to a subscriber; that directory is access-controlled and is not the public repository.

## 2.3 Time or Frequency of Publication

CA certificates are published promptly on issuance. CRLs are published within **4 hours** of
generation and never later than the `nextUpdate` of the CRL they supersede. Superseded CRLs are
removed on publication of their successor. This CP is published on approval of each version.

## 2.4 Access Controls on Repositories

Read access to the public repository is unrestricted. Write access is restricted to the CA and to
automated publication processes authenticated with certificates issued under this CP. The repository
shall be protected against unauthorized addition, modification and deletion, and such attempts shall
be logged as auditable events (§5.4.1).

---

# 3. Identification and Authentication

## 3.1 Naming

### 3.1.1 Types of Names

Every certificate contains a non-null X.501 Distinguished Name in the subject field, of the forms in
[profiles.md §1.1](profiles.md). All DNs carry the prefix
`C=[CC], O=[ORG], OU=[PROGRAM], OU=PKI`.

### 3.1.2 Need of Names to be Meaningful

Names shall identify the subscriber in a form comprehensible to a human. For people, the common name
is the legal or formally recognized name plus the unique identifier of §3.1.5. For NPEs, the common
name is a fully qualified domain name, IP address, `model-serial`, or application name.

### 3.1.3 Anonymity or Pseudonymity of Subscribers

Anonymous certificates shall not be issued. Pseudonymous certificates may be issued only with PMA
approval, and only where the CA retains the binding between pseudonym and verified identity for the
archive period of §5.5.2.

### 3.1.4 Rules for Interpreting Various Name Forms

Per RFC 5280 and X.501. Each Relative Distinguished Name contains a **single** attribute value;
multi-valued RDNs are prohibited. Directory-string attributes are `PrintableString`, except a common
name that cannot be so encoded, which may be `UTF8String`.

### 3.1.5 Uniqueness of Names

Every subject DN shall be unique across the [ORG] PKI and shall not be reassigned to a different
entity. Uniqueness for people is achieved by a **unique identifier** minted by the Identity Source
of Record and included in the common name. The identifier is immutable and survives name change,
role change and re-issuance.

The CPS shall document how the CA and its RAs interact with the naming authority, and how collisions
are resolved.

> **RESOLVED: allocated by this PKI.** With no external identity system to draw
> on, the PKI is its own naming authority. Identifiers are ten decimal digits
> from 1000000000, allocated sequentially by `./certauth subscriber add` and
> recorded in `ca/registry/subscribers.tsv`. The common name is
> `<name> <identifier>`.
>
> The registry is the authority, so it carries the obligations §3.1.5 places on
> one: an identifier is **allocated once and never reissued**, including after
> the affiliation ends. A returning subscriber is *reactivated* and keeps their
> original identifier; allocating a second would make one person two subjects in
> the archive years later, which is exactly the defect the requirement exists to
> prevent. The tool refuses to allocate against the name of a retired subscriber
> without an explicit override.
>
> The registry is included in backups (§5.1.8). Losing it means reissuing
> identifiers already in use: a silent, permanent violation of §3.1.5.
>
> Sequential allocation reveals the approximate size of the subscriber
> population. That is accepted for an internal PKI and would not be for a public
> one.

### 3.1.6 Recognition, Authentication and Role of Trademarks

Subscribers shall not request names infringing another party's rights. The CA is not obliged to
adjudicate trademark disputes and may reject or revoke on notice of infringement.

## 3.2 Initial Identity Validation

### 3.2.1 Method to Prove Possession of Private Key

Possession shall be proven by a signature over the certificate request (PKCS#10 or CRMF), verified
by the CA or RA. Where the CA generates the key pair on the subscriber's behalf (permitted only for
escrowed encryption keys, §6.1.1), proof of possession is not required, and the private key shall be
delivered per §6.1.2.

### 3.2.2 Authentication of Organization Identity

Where a certificate names an organization, an RA shall verify that the organization exists and that
the requester is authorized to act for it, using documentation independent of the requester.

### 3.2.3 Authentication of Individual Identity

#### 3.2.3.1 People

Identity proofing shall be conducted in person, or by a supervised remote process of equivalent
rigor, by an RA, LRA or Trusted Agent. The proofing shall:

- collect and validate identity evidence sufficient for IAL2 (at least one STRONG piece, or one
  FAIR plus corroboration), at least one bearing a photograph;
- confirm the subscriber's affiliation against the Identity Source of Record;
- record the evidence examined, the identifier of the person who performed the proofing, and the
  date, and retain that record per §5.5.2.

**Proofing standard.** Identity proofing for `id-org-hardware-112` and `id-org-hardware-192` shall
meet **NIST SP 800-63-4 Identity Assurance Level 2 (IAL2)**. Where 800-63-4 and this CP differ, the
stricter applies. Binding to a published IAL rather than to prose is what makes the requirement
auditable and makes policy mapping to a partner's CP tractable.

`id-org-device-128` certificates are issued to non-person entities and are not subject to an IAL;
they are authorized by PKI Sponsor attestation and name-control verification per §3.2.3.3.

#### 3.2.3.2 Trusted Roles

A person appointed to a trusted role (§5.2.1) is a subscriber and shall be proofed at the highest
assurance level operated by that CMA, in addition to the personnel controls of §5.3.

#### 3.2.3.3 Non-Person Entities

An NPE certificate shall be requested by a named **PKI Sponsor**, who shall be a person holding a
current certificate under this CP. The RA shall verify that the sponsor is authorized for the NPE,
and that the name requested is one the sponsor controls; for a DNS name, by verifying control of
the domain.

### 3.2.4 Non-Verified Subscriber Information

Information that has not been verified shall not appear in a certificate. There are no
non-verified fields.

### 3.2.5 Validation of Authority

Before issuing a certificate naming an organization or role, the RA shall verify the requester's
authority to represent it, and shall record the basis of that determination.

### 3.2.6 Criteria for Interoperation

The PMA may approve interoperation with an external PKI by cross-certification, subject to
[architecture.md §4](architecture.md). The external PKI shall demonstrate: an approved CP mapped to
one or more [ORG] policy OIDs; a current compliance audit by an independent auditor; and successful
interoperability testing in the test environment. Cross-certificates shall assert name constraints
and policy constraints per [profiles.md §2.3](profiles.md). Interoperation is re-established on a
recurring basis; a lapsed retest is grounds for revoking the cross-certificate.

## 3.3 Identification and Authentication for Re-Key Requests

### 3.3.1 Identification and Authentication for Routine Re-Key

A subscriber holding a valid, unrevoked certificate may authenticate a re-key request using the
current private key. Re-key without repeated in-person proofing is permitted for at most
**one** routine re-key, giving approximately six years between in-person proofing events
consecutive cycles, after which §3.2.3 proofing is repeated.

### 3.3.2 Identification and Authentication for Re-Key After Revocation

A subscriber whose certificate was revoked shall be re-proofed per §3.2.3. Re-key using the revoked
certificate's key is prohibited in all cases.

## 3.4 Identification and Authentication for Revocation Requests

A revocation request may be authenticated by: the subscriber's own signature; an RA or CA in a
trusted role; the PKI Sponsor for an NPE; or the subscriber's management chain or the Identity
Source of Record, where affiliation has ended.

**Revocation shall never be delayed for want of authentication.** Where a request is credible but
unauthenticated, the CA shall revoke and investigate afterwards. The cost of a wrongful revocation is
a reissuance; the cost of a delayed one is unbounded.

## 3.5 Identification and Authentication for Key Recovery Requests

### 3.5.1 Subscriber Key Recovery Requests

A subscriber requesting recovery of their own escrowed encryption key shall be authenticated to the
standard of §3.2.3, in person or by an equivalent supervised process.

### 3.5.2 Third Party Key Recovery Requests

A third party requesting recovery of another subscriber's escrowed key shall be authenticated as
above **and** shall demonstrate authorization under the Key Recovery Policy. Release requires
**two-person control** (§6.2.2) and shall be notified to the subscriber (§4.12.1).

---

# 4. Certificate Life-Cycle Operational Requirements

## 4.1 Certificate Application

### 4.1.1 Who Can Submit a Certificate Application

A prospective subscriber, an RA on a subscriber's behalf, or a PKI Sponsor on an NPE's behalf.

### 4.1.2 Enrollment Process and Responsibilities

The applicant and the CMA shall: establish and record identity per §3.2; record the basis for the
request; verify proof of possession per §3.2.1; and obtain the subscriber's acknowledgement of the
obligations in §9.6.3. Registration information shall be protected in transit and at rest to a
strength at least that of the key being certified.

## 4.2 Certificate Application Processing

### 4.2.1 Performing Identification and Authentication Functions

Per §3.2. The CPS shall state the division of these functions between CA and RA.

### 4.2.2 Approval or Rejection of Certificate Applications

An application shall be rejected where identity cannot be verified, the requested name violates
§3.1, the requester lacks authority, or the request would produce a certificate not conforming to
[profiles.md](profiles.md). **Every issued certificate shall be verified against the applicable
profile before release**; see §7.1.

### 4.2.3 Time to Process Certificate Applications

No stipulation. A service target, if published, belongs in the CPS rather than in this CP.

## 4.3 Certificate Issuance

### 4.3.1 CA Actions During Certificate Issuance

The CA shall verify the request's source and integrity, confirm the requested policy OIDs are within
those the CA's own certificate carries (§7.1), generate the certificate per the applicable profile,
log the issuance as an auditable event (§5.4.1), and publish per §2.

A CA shall **not** assert a policy OID in a subject certificate that its own certificate does not
carry. This is enforced in software, not only in procedure.

### 4.3.2 Notification to Subscriber by the CA of Issuance of Certificate

The CA shall notify the subscriber, or the PKI Sponsor, on issuance.

## 4.4 Certificate Acceptance

### 4.4.1 Conduct Constituting Certificate Acceptance

Downloading, installing or otherwise using the certificate, or failing to object within **7 days** of
notification.

### 4.4.2 Publication of the Certificate by the CA

Per §2.2.

### 4.4.3 Notification of Certificate Issuance by the CA to Other Entities

No stipulation.

## 4.5 Key Pair and Certificate Usage

### 4.5.1 Subscriber Private Key and Certificate Usage

Subscribers shall use private keys only for the purposes indicated by `keyUsage` and
`extendedKeyUsage`, protect them per §6.2 and §6.4, and request revocation immediately on suspected
compromise (§4.9.1).

### 4.5.2 Relying Party Public Key and Certificate Usage

A relying party shall, before relying on a certificate:

1. build and validate a certification path to a trust anchor per RFC 5280 §6;
2. check revocation status per §4.9.6, using a CRL or an approved OCSP responder;
3. confirm that the **surviving policy OID set** contains an OID acceptable for the intended use;
4. confirm `keyUsage` and `extendedKeyUsage` are consistent with that use.

A relying party that omits step 3 is not relying under this CP.

## 4.6 Certificate Renewal

### 4.6.1 Circumstance for Certificate Renewal

Renewal (a new certificate over the same public key) is **not supported**. Subscribers re-key
(§4.7). Retaining a key beyond its usage period defeats the purpose of a validity period.

### 4.6.2–4.6.7

Not applicable; renewal is not supported.

## 4.7 Certificate Re-Key

### 4.7.1 Circumstance for Certificate Re-Key

On expiry of the key usage period, on certificate expiry, on revocation for a reason other than key
compromise (with re-proofing per §3.3.2), or on a change to the cryptographic requirements of §6.1.5.

### 4.7.2 Who May Request Certification of a New Public Key

The subscriber, or the PKI Sponsor for an NPE.

### 4.7.3 Processing Certificate Re-Keying Requests

Per §3.3. A new key pair shall be generated; the prior key shall not be re-certified.

### 4.7.4–4.7.7

As for initial issuance: §4.3.2, §4.4.1, §4.4.2, §4.4.3 apply.

## 4.8 Certificate Modification

### 4.8.1 Circumstance for Certificate Modification

Where subscriber information in a certificate changes (legal name, affiliation, email address),
the certificate shall be **revoked and a new one issued**. Modification in place is not supported.
The unique identifier of §3.1.5 does not change.

### 4.8.2–4.8.7

Not applicable.

## 4.9 Certificate Revocation and Suspension

### 4.9.1 Circumstances for Revocation

A certificate shall be revoked when:

- the private key is compromised, or suspected compromised;
- the subscriber's affiliation ends, or authorization is withdrawn;
- information in the certificate becomes incorrect;
- the subscriber or sponsor requests it;
- the subscriber has failed to meet obligations under this CP;
- the issuing CA's certificate is revoked, or the CA ceases operation (§5.8);
- the cryptographic algorithm or key length is no longer adequate (§6.1.5).

### 4.9.2 Who Can Request Revocation

The subscriber; the PKI Sponsor; any RA or CA in a trusted role; the subscriber's management chain
or the Identity Source of Record; the PMA. The PMA shall designate at least one individual with
**unilateral** authority to revoke any certificate, reachable 24×7.

### 4.9.3 Procedure for Revocation Request

Requests are authenticated per §3.4, logged as auditable events, and acted on within the latency
budget of §4.9.7. A monitored 24×7 channel for compromise reports shall be published (§1.5.2).

### 4.9.4 Revocation Request Grace Period

None. Revocation requests are acted on immediately.

### 4.9.5 Time Within Which CA Must Process the Revocation Request

Per the compromise latency column of §4.9.7.

### 4.9.6 Revocation Checking Requirements for Relying Parties

A relying party shall check status by CRL or approved OCSP responder before relying on a certificate.
Certificate status obtained more than **24 hours** earlier shall not be used. Relying
parties shall use only OCSP responders approved under §4.9.9.

### 4.9.7 CRL Issuance Frequency

| CA class | Normal periodicity | Maximum latency on key or CA compromise |
|---|---|---|
| Root CA (offline) | at least every **28 days** | within **6 hours** of notification |
| Issuing CA | at least **once per day** | within **18 hours** of notification |
| Internal device CA | at least every **90 days** | within **18 hours** of notification |

CRLs are issued on schedule **even when nothing has changed**, so that a stale CRL is
distinguishable from a current one.

On revocation of any [ORG] CA, the PMA shall notify every cross-certified and approved external PKI
within the latency above. Federation creates an outbound notification duty, not merely an inbound
checking one.

### 4.9.8 Maximum Latency for CRLs

Published within **4 hours** of generation, and no later than the `nextUpdate` of the CRL being
superseded.

### 4.9.9 On-Line Revocation/Status Checking Availability

OCSP per RFC 6960 is the primary status mechanism; CRLs are published in all cases as a fallback and
for offline validation. OCSP responses shall be signed with strength at least that of the
certificates they cover. Only responders approved by the PMA are authoritative. OCSP stapling is
required of [ORG] TLS services.

### 4.9.10 On-Line Revocation Checking Requirements

Per §4.9.6.

### 4.9.11 Other Forms of Revocation Advertisements Available

No stipulation.

### 4.9.12 Special Requirements Related to Key Compromise

On suspected CA key compromise the PMA shall invoke §5.7.3. A certificate revoked for a reason other
than `keyCompromise` may have its reason escalated to `keyCompromise` on later evidence; the CA
product shall support this. Every CRL entry shall carry a `reasonCode`
([profiles.md §4](profiles.md)); a CRL that omits it cannot be triaged during an incident.

### 4.9.13 Circumstances for Suspension

**Suspension is not supported.** A client that has cached a CRL asserting `certificateHold` cannot
distinguish a restored certificate from a still-held one until its cache expires, and OCSP has no
"restored" transition. The remedy for a temporary withdrawal of trust is revocation and reissuance.

### 4.9.14–4.9.16

Not applicable; suspension is not supported.

## 4.10 Certificate Status Services

### 4.10.1 Operational Characteristics

Status is provided by CRL (§4.9.7) and OCSP (§4.9.9).

### 4.10.2 Service Availability

Status services shall be available 24×7. Availability of the status service is an availability
requirement of every relying application.

### 4.10.3 Optional Features

The [ORG] PKI does not support SCVP (RFC 5055). Where applications cannot validate paths
themselves, a path validation service may be provided; it is a trusted component and is subject to
the controls of §5.2 and §6; see [components.md §7 item 3](components.md).

## 4.11 End of Subscription

A subscriber ends subscription by allowing certificates to expire without re-key, or by requesting
revocation. Ending affiliation triggers revocation under §4.9.1.

## 4.12 Key Escrow and Recovery

### 4.12.1 Key Escrow and Recovery Policy and Practices

**CA private keys shall never be escrowed.** Private keys corresponding to certificates asserting
`digitalSignature` or `nonRepudiation` shall never be escrowed. Only **encryption** keys are
escrowed, and only to support recovery of encrypted data.

Where escrow is operated, the CA shall maintain a Key Recovery Policy and Key Recovery Practice
Statement, approved by the PMA, covering storage, request, extraction, delivery, protection and
destruction of recovered key material. Escrowed keys shall be protected at least as strongly as the
CA signing key.

**Third-party recovery requires authorization by a Key Recovery Agent** and shall be notified to the
subscriber unless the PMA determines that notification would prejudice a lawful investigation.

> **Two-person control on recovery is NOT claimed.** It was tested and the key
> recovery service does not enforce a multi-agent quorum: with the quorum set to two
> and two agents registered, a single approval released the request. Rather than have
> this CP assert a control the implementation does not provide, the requirement is
> withdrawn for recovery specifically. Recovery is authorized by **one** agent, and
> every request, approval and release is an auditable event (§5.4.1) reviewed under
> §5.4.2.
>
> Two-person control remains in force everywhere §6.2.2 states it: CA key generation,
> activation and backup, and access to disaster-recovery key backups. Those are
> enforced by ceremony, not by a product feature.
>
> **The compensating control is detection, not prevention.** A single agent can
> release an escrowed key; the audit record makes it visible afterwards. Organizations
> that need prevention must add it outside the product: dual custody of the agent
> credential, or an approval step in front of the recovery interface. Every recovery,
and every attempted recovery, is an auditable event (§5.4.1). Recovered keys shall be delivered over
a channel protected to at least the strength of the key, and destroyed by the requestor when no
longer required.

Escrow is the most concentrated confidentiality risk in this architecture. Its full cost is
enumerated in [components.md §7 item 5](components.md).

> **RESOLVED.** Escrowed encryption keys are archived for
> **10 years and 6 months after certificate expiry**, the same clock as the
> non-repudiation tier in §5.5.2, deliberately, so the program reasons about one
> retention period rather than two.
>
> The reasoning: an escrowed key is only useful for as long as the data encrypted
> to it may need recovery, and that data is generally under the organization's own
> retention obligation. Destroying the key early destroys the data irreversibly,
> and unlike a lost record it cannot be reconstructed from anywhere. Retaining it
> longer than the data it protects enlarges a breach for no benefit. Aligning to
> the longest record-retention tier is the defensible compromise.
>
> Only encryption keys are escrowed (§4.12.1). Archival requires server-side key
> generation, since a PKCS#10 request carries only the public key, so the
> subscriber does not generate their own encryption key. Wrapping is performed by
> the KRA using its RSA transport key; no bespoke key wrapping is implemented.
>
> **Destruction at end of retention is implemented** (2026-08-31):
> `./certauth keys destroy <keyID>` deletes the wrapped key material from the
> KRA repository and marks the record INVALID, keeping the record skeleton as
> §5.5.3 archive evidence. It refuses before retention expires unless forced
> (`FORCE_DESTROY=1`, for compromise or verified data destruction), verifies
> from both the directory and the KRA that the key is gone, and appends a
> dated record to the ceremony log. The retention clock is computed from the
> record's own archival date plus the certificate lifetime, auditable without
> any external source.

### 4.12.2 Session Key Encapsulation and Recovery Policy and Practices

No stipulation.

---

# 5. Facility, Management and Operational Controls

## 5.1 Physical Controls

### 5.1.1 Site Location and Construction

CA equipment shall be located in a facility that physically protects CA operations from unauthorized
access, damage and interference, with at least **four**
successive physical barriers between public space and the CA equipment.

### 5.1.2 Physical Access

**Offline root CA enclave.** Access requires **two persons in trusted roles**, simultaneously
present. The cryptographic module and its activation data shall be stored in **separate** containers,
each accessible to different individuals. Access shall be recorded on a sign-out sheet initialled by
both persons, and a security check performed on departure. When unattended for more than 24 hours,
intrusion detection shall be active, and a tamper check performed at least every 24 hours with a log
recording who performed it.

**Online CA enclave.** Access restricted to trusted roles, logged, and reviewed under §5.4.2.

### 5.1.3 Power and Air Conditioning

Sufficient backup power to permit an orderly shutdown without loss of the CA database or audit log.

### 5.1.4 Water Exposures

Moisture detection, and a contingency for fire suppression discharge.

### 5.1.5 Fire Prevention and Protection

Per applicable code.

### 5.1.6 Media Storage

Media holding CA private key backups, audit logs or archive data shall be stored to protect against
accidental damage and unauthorized access, and shall be inventoried.

### 5.1.7 Waste Disposal

Media holding sensitive material shall be destroyed such that recovery is infeasible. Destruction
shall be witnessed by two trusted roles and recorded.

### 5.1.8 Off-Site Backup

Backups of the CA database and audit log shall be stored off-site, protected to the standard of
§5.1.6, and restorable within the RTO of §5.7.4.

## 5.2 Procedural Controls

### 5.2.1 Trusted Roles

A trusted role is one whose incumbent can introduce security problems if the role is performed
improperly, whether accidentally or maliciously. The primary trusted roles are the **CA**, the
**RA** and the **OCSP Responder**. Each CMA shall additionally define:

| Role | Responsibilities |
|---|---|
| **System Administrator** | Installation and configuration; account creation; assignment of privileges and access control; creation of recovery media; backups, upgrades and recovery; network and host configuration |
| **Compliance Auditor** | Performance of the compliance audit (§8) |
| **ISSO** | Review of the security audit log; archive and deletion of audit and archive data per §5.4 and §5.5 |
| **PKI Sponsor** | Subscriber obligations for an NPE (§1.3.3) |

A CMA shall maintain a list of individuals holding each trusted role, with organization and contact
details, and produce it at compliance audit.

### 5.2.2 Number of Persons Required per Task

Two persons in trusted roles are required for: CA key generation; CA key activation; CA key backup;
access to disaster-recovery key backups; generation and delivery of a CA or OCSP certificate request;
and release of an escrowed key to a third party. See §6.2.2.

### 5.2.3 Identification and Authentication for Each Role

A person occupying a trusted role shall authenticate to PKI infrastructure using a valid certificate
issued under this CP. **Remote** administration of any CMA requires certificate authentication; no
other mechanism is acceptable.

The CPS shall describe how trusted-role credentials are bootstrapped before the PKI can issue them.

### 5.2.4 Roles Requiring Separation of Duties

1. No CMA shall perform its own compliance audit or security audit function.
2. The **Compliance Auditor** shall hold no other role on that CMA.
3. The **ISSO** shall hold no other role on that CMA.
4. An **RA** shall not hold System Administrator or ISSO duties on any system where it exercises RA
   authority.
5. **No individual shall hold more than one identity on any CA, RA or OCSP responder system.**
6. **CA, RA and OCSP responder software and hardware shall enforce these separations.** This is a
   product selection requirement, not a procedure. A CMA whose software cannot express mutually
   exclusive roles does not conform.

#### 5.2.4.1 Small-operator provision

Rules 1–6 define seven roles. A CMA operated by fewer people than it has roles cannot satisfy them
all, and a policy that pretends otherwise invites quiet non-compliance. Where the trusted-role
population is smaller than the role count, the following applies **instead of**, not in addition to,
strict disjointness:

| Separation | Status with a small team | Why |
|---|---|---|
| **Compliance Auditor holds no other role** | **Absolute; no exception.** The auditor shall be **external** to the CMA | Self-audit is not audit. This is the one separation that cannot be compensated for procedurally, and it is why §8.3 requires independence |
| **ISSO review is not self-review** | **Absolute.** The person who performed an action shall not be the sole reviewer of the log entry recording it. With three people this is a rotation, not a headcount problem | Preserves the actual point of §5.4.4: separating who may act from who may erase the record of acting |
| **No individual holds two identities on one system** | **Absolute.** Enforceable at any size | This is the rule that stops role overlap from becoming invisible |
| **Two-person control (§6.2.2)** | **Absolute.** Three appointees give a 2-of-3 quorum for every controlled operation | The control that most directly prevents unilateral key compromise |
| **RA not a System Administrator on a system where it exercises RA authority** | **May overlap**, if declared | Compensated by the two rules above: overlap is logged, and the log is reviewed by someone else |
| **System Administrator / CA / RA overlap** | **May overlap**, if declared | Same |

Any overlap permitted here shall be **named in the CPS**, listing which roles which individual holds,
and recorded in the Deprecated Practices Register as a declared divergence with the headcount that
would retire it. Overlap that is not declared is non-conformance, not a small-team exception.

**Minimum viable population: three appointees plus an external Compliance Auditor.** Below three, the
two-person-control quorum of §6.2.2 fails on any single absence, and the CMA cannot conform.

## 5.3 Personnel Controls

### 5.3.1 Qualifications, Experience and Clearance Requirements

Persons in trusted roles shall be selected for trustworthiness and integrity, and shall have
completed the background investigation of §5.3.2 **before** being granted access to trusted
functions.

**Vetting is proportionate to the operator population.** The DoD model conditions trusted roles on
US citizenship and a formal background investigation. That apparatus assumes thousands of operators
and an adversary who will invest in placing one. It is not proportionate to a PKI operated by a named
handful of people who are also its principals.

Trusted roles shall therefore be:

- **named individually** in the Trusted Role Register (§5.2.1), not filled by job title;
- **appointed in writing** by the PMA, with the appointment recorded and dated;
- subject to a **conflict-of-interest declaration** and to §5.3.6 sanctions;
- removed from the register, with credentials revoked, on departure or on loss of PMA confidence.

Formal background investigation is **not** required while the trusted-role population remains small
enough to be named individually and known personally to the PMA. Vetting rests instead on that direct
knowledge, on the appointment record, and on the procedural controls of §5.2.4 and §6.2.2.

> **This provision expires by its own terms.** When trusted roles are filled by people the PMA does
> not know personally (a hire, a contractor, an acquired team, or simply growth), the basis for this
> clause is gone. At that point the PMA shall adopt a documented background package (criminal history,
> employment and education verification, references, identity trace, sanctions screening, over a
> stated lookback) before any such person is appointed. Record the trigger, not just the intent.

### 5.3.2 Background Check Procedures

While §5.3.1's small-population provision applies: none, beyond the appointment record and
conflict-of-interest declaration. Once it expires: the adopted package, repeated at least every
**5 years** and on appointment to any additional trusted role.

### 5.3.3 Training Requirements

Training in this CP, the applicable CPS, the duties of the role, incident reporting, and the
operation of the systems used. Training shall be completed and recorded before independent
performance of the role.

### 5.3.4 Retraining Frequency and Requirements

On material change to this CP, the CPS or the systems, and at least annually.

### 5.3.5 Job Rotation Frequency and Sequence

No stipulation, except that rotation shall not defeat §5.2.4.

### 5.3.6 Sanctions for Unauthorized Actions

Unauthorized action by a person in a trusted role shall result in immediate suspension of access
pending investigation, and revocation of that person's trusted-role credentials.

### 5.3.7 Independent Contractor Requirements

Contractors in trusted roles are subject to every requirement of §5.2 and §5.3, established
contractually and auditable.

### 5.3.8 Documentation Supplied to Personnel

This CP, the applicable CPS, role procedures, and the incident response plan.

## 5.4 Audit Logging Procedures

### 5.4.1 Types of Events Recorded

At minimum, with date, time, actor identity and outcome:

- **Key lifecycle**: generation, backup, storage, recovery, archival, destruction; cryptographic
  module lifecycle and custody.
- **Certificate lifecycle**: application, identity proofing outcome, approval or rejection,
  issuance, re-key, revocation request and action, CRL generation and publication.
- **Escrow**: every escrow, every recovery request, every approval and denial, every release, and
  every failed attempt.
- **Security**: successful and failed authentication attempts to CMA systems; privilege changes;
  role assignments; access to the CA enclave; configuration and software changes; system startup and
  shutdown; audit log access and any attempt to modify or delete it; repository write attempts.
- **Ceremony**: the full record of every key ceremony, including participants and witnesses.

### 5.4.2 Frequency of Processing Log

The ISSO shall review the security audit log at least **monthly**, examining at least **25%** of
entries, and shall investigate every alert and anomaly. Reviews shall be recorded.

### 5.4.3 Retention Period for Audit Log

Audit logs shall be retained on the generating system for at least **two months** and thereafter in
the archive per §5.5.2.

### 5.4.4 Protection of Audit Log

Audit logs shall be protected against modification and deletion. **Only the ISSO** may archive or
delete audit data, and the ISSO holds no other role (§5.2.4). Separating "who may act" from "who may
erase the record of acting" is the point of the control.

### 5.4.5 Audit Log Backup Procedures

Backed up to off-site storage per §5.1.8 at least **weekly**.

### 5.4.6 Audit Collection System

Audit collection shall start on system startup and end on shutdown. **If audit collection fails, the
CA shall cease issuing certificates** until collection is restored. Issuance without an audit trail
is not issuance under this CP.

### 5.4.7 Notification to Event-Causing Subject

No stipulation.

### 5.4.8 Vulnerability Assessments

At least annually, and after material change.

## 5.5 Records Archival

### 5.5.1 Types of Records Archived

Certificate applications and their disposition; identity proofing evidence; issued certificates;
CRLs; audit logs; ceremony records and witness attestations; CP and CPS versions; compliance audit
reports; cross-certification agreements; escrow and recovery records; and correspondence of record.

### 5.5.2 Retention Period for Archive

| Class | Retention |
|---|---|
| Records relating to certificates asserting `nonRepudiation` | **10 years 6 months** after certificate expiry |
| All other archive records | **7 years** after certificate expiry or record creation |

The longer tier exists because a non-repudiation dispute may arise long after expiry, and an archive
that has aged out cannot settle it.

> `[DECIDE: counsel]` **Retention.** The periods above are defensible defaults, not legal advice.
> Confirm against your jurisdiction's statute of limitations and any sector obligation before
> approval. Too short destroys the evidentiary value of non-repudiation; too long enlarges a breach.
>
> **DEFERRED (2026-08-30).** Tabled by decision; this is organizational and
> legal work, not technical, and it does not block building or operating the
> system. It **does** block the CP being approved and therefore blocks issuing
> credentials anyone else is expected to rely on. Revisit before that point.

### 5.5.3 Protection of Archive

The archive shall be protected against modification, deletion and unauthorized reading, on
write-once media or an equivalent immutable store. Only the ISSO may delete archive data, and only
after retention has expired.

### 5.5.4 Archive Backup Procedures

Archives shall be replicated to a geographically separate location.

### 5.5.5 Requirements for Time-Stamping of Records

Archive records shall be time-stamped. Records whose evidentiary value must survive the expiry of the
signing certificate shall be time-stamped per RFC 3161 by a Time Stamp Authority whose certificate
conforms to [profiles.md §3.7](profiles.md).

### 5.5.6 Archive Collection System

May be internal or external; shall be described in the CPS.

### 5.5.7 Procedures to Obtain and Verify Archive Information

The CPS shall state who may request archive retrieval, how requests are authorized, and how the
integrity of retrieved records is verified. Retrieval shall be an auditable event.

## 5.6 Key Changeover

A CA shall cease issuing certificates at the point where the remaining validity of its own
certificate is shorter than the maximum validity of the certificates it issues. Beyond that point it
continues to issue CRLs until the last certificate it issued has expired.

CA key changeover is performed by generating a new key pair and certifying it, **not** by
re-certifying an existing key. Where a CA is retired, its successor is a **new CA** with a new name
and a new key ([architecture.md §3](architecture.md)); the retired CA's certificate is not reissued.

A trust anchor is identified by its key. A new algorithm therefore means a new root, and a new root
means a new distribution; see §6.1.5 and [architecture.md §11](architecture.md).

## 5.7 Compromise and Disaster Recovery

### 5.7.1 Incident and Compromise Handling Procedures

Each CMA shall maintain an incident response plan approved by the PMA, exercised at least annually.
On any incident affecting the integrity of issuance or the confidentiality of key material, the CMA
shall notify the PMA immediately and shall publish an incident notice, hosted independently of the
affected CA, stating: what happened; when; which certificates are affected; what action relying
parties must take; the current status; and a point of contact.

### 5.7.2 Computing Resources, Software and/or Data Are Corrupted

The CMA shall restore from backup (§5.1.8), verify integrity before resuming, and treat the
corruption as an auditable event pending a determination of whether key material was affected.

### 5.7.3 Entity Private Key Compromise Procedures

On compromise or suspected compromise of a CA private key:

1. The CA **immediately ceases issuance**.
2. The PMA is notified, and the superior CA revokes the CA's certificate within the latency of
   §4.9.7: **6 hours** for a root.
3. Every cross-certified and approved external PKI is notified within the same budget.
4. An incident notice is published per §5.7.1.
5. The **exposure set** (every certificate issued by the compromised CA) is reconstructed and
   revoked. The CA database and escrow database shall be structured so that this set is computable;
   a design in which it is not is non-conformant.
6. A replacement CA is established under §5.6 and its trust anchor distributed.

On compromise of a **root** key, the trust anchor itself must be replaced in every relying party.
Distribution lead time is the binding constraint, which is why §6.1.4 exists.

### 5.7.4 Business Continuity Capabilities After a Disaster

Each CA shall be restorable within a **Recovery Time Objective of 72 hours**, demonstrated by
exercise at least annually. The RTO shall be published to relying parties. Where escrow is operated,
a separate escrow RTO shall be committed and published.

## 5.8 CA or RA Termination

Termination is planned. Before ceasing operation a CA shall:

1. notify the PMA at least **90 days** in advance, and subscribers and relying parties at least
   **2 weeks** in advance;
2. cease issuing certificates on the announced date;
3. continue issuing CRLs until the last certificate it issued has expired, or revoke the entire
   population and issue a final CRL;
4. transfer its archive to the PMA or a designated custodian for the remainder of §5.5.2;
5. destroy its private keys under two-person control, witnessed and recorded;
6. have its certificate revoked by its superior CA.

An RA ceasing operation shall transfer its registration records and have its credentials revoked.

---

# 6. Technical Security Controls

## 6.1 Key Pair Generation and Installation

### 6.1.1 Key Pair Generation

**CA keys** shall be generated within a validated hardware cryptographic module (§6.2.1), in a
scripted, witnessed ceremony, under two-person control (§6.2.2), and recorded per §5.4.1.

**Subscriber signature and authentication keys** shall be generated on the subscriber's
cryptographic module and shall never exist outside it. This is what makes `nonRepudiation` meaningful.

**Subscriber encryption keys** subject to escrow are generated such that the private key can be
archived before delivery, and are wrapped for escrow at the moment of generation.

### 6.1.2 Private Key Delivery to Subscriber

Where the subscriber generates the key, no delivery occurs. Where the CA generates an escrowed
encryption key, it shall be delivered over a channel protected to at least the strength of the key,
and the CA shall retain no copy other than the escrowed one.

### 6.1.3 Public Key Delivery to Certificate Issuer

By PKCS#10 or CRMF, signed to prove possession per §3.2.1.

### 6.1.4 CA Public Key Delivery to Relying Parties

Root CA certificates shall be delivered to relying parties by an out-of-band mechanism whose
integrity does not depend on the PKI: managed device configuration, signed OS or application trust
store updates, or verified download with an out-of-band published fingerprint. **Trust anchor
distribution shall not depend on any certificate issued under this CP.**

The CPS shall name the distribution mechanism and state the expected lead time to reach the relying
party population. That lead time bounds every algorithm migration and every root compromise
recovery.

### 6.1.5 Key Sizes

Every certificate shall be signed with, and contain, a key at least as strong as required by the
highest-assurance policy OID it asserts:

| Policy OID | Signature | Subject key | Hash |
|---|---|---|---|
| `id-org-hardware-112` | `sha256WithRSAEncryption` | RSA 2048 | SHA-256 |
| `id-org-hardware-128`, `id-org-device-128` | `ecdsa-with-SHA256` | EC P-256 | SHA-256 |
| `id-org-hardware-192`, `id-org-admin` | `ecdsa-with-SHA384` | EC P-384 | SHA-384 |

CRLs shall be signed with the same algorithm, key size and hash as the certificates issued by the
same CA. **No RSA-2048 certificate, CRL or OCSP response shall be valid beyond 2030-12-31.** CA keys
shall be EC P-384 or stronger regardless of subscriber key type.

### 6.1.6 Public Key Parameters Generation and Quality Checking

Per the standard defining the algorithm. Weak or malformed public keys shall be rejected at issuance.

### 6.1.7 Key Usage Purposes

Per the `keyUsage` and `extendedKeyUsage` of [profiles.md](profiles.md). A key pair shall serve a
single purpose: **separate key pairs for authentication, signature and encryption**. Collapsing them
forfeits either non-repudiation or data recovery.

## 6.2 Private Key Protection and Cryptographic Module Engineering Controls

### 6.2.1 Cryptographic Module Standards and Controls

| | Subscriber | RA / CA | OCSP Responder |
|---|---|---|---|
| `id-org-medium-*` | FIPS 140-3 **Level 1** | **Level 2 hardware** | **Level 2 hardware** |
| `id-org-hardware-*` | **Level 2 hardware** | **Level 2 hardware** | **Level 2 hardware** |

All certificate signing shall be performed by a hardware module validated at **overall Level 2 with
Level 3 Physical Security**. Private asymmetric keys shall never appear in plaintext outside a
cryptographic module.

### 6.2.2 Private Key Multi-Person Control

Two persons in trusted roles are required for CA and OCSP key generation, activation and backup. One
shall be a System Administrator; the other shall be neither the ISSO nor the Compliance Auditor. Two-
person control also governs access to disaster-recovery key backups and generation and delivery of a
CA or OCSP certificate request.

Release of an escrowed key is **not** under two-person control; see §4.12.1. That is a deliberate,
tested exception, not an oversight. The roster used for
two-person control shall be maintained and produced at compliance audit.

### 6.2.3 Private Key Escrow

Per §4.12. CA private keys are never escrowed. Signature and non-repudiation keys are never escrowed.

### 6.2.4 Private Key Backup

CA private keys may be backed up only under two-person control, encrypted, on media stored per
§5.1.6. Subscriber signature keys shall never be backed up. Subscriber encryption keys are backed up
only through escrow (§4.12).

### 6.2.5 Private Key Archival

CA private keys shall not be archived. On CA termination they are destroyed (§5.8).

### 6.2.6 Private Key Transfer Into or From a Cryptographic Module

Keys shall be transferred only in encrypted form, between validated modules, under two-person
control. The wrapping mechanism shall be specified in the [ORG] Cryptographic Algorithm Standard.

### 6.2.7 Private Key Storage on Cryptographic Module

Encrypted, per the module's validated configuration.

### 6.2.8 Method of Activating Private Key

By the activation data of §6.4. NPE keys under `id-org-internal-device-128` may be activated without
activation data; this is the assurance carve-out that requires those certificates to be issued under
a separate root ([architecture.md §2](architecture.md)).

### 6.2.9 Method of Deactivating Private Key

Keys shall be deactivated on session end, idle timeout, or removal of the module.

### 6.2.10 Method of Destroying Private Key

Zeroization per the module's validated procedure, under two-person control for CA keys, witnessed
and recorded.

### 6.2.11 Cryptographic Module Rating

Per §6.2.1.

## 6.3 Other Aspects of Key Pair Management

### 6.3.1 Public Key Archival

Public keys are archived as part of the issued certificate (§5.5.1).

### 6.3.2 Certificate Operational Periods and Key Pair Usage Periods

| Certificate | Maximum validity |
|---|---|
| Root CA | 25 years |
| Issuing CA | 6 years |
| Cross-certificate | 3 years |
| OCSP responder (delegated) | 45 days (key ≤ 3 years) |
| Human credential (hardware) | 3 years |
| TLS server | 90 days |
| Workload | 24 hours |
| Code signing | 6 years (private key usage ≤ 13 months) |

Certificates containing an RSA-2048 key shall not be valid beyond **2030-12-31**, which caps human
credential validity from 2028-01-01 onward; see [profiles.md §1.2b](profiles.md).

## 6.4 Activation Data

### 6.4.1 Activation Data Generation and Installation

A passphrase, PIN, biometric or mechanism of equivalent robustness shall protect use of every private
key, except NPE keys under §6.2.8. PINs shall be at least 6 digits and randomly generated where
possible. Passphrases shall be at least 8 characters with interspersed digits, shall not resemble
dictionary words, names, sequences, repeated characters or date formats, and shall be technically
enforced where practicable.

### 6.4.2 Activation Data Protection

Activation data shall be memorized where possible. If written, it shall be protected to the level of
the data the key protects, and stored separately from the module. Activation data for a certificate
asserting an individual identity shall **never** be shared.

### 6.4.3 Other Aspects of Activation Data

A CMA shall change activation data whenever its module is returned for maintenance or re-key.

## 6.5 Computer Security Controls

### 6.5.1 Specific Computer Security Technical Requirements

CMA systems shall enforce authenticated logins, discretionary access control, role separation
(§5.2.4), security audit generation, self-test of security functions, trusted path for
authentication, and recovery from key and system failure. CMA systems shall be dedicated to PKI
functions and shall not run unrelated applications.

### 6.5.2 Computer Security Rating

No stipulation beyond §6.2.1 and §6.5.1.

## 6.6 Life Cycle Technical Controls

### 6.6.1 System Development Controls

CMA software shall be obtained from the vendor or built from verified source, with integrity
verified against a published hash or signature before installation, and installed on a hardened
platform. A configuration baseline shall be recorded and deviations detected.

### 6.6.2 Security Management Controls

Changes to CMA configuration or software shall follow change management, be approved, be recorded as
auditable events, and be tested in a pre-production environment first.

### 6.6.3 Life Cycle Security Controls

Cryptographic modules shall be procured through a controlled supply chain, their custody recorded
from receipt to destruction, and their provenance produced at compliance audit. Production modules
shall not be used for development or test.

## 6.7 Network Security Controls

Online CA equipment shall be protected by boundary controls permitting only the protocols required
for its function. **The offline root CA enclave shall have no network connection of any kind**;
material crosses that boundary only on removable media under the custody controls of §5.1.6 during a
ceremony.

## 6.8 Time-Stamping

CMA systems shall be synchronized to a trusted time source. Certificate and CRL times shall be
accurate to within **1 second**. Time-stamping of archive records is governed by §5.5.5.

---

# 7. Certificate, CRL and OCSP Profiles

## 7.1 Certificate Profile

Certificates shall conform to **[profiles.md](profiles.md)**, which is a controlled document approved
by the PMA and amended on its own cycle.

Two rules are stated here because they are policy, not formatting:

1. **Policy containment.** A CA shall not assert a policy OID in a subject certificate that its own
   certificate does not carry. Enforced in issuance software.
2. **Conformance verification.** Every issued certificate shall be verified against its profile
   before release. Verification shall be automated and shall **fail closed**. This exists because CA
   software has been observed to silently omit fields it cannot express, producing a certificate that
   is valid, chain-building, and non-conformant; see [architecture.md §13.3](architecture.md).

### 7.1.1–7.1.9

Per [profiles.md](profiles.md): version, extensions and criticality, algorithm OIDs, name forms, name
constraints, policy OIDs, policy constraints, policy qualifiers, and the processing semantics of the
critical `certificatePolicies` extension.

## 7.2 CRL Profile

Per [profiles.md §4](profiles.md). CRLs are **version 2**, carry a monotonically increasing
`cRLNumber` that is never reused or reset, and every entry carries a `reasonCode`.

## 7.3 OCSP Profile

Per RFC 6960 and [profiles.md §2.4](profiles.md). Responder certificates carry
`extendedKeyUsage = id-kp-OCSPSigning` marked critical with no other EKU, and `id-pkix-ocsp-nocheck`.

---

# 8. Compliance Audit and Other Assessments

## 8.1 Frequency or Circumstances of Assessment

Every CMA shall be audited **before commencing operation** and at least **annually** thereafter, and
after any material change to its operations or software.

## 8.2 Identity/Qualifications of Assessor

The auditor shall be independent of the CMA audited, competent in PKI and information security
audit, and shall hold no other role on that CMA (§5.2.4).

**Scheme.** Until the [ORG] PKI cross-certifies with any external PKI, compliance audit is conducted
against this CP and the CMA's CPS by an assessor meeting §8.3, without adopting an external scheme.

**Before the first cross-certificate is issued**, the PMA shall adopt a recognized scheme (WebTrust
for CA or ETSI EN 319 411), and the CMA shall have completed at least one audit under it. A partner
cannot assess our assurance from an internal audit, so deferring the scheme defers federation.

The evidence required by both schemes shall be produced **by construction** from the outset: the
audit logging of §5.4, the archive of §5.5, the ceremony records of §6.1.1, the trusted-role roster
of §5.2.1 and the two-person-control roster of §6.2.2. Retrofitting evidence is the expensive
failure mode this clause exists to prevent.

## 8.3 Assessor's Relationship to Assessed Entity

Independent. No financial or operational interest in the outcome.

## 8.4 Topics Covered by Assessment

Conformance of the CMA's practice to its CPS, and of its CPS to this CP: physical and personnel
controls, key management, issuance and revocation, audit logging and review, archive, escrow where
operated, business continuity, and profile conformance.

## 8.5 Actions Taken as a Result of Deficiency

The auditor reports findings to the PMA. The PMA determines remediation and its deadline. Pending
remediation, the PMA may restrict the CMA's issuance or, where the deficiency is material to
assurance, revoke its certificate under §4.9.1.

## 8.6 Communication of Results

Audit results are communicated to the PMA. A summary shall be made available to cross-certified
partners on request; a partner cannot assess our assurance without it.

---

# 9. Other Business and Legal Matters

## 9.1 Fees

`[DECIDE: or "No stipulation" for an internal PKI]`

## 9.2 Financial Responsibility

`[DECIDE: insurance or indemnity, if any. Note it interacts with §9.8]`

## 9.3 Confidentiality of Business Information

Identity proofing evidence, audit logs, archive records, escrowed key material, CA private keys,
security configuration and the unabridged CPS are confidential and shall not be disclosed except as
required by §9.4 or by law.

## 9.4 Privacy of Personal Information

Personal information collected for identity proofing shall be used only for the purposes of this CP,
protected per §9.3, retained no longer than §5.5.2 requires, and disclosed only to the subscriber, to
trusted roles with a need to know, to auditors under §8, or as required by law.

Subscribers shall be informed at enrollment what is collected, why, how long it is retained, and that
information in the certificate itself is not confidential.

> `[DECIDE]` **Privacy regime.** Identify the applicable regime (GDPR, state privacy law, sector
> rules) and reconcile it with §5.5.2's retention and with escrow. Retention mandated here may
> conflict with erasure rights; that conflict is resolved in law, not in this document, and needs
> counsel before approval.
>
> **DEFERRED (2026-08-30).** Tabled by decision; this is organizational and
> legal work, not technical, and it does not block building or operating the
> system. It **does** block the CP being approved and therefore blocks issuing
> credentials anyone else is expected to rely on. Revisit before that point.

## 9.5 Intellectual Property Rights

`[DECIDE]`

## 9.6 Representations and Warranties

### 9.6.1 CA Representations and Warranties

Each CA warrants that it operates in conformance with this CP and its approved CPS; that it issues
certificates only after the identification and authentication of §3; that it revokes within §4.9.7;
and that it publishes status information per §2.

### 9.6.2 RA Representations and Warranties

Each RA warrants that it performs identification and authentication per §3 and communicates requests
faithfully.

### 9.6.3 Subscriber Representations and Warranties

Each subscriber warrants that the information provided is accurate; that the private key is generated
and protected per §6; that the key is used only for its stated purposes; that revocation is requested
immediately on suspected compromise; and that use ceases on expiry or revocation.

### 9.6.4 Relying Party Representations and Warranties

Each relying party warrants that it performs the checks of §4.5.2 before relying, and that it
assesses whether the asserted policy OID is appropriate for its intended use.

### 9.6.5 Representations and Warranties of Other Participants

OCSP responders warrant that responses reflect current authoritative status. Time Stamp Authorities
warrant the accuracy of the time asserted.

## 9.7 Disclaimers of Warranties

`[DECIDE: counsel]`

## 9.8 Limitations of Liability

`[DECIDE: counsel]`

## 9.9 Indemnities

`[DECIDE: counsel]`

## 9.10 Term and Termination

### 9.10.1 Term

This CP takes effect on PMA approval and remains in force until superseded or withdrawn.

### 9.10.2 Termination

On withdrawal by the PMA, with notice to every CA operating under it.

### 9.10.3 Effect of Termination and Survival

Confidentiality (§9.3), privacy (§9.4) and archive retention (§5.5.2) survive termination.

## 9.11 Individual Notices and Communications Among Participants

`[DECIDE: the address of record and acceptable channels]`

## 9.12 Amendments

### 9.12.1 Procedure for Amendment

The PMA amends this CP. Proposed amendments are circulated to CA operators and affected stakeholders.

### 9.12.2 Notification Mechanism and Period

Amendments shall be published with a comment period of at least **one month** before taking effect.

**Expedited amendment.** Where an amendment addresses an active security deficiency, the PMA may
shorten or waive the comment period. The amendment takes effect on publication, and the PMA shall
record and publish: the deficiency, why the ordinary period was not survivable, and the date by which
the amendment will receive ordinary review. Every expedited amendment shall be re-reviewed at the
next scheduled PMA session.

This is the **only** relief mechanism in this CP (§1.5.5). It is deliberately public and applies to
every CA, so that relief cannot be granted quietly to one operator.

### 9.12.3 Circumstances Under Which OID Must Be Changed

Where an amendment materially changes the assurance associated with a policy OID, a **new OID shall
be assigned** and the existing one deprecated. An OID is never redefined (§1.2).

## 9.13 Dispute Resolution Provisions

`[DECIDE: counsel]`

## 9.14 Governing Law

`[DECIDE: counsel]`

## 9.15–9.16 Compliance with Applicable Law; Miscellaneous Provisions

`[DECIDE: counsel]`

## 9.17 Other Provisions

No stipulation.