ToppyMicroServices

RFC 7517 Quiz (JA)

JSON Web Key (JWK)

ENJA
0 / 0

一次資料

keyの表現・選択と、keyの由来、署名検証、application authorizationを分けて判断する問題です。節番号はRFC 7517を指します。

Q1: JSON Web Keyは何を表現するか？

Multiple Choice
RFC 7517 Sections 2と4は、JWKを暗号keyとその属性を表すJSON objectと定義します。この形式はOAuth authorizationを定義せず、`kid`をglobal identityやtrust proofにするものでもありません。JWKは`x5c`などのcertificate関連memberを持てますが、JWKの定義自体がX.509 certification pathや、その検証の代替になるわけではありません。key表現を読み取った後、由来、trust、authorizationを別々に評価します。

Q2: JWKとJWK Setのparse規則に従う記述はどれか.該当するものをすべて選べ.

Multi-Select
RFC 7517 Section 4.1は`kty`を必須かつcase-sensitiveとし,Section 4は理解できない追加memberを無視するよう求めます.Section 4.5の`kid`はoptionalでglobal uniquenessを持たず,Section 5.1もJWK Setのarray順序へ既定の優先順位を与えません.parserは明示されたmember規則に従い,identityや順序の意味を追加してはいけません.

Q3: 1つのJWKにuseとkey_opsの両方がある場合,profileはどう扱うべきか？

Multiple Choice
RFC 7517 Section 4.3は`use`と`key_ops`の併用を避けるべきとし,両方がある場合は内容の一致を要求します.一方へ自動的な優先順位を与えておらず,message headerも矛盾したkey metadataを修復しません.profileは一方の表現を選べますが,衝突する制約をpermissionへ変えてはいけません.

Q4: JWT headerのkidが設定済みJWK Set内のkeyと一致した.この一致で何が確定したか？

Multiple Choice
RFC 7517 Section 4.5は`kid`をrollover時にも使えるmatching aidとし,構造は未規定,set内で異なる値を使うことだけを推奨します.一致によってcandidate keyは選べますが,issuer認証,algorithm許可,signature検証はまだ終わっていません.`kid`は該当するtrust context内のselectorであり,受理結果ではありません.

Q5: public JWKSへoct JWKのk memberを誤って掲載した.適切な対応はどれか？

Multiple Choice
`oct` JWKの`k`にはsymmetric key materialが入るため,公開すればpublic keyの説明ではなくsecretそのものを各取得者へ渡します.RFC 7517 Section 9と9.2はsymmetric keyとprivate materialを漏えいから保護するよう求めます.TLSは各requesterまでの通信を守るだけであり,`kid`の変更も既に露出したkey byteを秘密へ戻しません.

Q6: x5c memberについて正しい記述はどれか.該当するものをすべて選べ.

Multi-Select
RFC 7517 Section 4.7は`x5c` certificateをbase64でencodeし,表現するkeyを含むcertificateを先頭へ置き,そのkeyとほかのJWK memberの一致を要求します.同じSectionはoptionalな`use`と`alg`もcertificateとの整合を要求します.`x5c`があっても,Section 9.1のprovenance,chain validation,application trustの評価は残ります.

Q7: kidをauthorization機構に変えず,検証可能性を保つrollover planはどれか？

Multiple Choice

A2A issuerは正午にsigning keyを変更する.旧keyで署名したtokenは1時間有効だが,公開JWK Setから旧keyを直ちに削除する予定である.

RFC 7517 Sections 4.5と5.1は、rollover中にset memberを選ぶ方法を提供しますが、`kid`は関連するtrust context内のselectorにとどまります。旧tokenを1時間受理するとapplicationが約束するなら、必要なtoken lifetimeとcacheの重複期間に旧verification keyを利用可能にしておくことは、そのpolicyから生じる運用上の判断であり、RFC 7517が一律に定める有効期間ではありません。別issuerのkeyを受け入れること、identifierを曖昧に再利用すること、署名検証を省略することでは、元のtrust boundaryを保てません。

Q8: このx5c付きJWKをverifierはどう扱うべきか？

Multiple Choice

JWKにRSAのnとe,およびx5c chainがある.先頭certificateは設定済みtrust anchorまで正しく検証できるが,そのsubject public keyはnとeから構成されるRSA keyと異なる.

RFC 7517 Section 4.7は,先頭`x5c` certificateのpublic keyとほかのJWK memberが表すkeyの一致を要求します.validなcertificate pathでも矛盾したkey表現は許されず,明示parameterもconsistency ruleを上書きしません.両方を試してsignatureが通る解釈を選べば,attacker-controlled dataに有効なkeyを選ばせるため,このJWKはrejectします.

Q9: このshared-kid設計について正当なreview findingはどれか.2つ選べ.

Multi-Select

verifierは無関係な2つのissuerのJWK Setを1つのcacheへ統合する.双方にkid=rotate-7があり,verifierは最初の一致keyを選び,signatureだけを確認する.

RFC 7517 Section 4.5は`kid`をglobal uniqueにしないため、2つのissuerを統合してその値だけで選ぶcacheはlookupを曖昧にします。Section 5.1はJWK Setの順序に既定の優先順位を与えないので、cache orderもtrust ruleにはなりません。Section 9.1のtrustに関する指針に従い、key selectionをissuerと由来で限定したうえで、algorithm、claim、resource authorizationのpolicyを別々に適用します。

Q10: このA2A経路の保証を正しく合成した評価はどれか？

Multiple Choice

Agent CardがJWKS URLを示す.gatewayはauthenticated TLSでsetを取得し,agent JWTを検証してX-Agent-Idをbackendへ転送する.resource policyを持つbackendは,JWTもgatewayの検証結果を保護したattestationも受け取らない.

RFC 7517 Section 9.1は、keyの取得方法と、その関連を主張するentityへのtrustにconfidenceを結び付けますが、keyへすべてのidentityやresource roleを与えるものではありません。TLSはJWKS取得先を認証しても、Agent Card referenceや`kid`と同様、後続hopで新しく作ったheaderを保護しません。RFC 7517はgateway-to-backend mechanismを指定していません。ただし提示された設計でbackendがgatewayのclaimへ依存するには、そのtrust boundaryでassertionを保護し、backendが明示的なlocal authorization ruleを適用する必要があります。