Summary

  • The LAMPS One Signature Certificates draft binds a certificate to one signing input through signedDocumentBinding, yet says that ordinary cryptographic signature validation can succeed without checking that binding. A green signature verdict and a successful dataTbsHash comparison are separate receipts.
  • The certificate also asserts that its private key was generated for one operation and destroyed immediately afterwards. That is a CA procedure claim, not an observation made by the extension. No expiration and no revocation channel reduce one lifecycle burden while moving long-term trust into CA policy, preserved evidence and future trust provisioning.

The certificate's notAfter value points to the final second of the year 9999. Its noRevAvail extension says that no revocation mechanism exists. Its signedDocumentBinding value contains a hash intended for one document. The ordinary signature verifies.

Which of those facts proves that the verifier checked the document binding? None of them.

Revision 02 of One Signature Certificates makes that separation unusually explicit. It defines a certificate created at signing time for a newly generated key, used for one digital signature and then immediately destroyed. The certificate is bound to the signed content, normally has no meaningful expiration and is intended to carry no revocation service. The design aims to simplify long-term validation by reducing the persistent end-entity key and revocation state that conventional reusable certificates accumulate.

The document is an active LAMPS working-group Internet-Draft in the IETF stream. Revision 02 is dated 1 July 2026, expires on 2 January 2027 and is intended for the Proposed Standard track. Datatracker lists it as a working-group document with IESG state I-D Exists. It is not an RFC, and its existence does not prove that a CA issues these certificates, that a signer destroys keys, that software checks the binding or that archived signatures remain valid.

One certificate, one document, several claims

The new certificate extension is called signedDocumentBinding. Its ASN.1 value contains dataTbsHash, hashAlg and an optional bindingType. The hash identifies the data to be signed. The binding type tells a verifier how that byte sequence was derived from the surrounding document format.

The extension therefore carries a precise scope coordinate: this public key certificate was issued for a particular signing input. It also carries a procedural statement. By adding it, the CA says the associated private key was generated exclusively for the bound document and destroyed after signing. Revision 02 says the details of that procedure and the assurance for destruction should be described in the certificate policy.

Those are not the same kind of evidence. A verifier can recompute a digest and compare bytes. It cannot look inside dataTbsHash and observe whether a remote service generated the key freshly, prevented a second use, erased every copy or followed the cited certificate policy. The certificate is an authenticated CA assertion about that process.

A durable receipt should preserve the extension value, the exact binding input, the digest result, the certificate policy identifier and version, the issuing service record, the key-generation event, the one signing authorization and the destruction evidence separately. Collapsing all of them into “one-time certificate valid” makes later audit impossible.

Signature validation can pass without the binding check

The security considerations state that verification of signedDocumentBinding is not required for successful cryptographic validation of the signature. A signature can validate even if the binding is never checked. The relying party should compare the signed content with dataTbsHash; performing that check enforces the intended certificate scope and reduces certificate substitution or unintended reuse.

This is the operational fault line. A library can return a correct signature result after processing the signature format and certificate public key. An application can turn that result into approval without invoking the additional binding procedure. The certificate may have been issued for a different signing input, or a key that was supposed to be single-use may have produced another valid signature. Ordinary signature mathematics does not answer that policy question.

The decision interface should therefore expose at least two statuses. signature_valid records the primitive and signature-format result. document_binding_match records the selected binding type, reconstructed bytes, digest algorithm, expected dataTbsHash and comparison result. If the second check was not performed, its state is not_checked, not passed and not an implicit property of the first verdict.

Whether an application rejects not_checked is a profile decision. The draft's SHOULD does not turn absence into success. Operators that depend on the one-document restriction need a local mandatory rule and evidence that every relevant validation path enforces it—including archive revalidation, batch verification, mobile clients and third-party validation services.

The binding type decides which bytes exist

The default binding applies when bindingType is absent. It hashes the exact input to the signature algorithm: XML SignedInfo, CMS DER-encoded SignedAttributes, or the equivalent signing structure. This sounds simple until the signed structure includes the certificate itself or a hash of it.

The certificate contains dataTbsHash; if the signing input also contains that certificate, computing either object first can depend on the other. Revision 02 therefore forbids default binding in those circular cases and defines format-specific exclusions.

For CAdES, the binding input is DER SignerInfo after removing SigningCertificate and SigningCertificateV2 attributes. For XAdES, it is canonicalized SignedInfo after removing references of the SignedProperties type while preserving every other character, whitespace and line feed. JWS and COSE use payload-only binding and exclude protected and unprotected headers.

