RFC 5280 Quiz (EN)

Q1: What does successful certification-path validation establish?

Multiple Choice

An A2A verifier validates an agent certificate against its configured RFC 5280 inputs. The path succeeds, but the requested operation is restricted to a subset of agents.

A. The certificate holder is authorized for every operation accepted by the same trust anchor B. The subject/public-key binding satisfies the configured path inputs; operation authorization remains application policy C. The peer proved possession of the private key for the exact A2A request under review D. Revocation status is necessarily current for every certificate in the path

**Explanation:** A: Path validation does not assign application permissions. B: RFC 5280 Sections 6.1 and 6.2 validate the subject/public-key binding under configured inputs and define minimum path conditions. Trust-anchor selection is a policy matter, and an application may impose additional purpose and authorization constraints. C: A certificate path binds a public key to a subject under the validation inputs; request-specific proof of possession requires the consuming protocol. D: Revocation processing depends on available and applicable status information; path success alone does not promise universally fresh status.

Q2: How should an implementation handle certificate extensions?

Multiple Choice

An agent certificate contains one unrecognized critical extension and one unrecognized non-critical extension. All signatures in the path verify.

A. Ignore both extensions because signature verification succeeded B. Ignore the critical extension if local policy does not use it, but reject the non-critical extension C. Reject because the critical extension is unrecognized; an unrecognized non-critical extension may be ignored D. Accept if another implementation reports that it recognizes the critical extension

**Explanation:** A: A valid signature does not override extension processing. B: This reverses RFC 5280 Section 4.2: an unrecognized critical extension prevents certificate use. C: Section 4.2 requires rejection for an unrecognized critical extension and permits an unrecognized non-critical extension to be ignored. A recognized extension must be processed according to its definition. D: Validation depends on the verifier's own correct processing, not another implementation's report.

Q3: Should this constrained certification path be accepted?

Multiple Choice

A trusted root issued an intermediate CA whose name constraints permit only dNSName values under agents.example. That intermediate issued a leaf with subjectAltName dNSName billing.other.example. The signatures, validity periods, and CA basic constraints are otherwise valid.

A. Accept, because a trust anchor may delegate names without limiting the intermediate's issuance scope B. Accept, because name constraints affect only name display after signature validation C. Accept if local authorization maps billing.other.example to the same agent role D. Reject the path because the leaf name is outside the permitted subtree, before applying any A2A role authorization

**Explanation:** A: The intermediate's name constraints deliberately limit the namespace it may certify. B: Name constraints are path-validation inputs, not presentation hints. C: Local authorization cannot repair a certification path that fails its constraints. D: RFC 5280 Section 4.2.1.10 defines permitted subtrees, and Section 6.1 applies name constraints during path validation. Only after a valid path exists should the application evaluate its role mapping.

Q4: Can this certificate be used for A2A client authentication?

Multiple Choice

A leaf certificate has Key Usage digitalSignature and Extended Key Usage serverAuth only. The A2A profile requires a certificate acceptable for TLS client authentication before mapping the identity to an agent role.

A. No; purpose must satisfy both extensions, and serverAuth does not permit client authentication B. Yes; digitalSignature alone authorizes every protocol use involving a signature C. Yes, if the local role mapping grants an A2A client role to the subject name D. No, because any certificate with more than one usage-related extension is ambiguous

**Explanation:** A: RFC 5280 Sections 4.2.1.3 and 4.2.1.12 require Key Usage and Extended Key Usage to be processed independently when both are present; the intended purpose must be consistent with both. B: digitalSignature constrains key operations but does not cancel a narrower Extended Key Usage. C: Authorization mapping cannot expand a certificate's permitted purpose. D: The two extensions are designed to be evaluated together; their coexistence is not itself an error.

Q5: How should unavailable revocation information be represented?

Multiple Choice

A verifier can build an otherwise valid path, but it cannot obtain an applicable current CRL required by its A2A deployment policy. The implementation currently records the certificate as not revoked and continues.

A. Record not revoked because no signed CRL states that the certificate was revoked B. Record revoked because inability to obtain a CRL is cryptographic evidence of revocation C. Preserve UNDETERMINED status; deployment policy chooses rejection, retry, or another approved source D. Ignore revocation whenever signatures and validity times pass

**Explanation:** A: Absence of evidence is not positive revocation-status evidence. B: Retrieval failure does not prove revocation either. C: RFC 5280 Section 6.3 returns UNDETERMINED when the available CRLs cannot determine status. The RFC does not define whether that result is operationally acceptable; rejection, retry, or another approved source belongs to the profile or deployment. D: This silently discards the deployment's stated revocation requirement.

Q6: Which architecture keeps the RFC 5280 result distinct from downstream responsibilities?

Multiple Choice

A gateway terminates mutual TLS, validates the client certificate path, and forwards a subject-name header to a backend. The backend owns the resource and cannot inspect the TLS handshake or original certificate. It uses the header for final authorization.

A. The bare subject header is sufficient because a valid path proves possession and authorization on every downstream hop B. Trust the gateway through a protected assertion carrying validated identity and request context; the backend still authorizes the resource C. The backend should repeat only signature-chain verification on the subject text, because names contain enough information to reconstruct the path D. RFC 5280 prohibits delegation, so the backend must always terminate the original client TLS connection

**Explanation:** A: RFC 5280 path validation does not authenticate an ordinary forwarded header, bind it to the downstream request, or decide resource authorization. B: Sections 6.1 and 6.2 support the gateway's certificate-path result. The protected assertion, gateway trust, request context, and final authorization are separate protocol and deployment responsibilities. C: A subject string is neither the certificate nor a certification path and cannot reproduce the required validation. D: RFC 5280 specifies certificate and CRL processing; it does not mandate a network architecture.

Internet X.509 PKI Certificate and CRL Profile

References (URLs)

Q1: What does successful certification-path validation establish?

Q2: How should an implementation handle certificate extensions?

Q3: Should this constrained certification path be accepted?

Q4: Can this certificate be used for A2A client authentication?

Q5: How should unavailable revocation information be represented?

Q6: Which architecture keeps the RFC 5280 result distinct from downstream responsibilities?