Post-Quantum X.509 Certificates

Authentication is the second half of the PQC migration. To make TLS, S/MIME, code signing, and the wider PKI quantum-safe, X.509 certificates must carry PQC public keys and signatures. This is harder than key exchange because PQC keys and signatures are much larger, and certificate chains are transmitted on every handshake.

What changes in a PQC certificate

An X.509 certificate binds a subject to a public key and is signed by an issuer. Going post-quantum touches three fields:

The SubjectPublicKeyInfo now holds an ML-DSA or SLH-DSA public key (or a composite key).
The signatureAlgorithm / signatureValue use a PQC signature scheme.
Each of these is identified by a new OID. The IETF LAMPS working group has published these algorithm identifiers as RFCs: RFC 9881 for ML-DSA (FIPS 204), RFC 9909 for SLH-DSA (FIPS 205) and RFC 9935 for ML-KEM (FIPS 203), so tooling can recognize the algorithms.

The size problem

PQC signatures and public keys dwarf their classical counterparts. An ECDSA P-256 signature is ~64 bytes; ML-DSA signatures are typically a few KB, while SLH-DSA, depending on the parameter set, can reach the order of tens of KB. A TLS chain typically contains the leaf, one or more intermediates, and is sent on every handshake, so the bytes add up quickly. This stresses:

Chain size — multi-certificate chains can balloon to many kilobytes, increasing handshake latency.
Embedded and IoT devices — constrained memory and flash struggle with large keys and signatures.
Protocol limits — buffers, record sizes, and amplification limits that assumed small certificates.

Composite and hybrid certificates

To migrate without a flag day, several transitional certificate shapes are being explored:

Composite certificates (IETF "composite ML-DSA", draft-ietf-lamps-pq-composite-sigs, plus composite ML-KEM in draft-ietf-lamps-pq-composite-kem — both still Internet-Drafts) carry two algorithms — for example a composite of ML-DSA + ECDSA — in a single key and a single signature that is only valid if both component signatures verify. A verifier must break both to forge.
Chameleon / hybrid certificates embed an alternative PQC key and signature alongside the classical ones (often via non-critical extensions), so the same certificate satisfies both classical-only and PQC-aware relying parties during the transition.

Composite gives strong "must break both" assurance at the cost of size; hybrid/chameleon designs prioritize backward compatibility.

Inspecting and generating

With PQC-enabled OpenSSL builds you can generate and inspect ML-DSA keys and certificates much as you would for classical algorithms:

# Generate an ML-DSA private key (algorithm name varies by provider/build)
openssl genpkey -algorithm ML-DSA-65 -out leaf.key

# Create a self-signed PQC certificate
openssl req -new -x509 -key leaf.key -out leaf.crt -days 365 -subj "/CN=example.com"

# Inspect it — note the signature algorithm OID and key size
openssl x509 -in leaf.crt -noout -text

CMS and S/MIME

The same algorithms extend to CMS (Cryptographic Message Syntax) and S/MIME: signed messages use ML-DSA/SLH-DSA, and encrypted messages use ML-KEM-based key transport in place of RSA key transport. The CMS conventions are now published RFCs: RFC 9882 (ML-DSA), RFC 9814 (SLH-DSA) and RFC 9936 (ML-KEM).

Standards & references

Warning

Before deploying PQC certificates, test the whole chain end to end — proxies, load balancers, and embedded clients may reject or truncate large certificate chains. Measure handshake size and latency, and favor composite or hybrid certificates during the transition so classical-only relying parties keep working.

后量子 X.509 证书

身份认证是后量子迁移的下半场。要让 TLS S/MIME 代码签名乃至整个 PKI 实现量子安全 X.509 证书必须承载后量子公钥与签名。这比密钥交换更难因为后量子密钥和签名都大得多而证书链每次握手都要传输。

后量子证书有哪些变化

X.509 证书把主体与公钥绑定并由签发者签名。迁移到后量子会触及三个字段：

SubjectPublicKeyInfo 现在存放 ML-DSA 或 SLH-DSA 公钥（或复合密钥）。
signatureAlgorithm / signatureValue 使用后量子签名方案。
以上各项均由新的 OID 标识。IETF LAMPS 工作组已把这些算法标识发布为 RFC：ML-DSA（FIPS 204）见 RFC 9881 SLH-DSA（FIPS 205）见 RFC 9909 ML-KEM（FIPS 203）见 RFC 9935 以便工具识别这些算法。

尺寸难题

后量子签名和公钥远大于经典对应物。ECDSA P-256 签名约 64 字节；ML-DSA 签名通常为数 KB；SLH-DSA 取决于参数集，签名可达到数十 KB 量级。TLS 证书链通常含叶证书和一个或多个中间证书且每次握手都要发送字节数迅速累积。由此带来压力：

证书链尺寸——多证书链可膨胀至许多千字节增加握手时延。
嵌入式与物联网设备——受限的内存和闪存难以容纳大密钥和大签名。
协议限制——按小证书假设设计的缓冲区记录尺寸和放大限制。

复合证书与混合证书

为避免"一刀切"式切换业界正在探索若干过渡型证书形态：

复合证书（IETF "composite ML-DSA" draft-ietf-lamps-pq-composite-sigs 以及 draft-ietf-lamps-pq-composite-kem 中的复合 ML-KEM 两者仍为 Internet-Draft）在单个密钥和单个签名里承载两种算法——例如 ML-DSA + ECDSA 复合——只有两个分量签名都验证通过整体才有效。攻击者必须同时攻破两者才能伪造。
变色龙 / 混合证书在经典密钥与签名旁（通常借助非关键扩展）嵌入一套备用后量子密钥与签名使同一张证书在过渡期内既能满足纯经典依赖方也能满足支持后量子的依赖方。

复合证书以尺寸为代价提供强力的"必须同时攻破"保证；混合/变色龙设计则优先考虑向后兼容。

查看与生成

使用启用后量子的 OpenSSL 构建可像处理经典算法一样生成并查看 ML-DSA 密钥和证书：

# 生成 ML-DSA 私钥（算法名称随 provider/构建而异）
openssl genpkey -algorithm ML-DSA-65 -out leaf.key

# 创建自签名后量子证书
openssl req -new -x509 -key leaf.key -out leaf.crt -days 365 -subj "/CN=example.com"

# 查看证书——留意签名算法 OID 与密钥尺寸
openssl x509 -in leaf.crt -noout -text

CMS 与 S/MIME

同样的算法可延伸到 CMS（密码消息语法）与 S/MIME：签名消息使用 ML-DSA/SLH-DSA 加密消息则以基于 ML-KEM 的密钥传输取代 RSA 密钥传输。CMS 约定现已发布为 RFC：RFC 9882（ML-DSA）RFC 9814（SLH-DSA）与 RFC 9936（ML-KEM）。

标准与参考

警告

部署后量子证书前务必端到端测试整条证书链——代理负载均衡器和嵌入式客户端可能拒绝或截断大证书链。测量握手尺寸与时延并在过渡期优先采用复合或混合证书让纯经典依赖方继续可用。

Previous上一页← IPsec / IKEv2IPsec / IKEv2 Next下一页TLS Decryption & PQCTLS 解密与 PQC →