Summary

  • RFC 9995 defines a COSE Hash Envelope whose payload is a digest; the required protected payload_hash_alg and optional protected preimage type and location describe how the digest relates to an external preimage.
  • A valid COSE signature or MAC can be checked without the preimage. It proves the protected envelope within the chosen key and application context, not that the original artifact is available, safe, current, semantically acceptable or authorized for use.
  • A relying system must execute and record the rest of the chain: identify the signer and purpose, retrieve under bounded policy, preserve exact bytes, recompute and compare the digest, parse and appraise the artifact, authorize the proposed action, then observe the effect.

The SBOM is missing when the decision arrives.

A supplier has sent a compact COSE_Sign1 message. Its signature validates. Its payload is the hash of a much larger SPDX document, and a protected header offers a location from which that document might be obtained. A verification dashboard can turn green before the first byte of the SBOM has crossed the network.

That green state is real. It is also narrow. The verifier has authenticated a protected digest claim under a key that the application accepted. It has not proved that the location responds, that redirects stay inside policy, that the bytes found there produce the digest, that the document is valid SPDX, that it describes the release under review, or that its contents permit deployment.

RFC 9995, published on the IETF Standards Track in July 2026, makes this separation useful. A signer need not move a large artifact merely to protect its digest. A remote signing service can receive a short value; a consumer can validate the envelope while the preimage lives elsewhere; a constrained exchange can avoid duplicating an artifact already held by another system.

The efficiency comes from a deliberate boundary. The digest is the COSE payload. The original bytes are not. The envelope answers a compact cryptographic question and leaves delivery, equality, meaning and action to later controls.

Envelope, digest and preimage are three different things

Operational descriptions often say that the “payload is detached”. That phrase hides three different states.

First is the preimage: the original SBOM, firmware package, evidence bundle or other byte sequence that was hashed. Second is the digest value placed in the COSE payload. Third, because ordinary COSE rules permit it, that small digest payload can itself be detached from the serialized COSE structure and supplied separately to verification.

RFC 9995 normally expects the digest to travel inline because it is small. Omitting the large preimage is the point of the Hash Envelope. Detaching the digest as well is a separate transport choice. A system that merely reports “detached content supplied” may therefore fail to reveal whether it supplied the 32-byte digest or the multi-megabyte preimage whose identity matters.

RFC 9052 supplies the underlying COSE structures. For COSE_Sign1, the signature calculation binds the protected headers, application-selected external authenticated data and the payload used in the Sig_structure. It does not protect unprotected headers. In a Hash Envelope, the full digest value used as the payload enters that construction. The unseen preimage does not magically enter it through association.

This creates two legitimate verification moments. One can validate the envelope without the preimage. Later, after obtaining exact candidate bytes, one can hash them and compare the result with the protected digest claim. Conflating those moments turns a useful two-stage protocol into an unsafe one-stage dashboard.

The protected labels carry coordinates, not the preimage

RFC 9995 registers three COSE header parameters.

payload_hash_alg, label 258, is mandatory. It identifies the hash algorithm that produced the digest payload. It must appear in the protected header and must not appear in the unprotected header. That placement prevents an intermediary from changing the algorithm coordinate without invalidating protection.

preimage_content_type, label 259, is optional and protected. It can identify a media type or a CoAP Content-Format for the bytes that were hashed. The distinction matters: ordinary COSE content_type, label 3, would describe the COSE payload—the digest—not the external preimage. RFC 9995 forbids label 3 in a Hash Envelope to prevent that ambiguity.

payload_location, label 260, is also optional and protected. It is a text string or URI that can help a verifier locate the preimage. Signing the hint prevents undetected substitution inside the envelope. It does not make the destination available, trustworthy, private, immutable or authorized for the verifier to contact.

The IANA COSE registry gives these labels stable coordinates and points to their specifications. RFC 8126 explains how registry policies coordinate assignments. Neither registry presence nor a reference is proof that a particular library implements the parameter correctly, that a received envelope conforms, or that an operator has approved its use.

Similarly, RFC 8610 gives CDDL a shared way to express CBOR structures. A grammar can distinguish required from optional fields and reject malformed shapes. It cannot establish provenance, availability or business meaning.

The type coordinate has the same limit. RFC 7252 supplies the CoAP Content-Format namespace that label 259 may use. A registered format helps select a parser. It does not prove that the bytes satisfy the parser, that the parsed assertions are true, or that the artifact is safe to consume.

Verification stops at the cryptographic scope

A valid signature is not “nothing”. It can establish that the protected headers and digest payload were not altered after an accepted signer produced the signature, assuming the algorithms and verification inputs are correct. A valid MAC can establish protection among parties sharing the appropriate secret context.

But the key is not its own identity. RFC 9052 expressly leaves the application responsible for associating a verification key with the correct signer and deciding whether that identity is authorized for the intended operation. A test key, an expired supplier role, a key valid for audit receipts, and a key valid to approve production releases may all produce mathematically valid signatures. Their powers are different.

External authenticated data sharpens this point. COSE can bind application context that is not transported in the message, but only if producer and verifier construct the same context under a defined profile. An empty or generic context does not acquire tenant, release, environment or transaction meaning merely because a signature passes.

RFC 9421 offers a useful contrast: HTTP Message Signatures select HTTP components and rely on an application profile to decide what the signature means. The Hash Envelope does not sign an HTTP request or grant authority to follow it. It signs or MACs a digest-centric COSE structure. The common lesson is scope discipline, not interchangeability.

Operators therefore need distinct verdicts: structure accepted; cryptographic operation valid; key mapped to an identity; identity authorized for this envelope purpose; required application context matched. Only then is the compact claim ready to inform the preimage-verification stage.

A location hint is an input to a downloader policy

