概要

crypto/x509パッケージのCertificate、CertificateRequest、RevocationList構造体にRawSignatureAlgorithm []byteフィールドを追加するproposalです。このフィールドにより、Goが現時点で認識できない署名アルゴリズム（例: Merkle Tree Certificates用のアルゴリズム）を持つ証明書を扱う際に、生のDERエンコードされたAlgorithmIdentifierバイト列を直接取得・比較できるようになります。

ステータス変更

active → likely_accept
2026年4月29日の週次Proposalレビュー会議において、@aclementsがコアチームの総意として「likely accept」への移行を宣言しました。既存のRaw*フィールド群（RawIssuer、RawSubject等）と同様の設計パターンに沿っており、シンプルかつ後方互換性を持つAPIであることが評価されました。また、pkix.AlgorithmIdentifier型（古いasn1.ObjectIdentifier型を使用）ではなく[]byteを採用することで、将来的なOID表現の移行方針にも沿っています。

技術的背景

現状の問題点

x509.ParseCertificate()は未知の署名アルゴリズムを持つ証明書を正常にパースしますが、SignatureAlgorithmフィールドをUnknownSignatureAlgorithmにセットします。これにより、呼び出し元はその証明書が期待するアルゴリズム（例: MTC用の特定OID）を使っているかどうかを確認できません。
Merkle Tree Certificates（MTC）はTLSにおける証明書透明性（Certificate Transparency）を統合した新しい証明書形式で、特有の署名アルゴリズムOID（id-alg-mtcProof、実験段階では1.3.6.1.4.1.44363.47.0）を使用します。このOIDは現時点でGoの標準ライブラリに登録されておらず、MTC証明書のアルゴリズムを検証するワークアラウンドがありませんでした。
署名アルゴリズムはX.509上ではAlgorithmIdentifier（OIDとオプションのANYパラメータから構成されるDER構造体）として表現されます。単純なOIDではなく、パラメータを含む可能性があるため、単一フィールドとして扱う必要があります。

提案された解決策

crypto/x509の以下の3つの構造体に同名フィールドを追加します。

// crypto/x509.Certificate
// crypto/x509.CertificateRequest
// crypto/x509.RevocationList
RawSignatureAlgorithm []byte // DER encoded AlgorithmIdentifier

このフィールドは証明書パース時に生のDERバイト列として設定されます。既知のアルゴリズムでも未知のアルゴリズムでも常に設定されます。

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

独自の署名アルゴリズム（MTC、ポスト量子暗号の実験的実装等）を扱うコードが、Goの標準ライブラリを改変することなく、証明書内の署名アルゴリズムを正確に識別・検証できるようになります。

コード例

// Before: 従来の方法 — 未知アルゴリズムかどうかしか分からない
cert, _ := x509.ParseCertificate(der)
if cert.SignatureAlgorithm == x509.UnknownSignatureAlgorithm {
    // アルゴリズムが何なのか判別できない
    // MTCのOIDかどうか確認する手段がない
}
// After: RawSignatureAlgorithm を使った方法
import "golang.org/x/crypto/cryptobyte"
import "golang.org/x/crypto/cryptobyte/asn1"
cert, _ := x509.ParseCertificate(der)
// 期待するAlgorithmIdentifier（MTC用OID）のDERバイト列と比較
expectedAlgID := []byte{...} // id-alg-mtcProof のDERエンコード
if bytes.Equal(cert.RawSignatureAlgorithm, expectedAlgID) {
    // MTC署名アルゴリズムであることを確認して検証処理へ
}
// または cryptobyte で詳細をパース
s := cryptobyte.String(cert.RawSignatureAlgorithm)
var oid asn1.ObjectIdentifier
s.ReadASN1ObjectIdentifier(&oid)

議論のハイライト

• 提案者の初期案: 提案者（@davidben、Cloudflare、MTC仕様の著者）は当初、(1) 生のアルゴリズムフィールドの露出、(2) MTC署名アルゴリズムの正式サポート、の2択を提示。OIDが未確定な実験段階の仕様をハードコードすることへの懸念から(1)が選ばれた。
• 型の選択: pkix.AlgorithmIdentifier型ではなく[]byteを採用。pkix.AlgorithmIdentifierは古いasn1.ObjectIdentifier型（文字列ではなく[]intスライス）を使用しており、Goチームは将来この型から離れる方針のため、生バイト列の方が適切と判断された。
• 対象構造体の拡大: @aarongable（GoogleのChrome証明書チーム）がRevocationList（CRL）への追加も提案し、@FiloSottileがCertificateRequestも含めた3構造体への追加に拡張した。X.509の署名アルゴリズム表現は証明書・CRL・CSRで共通のセマンティクスを持つため。
• 既存のRaw*パターンとの整合性: Certificate構造体にはRawIssuer、RawSubject、RawTBSCertificate、RawSubjectPublicKeyInfo等の生DERフィールドが既に存在しており、RawSignatureAlgorithmはその設計哲学と一致する。
• 関連する取り組みとの連携: 同時期にVerifyOptions.UnknownAlgorithmVerifier（#74024）や相対OIDサポート（#75260）等のproposalも並行して議論されており、MTC対応に向けたGoのcrypto/x509整備が進んでいる。