Zusammenfassung

  • RFC 9734 registriert id-kp-imUri mit der OID 1.3.6.1.5.5.7.3.40 für Zertifikate, deren Schlüssel IM-Identitätsnachweise signieren soll, statt allgemein als TLS-Client oder -Server zu dienen.
  • Die EKU beschreibt den Zweck. Der Konto-Identifier gehört in subjectAltName; Zertifizierungspfad, Soll-Ist-Namensvergleich, heutige Kontokontrolle, Sperrstatus und Anwendungsbefugnis bleiben eigene Entscheidungen.
  • MLS bindet den öffentlichen Zertifikatsschlüssel an den Signaturschlüssel im LeafNode. Welche Identität akzeptabel ist, prüft dennoch der Authentication Service nach der Politik der Anwendung.

In einem Audit liegen zwei saubere Datensätze. Die PKI sagt: Zertifikat gültig, IM-EKU vorhanden. Das Gerätemanagement sagt: Client vor drei Tagen außer Betrieb genommen. Wer nur die PKI-Zeile exportiert, erzeugt keinen technisch falschen Wert. Er erzeugt eine institutionell falsche Entscheidung.

RFC 9734 führt seit Februar 2025 einen speziellen Extended Key Purpose für Instant-Messaging-Identitätszertifikate. Allgemeine Zwecke wie id-kp-clientAuth und id-kp-serverAuth können eine für Messaging ausgestellte Berechtigung in andere Protokolle tragen. Deshalb sollen Aussteller sie nicht zusammen mit id-kp-imUri setzen.

Die neue OID begrenzt eine Angriffsfläche. Sie belegt weder ein Kontoverfahren noch einen laufenden Gerätezustand. Gerade die engere Aussage macht sie wertvoll.

Zweck und Identität sind absichtlich getrennt

RFC 5280 weist Extended Key Usage die zulässigen Zwecke des zertifizierten öffentlichen Schlüssels zu. Subject Alternative Name bindet Identitäten an das Zertifikatsobjekt; eine URI steht im Feld uniformResourceIdentifier.

Damit lassen sich verschiedene Aussagen nicht austauschen. id-kp-imUri sagt, wofür der Schlüssel vorgesehen ist. Der in subjectAltName präsentierte im:-URI ist ein vom Aussteller gebundener Name. Ein erfolgreicher Pfad sagt, dass Signaturen, Laufzeit, Beschränkungen und Richtlinien zu einem akzeptierten Vertrauensanker führten. Ein Signaturtest zeigt momentane Kontrolle des privaten Schlüssels.

Keine dieser Aussagen beweist für sich, dass das Dienstkonto heute aktiv ist, das Gerät registriert blieb, der Mensch noch die Rolle besitzt oder die Gruppe den Client aufnehmen darf.

RFC 3860 bezeichnet mit einer im:-URI ein INSTANT INBOX und empfiehlt bei S/MIME-IM-Zertifikaten die URI des Subjekts in subjectAltName. Zugleich enthält das abstrakte Modell keine eigene Anwendungsgarantie für Zustellung. Ein korrektes Ziel ist kein Leistungsnachweis.

RFC 6121 trennt auch bei XMPP den JID vom Recht, eine konkrete Operation auszuführen. Ein Roster-Update verlangt beispielsweise eine Absenderautorisierung. Identität liefert ein Subjekt für die Regel, nicht die Regel selbst.

IANA koordiniert den Namen des Zwecks

Das SMI-Verzeichnis der IANA führt id-kp-imUri als Nummer 40 im PKIX-Zweckzweig. Die Zuteilung verhindert Bedeutungs-Kollisionen zwischen Spezifikationen. Sie kennt keinen einzelnen Zertifikatsantrag.

Der Aussteller darf die EKU kritisch oder nicht kritisch markieren. Eine Anwendung darf den konkreten Zweck verlangen. Deshalb muss der Betrieb nicht nur ausgestellte Felder, sondern Ablehnungen prüfen: Scheitert ein IM-Zertifikat am TLS-Client- und Serverpfad? Scheitert ein allgemeines Zertifikat am IM-Eingang? Werden unbekannte kritische Zwecke korrekt abgewiesen?

Gemischte Zertifikate mit clientAuth, serverAuth oder anyExtendedKeyUsage verdienen einen eigenen Alarm. Auch dieselbe Schlüsselnutzung in mehreren Protokollen kann die beabsichtigte Trennung unterlaufen. Ohne solche Negativnachweise ist die OID eine Bestandszahl, keine Kontrolle.

Der gültige Pfad hat keinen Soll-Namen

