ToppyMicroServices

RFC 5280 Quiz (JA)

Internet X.509 PKI Certificate and CRL Profile

ENJA
0 / 0

参照（URL）

範囲: RFC 5280はcertificateとCRLをprofileし,path・CRL processingを定義します.trust anchorの選択,forwardされたgateway assertionの認証,A2A operationのauthorizationには,追加のprotocolまたはdeployment policyが必要です.

Q1: certification-path validationの成功は何を確立するか

単一選択

A2A verifierが, 設定されたRFC 5280 inputを用いてagent certificateをvalidateします. pathは成功しましたが, 要求されたoperationは一部のagentだけに制限されています.

**解説:** A: path validationはapplication permissionを付与しません. B: RFC 5280 Sections 6.1 and 6.2は,設定済みinputの下でsubjectとpublic keyのbindingをvalidateし,pathのminimum conditionを定義します.trust anchorの選択はpolicy事項であり,applicationはpurposeやauthorizationへ追加constraintを課せます. C: certificate pathはvalidation inputの下でpublic keyとsubjectを結び付けます. request固有のproof of possessionには利用protocolが必要です. D: revocation processingは, 取得できた適用可能なstatus情報に依存します. path成功だけで常に最新のstatusを保証しません.

Q2: certificate extensionをどう処理すべきか

単一選択

agent certificateに, 認識できないcritical extensionと, 認識できないnon-critical extensionが一つずつあります. path内のsignatureはすべてverifyできます.

**解説:** A: validなsignatureはextension processingを不要にしません. B: RFC 5280 Section 4.2とは逆です. 認識できないcritical extensionがあればcertificateを使用できません. C: Section 4.2は, 認識できないcritical extensionについてrejectを求め, 認識できないnon-critical extensionはignoreを許します. 認識したextensionは定義に従って処理します. D: verifier自身の正しいprocessingが必要であり, 別implementationの報告では代替できません.

Q3: このconstraint付きcertification pathをacceptできるか

単一選択

trusted rootが,agents.example配下のdNSNameだけを許すname constraintsを持つintermediate CAを発行しました.このintermediateはsubjectAltName dNSNameがbilling.other.exampleのleafを発行しています.signature,validity period,CA basic constraintsはその他の点で有効です.

**解説:** A: intermediateのname constraintsはcertifyできるnamespaceを意図的に制限します. B: name constraintsはpath-validation inputであり, 表示用hintではありません. C: local authorizationはconstraintに失敗するcertification pathを修復できません. D: RFC 5280 Section 4.2.1.10はpermitted subtreeを定義し, Section 6.1がpath validationでname constraintsを適用します. validなpathを得た後にapplicationのrole mappingを評価します.

Q4: このcertificateをA2A client authenticationへ使えるか

単一選択

leaf certificateのKey UsageはdigitalSignature, Extended Key UsageはserverAuthだけです. A2A profileは, identityをagent roleへmapする前に, TLS client authenticationへ適合するcertificateを求めています.

**解説:** A: RFC 5280 Sections 4.2.1.3 and 4.2.1.12は, 両方がある場合にKey UsageとExtended Key Usageを独立に処理し, intended purposeが双方に一致するよう求めます. B: digitalSignatureはkey operationを制約しますが, より狭いExtended Key Usageを取り消しません. C: authorization mappingでcertificateのpermitted purposeを拡張できません. D: 二つのextensionは併せて評価するためのものです. 共存自体はerrorではありません.

Q5: revocation情報を取得できない状態をどう表すべきか

単一選択

verifierはその他の点でvalidなpathを構築できますが, A2A deployment policyが必要とする適用可能でcurrentなCRLを取得できません. 現在のimplementationはcertificateをnot revokedと記録して続行します.

**解説:** A: evidenceがないことはpositiveなrevocation-status evidenceではありません. B: retrieval failureはrevocationも証明しません. C: RFC 5280 Section 6.3は,利用できるCRLからstatusを決定できなければUNDETERMINEDを返します.RFCはその結果をoperationally受理できるかを定めません.reject,retry,別のapproved sourceの利用はprofileまたはdeploymentが決めます. D: deploymentが明示したrevocation要件を黙って捨てています.

Q6: RFC 5280の結果とdownstream責務を分けるarchitectureはどれか

単一選択

gatewayがmutual TLSを終端し, client certificate pathをvalidateして, subject-name headerをbackendへforwardします. resourceを所有するbackendはTLS handshakeや元certificateを確認できず, headerを最終authorizationへ使います.

**解説:** A: RFC 5280 path validationは通常のforward headerをauthenticateせず, downstream requestへbindせず, resource authorizationも決めません. B: Sections 6.1 and 6.2はgatewayのcertificate-path resultを支えます. protected assertion, gateway trust, request context, 最終authorizationは別のprotocolおよびdeployment責務です. C: subject stringはcertificateでもcertification pathでもなく, 必要なvalidationを再現できません. D: RFC 5280はcertificateとCRLのprocessingを規定しますが, network architectureはmandateしません.