Zusammenfassung

  • Die IESG eröffnete am 24. August den Last Call zu draft-ietf-rats-endorsements-09. Bis 7. September geht es um die Veröffentlichung als Informational RFC; eine endgültige Entscheidung liegt nicht vor.
  • Anton Sokolov unterschied in einem ihm zuzurechnenden öffentlichen Kommentar die Unveränderlichkeit eines Claim-Inhalts vom fortdauernden Standing des Endorsers. Zudem fragte er, ob dieses Standing zum Evidence- oder zum Appraisal-Zeitpunkt zählt.
  • Die Autoren verwiesen auf getrennte Inhalts- und Signaturfenster in CoRIM. Der Kommentator sah seine Frage damit beantwortet; die Editoren beschlossen trotzdem, die Trennung im Entwurf festzuhalten.
  • Pull Request 76 wurde am 28. August zusammengeführt. Die latest Editor's Copy erläutert nun rim-validity, signature-validity, Widerruf und Trust Anchors. Version 09 enthält diese Absätze nicht.
  • Ein Dispositionsbeleg sollte Kommentar, Antwort, geprüften Diff, Merge, nächste nummerierte Fassung, Policy-Entscheidung, Appraisal-Ausgabe und IESG-Handlung verbinden. So wird ein Editor-Merge nicht zur IETF-Genehmigung umgedeutet.

Der Last Call hat einen festen Gegenstand

Die IESG-Mitteilung vom 24. August bittet um Stellungnahmen zu RATS Endorsements. Die Remote ATtestation ProcedureS Working Group beantragt eine Veröffentlichung von Version 09 als Informational RFC. Die Frist endet am 7. September.

Zum Recherchezeitpunkt zeigte der Datatracker weiterhin Revision 09, „In Last Call“, keinen Telechat-Termin und keine abschließende IESG-Aktion. Ein fortgeschrittener Repository-Stand macht diesen Datensatz nicht falsch. Er bildet eine andere Stufe ab: Editor-Quelltext, eingereichter Internet-Draft und Publikationsentscheidung haben unterschiedliche Urheber und Wirkungen.

Auch die RATS-Architektur verteilt Verantwortung. Ein Attester liefert Evidence über einen Systemzustand. Ein Verifier bewertet sie anhand von Reference Values, Endorsements und einer Appraisal Policy for Evidence. Der Verifier Owner ist für diese Policy maßgeblich; der Relying Party Owner entscheidet über die Verwendung des Attestation Result. Ein Endorser steuert zusätzliche Aussagen bei, erhält durch seine Signatur aber keine allgemeine Appraisal-Befugnis.

Abschnitt 5 von Version 09 überlässt konkreten Protokollspezifikationen, wie die Zeitnähe des Endorsements selbst gewährleistet wird, etwa durch eine Zertifikatslaufzeit. Anschließend heißt es, statische Claims über unveränderliche Eigenschaften eines Environment benötigten keine zusätzlichen Zeitnähe-Schritte für den Claim-Inhalt.

Die Aussagen sind vereinbar. Zusammen konnten sie jedoch den Eindruck erwecken, mit einem statischen Inhalt sei auch die zeitliche Frage des Ausstellers erledigt.

Ein unveränderter Inhalt konserviert nicht den Endorser

Anton Sokolov beschrieb die Trennung im öffentlichen Last-Call-Kommentar. Eine Hardwareeigenschaft kann gleich bleiben, während das Herstellerzertifikat abläuft, der Schlüssel widerrufen wird oder ein Verifier den zugehörigen Trust Anchor entfernt. Ob die Aussage unverändert bleibt und ob ihr Urheber noch akzeptiert wird, sind unabhängige Prüfungen.

Mit T1 und T2 gab er der Frage eine Betriebsform. Wenn Evidence einen Zustand bei T1 beschreibt und erst bei T2 bewertet wird, zu welchem Zeitpunkt muss das Endorser-Standing gelten? Der Kommentar unterstützte die Veröffentlichung. Er meldete weder Angriff noch kompromittiertes Gerät oder fehlerhafte Implementierung.

Diese Beobachtung ist Sokolov zuzuschreiben. Daniel Kades eigenständiger Beitrag liegt nicht in einer nachträglichen Aneignung, sondern in der Governance-Frage: Wie lässt sich beweisen, welche Behandlung der Kommentar erhielt und wann daraus Quelltext, eine nummerierte Revision und gegebenenfalls ein Beschluss wurden?

Dokumentautor Thomas Fossati spiegelte zunächst die gewünschte Klarstellung: Standing-Prüfungen sind logisch von der Zeitnähe des Claim-Inhalts getrennt; T1 oder T2 legt das Protokoll beziehungsweise die Appraisal Policy fest. Sokolov stimmte zu und regte an, die Wahl im Ergebnis erkennbar zu machen.

Anschließend zeigte Fossati auf vorhandene Technik. Ein CoRIM Processor verwaltet getrennte Gültigkeitsfenster für Inhalt und Signatur. Im beschriebenen Fall werden Signaturgültigkeit, Widerruf und Trust-Anchor-Status beim Appraisal, also T2, geprüft. Eine Verifier-Kennung im Attestation Result kann die Entscheidung lesbar machen. Sokolov erklärte seine Sorge daraufhin für beantwortet: Bestehende Mechanismen reichten aus.

