RFC 9261 Quiz

**Explanation:** **出題意図:** 小さな TLS の仕組みと, その上に作る identity・attestation・authorization の仕組みを分けて読めるようにします. **用語:** **Exported Authenticator** は, peer が identity を扱えることを handshake 後に示す proof です. **post-handshake** は, TLS または DTLS の接続がすでにできた後という意味です. **選択肢:** - A (incorrect): RFC 9261 は X.509 を置き換えません. X.509 certificate などの identity を使います. - B (correct): RFC 9261 の中心はここです. - C (incorrect): tenant, workload, agent, authorization policy などは application protocol や verifier policy 側で定義します. **関連キーワード:** - **Exported Authenticator** : 既存の TLS/DTLS connection に結びついた identity proof - **post-handshake** : secure connection が確立した後 - **building block** : application protocol が組み込んで使う部品

**Explanation:** **出題意図:** RFC が提供する暗号部品と, system 側が決める policy を混同しないようにします. **用語:** **verifier policy** は提示された identity や attestation を受け入れるかを決める規則です. **application-level meaning** は tenant, service, task などの文脈です. **選択肢:** - A (correct): RFC 9261 は tenant や workload の意図を自動では知りません. - B (incorrect): connection 由来の材料を使うことは RFC 9261 の中核です. - C (correct): これは application, verifier, deployment が決めます. - D (correct): authenticator は independent かつ unidirectional で, 作成や検証で TLS state が明示的に変わるわけではありません. **関連キーワード:** - **verifier policy** : evidence を受け入れるかを決める規則 - **application protocol** : request を運び, その意味を定義する層 - **TLS state** : TLS connection が内部で持つ protocol 状態

**Explanation:** **出題意図:** 小さな field でも replay や文脈の取り違えを防ぐ security control になることを押さえます. **用語:** **certificate_request_context** は request を識別する opaque value です. **opaque** は protocol が中身を名前として解釈しない byte string という意味です. **選択肢:** - A (correct): request と response を結びつけます. - B (incorrect): 再利用は replay や context confusion の原因になります. - C (correct): 同じ connection 内で unique である必要があります. - D (correct): 一時的な private key exposure による precomputation を避ける意味があります. **関連キーワード:** - **certificate_request_context** : request を識別し authenticator に echo される opaque value - **replay resistance** : 古い proof を別の場面で通さない性質 - **context confusion** : 別の request や目的の proof を誤って受け入れること

**Explanation:** **出題意図:** Exported Authenticator を「certificate と signature だけ」と単純化しすぎないようにします. **用語:** **CertificateVerify** は authenticator transcript に対して private key の所有を示します. **Finished** は TLS connection と transcript から導いた材料で MAC を確認します. **選択肢:** - A (incorrect): proof と transcript check を落としています. - B (correct): RFC 9261 の non-empty authenticator validation は connection, request, authenticator transcript に依存します. - C (incorrect): certificate name check だけでは足りません. **関連キーワード:** - **CertificateVerify** : 正しい transcript 上で private key の所有を示す signature - **Finished** : authenticator transcript material に対する MAC check - **transcript** : proof の計算対象になる順序付き byte 列

**Explanation:** **出題意図:** 形式モデルの主張を, full RFC 9261 の破綻という強すぎる主張に広げないようにします. **用語:** **Handshake Context** は connection と authenticator data から導かれる値です. **channel binding** は proof を特定の TLS/DTLS connection に結びつけることです. **選択肢:** - A (incorrect): 同じ certificate だけでは不十分です. - B (incorrect): full validation path を省いた model は proof obligation を示すもので, RFC 9261 全体の破綻証明ではありません. - C (correct): generation と validation が別 connection なら CertificateVerify validation は失敗します. **関連キーワード:** - **Handshake Context** : validation に使われる connection-derived value - **channel binding** : proof を特定 connection に結びつける性質 - **reduced model** : full validation の一部を省いた簡略モデル

**Explanation:** **出題意図:** valid protocol object と identity が認証されたことを分けて理解します. **用語:** **empty authenticator** は Certificate や CertificateVerify を持たない Finished-only の object です. **authenticated refusal** は, 拒否そのものに integrity があるという意味です. **選択肢:** - A (correct): well-formed empty authenticator は refusal であり, identity validation としては invalid と扱われます. - B (incorrect): identity や attestation は認証されていません. - C (incorrect): TLS version upgrade とは関係ありません. **関連キーワード:** - **empty authenticator** : Finished だけを持つ refusal object - **authenticated refusal** : 保護された拒否であり identity success ではない - **identity validation** : 提示された identity が証明されたと判断すること

**Explanation:** **出題意図:** RFC の allowed behavior を, application 側の policy 判定にどう接続するかを考えます. **用語:** **attestation required** は application 側の policy です. **no attestation identity** は, policy が承認できる identity evidence が返っていない状態です. **選択肢:** - A (correct): identity がないのに attestation success と返すのは危険です. - B (correct): valid EA processing と attestation verified は別の outcome です. - C (incorrect): empty authenticator は refusal であって attestation success ではありません. - D (correct): policy enforcement のために結果を明確に分ける必要があります. **関連キーワード:** - **aTLS deployment** : attestation policy を評価する application 側の文脈 - **attestation identity** : verifier policy が承認する identity evidence - **policy result** : success, refusal, failure など caller に見える判断

**Explanation:** **出題意図:** model が含んでいる範囲と, report が言える範囲を揃えます. **用語:** **reduced model** は一部の詳細を省いた model です. **proof obligation** は full system でまだ確認すべき主張です. **選択肢:** - A (incorrect): model の範囲を超えた強い読みです. - B (correct): full CertificateVerify / Finished transcript check を抽象化しているため, proof obligation として読むのが適切です. - C (incorrect): non-empty authenticator validation ではそれらの check が重要です. **関連キーワード:** - **same-endpoint model** : 同じ endpoint の設定に焦点を当てた model - **abstraction** : 詳細を省いて狭い性質を見ること - **proof obligation** : full system で確認が必要な主張

**Explanation:** **出題意図:** deployment-specific な parameter の論点を, RFC 9261 の label 自体の欠陥と読み違えないようにします. **用語:** **exporter label** は TLS exporter の用途を分ける文字列です. **attestation binder** は attestation evidence を protocol context に結びつける application-specific value です. **選択肢:** - A (incorrect): RFC 9261 の registered label が間違っているという話ではありません. - B (incorrect): label や binder parameter は policy design に関係することがあります. - C (correct): scope は deployment-specific な parameter と verifier policy です. **関連キーワード:** - **exporter label** : TLS exporter の用途を分ける string - **attestation binder** : evidence を context に結びつける application-specific value - **verifier policy** : evidence を受け入れるかを決める規則

**Explanation:** **出題意図:** report claim を正確に置きます. 問題は empty authenticator の存在ではなく, policy 上の解釈です. **用語:** **missing attestation** は policy が必要とする attestation identity が返っていない状態です. **verified attestation** は verifier が policy に基づいて evidence を承認した状態です. **選択肢:** - A (correct): application は no-attestation を attestation success と混同してはいけません. - B (incorrect): RFC 9261 は empty authenticator を許しています. - C (incorrect): authenticated refusal は protocol の一部です. **関連キーワード:** - **missing attestation** : policy が必要とする identity evidence がない状態 - **verified attestation** : verifier が evidence を承認した状態 - **RFC violation** : RFC そのものに反する動作