Zusammenfassung

  • RFC 9882 definiert reines ML-DSA-44, ML-DSA-65 und ML-DSA-87 für CMS SignedData, nicht aber HashML-DSA.
  • Das Vorhandensein von signedAttrs trennt die eContent-Wertbytes vom vollständigen SignedAttrs-DER.

Die vollständigen OIDs lauten 2.16.840.1.101.3.4.3.17, 2.16.840.1.101.3.4.3.18 und 2.16.840.1.101.3.4.3.19. Parameter im ML-DSA-AlgorithmIdentifier müssen fehlen; der ML-DSA-Kontext ist leer.

Bei signierten Attributen muss der Digest gegen Zweitpräbild- und Kollisionsangriffe die Lambda-Bit-Sicherheit des Parametersatzes bieten und mindestens 2*Lambda Ausgabebits erzeugen. Der niedrigere Wert von Digest und ML-DSA begrenzt die Stärke. Tabelle 1 vollständig: ML-DSA-44—SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256; ML-DSA-65—SHA-384, SHA-512, SHA3-384, SHA3-512, SHAKE256; ML-DSA-87—SHA-512, SHA3-512, SHAKE256. SHA-512 muss unterstützt werden, SHAKE256 wird empfohlen; beide Identifier haben keine Parameter.

Fixture mit zwei Pfaden. Pfad A gilt ohne signedAttrs. Er signiert ausschließlich die Wertbytes des eContent-OCTET STRING; Tag- und Längenbytes werden ausgeschlossen. Für Interoperabilität codiert der Signierer SHA-512 in digestAlgorithm; auf Pfad A hat dieses Feld keine kryptografische Bedeutung, und der Prüfer ignoriert seinen Inhalt. Pfad A enthält weder content-type noch message-digest und verlangt keine Neuberechnung eines signierten Attribut-Digests oder des Inhalts-Hashs. Pfad B gilt mit signedAttrs. Er signiert die vollständige DER-Kodierung von SignedAttrs einschließlich Tag und Länge und verwendet das explizite SET OF-Tag, niemals das abschließende implizite [0]. Er enthält mindestens content-type und message-digest; nur Pfad B verlangt, dass der Empfänger den Inhalts-Hash neu berechnet und mit message-digest vergleicht.

CMSAlgorithmProtection sollte in signierten Attributen enthalten sein, um Algorithmusersetzung abzuwehren. Dies ist eine normative Empfehlung, keine Aussage über Installationen. Große Inhalte dürfen außerhalb der HSM-Signaturgrenze bleiben. Die externe Berechnung des Pure-Mode-Repräsentanten mu ist in RFC 9881 Appendix D und FIPS 204 Section 6.2 beschrieben. HSM-Schnittstellenkontrollen und Einführungsfolgen sind Theo Marchs Analyse. Hedged- und deterministische Signaturen verwenden denselben Prüfer; bei Seitenkanal- oder Fehlerinjektionsrisiken sollte die deterministische Signatur nicht verwendet werden.

Betriebliche Einordnung

Die normativen Regeln stammen aus RFC 9882, RFC 5652, RFC 6211, RFC 9881 und FIPS 204. Theo Marchs Analyse empfiehlt, Pfad, Byte-Längen und Fingerprints, OID, fehlende Parameter, Tags, Attribute, Digest-Identifier, Hashvergleich auf B, HSM-Grenze und Prüfergebnis zu erfassen. Stufenweise Aktivierung, Shadow-Prüfung und getestete Rücknahme sind Empfehlungen, keine RFC-Pflichten und keine Adoptionsbehauptungen. RFC 9881 behandelt PKIX; RFC 9879 hat einen anderen Gegenstand.

Quellen