Cryptographic agility often requires more than replacing one certificate in place. Systems may need a second certificate for a new algorithm while older relying parties continue using the original. Updated November 2, the IETF LAMPS Working Group’s X.509 Certificate Discovery draft describes a way for one certificate to reference another through a retrieval URI, algorithm information, and a certificate hash.
The document remains an Internet-Draft, not a final standard. Its operational lesson is already useful: fallback and companion certificates must be modeled as governed relationships, not as unrelated records that happen to share a subject.
The link between certificates is the important asset
An inventory that stores two certificate fingerprints without connecting them cannot explain why both exist, which one a relying party should select, or whether the reference resolves to the intended object. The relationship needs its own lifecycle and evidence.
A defensible inventory should connect:
- source and referenced certificate fingerprints, serial numbers, subjects, issuers, and validity;
- public-key and signature algorithms, parameters, extensions, and policy identifiers;
- retrieval URI, transport, hosting service, location, owner, and availability objective;
- certificate hash, hash algorithm, retrieval time, verification result, and retained evidence;
- application, service, endpoint, device, host, location, environment, and business owner;
- relying-party population, trust stores, libraries, versions, selection logic, and compatibility;
- private-key generation, custody, HSM or module, rotation, backup, and destruction;
- supplier, certificate authority, renewal workflow, incident path, and rollback plan;
- policy status, migration stage, exception, target state, and accountable work item; and
- discovery source, timestamp, scope, confidence, and known coverage gaps.
Those fields let teams ask which legacy clients still need the original certificate, which clients retrieve the companion, and what happens if retrieval or verification fails.
A URI is an infrastructure dependency
Referencing a certificate by URI moves part of trust operation into a hosting and delivery path. DNS, TLS, storage, routing, access controls, content type, cache behavior, availability, and change management can all affect retrieval.
The hash helps a relying party verify that the fetched certificate is the intended one, but it does not make the delivery service operationally irrelevant. If the URI becomes unavailable, points to stale content, or is blocked in a constrained environment, the relying party may lose the alternate path.
Certificate inventory should therefore link the URI to the infrastructure that serves it and the teams that own it. Monitoring should test both retrieval and cryptographic binding from representative client locations.
Algorithm agility becomes a selection problem
A multi-certificate design gives relying parties a choice, but choice creates policy. Which certificate is preferred? When is fallback permitted? Does failure to support the new algorithm cause a downgrade, a hard failure, or use of the older credential? How is the decision logged?
“Supports PQC” is not a sufficient state. Inventory should distinguish present, referenced, retrievable, verified, supported, selected, exercised, and retired. Runtime evidence is necessary because library capability and configuration do not prove what a relying party actually chose.
For hybrid or parallel migrations, each algorithm and certificate should remain separately visible, along with the selection rule and retirement condition. Vista can track and govern that work; it does not perform every certificate migration or generate PQC keys.
Discovery does not eliminate discovery gaps
The draft’s mechanism can help a relying party locate a related certificate, but it does not automatically reveal every certificate, key copy, endpoint, or trust-store dependency in an organization. Teams still need network, configuration, file, API, code, and supplier discovery appropriate to their estate.
Findings should join a canonical system of record with source, time, scope, and confidence. A failed URI lookup is not proof that the referenced certificate does not exist elsewhere, and a successful lookup is not proof that every client can retrieve or validate it.
What organizations should do next
First, identify applications that use parallel, fallback, cross-signed, transitional, or algorithm-specific certificates. Map the relying-party populations and selection behavior.
Second, represent certificate references as first-class relationships with URI, hash, algorithm, owner, policy, and lifecycle state. Link the hosting infrastructure and retrieval evidence.
Third, test compatibility, selection, failure, downgrade, caching, renewal, and rollback from real client classes and locations. Preserve exact versions and results.
Finally, monitor the LAMPS draft and supplier adoption. Treat the mechanism as planning input until final semantics, implementations, and policy are stable.
How Vista Platform helps
Vista Platform is a 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 certificates, keys, algorithms, applications, devices, hosts, locations, owners, suppliers, policy, exceptions, and migration evidence.
Vista Core is source-available 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
The specification is still evolving. Final extension semantics, client behavior, retrieval policy, interoperability, and implementation timelines may change. Even a final mechanism cannot determine the organization’s fallback policy or guarantee that every relying party observes the intended certificate path.
Source
- A Mechanism for X.509 Certificate Discovery, draft-ietf-lamps-certdiscovery-06, Internet Engineering Task Force, updated November 2, 2026.