Zusammenfassung

  • draft-ietf-anima-rfc8366bis-36 erschien am 9. September 2026. Der Text befindet sich als Internet-Draft in der IESG Evaluation und ist weder RFC noch verabschiedeter Proposed Standard.
  • Bei einer Erneuerung bestätigt die MASA, dass die frühere Beziehung fortbesteht: frischer Registrar Voucher Request, fortdauernder Zugriff auf den Domain-Schlüssel, Widerrufsstatus des Domain-Zertifikats und neue Richtlinien.
  • Der neue Voucher ist ein autoritativ signiertes Ergebnis. Er führt nicht in einem gemeinsamen Format auf, welche Statusbeobachtung, Richtlinienversion oder Ausnahme dazu führte. Aus den Quellen lässt sich nicht ableiten, was einzelne MASA-Dienste intern protokollieren.
  • Ein getrennter Entscheidungsbeleg könnte die notwendigen Referenzen und Ergebnisse erhalten, ohne vertrauliche Vertragsdaten offenzulegen oder die Zuständigkeit von Domain-Eigentümer und MASA zu verschieben. Das ist Daniel Kades Vorschlag, keine IETF-Vorgabe.

Die Erneuerung ist kein bloßer Datumswechsel

Zwischen Revision 35 vom 12. August und Revision 36 vom 9. September liegt knapp ein Monat. Die Datatracker-Historie verzeichnet die neue Fassung und den Wechsel von Revised I-D Needed zu AD Followup. Das Dokument zielt auf den Standards Track, bleibt aber ein Entwurf. Es hat RFC 8366 noch nicht abgelöst und RFC 8995 noch nicht aktualisiert.

Der offizielle Vergleich grenzt Erstprüfung und Erneuerung voneinander ab. Bei der ersten Ausstellung können aufwendige Fragen anstehen: Ist der Antragsteller wirklich der behauptete Akteur, und gehört ihm das Pledge? Die spätere Erneuerung wiederholt diese Prüfungen nicht vollständig. Sie soll feststellen, ob die damals begründete Beziehung noch gilt.

Dafür prüft die Manufacturer Authorized Signing Authority stets den frisch signierten Registrar Voucher Request. Damit wird nachgewiesen, dass der anfragende Registrar weiterhin auf den privaten Schlüssel der Domain zugreifen kann. Zusätzlich prüft die MASA den Widerrufsstatus des Domain-Identitätszertifikats und wendet Änderungen an, die seit der vorherigen Ausstellung wirksam wurden.

Die Beispiele sind handlungswirksam. Der Domain-Eigentümer kann weitere Erneuerungen sperren lassen. Ein Supportvertrag kann ausgelaufen sein. Automatisierung darf diese Eingaben schnell auswerten; sie macht daraus aber keine bedeutungslose Routine.

Der Voucher transportiert das Ja

Der Registrar nimmt den alten Voucher in prior-signed-voucher-request auf und signiert eine neue Anfrage. Das verknüpft die fortzusetzende Autorisierung mit einem aktuellen Nachweis des Schlüsselzugriffs.

Der von der MASA ausgestellte Voucher muss für ein möglicherweise stark eingeschränktes Pledge prüfbar bleiben. Er bindet Gerät, zulässige Domain und Onboarding-Bedingungen. Er soll nicht die interne Vertragspolitik oder vollständige Antworten aus OCSP und PKIX-Systemen transportieren. Revision 36 untersagt sogar vertraulichkeitsbedürftige Daten im herstellerspezifischen Attribut, weil Zwischenstellen den Voucher speichern können.

Diese Sparsamkeit ist richtig. Sie begrenzt jedoch die Aussage des Artefakts. Die Signatur zeigt, dass die MASA zugestimmt hat. Allein daraus folgen weder Zeitpunkt und Frische der Widerrufsabfrage noch die ausgeführte Richtlinienversion, ein Vertragsstatus oder eine Ausnahmegenehmigung.

Eine reale Implementierung kann umfassende Logs führen. Dafür oder dagegen enthält das Quellenpaket keine allgemeine Evidenz. Der erkennbare Abstand liegt zwischen einem gemeinsamen signierten Ergebnis und nicht standardisierten Entscheidungsdaten, die über mehrere interne Systeme verteilt sein können.

