Zusammenfassung

  • RFC 5280 verlangte im Zertifikatsprofil bereits keyUsage mit cRLSign, während der Validierungsalgorithmus das Bit nur prüfte, falls die Erweiterung vorhanden war.
  • RFC 10007 macht für v3-Zertifikate beide Befunde obligatorisch. Passender DN, gültiger Pfad und korrekte Signatur ersetzen die Zweckbefugnis nicht.
  • Ein belastbarer Beleg trennt Zertifikatsversion, ausgewählten Schlüssel, Erweiterung, CRL-Umfang und -Frische, Pfad, Signatur, Zielstatus und Altfall-Ausnahme.

Der gefährliche Fall sieht zunächst ordentlich aus. Eine CRL ist signiert. Das Aussteller-DN passt zum Distribution Point. Der Zertifizierungspfad führt zur erwarteten Vertrauenswurzel. Keine dieser Aussagen muss falsch sein.

Trotzdem kann der verwendete Schlüssel für CRL-Signaturen unbefugt sein.

RFC 10007 beschreibt, wie das möglich wird, und aktualisiert damit RFC 5280. Das Standards-Track-Dokument erschien im Juni 2026; Autoren sind Corey Bonnell, Tadahiko Ito und Tomofumi Okubo, Bonnell steht an erster Stelle. Die Namensnennung belegt seinen Beitrag zu kollektivem IETF-Werk. Sie macht ihn weder zum alleinigen Erfinder noch zum Betreiber der betroffenen Systeme.

Zwei Schlüssel, ein Subject

Eine CA delegiert die Ausstellung indirekter CRLs an Subject X. Für Schlüssel A stellt sie ein Zertifikat aus, dessen keyUsage den Wert cRLSign enthält. Betroffene Zertifikate verweisen in cRLIssuer auf das DN von X.

Die CA zertifiziert für X außerdem Schlüssel B. Dieser ist für einen gewöhnlichen Zweck vorgesehen; sein Zertifikat enthält keine keyUsage-Erweiterung. Subject-DN und gültiger Pfad können mit A übereinstimmen.

Signiert X eine CRL mit B, kann die mathematische Prüfung erfolgreich sein. Auch der Name stimmt. Doch das Zertifikat von B hat B nie als CRL-Signaturschlüssel ausgewiesen. Die Befugnis von A darf nicht allein über die gemeinsame Identität auf B übergehen.

Damit wird eine grundlegende PKI-Trennung sichtbar. Die Bindung eines Schlüssels an ein Subject und die Zertifizierung eines Verwendungszwecks sind verschiedene Aussagen. Wer beide unter „Zertifikat gültig“ zusammenfasst, erweitert den Handlungsspielraum des Schlüssels ohne positive Grundlage.

Die Prüfung, die bei Abwesenheit verschwand

Section 4.2.1.3 von RFC 5280 verlangt keyUsage als critical, wenn ein Zertifikat Signaturen auf Zertifikaten oder CRLs prüft. cRLSign kennzeichnet den speziellen Zweck der CRL-Signaturprüfung.

Der spätere Algorithmus formulierte jedoch bedingt: Wenn eine Key-Usage-Erweiterung vorhanden ist, soll cRLSign geprüft werden. Ein Zertifikat mit vorhandener Erweiterung ohne Bit fällt durch. Fehlt die Erweiterung ganz, konnte eine wörtliche Implementierung die Prüfung überspringen. Abwesenheit wurde günstiger behandelt als ein ausdrücklicher Ausschluss.

Das ist ein typischer Validierungsfehler. Der Wert eines optionalen Feldes wird geprüft, aber seine im jeweiligen Kontext erforderliche Anwesenheit nicht. Das System meldet Erfolg, weil es keinen negativen Wert gefunden hat, obwohl es überhaupt keine positive Befugnis fand.

RFC 10007 ersetzt den Schritt für v3-Zertifikate: keyUsage muss vorhanden sein und cRLSign muss gesetzt sein. Beides gehört getrennt ins Protokoll. Fehlende Erweiterung deutet auf ein falsches Profil oder ein falsch ausgewähltes Zertifikat. Fehlendes Bit bei vorhandener Erweiterung beschreibt einen anderen Zweck.

Ein Versionsfall braucht eine dokumentierte Ausnahme

