Summary

  • The IESG opened Last Call on draft-ietf-rats-endorsements-09 on 24 August, seeking comments through 7 September on publication as an Informational RFC. Revision 09 remains the numbered document under review, and no IESG decision has been announced.
  • In an attributed public comment, Anton Sokolov distinguished the stability of an endorsement's claim content from the continuing standing of the Endorser. He asked whether standing for historical Evidence should be assessed at Evidence time or appraisal time.
  • The authors answered that CoRIM already carries separate validity windows for content and signature standing. The commenter accepted that answer, while the editors chose to preserve the distinction in the draft.
  • Pull request 76 was reviewed and merged on 28 August. The editor's latest copy now explains rim-validity, signature-validity, revocation and trust-anchor checks, but those paragraphs are not in numbered revision 09.
  • A compact disposition receipt should link the comment, response, reviewed diff, merge, next numbered draft, protocol-policy choice, appraisal output and eventual IESG action. That would document the change without laundering an editor merge into IETF approval.

The public review still has an open ending

The IESG announcement on 24 August did not approve a new rule. It opened an IETF-wide Last Call on RATS Endorsements. The Remote ATtestation ProcedureS Working Group has asked for revision 09 to be published as an Informational RFC. Substantive comments are due by 7 September.

At this article's evidence cutoff, the Datatracker record still identified draft-ietf-rats-endorsements-09, showed “In Last Call,” listed no telechat date and recorded no final IESG action. Those fields matter because an active review, a source edit and an approved publication are different institutional objects.

The document extends the RATS architecture's treatment of Endorsements and Reference Values. In simplified terms, an Attester produces Evidence about a system's state. A Verifier appraises that Evidence, commonly with Reference Values, Endorsements and an Appraisal Policy for Evidence. The Verifier Owner controls that policy; the Relying Party Owner remains authoritative for the policy applied to Attestation Results. An Endorser can supply additional claims, but it does not inherit the Verifier Owner's decision authority.

Revision 09's timeliness section makes two statements. Specific protocol documents are responsible for providing timeliness for the Endorsement itself, perhaps through a certificate lifetime. It then says that additional static claims representing invariant properties of an Environment need no extra timeliness step because the claims do not vary dynamically.

Both propositions can be true. Their proximity created the review question.

A static claim does not freeze its Endorser

In a public Last Call comment, Anton Sokolov said the second sentence could be read too broadly. A hardware fact can remain unchanged while the manufacturer's certificate expires, its key is revoked or a Verifier removes the relevant trust anchor. The invariance of the assertion and the continuing standing of the actor who made it are independent.

Sokolov also asked a narrower question. Suppose Evidence records an Attester at time T1 and a Verifier appraises it later at T2. Should the Endorser's standing be tested at T1 or T2? The comment supported publication and did not allege an exploit or broken implementation. It asked the architecture to make the choice legible.

That attribution is important. The two-clock observation belongs to the public contributor who raised it. The editorial task is to report what the process did with it and what evidence a later reader would need to reconstruct the disposition.

Document author Thomas Fossati first restated the proposed clarification: Endorser-standing checks are logically independent of claim-content timeliness, and the reference point belongs to a protocol or appraisal policy. Sokolov agreed and suggested that an appraisal result should reveal which choice was used.

The exchange then found more than a sentence. Fossati pointed to CoRIM processing, where content and signature validity occupy separate windows. In that example, signature validity, revocation and trust-anchor status are evaluated at appraisal time. A verifier identifier in an Attestation Result can help make the applied engine—and therefore the choice—interpretable. Sokolov closed the concern by saying existing machinery answered it better than a new mechanism would.

An answer in a thread could have ended the episode. The editors instead chose to leave a durable trace.

The merged text adds a second separation

Pull request 76, “Addressing Anton's LC review,” opened on 25 August. It accumulated editorial changes, received approvals from Dave Thaler and Henk Birkholz, and merged on 28 August at commit bb53db0c7c6203f82cfad9cd3c4b5eaf8b6fd624.

The resulting editor's copy does more than add a revocation reminder. It separates two changes over time.

First, an Environment property or matching value can be static while an Endorser's assessment of it changes. The source gives a firmware example: the same measurement may once support a trusted verdict and later support an untrusted verdict after a vulnerability becomes known. Both messages may come from an Endorser that remains in good standing. The content therefore needs a validity period so a Verifier can determine which temporally scoped Endorsement applies. The text points to CoRIM's rim-validity window.

Second, the Endorser's own standing is independent again. Its signing key or certificate may cease to be valid, or its trust anchor may no longer be recognized. The text points to signature-validity and says that the CoRIM processor checks that window, revocation and trust-anchor status at appraisal time. Other protocols or policies may select a different reference point, but they need to document it.

This is more precise than saying “static claims expire.” The property, the Endorser's verdict about it and the Endorser's standing can move on different clocks. A valid signature authenticates a statement under a specified validation path. It does not make the statement permanently applicable, and it does not transfer appraisal authority from the Verifier Owner to the signer.

A merge is a disposition, not a publication

The merged change is inspectable, attributed and reviewed. It also remains in an editor's rendering labelled draft-ietf-rats-endorsements-latest. The formal numbered revision on Datatracker is still 09 and does not contain the new paragraphs.

That is not a defect. Internet-Drafts are working documents, and editors need a place to integrate review before submitting another numbered version. The danger begins when a citation drops the state label. “The editors merged the fix,” “the Working Group submitted revision 09,” and “the IESG approved an RFC” may sound like stages of one sentence, but they carry different authority. Only the first two are supported here, and they refer to different text snapshots.

Heng Lu's mandate-laundering test applies cleanly. A repository can prove which bytes editors accepted. It cannot supply the IESG decision those bytes may later receive. Conversely, the numbered draft's official status does not erase a newer, useful editor change. Governance fails in either direction if it collapses the layers.

Build a comment-to-spec disposition receipt

The public record already contains the necessary pieces; they are merely distributed among Mail Archive, GitHub, the editor's rendering and Datatracker. A compact receipt would join them without creating another approval body.

It should identify the archived contribution and date, contributor, affected revision and section, and an explicit disposition such as accepted, partly accepted, answered by existing mechanism, deferred or rejected. It should link the responsible editor's response, issue or pull request, exact head and merge commits, reviewers, merge time and a bounded description of what changed.

The next edge is institutional: name the first numbered Internet-Draft containing the change and preserve later IESG state and RFC number, if one exists. For this issue, the receipt should also record the protocol or policy owner, the content-validity window, the Endorser-standing window, Evidence time, appraisal time, selected reference point and enough verifier or policy identity to interpret an Attestation Result.

The record must include a non-conclusion. A comment can improve a document without representing community consensus. A merge can modify editor source without approving publication. A successful signature check can establish integrity under a chosen trust path without proving the claim true, the Endorser institutionally entitled, or the device trustworthy.

No private deliberation is needed. Stable public URLs, document hashes, role names, timestamps and disposition states are enough. The receipt would not replace the mailing list, chairs, editors or IESG. It would stop each layer from impersonating the next one.

Sources