ToppyMicroServices

RFC 7515 クイズ

JWSの保護範囲, serialization, validation境界

🇺🇸🇯🇵
0 / 0

参照仕様

このクイズでは、JWSの検証で何を確認できるか、どのbyteが保護されるか、どの受理判断がapplication側に残るかを扱います。節番号はRFC 7515を指します。

Q1: validな署名は、このrouting判断まで保護しているか？

単一選択 · L3

A2A gatewayが、compact JWSと別のtarget memberを持つenvelopeを受信しました。signed payloadはagent Aを示しますが、外側のmemberはagent Bを示します。JWSの検証は成功し、gatewayは外側のmemberでroutingします。

**解説:** Aが正解です。Sections 5.1と5.2は、encoded protected headerとpayloadからsigning inputを構成します。application側のmemberは、JWSに隣接しているだけでは追加されません。targetがroutingを左右するなら、application profileは発行前にその値をprotected contentへ置き、検証後に確認する必要があります。 Bはsigning inputにないbyteまで保護されると誤認しています。Cは受信内容を記録できるだけで、signerが何に署名したかを遡って変えられません。判断基準は外側のobjectがvalidなJSONかではなく、cryptographic coverageの境界です。

Q2: protected parameterとunprotected parameterが衝突した場合、どう処理するか？

単一選択 · L3

flattened JWS JSON objectのprotected headerにalg: ES256、unprotected headerにalg: HS256があります。libraryはprotected側を優先して処理を続けられます。

**解説:** Cが正解です。Section 5.2 step 4とSection 7.2は、protected headerとunprotected headerのparameter名をdisjointにするよう求めています。同じalgが両方にあるJOSE Headerは、このsignatureについて不正であり、優先順位で補修する規則はありません。 Aは、algを保護する設計自体は妥当でも、禁止された衝突を隠してしまいます。Bは改変しても署名がinvalidにならない値を選ぶため、さらに不適切です。verifierはどちらかを選ばず、このsignatureを失敗させます。

Q3: 署名がvalidなら、未知のcritical extensionを無視できるか？

単一選択 · L3

protected headerにcrit: ["session-bind"]とsession-bind valueがあります。cryptographicな署名検証は成功しましたが、このverifierはextensionを実装していません。

**解説:** Bが正解です。Section 4.1.11は、critに列挙されたextensionを理解し、処理できなければJWSをinvalidとします。意味を処理できない値が改変されていないだけでは十分ではありません。 Aはintegrityと、senderが要求した処理を適用できることを混同しています。Cはprotected header、したがってsigning inputを変更するため、元の署名検証結果を維持できません。critical extensionの仕組みが要求する結果はrejectです。

Q4: profileが許可しないalgorithmでも、数学的に検証できれば十分か？

単一選択 · L3

Agent Card profileはEdDSAだけを許可しています。legacy cardはtrusted keyによるES256を使い、cryptographic libraryは署名をvalidと判定しました。verifier自体は両方のalgorithmを実装しています。

**解説:** Cが正解です。Section 5.2はacceptableなalgorithmをapplication decisionとし、検証に成功してもalgorithmが受理対象でなければ、そのJWSをinvalidとみなすべきだとしています。Section 10.6はsignature内部のalgorithm情報とalg headerの一致も確認するよう求めます。 Aはkey trustとalgorithm policyを混同しています。Bは実装能力と、このprofileで使う権限を混同しています。提示されたprofileがEdDSAだけを受理するため、数学的な検証に成功してもES256はapplicationの受理条件を満たしません。

Q5: headerが指定したJWK SetをTLSで取得できた場合、何まで判断できるか？

単一選択 · L3

untrusted senderがprotected jkuを指定しました。HTTPSとserver identityの検証は成功し、取得したsetには指定されたkidがあり、そのkeyでJWSも検証できました。しかし、そのURLのhostはapplicationがissuerとして設定した相手ではありません。

**解説:** Bが正解です。Section 4.1.2は、HTTPでjkuを取得する場合にintegrity-protectedな通信とTLS server identityの検証を要求します。これで接続先serviceは認証できますが、そのserviceがclaimed signerのkeyを供給する権限をapplicationから与えられたことまでは確認できません。Section 10.3はkey managementにkey originの認証を別途求めています。 Aはtransport要件をapplicationのtrust付与へ拡張しています。Cはkidを過大評価しています。Section 4.1.4のkidはkey選択のhintにすぎません。許可するkey sourceやsender-controlled URLを取得するかはapplication security policyであり、JWS検証だけから得られる保証ではありません。

Q6: 1つの署名がvalidなら、2-signerの受理policyを満たすか？

単一選択 · L3

general JWS JSON objectにissuer、auditor、無関係なserviceの署名があります。applicationはissuerとauditorの両方を要求します。issuerと無関係なserviceの署名だけがvalidでした。

**解説:** Aが正解です。Section 5.2は各signatureにvalidation処理を適用し、どのsignatureが成功すべきかをapplication decisionとしています。少なくとも1つがvalidという条件はRFC上のminimumであり、application policyの上限ではありません。 Bはこの関係を逆にしています。Cは、必要なauditorが署名したかを確認せず成功数だけを数えています。verifierはどのsignatureが成功したかをapplicationへ渡すか保持し、issuerとauditorの両方を求めるruleを適用できなければなりません。

Q7: 意味が同じJSONでdetached JWS payloadを置き換えられるか？

単一選択 · L3

detached JWSは、特定のmember順序と空白を持つUTF-8 JSON byteに対して作られました。receiverは保存済みのcopyをparseし、意味は同じでもbyteが異なるJSONを出力して、検証前にpayloadとして挿入しようとしています。

**解説:** Cが正解です。Appendix Fのdetached-content方式は、recipientがJWSで使われたexactなpayloadを復元できることを前提にします。Sections 5.1と5.2が扱うのはpayloadのencoded octetであり、parseしたJSON objectの意味上の等価性ではありません。 Aが述べるcanonical data-model signatureをRFC 7515は提供しません。Bのobject比較はapplication上の確認には使えても、異なるbyteを元の署名に一致させることはできません。別profileでcanonicalizationを定めることはできますが、signerとverifierの双方がsigned representationへ同じ規則を適用する必要があります。

Q8: JWS検証とA2A authorizationを正しく組み合わせた結論はどれか？

単一選択 · L4

cached Agent Card JWSはagent identifierとendpointへvalidに署名しています。verifierはsigning keyをtrustし、algorithmも許可しています。cardにはsigned audience、expiry、unique identifierがありません。別のgrantはworkflow Xについてvalidです。attackerが同じcardとrequestをworkflow Yでreplayしました。

**解説:** Bが正解です。validな署名で確認できるのは、選択したtrusted keyの下でprotected headerとsigned payloadのintegrityが保たれていることです。別grantのscopeがcardへ移るわけではなく、署名されていないaudience、freshness、replayの意味も新たには生まれません。 Aは独立したevidenceと受理条件を混同しています。CはJWSにない必須claimを作っています。RFC 7515は署名形式を定めますが、普遍的なAgent Card claim setは定めません。Section 10.10はreplay protectionをapplication concernとし、integrity-protectedなunique identifierとprior-use checkを一例として示します。A2A profile側でdecision field、そのprotected placement、card・grant・request・workflowを結び付ける検証を定義する必要があります。