Pfadvalidierung prüft einen PKI-Zusammenhang. Sie erzeugt nicht den Identifier, den die Anwendung erwartet hat.

RFC 9525 unterscheidet für Dienstidentitäten präsentierte und referenzierte Identifier. Der Client kennt die Referenz aus seinem Ziel; das Zertifikat präsentiert Kandidaten. Erst eine definierte Vergleichsregel verbindet beide.

Ein Zertifikat kann mehrere URIs enthalten. Ein Alias kann während der Laufzeit neu vergeben werden. Ein String kann syntaktisch ähnlich, aber institutionell fremd sein. Ein belastbarer Datensatz bewahrt Referenz, präsentierte Werte, Normalisierung, Regel, Anker, Policy, Zeit, Ergebnis und Begründung. „Pfad gültig“ ohne Soll-Identifier ist eine Antwort ohne gespeicherte Frage.

MLS macht die Komposition sichtbar

RFC 9420 verlangt in einem X509Credential, dass der öffentliche Schlüssel des Endzertifikats identisch mit dem signature_key des LeafNode ist. Diese Regel verhindert eine Trennung zwischen vorgelegtem Zertifikat und tatsächlichem Gruppensignierer.

Die Anwendung legt trotzdem fest, welche Identifier sie akzeptiert. Der Authentication Service prüft die legitime Bindung der präsentierten Identifier an die Berechtigung und deren Übereinstimmung mit den Referenzen. Neue und ersetzte Credentials werden an den vorgesehenen Eintritts- und Aktualisierungspunkten erneut geprüft.

Vier Belege dürfen nicht verschmelzen: Zertifikatsschlüssel gleich LeafNode-Schlüssel; Pfad und IM-EKU akzeptiert; präsentierte URI entspricht der erwarteten; Client ist in Gruppe, Rolle und Epoch zugelassen. Die OID gehört in den zweiten Beleg.

Ein Konto kann mehrere Geräte haben. RFC 9420 warnt, dass Anwendungs-Identifier Clients nicht zwingend eindeutig unterscheiden; auch ein Leaf-Index gilt nur in einem Epoch. Für verwaltete und private Geräte braucht die Organisation deshalb eine eigene Client- oder Enrollment-Koordinate.

Status ist zeitgebunden

Nach der Ausstellung können Konto, Gerät, Beschäftigung oder Gruppenmitgliedschaft enden, während Schlüssel und Zertifikat fortbestehen.

RFC 6960 definiert bei OCSP good, revoked und unknown. good bedeutet mindestens, dass kein Zertifikat mit dieser Seriennummer innerhalb seiner Laufzeit als gesperrt verzeichnet ist. Es ist nicht automatisch ein Beweis der Ausstellung oder der vollständigen Gültigkeit. thisUpdate, nextUpdate und producedAt grenzen die Aussage zeitlich ein.

Der von RFC 9734 zitierte draft-barnes-mimi-identity-arch-02 behandelt Sperrinformation als externen Fluss und vergleicht kurze Zertifikate, OCSP und CRLs. Der Entwurf ist keine Implementierungsbestätigung. Er zeigt aber, warum ein statisches Zertifikat Änderungen nach der Ausstellung nicht alleine abbildet.

Aus dem grünen Feld wieder ein Dossier machen

Bei der Ausstellung gehören beantragte URI, Kontonachweis, prüfende Stelle, Policy-Version, Schlüsselbesitz, subjectAltName, EKU, Seriennummer und Laufzeit in den Beleg. Bei der Validierung: Soll-Identifier, präsentierte Namen, Vergleichsregel, Kette, Anker, EKU-Ergebnis, Statusquelle, Frische und Fehlermodus. Bei MLS: LeafNode, Credential-Fingerprint, Entscheidung des Authentication Service, Gruppe, Epoch, Client und Zulassungsregel. Ein Zusteller belegt nur seine beobachtete Übergabe.

Der kanonische Text, das XML, der RFC-Editor-Eintrag, das Errata-Verzeichnis und die IETF-Historie belegen die Dokumentprovenienz, nicht den Einsatz.

Heng Lus Running-Code-Primat fragt, welche Prüfung tatsächlich lief. Die minimale Anfangsspezifikation hält den gemeinsamen Zweck-Identifier schmal und lokale Entscheidungen sichtbar. Die Trennung der Realitätsebenen verhindert, dass registrierte OID, Zertifikat, Kontobindung, Befugnis und Wirkung zu einem Fakt werden.

RFC 9734 macht keine große Identitätsbehauptung. Es macht eine kleine Zweckbehauptung belastbarer.

Quellen