Summary

  • RFC 9596 registers the protected COSE typ parameter so an application can distinguish the type of the complete COSE object from the content type of its payload.
  • The COSE library passes typ to the application and does not interpret it; a matching label becomes security evidence only when the application binds it to mutually exclusive validation, key and authorization rules.

A receiver opens a cryptographically valid COSE object. Its protected header says exactly what the complete object claims to be. The signature verifies. In many control planes, those two green checks are enough to choose a handler and begin work.

RFC 9596 supplies the first check and deliberately stops there. It adds typ, label 16, so an application that can receive several kinds of COSE object can disambiguate them. It does not make the generic COSE library the judge of that application meaning. The library passes the value through. The application decides what values it expects, what is missing, what is wrong and what must be rejected.

The difference is small in bytes and large in authority. A protected declaration can name an object class. It cannot grant that class permission to act.

The complete object and its payload have different labels

COSE already had a content type header. RFC 9052 defines it as the type of the data in the payload or ciphertext field. RFC 9596 adds a different statement: typ declares the type of the complete COSE object.

The distinction matters whenever one envelope can carry another. A signed security event can contain a structured payload. A token can appear inside a larger message. A relying application may accept several signed object families whose payloads all use CBOR. Saying “the payload is application/cbor” does not say whether the outer object is an authorization request, an attestation result, a receipt or a status message.

RFC 9596 reuses the content-type value syntax. A typ can be an unsigned integer from the CoAP Content-Formats registry or a text media type, optionally with media-type parameters. Reusing syntax does not merge meaning. One field classifies the complete COSE object; the other classifies what is carried inside it.

An evidence system should therefore preserve both exact received values and their locations. If it stores only a normalized media label, it loses whether the sender typed the envelope, the payload or both. That missing distinction can make a later investigation reconstruct a security decision that no component actually made.

Protection makes the declaration tamper-evident, not self-enforcing

RFC 9596 says typ must not appear in unprotected headers. In a COSE construction that authenticates the protected-header bucket, changing the type value breaks the cryptographic verification. That prevents an intermediary from freely rewriting the declared object class while leaving the signature valid.

But integrity is not interpretation. The RFC says COSE implementations ignore typ except for passing it to the application. All processing is application-specific. A library can return “signature valid” and a protected type value without knowing whether the endpoint accepts that type, whether its profile requires the parameter, or which claims must follow.

That is the central operational boundary. A protected field proves that the field travelled inside the authenticated structure. It does not prove the field is correct. A signer can faithfully sign a false label, use an obsolete alias, choose a type meant for another endpoint or sign an object with the right type and the wrong payload.

The application must supply the missing rules. RFC 9596 says an application using explicit typing should reject an unexpected value and should reject absence when a type is expected. Those rejection paths are the security mechanism. Merely displaying typ in a decoded-object view is not adoption.

Explicit typing closes one confusion path, not every substitution path

RFC 9596 imports the explicit-typing argument from RFC 8725. That JWT guidance describes how one kind of token can be confused for another and recommends distinct typ values for new uses. It immediately adds a harder requirement: validation rules for different token kinds must be mutually exclusive.

This is why a type allow list cannot stand alone. Suppose an endpoint accepts two COSE object types but routes both through the same claims parser, trusts the same keys without purpose restrictions and applies the same audience defaults. The labels differ, yet the acceptance surface is still shared. An object of one class may satisfy enough generic checks to reach an action intended for the other.

A robust branch binds the type to its full contract: allowed structure, required protected fields, payload content type, required claims, issuer, audience, key purpose, freshness rules, replay handling, endpoint and permitted operation. A wrong type must fail before shared business logic erases the distinction. A missing type must not silently inherit a default if the profile expected explicit typing.

RFC 8725 also warns that explicit typing may not disambiguate from older token kinds whose validators ignore typ. That warning carries cleanly into COSE. Adding a label to the sender does not upgrade every receiver. Migration evidence needs the receive-side rule version, not merely a count of newly labelled objects.

Registries coordinate names; they do not decide trust

IANA records typ as COSE header label 16 and points value interpretation toward the CoAP Content-Formats and Media Types registries. That creates a shared namespace and compact representation. It does not turn every registered media type into an accepted application object.

A registry can answer whether a number or name has an assigned meaning. It cannot answer whether this endpoint enabled the type, whether this signer may use it, whether the selected media-type parameters are allowed, or whether the payload conforms. Registration is a coordination fact. Acceptance remains local.

This is Minimum Initial Specification at useful scale. The common layer defines a protected place for the declaration and interoperable value syntax. The future decision stays with the application profile and deployed validator. Voluntary adoption becomes observable only when receivers enforce distinct rules and reject the wrong branch.

The danger begins when a central inventory is promoted from “known type” to “trusted type.” A platform team may maintain a global catalogue for discovery, but every use still needs endpoint-specific policy. Otherwise adding one new registered type expands the authority of every generic consumer that treats catalogue membership as permission.

A clean evidence chain keeps the green checks separate

For each received object, preserve a digest of the received bytes; COSE structure kind; protected-header bytes; exact typ value and representation; exact payload content type; endpoint and operation; expected type set; validator-policy version; cryptographic result; key identifier and authorized purpose; payload parse result; required-claim result; issuer and audience checks; replay and freshness result; authorization decision; dispatched handler; and observed effect.

These are not redundant logs. They answer different disputes. A valid signature establishes a bounded cryptographic relation. A matching typ establishes that the declared object class was the one expected in that context. A successful payload parse establishes syntactic conformance. Profile validation establishes the required semantics. Key policy establishes that the signer was authorized for the class. Local authorization establishes that this operation may proceed now. The application result establishes what actually happened.

Do not ask the COSE library to speak for the final action. Do not ask the media-type registry to speak for a key. Do not ask a valid signature to repair a missing audience. Each component should issue only the receipt it can observe.

That discipline follows the reality layers in docs/heng-lu-note.md. Symbolic power accumulates when a compact label appears to settle everything downstream. Running-code primacy reverses the order: the label proposes a branch, deployed validation proves that the branch was enforced, and the resulting action remains a later fact.

Sources