Digest Fields

Integrity preference fields (Want-Content-Digest, Want-Repr-Digest) are defined as hints rather than binding requirements. The receiver may reply with any algorithm or omit the field entirely; this avoids making algorithm negotiation a hard protocol dependency and lets application policy layer additional constraints on top.

http

RFC 3230 was obsoleted because implementations inconsistently interpreted its 'instance' concept: many computed digests over message content rather than representation data as intended. Because a content digest also proves useful for certain cases, non-conformance was difficult to detect. The new field names (Repr-Digest, Content-Digest) explicitly disambiguate the two inputs.

http

Structured Fields (RFC 8941) Dictionary encoding was chosen for all four new fields to eliminate the mixed base64/hex/decimal encoding formats allowed by RFC 3230. Digest values are uniformly serialized as Byte Sequences, and multiple algorithm/digest pairs can appear in a single field to support algorithm agility and negotiation.

http

Two separate Integrity fields were defined rather than one: Content-Digest covers actual message content bytes (useful for simple integrity of transferred bytes), while Repr-Digest covers the full selected representation data (useful for range requests, HEAD responses, and multi-hop reassembly). This separation allows each to be useful independently.

http

Integrity fields are tied to Content-Encoding and Content-Type metadata. A given resource may produce different digest values when transferred with different content codings (e.g., uncompressed vs. Brotli-encoded). Peers must use the same representation metadata to reproduce a digest.

http

Migrating from RFC 3230: the Digest field used representation data as input (what RFC 9530 calls Repr-Digest), while Content-Digest provides the capability RFC 3230 never had — a digest of HTTP message content. The syntax differs (RFC 3230 allowed per-algorithm encoding formats; RFC 9530 uses uniform Byte Sequence encoding), but the semantic considerations for Repr-Digest apply equally to the legacy Digest field.

http

Repr-Digest is designed to be independent of transfer codings (e.g., chunked transfer encoding for HTTP/1.1). Its value is computed over the selected representation data, so a Repr-Digest sent in a trailer section has the same value it would have in a header section, as demonstrated in Appendix B.11.

http

When a response includes Content-Location, Repr-Digest is computed on the selected representation of the resource identified by Content-Location, not necessarily the target URI of the request. The Location header field does not affect Repr-Digest computation because it is not representation metadata.

http

A recipient MAY ignore any or all digests. Application-specific behavior or local policy MAY set additional constraints on validation. It is not a protocol error if Want-Content-Digest or Want-Repr-Digest preferences are ignored.

http

Algorithms with status 'Active' are RECOMMENDED for use in applications, including adversarial contexts requiring resistance to collision, first-preimage, and second-preimage attacks.

http, crypto, security

Content-Digest and Repr-Digest MAY be sent in a trailer section, in which case they MAY be merged into the header section per Section 6.5.1 of [HTTP]. A sender MAY send a digest without knowing whether the recipient supports the given hashing algorithm.

http

Deprecated algorithms MUST NOT be used in a potentially adversarial setting, such as when signing Integrity fields for authenticity; they MAY be used only to preserve integrity against accidental corruption.

http, crypto, security

When a state-changing request's representation does not describe the target resource, Repr-Digest MUST be computed on the representation data. In responses, if the representation describes the request status, Repr-Digest MUST be computed on the enclosed representation; if there is a referenced resource, Repr-Digest MUST be computed on the selected representation of that referenced resource.

http

Hash algorithm registration entries carry four fields: Algorithm Key (the Structured Fields key string), Status (Active, Provisional, or Deprecated), Description, and Reference(s). Transitions between statuses (e.g., Active to Deprecated as security environment evolves) are permitted via update requests to the registry.

http, registry, crypto

The Content-Digest HTTP field communicates digests of actual message content (Section 6.4 of [HTTP]). It is a Structured Fields Dictionary where each key is a hashing algorithm identifier and each value is a Byte Sequence encoding of the digest output.

