Parameter Sets as Policy: Profiles, Weakest Links and One Estate

Every post-quantum standard comes in several sizes. Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) offers three, Module-Lattice-Based Digital Signature Algorithm (ML-DSA) three, and Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) twelve. Engineers tend to treat the choice as a trade between margin and bytes, pick a sensible middle, and move on. In a real estate, with customers in several countries, government profiles that disagree, cloud services that offer some sizes and not others, and a certificate chain built years apart, the choice is a policy question. And whatever is chosen can be silently undone by one weaker component that nobody looked at. This article shows how to read a parameter set as a promise, why a system's strength is the minimum over its parts, how three well-known government profiles differ, and a method for turning all of that into one enforceable policy that people and AI agents cannot route around.

What a security category promises

The United States National Institute of Standards and Technology (NIST) describes the strength of its post-quantum standards with five security categories, each defined by comparison with a well-understood attack on a symmetric primitive. Category 1 means breaking the scheme is at least as hard as finding a 128-bit Advanced Encryption Standard (AES-128) key by exhaustive search. Category 2 is at least as hard as finding a collision in the Secure Hash Algorithm SHA-256. Category 3 matches an AES-192 key search, category 4 a SHA-384 collision, and category 5 an AES-256 key search. The comparisons deliberately cover both classical and quantum attackers, so a category is a statement about the cheapest known way in, whoever the attacker is.

Each parameter set is placed in a category. ML-KEM-512, 768 and 1024 are categories 1, 3 and 5. ML-DSA-44, 65 and 87 are categories 2, 3 and 5. The SLH-DSA sets whose names contain 128, 192 and 256 are categories 1, 3 and 5, each available with the SHA2 or SHAKE hash family and in a small-signature 's' or fast-signing 'f' variant.

Going up a category costs bytes everywhere the key or ciphertext travels. Moving from ML-KEM-768 to ML-KEM-1024 grows the encapsulation key from 1,184 to 1,568 bytes and the ciphertext from 1,088 to 1,568. Moving from ML-DSA-65 to ML-DSA-87 grows the public key from 1,952 to 2,592 bytes and each signature from 3,309 to 4,627. Those are modest numbers in isolation and significant ones in a chain of certificates, a constrained radio link or a log that stores millions of signatures.

Two habits of thought help when reading these categories. The numbers in the names are not security levels: ML-KEM-768 does not mean 768 bits of security, and ML-DSA-65 is not 65 of anything a reader should compare. They describe internal sizes of the construction, so the category, not the name, is what policy should reference. And the categories are benchmarks rather than precise measurements; they say that the best known attack costs at least as much as the reference attack, which is why profiles and regulators can express requirements in categories without having to agree on exact bit counts.

The weakest link sets the category

A category is a promise about the cheapest attack, so a system made of several components is only as strong as its cheapest component to attack. Choosing ML-KEM-1024 buys nothing if the session it protects is encrypted with AES-128 in Galois/Counter Mode (GCM): an attacker who wants the traffic will attack the 128-bit cipher, not the key exchange, and the session sits at category 1. The same is true of the hash and key derivation function (KDF) that turn the shared secret into session keys, and of any random number generator that produced the keys in the first place.

Certificate chains are the classic trap. A service can present an ML-DSA-87 certificate, but if that certificate was issued by an intermediate authority whose key is ML-DSA-44, an attacker who can forge the intermediate's signatures can mint a convincing certificate of their own, and the chain is no stronger than category 2. The root above it, and any signatures on revocation data or transparency logs that verifiers rely on, belong in the same calculation.

The practical method is to write down every component an attacker could target for each protected asset, assign each its category, and take the minimum. The exercise usually shows that the expensive upgrade went to the component that was already strongest.

Hybrids and time add two refinements. In a hybrid key exchange such as X25519MLKEM768, the classical half protects against ordinary attackers if the post-quantum half ever turns out to be weaker than expected, but against an attacker with a large quantum computer only the post-quantum half counts, so its category is the one to put in the calculation. Time matters because the minimum must hold for as long as the protection must hold. Traffic that must stay confidential for twenty years needs every component to resist attack for twenty years; a signature that is checked once, at connection time, needs to resist forgery only until it is checked, unless it also protects something long-lived such as an archive, a firmware image or a root of trust.

