Zusammenfassung

  • RFC 9883 erlaubt dem Inhaber eines Signaturzertifikats, den Besitz eines anderen privaten Schlüssels zur Schlüsseleinrichtung zu erklären, ohne diesen Besitz technisch zu beweisen.
  • Die CA muss Zertifikatspfad, Antragssignatur und Identitätsbindung prüfen und eine Richtlinie anwenden, die diese Ersetzung ausdrücklich zulässt.
  • Wird der Signaturschlüssel kompromittiert, müssen die auf seinen Erklärungen beruhenden Einrichtungszertifikate auffindbar und widerrufbar sein.

Die Akte enthält einen neuen öffentlichen Schlüssel, ein Besitzattribut und eine korrekte Signatur. Trotzdem hat der zum neuen Schlüssel gehörende private Schlüssel keine prüfbare Operation ausgeführt. Signiert hat der private Schlüssel eines älteren Zertifikats.

Zwei Schlüssel tragen nicht denselben Nachweis

Zuerst erzeugt der Antragsteller ein Signaturschlüsselpaar, unterschreibt einen gewöhnlichen Antrag und erhält ein Signaturzertifikat. Danach erzeugt er ein Paar zur Schlüsseleinrichtung. Der zweite PKCS#10-Antrag enthält den neuen öffentlichen Schlüssel und privateKeyPossessionStatement, verweist auf das ältere Zertifikat und wird mit dem ersten privaten Schlüssel signiert.

RFC 9883 bezeichnet die Semantik offen: Das Subjekt des Signaturzertifikats erklärt ohne Beweis, den privaten Einrichtungsschlüssel zu besitzen. Eine CA darf dies nur anstelle eines technischen Nachweises akzeptieren, wenn ihre Zertifikatsrichtlinie es erlaubt. RFC 6955 bietet technische Verfahren für bestimmte DH- und ECDH-Schlüssel, passt aber nicht zu PKCS#10 und unterstützt keine KEMs wie ML-KEM. Die neue Erklärung funktioniert mit PKCS#10 und CRMF.

Die gültige Signatur beweist damit die Kontrolle über den Signaturschlüssel in diesem Antrag. Sie bindet einen bereits zertifizierten Akteur an eine Aussage über einen anderen Schlüssel. Erzeugungsort, Exportierbarkeit, fortbestehende Verfügbarkeit oder Hardwareverwahrung dieses anderen Schlüssels werden nicht sichtbar.

Die Richtlinie übernimmt die Lücke

Die CA muss den Pfad des Signaturzertifikats nach RFC 5280 validieren und die Antragssignatur mit dessen öffentlichem Schlüssel prüfen. Fehler führen zur Ablehnung. Die Subjektnamen sollten übereinstimmen. Weichen Subjekt oder alternative Namen ab, muss die Richtlinie erklären, wie dieselbe Entität festgestellt wird; gelingt das nicht, ist der Antrag abzulehnen.

Das Attribut bezeichnet das Signaturzertifikat durch Aussteller und Seriennummer und kann es optional enthalten. Bei gleichem Aussteller darf es fehlen. Dann nimmt der Antragsteller jedoch an, dass die CA sämtliche gültigen, von ihr ausgestellten Zertifikate abrufen kann. Das ist eine Betriebseigenschaft des Repositoriums. Ein Verweis ersetzt weder das abgerufene Zertifikat noch den validierten Pfad oder den damaligen Widerrufsstatus.

CRMF verwendet die Signaturauswahl von ProofOfPossession, verlangt poposkInput, Absenderidentität und eine Kopie des Einrichtungsschlüssels und legt die Erklärung in regInfo ab. Die Verpackung ändert sich; der Einrichtungsschlüssel führt weiterhin keinen Besitznachweis aus.

Das Attribut darf deshalb nicht für ein Signaturzertifikat verwendet werden. Ein signaturfähiger Schlüssel kann seinen Besitz unmittelbar durch das Signieren des eigenen Antrags beweisen. Die Ausnahme bleibt auf Einrichtungsschlüssel begrenzt.

Widerruf folgt der Abhängigkeit

Ein Angreifer mit dem Signaturschlüssel kann neue Erklärungen erzeugen. Die vorgesehene Schutzmaßnahme ist der rechtzeitige Widerruf des Signaturzertifikats. Bei kompromittierungsbedingtem Widerruf sollte die CA auch alle Einrichtungszertifikate widerrufen, die durch damit signierte Erklärungen erlangt wurden.

Dafür braucht sie vom Ausstellungszeitpunkt an einen Rückwärtsindex: Signaturzertifikat, Antragsbytes, Richtlinienversion, Identitätsentscheidung und resultierende Zertifikate. Der Signaturschlüssel sollte mindestens so stark sein wie der Einrichtungsschlüssel, damit die Vertrauensbrücke nicht zum schwächeren Glied wird.

Quellen