Zusammenfassung

  • RFC 9881 beschreibt die Verwendung der reinen Varianten ML-DSA-44, ML-DSA-65 und ML-DSA-87 in PKIX-Zertifikaten und CRLs.
  • Die vollständigen OIDs lauten 2.16.840.1.101.3.4.3.17 für ML-DSA-44, 2.16.840.1.101.3.4.3.18 für ML-DSA-65 und 2.16.840.1.101.3.4.3.19 für ML-DSA-87. Sie entsprechen den Sicherheitsstufen 2, 3 und 5.
  • Der Parameterteil von AlgorithmIdentifier MUSS fehlen und darf nicht als NULL codiert werden. signatureValue enthält die rohe Signatur über die DER-codierte signierte Struktur; der Kontext bleibt leer.

Im PKIX-Profil ist der Algorithmus eine exakte Byte-Konvention. Die OID steht in AlgorithmIdentifier, die rohe ML-DSA-Signatur in signatureValue. Geprüft wird die DER-Codierung der signierten Struktur, nicht eine scheinbar gleichwertige Neucodierung. Der optionale Kontext ist für diesen Einsatz leer.

SubjectPublicKeyInfo enthält die rohen Bytes des ML-DSA-öffentlichen Schlüssels ohne zusätzliche ASN.1-Hülle. Die Größen betragen 1.312 Oktette für ML-DSA-44, 1.952 für ML-DSA-65 und 2.592 für ML-DSA-87. Ist keyUsage vorhanden, muss mindestens ein Signaturbit gesetzt sein; Verschlüsselungs- und Schlüsselaustauschbits DÜRFEN bei ML-DSA-Schlüsseln nicht gesetzt werden.

OneAsymmetricKey kann einen Seed, einen erweiterten Schlüssel oder beide enthalten. Für effiziente Speicherung wird die Seed-only-Form empfohlen. Parser müssen anhand des ASN.1-Tags und nicht anhand einer Längenheuristik entscheiden. Bei beiden Repräsentationen führt eine fehlgeschlagene Konsistenzprüfung dazu, dass der Empfänger den privaten Schlüssel als fehlerhaft ZURÜCKWEISEN MUSS.

RFC 9881 wählt reines ML-DSA. HashML-DSA-OIDs DÜRFEN in den erfassten PKIX-Protokollen nicht verwendet werden. Ebenso besteht eine harte Grenze zum vorstandardisierten Dilithium: ML-DSA und Dilithium sind nicht kompatibel. Ein gleicher Name ist kein Grund, das andere Drahtformat zu akzeptieren.

Quellen