Standards index: the rules behind every chapter

Public key infrastructure is held together by documents. The IETF defines the formats and protocols, the CA/Browser Forum and the browsers’ root programs set the rules for publicly trusted CAs, NIST standardises the algorithms, and EU law gives some signatures and certificates legal weight. This page lists the ones the handbook relies on, grouped by topic, with links to the official text.

Two tips for reading them:

RFCs never change once published. A newer RFC “obsoletes” or “updates” an older one, and the header of each RFC on rfc-editor.org says which. Always check you are reading the current one.
Industry requirements change often. The CA/Browser Forum and the root programs publish new versions several times a year. The links below go to the page that always shows the latest version.

Certificates and PKI structure

Standard	What it covers	Chapters
ITU-T X.509	The original framework for public-key certificates and attribute certificates, which the internet profile builds on	X.509 certificates
RFC 5280: Internet X.509 PKI Certificate and CRL Profile	The internet profile of X.509 (RFC 5280, May 2008): certificate fields and extensions, CRLs and the path validation algorithm	X.509 certificates, names and key usage, chains, revocation
RFC 2986: PKCS #10	The certificate signing request format (RFC 2986 (PKCS #10))	The CSR
RFC 3647: Certificate Policy and Certification Practices Framework	The standard outline for a CA’s certificate policy (CP) and certification practice statement (CPS)	Private CA
RFC 5652: Cryptographic Message Syntax (CMS)	The signed and encrypted container format behind PKCS #7, S/MIME, Authenticode and timestamps	Code signing, file formats
RFC 7468: Textual Encodings of PKIX, PKCS and CMS Structures	PEM files and their `BEGIN` labels	File formats
RFC 7292: PKCS #12 v1.1	Password-protected bundles of a private key and its certificates (PFX)	File formats
RFC 5958: Asymmetric Key Packages	The private key format that succeeded PKCS #8 (RFC 5208)	File formats
RFC 8017: PKCS #1 v2.2	RSA encryption and signature schemes, including RSA-PSS	Key pairs, digital signatures
RFC 9881, RFC 9909, RFC 9935	How ML-DSA, SLH-DSA and ML-KEM keys and signatures appear in X.509 certificates (ML-DSA: RFC 9881, October 2025)	Post-quantum

TLS and names

Standard	What it covers	Chapters
RFC 9846: TLS 1.3	The current TLS 1.3 specification: the handshake, key schedule and client authentication. Published July 2026 (replaces RFC 8446).	TLS handshake, mutual TLS
RFC 8446: TLS 1.3 (first edition)	The original TLS 1.3 text (August 2018), still widely cited in documentation and code comments	TLS handshake
RFC 5246: TLS 1.2	TLS 1.2 (RFC 5246, August 2008), still supported by most servers. RFC 9846 formally obsoletes RFC 5246 and adds requirements for TLS 1.2 implementations (section 1.4)	TLS handshake
RFC 8996: Deprecating TLS 1.0 and TLS 1.1	Why and how the old versions were retired (March 2021)	TLS handshake
RFC 6066: TLS Extensions	Server Name Indication (SNI) and the status request used for OCSP stapling	TLS handshake, revocation
RFC 9525: Service Identity in TLS	How clients match a hostname against a certificate’s names, including wildcard rules. Published November 2023 (replaces RFC 6125).	Names and key usage
RFC 9954 and RFC 10024	Hybrid key exchange in TLS 1.3 (July 2026), and the X25519MLKEM768 group that browsers use (August 2026)	Post-quantum
RFC 8705: OAuth 2.0 Mutual-TLS	Client authentication with certificates for APIs, and access tokens bound to a certificate	Mutual TLS

Revocation and transparency

Standard	What it covers	Chapters
RFC 6960: OCSP	The Online Certificate Status Protocol (June 2013)	Revocation
RFC 7633: TLS Feature Extension	The certificate extension behind OCSP Must-Staple (October 2015)	Revocation
RFC 6962 and RFC 9162: Certificate Transparency	Public append-only logs of certificates, SCTs and Merkle tree proofs. Both are Experimental RFCs.	Certificate Transparency
Chrome Certificate Transparency policy	Which logs Chrome accepts and how many SCTs a certificate needs	Certificate Transparency

Issuance and automation

Standard	What it covers	Chapters
RFC 8555: ACME	Automatic certificate issuance and renewal: accounts, orders, challenges, finalisation (March 2019)	ACME, domain validation
RFC 8737: ACME TLS-ALPN-01	Proving domain control inside a TLS handshake	Domain validation
RFC 9773: ACME Renewal Information	How a CA tells clients when to renew (June 2025)	ACME
RFC 8659: CAA	DNS records that say which CAs may issue for a domain (November 2019)	Domain validation
RFC 7030: Enrollment over Secure Transport	A standard way for devices and servers to request certificates from a CA	Device identity
RFC 8995: BRSKI	Zero-touch onboarding of devices with manufacturer-installed certificates	Device identity

Signing and time

