Crypto プロファイル¶

英語の仕様の参考訳です（28/10/2026 更新）。規範となるのは英語版です。この翻訳に規範的な効力はなく、内容が異なる場合は英語版が優先されます。識別子とコードブロックは翻訳せずにそのまま掲載しています。

状態： 公開済み — v2.0
範囲： 暗号アルゴリズムの選択、複合署名、暗号の俊敏性、検証器のポリシー

目的¶

DCP コアは暗号の署名とハッシュ関数を求めますが、特定のアルゴリズムを意図的に義務づけていません。Crypto プロファイルは、DCP v2.0 で使う具体的な暗号の選択と、その選択を時とともに発展させる仕組みを定義します。

この分離により、次のことが保証されます：

コアのプロトコルは、構造の変更なしにアルゴリズムの移行（たとえばポスト量子への移行）を乗り越えられる
検証器は、リスクの文脈に基づいて独自のアルゴリズムのポリシーを適用できる
実装はクラシカルなアルゴリズムから始め、準備ができたらポスト量子を採用できる
アルゴリズムの非推奨化がコアの仕様を壊さない

ここにあるもの（コアにはない）¶

アルゴリズムのレジストリ¶

承認された署名のアルゴリズム（Ed25519、ML-DSA-65、ML-DSA-87、SLH-DSA-192f）、鍵カプセル化の仕組み（X25519、ML-KEM-768、ハイブリッドの X25519+ML-KEM-768）、ハッシュのアルゴリズム（SHA-256、SHA3-256、SHA-384）の集合。

参考の注記（2026 年 10 月 25 日）、プロファイルの一部ではありません： DCP-AI の SDK のどれもまだ ML-DSA-87 を実装しておらず、ハイブリッドの X25519+ML-KEM-768 の交換をエクスポートしているものもありません（docs/NIST_CONFORMITY.md）。

完全なレジストリは DCP-AI v2.0 の 2 節を参照してください。

複合署名の結び付け¶

クラシカルとポスト量子のどちらの署名の構成要素も取り除けないようにする、pq_over_classical の結び付けのプロトコル：

クラシカルの署名は context || 0x00 || payload に署名する
PQ の署名は context || 0x00 || payload || classical_sig に署名する

結び付けのプロトコルと通信路上の形式は DCP-AI v2.0 の 5 節を参照してください。

ドメインの分離¶

アーティファクトをまたいだリプレイ攻撃を防ぐコンテキストのタグ。アーティファクトの種類ごとに一意のコンテキストのタグがあります（たとえば DCP-AI.v2.AgentPassport、DCP-AI.v2.Intent）。

タグの完全なリストは DCP-AI v2.0 の 4 節を参照してください。

検証モード¶

どの署名の構成要素が必要かを決める、検証器が決定権を持つポリシー：

classical_only — クラシカルの署名だけが必要
hybrid_preferred — クラシカルは必須、PQ は推奨
hybrid_required — クラシカルと PQ の両方が必須
pq_only — PQ の署名だけが必要（フェーズ 3）

検証モードと検証器のポリシーの形式は DCP-AI v2.0 の 7 節を参照してください。

暗号の俊敏性¶

ガバナンスの権限者が、署名されたアドバイザリーによってアルゴリズムを非推奨にしたり失効させたりでき、検証器が自動で対応する、アルゴリズムのアドバイザリーの仕組み。

DCP-AI v2.0 の 13.2 節と AUDIT の報告の欠落 4 を参照してください。

二重のハッシュチェーン¶

一方のハッシュの系統が危殆化しても連続性を保つ、監査エントリーのための並行した SHA-256 と SHA3-256 のハッシュチェーン。

DCP-AI v2.0 の 10.3 節を参照してください。

コアに残るもの¶

アーティファクトが署名されているという要件（ただしどのアルゴリズムかは含まない）
監査エントリーがハッシュチェーンでつながっているという要件（ただしどのハッシュ関数かは含まない）
バンドルの構造と検証のモデル
bundle_hash と merkle_root の概念

規範的な参照¶

DCP-AI v2.0 — 2 節（アルゴリズムのレジストリ）、4 節（ドメインの分離）、5 節（複合署名）、7 節（検証モード）、10.3 節（二重のハッシュ）、13.2 節（アドバイザリーの仕組み）
NIST への適合 — NIST のポスト量子暗号への適合
セキュリティのモデル — 脅威のモデルと保護の層

実装に関する注記（参考）¶

2026 年 10 月 25 日に追加。規範的ではありません。 これらの注記は要件を加えず、上の内容を何も変えません。main のリファレンスのコードがこの文書とどう関係するかを説明するものです。食い違う場合は、上の規範的な本文がそのまま有効です。

複合の結び付けが除去を検出可能にするのは、検証器がそれを求める場合だけです。意味を持つのは検証器が解決する実効のモードで、リスクティア、セキュリティティア、ポリシーを適用した後は、求められた default_mode より厳しくなることがあります。 SDK の検証器では、PQ の署名を取り除き、結び付けのラベルを classical_only に付け替えたものは、実効のモードが classical_only か hybrid_preferred の場合は受け入れられ（hybrid_preferred では警告付き）、hybrid_required か pq_only の場合は拒否されます。許容されうるのは、明示的に存在しない PQ の署名だけです。pq_over_classical のもとで存在する無効な PQ の署名は、どのモードでも拒否され、そのほかの確認もすべて引き続き適用されます。
SDK の検証器の pq_only は、引き続き、クラシカルの署名のバイト列が存在する pq_over_classical の結び付けを求めます。PQ の署名がそれを覆うからです。PQ の署名だけを持つバンドルは受け入れません。
アドバイザリーの仕組みは自動ではありません。検証器がアドバイザリーを適用するのは、その運用者がそれを読み込み、アドバイザリーのヘルパーを呼ぶか、それに応じてポリシーを設定したときです。
SDK の検証器は SHA-256 の監査チェーンと Merkle ルートを確認しますが、@dcp-ai/sdk 2.2.1、@dcp-ai/wasm 2.1.1、dcp-ai 2.10.1（PyPI）、Go v2.11.1、Rust dcp-ai 2.11.1 以降は、存在する二次の SHA3-256 のフィールドも確認します（VERIFICATION.md の V2-11 とその正誤）。それより前のバージョンは確認しません。