PKI and Certificate Architecture: [Organisation or platform name]
Architecture for an organisation's public key infrastructure (PKI) and certificate lifecycle: certificate use
cases, trust model and CA hierarchy, CA roles, key ceremonies and HSMs, certificate profiles, issuance and ACME
automation, validity and renewal under the CA/Browser Forum schedule, revocation (CRL and OCSP), internal mTLS and
workload identity (SPIFFE), inventory and monitoring, compromise and recovery, crypto agility and post-quantum
readiness, and alignment with a certificate policy and certification practice statement (CP/CPS). Certificate and
CRL profiles follow RFC 5280. The CP/CPS outline follows RFC 3647. Public TLS rules follow the CA/Browser Forum
TLS Baseline Requirements, including Ballot SC-081v3 (maximum validity 200 days from 2026-03-15, 100 days from
2027-03-15, 47 days from 2029-03-15). Automation follows ACME (RFC 8555). Replace every [bracketed] value and
every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [PKI-ARC-001] |
| PKI name | [Name] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@pki-architect] |
| Policy authority | [Example: PKI policy board chaired by the CISO] |
| Approvers/reviewers | [@ciso], [@infrastructure-lead], [@platform-lead], [@internal-audit] |
| Public CAs used | [CA vendor or ACME service] |
| Private CA platform | [Product or managed service, HSM model and validation level] |
| Related CP/CPS | [Document IDs, or "not required" with reason] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
Approvals
| Role | Name | Decision | Date |
|---|
| PKI policy authority | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Decision] | YYYY-MM-DD |
| Infrastructure and platform | [@name] | [Decision] | YYYY-MM-DD |
| Internal audit (consulted) | [@name] | [Comments] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 0.2 | YYYY-MM-DD | [@name] | Example: Added 200/100/47-day renewal plan and ACME coverage targets |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved; new offline root ceremony scheduled |
Contents
1. Scope, drivers and principles
1.1 Scope
| In scope | Out of scope |
|---|
| Example: Public TLS for customer-facing domains | Customer-held certificates in B2B integrations (interface only) |
| Example: Private CA for internal TLS, mTLS, devices, smart cards | Personal email encryption keys held by users |
| Example: Code signing for internal software and container images | Third-party SaaS certificates managed by the vendor |
| [Item] | [Item] |
1.2 Drivers
| ID | Driver | Consequence for the design |
|---|
| PKD-001 (Example) | CA/Browser Forum Ballot SC-081v3 cuts public TLS lifetime to 200, then 100, then 47 days | Every public certificate must renew automatically; manual renewals end before 2027-03-15 |
| PKD-002 (Example) | Two production outages from expired internal certificates last year | Central inventory, expiry alerts and ownership |
| PKD-003 (Example) | Public CAs removing client authentication from public TLS certificates, following browser root program policy | mTLS client certificates move to the private CA |
| PKD-004 (Example) | Post-quantum migration guidance from national agencies | Algorithm inventory and agility plan (section 12) |
| [PKD-NNN] | [Driver] | [Consequence] |
1.3 Principles
| ID | Principle | Consequence |
|---|
| PKP-001 (Example) | Public trust only where the relying party is outside our control | Internal services never use public certificates |
| PKP-002 (Example) | One hierarchy per trust purpose | Separate issuing CAs for internal TLS, client and device, workload identity and code signing |
| PKP-003 (Example) | Automate issuance and renewal; humans approve policy, not certificates | ACME or platform-native issuance for at least 95% of certificates |
| PKP-004 (Example) | Short lifetimes instead of reliance on revocation | Internal workload certificates live hours to days |
| PKP-005 (Example) | Private keys never leave their protected boundary | CA keys in HSMs; workload keys generated on the workload |
| [PKP-NNN] | [Principle] | [Consequence] |
2. Certificate use cases
| ID | Use case | Relying party | Trust anchor | Typical lifetime | Volume per year |
|---|
| UC-001 (Example) | Public web and API TLS | Browsers, customer systems | Public CA in browser root stores | Public maximum (section 7.1) | 1,200 |
| UC-002 (Example) | Internal service TLS | Internal clients | Private root distributed to managed devices and images | 30 days | 40,000 |
| UC-003 (Example) | Service-to-service mTLS | Service mesh sidecars | Mesh or SPIFFE trust bundle | 1 to 24 hours | Millions (automated) |
| UC-004 (Example) | Partner B2B mTLS | Partner gateways | Private client CA, pinned by partner | 1 year (partner limit) | 150 |
| UC-005 (Example) | Device identity (laptops, mobiles, IoT) | Network access control, VPN, IdP | Private device CA | 1 year, renewed automatically | 15,000 |
| UC-006 (Example) | Smart card or derived credential for staff | IdP, Windows sign-in | Private user CA | 3 years | 3,000 |
| UC-007 (Example) | Code and container signing | Build pipeline verifiers, endpoints | Private code-signing CA or a public code-signing CA for distributed software | Private CA: 1 to 3 years; public code-signing CA: at most 460 days (CA/B Forum Code Signing Baseline Requirements, for certificates issued from 2026-03-01); timestamp every signature | 50 |
| UC-008 (Example) | Email signing and encryption (S/MIME) | Mail clients | Public S/MIME CA under the CA/B Forum S/MIME requirements | Per S/MIME rules | 500 |
| [UC-NNN] | [Use case] | [Relying party] | [Anchor] | [Lifetime] | [Volume] |
3. Trust model and CA hierarchy
3.1 Hierarchy
The private hierarchy has an offline root and purpose-specific issuing CAs; public certificates come from external CAs and never chain to the private root.
3.2 CA register
| CA | Type | Key algorithm | Validity | Online or offline | Constraints | Owner |
|---|
| Private root (Example) | Root | ECDSA P-384 | 20 years | Offline, powered on only for ceremonies | None | PKI policy authority |
| Internal TLS issuing CA (Example) | Subordinate | ECDSA P-256 | 5 years | Online, HSM | Name constraints to corp.example and internal.example; serverAuth EKU only | PKI team |
| Client and device issuing CA (Example) | Subordinate | ECDSA P-256 | 5 years | Online, HSM | clientAuth EKU only | PKI team |
| Workload identity intermediate (Example) | Subordinate | ECDSA P-256 | 2 years | Online, HSM or cloud KMS | URI SAN constraint to approved SPIFFE trust domains; serverAuth and clientAuth EKUs | Platform team with PKI oversight |
| Code-signing issuing CA (Example) | Subordinate | RSA 3072 | 5 years | Online, HSM with dual control for issuance | codeSigning EKU only | PKI team and release engineering |
| [CA] | [Type] | [Algorithm] | [Validity] | [Mode] | [Constraints] | [Owner] |
3.3 Trust distribution
| Trust store | How the private root is distributed | Owner |
|---|
| Managed laptops and servers (Example) | Device management and configuration management baseline | Endpoint team |
| Container base images (Example) | Added at image build; images rebuilt on root change | Platform team |
| Language runtimes with their own stores (Java, Python, Node) (Example) | Image build step that adds the root to each runtime store | Platform team |
| Partner systems (Example) | Root and client issuing CA certificate shared out of band, fingerprint confirmed by phone | Integration owner |
| [Store] | [Method] | [Owner] |
4. CA roles, key ceremonies and HSMs
4.1 Trusted roles
| Role | Responsibilities | Separation rule |
|---|
| Policy authority (Example) | Approves CP, profiles, new CAs, exceptions | Not a CA operator |
| CA administrator (Example) | Configures CA software, templates and profiles | Cannot approve own changes |
| CA operator or registration officer (Example) | Approves non-automated requests (code signing, partner mTLS) | Cannot administer CA configuration |
| HSM custodian (Example) | Holds one share of HSM activation credentials | M of N, for example 3 of 5; custodians in at least two locations |
| Auditor (Example) | Reviews logs and ceremony records | Read-only; independent of PKI team |
| [Role] | [Responsibilities] | [Rule] |
4.2 Key ceremony requirements
- Script every ceremony in advance, run it with at least [Example: two custodians, one witness and one auditor], record it on video where policy requires, and keep signed minutes.
- Generate CA keys inside the HSM; never import a CA key generated elsewhere.
- Back up the root key only as HSM-encrypted backups split across custodians and stored in [two] secure sites.
- Keep the offline root powered off and in a safe between ceremonies; plan ceremonies for issuing CA renewals and CRL signing (section 8.2).
4.3 HSM and key storage
| Item | Design |
|---|
| HSM validation (Example) | FIPS 140-3 Level 3 validated modules for root and issuing CAs (check the NIST CMVP certificate for the exact firmware) |
| Cloud option (Example) | Managed private CA service backed by provider HSMs for issuing CAs; root stays on premises |
| Key usage logging (Example) | Every sign operation logged to SIEM; alerts on signing outside the CA service account |
| Key lifetimes (Example) | Set per SP 800-57 Part 1 Rev. 5 cryptoperiod guidance and the CA validity in section 3.2 |
| [Item] | [Design] |
5. Certificate profiles
| Profile ID | Use case | Key | Validity | Key usage | Extended key usage | Subject and SAN rules | Status pointers |
|---|
| PRF-001 (Example) | UC-001 public TLS | ECDSA P-256 or RSA 2048+ | Public maximum | digitalSignature (keyEncipherment also permitted for RSA keys) | serverAuth | DNS SANs only; no internal names | CRL distribution point from the public CA |
| PRF-002 (Example) | UC-002 internal TLS | ECDSA P-256 | 30 days | digitalSignature | serverAuth | Internal DNS SANs within name constraints | CRL; OCSP not provided |
| PRF-003 (Example) | UC-003 workload mTLS | ECDSA P-256 | 1 hour | digitalSignature | serverAuth, clientAuth | URI SAN with SPIFFE ID, for example spiffe://prod.example/ns/payments/sa/api | None (short-lived) |
| PRF-004 (Example) | UC-005 device | ECDSA P-256 in TPM or secure enclave | 1 year | digitalSignature | clientAuth | Device ID in SAN; no user names | CRL |
| PRF-005 (Example) | UC-007 code signing, private CA | RSA 3072 in HSM | 3 years (a public code-signing certificate is limited to 460 days) | digitalSignature | codeSigning | Organisation name | CRL; timestamp each signature |
| [PRF-NNN] | [Use case] | [Key] | [Validity] | [KU] | [EKU] | [Rules] | [Pointers] |
Profile rules for every profile: unique serial numbers with at least 64 bits of randomness where the CA/B Forum requirements apply, Basic Constraints set correctly, Authority and Subject Key Identifiers present, and no deprecated algorithms (SHA-1, RSA under 2048). The TLS Baseline Requirements restrict public TLS keys to RSA of at least 2048 bits and ECDSA on P-256, P-384 or P-521.
6. Issuance, validation and automation
6.1 Issuance channels
| Profile | Channel | Validation | Approval |
|---|
| PRF-001 (Example) | ACME (RFC 8555) client on load balancers and ingress controllers; DNS-01 through DNS provider API | Domain control validation by the public CA | Automatic within CAA policy |
| PRF-002 (Example) | Internal ACME service or Kubernetes certificate controller | Requester's workload identity and namespace policy | Automatic |
| PRF-003 (Example) | SPIFFE Workload API (section 9) | Node and workload attestation | Automatic |
| PRF-004 (Example) | EST (RFC 7030) or SCEP through device management | Device enrolment record | Automatic for managed devices |
| PRF-005 (Example) | Signing service in the pipeline; key never leaves HSM | Pipeline identity plus release approval | Two-person approval |
| [Profile] | [Channel] | [Validation] | [Approval] |
6.2 Public CA controls
- Publish DNS CAA records (RFC 8659) that name only the approved public CAs, and, where the CA supports it, restrict issuance to your ACME account.
- Keep ACME account keys in a secrets manager, one account per environment, rotated on staff change.
- Plan for domain validation reuse periods that shrink with SC-081v3 (section 7.1): automate DNS-01 or HTTP-01 so revalidation needs no human.
- Use at least two public CAs, configured and tested, so a CA outage or distrust event does not stop renewals.
7. Validity, renewal and rotation
7.1 Public TLS schedule (CA/Browser Forum Ballot SC-081v3)
| Certificates issued on or after | Maximum validity | Maximum reuse of domain or IP validation | Design consequence (Example) |
|---|
| 2026-03-15 | 200 days | 200 days | Renew every 4 months at most; already in force |
| 2027-03-15 | 100 days | 100 days | Renew about every 2 months; manual processes no longer viable |
| 2029-03-15 | 47 days | 10 days | Renew about monthly; domain validation effectively per issuance, so DNS automation is mandatory |
The ballot also limits reuse of validated subject identity information (organisation details) to 398 days from 2026-03-15. Certificates issued before each date keep their original term. Check the current TLS Baseline Requirements (section 6.3.2 for validity, section 4.2.1 for reuse) at cabforum.org before relying on these values.
7.2 Renewal policy
| Profile | Renew when remaining life is below | Retry and alert | Rotation of key |
|---|
| PRF-001 (Example) | One third of lifetime, or as directed by the CA through ACME Renewal Information (ARI, RFC 9773) | Retry hourly; alert owner at half the renewal window; page at 7 days | New key every renewal |
| PRF-002 (Example) | One third of lifetime | Platform alert at 7 days | New key every renewal |
| PRF-003 (Example) | Half of lifetime | Workload API pushes new SVID | New key every renewal |
| PRF-004 (Example) | 30 days | Device management compliance report | New key in TPM |
| [Profile] | [Threshold] | [Alert] | [Rotation] |
7.3 Hard-coded trust and pinning
List every system that pins a certificate or a public key, because shorter lifetimes break pinning. Replace leaf pinning with trust-anchor configuration or pin to the issuing CA with a documented backup pin.
8. Revocation and status checking
8.1 Status mechanisms
The CA/Browser Forum made OCSP optional and CRLs mandatory for publicly trusted TLS CAs (Ballot SC063, effective March 2024), and some public CAs have stopped OCSP; Let's Encrypt ended its OCSP service on 2025-08-06. Design public TLS on CRLs and short lifetimes. For the private PKI, choose per use case:
| Use case | Mechanism | Publication or freshness | Behaviour when unavailable |
|---|
| Public TLS (Example) | CRL from the public CA; browsers use their own revocation sets | Per Baseline Requirements | Browser-controlled |
| Internal TLS (Example) | CRL from the issuing CA, published to two HTTP locations | Every [24] hours; immediately on key-compromise revocation | Fail open for 24 hours, then fail closed on critical systems |
| Workload mTLS (Example) | None: lifetime of 1 hour is the revocation control; remove the workload's registration entry to stop renewal | Not applicable | Not applicable |
| Device and VPN (Example) | CRL checked by VPN and network access control; OCSP responder if the access product requires it | Every [4] hours | Fail closed |
| Code signing (Example) | CRL with timestamp-aware validation | Every [24] hours | Fail closed for install-time checks |
| [Use case] | [Mechanism] | [Freshness] | [Behaviour] |
8.2 Revocation process
| Reason | Who may request | Target time to revoke | Evidence |
|---|
| Private key compromise (Example) | Owner, security operations, PKI team | 4 hours internal; public CAs must act within 24 hours under the Baseline Requirements | Incident ticket |
| Workload decommissioned (Example) | Owner or automation | 1 business day | Change record |
| Misissuance (Example) | PKI team | 24 hours | Investigation record |
| [Reason] | [Requester] | [Time] | [Evidence] |
The offline root signs its CRL at each ceremony; set its next-update interval long enough (Example: 12 months) to reach the next scheduled ceremony with margin.
9. Internal mTLS and workload identity
| Topic | Design |
|---|
| Identity format (Example) | SPIFFE ID per workload: spiffe://<trust-domain>/ns/<namespace>/sa/<service-account> (one trust domain per environment, so the environment is not repeated in the path), for example spiffe://prod.example/ns/payments/sa/api as in PRF-003 |
| Issuer (Example) | SPIRE server per trust domain (SPIFFE and SPIRE are CNCF graduated projects); mesh control plane consumes SPIRE or uses its built-in CA, chained to a dedicated workload intermediate under the private root (not to the serverAuth-only internal TLS CA, whose EKU and name constraints do not fit workload SVIDs) |
| Attestation (Example) | Node attestation by cloud instance identity or Kubernetes service account token; workload attestation by namespace, service account and image digest |
| Document types (Example) | X.509-SVID for mTLS; JWT-SVID only where a proxy breaks TLS, with short expiry and audience |
| Trust bundles and federation (Example) | One trust domain per environment; federation between production clusters in different clouds through SPIFFE bundle endpoints |
| Authorisation (Example) | mTLS proves identity; an authorisation policy decides which SPIFFE IDs may call which service (see system-design/design-authorization-service) |
| Cloud federation (Example) | Exchange JWT-SVIDs for cloud credentials through workload identity federation, removing static cloud keys |
| [Topic] | [Design] |
The IAM Solution Design (security/iam-solution-design, section 11) owns the policy for non-human identities; this section owns the certificate mechanics.
10. Inventory, discovery and monitoring
10.1 Inventory fields
| Field | Source | Notes |
|---|
| Subject, SANs, serial, issuer, validity (Example) | CA records, network scans, cloud certificate services | Reconcile daily |
| Key algorithm and size (Example) | Same | Feeds section 12 |
| Owner team and service (Example) | Service catalogue tag on the deploying resource | Required at issuance |
| Deployment locations (Example) | Load balancers, ingress, hosts, appliances | One certificate in many places is a risk flag |
| Issuance channel and auto-renewal status (Example) | ACME client, controller, manual | Manual certificates tracked to zero |
| [Field] | [Source] | [Notes] |
10.2 Monitoring
| ID | Monitor | Threshold | Action |
|---|
| MON-001 (Example) | Expiry of any production certificate | 14 days (7 for public TLS once at 47 days) | Page owner |
| MON-002 (Example) | Certificate Transparency logs for our domains (RFC 6962, CT v2 in RFC 9162) | Any certificate from a CA not in CAA, or unknown SAN | Security investigation |
| MON-003 (Example) | Renewal failures in ACME clients and controllers | Two consecutive failures | Ticket to owner |
| MON-004 (Example) | CRL publication freshness | Older than next-update minus 6 hours | Page PKI on call |
| MON-005 (Example) | HSM health and sign errors | Any error | Page PKI on call |
| [MON-NNN] | [Monitor] | [Threshold] | [Action] |
11. Compromise, incident and recovery
| Scenario | Impact | Response | Target recovery |
|---|
| Leaf key compromise (Example) | One service | Revoke, reissue with new key, investigate | 4 hours |
| Issuing CA key compromise (Example) | All certificates under that CA | Revoke issuing CA at root ceremony; stand up a new issuing CA from pre-staged ceremony script; mass reissue through automation | 48 hours for automated profiles |
| Root key compromise (Example) | Entire private PKI | Build new root; redistribute trust; reissue everything; remove old root from all stores | [Weeks]; rehearse annually |
| Public CA distrusted by browsers (Example) | All public certificates from that CA | Switch ACME configuration to secondary CA (section 6.2); reissue | Before distrust date |
| Mass revocation by a public CA after misissuance (Example) | Many public certificates within days | Reissue through ACME; ARI signals early renewal | Within the CA's revocation window |
| [Scenario] | [Impact] | [Response] | [Target] |
Link the scenarios to the Incident Response Plan (compliance/incident-response-plan) and the Disaster Recovery Plan (ops/disaster-recovery-plan), including HSM backup restore.
12. Crypto agility and post-quantum readiness
- Keep algorithms in configuration, not code: profiles, ACME clients and libraries must switch algorithm without a release where possible.
- Maintain the algorithm inventory from section 10 and rank systems by how long their data or signatures must stay trustworthy.
- Track NIST post-quantum standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), published August 2024. NIST IR 8547, an initial public draft (November 2024) at the time of writing, sets out a proposed transition timeline for quantum-vulnerable algorithms; check its current status at csrc.nist.gov.
- Prioritise key establishment first (hybrid post-quantum key exchange in TLS, which protects against harvest-now-decrypt-later), then signatures where long-lived trust is needed (roots, code signing, firmware).
- Public TLS certificates can use only the algorithms the Baseline Requirements allow; follow browser root program announcements for post-quantum certificates rather than issuing them ahead of support.
| ID | System | Current algorithm | Constraint | Target | Date |
|---|
| PQC-001 (Example) | Private root and issuing CAs | ECDSA P-384 / P-256 | HSM firmware support for ML-DSA | Parallel ML-DSA hierarchy for pilot | YYYY-MM-DD |
| PQC-002 (Example) | Internal TLS key exchange | X25519 | Library versions | Hybrid key exchange enabled | YYYY-MM-DD |
| [PQC-NNN] | [System] | [Current] | [Constraint] | [Target] | YYYY-MM-DD |
13. Operations, roles and metrics
13.1 RACI
| Activity | PKI team | Platform team | Service owners | Security operations | Policy authority |
|---|
| Profile and CA changes (Example) | R | C | I | C | A |
| Automated issuance and renewal (Example) | A | R | I | I | I |
| Certificate ownership and deployment (Example) | C | C | A, R | I | I |
| Revocation on compromise (Example) | R | C | C | A | I |
| CT and expiry monitoring (Example) | A | R | I | R | I |
| Key ceremonies (Example) | R | I | I | C | A |
13.2 Metrics
| ID | Metric | Target |
|---|
| PKM-001 (Example) | Certificates issued through automation | 95% (public TLS 100% before 2027-03-15) |
| PKM-002 (Example) | Production incidents caused by expiry | Zero per quarter |
| PKM-003 (Example) | Certificates without owner in inventory | Zero |
| PKM-004 (Example) | Median time to issue an internal TLS certificate | Under 5 minutes |
| PKM-005 (Example) | Time to reissue all certificates under one issuing CA (rehearsal) | Under 48 hours |
| [PKM-NNN] | [Metric] | [Target] |
14. CP/CPS alignment
RFC 3647 defines a nine-part outline for certificate policies and certification practice statements. Map each part to this design and to the operational documents that hold the detail.
| RFC 3647 part | Topic (paraphrased) | Where it is covered |
|---|
| 1 | Introduction: PKI participants, certificate usage, policy administration | Sections 1, 2, 4.1 |
| 2 | Publication and repository responsibilities | Section 8.1 (CRL locations), 3.3 (trust distribution) |
| 3 | Identification and authentication of subscribers | Section 6.1 (validation per profile) |
| 4 | Certificate life-cycle operational requirements | Sections 6, 7, 8 |
| 5 | Facility, management and operational controls | Sections 4, 13; site security documents |
| 6 | Technical security controls (keys, HSMs, cryptographic modules) | Sections 4.3, 5, 12 |
| 7 | Certificate, CRL and OCSP profiles | Section 5, 8.1 |
| 8 | Compliance audit and other assessments | [Internal audit plan; public CA audit reports for external CAs] |
| 9 | Other business and legal matters | [Legal and contract documents] |
15. Roadmap, risks and acceptance
15.1 Roadmap
| Phase | Scope | Exit criteria | Target date |
|---|
| 1: Inventory (Example) | Discovery across networks, clouds and CAs; owners assigned | 100% of production certificates owned | YYYY-MM-DD |
| 2: Public automation (Example) | ACME for every public endpoint; second CA configured; CAA records | No manual public renewals | Before 2027-03-15 |
| 3: Private PKI rebuild (Example) | New offline root, purpose-specific issuing CAs, internal ACME | Old internal CA retired | YYYY-MM-DD |
| 4: Workload identity (Example) | SPIFFE issuer in production clusters | 90% of service calls on mTLS | YYYY-MM-DD |
| 5: Agility and PQC pilot (Example) | Hybrid key exchange; ML-DSA pilot hierarchy | Pilot report approved | YYYY-MM-DD |
15.2 Risks
| ID | Risk | Mitigation | Owner |
|---|
| RSK-001 (Example) | Appliances that cannot run ACME | Vendor automation API, front with automated load balancer, or replace | [@infrastructure-lead] |
| RSK-002 (Example) | Partner systems pin our certificates | Move pins to CA level; notify partners 90 days ahead | [@integration-lead] |
| RSK-003 (Example) | HSM custodian unavailable for emergency ceremony | 3 of 5 quorum across two sites; deputies trained | [@pki-architect] |
| [RSK-NNN] | [Risk] | [Mitigation] | [@owner] |
15.3 Acceptance criteria
| Req ID | Requirement | Verification | Acceptance criterion |
|---|
| PKI-REQ-001 (Example) | Public certificates renew without humans | Inventory report and ACME logs | 100% of public certificates issued by ACME in the last 90 days |
| PKI-REQ-002 (Example) | Expiry never causes an outage | Incident records | No expiry incidents for two quarters |
| PKI-REQ-003 (Example) | Issuing CA compromise is recoverable | Rehearsal | All automated profiles reissued under a new CA in under 48 hours |
| PKI-REQ-004 (Example) | Only approved CAs issue for our domains | CAA check and CT monitoring | CAA present on all zones; no unexplained CT entries |
| [PKI-REQ-NNN] | [Requirement] | [Method] | [Criterion] |
16. Glossary and references
16.1 Glossary
| Term | Meaning |
|---|
| CA | Certification authority that signs certificates |
| CP, CPS | Certificate policy (what is required) and certification practice statement (how a CA meets it) |
| ACME | Automatic Certificate Management Environment protocol (RFC 8555) |
| ARI | ACME Renewal Information, which lets a CA suggest when to renew (RFC 9773) |
| CAA | DNS record naming the CAs allowed to issue for a domain (RFC 8659) |
| CRL, OCSP | Certificate revocation list; Online Certificate Status Protocol |
| CT | Certificate Transparency, public append-only logs of issued certificates |
| HSM | Hardware security module that protects private keys |
| SVID | SPIFFE Verifiable Identity Document (X.509 or JWT) |
| DCV | Domain control validation |
| ML-KEM, ML-DSA, SLH-DSA | NIST post-quantum key encapsulation and signature algorithms (FIPS 203, 204, 205) |
16.2 References
| Reference | Version or date | Use |
|---|
| RFC 5280, Internet X.509 PKI Certificate and CRL Profile | May 2008, with updating RFCs | Certificate and CRL profiles |
| RFC 3647, Certificate Policy and Certification Practices Framework | November 2003 (Informational) | CP/CPS outline |
| CA/Browser Forum, TLS Baseline Requirements, cabforum.org | Version 2.3.1 (checked 2026-10-23) | Validity, reuse, revocation, key rules |
| CA/Browser Forum Ballot SC-081v3 | Adopted April 2025 | 200, 100 and 47-day schedule |
| CA/Browser Forum Ballot SC063 | Effective March 2024 | OCSP optional, CRLs required |
| CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates (section 6.3.2, Ballot CSC-31) | Version 3.11.0 (checked 2026-10-23) | 460-day maximum for public code-signing certificates from 2026-03-01 |
| Let's Encrypt, "OCSP service has reached end of life" | 2025-08-06 | Industry move to CRLs |
| RFC 8555 (ACME), RFC 9773 (ARI), RFC 7030 (EST), RFC 8659 (CAA) | 2019, 2025, 2013, 2019 | Automation and issuance control |
| RFC 6962 and RFC 9162, Certificate Transparency | 2013, 2021 (both Experimental) | CT monitoring |
| SPIFFE specifications, spiffe.io; SPIRE | Current; CNCF graduated 2022 | Workload identity |
| FIPS 140-3, Security Requirements for Cryptographic Modules | March 2019 | HSM validation |
| NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management | May 2020 | Cryptoperiods |
| FIPS 203, 204, 205; NIST IR 8547 (initial public draft) | August 2024; November 2024 | Post-quantum planning |
| [Internal CP/CPS] | [Version] | [Use] |
Standard and licence note
Based on RFC 5280, RFC 3647, RFC 8555, RFC 9773, RFC 7030, RFC 8659, RFC 6962 and RFC 9162 (IETF), the CA/Browser Forum TLS Baseline Requirements and Ballots SC-081v3 and SC063, the CA/Browser Forum Code Signing Baseline Requirements, the SPIFFE specifications, and NIST FIPS 140-3, SP 800-57 Part 1 Rev. 5 and FIPS 203, 204 and 205 (works of the US Government). The RFC 3647 outline is listed by part number with paraphrased topics; no specification or requirement text is reproduced. This template is original text written for this collection. Product names belong to their owners. Public CA and browser root program rules change several times a year: check the current Baseline Requirements and root program policies at the official sites before use. Template licence: MIT.