Most certificate operations assume a credential will be used many times during a validity period and may need renewal or revocation. A recent IETF proposal explores a very different model. Updated October 27, draft-ietf-lamps-one-signature-certs-04 defines a certificate extension that binds a certificate to the content of one digital signature. The signing key is created for that signature, used once, and then destroyed.
The draft is a work in progress, not a final standard or deployment recommendation. It is valuable because it exposes how strongly today’s inventories assume reusable keys and time-bounded certificates.
The signed event becomes the center of the record
In the proposed model, the certificate is not merely a reusable identity credential. It is bound to one signed object, and the private key should no longer exist after signing. Inventory therefore needs to connect the certificate, key event, content, signer identity, authority, timestamp, validation material, and destruction evidence.
A defensible record would include:
- signed-object identifier, content hash, format, signature algorithm, and parameters;
- certificate fingerprint, serial number, issuer, extension values, and issuance evidence;
- public key, key-generation mechanism, execution environment, and cryptographic module;
- private-key custody boundary, proof of single use, destruction method, and destruction evidence;
- signer identity, role, authority, approval, and separation-of-duties controls;
- application, workflow, transaction, repository, device, host, location, and owner;
- certificate-chain material, trust anchors, policy identifiers, and validation rules;
- trusted time evidence and the validation time or policy time being asserted;
- retention period, data classification, legal or business purpose, and archive location;
- discovery source, timestamp, scope, confidence, and coverage gaps; and
- exception, incident, remediation, and independent verification evidence.
A row that merely says “certificate active” cannot describe this lifecycle. The meaningful state is whether the authorized signature occurred, the key was destroyed, and the evidence needed for future validation was preserved.
No revocation does not mean no governance
The draft’s design intends certificates without a revocation mechanism and without expiration, simplifying long-term validation under its assumptions. That does not eliminate governance. It moves governance earlier and makes issuance, identity proofing, authorization, signing context, and evidence preservation more important.
A reusable credential can be revoked after compromise because future uses must stop. A correctly destroyed one-time private key has no future use to revoke. But an organization still needs to investigate unauthorized issuance, false signer attributes, compromised signing environments, incorrect content binding, or inadequate key destruction. Status may attach to the signed event and supporting evidence rather than a reusable credential.
Key destruction becomes a positive control
Many inventories track creation, activation, rotation, expiration, revocation, and deletion. One-signature certificates add a sharper requirement: the private key’s destruction is part of the security model, and it occurs immediately after its authorized use.
That claim needs evidence appropriate to the environment. A software process, HSM, secure enclave, or remote signing service may expose different guarantees and logs. “Deleted” in an application database may not prove removal from memory, backup, replica, snapshot, queue, or hardware slot. Teams should define what destruction means, which component enforces it, and how auditors can verify the result.
Long-term validation creates durable dependencies
A signature meant to remain verifiable for years may outlive applications, suppliers, algorithms, certificate authorities, and infrastructure. The organization must preserve the signed content, certificate chain, policy context, trusted time, validation rules, and evidence in a form that future systems can interpret.
That is a cryptographic inventory problem and an infrastructure inventory problem. Records should identify where evidence is stored, who owns it, what formats and algorithms it uses, and what migration or archival process applies when those dependencies age. A CBOM can describe cryptographic components, but canonical asset and data relationships explain operational custody and location.
Post-quantum planning must consider the evidence lifetime
The draft is algorithm-agnostic at the lifecycle level, but long-lived signatures raise a familiar quantum question: how long must authenticity remain defensible, and when could the chosen signature algorithm cease to be trusted?
One-time key use reduces some exposure; it does not make a quantum-vulnerable signature algorithm quantum resistant. Inventory should record the signature algorithm, parameters, expected evidence lifetime, policy status, and any plan for renewal, wrapping, or preservation using later mechanisms. Vista can track and govern that work, but it does not generate PQC keys or perform every migration.
What organizations should do next
First, identify workflows that require durable proof of one authorized signature rather than reusable authentication. Do not treat the model as a general replacement for ordinary certificates.
Second, define stable identifiers linking content, signature, certificate, signer, transaction, signing environment, and archive. Specify the authoritative system for each relationship.
Third, document how single use and private-key destruction are enforced and evidenced across memory, storage, backups, hardware, and service boundaries.
Finally, test long-term validation independently and monitor the IETF work. Preserve uncertainty: implementations, policies, and final requirements may differ from the current draft.
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, DNS records, 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 proposal remains an active Internet-Draft. Its security, interoperability, issuance practices, archive requirements, and adoption may change through review. Whether it fits a regulated or evidentiary use case depends on applicable law, policy, trusted-time requirements, implementation assurance, and the complete validation environment.
Source
- One Signature Certificates, draft-ietf-lamps-one-signature-certs-04, Internet Engineering Task Force, updated October 27, 2026.