Last updated: June 2025
[IMAGE: Macro shot of a quantum processor chip with branching Merkle tree light paths rendered in cyan and teal, emanating from the die surface into deep black space — cinematic 8K, dramatic low-angle perspective, no text or human faces]
Key Takeaways
- ML-DSA-65 post-quantum signatures weigh 3,309 bytes — over 50× larger than Ed25519 — creating compounding TLS handshake overhead across thousands of connections per second in Kubernetes and 5G Core environments
- Merkle Tree Certificate (MTC) landmark verification completes in under 2 microseconds on an Intel i9-12900, approximately 12× faster than ECDSA’s 24-microsecond baseline, with no measurable impact on TLS handshake time
- Organizations running cloud-native infrastructure must begin redesigning their PKI architecture now — before IETF standardization forces an emergency migration under compliance pressure
The Handshake Tax Your 5G Core Cannot Afford
Picture your 5G Core network’s Network Repository Function (NRF) processing service discovery requests at peak load — thousands of TLS handshakes per second between microservices. Now add post-quantum signatures to every one of those handshakes.
ML-DSA-65, one of NIST’s newly standardized post-quantum signature algorithms, produces signatures of 3,309 bytes and public keys of 1,952 bytes. Compare that to Ed25519, the elliptic-curve algorithm most Kubernetes clusters and 5G Service-Based Architectures (SBA) rely on today. ML-DSA-65’s artifacts are over 50 times larger. At thousands of handshakes per second — the operational reality of a production Kubernetes control plane or 3GPP 5G Service-Based Architecture — that overhead compounds into a measurable latency and bandwidth problem that no amount of hardware scaling fully absorbs.
This is not a theoretical future risk. NIST has already standardized ML-DSA. The migration clock is running. The question for your security architecture team is not whether to adopt post-quantum signatures, but how to do it without degrading the performance your infrastructure SLAs depend on.
Researchers publishing on arXiv (submission 2604.04191v1) have proposed a concrete answer: Merkle Tree Certificates (MTC), currently under active development at the IETF, deployed as a replacement PKI layer for both Kubernetes control planes and 5G Core networks.
What Merkle Tree Certificates Actually Do
Merkle Tree Certificates (MTC) are a post-quantum PKI scheme in which per-certificate issuer signatures are replaced with Merkle inclusion proofs. Instead of each certificate carrying a cryptographic signature from a Certificate Authority, a Merkle Tree Certificate Authority (MTCA) batches certificates into a Merkle tree, publishes the root, and issues compact inclusion proofs. Relying parties verify membership in the tree rather than verifying an individual signature.
In landmark mode — the operationally significant configuration for high-frequency TLS environments — MTC eliminates on-wire signatures from certificate authentication entirely. The landmark (a pre-distributed, trusted Merkle root) allows a verifier to confirm certificate validity without processing any signature at handshake time.
The performance result is stark:
MTC landmark verification completes in under 2 microseconds on an Intel i9-12900, compared to 24 microseconds for ECDSA signature verification — with no measurable impact on TLS handshake time. (arXiv:2604.04191v1)
That is a 12× verification speedup, achieved while simultaneously eliminating the bandwidth overhead of carrying post-quantum signature bytes on the wire.
How the Architecture Fits Together
The MTC deployment model introduces three infrastructure components your team needs to understand:
- MTCA (Merkle Tree Certificate Authority): Issues MTC certificates by batching them into Merkle trees and publishing signed roots. In a Kubernetes deployment, the cluster CA is replaced with an MTCA.
- Cosigners: Witness nodes that co-sign Merkle roots, providing additional trust anchors. In the 5G SBA model, the Service Communication Proxy (SCP) acts as the witness cosigner.
- Landmark Distributor: A DaemonSet-based component in Kubernetes that pushes trusted Merkle roots to every node, enabling landmark-mode verification without per-handshake signature processing.
The researchers validated this architecture in two concrete deployments: a Kubernetes cluster where the control plane CA was replaced with an MTCA issuing MTC certificates to all control plane components, and a post-quantum 5G Core (QORE) where the NRF serves as the MTCA and the SCP acts as witness cosigner.
MTC proof construction and verification were implemented directly in Go’s crypto/tls and crypto/x509 packages — meaning the integration path into existing Go-based infrastructure is well-defined.
Post-Quantum Signature Overhead: By the Numbers
Before evaluating MTC as a solution, security architects need to internalize the scale of the problem ML-DSA-65 creates in high-frequency TLS environments.
| Metric | Ed25519 (Classical) | ML-DSA-65 (Post-Quantum) | MTC Landmark Mode |
|---|---|---|---|
| Signature size | ~64 bytes | 3,309 bytes | 0 bytes (on-wire) |
| Public key size | ~32 bytes | 1,952 bytes | Merkle proof (compact) |
| Size ratio vs. Ed25519 | 1× | >50× | <1× |
| Verification time (i9-12900) | ~24μs (ECDSA baseline) | Not benchmarked in study | <2μs |
| TLS handshake impact | Baseline | Significant at scale | No measurable impact |
| On-wire signature required | Yes | Yes | No (landmark mode) |
Sources: arXiv:2604.04191v1; ECDSA baseline measured on Intel i9-12900
The table makes the operational reality clear: adopting ML-DSA-65 without an architectural mitigation like MTC means accepting a 50× increase in certificate-related payload per handshake. In a Kubernetes cluster processing thousands of inter-component authentications per second, that translates directly into increased CPU cycles, network bandwidth consumption, and tail latency — all of which erode the performance margins your SRE team has carefully engineered.
The critical insight: Post-quantum security and performance are not inherently in conflict. MTC landmark mode delivers both — but it requires a deliberate architectural decision, not a drop-in algorithm swap.
Regulatory Timeline and Who Is Moving
The NIST Mandate Is Already in Effect
NIST finalized ML-DSA (FIPS 204) in August 2024. Federal agencies operating under OMB memoranda and CISA guidance are already under pressure to inventory cryptographic dependencies and begin migration planning. For enterprises in regulated sectors — financial services, healthcare, critical infrastructure — the compliance burden is not hypothetical: auditors are beginning to ask about post-quantum readiness.
The IETF’s Merkle Tree Certificates draft is currently under active development, which means the standardization window is open. Organizations that begin piloting MTC-based PKI architectures now will have a significant advantage: they will have operational experience before compliance mandates force rushed deployments.
Who Is Lagging and Why
Most enterprises running Kubernetes today use cert-manager with a traditional CA backend — a configuration that has no native path to MTC without architectural changes. Similarly, telecom operators running 3GPP 5G SBA deployments have PKI assumptions baked into their NRF and SCP configurations that predate post-quantum requirements entirely.
The migration path is not trivial. Replacing a cluster CA with an MTCA, deploying cosigner infrastructure, and distributing landmarks via DaemonSet requires deliberate planning. Organizations that treat this as a future problem will face it as an emergency when compliance deadlines arrive.
The Economic Case for Acting Now
The cost of inaction has two components. First, the performance tax: every month your infrastructure runs ML-DSA-65 without MTC mitigation is a month of compounding overhead at scale. Second, the migration cost curve: PKI architecture changes are significantly cheaper when planned proactively than when executed under regulatory deadline pressure. Emergency migrations introduce configuration errors, certificate chain breaks, and service outages that planned migrations avoid.
The BeQuantum Perspective: PKI Architecture as a Security Primitive
At BeQuantum, we treat PKI architecture as a first-class security primitive — not an operational afterthought. The MTC research validates an approach we have been advocating in our PQC Layer design: that post-quantum migration requires rethinking trust distribution mechanisms, not just swapping algorithm identifiers.
The landmark distributor pattern — where trusted Merkle roots are pre-positioned at every node via a DaemonSet — maps directly to how our PQC Layer handles trust anchor distribution in cloud-native environments. The key architectural principle is that verification speed at handshake time is determined by decisions made at infrastructure design time. Organizations that embed this principle into their Kubernetes and 5G Core deployments now will not need to re-architect under pressure later.
For 5G operators specifically, the NRF-as-MTCA and SCP-as-cosigner model described in the QORE architecture represents a clean integration point with existing 3GPP SBA topology. The trust hierarchy does not need to be invented from scratch — it needs to be mapped onto post-quantum primitives that the existing network functions already understand.
Our Digital Notary service extends this model to content and configuration artifacts: every signed artifact carries a verifiable MTC-compatible proof chain, ensuring that post-quantum integrity guarantees extend beyond TLS sessions to the software supply chain feeding your infrastructure.
What Your Team Should Do in the Next 90 Days
Step 1: Audit your TLS certificate chains for algorithm exposure (Days 1–30) Inventory every certificate in your Kubernetes control plane and 5G Core NRF/SCP configuration. Identify which are signed with ECDSA or Ed25519 and document their renewal schedules. This audit is the prerequisite for every subsequent decision — you cannot plan a migration you have not mapped.
Step 2: Stand up a non-production MTCA and benchmark your specific workload (Days 30–60)
Deploy an MTCA in a staging Kubernetes cluster using the Go crypto/tls and crypto/x509 MTC implementation. Measure TLS handshake latency under your actual inter-component traffic patterns. The 2-microsecond landmark verification figure is a single-node benchmark on an Intel i9-12900 — your production environment will have different characteristics, and you need your own data before committing to an architecture.
Step 3: Define your landmark distribution strategy before production rollout (Days 60–90) The DaemonSet-based landmark distributor is the operational linchpin of MTC in Kubernetes. Define your update cadence for Merkle root distribution, your rollback procedure if a landmark update fails, and your monitoring strategy for landmark staleness. These operational decisions are as important as the cryptographic ones.
FAQ: Merkle Tree Certificates and Post-Quantum PKI
Q: Does MTC provide post-quantum security, or does it just solve the performance problem? A: MTC addresses both concerns simultaneously. By replacing per-certificate issuer signatures with Merkle inclusion proofs, MTC eliminates the need to transmit large post-quantum signature artifacts (like ML-DSA-65’s 3,309-byte signatures) on the wire during TLS handshakes. The Merkle tree root itself can be signed with a post-quantum algorithm once, at publication time, rather than per-certificate — concentrating the post-quantum signature cost where it is manageable. The result is post-quantum security with classical-or-better verification performance.
Q: Is MTC ready for production deployment today?
A: MTC is currently under active development at the IETF and should be treated as a near-production technology requiring careful evaluation. The Go crypto/tls and crypto/x509 implementations described in the research provide a concrete starting point, but organizations should conduct their own security review and performance benchmarking before production rollout. The IETF standardization process will introduce refinements — early adopters should plan for protocol evolution.
Q: How does MTC interact with existing certificate transparency and revocation infrastructure? A: The research does not address backward compatibility with existing PKI infrastructure, certificate transparency logs, or OCSP/CRL revocation mechanisms in detail — this is an acknowledged gap. Organizations evaluating MTC should treat revocation strategy as an open design question requiring resolution before production deployment. This is an area where the IETF standardization process is expected to provide guidance.
Source: “Merkle Tree Certificate Post-Quantum PKI for Kubernetes and Cloud-Native 5G/B5G Core” — arXiv:2604.04191v1