Zusammenfassung

  • Fassung 05 des Authority-Token-Profils für JWTClaimConstraints behandelt die DER-Einschränkung für ACME-Client und -Server als undurchsichtige Oktettfolge: Sie wird transportiert und exakt verglichen, aber nicht interpretiert.
  • Die Token Authority prüft die fachliche Bedeutung. Das einsetzende Ökosystem entscheidet separat, welchen Ausstellerzertifikaten der ACME-Server vertrauen soll.
  • Der optionale Parameter token-authority weist nur dem Client einen möglichen Bezugsort. Der Server ignoriert ihn bei der Validierung und verlangt über x5u oder x5c ein Zertifikat aus seiner vorkonfigurierten Vertrauensmenge.
  • Das Dokument ist weiterhin ein Internet-Draft der Arbeitsgruppe. Ein erfolgreicher Protokolltest beweist weder eine Rechtspersönlichkeit noch die Wahrheit eines Anrufs oder eine allgemeine Berechtigung.

Die neue Fassung benennt drei Zuständigkeiten

Die Autoren kündigten Fassung 05 am 5. September 2026 an. Zuvor hatte eine Prüfung durch den ACME-Vorsitz gefragt, für wen die normativen Vorgaben gelten und wie mehrere Felder umzusetzen sind. Chris Wendts Antwort und Änderungsliste nennt Klarstellungen zu Zielgruppe, Ausstellervertrauen und token-authority.

Das Profil richtet sich an Zertifizierungsstellen für Secure Telephone Identity. Über ACME soll Autorität für eine JWTClaimConstraints-Zertifikatserweiterung nachgewiesen werden, die zulässige Aussagen eines Berechtigungsnachweises begrenzt. RFC 9448 definiert die Erweiterung; RFC 8226 und RFC 9118 liefern die Zertifikats- und Einschränkungsregeln des fachlichen Umfelds.

Nach Fassung 05 übermittelt der ACME-Client den Identifier und beschafft das Token. Der ACME-Server prüft die Challenge-Antwort. Die Token Authority entscheidet zuvor anhand der jeweiligen Domänenregeln, ob die beantragte Einschränkung angemessen ist, und signiert die Autorisierung.

Client und Server zerlegen den Wert nicht. Für sie ist die base64url-dargestellte DER-Codierung eine undurchsichtige Oktettfolge. Sie bleibt beim Transport unverändert und wird zwischen Identifier und Token exakt verglichen. Ob mustInclude, permittedValues und mustExclude inhaltlich passen, entscheidet nicht ACME, sondern die Token Authority.

Diese Zurückhaltung ist eine Stärke. RFC 8555 automatisiert Zertifikatsmanagement. Er macht einen allgemeinen Challenge-Server nicht zur Institution, die Rechte über telefoniebezogene Einschränkungen festlegt.

Ein Bezugshinweis für den Client ist keine Vertrauenswurzel

Der optionale Wert token-authority kann dem Client zeigen, wo er ein Token beschaffen könnte. Bei der Servervalidierung spielt er ausdrücklich keine Rolle. Ein vom Antragsteller übermittelter Fundort darf die Vertrauensentscheidung des Prüfers nicht steuern.

Das Ausstellerzertifikat kommt über x5u oder x5c im Token; beide dürfen nicht fehlen. Der Server ruft das Zertifikat ab oder liest es, prüft die Signatur und stellt fest, ob es in seiner Konfiguration als vertrauenswürdiger Authority-Token-Aussteller für dieses Ökosystem geführt wird. Der Verweis liefert kryptografisches Material, aber keine automatische Legitimation.

Vertrauensanker und ökosystemspezifische Zertifikatsbedingungen setzt die einführende Gemeinschaft. Der Entwurf nennt STIR-Governance als Beispiel, definiert jedoch keine globale Zulassungsstelle und keinen Ablauf für Aufnahme, Begrenzung, Aussetzung, Widerruf oder Beschwerde.

