Zusammenfassung

  • Revision 02 erlaubt einer CA, den dauerhaften DNS-Eintrag mit dem SHA-256-JWK-Fingerabdruck jedes öffentlichen Schlüssels abzugleichen, den ein ACME-Konto während seiner Lebensdauer verwendet hat.
  • Die Rotation sperrt den alten privaten Schlüssel für neue authentisierte Anfragen, widerruft aber nicht automatisch die daran geknüpfte DNS-Autorisierung. TXT-Löschung, Cache-Ablauf, persistUntil und Autorisierungsende sind getrennte Ereignisse.
  • Die Kontodeaktivierung ist der unmittelbare kontoweite Stopp des Entwurfs. Betreiber benötigen bis dahin einen Lebenszyklusbeleg mit Schlüsselgeneration, DNS-Beobachtung, CAA, Kontostatus und Wiederverwendungsfrist.

Zwei grüne Anzeigen können eine falsche Gewissheit erzeugen. Das ACME-Konto verwendet einen neuen Schlüssel, und der autoritative DNS-Server liefert den alten TXT-Wert nicht mehr. Eine CA kann trotzdem noch auf Prüfdaten vertrauen, die sie vor beiden Änderungen erhalten hat.

Genau diese Lücke formalisiert Revision 02 von ACME DNS Persistent Challenge, veröffentlicht am 20. September 2026. Laut Datatracker-Historie ist das Dokument ein aktiver Working-Group-Entwurf im Zustand I-D Exists. Standards Track steht im Text, doch intended status, Shepherd, Area Director und IESG-Phase fehlen. Es handelt sich weder um einen RFC noch um Last Call oder einen Nachweis realer Einführung.

Der Mechanismus legt unter _validation-persist einen Wert mit dns-persist-01 ab. Er enthält einen 43 Zeichen langen, ungepolsterten base64url-SHA-256-JWK-Fingerabdruck und einen Hash über Domainname, Fingerabdruck und ACME-Konto-URL. RFC 7638 definiert den Fingerabdruck, RFC 6920 die hashbasierte Benennung.

Die CA prüft zunächst den aktuellen Schlüssel. Passt er nicht, durchläuft sie die gespeicherten öffentlichen Schlüssel rückwärts. Der Vergleich von 01 und 02 zeigt die entscheidende Pflicht: Ein unterstützender Server bewahrt den Fingerabdruck jedes je verwendeten öffentlichen Kontoschlüssels während der gesamten Kontolebensdauer auf. Das Repository der ACME-Arbeitsgruppe belegt Entwicklung, nicht Deployment.

Die Begründung folgt ACME. Kontoschlüssel sollen regulär gewechselt werden können, ohne dass DNS-Verantwortliche eine als dauerhaft gedachte Delegation neu schreiben müssen. Gespeichert wird kein alter privater Schlüssel. Ein öffentlicher Fingerabdruck erkennt die damalige Bindung, kann aber keinen neuen Auftrag signieren.

Kontinuität erzeugt dennoch Restautorität. Wurde eine Prüfung mit K1 gewonnen und das Konto wechselt zu K2, verliert K1 die Anmeldefähigkeit. Die Autorisierung bleibt jedoch dem gültigen Konto zugeordnet. Auch bei einer erneuten DNS-Prüfung kann der mit K1 gebildete Wert passen, weil sein Fingerabdruck historisch erhalten ist. Der aktive Signierer wurde ersetzt; die frühere DNS-Erlaubnis nicht zwingend.

Auch das Löschen des TXT wirkt verzögert. Rekursive Resolver dürfen die Antwort bis zum TTL-Ende liefern. Der Entwurf setzt TTL nicht mit der Wiederverwendungsdauer gleich: Das eine steuert DNS-Caches, das andere die gespeicherte CA-Entscheidung. persistUntil kann eine Obergrenze setzen; späteres Löschen oder Verkürzen reduziert bereits gewonnene Prüfdaten nicht rückwirkend.

Damit existieren vier Uhren: der aktuell authentisierende Kontoschlüssel, autoritative Veröffentlichung samt Caches, der Ablauf der ACME-Autorisierung und das bei der Beobachtung erfasste persistUntil. Wer sie in einem einzigen Status „widerrufen“ zusammenfasst, kann das tatsächliche Ende der Befugnis nicht nennen.

Eine harte, sofortige Wirkung hat die Deaktivierung des ACME-Kontos. Die CA muss den Status valid prüfen; die Deaktivierung überstimmt die historische Schlüsselkontinuität. Sie ist breiter als das Entfernen eines Domain-Eintrags und stoppt das gesamte Konto. Incident-Runbooks brauchen deshalb beide Handlungen mit klarer Reichweite.

Normalerweise bindet der Hash eine Domain. domain_name=* lässt denselben Wert für mehrere Domains eines Kontos und Schlüssels zu. Das spart Arbeit, vergrößert aber Korrelation und Schadensradius. Der genaue Identifier- und Wildcard-Umfang gehört in jeden Ausstellungsnachweis.

CAA bleibt unabhängig. accounturi aus RFC 8657 enthält die tatsächliche Konto-URL; der persistente TXT hasht sie. Ein Treffer ersetzt weder CAA, noch beweist CAA den persistenten DNS-Nachweis.

DNSSEC authentisiert die beobachtete Antwort, nicht die heutige organisatorische Absicht. Der Entwurf empfiehlt Validierung, sofern verfügbar, und einen Fehler bei gescheiterter Validierung. RFC 4033 beschreibt Herkunft und Integrität. Über Kontostatus oder gewollte Cache-Inhalte entscheidet DNSSEC nicht.

Auch Vorabbereitstellung lässt sich delegieren. Nach einem authentisierten POST-as-GET, der das Konto als valid bestätigt, kann eine andere Partei öffentliche Konto-URL und Fingerabdruck erhalten und den TXT setzen. Der private Schlüssel bleibt geheim. Damit werden DNS-Betrieb und ACME-Kontrolle getrennt; Anfrage, Genehmigung und Installation müssen entsprechend zugeordnet werden.

In den IANA-ACME-Registern fehlt dns-persist-01 zum Redaktionsschluss. Das CA/Browser-Forum-Votum SC-088v3 zeigt Branchenunterstützung für eine kontogebundene dauerhafte TXT-Methode. Es beweist weder die Einführung dieses IETF-Entwurfs noch die Gleichheit der Verträge.

Benötigt wird ein Autorisierungsbeleg über die gesamte Lebensdauer: FQDN und Umfang, Digest und Beobachtungszeit, autoritative und rekursive Sicht, TTL und Cache-Horizont, Aussteller, domain_name=*, geschützte Kontoidentität, passende aktuelle oder historische Schlüsselgeneration, Kontostatus, CAA, DNSSEC, persistUntil, Autorisierungsablauf sowie Auftrag und Ausstellung, die das Ergebnis nutzten.

Damit unterscheidet eine Prüfung Rotation mit weiter zulässigem historischen Treffer, Löschung bei lebendem Cache, Wiederverwendung ohne neue DNS-Prüfung und Deaktivierung vor Ausstellung. Ohne den Beleg soll der DNS-Zustand von heute eine Entscheidung von gestern erklären.

Der Entwurf kann sich noch ändern. Die Governance-Grenze ist bereits erkennbar: Dauerhafte Autorisierung verlagert Macht von einem Live-Nachweis in verwaltete Geschichte. Rotation ist Pflege. Entzug muss die weiterhin wirksame Erlaubnis treffen.

Quellen