Three profiles, three answers

Governments publish profiles that narrow the choice, and they do not agree. The Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) of the United States National Security Agency (NSA), as restated in an NSA-authored certificate profile published as an Internet Engineering Task Force (IETF) draft in October 2026, selects only the top category: ML-DSA-87 for signing and ML-KEM-1024 for key establishment, with SHA-384 or SHA-512 and AES-256, plus the stateful hash-based schemes LMS and XMSS for software and firmware signing. SLH-DSA is not part of the suite, and NSA has said hybrid combinations are not required.

Germany's Federal Office for Information Security (BSI), in technical guideline TR-02102-1 version 2026-01, recommends ML-KEM-768 and ML-KEM-1024, ML-DSA-65 and ML-DSA-87, and SLH-DSA only in its 192- and 256-bit sets. The smallest sets, ML-KEM-512, ML-DSA-44 and the 128-bit SLH-DSA sets, are not on its list. It asks for post-quantum key establishment to be combined with a classical scheme, a hybrid, and accepts purely classical key establishment only until 2031. France's National Cybersecurity Agency (ANSSI) prefers the highest category for ML-KEM, accepts category 3, and strongly emphasises hybrid use for products that need protection beyond 2030.

Timelines frame the same choices. NIST's draft transition report, Internal Report 8547, proposes deprecating quantum-vulnerable public-key algorithms at the 112-bit level after 2030 and disallowing quantum-vulnerable ones after 2035, and the United Kingdom's National Cyber Security Centre (NCSC) asks organisations to finish discovery and planning by 2028, migrate high-priority systems by 2031 and complete migration by 2035.

What the intersection costs

An intersection exists. For key establishment, a hybrid that pairs a classical elliptic-curve exchange with ML-KEM-1024 satisfies a profile that wants category 5, one that wants hybrids, and one that excludes the smallest sets. RFC 10024, published in August 2026, standardizes exactly such a combination for Transport Layer Security (TLS) 1.3, SecP384r1MLKEM1024, alongside the more common X25519MLKEM768. For signatures, ML-DSA-87 appears on every list.

The intersection is not free, and it is not always available. Every handshake and every signature grows. Platform defaults differ: the Go standard library enables its P-curve hybrids, including SecP384r1MLKEM1024, by default from Go 1.26, while the Java Development Kit 27 puts X25519MLKEM768 first and leaves the P-curve hybrids off unless configured. Pure ML-KEM groups for TLS are still waiting in the RFC Editor queue. Key stores constrain signatures too: at the time of checking, Google Cloud's key management service offered SLH-DSA only as SLH-DSA-SHA2-128s, a set outside BSI's list, and Amazon Web Services' key management service offered no SLH-DSA at all.

The costs also compound. A certificate chain carries several public keys and signatures, so moving every element from category 3 to category 5 multiplies the growth, and mutual authentication, in which both sides present chains, doubles it again. Some constrained devices cannot run the largest sets within their memory, energy or timing budgets at all, which is a further reason why a single estate often ends up serving different profiles from different endpoints.

So the honest outcome of a profile analysis is often a split decision: the strict intersection where a profile genuinely applies, and a lighter default elsewhere, with the boundary between them written down.

A method for one estate

A repeatable method turns this from a debate into an artefact. First, for each data domain, customer group or product line, list the profiles it must satisfy and why. Second, intersect them into an allowed matrix: permitted KEM sets, signature sets, hybrid requirements and symmetric and hash choices for that domain. Third, check every library, platform and key store on each path against the matrix, with a date. Fourth, where the intersection is empty or unavailable, decide explicitly, for example by serving a strict endpoint for one customer group, or by adopting the stricter choice everywhere, and record the decision and its owner. Fifth, enforce the matrix as policy-as-code: configuration linting for TLS group lists, certificate-profile checks at issuance, and key-specification checks when keys are created.

The fifth step is where most programmes stop short. A matrix in a document is advice; a matrix checked in the deployment pipeline is policy.

