Zusammenfassung

  • draft-ietf-anima-rfc8366bis-36 beschreibt last-renewal-date als bloß informative Prognose; Pledges verarbeiten das Feld nicht, und es verlängert expires-on nicht.
  • Eine Erneuerung benötigt später eine frisch signierte RVR mit dem alten Voucher sowie aktuelle Prüfungen von Domain-Schlüssel, Zertifikat und Policy, bevor ein neuer Voucher entstehen kann.

Ein signiertes Datum wandert schnell aus dem Protokoll in eine Zusage. In der Anlagenverwaltung heißt es dann „erneuerbar bis“, obwohl der Aussteller nur festgehalten hat, bis wann er eine Erneuerung voraussichtlich anbieten wird.

Die YANG-Beschreibung zieht eine klare Grenze. last-renewal-date ist informativ und wird vom Pledge nicht verarbeitet. Das Feld setzt expires-on voraus, ist aber weder dessen Ersatz noch dessen Verlängerung. Es beweist keinen reservierten Dienst und keinen bereits erzeugten Nachfolger.

Der Entwurf ist noch im IESG-Verfahren

Datatracker führt Revision 36 vom 9. September 2026 als aktiven ANIMA Internet-Draft mit Ziel Proposed Standard. Der Zustand lautet IESG Evaluation::Revised I-D Needed; zwei DISCUSS bleiben offen, zwei weitere YES- oder NO-OBJECTION-Positionen werden benötigt, und IANA verlangt nach der Versionsänderung eine neue Prüfung.

Bei Zustimmung würde der Text RFC 8366 ablösen und RFC 8995 aktualisieren. Er ist noch kein RFC und kein Beleg für Implementierung oder Verfügbarkeit eines konkreten MASA.

Die Erneuerungsstrategie stammt nicht erst aus Revision 36. Schon RFC 8366 empfiehlt kurzlebige, nicht durch einen eigenen Mechanismus widerrufbare Vouchers mit leichter Neuausstellung. Neu und nützlich ist die ausführlichere Beschreibung der späteren Kontrollen gegenüber Revision 35.

Die alte Signatur friert die heutige Entscheidung nicht ein

Der Registrar erstellt eine neue Registrar Voucher Request, signiert sie und legt den alten Voucher in prior-signed-voucher-request ab. Der MASA prüft die RVR und bestätigt, dass der anfragende Registrar weiterhin Zugriff auf den privaten Domain-Schlüssel hat. Zusätzlich prüft er den Widerrufsstatus des Domain-Identitätszertifikats und wendet die aktuelle Policy an.

Ein Domain-Eigentümer kann weitere Erneuerungen blockiert haben; ein Supportvertrag kann abgelaufen sein. Das sind Beispiele für Policy-Änderungen, keine universelle Vertragsregel.

Die erste Ausstellung mag aufwendige Eigentumsprüfungen erfordern. Bei der Erneuerung genügt eine Prüfung, ob die bestehende Beziehung weiter trägt. Das senkt Aufwand und ermöglicht Automatisierung, garantiert aber keine positive Entscheidung.

Antrag, Entscheidung und Ersatz sind getrennte Artefakte

Eine gültige RVR belegt einen Antrag im jeweiligen Schlüssel- und Zertifikatskontext. Der beigefügte alte Voucher bezeichnet die fortzusetzende Beziehung. Der Domain-Schlüsselnachweis belegt aktuelle Kontrolle.

Danach kann der MASA wegen Zertifikat oder Policy ablehnen. Eine Antwort kann verloren gehen. Ein ausgestellter Ersatz kann beim Registrar liegen, ohne das Pledge zu erreichen. Das Pledge kann Signaturkette, Gerätebindung, Zeit oder Domain-Anker zurückweisen. Selbst nach Annahme können Enrollment, Konfiguration oder Dienst scheitern.

Ein belastbares Register trennt daher: altes Versprechen; getestete Erreichbarkeit; neue RVR; aktuelle Berechtigung; exakte Ersatzbytes; Annahme durch das Pledge; Abschluss und Ergebnis. Ein einziges Feld „renewable“ verschweigt sowohl Fehlerort als auch Verantwortlichkeit.

Weniger Widerrufslogik verlangt frühere Erprobung

Der Ansatz reduziert echte Komplexität. Langfristige Assertions mit OCSP oder CRL benötigen zusätzliche Verteilung und Verarbeitung. Ein Pledge kann den OCSP Responder womöglich nicht erreichen. Der Entwurf empfiehlt deshalb kurzlebige Vouchers und Neuausstellung über denselben Artefakttyp.

Wie kurz „kurz“ ist, entscheidet das Onboarding-Verfahren. Lange Vouchers bleiben möglich, doch ein Voucher-eigener Widerruf wird nicht beschrieben. Wird ein Zwischen-CA-Zertifikat der Signaturkette widerrufen, kann der Voucher über PKIX unbrauchbar werden; das ist eine andere Ebene.

Der operative Schwerpunkt liegt damit auf rechtzeitiger Erneuerung. Ein früher Test lässt Raum, Route, Zertifikat, Domain-Schlüssel oder Eigentumsakte zu reparieren. Nach Ablauf stellt die alte Prognose keine Gültigkeit wieder her.

Ohne Nonce bleibt die Uhr ein eigener Risikofaktor

Ein nonceless Voucher kann seine Frische nur über expires-on und die interne Uhr des Pledge belegen. NTP ist in einem feindlichen Netz keine sichere Quelle, weil ein Angreifer den Zeitstrom kontrollieren kann. Ein Gerät ohne vertrauenswürdige Uhr braucht einen Nonce und einen frischen ephemeren Voucher.

Während seiner Gültigkeit darf ein nonceless Voucher beliebig oft wiederverwendet werden. Das erleichtert wiederholtes Onboarding in dieselbe Domain, ermöglicht aber auch wiederholte Versuche durch einen Besitzer des Artefakts. Der gepinnte Domain-Anker begrenzt das akzeptable Ziel.

last-renewal-date liefert weder Uhr noch Nonce noch Einmaligkeit. Es ist auch kein Nachweis, dass der aktuelle Registrar zum Anker passt.

Der Domain-Anker ist kein Ergebnisbericht

Der Voucher transportiert einen Trust Anchor, mit dem das Pledge spätere Domain-Interaktionen authentifiziert. Die Übereinstimmung mit dem aktuellen Registrar verhindert eine Umleitung in eine andere Angreifer-Domain.

Sie beweist nicht Gesundheit des Registrars, erfolgreiches Enrollment, korrekte Konfiguration oder den beabsichtigten Dienst. RFC 8995 beschreibt den weiteren BRSKI-Ablauf. Signatur, Gerätebindung, Frische, Domain-Match, Erneuerungsberechtigung, Ausstellung, Annahme und Ergebnis bleiben eigenständig.

Aus der Prognose einen Testtermin machen

Heng Lus Minimum Initial Specification und Running-Code Primacy helfen, gemeinsamen Text und lokale Wirklichkeit zu trennen. Die Spezifikation kann Artefakt und Prüfregeln festlegen. Der Erneuerungsbeleg entsteht erst, wenn laufende Systeme die Transaktion ausführen und beobachtbar bestätigen.

Ein ehrliches Dashboard zeigt „Aussteller prognostizierte bis X“, „letzter vollständiger Test Y“, „Ersatz gültig bis Z“ und „nächster Test Q“. Eine Verfügbarkeitsgarantie gehört mit Eigentümer und Abhilfe in einen Betriebsvertrag, nicht in eine Interpretation des YANG-Felds.

Quellen