Summary

  • draft-ietf-suit-update-management-16 makes update-management support an optional, deployment-specific fact that may be known out of band; an authentic manifest does not prove the target Recipient implements its commands.
  • Human-readable version fields are explicitly untrusted and display-only. Machine decisions, local authorization, wait events, installation and observed running state need separate receipts.

The envelope arrives before the capability does

Imagine the cleanest possible start to an update incident. The manifest verifies. Its author is recognized. Its component version looks current. A human-readable field says that another component must be at least a particular release. The operations screen therefore presents an update as both legitimate and urgent.

Nothing moves.

That scene is often narrated as a transport problem or a reluctant device. Revision 16 of the IETF SUIT update-management draft points to a more awkward possibility: the update instruction and the device capability are different facts. The document's extensions are optional to implement and optional to place in a manifest. Knowledge that a Recipient supports them is deployment-specific and may be established out of band.

The signature can authenticate the envelope and protect its contents. It cannot manufacture an optional command in code that does not implement it. Nor can it identify which private capability inventory, procurement profile or fleet database supplied the belief that the command would work.

This is a small sentence with a large operating consequence. A signed manifest is an instruction record. Recipient support is a running-system property. The deployment profile connecting them is a local agreement. The result of applying the instruction is a later observation. Treating those four records as one is how a stalled rollout becomes a green dashboard.

Revision 16 moved the burden into the deployment record

The change from revision 15 is unusually revealing. Revision 15 said that an unimplemented command or parameter had to make the Recipient reject the manifest. It also said that an author relying on update-management behavior had to ensure targeted Recipients advertised support before shipping the manifest.

Revision 16 replaces that paragraph with a shorter rule: support knowledge is deployment-specific and may be established out of band. This does not prove that deployed devices changed overnight. It changes the specification text and, with it, the evidence an operator should preserve.

An out-of-band capability assertion needs at least four coordinates: who made it, which Recipient population it covered, which implementation and version it described, and when it was last verified. “This model supports SUIT update management” is not enough if a fleet contains different builds, disabled features or a bootloader/application split. A procurement sheet may be true for the product line and false for the device in front of the update server.

The draft defines a deployment profile as the specification or agreement that selects locally open options and mappings. Crucially, that profile is not a new wire-format object. It can exist as configuration, documentation or organizational agreement. That makes it powerful and easy to lose. If a manifest depends on a profile but the execution receipt records only the manifest digest, the decisive policy context disappears.

A readable version is not the comparison value

Revision 16 also draws a bright line between two kinds of version information.

suit-set-version is machine-readable. When a release fits the draft's constrained encoding, an author should provide it so a Recipient can compare manifests deterministically. The machine representation excludes build metadata from precedence. suit-parameter-version carries a comparison operator and version for a component condition.

suit-text-current-version and suit-text-version-required serve people. One can display a current version; the other can explain a dependency. They may resemble executable expressions—>=1.2.5,<2 is the draft's example—but the processor must not interpret or process them. If readable and machine-readable records disagree, the machine fields are authoritative.

The security section is stricter still. Those free-text values are untrusted input. A Recipient must not evaluate them, execute embedded markup or allow them to override the machine decision. A renderer must prevent markup, control-code, log or interface injection.

This distinction is not cosmetic. A console that extracts a readable “required” string and turns it into a policy decision has promoted operator guidance into code. A console that merely displays the string but labels the update “compatible” has made a subtler mistake: it has presented a human-facing explanation as evidence that the processor evaluated the corresponding machine condition.

The useful comparison record therefore contains both surfaces without confusing them: the exact display text for operator context, the exact machine field used by the processor, the component whose version was observed, the source of that observation, and the Boolean result. If no machine field exists because the version could not be represented without loss of fidelity, the absence is itself material.

Priority requests authority; it does not possess it

The draft's update-priority parameter gives smaller integers higher priority. But local policy assigns meaning to the values. The priority is passed into suit-condition-update-authorized, which requests permission from an application and fails if permission is not granted.

