Q1: Signature-Inputは何を記述する？
単一選択**解説:**
A: Signature-Inputはsignature baseの構築に使うcomponent identifierとmetadataを運ぶ。
B: Signature fieldがcryptographic byte sequenceを運ぶ。
C: message contentそのものはSignature-Inputへcopyされない。
参照仕様
Q2: Signatureにlabel sig1があるが、Signature-Inputにsig1がない。どう扱う？
単一選択**解説:**
A: 推測では、signerが定義したsignature baseを安全に再現できない。
B: 各message signatureのlabelは、両方のfieldに存在する必要がある。
C: body digestは、欠けているsignature metadataの代わりにはならない。
Q3: HTTP message signatureはrequest bodyを自動的に対象にする？
単一選択**解説:**
A: RFC 9421はraw message全体ではなく、選択したcomponentから構築したbaseを署名する。
B: @methodと@target-uriはrequest metadataを対象にするが、contentは対象にしない。
C: Content-Digestを署名対象にしてdigest fieldをbindし、そのdigestを検証してbodyへ結び付ける。
Q4: request profileが@methodと@target-uriを対象にする理由はどれ？
単一選択**解説:**
A: これらのderived componentにより、methodやdestinationを変えた後のreuseを防ぐ。
B: signatureはintegrityとauthenticityを与えるが、confidentialityは与えない。
C: HTTPのcovered componentはTLS algorithmをnegotiateしない。
Q5: created、expires、nonce signature parameterのroleはどれ？
単一選択**解説:**
A: metadataだけではclock synchronizationを確立できない。
B: applicationが許容windowとnonceのuniquenessを定義し、適用する必要がある。
C: これらのparameterはscope grantではなく、signatureのtimingとuniquenessに関する。
Q6: signatureの暗号検証は成功したが、必須のAuthorizationが署名対象にない。どうする？
単一選択**解説:**
A: RFC 9421では、applicationが追加のcoverage requirementを適用する。
B: Signature-Inputを変えるとsignature baseも変わり、signatureは無効になる。
C: 含まれるcomponentの検証に成功しても、必須componentを欠くsignatureはprofileを満たさない。
Q7: keyidだけで確認できることはどれ？
単一選択**解説:**
A: verifierには、信頼できるkey resolutionとauthorization ruleが別途必要である。
B: authorizationはkey identificationだけでは決まらず、application policyに属する。
C: algorithmを許容できるかは別途解決し、検査する必要がある。
Q8: 一つのHTTP messageに複数のsignatureを含められる？
単一選択**解説:**
A: RFC 9421は、複数のlabeled valueを運べるdictionaryを定義する。
B: 対応する固有のlabelで、各Signature valueをSignature-Inputへ関連付ける。
C: 複数のsignatureは、それぞれ異なるsigner、key、algorithm、coverageを使える。
Q9: defensibleなsignature contextを持つ修正はどれ？
単一選択clientはhttps://api.example/payについて@method、@target-uri、content-digestを署名する。gatewayはrequestをhttp://payments.internal/v2/payへ書き換える。backendがinternal requestから@target-uriを再構築すると検証に失敗する。gatewayは未署名のX-Original-URIも追加する。
**解説:**
RFC 9421 Section 7.4.3は、verifierが正しいsignature contextからcomponent valueを得ることを求め、Appendix B.3はTLS-terminating proxyの考慮点を例示する。Cはpublic targetのsourceとtrustを明示する。Aではattackerが検証用valueを選べ、Bは宣言したcoverage保証を捨てる。Dのような同値性は
@target-uriの導出規則にはない。Q10: backendはこのarchitectureで何を主張し、何に依存できる？
単一選択clientはmethod、target URI、Authorization field、Content-Digest、creation time、nonceを署名する。gatewayはsignatureを検証してnonceを消費し、requestを変換した後、別TLS connection上で未署名のX-Verified-Signerをbackendへ送る。backendはclientのsignature baseを再構築できない。
**解説:**
RFC 9421 Sections 1.4と3.2.1は、application profileとverifierがcoverage、key、algorithm、freshnessなどの受理要件を定義・適用することを求める。request変換後のbackendはclientのtarget messageを自ら検証していない。Cは、gateway identity、assertion integrity、request binding、authorization上の意味を定義して保護する場合に限り成立するlocal trust designである。ただし、これはgatewayへの依存であり、backendによるend-to-end検証とは表現できない。RFC 9421はこのarchitectureを一律禁止しないためDは強すぎる。