Certificates & Proofs / Hybrid Certificates
What you will do: Enable the HSM, press Generate on any of the seven current certificate format cards or Generate All Current Formats, check each card's verification results, then read each PEM or parsed view and the Format Comparison table. Advanced and historical examples are generated separately.
Worked example: Generate Pure PQC (ML-DSA-65) and Related Certificates (RFC 9763) first: the comparison table shows their DER size, generation time and quantum-safe status side by side.
Runtime and privacy: The cryptographic exercise runs in this browser. Review the site privacy terms before entering sensitive material; use synthetic inputs for learning and evaluation.
Browse all Crypto Lab tools · Learn with Hybrid Cryptography
For your role
- Developer / Engineer
- Press Generate All Formats, or generate one at a time: Pure PQC (ML-DSA-65), Composite (ML-DSA-65 + ECDSA), Alt-Sig / Catalyst, Related Certificates (RFC 9763) and the KEM certificates; the PKCS#11 log shows the key generation each one needs.
- Security Architect
- Choose a composite profile such as ML-DSA-65 + ECDSA P-256 from the draft's list and compare its certificate with the Alt-Sig and Related Certificates forms: each keeps or breaks backward compatibility with relying parties differently.
- Researcher / Academic
- Generate each format and compare the encoded certificates: the OIDs in the composite profile list come from the draft, and the Pure PQC KEM (ML-KEM-768) form shows a certificate whose key is for encapsulation, not signing.
- IT Ops / DevOps
- Generate the Composite and the Alt-Sig / Catalyst forms: a relying party that knows only ECDSA still validates one of them, and that is the property that decides which form your fleet can carry during migration.
Initializing SoftHSM…
C_Initialize → C_InitToken → C_OpenSession → C_Login
Hybrid Certificate Formats
Generate and compare X.509 hybrid certificate approaches. Each format combines classical and PQC algorithms differently, with distinct trade-offs for backward compatibility, standardization, and security properties.
Enable the HSM above to generate certificates. (softhsmv3 WASM loads once — allow 3–8 seconds on first use.)
Pure PQC (ML-DSA-65)
Pure PQC certificates are the simplest approach — a direct replacement of classical algorithms. However, they break backward compatibility since legacy validators cannot process ML-DSA-65. ANSSI recommends hybrid approaches until PQC algorithms have matured through extended cryptanalysis.
Pure PQC (SLH-DSA-128s)
SLH-DSA (SPHINCS+) uses hash-based constructions with no lattice assumptions. RFC 9909 (published December 2025) defines the X.509 profile, but CA/browser ecosystem adoption is still nascent — significantly behind ML-DSA (RFC 9881). ANSSI allows standalone use of hash-based signatures (SLH-DSA, LMS, XMSS) even without hybrid mode, since their security relies only on hash function properties.
Composite (ML-DSA-65 + ECDSA P-256)
General use — §10.4 calls this the best overall balance of performance and security.
id-MLDSA65-ECDSA-P256-SHA512 — PH SHA-512, traditional ECDSA P-256 with SHA-256. The pre-hash and the traditional hash are chosen independently — the SHA-xxx in the profile name is the pre-hash, not the traditional algorithm’s hash.
Composite certificates bind both algorithms under a single OID (1.3.6.1.5.5.7.6.45) and require both signatures to verify — if either fails, the certificate is rejected. Both the public key and the signature are RAW CONCATENATIONS with the ML-DSA component first (§4.1, §4.3); there is no ASN.1 wrapper, so a verifier splits at ML-DSA's fixed length. Both components sign a shared message representative M' = Prefix || Label || len(ctx) || ctx || PH(TBS), and ML-DSA takes the signature label as its FIPS 204 context — this is what prevents either half being stripped and reused. Legacy validators cannot process composite OIDs at all: composite is NOT backward compatible.
Alt-Sig / Catalyst (ECDSA + ML-DSA)
Alt-Sig (the alternative-signature extensions from ITU-T X.509 §9.8; ISARA marketed an implementation as "Catalyst") embeds a PQC public key and signature inside a classical certificate's X.509 extensions. Legacy validators ignore the unknown extensions and process only the classical ECDSA signature. PQC-aware verifiers can also check the alternative signature; their policy decides whether one or both must verify. This differs from Related Certificates (RFC 9763), which uses two separate independent certificates bound by a hash.
Related Certificates (RFC 9763)
RFC 9763 (Related Certificates) links a NEW certificate to an EXISTING one. The requester proves it holds Cert A's key in a relatedCertRequest CSR attribute; the CA verifies that proof and issues Cert B with a RelatedCertificate extension holding the hash of the complete final Cert A — the hash named by Cert A's signature algorithm, SHA-256 here. The link is one-way and Cert A is never modified. Each certificate stays independently valid, and a protocol may use either or both — RFC 9763 does not require both. Unlike Alt-Sig (one certificate carrying a second signature), the two certificates stay separate.
Pure PQC KEM (ML-KEM-768)
RFC 9935 (March 2026) defines X.509 algorithm identifiers for ML-KEM-512/768/1024. KEM certificates are encryption-only per §4 — they cannot self-sign. This workshop generates an ML-KEM-768 key and issues a CA-issued ML-KEM end-entity certificate from a separate ML-DSA-65 workshop CA: the subject key does encapsulation and decapsulation, and only the issuer key signs. A CA cannot check a self-signature from a KEM key, so the workshop CA injects the public key directly. KEM certs enable PQ-safe key encapsulation at the X.509 layer (CMS, S/MIME, IKE certificate-based modes).
Composite KEM (ML-KEM-768 + X25519)
draft-ietf-lamps-pq-composite-kem defines composite KEM public keys binding ML-KEM-768 with a classical KEM (X25519, P-256, P-384, RSA-2048/3072/4096, brainpoolP256) under a single OID (encoded ML-KEM component first, then the classical component — §4.1). Encapsulation runs both KEMs and combines shared secrets via a KDF — both must succeed. Like composite signatures, the wire format is parsed only by composite-aware libraries: stock OpenSSL 3.6.3 registers no composite algorithms at all and fails to load a composite public key, so composite certificates are NOT backward compatible. KEM certs are encryption-only (RFC 9935 §4); signing requires a separate CA. This card shows the certificate encoding only — it does not run composite encapsulation.
Advanced examples
Specialised mechanisms that are not part of Generate All: Certificate Discovery (an active draft whose OIDs are not assigned yet, so its encoding here is illustrative) and the RFC 9925 unsigned certificate (a container that is never valid in a certification path).
Certificate Discovery (draft, OIDs TBD)
draft-ietf-lamps-certdiscovery-03 (active LAMPS working-group draft, replacing draft-lamps-okubo-certdiscovery) lets a certificate point to a related certificate — for example a PQC one — through a subjectInfoAccess entry. The RelatedCertificateDescriptor says how to fetch it (by URI, by inclusion, or by local policy), why (agility, redundancy, dual use…), and which signature and public-key algorithms it uses, so a relying party can skip what it cannot process. A fetched secondary is not trusted by being fetched: it must pass full certification path validation. The draft's id-ad-certDiscovery, id-on-relatedCertificateDescriptor and intent OIDs are still TBD, so this example uses documentation-arc placeholders and resolves the URI locally — it shows the shape of the mechanism, not an interoperable encoding.
Unsigned ML-KEM certificate (RFC 9925)
RFC 9925 (February 2026, updates RFC 5280) defines id-alg-unsigned for certificates that carry no signature: the signature value is a zero-length BIT STRING and the issuer is a placeholder (here the id-rdna-unsigned RDN), so the object is not self-signed and not self-issued even though no CA signed it. It suits keys that are trusted by other means — for example a trust anchor, or a KEM key delivered over an already-authenticated channel. Validators MUST NOT accept id-alg-unsigned as a signature in a certification path. Compare the ordinary CA-issued ML-KEM certificate (RFC 9935) in the main comparison.
Historical designs
Proposals that expired or were never adopted by the IETF. They are kept for study only, are not part of Generate All, and are not recommended for new deployments.
Chameleon Certificates
HISTORICAL — not recommended for new deployments. draft-bonnell-lamps-chameleon-certs-07 is an INDIVIDUAL submission that EXPIRED on 2026-04-21 and was never adopted as a LAMPS working-group document — there is no draft-ietf-lamps-chameleon-certs, and the work was not renamed or absorbed elsewhere. Treat it as a dormant design, not an active standards track; it is kept here only because the delta-encoding idea is instructive. This demo generates a real DER-encoded chameleon cert with a DeltaCertificateDescriptor extension (OID 2.16.840.1.114027.80.6.1). The delta extension encodes only the differences (signature, public key, extensions) needed to reconstruct the classical partner cert — but validating it requires a chameleon-aware parser. Legacy validators see only the ML-DSA-65 primary and silently ignore the delta: verified against OpenSSL 3.6.3, which validates the ML-DSA-65 signature and reports the delta as an unrecognised OID.
Try it
Which generated format can a relying party that knows only ECDSA still validate?
Next step
Turn it into a plan: Hybrid Transition PlannerThis tool practises the Hybrid Cryptography module, phase 5 (Pilots & Migration); Hybrid Transition Planner produces a deliverable of that phase.
Related content
Next in Certificates & Proofs