RFC 7517 Quiz (JA)

JSON Web Key (JWK)

0 / 0

参考URL

Q1: RFC 7517の中心的な役割として最も適切なのはどれですか

単一選択
**Judgment point:** JWKはkey materialとkey metadataを運びます. ただし, そのkeyを信頼するかは取得元とpolicyで別に決まります. **Related keywords:** - **JWK** : 暗号鍵をJSON objectで表す形式 - **JWKS** : 複数のkeyを公開するJSON set - **kid** : keyを探すためのhintでありtrustそのものではない **Options:** - A: authorization policyはOAuthやapplication ruleやlocal trust policyの仕事であり, JWK formatだけでは決まりません. - B: JWKはJOSE系protocolで使うkeyのJSON表現です. このRFCの中心として適切です. - C: kidはcandidate keyを探すhintです. trust decisionでもglobal uniqueな証明でもありません.

Q2: serviceがJWKSを読むとき明示しておくべきreview項目はどれですか. すべて選んでください

複数選択
**Judgment point:** JWKSは便利ですが, どこから来たか, 誰が管理しているか, どの用途で許すかをdeploymentが決める必要があります. **Related keywords:** - **JWK** : 暗号鍵をJSON objectで表す形式 - **JWKS** : 複数のkeyを公開するJSON set - **kid** : keyを探すためのhintでありtrustそのものではない **Options:** - A: JSON key setだけでは誰がsignしてよいかを証明しないため, sourceとissuerのcheckが必要です. - B: 全keyをblind trustすると, wrong issuerやwrong use caseを通してしまう可能性があります. - C: public JWKSにsecret materialを置くと, verifier aidではなくsecret leakになります. - D: alg memberはconstraintやhintになり得ますが, verifier側のallow-listとprofile ruleが必要です.

Q3: JWKのktyがRSAやECのとき, 主に何を決めますか

単一選択
**Judgment point:** ktyはkey typeを選びます. 実装はその値を見て, 暗号処理前に読むべきkey-specific memberを決めます. **Related keywords:** - **JWK** : 暗号鍵をJSON objectで表す形式 - **JWKS** : 複数のkeyを公開するJSON set - **kid** : keyを探すためのhintでありtrustそのものではない **Options:** - A: user identityはcertificate, claim, deployment policyなどで扱うことが多く, ktyでは決まりません. - B: OAuth scopeはtoken policyであり, key type fieldの役割ではありません. - C: ktyはkey familyを選ぶため, RSA modulus/exponentやEC curve coordinateなどの必要memberを決めます.

Q4: JWT headerのkidと一致するkeyが見つかったとき, 最も安全な解釈はどれですか

単一選択
**Judgment point:** key selectionとkey trustは別のstepです. key identifierでcandidateを絞ったあと, policyとcryptographic checkでacceptanceを決めます. **Related keywords:** - **JWK** : 暗号鍵をJSON objectで表す形式 - **JWKS** : 複数のkeyを公開するJSON set - **kid** : keyを探すためのhintでありtrustそのものではない **Options:** - A: kidをlookup hintに留め, その後のvalidation stepを残しているため安全です. - B: issuer validationを上書きすると, convenience identifierをauthorization mechanismにしてしまいます. - C: RFCはkidをglobal uniqueにしていないため, issuerをまたぐcollisionやreuseを考える必要があります.

Q5: signed tokenをJWKSで検証する流れとして最も適切なのはどれですか

単一選択
JWKSによるtoken検証の流れ.
設定済み JWKS source candidate key selection signature verification claim/policy decision
**Judgment point:** 安全なverifierはkey setだけでacceptanceを決めません. trusted discovery, candidate selection, cryptographic validation, application policyを組み合わせます. **Related keywords:** - **JWK** : 暗号鍵をJSON objectで表す形式 - **JWKS** : 複数のkeyを公開するJSON set - **kid** : keyを探すためのhintでありtrustそのものではない **Options:** - A: 最初のkeyは任意であり, algorithmを広く試すとalgorithm confusionのriskが出ます. - B: discovery, selection, signature verification, policy checkを分けており, JWKSの安全な使い方です. - C: well formedなkey materialは, right issuerやkey ownerを証明しません.

