╔══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╗ ║ SYS SPACE SERVICES PKI · CERTIFICATE POLICY · Node 1 ║ ╚══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╝
╔══════════════════════════════════════╗ ║ PKI · Node 1 ║ ╚══════════════════════════════════════╝
[ESC] Main menu · [1] Policy [2] Profiles [3] Architecture [4] Markdown
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
────────────────────────────────────────
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 ───────────────────────────────────────────────────
─────────── 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 Field-by-field certificate and CRL contents │ profiles.md Components, trust boundaries, flows, sequencing │ components.md How a specific CA meets this policy │ that CA's CPS
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
────────────────────────────────────────
─────────────────────────────────────────────────── 1. Introduction ────────────────────────────────────────────────────
─────────── 1. Introduction ────────────
───────────────────────────────────────────────────── 1.1 Overview ─────────────────────────────────────────────────────
───────────── 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. 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 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 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. 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 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.
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 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);
▪ 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 ─────────────────────────────────────────────
───── 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 ───────────────────────────────────────────────────
─────────── 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). 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 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. 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 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. 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. 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 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. 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 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 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 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 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 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 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); 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 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.
─────────────────────────────────────────────── 4.11 End of Subscription ───────────────────────────────────────────────
─────── 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 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.
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 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 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 │ Absolute; no exception. The auditor │ Self-audit is not audit. This is the role │ shall be external to the CMA │ 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 │ Preserves the actual point of §5.4.4: │ action shall not be the sole reviewer │ separating who may act from who may │ of the log entry recording it. With │ erase the record of acting │ three people this is a rotation, not │ │ a headcount problem │ No individual holds two identities on │ Absolute. Enforceable at any size │ This is the rule that stops role one system │ │ overlap from becoming invisible Two-person control (§6.2.2) │ Absolute. Three appointees give a │ The control that most directly │ 2-of-3 quorum for every controlled │ prevents unilateral key compromise │ operation │ RA not a System Administrator on a │ May overlap, if declared │ Compensated by the two rules above: system where it exercises RA │ │ overlap is logged, and the log is authority │ │ reviewed by someone else System Administrator / CA / RA │ May overlap, if declared │ Same overlap │ │
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 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 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 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.
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 ──────────────────────────────────────────────────
────────── 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); 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.
───────────────────────────────────────── 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 ───────────────────────────────────────────────
─────── 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. 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. 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).
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.
───────────────────────────────────────────────── 6.4 Activation Data ──────────────────────────────────────────────────
───────── 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 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 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 ─────────────────────────────────────────────
──── 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 ───────────────────────────────────────────────────
────────── 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 ────────────────────────────────────────────────
─────── 7.1 Certificate Profile ────────
Certificates shall conform to 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.
7.1.1–7.1.9
Per 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 ────────────────────────────────────────────────────
─────────── 7.2 CRL Profile ────────────
Per profiles.md §4. 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 ───────────────────────────────────────────────────
─────────── 7.3 OCSP Profile ───────────
Per RFC 6960 and profiles.md §2.4. 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 ───────────────────────────────────────────
─── 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 ─────────────────────────────────────────────
───── 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 ───────────────────────────────────────────────────────
─────────────── 9.1 Fees ───────────────
[DECIDE: or "No stipulation" for an internal PKI]
───────────────────────────────────────────── 9.2 Financial Responsibility ─────────────────────────────────────────────
───── 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 ───────────────────────────────────────────
─── 9.5 Intellectual Property Rights ───
[DECIDE]
────────────────────────────────────────── 9.6 Representations and Warranties ──────────────────────────────────────────
── 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 ─────────────────────────────────────────────
──── 9.7 Disclaimers of Warranties ─────
[DECIDE: counsel]
───────────────────────────────────────────── 9.8 Limitations of Liability ─────────────────────────────────────────────
───── 9.8 Limitations of Liability ─────
[DECIDE: counsel]
─────────────────────────────────────────────────── 9.9 Indemnities ────────────────────────────────────────────────────
─────────── 9.9 Indemnities ────────────
[DECIDE: counsel]
────────────────────────────────────────────── 9.10 Term and Termination ───────────────────────────────────────────────
────── 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 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 ──────────────────────────────────────────
── 9.13 Dispute Resolution Provisions ──
[DECIDE: counsel]
────────────────────────────────────────────────── 9.14 Governing Law ──────────────────────────────────────────────────
────────── 9.14 Governing Law ──────────
[DECIDE: counsel]
────────────────────────── 9.15–9.16 Compliance with Applicable Law; Miscellaneous Provisions ──────────────────────────
────────────────────────────────────────
[DECIDE: counsel]
──────────────────────────────────────────────── 9.17 Other Provisions ─────────────────────────────────────────────────
──────── 9.17 Other Provisions ─────────
No stipulation.
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
────────────────────────────────────────
[ESC] Main menu · [1] Policy [2] Profiles [3] Architecture [4] Markdown
╔══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╗ ║ (c) 2026 SYS SPACE SERVICES · certificate policy ║ ╚══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╝
──────────────────────────────────────── (c) 2026 SYS SPACE SERVICES certificate policy