Auch der bereits als Standards Track veröffentlichte RFC 9447 setzt Beziehungen zwischen CA und Token Authority sowie zwischen Client und Token Authority voraus. Wo diese Beziehungen nicht vorausgesetzt werden können, ist die Challenge nicht anwendbar. Das neue Profil ändert den Gegenstand der Autorisierung, nicht den institutionellen Ursprung der Autorität.

Der Server beweist Bindung und Konsistenz, nicht Zuständigkeit

Nach der Vertrauenskonfiguration prüft der Server Struktur, Typ und Signatur des Tokens. exp muss vorhanden und aktuell sein, jti muss existieren. Das Token wird an den Schlüssel des ACME-Kontos gebunden, das den Auftrag gestellt hat; das ca-Flag muss zur beantragten Zertifikatsart passen.

Zusätzlich wird der Einschränkungswert exakt mit dem Identifier verglichen. Scheitert ein Schritt, wird die Challenge invalid; in der Regel soll ein ACME-Problembericht vom Typ unauthorized folgen. Dadurch lässt sich ein Token nicht ohne Weiteres für ein anderes Konto, eine andere Auftragsform oder eine andere Oktettfolge wiederverwenden.

Die Aussage bleibt trotzdem begrenzt. exp belegt Aktualität innerhalb des Profils, die Signatur den Besitz des Schlüssels und der Vergleich die Gleichheit zweier Darstellungen. Nichts davon erklärt, wer den Aussteller zugelassen hat, welche Richtlinienfassung seinen Auftrag begrenzte oder wie eine falsche semantische Entscheidung korrigiert wird.

Der aktuelle Datatracker-Eintrag führt das Dokument als aktiv und In WG Last Call, auf IESG-Ebene lediglich als I-D Exists. Document Shepherd, verantwortlicher Area Director und Telechat-Termin fehlen. Der frühere Aufruf nannte den 25. Juli als Ende; das Etikett beweist daher keine weiterhin offene Kommentierungsphase. Fassung 05 ist weder verabschiedeter RFC noch Implementierungs- oder Einsatznachweis.

Pro Auftrag sind höchstens ein JWTClaimConstraints-Identifier und ein TNAuthList-Identifier erlaubt. Die x5u-Adresse eines ausgestellten Zertifikats soll außerdem so lange abrufbar bleiben, wie sich verlassende Parteien sie benötigen, meist mindestens bis zum Ablauf. Das erhält Prüfmaterial, aber nicht den Grund für die damalige Vertrauensentscheidung.

Ein Nachweis der Einschränkungsautorität kann die Lücke schließen

Das Ökosystem könnte einen datensparsamen Nachweis erzeugen, der sich mit der ACME-Entscheidung verbinden lässt. Er bindet Kennung und Fassung der Richtlinie, Identität der Token Authority, Fingerabdruck des vertrauenswürdigen Zertifikats, zugelassene Einschränkungsfamilie, delegierte Umfangsklasse sowie einen Hash von Auftrag und codiertem Wert.

Hinzu kommen Ausgabe-, Entscheidungs- und Ablaufzeit, Ergebnis und begrenzte Fehlerklasse, Wirksamkeits- oder Widerrufsstatus des Vertrauenseintrags sowie eine Stelle für Korrektur, Vorfall oder Beschwerde. Ein Hinweis stellt klar, dass Protokollvalidierung kein allgemeines Urteil über rechtliche Identität, Anruferwahrheit oder Rechte außerhalb des benannten Ökosystems ist.

Dieser Nachweis ist ein redaktioneller Vorschlag von Daniel Kade, keine IETF-Vorgabe. Er sollte direkt aus dem tatsächlich angewandten Richtliniensystem kommen, nicht aus manueller Zweiterfassung. Telefonnummern und rohe Einschränkungen müssen dafür nicht öffentlich werden.