Zusammenfassung

  • Der aktuelle CoSERV-Arbeitsgruppenentwurf erlaubt bei einer nicht vollständig erfüllbaren RIM-ID-Anfrage die Rückgabe einer Teilmenge; im Grenzfall gilt auch die leere Menge als gültiges Ergebnis.
  • Deterministische Kodierung, Anfragebindung, Signatur und Ablauf schützen Eigenschaften der konkreten Antwort, nicht die Vollständigkeit des dahinterliegenden Bestands.
  • Ein separater Abrufbeleg sollte Anfrageumfang, Datenbestandsgeneration, angeforderte, gelieferte und ausgelassene Elemente, Herkunft, Cachepfad, Prüfung und lokale Entscheidung zusammenführen.

Die fünfte Behauptung

Remote Attestation trennt Rollen, weil aus einer technischen Prüfung nicht automatisch eine umfassende Vertrauensentscheidung folgt. Ein Attester liefert Evidence, ein Verifier bewertet sie, und eine Relying Party entscheidet über Zugriff oder Einschränkung. RFC 9334 schützt damit auch die Nachvollziehbarkeit: Jede Stelle verantwortet eine andere Aussage.

Für die Beschaffung von Endorsements und Referenzwerten gilt dasselbe. Der aktive RATS-Arbeitsgruppenentwurf Concise Selector for Endorsements and Reference Values, kurz CoSERV, beschreibt kompakte Anfragen und Resultate für diesen Abruf. Revision 07 ist ein Internet-Draft, weder RFC noch verabschiedeter IETF-Standard.

Der Entwurf gibt dem zurückgegebenen Objekt starke Eigenschaften. Die Anfrage wird als deterministisches CBOR kodiert. Im HTTP-Binding kann daraus eine stabile GET-URL samt Cache-Schlüssel entstehen. Die signierte Antwort ist an die Anfrage gebunden; der Austausch gegen ein Resultat einer anderen Anfrage muss die Prüfung brechen. Ein Result Set hat einen verpflichtenden Ablaufzeitpunkt, darf die Gültigkeit enthaltener RIMs nicht überschreiten und schließt ungültige RIMs aus.

Damit lassen sich vier Aussagen prüfen: Wer hat das Objekt signiert? Blieben die Bytes unverändert? Gehört es zu genau dieser Anfrage? Liegt es noch im erklärten Zeitfenster? Eine fünfte Aussage ist davon logisch getrennt: Umfasste die durchsuchte Sammlung die relevante Grundgesamtheit, und wurde jedes anwendbare Element ausgegeben?

Diese fünfte Aussage benötigt nicht bloß eine weitere Signatur. Sie benötigt eine definierte Grundgesamtheit, beobachtbare Sammlungsvorgänge und sichtbare Auslassungen. Was nie in den Bestand gelangte, kann die Signatur einer Antwort nicht offenlegen.

Gültig leer

Die für den Betrieb entscheidende Passage in Revision 07 betrifft RIM-ID-Anfragen. Kann der Empfänger nicht die ganze Anfrage erfüllen, darf er nur eine Teilmenge liefern. Im schlimmsten Fall ist eine leere Menge dennoch ein gültiges Ergebnis.

Das ist vernünftig. Ein Dienst mit lückenhaftem Bestand soll weder Material erfinden noch seine Unkenntnis als Syntaxfehler ausgeben. Er darf korrekt liefern, was er liefern kann. Erst die betriebliche Übersetzung von „gültig“ zu „vollständig“ erzeugt eine falsche Zusage.

Bei fünf angeforderten und drei gelieferten Schlüsseln können alle drei Artefakte echt, frisch und exakt an die Anfrage gebunden sein. Für die zwei Lücken bleiben verschiedene Erklärungen offen: nie gesammelt, vorhanden aber nicht autorisiert, vom Selektor ausgeschlossen, verzögert importiert, Format nicht unterstützt oder vorübergehend nicht indiziert. Die Signatur schützt drei Anwesenheiten. Sie entscheidet nicht über den Grund zweier Abwesenheiten.

Eine leere Antwort sagt entsprechend nur: Dieser Empfänger lieferte nach den Regeln des Austauschs gültig null Elemente. Sie besagt nicht, dass weltweit kein passendes Endorsement oder kein Referenzwert existiert, dass keine Quelle ihn besitzt oder dass ein anderer Berechtigter mit anderer Anfrage dasselbe erhielte.

Auch „neueste Revision“ bleibt relativ. Bei ganzzahligen Versionszählern ist der höchste Zähler die neueste Revision für das jeweilige Tag unter den verfügbaren Kandidaten. Hat die Sammlung eine neuere Upstream-Version noch nicht gesehen, ist das lokale Maximum korrekt berechnet und trotzdem veraltet.

Ein Selektor legt den Blickwinkel fest

Eine Umgebungsanfrage wählt genau eine Art: Instanz, Gruppe oder Klasse. Instanz beziehungsweise Gruppe können in derselben Anfrage nicht mit einer Klassenauswahl verbunden werden. Mehrere Selektoren gleicher Art wirken als Alternativen. Innerhalb eines Klassenselektors müssen gesetzte Felder gemeinsam passen; nicht gesetzte Felder sind Platzhalter. Zustandsbehaftete Messungen können die Auswahl zusätzlich einschränken.

Die Regeln machen eine Anfrage reproduzierbar, nicht naturgegeben. Jemand hat Instanz statt Klasse gewählt, Felder gesetzt und andere offengelassen. Eine zu enge Bedingung kann relevantes Material ausblenden; ein zu weiter Platzhalter kann unpassende Kontexte vermischen oder sensible Zielmengen sichtbar machen.