Q6: use, key_ops, algについて慎重な説明はどれですか. すべて選んでください

複数選択
**Judgment point:** key metadataはmisuseを減らします. ただし各memberをどの強さで扱うかはprofileやverifier policyが定義します. **Related keywords:** - **JWK** : 暗号鍵をJSON objectで表す形式 - **JWKS** : 複数のkeyを公開するJSON set - **kid** : keyを探すためのhintでありtrustそのものではない **Options:** - A: key metadataはresource authorization grantではなく, policyを置き換えません. - B: profileはuse, key_ops, algをmandatory constraintにするかadvisory fieldにするかを明確にするべきです. - C: local algorithm policyは, attacker-controlledまたはissuer-provided headerでbypassしてはいけません. - D: 矛盾した値にはdeterministicなhandling ruleが必要です. そうしないと実装ごとにacceptanceが分かれます.

Q7: JWK形式のprivate key materialやsymmetric key materialについて最も安全な扱いはどれですか

単一選択
**Judgment point:** JWKはpublic, private, symmetric materialを表せます. JSON formatであることは中身のsensitivityを下げません. **Related keywords:** - **JWK** : 暗号鍵をJSON objectで表す形式 - **JWKS** : 複数のkeyを公開するJSON set - **kid** : keyを探すためのhintでありtrustそのものではない **Options:** - A: secret key memberをpublic JWKSに置くと, impersonationやdecryptionに必要なmaterialが漏れます. - B: JSONはencodingにすぎず, secret materialを安全にはしません. - C: secret materialはJWK encodingでもsecretです. 適切に保護する必要があります.

Q8: JWKにx5c certificate dataが含まれる場合, verifierが避けるべきでない慎重な扱いはどれですか

単一選択
**Judgment point:** certificate関連memberはkeyとcertificate materialを結び付けます. ただしcertificate pathとintended useは別に検証します. **Related keywords:** - **JWK** : 暗号鍵をJSON objectで表す形式 - **JWKS** : 複数のkeyを公開するJSON set - **kid** : keyを探すためのhintでありtrustそのものではない **Options:** - A: x5cをshortcutではなくvalidation inputとして扱っており, 慎重なpathです. - B: automatic trustにするとpath validation, name constraint, usage policyを省略してしまいます. - C: certificateのpublic keyとJWKの対応確認は必要なconsistency checkです. 避けるべきものではありません.

Q9: JWKSのkey rotationとして安全なpracticeはどれですか. すべて選んでください

複数選択
**Judgment point:** key rotationは通常運用です. ただしunknown keyやambiguous identifierをacceptする動作にしてはいけません. **Related keywords:** - **JWK** : 暗号鍵をJSON objectで表す形式 - **JWKS** : 複数のkeyを公開するJSON set - **kid** : keyを探すためのhintでありtrustそのものではない **Options:** - A: overlap windowがあると, 既存tokenを検証しながら新しいkeyへ移行できます. - B: unrelated keyでkidを再利用するとselectionが曖昧になり, wrong materialを選ぶ原因になります. - C: backup algorithm fallbackはrotationをalgorithm confusionやkey confusion bugに変えます. - D: trustworthy candidate keyがないときfail closedすることでsecurityを保ちます.

Q10: verifierがtoken用のacceptable JWKを見つけられない場合, どう扱うべきですか

単一選択
**Judgment point:** acceptable keyがないことは現在のvalidation pathではfailureです. protectionを検証するまでclaimは信頼できません. **Related keywords:** - **JWK** : 暗号鍵をJSON objectで表す形式 - **JWKS** : 複数のkeyを公開するJSON set - **kid** : keyを探すためのhintでありtrustそのものではない **Options:** - A: JWKS endpointのreachabilityはvalid signatureやtrusted issuerと同じではありません. - B: rejectすればfail-closed behaviorを保てます. alternate pathは明示的に定義された場合だけ使えます. - C: signatureとpolicy checkが通るまでpayload claimはattacker-controlledとして扱います.