ToppyMicroServices

RFC 9052 Quiz (JA)

COSE Structures and Process

ENJA
0 / 0

参照（URL）

Q1: COSE headerについて正しい説明はどれか

Multiple Choice

A2A profileはCOSE_Sign1を使い,どのheader valueがsignatureで保護されるかを把握する必要があります.

**Explanation:** A: Section 3はprotected/unprotected bucketを分け,array内の隣接はunprotected mapをauthenticateしません. B: Section 4.4のSig_structureはpayload,external dataに加えてprotected attributesを含みます. C: 正解です.Sections 3 and 4.4がprotection boundaryを定義し,profileはunprotected valueだけからauthenticated semanticsを推論してはいけません. D: Section 3は両bucketにlabelがある場合protected valueを使うとします.ただしapplicationは重複自体を検出すべきです.

Q2: verifierはunprotected kidから何を推論できるか

Multiple Choice

COSE_Sign1 objectはkid=h'17'を含みます.三つのconfigured keyが同じkidを共有しますが,このA2A issuerにauthorizeされるのは一つだけです.

**Explanation:** A: Section 3.1はkidをnon-unique key-selection hintとします.Section 4.4はverified keyとauthorized signing identityの対応をapplicationに別途確認させます. B: Section 3.1はapplicationがkid valueをuniqueと仮定してはならないと明記します. C: Section 3.1はkid自体をsecurity criticalとせず,unprotected bucketへ置くことを認めます. D: Matching identifierはsignature verificationでもissuer-to-key trust decisionでもありません.

Q3: profileのalgorithm placementは受理可能か

Multiple Choice

COSE_Sign1 profileはalgをunprotected bucketだけに置きます.verifierはその値からverification algorithmを選びます.requirementはintermediaryがmessageの残りを維持したままalgorithm selectionを変更することの防止です.

**Explanation:** A: Registryはsemantics/code pointを割り当てますが,message内のparameter instanceをprotectしません. B: 一つのparameterのprotectionは別unprotected parameterへ拡張されません. C: Algorithm trialはdifferent/ambiguous processing ruleを作り,指定authenticated-selection criterionを満たしません. D: Section 3.1は可能な場合algをauthenticateするよう要求し,protected headerまたはexternal dataをmechanismとして示します.Algorithm acceptanceはprofile policyです.

Q4: verifierはこのcrit valueをどう処理すべきか

Multiple Choice

COSE_Sign1 objectはprotected headerにcrit=[1001]を置きますが,parameter 1001はunprotected bucketだけにあります.A2A profileは1001を理解した場合authorization semanticsが変わると定義します.

**Explanation:** A: critはunderstand必須のprotected parameterを列挙し,同labelのunprotected valueをauthenticateしません. B: Section 3.1はこのconditionを明示的にfatal errorとします. C: Validなprotected crit listをignoreするとsenderのcritical-processing requirementを無効にします. D: Protected header変更はSig_structureを変え,received signatureを事後修復できません.

Q5: なぜこのdetached-payload verificationは失敗しなければならないか

Multiple Choice

signerはdetached payloadと,ASCII bytesのPOST /tasksをexternal_aadにしたCOSE_Sign1を作ります.verifierは同じpayload bytesを使いますがexternal_aadはemptyです.profileはHTTP method/pathをsignatureへbindするよう要求します.

**Explanation:** A: Sections 4.3 and 4.4は両sideに同じexternal data byte stringを作らせ,Sig_structureはfull payloadの前にそれを含みます. B: Section 4.4はexternal_aadをSig_structureに明示的に含めます. C: Detached transportが変えるのはpayloadの運搬場所で,signing inputに含むpayload/contextではありません. D: COSEはapplication-supplied bytesを使います.複数HTTP spellingをequivalentにするならA2A profileがnormalizationを定義します.

Q6: backend policyが要求するevidenceを与える設計はどれか

Multiple Choice

A2A gatewayはCOSE_Sign1 requestをverifyし,そのkeyがissuer Iにauthorizeされることを確認します.decoded subとroleをordinary HTTP headerで転送します.backendはresourceを所有し,authenticated issuer,role,payload digest,operation contextを要求します.COSE objectもprotected gateway evidenceも受け取りません.

**Explanation:** A: Sections 3 and 4.4はoriginal bytesのauthenticated範囲を定義し,decoded ordinary headerはそのprotectionを継承しません. B: Section 3.1のkidはnon-unique lookup hintで,backend-required evidenceのcontainerではありません. C: Section 4.4がCOSE verificationを定義し,applicationにkey,identity,authorization checkを要求します.downstream assertionは別のA2A trust-boundary designであり,そのsemanticsをprotectする必要があります. D: Gateway TLSはimmediate connectionをauthenticateしますが,original COSE evidenceからdownstream fieldへの未定義mappingはauthenticateしません.