要約

  • RFC 9881 は、PKIX の証明書と CRL で pure ML-DSA-44、ML-DSA-65、ML-DSA-87 を使う方法を定める。
  • 完全な OID は ML-DSA-44 が 2.16.840.1.101.3.4.3.17、ML-DSA-65 が 2.16.840.1.101.3.4.3.18、ML-DSA-87 が 2.16.840.1.101.3.4.3.19 である。安全性レベルは順に 2、3、5 である。
  • AlgorithmIdentifier の parameters は存在してはならず、NULL にしてはならない。signatureValue は DER で符号化された署名対象に対する生の ML-DSA 署名を持ち、context は空のままである。

PKIX ではアルゴリズム識別子がバイト列の規約になる。選択した OID は AlgorithmIdentifier に入り、生の署名は signatureValue に入る。検証者は署名対象構造の DER 表現そのものを検証しなければならず、意味が同じに見える再シリアライズを検証してはならない。PKIX 用途では任意の context は空である。

SubjectPublicKeyInfo は追加の ASN.1 ラッパーなしに、生の ML-DSA 公開鍵バイト列を運ぶ。公開鍵サイズは ML-DSA-44 が 1,312 オクテット、ML-DSA-65 が 1,952、ML-DSA-87 が 2,592 である。keyUsage が存在する場合、少なくとも署名関連ビットを一つ設定し、暗号化および鍵合意ビットを ML-DSA 鍵に設定してはならない。これは RFC の要求である。

OneAsymmetricKey には seed、expandedKey、または両方を入れられる。保存効率の面では seed のみの形式が推奨される。パーサーは長さの推測ではなく ASN.1 タグによって表現を選ばなければならない。両方が存在し、一貫性検査が不一致なら、受信者は秘密鍵を不正形式として拒否しなければならない。

RFC 9881 が選ぶのは pure ML-DSA である。対象となる PKIX プロトコルでは HashML-DSA の OID を使ってはならない。また標準化前の Dilithium との境界も明確で、ML-DSA と Dilithium は互換性がない。名称の一致だけで別のワイヤー形式を受け入れる理由にはならない。

出典