A worked example shows how the method behaves. Imagine, purely for illustration, a shared AI agent platform with three tenant groups: a German public-sector customer bound by BSI's guideline, a defence contractor bound by CNSA 2.0, and general commercial customers bound by nothing beyond good practice. The allowed matrices come out as hybrid ML-KEM-768 or 1024 with ML-DSA-65 or 87 for the first group, ML-KEM-1024 and ML-DSA-87 for the second, and the common X25519MLKEM768 with ML-DSA-65 for the third. Only hybrid ML-KEM-1024 with ML-DSA-87 satisfies all three, so the platform either serves that everywhere and pays its cost on every connection, or runs a strict endpoint for the first two groups and a default endpoint for the rest. Either answer is defensible; leaving the question unanswered is not.

When the smaller set is the right default

Not every system is bound by the strictest profile. Where no applicable profile asks for category 5, ML-KEM-768 and ML-DSA-65 are the balanced defaults: category 3, widely supported, and the sets most libraries and protocols treat as their main path. ML-KEM-512 and ML-DSA-44 remain legitimate, but as documented exceptions for constrained links or devices, chosen deliberately and recorded, rather than a way to shave bytes by default.

SLH-DSA choices also become policy questions. The hash family usually follows what the rest of the system and its validated cryptographic module already use, so SHA2 in an estate built around SHA-256 and SHA-384, and SHAKE where the platform is built around the SHA-3 family. The 's' variants, small signatures with slow signing, suit keys that sign rarely, such as release and root keys; the 'f' variants trade much larger signatures for faster signing and are worth their size only where signing throughput genuinely matters. In every case, check that the chosen set is offered by the key store that must hold the key.

Policy that AI agents cannot route around

AI agent platforms, the systems that run software agents which plan and act by calling tools, are a hard case for parameter policy. One shared platform often serves many tenants in several jurisdictions, and agents and AI coding assistants increasingly generate the configuration themselves: TLS group lists for outbound connections, certificate requests, key specifications for a key management service. An assistant asked to make a connection work will happily offer ML-KEM-512 to a peer, or request an ML-DSA-44 key, if that is what makes the error go away.

The answer is to make the allowed matrix machine-checkable and to give agents a vocabulary of named profiles rather than raw parameters. An agent requests a key under a profile such as 'eu-hybrid-cat3' or 'nss-cat5', and the platform maps the name to concrete sets; a generated configuration that offers a forbidden group to a tenant bound by a stricter profile fails a gate before it ships. Logging which profile each agent action used then turns policy compliance into something an auditor can query.

Logging closes the loop. When every agent action records which named profile it used, which key-exchange group was negotiated and which key specification signed its output, compliance becomes a query rather than a project, and drift, such as a new connector that quietly negotiates a group outside its tenant's matrix, shows up in the same dashboards that already watch errors and latency.

Decisions to write down

These are the decisions practitioners and security leaders actually face when parameter sets become policy. Each one should end up as a line in a document that has an owner and a review date.

1. For each protected asset, list every component an attacker could target and take the minimum category.
2. For each data domain, list the profiles that apply and intersect them into an allowed matrix.
3. Check libraries, platforms and key stores against the matrix, with dates.
4. Record explicit decisions where the intersection is empty or unavailable.
5. Default to the middle sets where no profile requires more, and document every smallest-set exception.
6. Enforce the matrix in pipelines, and give agents named profiles instead of raw parameters.

Glossary

Security category

One of five NIST strength levels, each defined by comparison with an AES key search or a SHA collision search.

Parameter set

A named, fixed choice of sizes inside a standard, such as ML-KEM-768 or ML-DSA-65.

Weakest link

The component of a system that is cheapest to attack, which determines the strength of the whole.

CNSA 2.0

The United States National Security Agency's algorithm suite for national security systems, which selects category 5 post-quantum sets.

Hybrid

A combination of a classical algorithm and a post-quantum one, so that security holds if either remains unbroken.

Allowed matrix

A per-domain list of permitted parameter sets, hybrid rules and supporting algorithms derived from the applicable profiles.

Policy-as-code

Expressing rules as machine-checkable tests that run in deployment pipelines rather than as prose guidance.

Further reading

1. CNSA 2.0 Profile for Certificates and CRLs, draft-jenkins-cnsa2-pkix-profile (IETF)
2. BSI TR-02102-1, Cryptographic Mechanisms: Recommendations and Key Lengths (BSI)
3. NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards (NIST)
4. Timelines for migration to post-quantum cryptography (UK NCSC)