The same human document can consequently produce different dataTbsHash values under different binding types. A matching JWS payload hash also does not prove that its protected header, key identifier, algorithm or certificate reference was identical. Those fields remain part of ordinary JWS validation and application policy, not of the payload-only certificate binding.

Record the format, binding identifier, canonicalization or exclusion rule, implementation version and exact reconstructed-byte hash. The proposed IANA registry asks future binding specifications to be deterministic, unambiguous and explicit about circularity. A registered name is still not proof that two implementations produced the same byte string.

No revocation available is a statement, not a cure

The draft recommends setting notAfter to 99991231235959Z, the conventional upper boundary used to signal no well-defined certificate expiration. It also recommends the RFC 9608 id-ce-noRevAvail extension, which says that no revocation information is available for this certificate.

Neither field proves why revocation is unnecessary. The argument depends on the operating model: the key existed only briefly, signed once and was destroyed; later revocation events therefore should not change the validity of the already-created signature at its established time. A reusable key has a broad future exposure surface. A genuinely destroyed one-time key has a much narrower one.

But the risk has not vanished. It has moved into the accuracy of the creation-time record. Was the key actually fresh? Was there only one authorized signing request? Did a backup, log, crash dump, HSM replication channel or retry path preserve it? Did destruction occur before any compromise? Did the certificate policy require and audit the same controls that the public certificate implies?

noRevAvail tells a relying party not to expect CRLs or OCSP for this certificate. It does not certify those answers. A validator must distinguish “no revocation mechanism by design” from “revocation data could not be reached” and from “the profile was not recognized.”

Issuance time inherits timestamp authority

Long-term signature validation usually needs a best-signature-time: the earliest trusted evidence that the signature existed. RFC 3161 provides one model through an independent time-stamp authority. Revision 02 reasons that a one-signature certificate is created at signing time, so its issuance time establishes the signing time, with the CA acting in a timestamp-like role.

That coupling is efficient, but it enlarges the CA's evidence surface. The issuer is no longer only vouching for identity and a public key. It is also asserting when the one signing event occurred, which content scope the certificate belongs to, that its procedure generated a fresh private key, and that the key was destroyed immediately afterwards.

An operator should make that authority explicit. Record whether best-signature-time comes from the certificate issuance event, an RFC 3161 timestamp, a Signature Validation Token, an archive evidence record or several of them. Preserve clock source, issuance transaction, policy and audit evidence. Do not silently treat a syntactically valid notBefore value as independent proof of event time.

Year 9999 does not make the CA immortal

Revision 02 also draws a necessary boundary around its non-expiring end-entity certificate. Validation remains limited by the ability to trust the issuing CA. Initial validation is assumed to occur during the CA certificate's validity period.

Later revalidation may require a verifier to retain the CA key as a local trust anchor, use cross-certification, retrieve renewed CA certificates from a repository or apply another trust-provisioning mechanism. How to establish CA trust beyond the CA certificate's own validity is outside the draft's scope.

The long end-entity notAfter value therefore removes one expiry check; it does not preserve the entire trust path until 9999. Algorithms age. Trust stores change. Policies are superseded. CAs close or rotate. Archives migrate content. Validation software disappears. The original signed bytes, certificate path, policy documents, timestamps, validation evidence and trust-anchor history must remain recoverable.

This distinction matters to procurement. A service that advertises “signatures valid forever” should be asked which artifacts it exports, who can revalidate without the service, how CA trust is preserved, what happens when algorithms become unacceptable, and how a failed one-time-key audit is handled when no end-entity revocation channel exists.

A certificate-bound document is not an authorized outcome

Even a complete binding check establishes a narrow relation: this certificate was issued for this reconstructed signing input under this hash algorithm and binding rule. It does not prove that the signer understood the document, held authority for the transaction, received the final representation, or caused the promised external result.

One-use key evidence also does not convert a signature into non-repudiation by itself. Identity proofing, consent ceremony, delegated authority, display integrity, application policy, legal context, delivery and archival custody remain separate. If the signed action releases money, software, credentials or regulated records, preserve the effect receipt as well as the signature receipt.

The most useful design discipline is to keep the chain typed: certificate syntax; path and trust; signature mathematics; document binding; CA procedure; key lifecycle; trusted time; signer identity and authority; application decision; durable storage; external outcome. A one-signature certificate can make the first half narrower. It cannot make the second half disappear.