Formate der Post-Quanten-Anteile

graph TD
    CERT["Hybrides Zertifikat"]
    TBS["TBSCertificate mit drei nicht kritischen Erweiterungen"]
    SPKI["subjectAltPublicKeyInfo: ML-DSA-Schlüssel des Inhabers"]
    ALG["altSignatureAlgorithm: ML-DSA-Parametersatz"]
    VAL["altSignatureValue: ML-DSA-Signatur des Ausstellers"]
    SIG["Klassische Signatur: RSA oder ECDSA über das ganze TBSCertificate"]
    CERT --> TBS
    CERT --> SIG
    TBS --> SPKI
    TBS --> ALG
    TBS --> VAL

Bild: Ein hybrides Zertifikat ist ein gewöhnliches X.509-Zertifikat. Der Post-Quanten-Anteil liegt in drei nicht kritischen Erweiterungen, die die klassische Signatur mit abdeckt.

Die Bibliothek legt jeden Post-Quanten-Anteil so ab, dass Software ohne PQ-Kenntnis die Daten weiter liest und prüft. Wo eine Norm ein Format festlegt, folgt die Bibliothek ihr. Wo noch keine Norm besteht, verwendet sie vorläufige Kennungen; diese Stellen sind unten genannt.

• Hybride Zertifikate und Sperrlisten nach ITU-T X.509 (10/2019), alternative Signaturen.
• Reine ML-DSA-Zertifikate nach RFC 9881.
• Composite ML-DSA für rohe Signaturen nach dem IETF-Entwurf draft-ietf-lamps-pq-composite-sigs.
• CMS-Verschlüsselung für ML-KEM nach RFC 9629 (KEMRecipientInfo).
• PFX-Dateien nach RFC 7292 mit dem ML-DSA-Schlüssel in einer eigenen Schlüsseltasche.
• Vorläufig: PQ-Signaturen in CMS und in XML, hybride Verschlüsselung mit EncryptHybrid.

Ein hybrides Zertifikat trägt drei nicht kritische Erweiterungen aus ITU-T X.509 (10/2019):

Die ML-DSA-Signatur deckt das TBSCertificate ohne die Erweiterung altSignatureValue ab. Die klassische Signatur deckt das ganze TBSCertificate ab, also auch die drei Erweiterungen. Ein klassischer Prüfer übergeht unbekannte nicht kritische Erweiterungen und prüft das Zertifikat wie jedes andere. Sperrlisten aus X509CrlBuilder tragen ihre zusätzliche Signatur auf dieselbe Weise.

Zertifikate der Betriebsart PostQuantum tragen den ML-DSA-Schlüssel als gewöhnlichen SubjectPublicKeyInfo und sind mit ML-DSA signiert, wie RFC 9881 es festlegt. Die Bibliothek unterstützt die Parametersätze ML-DSA-44, ML-DSA-65 und ML-DSA-87. Welche davon ohne Freischaltung Daten erzeugen, regelt die Richtlinie für Post-Quanten-Verfahren.

Rohe Signaturen der Betriebsart Hybrid sind Composite-ML-DSA-Signaturen nach dem IETF-Entwurf draft-ietf-lamps-pq-composite-sigs (Fassung 19): eine ML-DSA-Signatur, an die die RSA- oder ECDSA-Signatur angehängt ist. Der Entwurf legt feste Paare fest. Die Bibliothek unterstützt diese; die Spalte „Hashverfahren“ nennt den Wert, den Sie SignData und VerifyData übergeben:

Ein anderes Paar, etwa ML-DSA-65 mit RSA-2048, weist die Bibliothek mit einer CryptographicException ab. Die Paare mit ML-DSA-44 signieren nur mit der Freischaltung ReducedParameterSets; prüfen lassen sie sich ohne. Ed25519 und Ed448 fehlen, weil .NET 8 kein EdDSA bietet.

KemEnvelopedCms schreibt CMS EnvelopedData (RFC 5652) mit KEMRecipientInfo (RFC 9629). Für ML-KEM entspricht das Format dem, das OpenSSL 3.6 schreibt; für Composite ML-KEM folgt es dem IETF-Entwurf draft-ietf-lamps-cms-composite-kem. RSA-Empfänger derselben Nachricht erhalten eine KeyTransRecipientInfo mit RSAES-OAEP.

EnvelopedCms von .NET kann eine Nachricht mit KEMRecipientInfo nicht dekodieren, auch nicht für einen RSA-Empfänger derselben Nachricht. Gemischte Nachrichten öffnen Sie deshalb mit KemEnvelopedCms.

ExportPfx schreibt eine PKCS#12-Datei nach RFC 7292. Der ML-DSA-Schlüssel liegt als zusätzliche, verschlüsselte Schlüsseltasche neben dem klassischen Schlüssel; dieselbe localKeyId verbindet ihn mit dem Zertifikat. ML-KEM- und Composite-ML-KEM-Schlüssel liegen auf dieselbe Weise in der Datei. Andere Programme lesen das Zertifikat und den klassischen Schlüssel wie gewohnt und übergehen die zusätzliche Tasche. Wie die Datei verschlüsselt ist, beschreibt Schlüssel und ihre Ablage.

Für die folgenden Fälle vergibt noch keine Norm Kennungen. Die Bibliothek verwendet vorläufige Kennungen. Nur Gegenstellen, die diese Bibliothek verwenden, prüfen den PQ-Anteil; klassische Prüfer lesen die Daten weiter.

Die Ankündigung in CMS ist durch die klassische Signatur geschützt. Entfernt jemand die PQ-Signatur, erkennt ein Prüfer mit dieser Bibliothek das als Herabstufung und weist die Nachricht ab.

• Vorläufige Kennungen sind nicht registriert. Eine künftige Norm wird andere Kennungen vergeben. Setzen Sie PQ-Signaturen in CMS und XML deshalb nur zwischen Anwendungen ein, die diese Bibliothek verwenden, und bewahren Sie signierte Dokumente nicht allein im Vertrauen auf diese Kennungen langfristig auf.
• Entwürfe sind keine Normen. Composite ML-DSA und Composite ML-KEM folgen IETF-Entwürfen in einer bestimmten Fassung. Eine Gegenstelle, die eine andere Fassung umsetzt, kann solche Signaturen und Nachrichten ablehnen.
• Eigenes Binärformat nur zwischen Ihren Anwendungen. EncryptHybrid und PqCrypto eignen sich nicht für den Austausch mit fremder Software. Für den Austausch verwenden Sie KemEnvelopedCms.

• Betriebsarten und Aufrufbindung
• Schlüssel und ihre Ablage
• So signieren Sie CMS-Nachrichten
• So signieren Sie XML-Dokumente
• So verschlüsseln Sie CMS-Nachrichten