Summary

  • draft-ietf-suit-report-22 allows a report to say suit-report-reason-invoke-pending because remote-attestation evidence may need to be signed before an invoked program receives control and possibly never returns.
  • Authentication protects the report, not the future. The compact records also require the exact digest-matched manifest, and attestation requires measurements of the processor and report-generating environment.
  • A defensible deployment separates report signature, freshness, manifest reconstruction, environment appraisal, invocation handoff, first execution, sustained runtime and service outcome.

The last honest statement before control disappears

Consider the final instruction in a secure update sequence. The manifest processor has validated the envelope, followed the command path and assembled a status report for remote attestation. The next command invokes the new code. Once control is transferred, that code may never return to the processor that created the report.

The tempting implementation is to sign success first and invoke second. It produces a neat attestation object and a green result that can travel upstream. It also states something the device does not yet know.

Revision 22 of the IETF SUIT reporting draft deals with that timing problem explicitly. Its result vocabulary includes suit-report-reason-invoke-pending: invocation is about to be attempted and the final outcome is not known. The accompanying note explains why. Implementations often need to sign remote-attestation evidence before calling code that may not return. Signing unconditional success would be misleading if the invocation later failed.

That is not an admission that invocation failed. Nor is it a weaker spelling of success. It is a precise boundary in time: the reporting system has reached the handoff, and the statement has been sealed before the outcome exists.

The distinction matters because cryptography can make a premature claim more convincing without making it more true. A valid signature tells the verifier that protected bytes came from the expected key and were not altered. It does not move the clock forward.

The report is compact because the manifest carries half its meaning

A SUIT_Record is not a prose log. It identifies a path through the manifest dependency tree, the active command sequence, a byte offset, a component index and measured properties. The manifest itself acts as the dictionary from which the verifier reconstructs the decision.

This design is economical for constrained devices, but it creates a strict interpretive dependency. Revision 22 says the records are meaningful only when the matching manifest can be obtained and validated with suit-report-manifest-digest and, when present, the manifest URI. A recipient must not use the records to reconstruct execution without that matching manifest.

The digest is not decorative metadata. The draft prefers it because sequence numbers can collide, particularly when more than one signer is trusted. “Sequence 47” can describe two authorised histories. The characteristic digest points to one exact manifest.

Standalone system-property-claims have a narrower exception. They contain a component identifier and may be processed without first obtaining the manifest. That exception reinforces the rule: an explicit component claim is self-locating in a way that a waypoint offset is not.

Operations therefore need to preserve the report and its dictionary as a pair. A signed report whose referenced manifest has disappeared is not a complete audit record. The bytes remain authentic, but the compressed path can no longer be interpreted safely.

Freshness answers a different question

The report may carry suit-report-nonce for freshness or replay protection. The nonce may be omitted when the authenticating container already supplies freshness—for example, when an attestation exchange includes a challenge.

This produces another separation that dashboards often erase. Authentication asks whether the report is genuine and intact. Freshness asks whether it belongs to the present exchange rather than an earlier one. The manifest digest asks which instruction dictionary gives the waypoints meaning. The result field says what the processor was prepared to assert at signing time.

None of those fields says that the invoked code is still running ten seconds later. A fresh statement of invoke-pending is still pending. An old success report may be authentic and irrelevant to the current boot. A digest match may be exact while the signer lacks authority for this fleet. Each control protects a different failure mode.

Who measured the measuring machine?

Revision 22 is unusually direct about using a SUIT Report as Attestation Evidence. The environment that generated the report must also be measured. That normally includes the Manifest Processor, the Report Generator and the bootloaders or operating systems that enable them to run.

Without those measurements, a relying party can validate a report container while knowing too little about the machinery that selected and assembled its claims. A compromised report generator may sign an internally consistent story. A modified processor may emit truthful bytes about decisions made by the wrong code.

RFC 9334 helps keep the roles straight. An Attester produces Evidence. A Verifier appraises that Evidence under policy and produces Attestation Results. A Relying Party uses those results to decide. Trust is the relying party's decision; trustworthiness is a quality about the system. The signature does not collapse those roles.

The SUIT draft adds a practical translation step. Its waypoint log is designed around the manifest, not around the questions a relying party wants to ask. A verifier with the matching manifest reconstructs the path and turns it into claims suitable for appraisal. If the verifier lacks the exact manifest, or does not appraise the measuring environment, the relying party receives a polished conclusion built on an incomplete chain.

A secure channel cannot certify a future event

The draft requires strong transport protection. Device reports to remote systems must travel over an authenticated, confidential channel or within an equivalently protected mechanism. COSE containers, a protected EAT claim and secure transport are among the defined options. If local policy requires authenticated reports, a recipient must not emit an unauthenticated substitute; even a partial report must meet the same integrity policy.

These requirements matter. They prevent spoofing, modification and exposure. They do not alter the semantics of the result. A confidential invoke-pending remains a statement that the final outcome is unknown.

That limit should shape incident response. If a device becomes silent immediately after returning an authenticated pending report, investigators should not rewrite the record as failure or success. They know the evidence chain reached the pre-invocation boundary. They still need a post-handoff witness.

Build the receipt after the signature

A production evidence chain can be short without being vague.

First preserve the exact report bytes, authentication method, signer identity and validation result. Record the freshness mechanism. Bind the report to the exact root-manifest digest and obtain the matching manifest before reconstructing any SUIT_Record. Preserve the reconstructed dependency path, command sequence, offset and component identity.

Then appraise measurements for the processor, report generator and supporting execution environment. Preserve the exact result semantics: success, explicit failure, implicit handoff or invoke-pending.

Only after that boundary should runtime receipts begin. One observation proves that control reached the expected entry point. Another proves that the code remained healthy beyond initial execution. A service-level observation proves an outcome from a named vantage point. These may be boot measurements, watchdog heartbeats, application health records or external probes, but their scope must be explicit.

The chain is:

authenticated report → freshness → exact manifest → reconstructed path → measured reporter → invocation handoff → first execution → sustained runtime → service effect

No receipt is promoted into the next one merely because leadership wants a single status colour.

The draft is evidence of a boundary, not deployment

At the research freeze, draft-ietf-suit-report-22 was an active Internet-Draft intended for Proposed Standard. Datatracker placed it in the RFC Editor queue, blocked on a second-generation reference. It was not an RFC, and that document state is not evidence that a vendor implements the format or that a deployed device emits trustworthy reports.

The value of the draft is narrower and more durable. It identifies the moment when the most responsible signed statement is not “success” but “about to try.” A system that preserves that uncertainty is more governable than one that manufactures completion early.

Sources