Zusammenfassung

  • RFC 9925 ist ein im Februar 2026 veröffentlichter IETF Proposed Standard und definiert id-alg-unsigned mit fehlenden Parametern und null Bit Signaturwert.
  • Das Objekt enthält Subjektinformationen, aber keinen Beweis eines Ausstellers. Ein wiederholter Subjektname im Ausstellerfeld bleibt Kompatibilitätsplatzhalter.
  • Anwendungen ohne X.509-Signaturprüfung dürfen das Profil annehmen; Zertifizierungspfad-Validatoren müssen es anstelle einer Signatur ablehnen.
  • Das Entfernen einer dekorativen Selbstsignatur kann Post-Quanten-Größe senken, protokollübergreifende Schlüsselnutzung vermeiden und nicht signierende KEM-Schlüssel aufnehmen.
  • Ein Herkunfts- und Geltungsnachweis sollte Bytes, externe Prüfung, Genehmiger, Trust Store, erlaubte Nutzung und Entfernung verbinden.

Die Null ist eine Zustandsangabe

1.3.6.1.5.5.7.6.36 bezeichnet keine schwache Signatur, sondern eine Nicht-Signatur. Parameter fehlen, signatureValue ist leer. Der Empfänger kann deshalb zwischen beschädigtem Material, unbekanntem Verfahren und bewusst fehlendem Beweis unterscheiden.

Ein spezialisiertes Programm darf die Subjektangaben verarbeiten, wenn es die X.509-Signatur in diesem Kontext gar nicht prüft. Sobald Signaturprüfung oder Pfadvalidierung stattfindet, muss das Objekt scheitern. Ein unveränderter Validator sollte geschlossen reagieren, weil er den Wert nicht verifizieren kann.

Die Governance-Frage entsteht in der Darstellung. Ein grünes Zertifikatssymbol, die Überschrift „Ausgestellt von“ oder ein gemeinsamer Vertrauensspeicher können mehr Autorität vermitteln, als die Datei enthält. Die Norm verlangt das nicht; sie macht den fehlenden Beweis maschinenlesbar.

Der Knoten bleibt ohne Kante

RFC 9925 beschreibt ein gewöhnliches Zertifikat als Verbindung von Subjektinformation und Ausstellerbeweis. Im PKI-Graphen sind die Beteiligten Knoten, das signierte Zertifikat bildet eine Kante.

Manche Anwendungen brauchen nur einen Knoten. Ein Trust Anchor beginnt den Pfad. Eine geschlossene TLS-Installation kennt einen Schlüssel durch einen anderen Kanal. Ein KEM-Schlüssel braucht vielleicht X.509-Felder, kann aber nicht signieren.

Eine Selbstsignatur wählte den Schlüssel nie für den Betreiber aus. Sie bewies weder den Namen noch die Berechtigung zur Installation oder deren Umfang. RFC 5280 behandelt die Darstellung eines Trust Anchors schon als Eingabe außerhalb des prospektiven Pfads. Sie gilt, weil ein vertrauenswürdiges Out-of-Band-Verfahren sie liefert; die Auswahl bleibt lokal und anwendungsspezifisch.

Die neue Norm entfernt die dekorative Kante. Das entspricht Lu Hengs Policy Mirror: Form und tatsächliche Befugnis sollen übereinstimmen. Dafür muss die externe Entscheidung sichtbar werden.

Ein Ausstellerfeld kann ohne Aussteller existieren

X.509 erlaubt kein leeres Ausstellerfeld. Für ältere Software darf der Absender den Subjektnamen wiederholen oder den definierten kurzen Platzhalter verwenden. Beides erzeugt keinen Ausstellungsakt. Das Objekt ist ausdrücklich weder selbstsigniert noch selbstausgestellt.

Eine korrekte Oberfläche muss das sagen. Ein Kreispfeil vom Subjekt zu sich selbst erfindet die entfernte Beziehung. Authority Key Identifier und alternativer Ausstellername sollten gewöhnlich fehlen. Basic Constraints und Key Usage können die Rolle des Subjekts beschreiben; die technische Fähigkeit einer CA ist jedoch noch keine Genehmigung, ihr zu vertrauen.

IANA registriert Erkennbarkeit, nicht Vertrauen

Der IANA-Eintrag gibt unabhängigen Implementierungen denselben Codepunkt und dieselbe Referenz. Er authentisiert kein Subjekt, prüft kein Produkt und ordnet keine Installation an.

