Zusammenfassung

  • draft-birkholz-did-x509-03 validiert eine mitgelieferte, beim Blatt beginnende Zertifikatskette gegen ihr letztes Zertifikat, gleicht den Fingerabdruck eines Nicht-Blatt-Zertifikats ab und prüft Prädikate des Blatts.
  • Der dabei verwendete algorithmische Anker wird nicht automatisch zum Vertrauensanker der prüfenden Stelle. Trust Store, Allowlist oder Anwendungspolitik müssen CA, DID und Kontext gesondert akzeptieren.
  • Auflösung, lokales Vertrauen, Nachrichtensignatur, Zweckautorisierung, dauerhafter Commit und Außenwirkung benötigen eigene Belege. Revision 03 ist ein informativer Independent-Submission-Internet-Draft, kein RFC und kein IETF-Standard.

Ein Prüfdienst erhält alles, was er für eine geschlossene Rechnung braucht: Identifikator, Blattzertifikat, Zwischenzertifikate und ein letztes Zertifikat. Jede Signatur stimmt, der im DID genannte Fingerabdruck ist vorhanden, alle Bedingungen passen. Der Dienst liefert ein DID-Dokument und meldet Erfolg.

Die Organisation hat damit noch keine CA gewählt.

Genau diese Lücke macht Revision 03 von did:x509 zu einem interessanten Governance-Dokument. Das Verfahren kommt ohne dauerhaftes Register für DID-Dokumente aus. Es beschreibt im Identifikator eine Zertifikatsklasse und rekonstruiert aus der vorgelegten Kette das Verifikationsmaterial. Ein deterministischer Zusammenhang entsteht. Vertrauen entsteht nicht automatisch mit.

Der Identifikator beschreibt eine Menge

Das Format beginnt mit did:x509:0, gefolgt von Fingerabdruckverfahren, Fingerabdruck und mindestens einem Prädikat. SHA-256, SHA-384 und SHA-512 sind vorgesehen. Der Fingerabdruck gehört zu einem Nicht-Blatt-Zertifikat, also einem Zwischenzertifikat oder Anker; die Prädikate beziehen sich auf das Blatt.

subject prüft eine Teilmenge ausgewählter Namensattribute. san verlangt genau einen E-Mail-, DNS- oder URI-Wert. eku gleicht eine Extended-Key-Usage-OID ab. fulcio-issuer stellt das Präfix https:// wieder her und vergleicht die Fulcio-Issuer-Erweiterung, die vorhanden und nicht kritisch sein muss.

Dadurch kann ein DID einen Blattwechsel überleben. Mehrere Ketten können denselben Identifikator erfüllen. Die Stabilität beruht aber auf der Breite der Auswahlregel. Ein dürftiges Subject-Prädikat kann unerwartet viele Zertifikate einschließen. Ein EKU ist keine Geschäftsberechtigung, und ein passender SAN-Wert ist kein Mandat für eine bestimmte Freigabe.

Ein Trust Anchor im Algorithmus ist noch kein politischer Vertrauensanker

Die Option x509chain transportiert vollständige DER-Zertifikate, base64url-kodiert und durch Kommata getrennt. Das Blatt steht vorn, das als Wurzel oder Anker behandelte Zertifikat hinten. Weniger als zwei Zertifikate müssen abgewiesen werden.

Der Resolver führt eine Pfadvalidierung nach RFC 5280 aus. Dazu gehören Signaturen, Basic und Name Constraints, Zertifikatspolitiken, Key Usage, kritische Erweiterungen, Algorithmen und Validierungszeit. Anschließend werden Fingerabdruck und sämtliche Prädikate geprüft. Aus dem öffentlichen Blattschlüssel entstehen JWK und DID-Dokument.

Für diese Rechnung ist das letzte Zertifikat der Trust Anchor. Es ist jedoch eine mit der Nachricht gelieferte Eingabe. Der lokale Trust Store kann es ablehnen oder gar nicht kennen. Wer beide Ebenen gleichsetzt, erlaubt dem Beweisanbieter zugleich, die für ihn zuständige Autorität zu bestimmen.

RFC 9360 zieht für COSE-Zertifikatsketten dieselbe Grenze: empfangenes Zertifikatsmaterial darf die konfigurierten Anker einer Anwendung nicht stillschweigend verändern. Eine Kette kann ihre innere Beziehung belegen, aber nicht die Zustimmung des Empfängers mitliefern.

Beleg Zulässige Aussage Offene Frage
DID-Parsing Version, Verfahren, Fingerabdruck und Prädikate sind wohlgeformt Gibt es eine legitime passende Kette?
Pfadvalidierung Das Blatt führt unter angegebenen Parametern zum letzten Zertifikat Vertraut die Stelle diesem Zertifikat?
Fingerabdruck und Prädikate Die Kette gehört zur beschriebenen Klasse Ist die Klasse für den Zweck eng genug?
Lokale Annahme CA oder DID sind im Kontext erlaubt Ist die konkrete Nachricht korrekt signiert?
Signaturprüfung Die erfassten Bytes verifizieren unter dem aufgelösten Schlüssel Darf der Signierende die Handlung auslösen?
Autorisierung und Commit Akteur, Ressource und Operation wurden erlaubt und gespeichert Trat die behauptete Außenwirkung ein?