http, security, crypto

The Repr-Digest HTTP field communicates digests of the entire selected representation data (Section 8.1 of [HTTP]). It is a Structured Fields Dictionary with the same key/value structure as Content-Digest, but computed over representation data rather than message content.

http, security, crypto

The Want-Content-Digest and Want-Repr-Digest fields allow senders to indicate interest in receiving an Integrity field and to express algorithm preferences. Each is a Structured Fields Dictionary where keys are algorithm identifiers and values are Integers in the range 0–10 representing weighted preference (0 means 'not acceptable', 1 is least preferred, 10 is most preferred).

http, security

IANA deprecated the legacy 'Hypertext Transfer Protocol (HTTP) Digest Algorithm Values' registry (which listed algorithms for RFC 3230's Digest and Want-Digest fields). New registrations are encouraged to use the 'Hash Algorithms for HTTP Digest Fields' registry instead.

http, registry

IANA updated the HTTP Field Name Registry to add four permanent fields (Content-Digest, Repr-Digest, Want-Content-Digest, Want-Repr-Digest) and mark the legacy Digest and Want-Digest fields as obsoleted per RFC 3230 and Section 1.3 of RFC 9530.

http, registry

RFC 9530 creates the 'Hash Algorithms for HTTP Digest Fields' registry with initial entries: sha-512 (Active), sha-256 (Active), md5 (Deprecated), sha/SHA-1 (Deprecated), unixsum (Deprecated), unixcksum (Deprecated), adler/ADLER32 (Deprecated), crc32c (Deprecated). Registration uses Specification Required policy. Each entry carries an Algorithm Key, Status (Active/Provisional/Deprecated), Description, and Reference(s).

http, registry, crypto

Algorithm agility does not prevent downgrade or substitution attacks on the hashing algorithm. Integrity fields provide no mitigation for such attacks; endpoints can defend by restricting supported algorithms to stronger ones and protecting field values with TLS and/or digital signatures.

http, security, crypto

Before sending Integrity fields in a trailer section, senders should consider that intermediaries are explicitly allowed to drop trailers. Eager content processing before trailer receipt prevents digest validation, possibly leading to processing of corrupt or tampered data.

http, security

Content coding mechanisms (e.g., GZIP at different compression levels, aes128gcm with nonces) can produce different outputs from the same input without reflecting the difference in representation metadata. Therefore, Integrity field digests cannot serve as at-rest integrity proofs unless the exact encoded content is persisted.

http, security

Integrity field validation consumes computational resources. Implementations can restrict validation by algorithm type, count, or content size to avoid resource exhaustion; however, skipping validation or ignoring failure of a preferred algorithm opens the door to downgrade attacks.

http, security

Integrity fields protect HTTP representation data or content but do not protect HTTP header and trailer fields. An on-path attacker can remove or substitute a digest value without additional protection. Mitigation requires combining Integrity fields with TLS or digital signatures such as HTTP Message Signatures (RFC 9421).

http, security

When using Repr-Digest with digital signatures, the signature must also cover the representation metadata fields (Content-Type, Content-Encoding, etc.). A signature covering only Integrity fields allows an attacker to manipulate Content-Type and cause digest validation failure, consuming endpoint resources without delivering the representation.

http, security, crypto

Content-Digest and Repr-Digest are Structured Fields Dictionaries (RFC 8941 Section 3.2). Each dictionary member key is an Algorithm Key string and the value is a Byte Sequence (Section 3.3.5 of RFC 8941) containing the base64-encoded digest output. Multiple algorithm/digest pairs may appear in one field.

http, crypto

Want-Content-Digest and Want-Repr-Digest are Structured Fields Dictionaries where each member key is an Algorithm Key and the value is a Structured Fields Integer between 0 and 10 inclusive, encoding relative algorithm preference. Example: 'Want-Repr-Digest: sha-512=3, sha-256=10, unixsum=0'.

http