#78888 crypto/x509,crypto/tls: add ML-DSA support

AIによる要約であり、誤りを含む場合があります。

概要

crypto/x509 および crypto/tls パッケージに、耐量子計算機暗号の署名アルゴリズムである ML-DSA（Module-Lattice-Based Digital Signature Algorithm、FIPS 204）のサポートを追加するproposalです。量子コンピュータの実用化タイムラインが従来予測より大幅に前倒しになったことを受け、Go標準ライブラリでのポスト量子署名対応を具体的に実現します。

ステータス変更

（新規） → active
2026年4月22日に @aclements によりproposal reviewの「active」カラムへ追加され、週次proposalレビュー会議での審議対象となりました。proposalの提案者はGoのセキュリティ担当であるFilipo Sottile氏であり、Go暗号ライブラリの信頼性から迅速にactiveへ移行されたと考えられます。

技術的背景

現状の問題点

現在のGoの crypto/tls および crypto/x509 は、RSAやECDSA、Ed25519などの従来の公開鍵暗号アルゴリズムにのみ対応しています。しかし2026年時点で、以下の問題が顕在化しています。

量子コンピュータの脅威タイムライン前倒し: Googleの研究によると、256ビット楕円曲線暗号の解読に必要な量子ビット数が当初予測より大幅に少ないことが判明。2029年を暗号セキュリティの重要な閾値とする見方も出ており、従来の「様子見アプローチ」が通用しない状況になりました。
プライベートPKIの移行余地が狭い: WebPKIはMerkle Tree Certificates（2027年頃）への移行が見込まれていますが、プライベートPKIはその恩恵を受けにくく、今から対応が必要です。
ML-DSAの葉公開鍵は必須: Merkle Tree CertificatesでさえML-DSAの葉公開鍵を必要とするため、先行して対応する意義があります。

提案された解決策

本proposalは、#77626（crypto/mldsaパッケージの新設）のAPIを前提として、crypto/x509 と crypto/tls にML-DSAの対応を追加します。コンポジット署名（従来の署名と組み合わせる方式）ではなく「純粋なML-DSA署名（pure ML-DSA）」のみを対象とし、実装をシンプルに保ちます。
crypto/x509 への追加内容:

新しい PublicKeyAlgorithm 定数:
```
const MLDSA PublicKeyAlgorithm = iota
```

新しい SignatureAlgorithm 定数（セキュリティレベル別に3種）:

const MLDSA44 SignatureAlgorithm = iota  // NISTセキュリティレベル2
const MLDSA65 SignatureAlgorithm = iota  // NISTセキュリティレベル3
const MLDSA87 SignatureAlgorithm = iota  // NISTセキュリティレベル5

*mldsa.PublicKey / *mldsa.PrivateKey の各証明書操作関数への対応（CreateCertificate、MarshalPKIXPublicKey、ParsePKIXPublicKey、MarshalPKCS8PrivateKey、ParsePKCS8PrivateKeyなど）
crypto/tls への追加内容:

新しい SignatureScheme 定数（IANAに登録済みのコードポイント）:

const MLDSA44 SignatureScheme = 0x0904
const MLDSA65 SignatureScheme = 0x0905
const MLDSA87 SignatureScheme = 0x0906

ML-DSA X.509証明書によるハンドシェイク署名の検証サポート
Certificate.PrivateKey として *mldsa.PublicKey を返す crypto.Signer のサポート
仕様の根拠は、X.509側がRFC 9881、TLS側がdraft-ietf-tls-mldsa-02です。秘密鍵フォーマットはRFC 9881推奨の「シードのみ（32バイト）」形式のみを実装します。

これによって何ができるようになるか

コード例

// Before: ML-DSAはGoの標準ライブラリで使用不可
// 自己署名証明書にECDSAしか使えず、量子コンピュータ耐性がない
privateKey, _ := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)
template := &x509.Certificate{
    SerialNumber:          big.NewInt(1),
    SignatureAlgorithm:    x509.ECDSAWithSHA256,
    // ... その他フィールド
}
certDER, _ := x509.CreateCertificate(rand.Reader, template, template, &privateKey.PublicKey, privateKey)
// After: ML-DSA-65を使った耐量子計算機証明書の生成
import "crypto/mldsa"
import "crypto/x509"
mldsaKey, _ := mldsa.GenerateKey(mldsa.MLDSA65())
template := &x509.Certificate{
    SerialNumber:          big.NewInt(1),
    SignatureAlgorithm:    x509.MLDSA65,
    // ... その他フィールド
}
certDER, _ := x509.CreateCertificate(rand.Reader, template, template, mldsaKey.Public(), mldsaKey)

// After: ML-DSA証明書を使ったTLSサーバ設定
tlsCert, _ := tls.X509KeyPair(certPEM, keyPEM)
server := &tls.Config{
    Certificates: []tls.Certificate{tlsCert},
    // ML-DSA44/65/87の署名スキームが自動的に利用可能になる
}

実践的なユースケースとしては以下が考えられます。

企業内プライベートPKIの量子耐性化: 社内CAで発行する証明書をML-DSAベースに移行し、内部サービス間のTLS通信を量子コンピュータ耐性のある署名で保護できます。
金融・医療など規制産業でのコンプライアンス対応: NISTがFIPS 204として標準化したML-DSAを標準ライブラリで直接利用でき、認定された実装であることを担保しやすくなります。
段階的なハイブリッド移行の足がかり: まず純粋ML-DSA対応を実装し、将来的にコンポジット署名（別proposalとして分離）への移行パスを確保します。

議論のハイライト

コンポジット署名は対象外: 本proposalは意図的に「純粋なML-DSA署名のみ」に限定しています。コンポジット署名（従来署名＋ML-DSAの組み合わせ）は別のproposalとして分離するよう明示されており、議論の混乱を防いでいます。
TLS草案の採用判断: draft-ietf-tls-mldsa-02 はIETF WG内の政治的理由でまだDraft段階ですが、IANAへのコードポイント登録は完了しており（0x0904〜0x0906）、他の実装も存在することからGoとして採用を決定しています。
既存APIへの統合: 新しい型を大量に追加するのではなく、既存の PublicKeyAlgorithm、SignatureAlgorithm、SignatureScheme などの列挙に値を追加するアプローチを採用。APIの変更量は「列挙型への値追加とswitch文の拡張」程度であり、後方互換性を維持します。
crypto/mldsaパッケージ（#77626）との依存関係: 本proposalは crypto/mldsa パッケージのAPIが前提となります。*mldsa.PrivateKey は crypto.Signer を実装しており、既存のTLS/X509の crypto.Signer インターフェースとシームレスに連携します。
タイミングの必然性: 提案者のblogで示された「2029年の量子脅威閾値」や、WebPKIのMerkle Tree Certificates移行計画（2027年頃）が直接的な動機です。待ち続けることのリスクが、不確実性よりも大きくなったと判断されています。

Go Proposal Weekly Digest

crypto/x509,crypto/tls: add ML-DSA support

要約

概要