Standard	What it covers	Chapters
RFC 3161: Time-Stamp Protocol	Trusted timestamps that keep signatures valid after the signing certificate expires	Code signing
RFC 8551: S/MIME 4.0	Signed and encrypted email	Code signing
RFC 8032: EdDSA	The Ed25519 and Ed448 signature algorithms	Digital signatures
RFC 7748: Elliptic Curves for Security	X25519 and X448 key agreement	Key exchange
RFC 5869: HKDF	The key derivation function inside the TLS 1.3 key schedule	Key exchange, TLS handshake
RFC 2104: HMAC	Message authentication codes built from hash functions	Hashes

Algorithms and key management (NIST)

Standard	What it covers	Chapters
FIPS 186-5: Digital Signature Standard	RSA, ECDSA and EdDSA signatures	Digital signatures
FIPS 197: AES	The Advanced Encryption Standard	Symmetric encryption
FIPS 180-4 and FIPS 202	The SHA-2 and SHA-3 hash functions	Hashes
FIPS 203, FIPS 204, FIPS 205	The first post-quantum standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), published 13 August 2024	Post-quantum
NIST IR 8547: Transition to Post-Quantum Cryptography Standards	The proposed timeline for retiring quantum-vulnerable algorithms: NIST proposes deprecating quantum-vulnerable public-key algorithms at the 112-bit security level after 2030 and disallowing all of them after 2035. Status: NIST IR 8547 (initial public draft, November 2024).	Post-quantum
FIPS 140-3: Security Requirements for Cryptographic Modules	How HSMs and other crypto modules are tested and validated	HSMs and key ceremonies
SP 800-57 Part 1 Rev. 5: Recommendation for Key Management	Key types, cryptoperiods and key protection	HSMs and key ceremonies, private CA
SP 800-52 Rev. 2: TLS Guidelines	Recommended TLS versions, cipher suites and certificate settings for US federal systems, a useful reference for anyone	TLS handshake
SP 800-131A Rev. 2: Transitioning Algorithms and Key Lengths	Which algorithms and key sizes NIST allows, deprecates or disallows	Key pairs, post-quantum
SP 800-208: Stateful Hash-Based Signature Schemes	LMS and XMSS, hash-based signatures used for firmware signing	Post-quantum

Rules for publicly trusted CAs

Document	What it covers	Chapters
CA/Browser Forum TLS Baseline Requirements	The Baseline Requirements: everything a publicly trusted TLS CA must do: validation methods, certificate profiles, lifetimes, revocation and audits	Domain validation, ACME, revocation
CA/Browser Forum EV Guidelines	The extra identity checks for Extended Validation certificates	Domain validation
CA/Browser Forum Code Signing Baseline Requirements	Identity checks, hardware key protection, lifetimes and timestamp authorities for code signing	Code signing
CA/Browser Forum S/MIME Baseline Requirements	Rules for publicly trusted email certificates	Code signing
CA/Browser Forum Network and Certificate System Security Requirements	Security controls for the systems CAs run on	HSMs and key ceremonies
Chrome Root Program Policy	Which CAs Chrome trusts and what it demands of them. Version checked: Chrome Root Program Policy, version 1.8, 5 February 2026.	Trust stores, mutual TLS
Mozilla Root Store Policy	The same for Firefox and the many systems that reuse Mozilla’s root list. Version checked: Mozilla Root Store Policy, version 3.1, 1 July 2026.	Trust stores
Apple Root Certificate Program	The same for Apple platforms. Version checked: Apple Root Program Policy, version 2.0, 1 August 2026.	Trust stores
Microsoft Trusted Root Program requirements	The same for Windows. Version checked: Microsoft Trusted Root Program requirements, version 1.2, 20 May 2026.	Trust stores
CCADB	The Common CA Database, where CAs disclose their hierarchies, audits and policies to the root programs	Trust stores, private CA

European law and ETSI standards

Document	What it covers	Chapters
eIDAS, Regulation (EU) No 910/2014	Electronic signatures, seals, time stamps and qualified trust service providers in the EU	Code signing
Regulation (EU) 2024/1183	Regulation (EU) 2024/1183 (eIDAS 2.0), in force since 20 May 2024: the update to eIDAS, including the European Digital Identity Wallet	Code signing
NIS2, Directive (EU) 2022/2555	Cybersecurity duties for essential and important entities, including policies and procedures regarding the use of cryptography and, where appropriate, encryption (NIS2 Directive (EU) 2022/2555, Article 21(2)(h))	Private CA, post-quantum
ETSI EN 319 411-1 and EN 319 411-2	Policy and security requirements for trust service providers that issue certificates, and for EU qualified certificates	Private CA, code signing
ETSI EN 319 412	Certificate profiles, including qualified certificates	X.509 certificates
ETSI EN 319 421	Policy and security requirements for timestamping authorities	Code signing
ETSI EN 319 142-1	PAdES: signatures inside PDF documents, including long-term validation	Code signing

Devices and workloads

Standard	What it covers	Chapters
IEEE 802.1AR: Secure Device Identity	Manufacturer-installed IDevIDs and owner-issued LDevIDs (IEEE 802.1AR-2018)	Device identity
TCG EK Credential Profile	The certificates that TPM manufacturers issue for each TPM’s endorsement key	Device identity
SPIFFE standards	SPIFFE IDs, X.509-SVIDs and the Workload API for service identity	Mutual TLS
OpenSSH certificates (ssh-keygen manual)	SSH user and host certificates, a simple non-X.509 PKI	Device identity

Missing a standard you need, or found a link that has moved? Tell us.