Ein Pledge setzt die Grenze

Revision 36 begründet außerdem, warum ein Voucher nur eine Seriennummer umfasst. Ein früheres Modell konnte Gerätegruppen mit regulären Ausdrücken abdecken. Musste aber nur bei einem Pledge die Eigentumsbeziehung beendet werden, hätte eine Sperre die Erneuerung vieler unbeteiligter Geräte getroffen.

Ein Voucher pro Pledge verringert den Wirkungsradius einer Ablehnung. Die Seriennummer ist deshalb noch nicht weltweit eindeutig; ihr Ausstellerkontext bleibt nötig. Aber die Einheit der Autorisierung entspricht nun eher der Einheit, in der Kontrolle wechseln kann.

Auch ein Entscheidungsbeleg sollte diese Granularität übernehmen. Eine Flottenquote erklärt keinen Einzelfall. Nachvollziehbarkeit verlangt trotzdem weder Standort noch Vertragswert. Gehashte Referenzen und begrenzte Ergebnisklassen reichen.

Die Uhr des Pledge ist eine andere Kontrollfläche

Der Entwurf bevorzugt kurzlebige, nicht eigenständig widerrufbare Voucher mit programmatischer Erneuerung. Was kurz bedeutet, bestimmt das jeweilige Onboarding-Verfahren. Der Voucher selbst hat kein separates Widerrufsobjekt; Widerruf in der Zertifikatskette kann dennoch wirken.

Bei einem Voucher ohne Nonce muss das Pledge expires-on mit einer verlässlichen internen Uhr vergleichen. Revision 36 erklärt, warum NTP in dieser Phase nicht automatisch vertrauenswürdig ist: Ein Angreifer kann den Zeitstrom kontrollieren. Fehlt eine manipulationssichere Uhr, bietet sich eine Nonce und ein frischer ephemerer Voucher an.

Die MASA muss also den Zeitpunkt ihrer Quellenbeobachtung beherrschen. Das Pledge muss die Frische beim Verbrauch feststellen. Ein einziges Label „gültig“ würde diese beiden Verantwortungen verdecken.

Ein kleiner Beleg außerhalb des Wire-Formats

Der vorgeschlagene Erneuerungsbeleg kann neben der MASA-Entscheidung liegen. Er bindet Digest des alten Vouchers und der frischen RVR, Pledge und Ausstellerbereich, gepinnte Domain, MASA, Anfrage- und Entscheidungszeit, Ergebnis des Schlüsselbesitznachweises, Methode und Frische des Zertifikatsstatus, Kennung und Version der Richtlinie, gegebenenfalls eine Vertragsstatusklasse, Ausnahme und verantwortliche Stelle, Endentscheidung, neue Gültigkeit und den nächsten Prüf- oder Sperrauslöser.

Details bleiben zugriffsgeschützt. Der Beleg kann mit Hashes und kontrollierten Codes auf sie verweisen. Er vereinheitlicht keine Geschäftsmodelle und gibt der IETF keine neue Entscheidungsgewalt. Er konserviert nur, welche eigene Regel die jeweilige MASA ausgeführt hat.

Das entspricht Heng Lus Minimum Initial Specification: gemeinsam wird nur die kleinste überprüfbare Grenze, während spätere Entscheidungen bei den verantwortlichen Akteuren bleiben. The Policy Mirror ergänzt, dass Automatisierung ihre legitimierende Richtlinie sichtbar halten muss.

Der Beleg ist Daniel Kades redaktioneller Vorschlag und kein Bestandteil von Revision 36.

Evidenzgrenze

RFC 8995 beschreibt BRSKI-Rollen, RFC 5280 und RFC 6960 den Zertifikatsstatus. Auch der getrennte Entwurf zu MASA-Betriebsfragen ist noch nicht abgeschlossen.

Die Quellen belegen weder Angriff noch fehlerhafte Erneuerung, veraltete Statusinformation, Vertragsstreit, Deployment-Anteil oder fehlende Logs. Der belastbare Befund bleibt enger: Revision 36 macht aus der Erneuerung ausdrücklich eine neue Kontrollentscheidung. Der Voucher liefert deren signiertes Ergebnis, nicht deren portable Begründung.

Quellen