SPECIFICATION

第 8 章：暗号学と署名

本章は CAP プロトコルが使用する署名アルゴリズム、鍵形式、鍵ライフサイクル管理および配布要件を定義する。本章の暗号学要件は規範的である——CAP プロトコルに適合するすべての実装は MUST 本章定義に従い実施する。

8.1 アルゴリズム集

CAP v1 は強制実装の署名アルゴリズムと鍵形式を 2 セット定義する：

アルゴリズム ID	アルゴリズム	公開鍵長	署名長	状態
`ed25519`	Ed25519（RFC 8032）	32 バイト	64 バイト	必須実装
`ecdsa-p256-sha256`	ECDSA P-256 + SHA-256（RFC 6979）	65 バイト（未圧縮）/ 33 バイト（圧縮）	64 バイト（DER エンコードまたは raw）	必須実装

すべての CAP 実装は MUST この 2 セットのアルゴリズムを同時にサポートする。Trusted_Ticket が JWS を使用する場合、対応するアルゴリズム名は：

CAP アルゴリズム ID	JWS `alg` フィールド
`ed25519`	`EdDSA`
`ecdsa-p256-sha256`	`ES256`

8.1.1 アルゴリズム選択推奨

ed25519 を優先使用：性能が良く、署名が短く、鍵管理がより簡単
ecdsa-p256-sha256：FIPS 140-3 等の規制要件下で使用

発行者は SHOULD すべての新規発行クレデンシャルでデフォルトで ed25519 を使用する、明確な遵守要件がある場合を除く。

8.1.2 許可されないアルゴリズム

CAP v1 実装は MUST NOT 以下のアルゴリズムで新規クレデンシャルを発行または受け入れる：

任意の RSA 署名バリアント（性能不良、鍵が大きい）
ECDSA secp256k1（非 FIPS 標準曲線）
ECDSA P-384 / P-521（v1 では強制せず、将来バージョンで追加可能性あり）
任意の SHA-1 派生署名アルゴリズム

8.2 鍵形式

8.2.1 Ed25519

公開鍵は RFC 8032 §5.1.5 に従いエンコード：

32 バイトのリトルエンディアンの圧縮 Edwards 曲線点

DescriptorPayload の signature.signature_value は 64 バイトの原始署名（ASN.1 エンコードを含まない）。

JWS の署名は RFC 8037 に従いエンコード、64 バイトの原始署名を base64url エンコード。

8.2.2 ECDSA P-256

公開鍵は RFC 5480 に従いエンコード：

未圧縮形式：65 バイト（0x04 || X || Y）
圧縮形式：33 バイト（0x02/0x03 || X）

実装は MUST 未圧縮および圧縮形式の公開鍵を同時に受け入れる。

署名形式：

DescriptorSignature 内：64 バイトの原始署名（R || S、各部分 32 バイトのビッグエンディアン）、DER 不使用
JWS 内：RFC 7518 §3.4 に従いエンコード（64 バイト R || S）

8.2.3 鍵のバイナリ表現

VerificationKey.key_material フィールドは上記形式のバイトシーケンスを直接保管する：

ed25519 → 32 バイト
ecdsa-p256-sha256（未圧縮） → 65 バイト
ecdsa-p256-sha256（圧縮） → 33 バイト

8.3 署名入力構築

8.3.1 Authorization_Descriptor 署名入力

以下のステップで署名入力を構築する：

AuthorizationDescriptor.payload（DescriptorPayload 構造）を取得
RFC 8949 CBOR 確定性エンコーディング（Deterministic Encoding）でバイトシーケンスにシリアライズ
当該バイトシーケンスは署名アルゴリズムの入力となる

CBOR 確定性エンコーディングの主要制約（RFC 8949 §4.2 由来）：

map のキーは辞書順でソート
数値は最短エンコーディングを使用
文字列とバイト列は最短長エンコーディングを使用
不確定長エンコーディング（indefinite-length encoding）を使用しない

実装は MUST 厳格にこれらの制約を遵守し、実装間の署名検証一貫性を保証する。

8.3.2 Trusted_Ticket 署名入力

RFC 7515 §5.1 に従い JWS 署名入力を構築：

Signing Input = base64url(UTF8(Header)) + "." + base64url(UTF8(Payload))

ここで：

Header と Payload は RFC 7159 に従い UTF-8 JSON にシリアライズ
JSON フィールド順序：実装は SHOULD キーを辞書順でソートするが、厳格なフィールド順序要件は base64url エンコードのバイトで決定される

8.3.3 RevocationStatement 署名入力

失効声明の署名入力構築は Authorization_Descriptor と同じ：

signature フィールドを除去し、その他の RevocationStatement フィールドを保持
CBOR 確定性エンコーディングシリアライゼーション
バイトシーケンスを署名入力とする

8.4 鍵配布

8.4.1 配布モード

端末は MUST 以下の 2 種類の Verification_Key 配布モードをサポートする：

オフラインプリインストール（Pre-installed）

