Zusammenfassung

  • token-authority ist ein optionaler Suchhinweis für den Client, kein Trust Anchor des Servers. Vertrauen entsteht aus der konfigurierten Ökosystembeziehung und dem per x5u oder x5c vorgelegten Ausstellerzertifikat.
  • Der ACME-Server behandelt JWTClaimConstraints als opake Zeichenfolge und vergleicht den Wert der ursprünglichen Bestellung direkt mit tkvalue, Oktett für Oktett und ohne Dekodierung, Rekodierung oder Normalisierung.
  • Eine gültige Challenge benötigt getrennte Belege für Aussteller, Signatur, Typ, exakte Identität, exp, jti, ACME-Kontoschlüssel und CA-Rolle der CSR. Ausstellung ist noch kein Beleg für spätere JWS-Prüfung oder ein Gesprächsergebnis.

Ein Wegweiser erteilt keine Befugnis

In einer tkauth-01-Challenge kann die optionale URL token-authority stehen. Der ACME-Client darf sie nutzen, um die Stelle zu finden, die ihm ein JWTClaimConstraints Authority Token liefert. Fehlt sie, soll der Client den Ort über eine Out-of-Band-Konfiguration kennen.

Revision 05 zieht eine klare Grenze: Bei der Prüfung der Challenge-Antwort verwendet der ACME-Server diese URL nicht. Die Adresse, die einem Client den Weg zeigt, nimmt den dortigen Unterzeichner nicht in die Vertrauensmenge des Servers auf.

Der Vertrauensentscheid läuft separat. Das Authority Token muss von einem Zertifikat signiert sein, das der Server für das betreffende Ökosystem als zulässigen Aussteller konfiguriert hat. Ein HTTPS-x5u kann auf das Zertifikat verweisen, x5c kann Zertifikatsmaterial enthalten. Fehlt beides oder besitzt das Zertifikat nicht die konfigurierte Rolle, muss die Prüfung scheitern. Der optionale Claim iss kann einen Aussteller benennen, aber eine Selbstbezeichnung ersetzt keine lokale Vertrauensentscheidung.

Dadurch können Betreiber Dienstort und Autorität unabhängig ändern. Ein Standortwechsel aus Verfügbarkeitsgründen erweitert nicht nebenbei den Vertrauenskreis. Der Entzug einer Ausstellerrolle verlangt keine fingierte Änderung der Clientroute. Ein gemeinsames Feld für beides würde aus einer URL-Änderung eine unsichtbare Sicherheitsentscheidung machen.

Semantische Befugnis hier, exakte Identität dort

Der JWTClaimConstraints-Identifier einer neuen Bestellung enthält die ungepolsterte base64url-Darstellung eines DER-kodierten JWTClaimConstraints- oder EnhancedJWTClaimConstraints-ASN.1-Objekts. Das Token trägt denselben Wert in atc.tkvalue.

Für die Token Authority beschreibt das Objekt STIR-spezifische Claim-Grenzen. Sie prüft nach RFC 8226 und RFC 9118, welche Ressourcen und Aussagen der Antragsteller vertreten darf. Der ACME-Server wiederholt diese semantische ASN.1-Prüfung nicht. Für Client und Server bleibt der Wert opak.

Der Server weist stattdessen nach, dass genau der semantisch autorisierte Wert zur ursprünglichen Bestellung gehört. Das ist eine minimale gemeinsame Spezifikation: eine kanonische Transportform, ein exakter Vergleich und ausdrücklich nachweisbare Verknüpfungen zu Aussteller, Zeit, Konto und Rolle. Die STIR-Politik bleibt bei der Stelle mit dem erforderlichen Kontext.

Keine selbst erfundene Gleichwertigkeit

DER und ungepolstertes base64url bestimmen eine einzige kanonische Oktettfolge. Der Server vergleicht die zwei empfangenen Strings direkt. Er darf sie davor weder dekodieren und neu kodieren noch kanonisieren, normalisieren oder anders transformieren.

