RFC 9421 Quiz

Q1: What does Signature-Input describe?

Multiple Choice

A. The ordered covered components and signature parameters B. Only the binary signature value C. A complete copy of the HTTP body

**Explanation:** A: Signature-Input carries the component identifiers and metadata used to build the signature base. B: The Signature field carries the cryptographic byte sequence. C: Message content is not copied into Signature-Input.

Q2: If Signature contains label sig1 but Signature-Input has no sig1, how should the message be handled?

Multiple Choice

A. Guess the covered components from common headers B. Treat the unmatched label as an error C. Verify only the body hash

**Explanation:** A: Guessing cannot reproduce the signer's defined signature base safely. B: Each message signature label must occur in both fields. C: A body digest is not a substitute for the missing signature metadata.

Q3: Does an HTTP message signature automatically cover the request body?

Multiple Choice

A. Yes, every signature implicitly includes all message bytes B. Yes, when @method is covered C. No, the profile must include a content digest or another defined content component

**Explanation:** A: RFC 9421 signs a constructed base of selected components rather than the raw whole message. B: @method covers the method only and says nothing about content. C: Signing Content-Digest binds the digest field, with digest validation linking it to the body.

Q4: Why might a request profile cover @method and @target-uri?

Multiple Choice

A. To bind the signature to the intended operation and target B. To encrypt the URI from intermediaries C. To select the TLS cipher suite

**Explanation:** A: These derived components prevent reuse after changing method or destination. B: A signature provides integrity and authenticity properties but not confidentiality. C: HTTP covered components do not negotiate TLS algorithms.

Q5: What is the role of the created, expires, and nonce signature parameters?

Multiple Choice

A. They automatically synchronize all server clocks B. They provide signed inputs for age, expiration, and replay checks C. They identify the signer's authorization scope

**Explanation:** A: Metadata cannot establish clock synchronization. B: The application defines acceptable windows and nonce uniqueness and must enforce them. C: These parameters concern signature timing and uniqueness rather than scope grants.

Q6: A signature verifies cryptographically but omits Authorization, which the application requires to be covered. What should happen?

Multiple Choice

A. Accept because cryptographic verification is the only required step B. Add Authorization to Signature-Input after receipt C. Fail application-level signature verification

**Explanation:** A: RFC 9421 expects applications to enforce their additional coverage requirements. B: Changing Signature-Input changes the signature base and invalidates the signature. C: A signature that omits a required component does not satisfy the profile even if its included components verify.

Q7: What does keyid establish by itself?

Multiple Choice

A. Only an identifier used to locate or select key material B. That the key owner may perform the requested action C. That the named key uses an acceptable algorithm

**Explanation:** A: The verifier still needs trusted resolution and authorization rules for the key. B: Authorization is application policy beyond key identification. C: Algorithm acceptability must be resolved and checked separately.

Q8: Can one HTTP message contain multiple signatures?

Multiple Choice

A. No, later signatures overwrite the first B. Yes, each distinct signature uses a unique label in both fields C. Yes, but all signatures must use the same key and components

**Explanation:** A: RFC 9421 defines dictionaries that can carry multiple labeled values. B: Matching unique labels associate each Signature value with its Signature-Input. C: Multiple signatures may use different signers, keys, algorithms, or coverage.

Q9: An intermediary changes a covered component in transit. What is the expected result?

Multiple Choice

A. The signature automatically adapts to the new value B. The change is ignored because intermediaries may modify HTTP C. Verification fails unless a valid new signature covers the transformed message

**Explanation:** A: Only the signer with the key can create a signature over the altered base. B: Permitted HTTP transformation still breaks a signature if the transformed component is covered. C: The covered value no longer matches the original signature base.

Q10: What must an A2A HTTP-signature profile specify beyond using RFC 9421?

Multiple Choice

A. Only the field label spelling and the display order of signature values B. Required components, key trust, algorithms, freshness, replay, and authorization binding C. A rule that every valid signature covers the entire HTTP exchange

**Explanation:** A: A label does not define security coverage, trust, or replay policy. B: These rules determine what a valid signature actually means for an A2A request. C: Coverage remains the explicit selected component set, not an implicit entire exchange.

Selected HTTP component integrity and application policy

References

Q1: What does Signature-Input describe?

Q2: If Signature contains label sig1 but Signature-Input has no sig1, how should the message be handled?

Q3: Does an HTTP message signature automatically cover the request body?

Q4: Why might a request profile cover @method and @target-uri?

Q5: What is the role of the created, expires, and nonce signature parameters?

Q6: A signature verifies cryptographically but omits Authorization, which the application requires to be covered. What should happen?

Q7: What does keyid establish by itself?

Q8: Can one HTTP message contain multiple signatures?

Q9: An intermediary changes a covered component in transit. What is the expected result?

Q10: What must an A2A HTTP-signature profile specify beyond using RFC 9421?