Day 19: Composite Signatures and Dual-Algorithm Certificates

Phase 3 · July 26, 2026

Agenda (2–3 hours)

• Read (60 min): IETF draft-ietf-lamps-pq-composite-sigs §1–4; draft-ounsworth-pq-composite-keys §1–3
• Study (45 min): Composite cert construction, backward compatibility, IETF status
• Challenge (45 min): Composite cert design for your CA hierarchy

The Transition Problem for Certificates

TLS hybrid (Day 16) handles key exchange gracefully — a combined key share is
self-contained and both sides negotiate it explicitly.

Certificate signatures are harder: a certificate has exactly one signature.
Old clients (pre-PQC) can only verify ECDSA. New clients want ML-DSA.

Options:

1. Two separate certs: one ECDSA, one ML-DSA — server sends both (complex)
2. Composite signatures: a single cert with TWO signatures (one classical, one PQC)
3. Pure PQC cert: only ML-DSA — breaks old clients
4. Pure classical cert: wait for HSMs → delays PQC protection

Composite Signature Construction

A composite signature bundles multiple algorithm outputs:

CompositeSignatureValue ::= SEQUENCE OF BIT STRING
-- [0] = ECDSA-P256 signature
-- [1] = ML-DSA-65 signature

CompositePublicKey ::= SEQUENCE OF SubjectPublicKeyInfo
-- [0] = ECDSA-P256 public key
-- [1] = ML-DSA-65 public key

A composite certificate has:

• A composite public key (both algorithms' keys)
• A composite signature (signed twice: once per algorithm)
• Special OID identifying the combination

Both signatures must verify for the certificate to be trusted.
A legacy client that understands only ECDSA can try to parse just the ECDSA signature
if the implementation supports it (soft vs. strict composite).

IETF Draft Status

IETF LAMPS WG is actively developing composite certs (as of 2026):

• draft-ietf-lamps-pq-composite-sigs: composite signature algorithms
• draft-ietf-lamps-pq-composite-kem: composite KEM for key agreement in S/MIME

Not yet an RFC — use only in internal/private PKI, not public-trust hierarchies.
Public CA/B Forum adoption expected 2027–2028.

For your toy PKI: implement a simplified composite scheme as a learning exercise.
For production: watch the IETF drafts and AWS Private CA roadmap.

Alternative: Dual-Certificate Delivery

While composite certs are being standardized, some implementations use dual delivery:

TLS Certificate message:
  CertificateEntry[0]: ML-DSA leaf cert (for PQC-capable clients)
  CertificateEntry[1]: ECDSA leaf cert  (for legacy clients)

Clients that understand ML-DSA use entry [0]; legacy clients fall back to [1].
TLS 1.3 supports multiple entries in the Certificate message.

This is simpler to implement today without waiting for composite cert standards.

When Does Each Apply?

For your provisioning service (all clients are your own code):
→ You control both sides → pure PQC cert is viable immediately.

For public-facing services:
→ Dual delivery or composite cert during transition.

Challenge Assignment

Design the certificate transition plan for your CA hierarchy:

Phase A (now – 2027): Dual-cert delivery

• Root CA: issue two intermediates (one ECDSA, one ML-DSA)
• Servers: present both chains, clients negotiate
• Advantage: no client changes required

Phase B (2027–2030): Composite certs (once IETF RFC is finalized)

• Single cert with both signatures
• Root CA: composite signature
• Streamlines cert management

Phase C (2030+): Pure ML-DSA

• Drop ECDSA infrastructure

For each phase, list: what changes, what stays the same, what the risk is.
Save to your migration roadmap as "Certificate Transition Plan."

Resources

• IETF draft-ietf-lamps-pq-composite-sigs: datatracker.ietf.org
• IETF draft-ounsworth-pq-composite-keys: composite public key format
• Open Quantum Safe project: openquantumsafe.org — has composite cert examples