Zusammenfassung

  • RFC 9883 lässt einen zertifizierten Signaturschlüssel eine Besitz-Erklärung für einen anderen Schlüsselaufbauantrag tragen.
  • Die Erklärung behauptet Besitz, liefert aber keinen technischen Besitznachweis.
  • Die CA muss Zertifikatspfad und Antragssignatur prüfen; Identitätsabweichungen sind anhand einer dokumentierten Gleichwertigkeitsregel zu klären.

Die operative Falle besteht darin, eine gültige Signatur als Antwort auf zwei verschiedene Fragen zu behandeln. Sie zeigt, wer den Antrag signiert hat; sie beweist nicht, wer den privaten Schlüssel des beantragten Zertifikats kontrolliert. privateKeyPossessionStatement überträgt Zusicherung vom ersten auf den zweiten Schlüssel, jedoch nur als signierte Behauptung.

Die Attribut-OID lautet 1.3.6.1.4.1.22112.2.1. Die vollständige Struktur ist PrivateKeyPossessionStatement ::= SEQUENCE { signer IssuerAndSerialNumber, cert Certificate OPTIONAL }: signer benennt das Signaturzertifikat über Ausstellername und Seriennummer, das optionale Feld cert enthält dieses Zertifikat. cert darf nur fehlen, wenn die CA zugleich Aussteller des Signaturzertifikats ist und alle von ihr ausgestellten gültigen Zertifikate abrufen kann. Das ist eine enge Abrufausnahme, keine Erlaubnis zur Identitätsvermutung.

Die CA muss den Zertifizierungspfad des Signaturzertifikats validieren und den Antrag bei einem ungültigen Pfad ablehnen. Ebenso muss sie die Antragssignatur mit dem öffentlichen Schlüssel dieses Zertifikats prüfen und bei einem Fehler ablehnen. Subjektname und SANs sollten denen des Signaturzertifikats entsprechen. Bei Abweichungen muss die Zertifikatspolitik die Gleichwertigkeit erklären; kann die CA sie nicht feststellen, muss sie ablehnen. Das Attribut darf nicht zum Erhalt eines Signaturzertifikats verwendet werden.

Bei PKCS#10 enthält subjectPublicKeyInfo den öffentlichen Schlüssel für den Schlüsselaufbau; die Attribute enthalten die Erklärung, und die Antragssignatur wird mit dem Signaturzertifikat geprüft. Bei CRMF enthält der Zertifikatsantrag Subjekt und öffentlichen Schlüssel; der Proof-of-Possession-Mechanismus nutzt die Signaturauswahl und die Absenderidentität, während regInfo die Erklärung trägt. Die gleiche Absicht bedeutet nicht, dass beide Formate dieselbe Codierungsstruktur haben.

RFC 5280 liefert die Grundlage für Zertifizierungspfad und Key Usage. RFC 6955 ist ein Vergleichspunkt für technische Besitznachweise bei Diffie-Hellman-Schlüsseln. RFC 9883 macht seine Erklärung nicht zu einem kryptografischen Nachweis des zweiten privaten Schlüssels. Dieser Gegenstand ist außerdem von den ML-DSA-Kennungen in PKIX aus RFC 9881 und den signierten CMS-Bytes aus RFC 9882 getrennt.

Analyse von Theo March: Operativ kann das Signaturzertifikat als delegierte Zusicherungswurzel für den zweiten Schlüssel verstanden werden. Das ist Analyse, kein RFC-Mandat. Eine CA sollte jedes abgeleitete Schlüsselaufbauzertifikat mit dem autorisierenden Signaturzertifikat verknüpfen, die Gleichwertigkeitsentscheidung protokollieren und Mengen, Identitätswechsel, Wiederholungen sowie Fehler überwachen.

Die Verknüpfung erzeugt einen Revokations-Fan-out. RFC 9883 nennt bei kompromittiertem Signaturzertifikat die rechtzeitige Sperrung als einzigen dort beschriebenen Schutz und sagt, die CA sollte über solche Erklärungen erlangte Schlüsselaufbauzertifikate sperren. Inventar, Alarmierung und Automatisierung sind Analyse, kein vorgeschriebenes Schema. Der Signaturschlüssel sollte mindestens die Sicherheitsstärke des Schlüsselaufbauschlüssels besitzen. Für Migrationen empfiehlt Theo Marchs operative Analyse, Stärke, Algorithmen und Identitätsgleichwertigkeit zu testen.

Test-Fixtures sollten gültigen Pfad und gültige Signatur, ungültigen Pfad, veränderte Signatur, fehlendes eingebettetes Zertifikat bei fremder CA, erfolgreiches Abrufen bei der ausstellenden CA, abweichende Subjekte und SANs mit und ohne dokumentierte Gleichwertigkeit, den Versuch eines Signaturzertifikats, einen schwächeren Signierer sowie getrennte PKCS#10- und CRMF-Prüfungen enthalten. Protokollieren: Aussteller, Seriennummer, Fingerabdrücke, Richtlinienentscheidung und ausgestelltes Zertifikat.

Bei einem Vorfall zuerst die Ausstellung aus dem verdächtigen Signaturzertifikat stoppen und Beweise sichern. Kompromittierung bestätigen, das Signaturzertifikat unverzüglich sperren, alle durch seine Erklärungen abgeleiteten Zertifikate ermitteln und nach CA-Politik bewerten oder sperren. Danach Schlüssel erneuern, Gleichwertigkeits- und Stärkeausnahmen prüfen und Wiederholungen überwachen. Dieser Ablauf ist Analyse, nicht ein vollständiger RFC-Workflow.

Quellen