As post-quantum cryptography (PQC) becomes a reality, organizations that rely on Device Identity Composition Engine (DICE) for secure boot and device attestation face a pressing question:
👉 How should Public Key Infrastructure (PKI) evolve to support both classical (such as ECDSA) and post-quantum (ML-DSA / CRYSTALS-Dilithium) algorithms?
This post explores the main design options — hybrid, composite, and separate hierarchies — with their pros, cons, and a recommended approach.
🔑 Why It Matters
- ECDSA: Well-supported, lightweight, and the backbone of current PKI deployments.
- ML-DSA: Post-quantum secure, but certificates and signatures are much larger, and ecosystem support is still evolving.
- DICE environments: Constrained devices, long lifecycles, and strict security requirements.
The challenge is balancing interoperability today with post-quantum security tomorrow.
🛠 Options for PKI Hierarchy
1. Two Separate Hierarchies (Recommended Baseline)
- Description: Maintain independent root and CA chains for ECDSA and ML-DSA. Devices hold two certificates.
- Pros:
- Clear separation of trust and policy.
- Works with existing TLS/PKI stacks.
- Flexible migration path.
- Cons:
- Larger storage footprint (two chains).
- More operational overhead.
✅ Best for: Phased migration, broad compatibility.
2. Dual-Certificate Approach
- Description: Issue two leaf certificates for the same device identity (one ECDSA, one ML-DSA) and link them via an extension.
- Pros:
- Standard-compliant.
- Easy to associate certs to the same device.
- Cons:
- Still doubles bandwidth and storage.
✅ Best for: Devices with enough space, when you want a tight identity link.
3. Dual-Signed Certificates
- Description: One certificate signed by both an ECDSA CA and an ML-DSA CA.
- Pros:
- One cert to manage and provision.
- Cons:
- Not fully standard.
- Many X.509 libraries won’t accept two signatures.
⚠️ Best for: Closed ecosystems only. Avoid for public or large-scale use.
4. Composite Certificates
- Description: Embed multiple public keys (ECDSA + ML-DSA) in a single certificate.
- Pros:
- Device presents one cert.
- Cons:
- Non-standard.
- Risk of downgrade or misuse.
⚠️ Best for: Experimental deployments.
5. Protocol-Level Hybrid
- Description: Keep one cert (often ECDSA) but use hybrid TLS with PQC + classical signatures in the handshake.
- Pros:
- Supported by draft TLS extensions.
- No new cert formats.
- Cons:
- Doesn’t solve PQ identity binding in certificates.
✅ Best for: TLS ecosystems with hybrid support.
🧩 Other Variations
- Cross-signing intermediates: Bridge between PQ and classical roots.
- Short-lived certs: Reduce revocation costs for PQ certs.
- Custom extensions: Carry alternate PQ public keys in X.509.
📊 Recommendation for DICE PKI
For most organizations, the safest and most practical path is:
- Run two parallel hierarchies (ECDSA and ML-DSA).
- Issue paired device certificates — one from each hierarchy.
- Cross-sign intermediates if you need a smooth transition.
- Select certificate chain based on peer capability (classical or PQ).
- Plan a long-term roadmap: gradually move from ECDSA-first to ML-DSA-first as PQ adoption grows.
This strikes a balance between compatibility, security, and operational clarity.
✅ Action Checklist
- 🔒 Protect root and intermediate keys (HSM/TPM).
- 🗂 Define CA policies for both hierarchies.
- 🔗 Create a mechanism to link paired certs.
- 🌐 Test with representative clients and servers.
- 📅 Establish a migration timeline and sunset plan for ECDSA.
🎯 Takeaway
Moving DICE PKI into the post-quantum era is not about choosing one algorithm today — it’s about coexistence and migration strategy.
👉 The recommended approach: two hierarchies with paired certificates, giving you flexibility to support legacy systems while building resilience against quantum threats.