Die Sachfrage war damit in der Mailingliste erledigt. Die Editoren sorgten zusätzlich für eine Spur im Dokument.

Der neue Text trennt Inhalt, Urteil und Standing

Pull Request 76 wurde am 25. August eröffnet, mehrfach redigiert und von Dave Thaler sowie Henk Birkholz genehmigt. Am 28. August erfolgte der Merge unter bb53db0c7c6203f82cfad9cd3c4b5eaf8b6fd624.

Die aktuelle Editor's Copy führt ein Firmware-Beispiel ein. Derselbe Messwert H kann vor Bekanntwerden einer Schwachstelle als vertrauenswürdig, danach als nicht vertrauenswürdig bewertet werden. Beide Endorsements können von einem durchgehend akzeptierten Endorser stammen. rim-validity begrenzt deshalb den Inhalt und hilft festzustellen, welche zeitlich eingegrenzte Aussage gilt.

Unabhängig davon verändert sich das Standing. Schlüssel, Zertifikat oder Trust Anchor können ausfallen. signature-validity begrenzt die Signatur; der genannte CoRIM Processor prüft dieses Fenster zusammen mit Widerruf und Anchor-Status zum Appraisal-Zeitpunkt. Andere Protokolle oder Policies dürfen einen anderen Referenzpunkt wählen, müssen ihn aber dokumentieren.

Die Rede von zwei Uhren verdeckt somit eine dritte Bewegung: den Wert im Environment, das Urteil des Endorsers über diesen Wert und das Standing des Endorsers. Ein einziges „valid“ kann alle drei Prüfgründe unkenntlich machen.

Der Merge ist ein überprüfbarer Schritt, kein IESG-Mandat

Diff, Reviews und Merge Commit sind öffentlich. Die gerenderte Fassung trägt trotzdem die Kennung draft-ietf-rats-endorsements-latest. Sie ist weder Revision 10 noch RFC. Die nummerierte Version 09 im Datatracker enthält die Ergänzungen nicht.

Das ist im Entwurfsprozess normal. Internet-Drafts sind Arbeitsdokumente, und Editoren brauchen vor einer neuen Einreichung einen Integrationsstand. Problematisch wird die Beschreibung erst, wenn Statuswörter verschwinden. „Die Editoren haben den Fix gemergt“, „die Working Group hat Version 09 eingereicht“ und „die IESG hat die Veröffentlichung genehmigt“ bezeichnen verschiedene Befugnisse. Belegt sind gegenwärtig nur die ersten beiden Aussagen, und sie beziehen sich auf verschiedene Textstände.

Heng Lus Prüfung auf Mandatswäsche ist hier unmittelbar anwendbar. Das Repository belegt die von Editoren akzeptierten Bytes, verleiht ihnen aber keine IESG-Genehmigung. Umgekehrt darf der formelle Rang von Version 09 nicht dazu dienen, den neueren Editor-Text zu leugnen. Saubere Governance bewahrt beide Ebenen und die noch offene Verbindung.

Ein Dispositionsbeleg für jeden Zustandswechsel

Mail Archive, GitHub, Editor's Copy und Datatracker veröffentlichen bereits alle Bausteine. Ein kompakter Beleg kann sie verbinden, ohne ein weiteres Entscheidungsgremium zu schaffen.

Er nennt stabile Kommentar-URL, Datum, Urheber, betroffene Revision und Abschnitt sowie eine ausdrückliche Disposition: angenommen, teilweise angenommen, durch vorhandenen Mechanismus beantwortet, vertagt oder abgelehnt. Danach folgen verantwortliche Antwort, Issue oder Pull Request, Head- und Merge-Commit, Reviewer, Merge-Zeit und eine begrenzte Beschreibung der Änderung.

Die formelle Fortsetzung nennt den ersten nummerierten Internet-Draft mit dem Text, den späteren IESG-Status und gegebenenfalls die RFC-Nummer. Im Zwei-Uhren-Fall gehören zusätzlich Inhaltsfenster, Standing-Fenster, Evidence-Zeit, Appraisal-Zeit, Policy-Eigentümer und ausreichend Verifier- oder Policy-Identität für die Auslegung des Ergebnisses hinein.

Der Beleg braucht eine Nicht-Schlussfolgerung. Ein beantworteter Kommentar ist kein IETF-weites Consensus-Ergebnis. Ein Merge ist keine Publikationsfreigabe. Eine gültige Signatur belegt Integrität unter einem bestimmten Vertrauenspfad, aber nicht allein Wahrheit, institutionelle Berechtigung des Endorsers oder Vertrauenswürdigkeit des Geräts.

Private Beratungen müssen nicht veröffentlicht werden. Öffentliche Links, Hashes, Rollen, Zeitpunkte und Zustände genügen. Der Beleg ersetzt weder Liste noch Editoren, Working Group oder IESG. Er verhindert, dass eine Ebene die Autorität der nächsten übernimmt.

Quellen