RFC 9421 Quiz

Q1: What does Signature-Input describe?

Multiple Choice

A. 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, because every signature covers all message bytes B. Yes, if the signature covers @method and @target-uri C. No, the profile must explicitly cover a digest or equivalent

**Explanation:** A: RFC 9421 signs a constructed base of selected components rather than the raw whole message. B: @method and @target-uri cover request metadata, not the 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 operation to its intended 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: Which repair has a defensible signature context?

Multiple Choice

A client signs @method, @target-uri, and content-digest for https://api.example/pay. A gateway rewrites the request to http://payments.internal/v2/pay. Backend verification fails because it reconstructs @target-uri from the internal request. The gateway also adds an unsigned X-Original-URI field.

A. Substitute any received X-Original-URI value without authenticating its source B. Drop @target-uri from verification while still claiming the destination is protected C. Define the proxy trust boundary and an authenticated source for the original target context D. Canonicalize the public and internal URIs as equal because they reach the same application

**Explanation:** RFC 9421 Section 7.4.3 requires a verifier to obtain component values from the correct signature context, and Appendix B.3 illustrates TLS-terminating proxy considerations. C makes the source and trust of the public target explicit. A lets an attacker choose the value used for verification, B abandons a stated coverage guarantee, and D invents an equivalence that the @target-uri derivation does not provide.

Q10: What may the backend claim and rely on in this architecture?

Multiple Choice

A client signs the method, target URI, Authorization field, Content-Digest, creation time, and nonce. A gateway verifies the signature, consumes the nonce, transforms the request, and sends the backend an unsigned X-Verified-Signer field over a separate TLS connection. The backend cannot reconstruct the client's signature base.

A. It directly verified the client signature because the gateway accepted it earlier B. It may trust the header without protecting its source because TLS was used somewhere C. It may rely on a gateway assertion only under an explicit, integrity-protected trust contract D. It must reject every proxied request because RFC 9421 forbids verifier delegation

**Explanation:** RFC 9421 Sections 1.4 and 3.2.1 require an application profile and verifier to define and enforce coverage, key, algorithm, freshness, and other acceptance requirements. The backend did not itself verify the client's target message after transformation. C can be a valid local trust design only if the gateway's identity, assertion integrity, request binding, and authorization meaning are specified and protected; it must be described as reliance on the gateway, not end-to-end backend verification. RFC 9421 does not categorically forbid that architecture, so D is too broad.

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: Which repair has a defensible signature context?

Q10: What may the backend claim and rely on in this architecture?