That sequence prevents a common rhetorical shortcut. “Critical” is not a privilege. A negative priority value may invite a local application to take a faster path, but the application remains the decision point. The update authority has supplied an explicit request for authorization, not a command that erases local authority.

For an accountable rollout, record the raw priority, the deployment policy version that interpreted it, the decision-maker, the authorization result and the time. Otherwise, a later audit cannot distinguish “the author marked it urgent” from “the local controller permitted installation.”

Waiting is a state, not a polite synonym for success

The most operationally important part of revision 16 may be the wait directive. An update can pause for authorization, external power, network availability, another device's firmware version, a time, a time of day or a day of week. All declared events must be satisfied before processing continues.

Yet the mechanism of waiting is intentionally local. An implementation might block on a semaphore, suspend with an event handler, poll, or abort and restart when notified. These choices have different failure modes. A suspended process can lose state across reboot. A polling loop can waste energy. Abort-and-restart can repeatedly refetch or reevaluate conditions. The protocol model can remain coherent while operations cannot explain why the update has not advanced.

Some events need more local definition than their names suggest. Local-time waits require configured civil-time and daylight-saving rules; without them, the event is unsupported. A wait on another device's version requires a deployment profile to define the identifier namespace, uniqueness scope, version source and encoding. A byte string that points nowhere in the receiving deployment is not coordination.

The draft therefore recommends that management interfaces expose the extensions a Recipient supports and the reason an update is waiting or has failed. It also recommends policy for whether waits survive reboot, how an operator cancels them and whether a local timeout applies.

That is not optional observability decoration. It is the minimum evidence needed to distinguish five cases that look identical from a distant rollout counter:

  1. the Recipient never supported the directive;
  2. it supported the directive but could not map the event;
  3. it entered a valid wait whose condition has not occurred;
  4. the condition occurred but the processor did not resume; or
  5. the processor resumed and later failed on a different condition.

“Pending” collapses all five. A useful receipt names the current state, the unresolved event, its data source, the last evaluation, the persistence rule and the next authorized transition.

CoSWID describes software; it does not witness the boot

The draft can carry a CoSWID object to support software identification, SBOM and attestation use cases. That is valuable, but the text carefully avoids making CoSWID universal execution evidence. Not every Recipient processes it. A severable CoSWID can be discarded without invalidating the manifest signature. A non-severable, well-formed and policy-permitted field cannot by itself be a reason for failure, even when the Recipient does not consume the metadata.

CoSWID also exposes component and version detail that may help an attacker as readily as an authorized operator. Access control and the decision to sever the data are therefore part of the evidence path.

Most importantly, the software identifier travels with the update description. It can tell verification infrastructure what software to expect. It does not prove that a particular device installed that software, activated it after reboot or is currently executing it. Those claims require a later observation tied to the device and component.

The receipt chain that a signed manifest does not contain

A defensible SUIT operating record should preserve at least ten separate receipts:

  1. the exact draft/RFC and registry state used by tooling;
  2. the signed manifest and identified Manifest Author;
  3. the target Recipient and the source, scope, version and age of its capability assertion;
  4. the deployment profile and local mappings in force;
  5. machine-readable digest, version, priority, authorization, battery and time inputs;
  6. the result of every condition and command;
  7. entry into a wait, the unresolved event, or an explicit failure;
  8. fetch, write and install completion with the resulting component digest;
  9. activation or reboot and a running-component observation; and
  10. inventory or attestation reconciliation plus any later application result.

This does not turn every firmware update into paperwork. It stops one strong artifact—the signed manifest—from impersonating the rest of the system.

Revision 16 is still an Internet-Draft even though the Datatracker showed that the approval announcement had been sent. Its IANA actions were still in progress at the research freeze. The responsible operating posture is therefore doubly bounded: do not present the draft as a final RFC, and do not present its eventual registration as evidence that devices implement it.

The manifest can be authentic. The update can be well specified. The human explanation can be accurate. The device can still lack the optional command, wait forever on a local condition, install without activating, or activate without producing the expected application result. Each statement needs the receipt that belongs to its layer.

Sources