Summary

  • RFC 9925, published as an IETF Proposed Standard in February 2026, defines id-alg-unsigned: an X.509 signature algorithm with omitted parameters and a zero-length signature value.
  • The profile carries subject information without proof from an issuer. A populated issuer field may be retained as a compatibility placeholder, but the object remains neither self-signed nor self-issued.
  • Applications may accept the object only where they are not verifying an X.509 signature. Certification-path validators must reject id-alg-unsigned in place of a signature.
  • Removing a decorative self-signature can reduce post-quantum size, avoid cross-protocol key reuse and support keys that cannot sign. The standard is not a security bypass; it makes the missing edge explicit.
  • Any trust, integrity and authority must therefore arrive through another mechanism. A trust-origin and scope receipt should identify the bytes, external evidence, installer, trust store, permitted use, change history and removal path.

A certificate with an intentionally empty proof field

The most revealing value in RFC 9925 is zero.

An unsigned certificate uses the object identifier 1.3.6.1.5.5.7.6.36 for id-alg-unsigned. Its algorithm parameters are absent. Its signatureValue is a BIT STRING of length zero. The structure still looks like X.509 because that structure is widely supported for carrying a subject name, public key and extensions. But it no longer asks a parser to pretend that an issuer cryptographically endorsed those fields.

That is not the same as forgetting to check a signature. The standard gives the absence a name and a processing rule. A receiver that is not verifying certificate signatures may accept the unsigned algorithm. A receiver that is verifying them must reject it. A certification-path validator must never let the empty value stand where an issuer signature belongs.

The distinction is unusually clean: the object can be syntactically useful and cryptographically invalid as an edge at the same time.

This is where governance enters. Security interfaces often borrow authority from familiar shapes. A file called a certificate may be displayed with an issuer, validity dates and a green icon. An inventory may count it beside CA-issued credentials. An operator may remember that it came from a trusted appliance image but lose the record of who approved that image. RFC 9925 does not require any of these mistakes. Its precision makes them easier to see.

The node remains; the edge is gone

RFC 9925 offers its own graph model. An ordinary X.509 certificate relates two entities: information about a subject and proof from an issuer. In a public-key infrastructure graph, the subject and issuer are nodes; the certificate is an edge between them.

Some applications need only the node. A trust anchor begins a path rather than receiving authority from a certificate above it. A pinned TLS deployment may know a public key or fingerprint through a separate provisioning channel. A device may need an X.509-shaped container for a KEM key that cannot produce a signature. In those cases, creating a self-signature may satisfy syntax without creating useful trust.

The unsigned profile removes the fictitious edge. This improves the truthfulness of the representation. It also exposes the question that a self-signed wrapper could obscure: what made this particular node authoritative here?

RFC 5280 already answers part of that question. When trust-anchor information is represented by a self-signed certificate, that certificate is not included in the prospective certification path. Its name, algorithm and public key are inputs. The information is trusted because some trustworthy out-of-band procedure delivered it to path processing. Selection of trusted certification authorities is a local decision and can vary by application or path.

The self-signature was therefore never the ultimate source of trust. It could show that the holder of the public key produced a signature over the same object, and some applications used it as a corruption check. It could not prove that an administrator should install the key, that the subject name was accurate, or that the key should be authoritative for every use.

RFC 9925 strips away that ambiguity. The node is visible. The missing edge is visible. The external decision must now carry its own evidence.

A populated issuer can still be a placeholder

The hardest field is not the empty signature. It is the issuer name.

X.509 requires an issuer field and does not permit it to be empty. Existing applications may also expect a trust-anchor representation to have matching subject and issuer names. RFC 9925 therefore permits a sender to copy the subject into the issuer field. It also defines a short dedicated placeholder name.

Neither choice creates an issuer. The standard says so expressly. A repeated subject is a compatibility value, not evidence that the subject issued itself. The unsigned certificate is not self-signed because there is no signature; it is not self-issued because no issuing relationship exists.

This is a small but consequential example of Lu Heng's Policy Mirror. The record should show the power and event that exist, not the ones its legacy grammar seems to imply. A software screen that labels the placeholder as “Issued by” without qualification would turn a mandatory syntax slot into an institutional claim. A path visualizer that draws a loop from subject to itself would manufacture the edge the standard removed.

The same discipline applies to extensions. Authority key identifier and issuer alternative name describe an issuer and should normally be omitted. Key usage and basic constraints should describe the subject's intended role. A CA-capable subject can be marked as such, but that mark does not authorize its installation as a trust anchor. It describes capability; a separate authority chooses whether and where to rely on it.

Recognition is not verification

IANA has registered id-alg-unsigned. That allocation lets independent systems recognize the value and find the specification. It does not make the empty signature valid, authenticate the subject or approve a trust-store change.

The difference matters because registries are often read as endorsement lists. In this case the registry entry does almost the opposite: it gives software an exact value with which to identify a non-signature and enforce rejection in verifying contexts.

The safest default is deliberately uneventful. An unchanged X.509 validator should see an algorithm it cannot verify and reject the path. Software needs special handling only in the bounded context where it was already prepared to consume subject information without checking a self-signature.

RFC 9925 warns about the failure mode. If an application accepts the unsigned identifier inside a certification path, or anywhere an X.509 signature must be verified, it has bypassed the check. The document compares the risk to algorithm-confusion failures in other token systems. RFC 8725 states the broader principle: cryptographic libraries must let the caller select supported algorithms and must bind the declared algorithm to the operation actually performed.

