← Week 3: Integration + failure modes + fit analysis

Day 18: PQC + ACM PCA — Algorithm Roadmap and Current Gaps

Phase 5 · September 12, 2026

← Week 3: Integration + failure modes + fit analysis

Agenda (2–3 hours)

  • Read (30 min): Re-read Phase 3 PQC migration roadmap §4 (AWS services)
  • Study (60 min): ACM PCA algorithm support today; CloudHSM PQC roadmap; SPIRE + PQC gap
  • Write (60 min): Update pqc-migration-roadmap.md with ACM PCA and CloudHSM specifics
← Week 3: Integration + failure modes + fit analysis

Where We Are: PQC Algorithm Support (2026)

Component Algorithm today PQC-ready? Target
ACM PCA leaf certs ECDSA P-256 No ML-DSA when NIST finalizes templates
ACM PCA CA key ECDSA P-256 (AWS-managed) No CloudHSM PQC needed first
CloudHSM RSA/ECDSA No PQC support ~2027
AWS KMS RSA/ECDSA/AES No ML-KEM, ML-DSA roadmap pending
SPIRE SVID ECDSA P-256 No Blocked by SPIRE CA key migration
rustls + aws-lc-rs ML-KEM (TLS KEM), ML-DSA Partial Key exchange ✓; cert signing TBD

This is the dependency chain from Phase 3, now applied to your specific architecture.

← Week 3: Integration + failure modes + fit analysis

The ACM PCA PQC Dependency Chain

Step 1: CloudHSM adds PQC key support (expected ~2027)
   └── AWS can generate ML-DSA key pairs inside CloudHSM hardware

Step 2: ACM PCA uses ML-DSA keys for its internal CA
   └── ACM PCA can sign certs with ML-DSA
   └── New template: "EndEntityCertificate/V1" with ML-DSA signing algorithm

Step 3: ACM PCA exposes ML-DSA signing algorithm in API
   └── IssueCertificate: SigningAlgorithm = ML_DSA_65 (new enum value)

Step 4: SPIRE upstream CA gets ML-DSA intermediate cert from ACM PCA
   └── All new SVIDs signed by ML-DSA intermediate → ML-DSA leaf SVIDs

Step 5: Your provisioning service passes ML-DSA signing algorithm to IssueCertificate
   └── Device certs signed with ML-DSA

Each step is a dependency on AWS roadmap. You don't control the timeline.

← Week 3: Integration + failure modes + fit analysis

What You CAN Do Today

Even without ACM PCA ML-DSA support, you can prepare:

1. Use short-lived SVIDs for service identity (Phase 4)

  • 1-hour SVID reduces HNDL window dramatically (even without PQC)
  • When SPIRE adds ML-DSA support, all SVIDs update within 1 TTL

2. Use hybrid TLS at the session layer (Phase 3)

  • rustls + aws-lc-rs with X25519MLKEM768 key exchange
  • TLS session keys are PQC-protected even if the cert signature is ECDSA
  • This addresses HNDL for data confidentiality

3. Design the cert hierarchy for algorithm agility

  • Use separate issuance CAs for device vs. service certs
  • When ACM PCA adds ML-DSA: migrate one issuance CA at a time

4. Plan the firmware update path for device root cert

  • If root CA changes algorithm, device firmware needs updating
  • Design this now so it's not a surprise in 2027
← Week 3: Integration + failure modes + fit analysis

Algorithm Agility in Certificate Templates

When ACM PCA adds ML-DSA support, the API change is minimal:

// Today (ECDSA):
client
    .issue_certificate()
    .signing_algorithm(SigningAlgorithm::Sha256Withecdsa)
    // ...

// Future (ML-DSA, when supported):
client
    .issue_certificate()
    .signing_algorithm(SigningAlgorithm::MlDsa65)  // hypothetical new enum
    // ...

The rest of your issuance code is unchanged.
This is algorithm agility — the benefit of building on an abstracted API.

← Week 3: Integration + failure modes + fit analysis

Hybrid Certs: What Would Full PQC Look Like?

A fully PQC-compliant device cert (2027+):

Subject: CN=Satellite-SN-12345
Algorithm: ML-DSA-65 (CRYSTALS-Dilithium)
Public Key: ML-DSA-65 (2592-byte public key)
Signature: ML-DSA-65 (signed by Leo Device Issuance CA using ML-DSA-65 key)
Validity: 90 days
Key Usage: digitalSignature
EKU: clientAuth

The device needs an ML-DSA key pair (not ECDSA).
Key generation on the device: the device firmware generates the ML-DSA key pair
and sends the CSR to your provisioning service — this is the same flow,
just with a different algorithm.

← Week 3: Integration + failure modes + fit analysis

CNSA 2.0 Compliance Timeline for Your Provisioning Service

From Phase 3, CNSA 2.0 targets:

Component CNSA 2.0 requirement Deadline Status
Key exchange ML-KEM-768 or hybrid 2025+ (now) ✓ (rustls hybrid)
Software sig ML-DSA-65 2025+ (now) ✗ (ECDSA only)
TLS certs ML-DSA-65 signing 2027 preferred ✗ (ACM PCA gap)
CA key ML-DSA-65 2027 preferred ✗ (CloudHSM gap)
Device certs ML-DSA-65 2030 required ✗ (firmware + ACM PCA)

The TLS key exchange is the only CNSA 2.0 item achievable today.
Everything else waits on AWS service roadmaps.

← Week 3: Integration + failure modes + fit analysis

Challenge Assignment

Update pqc-migration-roadmap.md with a new subsection:

### §9.5 ACM PCA and CloudHSM PQC Dependencies

**Table: Component × PQC readiness × dependency × estimated date**

**§9.5.1 ACM PCA PQC Migration Path**
<When ACM PCA adds ML-DSA: what changes in your IssueCertificate call?>
<What changes in your cert templates?>

**§9.5.2 CloudHSM PQC Gap**
<Why CloudHSM PQC support is the critical path item>
<What AWS announcements to watch for>

**§9.5.3 Device Cert Migration**
<How do satellite terminal devices get new ML-DSA key pairs?>
<Firmware update path for new root CA cert (if algorithm changes)>
← Week 3: Integration + failure modes + fit analysis

Resources

  • Phase 3, Day 19: PQC + SPIFFE intersection (SVID + HNDL window)
  • Phase 3, pqc-migration-roadmap.md §4 (AWS services dependency table)
  • AWS re:Post: search "ACM PCA post-quantum" for current status
  • CNSA 2.0: NSA media.defense.gov — Algorithm requirements table
  • NIST FIPS 204 (ML-DSA): csrc.nist.gov/pubs/fips/204/final