When label 260 is present, a verifier may try to retrieve the preimage. “May” matters. Some consumers already possess the artifact and need no network request. An offline verifier can validate the envelope but cannot compare it with an absent preimage or derive the artifact’s utility. A high-risk environment may require a human or a brokered fetch rather than automatic dereferencing.

A signed URI remains attacker-influenced input unless the relying profile says otherwise. A trusted signer could be compromised. A signer authorized to attest digests may not be authorized to direct internal network requests. Old envelopes may name decommissioned or reassigned hosts. Redirects can cross origins. DNS, TLS identities, proxies and credentials can change between signing and retrieval.

RFC 9110 distinguishes resources, representations, content coding, locations and redirection in HTTP. Those semantics mean a downloader must decide which response bytes constitute the candidate preimage. It must also cap redirects, response size, decompression expansion, time, credential forwarding and accepted schemes; isolate network reach; and record the final origin and transfer transformations.

The most dangerous implementation is a privileged verifier that automatically dereferences any protected location. The signature makes the hint tamper-evident; privilege turns it into a network capability. Those are separate facts.

RFC 6920 separates hash-based naming from location. A hash name can support name-data integrity after content is found without prescribing how it must be found. RFC 9995 keeps the same valuable separation: the protected digest can identify the expected bytes even when mirrors, stores or transfer mechanisms change.

Exact bytes must meet the protected digest

After retrieval, the verifier applies the algorithm identified by label 258 to the exact preimage bytes and compares the result with the COSE payload. A media type, filename, semantic version or storage key is not a substitute for this comparison.

Exactness becomes subtle when a transport has multiple representations. RFC 9530 distinguishes a digest of HTTP content from a digest of selected representation data. Content codings can give one abstract resource different byte sequences. Its digest fields also do not provide authentication, authorization or privacy. An envelope profile must say whether the hashed preimage is the stored compressed file, decoded content, canonical serialization or another precisely defined byte stream.

Re-serializing a parsed JSON or CBOR document before hashing can change whitespace, map order, floating-point spelling or encoding. Transparently decompressing before comparison can change the byte sequence being proved. Normalizing line endings can make a convenient local document unequal to the protected preimage. The correct order is to preserve received bytes, apply only profile-authorized transformations, hash the specified bytes, then compare in a way appropriate to the implementation.

A match establishes byte equality to the digest claim with the security properties of the chosen hash and envelope algorithms. It does not prove that the bytes are fresh, complete for the relying purpose, free of malicious content or internally truthful.

Parsing starts after equality; appraisal starts after parsing

Suppose the candidate SBOM matches. The consumer can now parse it under the protected preimage type, if that coordinate is present and locally accepted. Parsing can still fail. A parser can succeed while schema constraints fail. A schema-valid document can name the wrong release. A document for the correct release can omit dependencies the policy requires. A complete document can reveal a prohibited component. Each transition has a different owner and evidence.

The envelope does not carry a universal freshness rule. A digest can continue to identify old bytes perfectly. A valid signature can continue to validate after the operational fact it represented has expired, unless the application profile binds time, release identity or revocation state and enforces it.

Nor does RFC 9995 authorize execution. It covers COSE_Sign, COSE_Sign1, COSE_Mac and COSE_Mac0. COSE_Encrypt and COSE_Encrypt0 are outside its scope. The document does not provide confidentiality or decide whether some future application hashes before or after encryption. An encrypted artifact, executable package or disclosure bundle therefore needs its own handling and authorization path.

The useful chain is longer than a boolean: obtain candidate bytes; prove their digest; parse under an accepted format; validate syntax and schema; appraise assertions against the intended release and policy; establish freshness; authorize the particular action; execute inside the proper control boundary; observe and retain the effect.

Algorithm identifiers enable change; they do not perform it

RFC 9995 says the combined security strength of hash and signature or MAC should be at least as strong as the payload hash. RFC 9053 defines COSE algorithms and their parameter requirements. A verifier still needs a local acceptance set that considers artifact lifetime, threat model, key strength and implementation support.

RFC 7696 explains why algorithm agility is an operational process, not the mere presence of an identifier. Producers need a way to emit a successor. Consumers need overlapping support. Policy needs a date after which the old combination is rejected. Stored envelopes and long-lived artifacts need an explicit transition and retention story.

A registry entry can remain stable while risk changes. A library can parse an identifier it should no longer accept. A dual-envelope migration can increase compatibility while creating downgrade ambiguity if policy treats “any valid envelope” as sufficient. Record which combination was required, which was presented, which verification path won and why.

The executed chain is the evidence

Heng Lu’s running-code principle shifts the final claim from configuration to execution. “RFC 9995 supported” is not enough. Evidence should show the exact preimage bytes produced, their digest, the protected envelope bytes, algorithms and key, identity and purpose decision, location policy, retrieval trace, recomputed value, equality result, parser and appraisal outputs, action authorization and observed effect.

His minimum initial specification argument fits the protocol’s shape. Common labels and structural rules keep independent implementations interoperable. Downloader privileges, accepted formats, signer roles, freshness, semantic policy, algorithm retirement, retention and rollback remain local decisions. Local freedom is credible when each boundary has a named owner and measurable result.

The reality-layer distinction prevents a compact envelope from collapsing several realities into one badge. The envelope parses. The signature validates. The preimage is obtained. Its bytes match. Its meaning is acceptable. The action is authorized. The effect is safe. These are seven claims, not seven phrasings of “verified”.

The sources here specify protocols and editorial doctrine, not adoption. They do not show how many products implement RFC 9995, how fast they are, or whether a named deployment follows this chain. The SBOM scene is a bounded example derived from the RFC’s own use of SPDX, not a report about a vendor.