Darum reicht ein Anfrage-Hash als Auditspur nicht. Er beweist die Gleichheit der Bytes, erklärt aber nicht, wer den Umfang genehmigte, welche Entscheidung damit vorbereitet werden sollte und welche Alternative verworfen wurde. Ohne Begründung kann „kein Treffer“ lediglich heißen, dass sehr präzise an der falschen Stelle gesucht wurde.

Gleichzeitig warnt der Entwurf vor der Sensibilität von Instanzselektoren. Rechenschaft darf keine öffentliche Geräteliste schaffen. Exakte Anfragebytes können in einem zugriffsgeschützten Evidenzspeicher liegen; im Betriebsprotokoll genügen ein geschützter Fingerabdruck, die Selektorart und die Genehmigung des Umfangs.

Ein signiertes Paket beglaubigt nicht die Sammlung

Ein Dienst kann Quellartefakte ebenso liefern wie gesammelte oder aggregierte Artefakte. Die Signatur eines gesammelten Pakets belegt den Verpackenden und schützt dessen Bytes. Sie belegt nicht, dass jede Upstream-Quelle abgefragt, jeder Sammellauf beendet, jedes Format verarbeitet oder jedes laut Lizenz und Berechtigung verfügbare Element einbezogen wurde.

Eine Aktenmappe kann ein tadelloses Siegel tragen, obwohl im Archiv ein ganzer Schub fehlt. Die Siegelprüfung rekonstruiert den Schub nicht.

Ebenso wenig darf flache Prüfung als tiefe Vertrauensaussage erscheinen. Die Relying Party kann zunächst die CoSERV-Hülle, dann ein enthaltenes CoRIM, danach die Autorität eines Endorsements prüfen und schließlich dessen Anwendbarkeit auf die konkrete Evidence beurteilen. Jede Ebene hat andere Zuständigkeiten und Fehler. Der Erfolg außen vererbt nicht automatisch Wahrheit und Relevanz nach innen.

Der Ablaufzeitpunkt liefert eine Zeitgrenze, keinen Abdeckungsbeweis. Er verhindert eine unbegrenzte Wiederverwendung als aktuell und bindet das Ergebnis an die Gültigkeit seiner RIMs. Eine vor einer Minute erzeugte Antwort kann trotzdem einen unvollständigen Bestand exakt wiedergeben.

Der Cache bewahrt auch die Lücke

Deterministische Anfragen eignen sich als stabile HTTP-Cache-Schlüssel. Signierte Resultate können innerhalb ihrer Gültigkeit wiederverwendet werden; Rechenlast sinkt, Verfügbarkeit steigt. Dadurch entstehen jedoch drei Zeitpunkte: Änderung des Anbieterbestands, Abruf durch den Cache und Entscheidung der Relying Party.

Ein Cache kann wiederholt eine gültige Teilantwort liefern und alles richtig machen. Wenn das Protokoll nur „Signatur gültig“ festhält, geht dennoch die Entscheidungsgeschichte verloren: welcher Cache antwortete, wann er das Objekt erhielt, welche Freshness-Regeln und Validatoren galten und ob der Anbieter inzwischen eine neue Datengeneration hatte.

Lucas Pardue bewertete den Entwurf in seiner frühen HTTPDIR-Prüfung vom 15. August 2026 als „Not Ready“ und behandelte Cache, Datenschutz, HEAD, Anfragegröße, Validatoren und Freshness. Das ist die Bewertung eines Reviewers, kein Arbeitsgruppenkonsens und keine IETF-Ablehnung. Die Vollständigkeitsgrenze folgt bereits aus der Teilmengen- und Leermengenregel; das Review verdeutlicht lediglich die zusätzlich aufzuzeichnenden HTTP-Zustände.

Der Abrufbeleg

CoSERV muss nicht zu einem universellen Vollständigkeitszertifikat aufgebläht werden. Daneben sollte ein betrieblicher Abruf- und Abdeckungsbeleg stehen. Er verbindet mindestens:

  • die deterministischen Anfragebytes oder einen geschützten Fingerabdruck mit kontrolliertem Zugriff auf das Original;
  • Profil, Ergebnistyp und Selektorlogik;
  • angeforderte RIM-Schlüssel oder Auswahlzweige;
  • Anbieter, konsultierte Datengeneration und eine begrenzte Erklärung ihres Abdeckungsumfangs;
  • gelieferte Schlüssel und Artefakte;
  • bekannte Auslassungen mit Gründen wie nicht verfügbar, nicht autorisiert, keine Übereinstimmung, ungültig, nicht unterstützt oder Abruffehler;
  • Quelle gegenüber gesammeltem Objekt samt Herkunftskette;
  • RIM-Gültigkeit, Ergebnisablauf, Abrufzeit und Cachepfad;
  • Ergebnisse der Signatur- und Strukturprüfung;
  • lokale Bewertung, Maßnahme und Auslöser einer erneuten Anfrage.

Diese Felder dürfen nicht wieder in einer Ampel verschwinden. Die Abdeckung ist eine Behauptung des Anbieters. Ein signierter Auslassungsgrund beweist, dass der Anbieter ihn erklärte, nicht dass er objektiv wahr ist. Die lokale Freigabe oder Einschränkung ist eine weitere, unabhängige Tatsache.

Ein verständlicher Beleg könnte sagen: Drei von fünf Schlüsseln wurden geliefert, einer war nicht autorisiert, einer in dieser Generation nicht verfügbar; die drei Objekte bestanden die Prüfung; die Anwendung schränkte Funktionen bis zu einer zweiten Quelle oder neuen Generation ein. Eine solche Kette lässt sich überprüfen. „CoSERV OK“ lässt sich nur wiederholen.

Quellen