Zusammenfassung

  • RFC 10007 ergänzt RFC 5280: Bei einem v3-Zertifikat des CRL-Ausstellers müssen die Erweiterung keyUsage vorhanden und das Bit cRLSign gesetzt sein.
  • Ein übereinstimmender Subject-DN, derselbe Trust Anchor und eine korrekte Signatur übertragen die Befugnis von Schlüssel A nicht auf Schlüssel B.
  • Die strengere Prüfung kann alte, für CRLs gedachte v3-Zertifikate ohne Erweiterung unbrauchbar machen; CA, Policy Authority und Betreiber der Relying Party haben getrennte Sanierungsaufgaben.

Der Test, der zu früh „gültig“ sagte

Das Beispiel in RFC 10007 beginnt mit Subject X. Eine CA zertifiziert Schlüssel A mit keyUsage und cRLSign. Sie stellt X später ein anderes Zertifikat für Schlüssel B aus, ohne keyUsage, weil B einem gewöhnlichen Zweck dient.

Andere Zertifikate nennen X als indirekten CRL-Aussteller. Signiert X die CRL mit B, passt der Name. Der Zertifizierungspfad kann beim selben Trust Anchor enden. Die Signatur kann korrekt sein. Nur die Befugnis dieses konkreten Schlüssels fehlt.

Die Informationsseite zu RFC 10007 weist die Standards-Track-Veröffentlichung vom Juni 2026 als Aktualisierung von RFC 5280 aus. Der frühere Algorithmus in RFC 5280 prüfte cRLSign, falls keyUsage vorhanden war. Fehlte die Erweiterung, konnte auch die Zweckprüfung entfallen. Die RFC-5280-Übersicht gehört zugleich zu einem Profil, das die Erweiterung für Schlüssel zur Prüfung von Zertifikats- oder CRL-Signaturen bereits verlangte.

RFC 10007 bringt Ausstellung und Prüfung zusammen: Bei v3 muss die Erweiterung existieren und das Bit gesetzt sein. v1- und v2-Zertifikate besitzen kein Erweiterungsfeld; für sie gilt diese Existenzprüfung nicht.

Identität ist keine pauschale Vollmacht

Subject X muss kein Angreifer sein. Beide Schlüssel können rechtmäßig X gehören. Der Fehler entsteht, wenn die Identität des Inhabers als Vollmacht für jeden Schlüssel und Zweck behandelt wird.

RFC 4514 definiert die LDAP-Stringdarstellung von Distinguished Names. Seine Informationsseite macht daraus keinen Schlüssel-Fingerprint. Ein DN kann in mehreren Zertifikaten für unterschiedliche Schlüssel und Zwecke auftauchen.

RFC 5280 trennt digitalSignature, keyCertSign und cRLSign. Letzteres bezeichnet die Prüfung von Signaturen auf CRLs, Delta-CRLs und Authority Revocation Lists. Kryptografische Signierfähigkeit ersetzt keinen zertifizierten Auftrag.

Die Datatracker-Fassung, die Dokumenthistorie, die LAMPS-Charta und die Gruppenhistorie belegen Beratung und Veröffentlichung. Sie belegen keine heutige Produktunterstützung oder Verbreitung.

Eine indirekte CRL braucht mehrere passende Belege

Bei einer indirekten CRL kann ein anderer Akteur als die CA des geprüften Zertifikats die Liste signieren. Der Verteilungspunkt des Zertifikats kann einen cRLIssuer nennen; die kritische CRL-Erweiterung issuingDistributionPoint setzt indirectCRL und begrenzt den Geltungsbereich.

Die Relying Party muss Name, indirekte Rolle, Scope, Pfad, Trust Anchor, Signatur, Zweck, Zeit und abgedeckte Gründe getrennt prüfen. RFC 10007 repariert den Zweck. Ein korrektes cRLSign beweist weder Inhalt noch Aktualität, Vollständigkeit oder Erreichbarkeit.

RFC 3647 trennt CA, Registration Authority, Repository, Subscriber und Relying Party sowie Policy, Praxis, Audit und Statusdienst. Die Informationsseite hilft, die Verantwortung nicht in einem kryptografischen Ergebnis zu verstecken.

Die Reparatur kann den Altbetrieb treffen

RFC 10007 warnt ausdrücklich: Hat eine CA ein v3-Zertifikat für die CRL-Prüfung ausgestellt, aber keyUsage weggelassen, können aktualisierte Anwendungen die damit signierte CRL nicht mehr verifizieren. Die Absicht kann legitim gewesen sein; das Zertifikatsprofil war es nicht.

Die CA sollte inventarisieren, das Profil korrigieren, neu ausstellen, eine Überlappung schaffen und den alten Aussteller nachweisbar stilllegen. Ist eine Profiländerung unmöglich, soll die Policy Management Authority unterschiedliche DNs für unterschiedliche Zwecke verlangen. Das begrenzt die beschriebene Verwechslung, ersetzt aber weder Zweckangabe noch Schlüsselverwahrung, Scope und Frische.

Eine abgelehnte CRL beweist keine Sperrung des Zielzertifikats. Sie liefert keinen akzeptablen Status; das Ergebnis kann unbestimmt sein. „Gut“ und „gesperrt“ dürfen diesen dritten Zustand nicht verschlucken.

OCSP besitzt eigene Delegationsregeln. RFC 6960 verlangt CA-Signatur, lokale Konfiguration oder eine unter definierten Bedingungen ausgestellte Delegation mit id-kp-OCSPSigning; seine Informationsseite beschreibt einen anderen Mechanismus. RFC 6818 und die zugehörige Übersicht dokumentieren eine frühere Pflege von RFC 5280. Dokumentpflege ist keine automatische Flottenänderung.

Deterministische Regel, lokale Einführung

Lu Hengs Running-Code Primacy trennt Veröffentlichung von laufender Realität. Sein Rahmen für Minimum Initial Specification, Localized Future Decision und Voluntary Adoption legt schmale, lokal prüfbare Sicherheitsinvarianten in die gemeinsame Schicht und belässt die Einführung bei den Betreibern.

Die v3-Regel ist genau so eine Invariante. Eine Relying Party kann das exakte Zertifikat prüfen und B ohne institutionelles Ermessen ablehnen. Reissuance, Test, Zeitpunkt und Abdeckung bleiben jedoch Aufgaben der Systeme, die das Ergebnis tragen.

Quellen