365 Architect

08 — Deployment Guide

Where to Use ML-DSA

Use Case Classical Algorithm ML-DSA Replacement Priority
TLS certificates ECDSA P-256 ML-DSA-65 High
Code signing RSA-2048 / ECDSA ML-DSA-65 High
Software updates ECDSA / Ed25519 ML-DSA-65 High
Document signing RSA-2048 ML-DSA-65 or ML-DSA-87 Medium
Git commits Ed25519 ML-DSA-44 or ML-DSA-65 Low
Firmware signing RSA-2048 ML-DSA-87 (high assurance) High
Blockchain ECDSA / EdDSA ML-DSA-65 (layer 1) Medium

Certificate Transition Strategy

Dual-Signed Certificates

During transition, issue certificates signed by BOTH classical and PQC algorithms:

Certificate:
  Subject: CN=docs.365architect.com
  
  Signature 1 (classical):
    Algorithm: ECDSA P-256
    Signature: [64 bytes]
    
  Signature 2 (PQC):
    Algorithm: ML-DSA-65
    Signature: [3,293 bytes]

Benefits:

  • Old clients verify the ECDSA signature
  • New clients verify the ML-DSA signature
  • Either algorithm can be compromised without breaking trust

CA Hierarchy Update

Root CA (ML-DSA-87)
    |
    signs
    |
Intermediate CA (ML-DSA-65)
    |
    signs
    |
End-entity cert (ML-DSA-65)

Migration steps:

  1. Phase 1 (now): Add ML-DSA intermediate CA alongside existing ECDSA intermediate
  2. Phase 2 (2026–2028): Issue dual-signed end-entity certificates
  3. Phase 3 (2028–2030): Issue pure ML-DSA certificates for new systems
  4. Phase 4 (2030+): Retire classical CA hierarchy

Code Signing Pipeline

Before (Classical)

Build → Test → Sign with ECDSA → Release

After (Hybrid)

Build → Test → Sign with ECDSA + ML-DSA → Release
                    ↓
              [Dual signature]
                    ↓
         Package contains:
         - Binary
         - ECDSA signature
         - ML-DSA signature

Verification

Client:
  1. Check ECDSA signature (if supported)
  2. Check ML-DSA signature (if supported)
  3. Accept if at least one valid signature passes
  4. Prefer ML-DSA when both available

Document Signing

PDF Signatures

PDF supports multiple signature slots. Add ML-DSA as a second signature:

PDF Document:
  - Content stream
  - Signature 1: RSA-2048 (legacy)
  - Signature 2: ML-DSA-65 (PQC)

Tools:

  • Adobe Acrobat (future versions will support PQC via plugin)
  • iText / PDFBox (Java) — add custom signature handlers
  • OpenSSL 3.2+ with OQS provider

Blockchain Considerations

Signature Size Impact

Blockchain Current signature ML-DSA-65 Size increase
Bitcoin 72 B (ECDSA) 3,293 B 45×
Ethereum 65 B (ECDSA) 3,293 B 50×
Cardano 64 B (EdDSA) 3,293 B 51×

Solutions:

  • Layer 2 rollups: Aggregate signatures off-chain, submit single proof on-chain
  • Signature aggregation: Multiple ML-DSA signatures compressed into one
  • Hybrid approach: Use ML-DSA for high-value transactions, keep ECDSA for routine

Monitoring and Metrics

Metric Target Alert Threshold
Signature verification rate > 99.9% < 99.5%
Verification latency (p99) < 2 ms > 5 ms
Signature size (unexpected) Matches parameter set Deviation > 10%
Client compatibility > 95% PQC-aware < 90%

Common Pitfalls

Pitfall Cause Fix
Certificate chain too long ML-DSA signatures add 3 KB per cert Limit chain depth to 3; use compact intermediates
Old clients reject large handshakes TLS ClientHello size exceeds buffer Enable fragmentation; test with legacy clients
Hardware HSM incompatibility HSM firmware doesn't support ML-DSA Upgrade HSM firmware or use external signing module
Side-channel leaks Non-constant-time polynomial operations Use verified constant-time implementations (liboqs, pqm4)
Context string misuse Different applications use same key Always specify ctx for domain separation

Resources

★★★★★
Share on LinkedIn