Zielsysteme
Die Bibliothek bietet auf allen Zielsystemen dieselben Verfahren und Datenformate. Diese Seite nennt, welche Assembly für welches Zielsystem gebaut wird und wo sich der Weg zu einer Funktion unterscheidet, weil .NET Framework einen Typ noch nicht kennt.
Assemblies und Zielsysteme
| Assembly | Zielsysteme | Inhalt |
|---|---|---|
WKL.System.Security.Cryptography.Core | .NET Framework 4.6.2, .NET Core 3.1, .NET 8, .NET 9 | PostQuantumConfig, CryptoMode, die Richtlinie und die Schnittstelle der Anbieter |
WKL.System.Security.Cryptography.Extensions | .NET Framework 4.6.2 und 4.7.2, .NET Core 3.1, .NET 8 | die Erweiterungsmethoden und der Anbieter für OpenSSL |
WKL.System.Security.Cryptography.WASM | .NET 9 | der Anbieter für Blazor WebAssembly mit OpenSSL als WebAssembly-Modul |
Eine Anwendung für .NET Framework 4.8 verwendet den Build für 4.7.2, eine Anwendung für .NET 9 oder höher den Build für .NET 8.
Unterschiede auf .NET Framework
| Bereich | .NET Framework | Grund |
|---|---|---|
| Zertifikate ausstellen | X509CertificateBuilder auf allen Fassungen, ab 4.7.2 auch die Erweiterungen von CertificateRequest | CertificateRequest gibt es erst ab .NET Framework 4.7.2 |
CopyWithPrivateKey mit CryptoMode | ab 4.7.2 | die Methode von .NET gibt es erst ab 4.7.2 |
| Selbst signiertes Zertifikat unter 4.6.2 | Den RSA- oder ECDSA-Schlüssel ordnet die Bibliothek über eine PFX-Datei im Arbeitsspeicher zu. Ein Schlüssel, der sich nicht im Klartext exportieren lässt, bleibt unzugeordnet. | 4.6.2 kann einem Zertifikat keinen Schlüssel direkt zuordnen |
| Kettenprüfung mit eigenen Vertrauensankern | Die Anker gehen in ExtraStore. Die Kette gilt nur, wenn sie in einem der Anker endet; ChainStatus nennt dann zusätzlich UntrustedRoot. | X509ChainPolicy.CustomTrustStore fehlt |
| Sperrlisten ausstellen | X509CrlBuilder; die Überladungen von CertificateRevocationListBuilder nur auf .NET 8 | CertificateRevocationListBuilder gibt es erst ab .NET 7 |
PFX mit PbeParameters | PbeParameters und PbeEncryptionAlgorithm stellt die Bibliothek im Namensraum System.Security.Cryptography bereit | .NET Framework kennt die Typen nicht |
| ECDSA und ECDH unter 4.6.2 | mit Schlüsseln vom Typ ECDsaCng und ECDiffieHellmanCng | ECParameters gibt es erst ab .NET Framework 4.7 |
| Composite ML-KEM | Paare mit RSA wie auf .NET 8; Paare mit ECDH werfen PlatformNotSupportedException | der Kombinierer braucht das rohe ECDH-Geheimnis, das .NET erst ab .NET 8 herausgibt |
| OpenSSL laden | Die Bibliothek lädt libcrypto mit vollem Pfad aus PostQuantumConfig.OpenSslPath | .NET Framework kennt keine Auflösung von Bibliotheksnamen zur Laufzeit |
Alle anderen Funktionen verhalten sich auf .NET Framework wie auf .NET 8: hybride und reine
ML-DSA-Zertifikate, Ketten, Signaturen, CMS- und XML-Signaturen, KemEnvelopedCms, PFX-Dateien, die
Schlüsselablage und die Richtlinie.
Unterschiede nach Betriebssystem
| Bereich | Windows | Linux | macOS |
|---|---|---|---|
| .NET Framework | ja | – | – |
| Schlüsseldateien neben dem Zertifikatsspeicher | DPAPI | mit Secret Service | nicht verfügbar |
| Kette mit reinem ML-DSA-Aussteller | ja | wenn auch .NET ein OpenSSL ab 3.5 lädt | ohne Angabe |
| PFX-Import eines Zertifikats mit ML-DSA- oder ML-KEM-Hauptschlüssel | ja | nicht mit .NET 8 | ohne Angabe |
„Ohne Angabe“ heißt: Für diese Kombination liegen keine Zusicherungen vor. Die Einzelheiten zu Linux stehen in So binden Sie OpenSSL ein und So übertragen Sie Zertifikate mit PQ-Schlüssel als PFX.
Grenzen
- .NET Framework nur unter Windows. Mono und andere Laufzeiten für .NET Framework sind nicht vorgesehen.
- .NET Core 3.1 ist bei Microsoft ohne Unterstützung. Die Bibliothek baut weiter dafür, damit bestehende Anwendungen PQ-Verfahren aufnehmen können.