要約

  • CBOR tag 601は、署名、MAC、暗号化を内包しないCWT Claims Setを識別する。tag自体は送信元の証明ではない。
  • RATSで使う場合、受信側はチャネル確立時に送信側を認証し、通信の完全性を確保する。機密性、受信側の権限、リプレイ対策は別々に確認する。
  • UCCSを受信環境へ取り出すと、元のチャネルはそのオブジェクトを守らない。転送時には受信側が実質的な送信元となる。

小さな装置の節約は、証拠の省略ではない

通常のCWTはCOSEの封筒に入り、オブジェクト自身が出所認証と完全性の手掛かりを持つ。だが、制約の強い装置では、同じ当事者間にすでに適切な安全関連があるのに、クレームごとに同じ保護を重ねることが負担になる。RFC 9781は、その限られた状況でClaims Setだけを送るUCCSを定義した。

CDDLでは#6.601がクレームのmapを包む。IANA登録によって受信実装は形式を一意に識別できる。しかし、そこに鍵、署名者、セッション、チャレンジ、受信権限は記録されない。規格上の名前が決まったことと、運用上の保証が成立したことは別の事実である。

RATSの伝送では、受信者がチャネル確立時に送信者を認証し、チャネルが通信の完全性を提供しなければならない。機密性を求めるなら受信者も認証される。装置情報を暗号化して送ったというだけでは足りず、その相手に開示する権限があったかまで問われる。

TLS 1.3は例の一つにすぎない。監査記録にはプロトコルと版、暗号方式、サーバーのみか相互かという認証形態、検証した資格情報、信頼アンカー、接続時間、対象となったレコードを残す必要がある。さらに、通常の1-RTTと0-RTTではリプレイの扱いが異なる。RFC 9781もnonce claimによる追加のリプレイ対策を示す。したがって、相手を認証した記録と、今回のクレームが新鮮である記録は分ける。

同じUCCSを使って、そのUCCSを運んだチャネルの資格情報を信頼させることもできない。根拠が自分自身を支える循環になるからだ。端点の身元は独立した信頼経路で確立し、その後にクレームを評価する。

受信した瞬間から、主張者が変わる

RFC 9781の第4節は、UCCSが安全なチャネルから受信環境へ出た時点で、チャネルの安全特性が失われると明記する。さらに受信者が転送する場合、そのUCCSは受信者内部から発生したものとして扱われる。

これは単なる保管手順ではない。受信側は、どのバイトを採用し、どう解析し、正規化するか、どこへ保存し、誰へ渡すかを決める。次の受信者に対しては、元の装置ではなく自分が「このセッションでこのバイト列を受け取った」と主張する立場になる。

そのため、抽出記録には生のUCCSハッシュ、セッション識別子、認証した相手、parserの版、時刻、変換前後のハッシュを結び付ける。保管記録には書き込み主体、アクセス制御、保存時暗号化、保持期限と削除結果を加える。転送記録には入力ハッシュ、新しい送信者、新しいチャネルまたは署名、宛先と応答を残す。

ハッシュ一致は改変検知に役立つが、元の接続を再現しない。保存時暗号化はデータベースを守るが、元のAttesterの署名にはならない。次のTLS接続は中継サービスを認証するが、最初の装置を再認証するわけではない。

委任アテステーションの例は、この境界を正面から扱う。署名鍵を持たないサブAttesterは、ローカルな安全チャネルでUCCSを主Attesterへ渡す。主Attesterはそのハッシュを計算し、自身のEvidence署名鍵で保護する。ここで生まれるのは、元から隠れていた署名ではなく、主Attesterによる新しい責任ある主張である。

完全なCWTは異なる。COSE封筒がオブジェクト固有の出所と完全性を保持するため、外側のチャネルが内側の署名者を自動的に保証することはない。この違いを残すことがUCCSの正確な運用に不可欠だ。

評価と実行を最後まで分ける

必要な証拠列は、形式とバイト、チャネル確立、端点身元、鮮度、抽出、保管、転送、Verifierの評価、Relying Partyの行動である。RFC 9334では、AttesterがEvidenceを作り、Verifierが基準値と方針で評価し、Relying Partyが個別の権限判断を行う。

受信側が転送元になるとき、Verifierは何を評価しているかを明確にしなければならない。元のAttesting Environmentか、受信側が新しく保護した主張か、両者を結ぶ追跡可能な組合せか。ここを曖昧にすると、通信の節約が権限のすり替えに変わる。

RFC 9781は共通層を薄く保つ。tag、必要なチャネル特性、境界後の扱いを定め、最終判断までは奪わない。Heng Luのrunning-codeの基準に照らせば、RFCの存在は設計上の事実であり、実際の保証は認証、nonce、保管、転送、評価、実行の記録によって初めて示される。

情報源