=-Padding, Zeichen außerhalb des base64url-Alphabets, Leerraum, ein alternatives Alphabet, BER ohne DER-Konformität oder ein abweichendes Oktett führen zum Fehlschlag. Der Entwurf empfiehlt zusätzlich einen zeitkonstanten Vergleich, obwohl die Werte nicht geheim sind.

Jede tolerante Transformation schafft einen weiteren Entscheider darüber, welche Unterschiede angeblich bedeutungslos sind. Bibliotheken und Versionen können dabei auseinanderlaufen. Der direkte Vergleich entfernt diese versteckte Befugnis aus dem Autorisierungspfad und liefert einen reproduzierbaren Beleg aus sicheren Hashes, Längen und Prüfergebnissen beider Originalstrings.

Hinter einem Status stehen acht Prüfungen

Zuerst muss atc ein wohlgeformtes Objekt mit tktype, tkvalue und fingerprint sein. Dann wird geprüft, ob das Signaturzertifikat ein konfigurierter Aussteller ist und ob die Signatur stimmt. Der Typ muss JWTClaimConstraints lauten. Danach folgt der oktettgenaue Vergleich mit dem gespeicherten Wert der Originalbestellung.

exp muss vorhanden und nach Serveruhr und kleiner lokaler Zeitabweichung noch gültig sein; jti muss ebenfalls vorhanden sein. Der signierte Fingerabdruck muss zum ACME-Kontoschlüssel des antwortenden Clients passen. Schließlich muss der ca-Wert mit dem CA-Booleschen Wert der Basic Constraints in der CSR übereinstimmen.

Die Token Authority nutzt den Fingerabdruck nicht selbst als Nachweis der Kontokontrolle. Sie signiert ihn in das Token, damit der ACME-Server diese Verbindung später herstellen kann. Semantische Autorisierung und Kontokontrolle stammen damit aus unterschiedlichen Prüfstellen.

Scheitert ein Schritt, wird die Challenge ungültig; der Server kann einen ACME-Autorisierungsfehler liefern. Eine Sammelmetrik „Token ungültig“ verdeckt, ob Ausstellervertrauen, Zertifikatsabruf, Signatur, Bytes, Uhr, Transaktion, Konto oder CA-Rolle die Ursache waren.

Die Pflicht nach der Ausstellung

Eine gültige Autorisierung ist noch keine ausgestellte Urkunde. Der Entwurf erlaubt der CA außerdem, in die erfolgreiche Order-Antwort ein optionales x5u aufzunehmen. Der Inhaber kann damit das ausgestellte Zertifikat in späteren JWS-Objekten referenzieren. Die URL sollte abrufbar bleiben, solange Prüfende sie benötigen, typischerweise mindestens bis zum Zertifikatsablauf.

Dieses spätere x5u ist nicht der Verweis auf das Ausstellerzertifikat des Authority Tokens. Beide Links gehören zu anderen Schritten, Schlüsseln und Aufbewahrungspflichten. Die Ausstellung beweist weder späteren Abruf noch Akzeptanz des Zertifikats oder einer telefonbezogenen Aussage.

Evidenzgrenzen

Revision 05 wurde am 5. September 2026 als IETF-Arbeitsgruppen-Internet-Draft veröffentlicht und läuft am 9. März 2027 ab, wenn sie nicht aktualisiert wird. Sie kann sich ändern und ist kein RFC. Dieser Bericht testete keinen Client, Server, keine CA, Token Authority, Laufzeit, Ablage, Betreiberin oder Gesprächskette.

Die Quellen belegen keine Einführung, Konformität, Interoperabilität, Ausstellung, Telefonnummernbefugnis, Gesprächsauthentisierung oder Betrugsreduktion. Sie beschreiben einen vorgeschlagenen Vertrag, nicht seine Ausführung.

Quellen