ToppyMicroServices

RFC 9530 Quiz (JA)

Digest Fields

ENJA
0 / 0

参照（URL）

Q1: この2個のintegrity goalに合うdigest fieldはどれか

単一選択

agentはgzip-coded partial responseを受け取ります.このresponseで運ばれた正確なbyteと,rangeの元になった完全なselected representationの両方を検証したいとします.

**解説:** A: RFC 9530 Sections 1.2と3はRepr-Digestをselected representation data上で定義し,HTTP message fieldやcarried rangeだけのdigestにはしません. B: Section 4のWant-Content-Digestはpreference hintであり,integrity valueではありません.このcaseのContent-Digestはcomplete selected representationも表しません. C: Sections 2と3はactual message contentとselected representationを分けます.Appendix B.3はpartial responseで異なる値になる例を示します. D: range selectionはtransferred contentを変え,content codingはrepresentation dataへ影響します.2個のvalidation goalは異なるinputを持ちます. 判断軸: fieldを選ぶ前に,transferred content,selected representation,digest外metadataのどれを検証するか正確に書き出します.

Q2: このdigest preferenceが無視された場合の意味は何か

単一選択

A2A clientはsha-256を最優先とするWant-Content-Digestを送ります.serverはContent-Digestを返さず,A2A profileにも追加要件はありません.

**解説:** A: RFC 9530 Section 4はpreference fieldをhintと定義します.weightはrelative preferenceですが,response digest自体を必須にはしません. B: Section 4はreceiverがhintを無視でき,それ自体はprotocol errorでないとします.application-specific constraintは追加要件を定義できます. C: content integrityとrepresentation integrityは別goalです.一方のpreference無視は他方のfieldをnegotiateしません. D: Section 5はdeprecated algorithmを限定的なcorruption用途だけに許し,adversarial useでは禁止します.preferenceはunsafe fallbackを強制しません. 判断軸: 省略時にoperationを失敗させるなら,Want-Content-Digestから推論せず,consuming application profileへ要件を記載します.

Q3: このsigned digestはA2A判断に十分か

単一選択

senderはContent-Digestをsignしますが,Content-TypeとContent-Encodingはsignしません.backendはdigestとsignature検証後,この2個のunsigned fieldからsecurity-sensitive parserを選びます.

**解説:** A: RFC 9530 Section 6.1はdigest fieldがHTTP headerまたはtrailer fieldを保護しないとします.Content-Digestはactual message contentだけを対象にします. B: Active hashは関連hash attackへ耐性を持ち得ますが,signature inputから除外したfieldをbindしません. C: content sniffingは別の曖昧なsecurity ruleへ置換するだけで,RFC 9530が提供する保護ではありません. D: Section 6.3はIntegrity fieldだけをsignし,Content-TypeやContent-Encodingなどのrepresentation metadataを除くtampering surfaceを警告します. 判断軸: digest validationは定義されたbyteだけのintegrityを示します.security-relevantな解釈を制御するmetadataもsignatureでbindします.

Q4: このPATCH exchangeでRepr-Digestは何を対象にするか

単一選択

PATCH requestはpatch documentを運びます.success responseは更新後resourceのcomplete representationを運び,両messageにRepr-Digestがあります.

**解説:** A: RFC 9530 Section 3.1がこの区別を明記します.request metadataはpatch documentを示し,response metadataはpatched resource representationを示せます. B: pre-patch resourceは,記載されたどちらのmessageでもenclosed representationではありません.Repr-Digestは概念上の共通baseではなくrepresentation ruleに従います. C: HTTP methodだけではresponse contentをpatch documentにしません.responseのrepresentation metadataとmethod semanticsがdigest inputを決めます. D: Repr-Digestはstatus codeやLocationをdigestせず,PATCH request digestも自動的にtarget resourceを対象にしません. 判断軸: state-changing methodでは,requestとresponseが同じtargetを指すと仮定せず,digest inputを別々に導出します.

Q5: このbare digestが提供するassuranceは何か

単一選択

A2A webhookがactive intermediaryにcontrolされたchannelで届きます.receiverはsha-256 Content-Digestがbodyと一致することだけでsender identityを受理します.

**解説:** A: unkeyed hashはattackerも計算できます.RFC 9530 Section 6.1はmalicious on-path actorがcontentと新digestを置換できるとします. B: RFC 9530が定義するのはcontentまたはrepresentationのintegrity fieldであり,authorization decisionやidentity credentialではありません. C: Section 6.1がこの限定的assuranceを支えます.authenticationにはTLS endpoint authenticationや適切なcoverageのsignatureなど追加mechanismが必要です. D: Section 6.1はHTTP field全体を保護しないと明示します.request-targetとheader integrityには別coverageが必要です. 判断軸: threat modelとmechanismを対応させます.unkeyed digestはaccidental changeを検出できますが,adversarial channelでsenderを識別できません.

Q6: このtransforming gatewayを越えてintegrityをどうcomposeすべきか

単一選択

agentはgzip-coded taskのContent-Digest,Content-Type,Content-Encodingをsignします.gatewayは検証後にdecompressし,origin evidenceと処理byteの両方を必要とするbackendへplain JSONを転送します.

**解説:** A: RFC 9530 Section 2はContent-Digestをactual message contentへbindします.decompressionはそのbyteを変えるため,original valueはforwarded contentを検証しません. B: Sections 2,3,6.1,6.3はbyte domainとprotection layerの区別を求めます.gateway trustとorigin-verifiable evidenceは明示すべき別architectureです. C: Content-DigestとRepr-Digestはinputが異なり,covered fieldやdigestを変えればsignature schemeが変換を定義しない限りoriginal signatureはinvalidです. D: RFC 9530はintermediary越しのintegrity fieldを許しつつ,transformationとmetadataを警告します.一律除去ruleはありません. 判断軸: transformationは,original evidenceを保存するか,transformed messageへの新しいauthenticated assertionを定義しない限り,以前のbyte-level assertionを終わらせます.