PKI Security Standards and the New Post-Quantum RFC 9909

A futuristic cybersecurity interface in a server room featuring a central shield icon and the text "PKI Security Standards" at the top. The design includes glowing blue nodes and digital icons representing encrypted data and network security.

PKI security standards continue to evolve as cryptographic risks change. One of the most important updates comes from RFC 9909, an Internet Engineering Task Force specification that defines how post-quantum signature algorithms integrate into existing X.509 certificate structures.

For enterprise environments, this PKI standard has a major impact.  It specifies the rules of how PQC certificates are structured which enables the PQC and PKI eco-system to build solutions that interoperate. This in turn, influences how IT organizations plan long-term certificate usage and cryptographic resilience.

Why RFC 9909 Matters to PKI Security Standards

Most current PKI deployments rely on RSA and ECDSA. However, advances in quantum computing threaten these algorithms. RFC 9909 responds by extending PKI security standards to support post-quantum signature schemes while preserving compatibility with today’s trust models.

This approach allows enterprises to modernize cryptography without replacing their entire PKI infrastructure.

Algorithms Defined by RFC 9909

RFC 9909 standardizes the use of SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), which is based on the SPHINCS+ submission to the NIST Post-Quantum Cryptography (PQC) standardization process.

While previous hash-based schemes like LMS and XMSS are stateful—meaning the signer must meticulously track every signature generated to avoid security failure—SLH-DSA is stateless. This is a massive advantage for enterprise PKI because:

  • Operational Simplicity: It removes the risk of “state reuse” that can occur during virtual machine snapshots or database backups.

  • Security Resilience: It relies on the security of underlying hash functions (like SHA-256 or SHAKE256) rather than complex mathematical problems vulnerable to Shor’s algorithm.

  • Interoperability: RFC 9909 ensures that SLH-DSA signatures and public keys are formatted consistently within the Object Identifiers (OIDs) and structures of X.509 certificates.

The RFC specifically defines:

  1. Object Identifiers (OIDs) for the different parameter sets of SLH-DSA.

  2. Public Key Encoding for the SubjectPublicKeyInfo field in certificates.

  3. Signature Formats that allow software to verify the authenticity of the PQC certificate.

Certificate Types Affected by Enterprise PKI Standards Changes

RFC 9909 primarily impacts certificates used inside enterprise environments, including:

  • Internal TLS certificates for application traffic

  • Machine and device identity certificates

  • Code-signing certificates used in software delivery

  • Long-lived certificates with extended validity periods

Because internal PKI lifecycles differ from public web PKI, PKI security standards updates will likely appear internally first.

Operational Considerations for PKI Teams

As enterprise PKI standards evolve toward post-quantum resilience, the “footprint” of cryptography changes. SLH-DSA provides high security, but it introduces significant performance and infrastructure trade-offs that IT teams must account for.

1. Increased Bandwidth and Storage

Unlike ECDSA, which is prized for its tiny signatures, SLH-DSA signatures are substantially larger (often exceeding 10 KB to 40 KB depending on the parameter set).

  • Impact: This can increase network latency during TLS handshakes and may exceed the MTU (Maximum Transmission Unit) of some network packets, leading to fragmentation.

  • Storage: Large certificates can bloat database sizes for device registries and certificate transparency logs.

2. Computational Overhead

SLH-DSA is computationally intensive. While verification is relatively fast, signing (the process of issuing a certificate or creating a handshake signature) requires more CPU cycles than classical algorithms.

  • Impact: High-volume Issuing CAs may require Hardware Security Module (HSM) upgrades to handle the increased load without bottlenecking certificate issuance.

3. Fragmentation and Legacy Support

During the transition, organizations will likely use Hybrid Certificates—certificates containing both a classical signature (RSA/ECDSA) and a post-quantum signature (SLH-DSA).

  • Impact: This ensures that older systems don’t “break” when they encounter a PQC certificate, but it further increases the total size of the certificate.

4. Managing Modern Policy

With CertAccord Enterprise, organizations can automate the deployment of these complex types. Rather than manually managing which devices get a classical vs. a post-quantum certificate, policy-driven automation ensures that the right algorithm is delivered to the right endpoint based on its capabilities.

Choosing Between SLH-DSA and ML-DSA

When selecting a post-quantum algorithm, most organizations will find themselves choosing between SLH-DSA (as defined in RFC 9909) and ML-DSA (FIPS 204, based on Dilithium).

While SLH-DSA is the “conservative” choice for long-term security, it has significantly different performance characteristics than ML-DSA.

Comparison: ML-DSA vs. SLH-DSA

Feature ML-DSA (Lattice-based) SLH-DSA (Hash-based)
Primary Use Case General-purpose (TLS, VPNs) High-assurance/Archival (Code signing)
Signature Size ~2.4 KB to 4.6 KB ~17 KB to 49 KB
Public Key Size ~1.3 KB to 2.5 KB Very Small (~32 to 128 bytes)
Signing Speed Very Fast Very Slow
Verification Speed Very Fast Slow
Security Basis Module-LWE (Lattices) Hash functions (Conservative)

Which One Should You Use?

Use ML-DSA (Dilithium) if:

  • Latency is critical: It is the NIST “primary” recommendation for general applications like web traffic (HTTPS) and internal application communication.

  • Handshake speed matters: Its smaller signature size is less likely to cause TCP fragmentation or slow down the “time to first byte.”

  • General PKI: Most enterprise machine identities and user certificates will migrate to ML-DSA.

Use SLH-DSA (SPHINCS+) if:

  • Maximum security is required: Because it relies only on hash functions, it is considered the most “future-proof” against unforeseen mathematical breakthroughs in lattice-based attacks.

  • Small public keys are needed: If your hardware is extremely storage-constrained for storing public keys, SLH-DSA keys are even smaller than RSA.

  • Signing is infrequent: It is perfect for Code Signing or Root CAs, where you sign a certificate or firmware once and don’t mind the computation time, knowing the signature will be valid for 10+ years.

Impact on Infrastructure

For the IT team, this means your PKI policy needs to be “algorithm-aware.” You shouldn’t use a “one size fits all” approach. You might use SLH-DSA for your Offline Root CA but ML-DSA for your Subordinate CAs that issue high-velocity TLS certificates.

Aligning PKI Security Standards with CertAccord Enterprise

CertAccord Enterprise helps organizations enforce consistent certificate workflows as PKI security standards change. Rather than focusing on discovery or alerting, the platform supports predictable certificate issuance, renewal, and revocation across complex environments.

By applying policy-driven automation, enterprises reduce manual handling and maintain stability while preparing for post-quantum adoption.

Long-Term Impact on Enterprise PKI Standards

RFC 9909 highlights the need for crypto agility. Over time, enterprises that align their processes with evolving enterprise PKI standards will reduce disruption and security debt.

Early planning ensures smoother adoption as post-quantum certificates move from theory into production systems.

Final Thoughts

RFC 9909 marks a significant milestone for PKI security standards. While adoption will be gradual, the implications are long-lasting. Enterprises that prepare their PKI operations now will remain secure, flexible, and resilient in the face of future cryptographic change.

Categories