要約

  • RFC 9782 は CWT、JWT、CBOR/JSON の detached bundle、CBOR/JSON の非保護 claims set に六つの media type を与え、+cwt と CoAP Content-Format も登録した。
  • 任意の eat_profile parameter は body を開く前の振り分けに使えるが、内部 claim との一致や full profile 適合を証明するものではない。
  • 入口での型判定、bytes の確認、暗号または channel の保護、freshness、Verifier の appraisal、Relying Party の許可は、それぞれ独立した記録が必要である。

六つの型が整えるのは最初の交差点

RATS では Attester が Evidence を作り、Verifier が appraisal policy に照らして Attestation Results を作る。Relying Party はその結果と自身の policy を用いて、対象リソースに対する具体的な操作を決める。RFC 9782 は、この役割分担を変更せず、役割間を流れる表現に安定した名前を与えた。

application/eat+cwt と application/eat+jwt、CBOR と JSON の detached EAT bundle、そして CBOR の UCCS と JSON の UJCS が六つの型である。同じ区別に CoAP の 263 から 268 が割り当てられ、+cwt suffix は基礎構文が CWT であることを汎用処理系へ伝える。

これにより gateway は未対応形式を早く拒否し、Accept で結果形式を交渉し、狭い parser を選べる。しかし suffix は署名者、許可された algorithm、検証 key、必須 claim、freshness や業務 policy を示さない。bundle の名前も detached claims set と保護された digest の一致を証明しない。

UCCS/UJCS は差をさらに明確にする。RFC 9781 では、RATS で扱う secure channel が送信者を認証し integrity を守る必要があり、confidentiality には受信者認証も必要である。claims set が channel の外へ出れば、その保護は終わる。保存や再送は新しい引き渡しになる。一方、同じ channel を通る完成済み CWT は channel によって保証されず、自身の COSE envelope を検証しなければならない。

profile の名は検査表を選ぶ

EAT は JSON/CBOR、入れ子形式、COSE/JOSE、algorithm、key 識別、bundle、claim、freshness について選択肢を残す。RFC 9711 の profile は、特定用途に必要な選択を固定する仕組みである。

token 内部の eat_profile claim は URI または OID で profile を識別する。RFC 9782 は同じ識別子を media type parameter に置けるようにした。router は body を覗かず profile 専用 processor を選べる。未知 profile を入口で捉え、万能 parser への依存を減らせる点は大きい。

ただし外部 parameter は送信者の申告である。安全な decode の後、内部 claim が欠けているのか、一致するのか、衝突するのかを区別する必要がある。衝突は client の混乱、古い intermediary、置換の兆候かもしれず、黙って補正してはならない。

一致も適合の証明ではない。RFC 9711 は eat_profile で partial profile を識別することを禁じる。full profile は、双方が適合していれば、receiver が sender のあらゆる EAT を decode、verify し、freshness を確認できるほど完全でなければならない。正しい URI と禁止 algorithm、欠落 claim、誤った nonce rule は同居し得る。名は検査表を選ぶだけで、実行結果を作らない。

申告より bytes を優先する

RFC 9782 は media type を processing application への「手掛かり」にすぎないとする。application は申告にかかわらず実データが期待形式に一致するか検証し、失敗時に停止しなければならない。寛容な sniffing で別形式を受け入れると、cross-protocol attack や privilege escalation を招く。RFC 9110 と RFC 8725 も、誤推測や JWT 種別混同に対して同じ方向の境界を求める。

したがって受信記録は一つの success flag では足りない。header と byte hash、選択 route と parser、envelope・algorithm・key・trust anchor、または非保護 set の channel identity と scope を分ける。detached bundle では各 digest の照合結果も残す。

その後に claims の意味を評価する。RFC 9711 が定めるのは意味であり、計測実装の安全強度ではない。valid signature は key model 内で bytes の帰属を示すが、sensor が正直に測ったことまでは示さない。Verifier は実装、endorsement、reference value、policy を合わせて appraisal する。

freshness も独立する。すべての EAT 利用は replay を防ぐ仕組みを持たなければならず、profile が nonce や時刻などを指定する。真正な token でも古い場合がある。暗号検証と freshness を一つの「valid」にまとめると、再現可能な原因を失う。

最後に Verifier の結果と Relying Party の行為を分ける。良好な結果でも、別リソース、期限、法的条件、リスク policy により拒否できる。不確定な結果に限定権限と短い期限を与える場合もある。RFC 9782 は判断材料を正しい場所へ運ぶが、判断そのものではない。

証拠列は、外部 type/profile → exact bytes → handler → protection → 内部 profile/claims → 適合/freshness → appraisal → action となる。IANA 登録は共有された象徴層を作る。Heng Lu が述べる running code の現実は、実装が同じ不正 bytes を拒み、同じ profile を実行し、その遷移を観測したときに初めて生まれる。

情報源