Sichtbarer Text ist noch keine beglaubigte Eigenschaft

Prädikate sind im DID lesbar. Eine Anwendung könnte deshalb Organisation, Domain oder E-Mail direkt aus der Zeichenfolge entnehmen und eine Rolle vergeben. Revision 03 warnt ausdrücklich davor. Vor der Auflösung gegen eine validierte Kette kontrolliert allein der Ersteller den Text.

Eine syntaktisch korrekte Zeichenfolge mit prestigeträchtigem Organisationsnamen lässt sich frei erzeugen. Erst die Kette bindet die Aussage an ein ausgestelltes Blatt. Erst die lokale Vertrauensregel sagt, ob dessen CA in diesem Kontext zählt. Beide Übergänge müssen sichtbar bleiben.

Zeit und Widerruf gehören zum Ergebnis

Validiert werden kann zur Gegenwart oder zu einem sachlich relevanten Zeitpunkt, etwa der Signaturzeit. Dasselbe Zertifikat kann dann verschiedene Ergebnisse liefern. Ein iat in JWT oder CWT wird durch bloße Existenz nicht zur vertrauenswürdigen Uhr. Die RFC 7519 und RFC 8392 definieren den Claim; Integrität und Akzeptanz bleiben Anwendungspolitik.

Widerruf wird geprüft, wenn die Anwendung ihn verlangt, etwa per CRL oder OCSP. Certificate Transparency, Endorsements und der Ausschluss unsicherer Algorithmen können hinzukommen. Deshalb muss „gültig“ immer Validierungszeit, Widerrufspolitik, verwendete Antworten und Algorithmusregeln mitführen.

Auch die Transparenz- und Receipt-Mechanismen in RFC 9597 und RFC 9943 trennen den transportierten Beleg von der Politik, die ihm Wirkung gibt.

Ohne Register bleibt Macht vorhanden

did:x509 kennt keine Operation zur Aktualisierung eines DID-Dokuments und keine Update-Autorisierung. Eine Deaktivierungsoperation existiert ebenfalls nicht. Erstellung ist lokal; die Auflösung kombiniert DID und vorgelegte Kette.

Sind alle passenden Blätter abgelaufen oder widerrufen, wirkt der DID deaktiviert. Dauerhaft garantiert ist das nicht: Eine CA kann ein neues passendes Blatt ausstellen. Die Kontinuitätsmacht liegt somit bei CA-Betreiber, Prädikatbreite und lokalen Zulassungsregeln.

Mehrere passende Ketten können zu unterschiedlichen Blattschlüsseln führen. Ein Audit muss die konkrete Kette und Verification Method der Nachricht aufbewahren, nicht nur den stabilen DID.

Implementierungsdifferenzen sind die wertvolle Evidenz

Revision 03 beschreibt eine Microsoft-Implementierung und nennt Nuts Foundation sowie Anwendungen rund um Signaturen, SCITT, CCF und Confidential Containers. Microsoft stellt README, Spezifikation und Testvektoren bereit.

Der Draft hält zugleich Unterschiede der Nuts-Implementierung bei eku und einer otherName-SAN-Erweiterung fest. Das ist keine Fußnote: Hier können Resolver verschiedene Zertifikatsmengen akzeptieren. Implementierungsangaben stammen von Beitragenden, sind kein IETF-Endorsement und keine vollständige Merkmalsliste.

Revision 02 nannte Standards Track als Ziel. Revision 03 wechselt zu Informational und baut Vertrauensmodell, Operationen, Auflösung, Datenschutz und Implementierungsstand deutlich aus. Datatracker, Historie und I-D-Ankündigung belegen eine unabhängige Einreichung in Arbeit, keinen RFC und kein IETF-Produkt.

W3C DID Core und die DID Specification Registries liefern den allgemeinen Rahmen für Dokumente und Verification Relationships. Sie ändern den Status dieses Entwurfs nicht.

Das vollständige Entscheidungsprotokoll

Zu speichern sind exakter DID und dekodierte Prädikatbytes, alle DER-Zertifikate in Reihenfolge, Paket-Hash, Pfadaufbau und -validierung, Validierungszeit, Namens-, Policy-, Constraint-, Key-Usage-, Extension- und Algorithmusentscheidungen, Widerrufs- und Transparenzstatus, getroffenes Nicht-Blatt-Zertifikat, jedes Prädikatergebnis, lokale Trust- oder Allowlist-Regel samt Version, DID-Dokument und JWK, signiertes Objekt und erfasste Bytes, Signaturergebnis, zweckgebundene Autorisierung, Commit-Kennung und beobachtete Außenwirkung.

Nicht geprüft bedeutet nicht bestanden. not_required_by_policy ist kein Widerrufsurteil; not_evaluated ist keine Vertrauenszusage.

Lu Hengs Minimum Initial Specification begrenzt den gemeinsamen Kern auf prüfbare Mechanik. Running-Code Primacy verlangt Implementierungs- und Wirkungsspuren. The Policy Mirror zeigt die Institution hinter dem Trust Store. Reality Layers trennt Zeichenfolge, Zertifikat, Urteil, Signatur und Wirkung.

Quellen