PKI Workshop

Learn PKI fundamentals, build certificate chains hands-on, and explore PQC migration.

Learning sandbox — private keys are stored in your browser and should not be used in production.

What is PKI?

(PKI) is a framework of policies, hardware, software, and procedures for creating, managing, distributing, and revoking digital certificates. Defined by ITU-T and profiled for the internet in RFC 5280, PKI enables entities to establish trust through a hierarchy of (CAs) that vouch for the binding between a public key and an identity.

Components
  • Certificate Authorities (CAs)
  • Registration Authorities (RAs)
  • End Entities (subscribers)
Trust Models
  • Hierarchical (Root → Intermediate → EE)
  • Bridge CA (cross-certification)
  • Web of Trust (PGP model)
Standards
  • X.509v3 certificates (RFC 5280)
  • PKCS#10 format (RFC 2986)
  • CMP enrollment (RFC 4210)

The Certificate Lifecycle

Every X.509 certificate follows a defined lifecycle from key generation through revocation. RFC 5280 Section 3 describes the certificate path processing model, while RFC 6960 () and RFC 5280 Section 5 (s) define the revocation checking mechanisms that relying parties use to verify certificate validity in real time.

Key GenerationGenerate asymmetric key pair
CSR CreationSubject info + public key
CA SigningValidate identity & sign
Certificate UseTLS, code signing, S/MIME
Revocation / RenewalCRL, OCSP, or re-issue
Certificates expire or are revoked — the lifecycle repeats

X.509 Certificate Structure

An X.509v3 certificate (RFC 5280 Section 4.1) contains three main parts: the TBSCertificate (to-be-signed data), the signature algorithm identifier, and the digital signature value. The TBSCertificate holds all the fields that get signed by the CA:

Versionv3 (0x2) — required for extensions
Serial NumberUnique per CA — MUST be positive integer (RFC 5280 Section 4.1.2.2)
Signature Algorithmsha256WithRSAEncryption, ml-dsa-65, slh-dsa-sha2-128s, etc.
IssuerCA distinguished name (DN)
ValidityNot Before / Not After — defines certificate lifetime
SubjectEnd entity DN (CN, O, C, etc.)
Subject Public Key InfoAlgorithm OID + public key bits
ExtensionsKey Usage, Basic Constraints, SAN, CRL Distribution Points (RFC 5280 Section 4.2)

Digital Signatures in PKI

Certificate issuance and verification rely on as defined in RFC 5280 Section 4.1.1.2. The CA signs the TBSCertificate using its private key, and any relying party can verify the signature using the CA's public key from a trusted root store.

Signing (CA)
  1. Construct TBSCertificate (subject, key, extensions)
  2. Hash the TBSCertificate (SHA-256, SHA-384, etc.)
  3. Sign hash with CA private key
  4. Append signature algorithm OID + signature value
Verification (Relying Party)
  1. Extract signature from certificate
  2. Hash the TBSCertificate independently
  3. Verify signature against CA public key
  4. Check validity period, extensions, revocation

Classical vs PQC Algorithms in PKI

Traditional PKI relies on and signatures, both vulnerable to on a cryptographically relevant quantum computer. NIST has standardized post-quantum replacements: (FIPS 204) for signatures and (FIPS 205) for stateless hash-based signatures.

Classical (RSA / ECDSA)

Proven, widely deployed. Small signatures (256-512 bytes). Vulnerable to quantum computers running Shor's algorithm.

PQC (ML-DSA / SLH-DSA)

Quantum-resistant. ML-DSA-65 signatures ~3,309 bytes, SLH-DSA-SHA2-128s ~7,856 bytes (FIPS 204, FIPS 205). Larger but quantum-safe.

Hybrid /

Combine classical + PQC in one certificate for backward compatibility. Protects against both classical and quantum attacks during transition.

PQC Migration for PKI

Root CA certificates can have lifetimes of 20+ years. While data encryption is vulnerable to "" attacks, long-lived CAs are vulnerable to "forge later" attacks, where a cryptographically relevant quantum computer could forge signatures and issue rogue certificates. recommends beginning the transition to post-quantum algorithms immediately, with (NSA) setting a 2030 deadline for PQC-only PKI in national security systems.

Key migration challenges include certificate size growth (ML-DSA-87 public keys are ~2,592 bytes vs 294 bytes for ECDSA P-256), constrained device support, and maintaining cross-signed trust chains during the transition period. NIST SP 800-131A Rev 2 provides guidance on algorithm deprecation timelines.

Merkle Tree Certificates: Solving PQC Certificate Bloat

Post-quantum signatures are dramatically larger than their classical counterparts: signatures are 2,420 bytes compared to just 64 bytes for ECDSA P-256 — a 37× increase. A typical TLS certificate chain with three PQ signatures, public keys, and Certificate Transparency SCTs can add 18–36 KB to every handshake, breaking constrained clients and degrading performance.

Merkle Tree Certificates (MTCs), proposed in IETF draft-davidben-tls-merkle-tree-certs by Google and Cloudflare, offer an elegant solution: instead of signing each certificate individually, a Merkle Tree CA (MTCA) batches thousands of certificates as leaves in a , signs only the root hash, and distributes compact inclusion proofs (~736 bytes) that let any relying party verify a certificate belongs to the signed batch. This replaces three separate PQ signatures with a single root signature plus a hash-based proof.

Traditional PQC Chain
  • 3 ML-DSA-44 signatures: 7,260 B
  • 3 public keys: 3,936 B
  • 4 CT SCTs: 476 B
  • Total: ~12.3 KB per handshake
MTC Approach
  • 1 root signature: 2,420 B
  • 1 root public key: 1,312 B
  • Inclusion proof: 736 B
  • Total: ~4.5 KB per handshake

Tradeoff: MTC clients must periodically fetch transparency service updates (similar to CRLite). This trades per-handshake size for background data synchronization — a favorable tradeoff for high-traffic servers and constrained IoT devices.

Full MTC Workshop Module

Related Resources