要約

  • RFC 9882はCMS SignedData向けにpure ML-DSA-44、ML-DSA-65、ML-DSA-87を定めるが、HashML-DSAは定めない。
  • signedAttrsの有無によって、eContentの値オクテットを署名する経路と、SignedAttrsの完全なDERを署名する経路が分かれる。

完全なOIDは2.16.840.1.101.3.4.3.17、2.16.840.1.101.3.4.3.18、2.16.840.1.101.3.4.3.19である。ML-DSA AlgorithmIdentifierのパラメータは省略し、コンテキスト文字列は空とする。

署名属性がある場合、ダイジェストは第二原像攻撃と衝突攻撃の双方に対し、ML-DSAパラメータセットのlambdaビットの安全性を提供し、出力は少なくとも2*lambdaビットでなければならない。強度はダイジェストとML-DSAの低い方で制限される。表1の全集合は、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は必須、SHAKE256は推奨で、両識別子のパラメータは省略する。

二経路バイトfixture。 経路AはsignedAttrsがない場合である。eContentのOCTET STRINGの値オクテットだけを署名し、タグと長さのオクテットは除外する。相互運用性のため署名者はdigestAlgorithmにSHA-512を符号化するが、このフィールドは経路Aで暗号学的意味を持たず、検証者は内容を無視する。経路Aにはcontent-typeもmessage-digestもなく、署名属性のmessage-digestまたは内容ハッシュを再計算する要件もない。経路BはsignedAttrsがある場合である。SignedAttrsの完全なDERをタグと長さを含めて署名し、明示的なSET OFタグを使う。最終メッセージの暗黙[0]には置き換えない。経路Bには少なくともcontent-typeとmessage-digestを含め、受信者が内容ハッシュを再計算してmessage-digestと比較するのは経路Bだけである。

署名属性にはCMSAlgorithmProtectionを含めることが望ましい。これはアルゴリズム置換への規範的な推奨であり、導入実績の主張ではない。大きな内容はHSM署名境界の外に置ける。pure-modeのメッセージ代表muの外部計算はRFC 9881 Appendix DとFIPS 204 Section 6.2に記載される。HSMインターフェース管理と導入順序はTheo Marchの分析である。hedged署名と決定論的署名は同じ検証器を使うが、サイドチャネルまたは故障攻撃が懸念される場合、決定論的署名は使うべきではない。

運用上の読み方

規範的根拠はRFC 9882、RFC 5652、RFC 6211、RFC 9881、FIPS 204である。Theo Marchの分析では、経路、バイト長と指紋、OID、パラメータ省略、タグ、属性、ダイジェスト識別子、経路Bのハッシュ比較、HSM境界、検証結果を記録する。段階導入、シャドー検証、ロールバック試験は推奨事項であり、RFC要件でも普及の主張でもない。RFC 9881はPKIX、RFC 9879は別の対象を扱う。

出典