ToppyMicroServices

RFC 9530 Quiz (EN)

Digest Fields

ENJA
0 / 0

References (URLs)

Q1: Which digest fields match these two integrity goals?

Multiple Choice

An agent receives a gzip-coded partial response. It wants to verify the exact bytes carried in this response and also identify the complete selected representation from which the range came.

**Explanation:** A: RFC 9530 Sections 1.2 and 3 define Repr-Digest over selected representation data, not over the HTTP message fields or just the carried range. B: Section 4 defines Want-Content-Digest as a preference hint, not as an integrity value. Content-Digest also does not represent the complete selected representation in this case. C: Sections 2 and 3 distinguish the actual message content from the selected representation. Appendix B.3 illustrates different values for a partial response. D: Range selection changes the transferred content, and content coding affects representation data. The two validation goals therefore have different inputs. Decision rule: Before choosing a field, write down the exact byte domain: transferred content, selected representation, or metadata outside either digest.

Q2: What does this ignored digest preference mean?

Multiple Choice

An A2A client sends Want-Content-Digest with sha-256 as its highest preference. The server returns no Content-Digest, and the A2A profile defines no additional requirement.

**Explanation:** A: RFC 9530 Section 4 defines the preference fields as hints. Weight expresses relative preference but does not make a response digest mandatory by itself. B: Section 4 says a receiver may ignore the hint and that doing so is not a protocol error. Application-specific constraints may add a requirement. C: Content and representation integrity are different goals. Ignoring one preference does not negotiate the other field. D: Section 5 permits deprecated algorithms only for limited corruption cases and forbids them in adversarial uses. A preference does not force unsafe fallback. Decision rule: If omission must fail the operation, that requirement belongs in the consuming application profile rather than being inferred from Want-Content-Digest.

Q3: Is this signed digest sufficient for the stated A2A decision?

Multiple Choice

A sender signs Content-Digest but not Content-Type or Content-Encoding. The backend chooses a security-sensitive parser from those two unsigned fields after validating the digest and signature.

**Explanation:** A: RFC 9530 Section 6.1 states that digest fields do not protect HTTP header or trailer fields. Content-Digest covers actual message content only. B: An Active hash can resist relevant hash attacks, but it does not bind fields omitted from the signature input. C: Content sniffing substitutes another ambiguous security rule and is not a protection supplied by RFC 9530. D: Section 6.3 warns that signing an Integrity field without representation metadata such as Content-Type or Content-Encoding leaves a tampering surface. Decision rule: Digest validation establishes integrity only for its defined bytes; signature coverage must also bind metadata that controls security-relevant interpretation.

Q4: What should Repr-Digest cover in this PATCH exchange?

Multiple Choice

A PATCH request carries a patch document. The success response carries the complete updated resource representation, and both messages include Repr-Digest.

**Explanation:** A: RFC 9530 Section 3.1 states this distinction explicitly: request metadata refers to the patch document, while response metadata can refer to the patched resource representation. B: The pre-patch resource is not the enclosed representation in either stated message. Repr-Digest follows representation semantics, not a shared conceptual base. C: The HTTP method does not make response content a patch document. The response's representation metadata and method semantics determine its digest input. D: Repr-Digest does not digest status codes or Location, and the PATCH request digest is not automatically over the target resource. Decision rule: For state-changing methods, derive the digest input separately for request and response instead of assuming that both refer to the target resource.

Q5: What assurance does this bare digest provide?

Multiple Choice

An A2A webhook arrives over a channel controlled by an active intermediary. The receiver accepts the sender identity solely because sha-256 Content-Digest matches the body.

**Explanation:** A: An unkeyed hash is computable by an attacker. RFC 9530 Section 6.1 says a malicious on-path actor can substitute content and a new digest. B: RFC 9530 defines content or representation integrity fields, not an authorization decision or identity credential. C: Section 6.1 supports this bounded assurance. Authentication needs an additional mechanism such as TLS endpoint authentication or a signature with suitable coverage. D: Section 6.1 expressly says HTTP fields are not protected in full. Request-target and header integrity require separate coverage. Decision rule: Match the threat model to the mechanism: an unkeyed digest can detect accidental change but cannot identify a sender in an adversarial channel.

Q6: How should integrity be composed across this transforming gateway?

Multiple Choice

An agent signs Content-Digest, Content-Type, and Content-Encoding for a gzip-coded task. A gateway validates them, decompresses the content, and forwards plain JSON to a backend that needs both origin evidence and the exact bytes it processes.

**Explanation:** A: RFC 9530 Section 2 binds Content-Digest to actual message content. Decompression changes those bytes, so the original value does not validate the forwarded content. B: Sections 2, 3, 6.1, and 6.3 require the design to distinguish byte domains and protection layers. Gateway trust and origin-verifiable evidence are alternative architectures that must be explicit. C: Content-Digest and Repr-Digest have different defined inputs, and changing a covered field or digest invalidates the original signature unless the signature scheme defines that transformation. D: RFC 9530 allows integrity fields across intermediaries but warns about transformations and metadata. It does not impose a blanket removal rule. Decision rule: A transformation ends the old byte-level assertion unless the profile preserves the original evidence or defines a new, authenticated assertion for the transformed message.