Summary

  • RFC 9943 makes a bounded claim possible: a transparency service registered a signed statement under a policy and issued a receipt with verifiable data-structure proofs. That is evidence about a record, not a blanket approval of the artifact described by the record.
  • A responsible organization still has to choose its issuers, verify the relevant receipt, apply its own rules, name the person or body that may allow or hold a release, and retain a correction path. A receipt cannot silently make those choices for it.

A strong record can still be a narrow record

It is tempting to compress a supply-chain review into a reassuring sentence: “the artifact has a transparency receipt.” The sentence sounds like a conclusion. Under RFC 9943, it is better read as the start of a chain of questions.

The RFC, published in June 2026 as an IETF Standards Track document, describes an architecture for signed statements about supply-chain artifacts. A producer, analyst, auditor or other issuer creates a signed statement. The statement can concern an SBOM, an endorsement, an end-of-life notice, an advisory, or another serializable description of an artifact. A Transparency Service, or TS, may accept the signed statement for registration. Registration applies the service’s Registration Policy, adds the statement to a Verifiable Data Structure and produces a Receipt.

The resulting transparent statement carries evidence that the statement entered that particular structure.

That is consequential evidence. A receipt can support an inclusion proof. Some systems can provide consistency or other proof types too. The structure can help auditors ask whether entries form a consistent, append-only history. A later reader can inspect which statements an issuer has made about an artifact rather than accepting a mutable web page as the whole record.

But none of those properties is an instruction to ship code. The record may contain a statement about an artifact. It does not transform the statement into a risk assessment, bind a release manager, accept commercial liability, identify every affected system, choose a rollback threshold, or decide which supplier an organization is entitled to trust. The difference is not an implementation nuisance. It is where responsibility remains visible.

Four propositions that should not borrow each other’s authority

A disciplined review separates at least four propositions.

First, an issuer signed a statement. A valid signature can bind a statement and its stated metadata to a key under the applicable cryptographic rules. It does not, merely by being valid, prove that the issuer is the organization a relying party meant to trust, that the issuer had authority to make this kind of assertion, or that the assertion is accurate.

Second, a particular TS registered that statement. RFC 9943 defines registration as submission, application of the TS’s registration policy, insertion into the verifiable structure and receipt production. The policy is a precondition derived from non-opaque envelope header and metadata. It may be demanding, modest, sector-specific or limited by design. A registration result therefore speaks about the checks the named service performed under its named policy; it should not be inflated into every check a downstream organization may need.

Third, a relying party verified a receipt that it considers acceptable. This is an independent act. The RFC requires a relying party to trust the verification key or certificate and associated identity of at least one receipt issuer. It permits a relying party to accept one receipt and to apply arbitrary validation policies after it has checked the transparent statement. In plain terms, a receipt carries no universal acceptance rule inside itself. Somebody has to decide which service key, issuer identity, proof profile, freshness condition and statement type count for this use.

Fourth, an accountable authority made an operational decision. A release board may allow an artifact into production. A security team may hold it pending investigation. A procurement function may accept it for a defined contract. An operator may keep a currently running version while declining the next one. Each decision has a different mandate, consequence and repair path. None becomes true simply because a cryptographic record is well formed.

The four events can occur in a healthy order, but they are not interchangeable. A signed assertion can be registered even if a particular customer will not accept its issuer. A relying party can verify a receipt and still hold the artifact because a local exposure, licence, compatibility issue or emergency policy changes the decision. An organization can deploy a version through an emergency process and later seek to complete its evidence. The last example is not a recommended shortcut; it shows why an evidence record and a decision record must remain distinguishable if an exception is to be audited rather than hidden.

Policy has a clock, and a log has a scope

RFC 9943 makes this temporal boundary unusually clear. The operator of a TS may update its Registration Policy or its trust anchors. At the same time, the TS must make enough material available for auditors to reproduce the checks defined by the policy at the time of registration. The correct question after a receipt is therefore not only “does this proof verify?” It is also “under which policy, at what time, with which key and for which statement was this result produced?”

That is not an argument against policy change. A service may need to change its key material, tighten an admissibility rule or adopt a new profile. The point is that a later policy cannot silently describe an earlier registration, and an earlier receipt cannot silently stand for an organization’s current release policy. Both have dates and scopes.

The same caution applies to sequence. A verifiable structure can present an append-only order of registered statements. RFC 9943 says a relying party cannot assume that this order matches the order in which statements were issued unless the registration policy advertises that property. A log position therefore does not, by itself, establish which security notice was written first, whether a fix preceded an advisory, or whether a manager saw the evidence before an operational decision. Those are separate facts that need their own timestamps and custodians.

Nor does transparency settle truth. RFC 9943 says directly that an issuer can make a false statement intentionally or unintentionally. A statement can later be superseded; different issuers can make conflicting statements about the same artifact. The architecture lets a relying party examine a history and decide which issuers to trust. It does not appoint the architecture as the referee of every disagreement.

The missing object is often the decision, not another signature

Many organizations already preserve the technical parts: an artifact digest, a signed attestation, a receipt and perhaps a policy name. They then leave the decisive step in a chat message, an undocumented emergency approval or a dashboard toggle. The system appears transparent precisely until someone asks why a vulnerable, incompatible or disputed artifact was allowed through.

A small release-decision receipt can expose that step without turning internal review into public surveillance. For each consequential allow, hold, deny or exception, it should identify the immutable artifact version; the relevant statement and issuer; the named TS; the registration-policy version and registration time; the receipt-verification result and recheck time; the local policy or exception under which the case was decided; the authorized decision-maker; the result; the next review or expiry trigger; and the correction, rollback or appeal route.

This is not a new SCITT requirement. It is a governance record that consumes SCITT evidence without impersonating it. A company can keep confidential test details, customer identifiers and exploit-sensitive material protected. It can still make the accountable edge inspectable to the people who must audit, correct or challenge the decision.

That distinction also keeps automation honest. A pipeline may verify a receipt automatically and enforce a pre-declared local rule. The useful audit record should say that the rule executed, which version executed, what it evaluated and which authority adopted the rule. “The log allowed it” is not a sufficient explanation if the actual system allowed it because a human or organization selected that rule months earlier.

The standard leaves the right room for local judgement

RFC 9943 does not pretend otherwise. It leaves management and storage of statements, as well as how participants discover and notify one another of changes, outside its scope. It permits relying parties to apply their own policies after verification. Those limits make the standard more usable, not less. A software producer, public purchaser, regulated operator and volunteer maintainer do not share one risk mandate merely because they can verify the same receipt.

The danger begins when a technical control is offered as a substitute for that mandate. A buyer may say that a registered supplier statement means due diligence is complete. A release team may say that an inclusion proof means a risk owner approved. A service operator may say that an issuer signature means a component remains appropriate after a newly discovered flaw. In each case, a true but bounded technical fact is being asked to carry a decision nobody has placed on the record.

The better posture is more modest and more demanding: verify the receipt for the property it proves; preserve the policy and time that give it meaning; then record who chose what to do with that evidence. That sequence makes it possible to locate both a cryptographic failure and a governance failure. It never needs to pretend they are the same kind of failure.

Sources

  1. RFC 9943: An Architecture for Trustworthy and Transparent Digital Supply Chains
  2. IETF Datatracker: RFC 9943
  3. RFC 9942: CBOR Object Signing and Encryption (COSE) Receipts
  4. RFC 9162: Certificate Transparency Version 2.0
  5. RFC 9052: CBOR Object Signing and Encryption (COSE): Structures and Process