X.509-v1- und v2-Zertifikate haben kein Extensions-Feld. Deshalb wendet RFC 10007 die Anwesenheitsprüfung nicht auf sie an. Diese Ausnahme folgt dem Format und ist keine allgemeine Erlaubnis, die Erweiterung bei v3 wegzulassen.

Bei der Einführung können alte Profilfehler sichtbar werden. Eine CA hat vielleicht ein v3-Zertifikat für CRLs ausgestellt, aber keyUsage vergessen. Alte Anwendungen akzeptieren seine CRLs, aktualisierte Anwendungen lehnen dieselben Bytes ab. Die Signatur ist nicht plötzlich falsch; die zuvor übersprungene Zweckprüfung ist aktiv geworden.

RFC 10007 empfiehlt die korrekte Erweiterung, um Interoperabilitätsprobleme zu vermeiden. Lässt sich das Profil nicht ändern, soll die PKI-Policy-Instanz für unterschiedliche Zwecke eindeutige DNs verlangen. Das mindert die Verwechslung zweier Schlüssel, ersetzt aber weder Neuausstellung noch Migrationsentscheidung.

Ein neuer Reject ist daher weder automatisch Softwarefehler noch Beweis eines Angriffs. Sicher ist nur: Das ausgewählte v3-Zertifikat stellt die erforderliche Autorisierung nicht regelkonform dar. Ausnutzung und Wirkung erfordern eigene Belege.

Ein autorisierter Signierer ist noch kein Endergebnis

Nach cRLSign bleiben Ausstellerwahl, Zertifizierungspfad, Signaturalgorithmus, Distribution Point, Issuing Distribution Point, indirekte CRL, kritische Erweiterungen sowie thisUpdate und nextUpdate. Complete und Delta CRL müssen zueinander passen.

Anschließend wird das Serial des Zielzertifikats gesucht. Eine autorisiert signierte CRL kann veraltet oder außerhalb ihres Umfangs sein. Eine vollständig gültige CRL kann das Ziel als widerrufen melden. Kein positives Teilergebnis darf die übrigen Felder füllen.

Auch ein Autorisierungsfehler beweist nicht, dass die CRL inhaltlich gefälscht oder ein Schlüssel kompromittiert ist. Er benennt, dass die für diese Handlung geforderte Befugnis fehlt.

Heng Lus Agency-Perspektive ordnet die Zuständigkeiten. Standardautoren schaffen die gemeinsame Grammatik, die CA wählt das Profil, der Hersteller schreibt Running Code, eine Policy-Instanz genehmigt Ausnahmen und der Dienst trägt Verfügbarkeitsfolgen. Die Minimum Specification koordiniert die Prüfsemantik; Migration bleibt lokal. Kein Akteur leiht dem nächsten still seine Autorität.

Den Entscheidungsweg als Receipt erhalten

Der Beleg fixiert Zielzertifikat, Trust Anchor, CRL-URI und -Hash, Abrufzeit, thisUpdate, nextUpdate, Algorithmus und Validator-Version. Das ausgewählte Ausstellerzertifikat wird mit Serial, Subject Key Identifier, relevantem Authority Key Identifier, DN und Version identifiziert.

Danach folgen getrennte Ergebnisse für Pfad, Signatur, v3-Eigenschaft, Anwesenheit und Criticality von keyUsage sowie cRLSign. Eine v1/v2-Ausnahme nennt Policy, Owner, Population und Review-Termin.

Ein eigener Block enthält Distribution Point, cRLIssuer, indirekte CRL, Issuing Distribution Point, Reasons und Complete/Delta-Beziehung. Der Zielblock enthält Serialfund, Widerrufsdatum und -grund, fehlende oder veraltete Evidenz und die Anwendungsentscheidung.

So lässt sich eine Flottendifferenz erklären: fehlender neuer Test, andere Zertifikatsauswahl oder ein Fehler in einer späteren Stufe. Ein einfarbiger Status kann das nicht.

Die Schlussaussage bleibt eng: Ein benannter Validator verarbeitete eine konkrete CRL mit einem bestimmten v3-Zertifikat; keyUsage und cRLSign waren vorhanden; Pfad, Signatur, Umfang, Frische und Zielserial ergaben getrennte Befunde. Verantwortbare Automatisierung verspricht nicht mehr. Sie beweist jeden Schritt.

Quellen