Gerade hier ermöglicht Erkennen ein genaues Ablehnen. Nimmt eine Anwendung id-alg-unsigned in einem Zertifizierungspfad an, umgeht sie die Signaturprüfung. RFC 8725 formuliert die allgemeinere Regel: erlaubte Algorithmen müssen vorgegeben werden, und die deklarierte Operation muss der ausgeführten entsprechen.

Parsererfolg und kryptographischer Erfolg sind daher zwei getrennte Ergebnisse. Das erste kann grün sein, während das zweite zwingend rot bleibt.

Warum Weglassen sicherer sein kann

Nicht geprüfte Selbstsignaturen liefern nicht den Grund für Vertrauen. Post-Quanten-Signaturen können groß sein. Bei Endsystemschlüsseln kann die zusätzliche Signatur denselben Schlüssel in zwei Protokollkontexte ziehen. Ein KEM-Schlüssel kann die Operation gar nicht ausführen.

Eine benannte Leerstelle beseitigt dieses Theater. Der Schlüssel bleibt seinem Zweck vorbehalten, alte Validatoren scheitern sicher und die Anwendung muss die externe Integrität benennen. Das ist keine generelle Ausnahme: Wo Ausstellerbeweis erforderlich ist, ist das Objekt ungültig.

Der stärkste Einwand lautet, dass eine lokale Anlage den Schlüssel ohnehin kennt. Das kann stimmen. Doch Out of Band kann Fingerprintvergleich, signiertes Firmware-Image, geschütztes Repository, Verwaltungsprotokoll oder Handarbeit bedeuten. Diese Wege haben unterschiedliche Eigentümer, Reichweiten und Rückrufmöglichkeiten.

Installation ist die wirksame Entscheidung

RFC 6024 trennt Trust Anchor, Manager und Store. Sie beschreibt Hinzufügen, Entfernen und Ersetzen, Quellenauthentisierung, Befugnisprüfung, begrenzte Zielgruppen, Replay-Schutz und Wiederherstellung.

Damit wird Importieren zum Governance-Akt. Ein Hash bestätigt die Bytes, nicht den Namensraum. Ein sicherer Kanal bestätigt den unmittelbaren Absender, nicht zwingend dessen Mandat. Administratorrechte führen die Änderung aus, sind aber nicht automatisch politische Genehmigung.

Herkunfts- und Geltungsnachweis

Der Nachweis beginnt mit Digest, Subjektschlüssel, deklarierter Rolle, Nicht-Signaturzustand und ausdrücklichem Verbot, das Objekt als Pfadsignatur zu verwenden. Danach folgen Quelle, Erwerbskanal, externer Integritätsbeleg, Lieferant und seine Befugnis.

Der Entscheidungsblock nennt Genehmiger, Zeitpunkt, Store, Anwendungen, Geräte, Namensräume, Richtlinien, Zwecke und Gültigkeitsfenster. Der Lebenszyklus hält Ersetzung, Entfernung, nächste Prüfung, Verantwortlichen und Wiederherstellung fest.

Eine öffentliche Ansicht darf dünn sein: Digest, Befugnis, Umfang, Zustand, Versionslinie und Korrekturkontakt. Interne Zugangsdaten bleiben geschützt. Der Nachweis signiert das Objekt nicht; er bewahrt die ausgelagerte Entscheidung.

Beweisgrenze

Die Quellen zeigen weder Verbreitung noch ein fehlerhaftes Produkt. Die LAMPS-Charta ist Arbeitsauftrag, keine Telemetrie. IANA belegt Zuteilung, nicht Implementierung.

Nicht jede Selbstsignatur ist nutzlos: Manche Programme verwenden sie als Integritätsprüfung gegen Speicherfehler. Dann braucht das unsignierte Objekt einen externen Hash. Und nicht jedes unsignierte Objekt ist Trust Anchor.

Sicher belegt ist nur: Subjektinformationen bleiben, Ausstellerbeweis fehlt, Pfade müssen ablehnen, Vertrauen kommt von außen. Diese äußere Hälfte braucht denselben Wahrheitsanspruch wie das Format.

Quellen

  1. Lu Heng, „The Policy Mirror“
  2. RFC 9925, unsignierte X.509-Zertifikate
  3. RFC 5280, X.509-Zertifikats- und CRL-Profil
  4. RFC 4158, Aufbau von Zertifizierungspfaden
  5. RFC 5914, Trust-Anchor-Format
  6. RFC 6024, Anforderungen an Trust-Anchor-Management
  7. RFC 8446, TLS 1.3
  8. RFC 8725, Best Practices für JSON Web Token
  9. IANA, SMI-Nummern
  10. IETF, Charta der LAMPS-Arbeitsgruppe