On November 6, the IETF published RFC 10073, Composite ML-DSA for Use in X.509 Public Key Infrastructure, as a Proposed Standard. It defines composite signature schemes that combine ML-DSA with traditional algorithms including RSA, ECDSA, Ed25519, and Ed448, presenting the combination as one atomic public key and signature at the protocol layer.
This is a concrete standards milestone, but it is not a universal instruction to deploy composite certificates. The RFC says the combinations target settings that want additional protection against a break or implementation failure in ML-DSA and that can accept the specified security properties. Adoption remains a policy, interoperability, certification, and operational decision.
One algorithm identifier contains multiple governed parts
A composite certificate may look atomic to a protocol, yet its security and operability depend on both component algorithms and the rules that bind them. An inventory record that stores only the top-level object identifier loses information needed for transition and incident response.
A useful inventory should connect:
- composite algorithm identifier, parameter set, encoding, context, prefix, and pre-hash behavior;
- ML-DSA component and traditional component, including exact variants and security levels;
- each public and private key component, generation method, custody boundary, export policy, rotation, and destruction evidence;
- certificate fingerprint, issuer, subject, validity, key usage, policy, chain, trust anchor, and revocation path;
- CA, HSM, enrollment service, library, firmware, application, endpoint, and relying-party versions;
- device, host, service, environment, location, owner, supplier, and business dependency;
- issuance, parsing, path validation, signature verification, rollover, revocation, and rollback test results;
- applicable profile, regulatory basis, internal policy, exception, target state, and migration work item; and
- discovery source, observation time, scope, confidence, and known coverage gaps.
Those links let an organization respond when either component, an implementation, or an interpretation rule changes.
Composite does not mean universally backward compatible
RFC 10073 describes protocol-level compatibility in the sense that composite values fit structures already able to carry algorithm identifiers, public keys, and signatures. That does not mean unmodified legacy software will recognize new identifiers, accept larger objects, or validate both components correctly.
Teams should test every relevant CA, HSM, enrollment path, directory, gateway, parser, trust store, application, and monitoring tool. Failure may appear as rejection, truncation, unsupported-algorithm errors, path-building differences, or silent fallback elsewhere in a workflow.
Inventory needs separate states for advertised support, configured support, successful issuance, successful deployment, observed presentation, and verified relying-party acceptance. A vendor feature matrix is not production evidence.
Policy applies to the combination and its parts
The RFC includes several combinations because deployment environments and regulatory expectations differ. Organizations should not reduce this choice to “composite enabled.” They need an approved profile that names allowed combinations, certificate roles, transition periods, and deprecation rules.
If the traditional component later becomes unacceptable, the organization must know whether policy permits the composite as a temporary configuration, requires a new pairing, or requires a move to a pure post-quantum form. The same question applies if an ML-DSA implementation is found defective while the underlying algorithm remains sound.
Exceptions should identify the affected assets and relying systems, the reason, compensating controls, owner, review date, and exit criteria. Otherwise, transitional combinations can become permanent by inertia.
Size and lifecycle effects need evidence
Composite keys, signatures, certificates, and chains are larger than their traditional counterparts. That can affect handshake size, fragmentation, storage, directory limits, HSM capacity, logs, telemetry, and constrained devices.
Testing should use representative chains and real paths rather than isolated signature benchmarks. Include issuance throughput, validation latency, network loss, intermediaries, renewal, revocation, failover, backup, restoration, and rollback. Retain exact versions, configurations, results, and timestamps beside the canonical assets.
What organizations should do next
First, identify X.509 use cases where a composite profile has a documented policy or risk rationale. Avoid treating every certificate population as identical.
Second, build component-level records for algorithms, keys, certificates, implementations, trust paths, owners, and relying systems.
Third, perform end-to-end interoperability and lifecycle tests across representative infrastructure, including failure and rollback.
Finally, govern deployment as a migration state with explicit entry, evidence, review, and exit criteria. Publication of an RFC creates an option; it does not complete an organization’s risk decision.
How Vista Platform helps
Vista Platform is a proprietary, self-hosted infrastructure inventory and DCIM platform with cryptographic posture built in. It serves as a cryptographic system of record through discovery, canonical inventory, evaluation, action, and proof. Teams can connect cryptographic implementations and policy to applications, devices, hosts, locations, owners, suppliers, exceptions, and migration evidence.
Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted rather than indiscriminate network scanning. Vista is not a vulnerability scanner, and discovery gaps are not proof of absence.
Explore Vista’s cryptographic inventory, post-quantum migration, and CBOM and compliance resources.
Where uncertainty remains
Implementation availability, certification, supplier support, regulatory acceptance, performance, and interoperability will vary. Composite protection depends on correct binding and verification of both components, not merely their presence. Discovery of an algorithm identifier is not proof that every key, certificate path, or relying system has been observed.
Source
- RFC 10073: Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for Use in X.509 Public Key Infrastructure, Internet Engineering Task Force, November 6, 2026.