An algorithm registry can make a state machine explicit. It cannot enforce the state transition inside every product. That proof belongs in implementation tests, configuration and operating evidence.

Why removing the signature can be safer

It would be easy to read “unsigned certificate” as a weakening. In the intended context, the opposite can be true.

Many self-signatures on trust-anchor representations are not checked. They exist because X.509 has a signature slot and because software expects a certificate-shaped container. With post-quantum algorithms, the unused signature can be large. If the subject is an end entity, producing it reuses the key in the X.509 context and the key's actual protocol, creating a cross-protocol surface. If the public key is for key encapsulation rather than signing, it may be unable to produce the placeholder at all.

Replacing an ignored cryptographic gesture with a named empty value reduces theatre. It tells implementers not to derive trust from that field. It lets a validator fail closed. And it avoids asking a key to perform a function outside its purpose.

The strongest defence of RFC 9925 is therefore that it narrows claims. The certificate does not lie about having an issuer proof. The application does not waste effort validating a self-signature that was never the reason for trust. The real trust mechanism can remain local and appropriate to the deployment.

That defence succeeds only if the local mechanism is visible to the people responsible for it. “Out of band” is a boundary description, not an explanation. It might mean a fingerprint checked in person, a signed firmware image, a protected configuration repository, an enterprise management transaction, a manufacturing ceremony or a manual administrator choice. Those routes have different owners, scopes and recovery properties.

Trust moved to the installer

RFC 6024 provides a useful vocabulary for the missing layer. A trust anchor represents an authoritative entity through a public key and associated constraints. A trust-anchor manager controls one or more stores. Stores may be application-specific, device-specific or shared. Recognition can be limited to a subset of users or purposes. Management operations add, remove or replace anchors, and a sound protocol authenticates both the source and the authority of the party supplying the change.

Those details reveal the governance shift. Once the file contains no issuer proof, the person or system that installs it is no longer performing clerical import. It is making the operative trust decision.

The installer must answer at least four questions. Are these the exact bytes approved? Is the supplying party authorized to propose this anchor? Is the installer authorized to change this store? For which applications, names, policies and time period should the key be trusted?

None can be recovered from the empty signature. A hash can protect byte identity but cannot explain scope. A secure channel can authenticate a source but cannot prove that the source may bind this application. Administrative privilege can execute a change but does not by itself supply policy authority. A successful path-validation test proves that the newly configured anchor enables a path; it does not prove the decision to enable that path was legitimate.

This is why external trust needs a record, not merely a mechanism.

A trust-origin and scope receipt

A useful receipt would begin with the object, not its filename. It would record a digest of the exact bytes, the unsigned-algorithm identifier, the subject public key and the relevant subject-role fields. It would state explicitly that the object supplies no issuer signature and is not eligible to satisfy a signature step in a certification path.

The next section would record origin. From which repository, device image, package, ceremony or administrator was the object obtained? Which external hash, signature, protected channel or physical comparison established its integrity? What evidence authenticated the source, and what rule showed that the source was authorized to provide trust information?

Then comes the decision. The receipt would name the competent installation role, decision time, target store and affected application or device population. It would enumerate the accepted namespaces, policies, purposes and validity window rather than treat presence in a general store as universal authority.

Finally, it would preserve lifecycle. What record supersedes this one? What event requires replacement or removal? Who owns the next review? How is a mistaken installation corrected, and how can a compromised manager or key be recovered without silently rebuilding every store?

The public or cross-team view can remain thin. It need not expose root-store contents, administrator credentials or security-sensitive distribution paths. It can publish the object digest, decision authority, bounded scope, current state, change lineage and correction contact while keeping operational detail in a protected evidence store.

The receipt does not make the object signed. It does not create a universal authority or require central registration of local trust. It simply keeps the decision that already exists from disappearing behind a familiar file extension.

Evidence boundary

No checked source establishes how widely RFC 9925 is deployed, which products support it, or whether any implementation mishandles it. The approved LAMPS charter shows continuing work on post-quantum PKIX and S/MIME mechanisms, but a charter is not deployment telemetry. The IANA entries prove allocations, not correct processing.

The Article also does not claim that every self-signature is useless. RFC 9925 acknowledges that some applications use one to detect accidental storage corruption; the unsigned profile then requires another integrity mechanism for that use. Nor does the Article claim every unsigned certificate is a trust anchor. The format may carry standalone subject information in other externally authenticated contexts.

What can be proved is narrower and sufficient. RFC 9925 deliberately separates subject data from issuer proof. It requires path validators to reject the empty signature. It locates integrity and trust outside the object. That is a sound technical boundary. Governance should make the external half just as inspectable as the internal one.

Sources

  1. Lu Heng, “The Policy Mirror”
  2. RFC 9925, “Unsigned X.509 Certificates”
  3. RFC 5280, “Internet X.509 Public Key Infrastructure Certificate and CRL Profile”
  4. RFC 4158, “Internet X.509 Public Key Infrastructure: Certification Path Building”
  5. RFC 5914, “Trust Anchor Format”
  6. RFC 6024, “Trust Anchor Management Requirements”
  7. RFC 8446, “The Transport Layer Security (TLS) Protocol Version 1.3”
  8. RFC 8725, “JSON Web Token Best Current Practices”
  9. IANA, “Structure of Management Information (SMI) Numbers”
  10. IETF, LAMPS Working Group charter