端末出荷時または配備時に初期 Verification_Key をプリインストールする。プリインストール鍵：

VerificationKey 構造で source = "pre-installed" とマーク
MUST 製造または配備段階で物理的または管理されたセキュアチャネルを通じて書き込む
通常はルートレベル Descriptor_Issuer（デバイスベンダー認証 Issuer 等）に対応

オンライン配布（RA-distributed）

Registration_Authority がオンラインインタフェースを通じて新しい Verification_Key を配布する：

VerificationKey 構造で source = "ra-distributed" とマーク
MUST TLS/mTLS チャネルを通じて伝送する（§1.3.4 を参照）
端末は MUST 伝送者が信頼された Registration_Authority であることを検証する

8.4.2 信頼アンカー構成

端末の Registration_Authority 公開鍵（RA プッシュメッセージの署名検証に使用）は信頼アンカーとして：

MUST 端末製造または初回配備時にプリインストールされる
物理的または管理されたチャネルでのみ更換可能
CAP プロトコルランタイムメカニズムでは更新しない

8.4.3 配布メッセージ

Registration_Authority がプッシュする鍵配布メッセージ：

VerificationKeyDistribution {
  required version       : uint32 (= 1)
  required key           : VerificationKey
  required ra_signature  : DescriptorSignature       // Registration_Authority による署名
}

端末処理フロー：

ra_signature が信頼アンカー Registration_Authority によって発行されたものか検証
key.algorithm が §8.1 で許可されたアルゴリズム集合内にあることを検証
key.valid_from が端末の現在時刻と合理的か検証（現在時刻 +24 時間を超えない等）
端末鍵保管に書き込み
Registration_Authority に確認を返却（確認メカニズムは本仕様の範囲外）

8.5 鍵保管

端末は MUST すべての Verification_Key とローカル署名鍵（§4.4.3 を参照）を安全に保管する。

8.5.1 保管要件

端末は MUST：

すべての鍵の秘密鍵部分を暗号化保管する（公開鍵は平文保管可）
秘密鍵アクセスは OS プロセス権限で保護され、Protocol_Engine のみが読み取り可能
SHOULD 秘密鍵をハードウェアセキュリティ要素（TPM、Secure Enclave、TEE 等）に保存する

端末は MUST NOT：

平文形式で秘密鍵を永続化媒体に書き込む
秘密鍵を CAP プロトコルメッセージで伝送する
デバッグログまたはエラー出力で秘密鍵内容を露出する

8.5.2 鍵漏洩処理

端末が鍵漏洩の可能性を検出した場合（安全保管が攻撃された等）：

直ちに当該鍵の使用を停止
§8.6 フローを通じて Registration_Authority に報告
新鍵配布完了前は、関連クレデンシャルの検証をすべて拒否（保守的ポリシー）

8.6 鍵更新とローテーション

8.6.1 スムーズ移行

Registration_Authority は Verification_Key ローテーション時に MUST スムーズ移行を提供する：

新鍵をすべての端末に配布
移行期間中（デフォルト 30 日）、新旧鍵が並存して有効
移行期間終了後、旧鍵の valid_until が到来し、自動失効

端末は移行期間中、MUST 新旧鍵を同時に維持し、key_id に従い対応する鍵を選択して検証する。

8.6.2 緊急失効

VerificationKeyRevocation {
  required version          : uint32 (= 1)
  required key_id           : string
  required revocation_time  : timestamp
  required reason           : enum["compromised", "superseded", "ra_decision"]
  required ra_signature     : DescriptorSignature
}

端末は失効メッセージ受領後、MUST：

署名が信頼アンカー Registration_Authority 由来であることを検証
直ちに当該 key_id を失効済みとマーク
後続検証要求で当該 key_id を使用するクレデンシャルをすべて拒否（E_VERIFICATION_KEY_INVALID を返却）
すべてのアクティブ Session を主動チェック：当該 key_id で発行されたクレデンシャルを使用する Session を強制終了（§5.5 を参照）

8.6.3 端末ローカル署名鍵のローテーション

端末が §4.4 変換フローをサポートするために保有するローカル署名鍵：

90 日ごとに SHOULD 自動ローテーション
ローテーション時に端末が新鍵対を生成、旧鍵は既発行クレデンシャルの検証用にすべて期限切れまで継続使用
端末は MAY 最大 4 つのローカル署名鍵を同時保有できる（最長有効期間 + スムーズ移行をカバー）

8.7 暗号学要件サマリー

要件	範囲
署名アルゴリズムは MUST ed25519 / ecdsa-p256-sha256 から選択	すべての署名シナリオ
秘密鍵は MUST 安全保管	すべての発行者と端末
公開鍵配布は MUST 暗号化チャネルを通じる	Registration_Authority → 端末
信頼アンカーは MUST 物理的または管理されたチャネルでプリインストール	すべての端末
CBOR 確定性エンコーディングをオフラインクレデンシャル署名入力に使用	Authorization_Descriptor、RevocationStatement
JWS Compact Serialization をオンラインチケットに使用	Trusted_Ticket