署名検証と Evidence-as-Code ロードマップ
本ページは情報提供である。監査人が再検証を実施できるようにし、将来バージョンで整合性を暗号学的に保証するための Evidence Bundle 署名・検証の進化を述べる。
現状（v0.1）
- 規範: バンドルにはマニフェストを参照する署名エントリが少なくとも1つ MUST。バリデータは存在と参照のみをチェックする。
- 範囲外: 署名バイトの暗号学的検証、署名対象の正規形、署名者識別、検証手順。
v0.1.1 — 検証メタデータ（RECOMMENDED）
v0.1.1 では、監査人が将来再検証できるように、manifest.json の各署名エントリにオプションフィールドを追加する：
| フィールド | 目的 |
|---|---|
signer_identity |
誰が署名したか（例 PGP フィンガープリント、did:key）。 |
signed_at |
署名適用日時（ISO 8601）。 |
verification_command |
監査人向けの例示 CLI（例 aimo verify --pubkey ...）。 |
canonicalization |
署名対象の生成方法（例 rfc8785_json、cbor）。 |
実装者は v0.2 ツールが利用できるよう、これらの記載を RECOMMENDED とする。v0.1.1 のバリデータはこれらのフィールドを読み取り報告するが、暗号学的検証は行わない。
v0.2（予定）— 暗号学的検証とプロビナンス
将来の標準バージョン（目標 2026 Q4–2027）で予定：
- 検証をスコープに: バリデータがアルゴリズム・署名者（例 公開鍵）に対して署名バイトを検証する。検証失敗は報告する。
- プロビナンス: SLSA 風プロビナンス（ビルダー、ビルド種別、素材）や in-toto レイアウトとの整合により、バンドルの生成経路を証明する。
- 正規形: 署名対象の正規化ルール（例 RFC 8785 JSON）を規範化し、再現可能な検証を実現する。
本ロードマップは変更の可能性がある。各バージョンの規範は当該バージョンの標準とスキーマに記載される。