]> Digital Transformation Department, Italian Government

Italy robipolli@gmail.com

General Internet-Draft This document defines the "id-" prefix for digest-algorithms used in the Digest Fields. This prefix explicits that the computed checksum value is independent from Content-Encoding. Note to Readers RFC EDITOR: please remove this section before publication Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/. The source code and issues list for this draft can be found at https://github.com/ioggstream/draft-polli-id-digest-algorithms.

Introduction The defines a way to convey a checksum of a representation-data as specified in . As the representation data depends on the value of Content-Encoding, it is useful to convey the checksum value of a representation without any content coding applied. This proposal introduces the id- prefix to specify that the provided digest-algorithm value is computed on the representation-data without any content coding applied.

Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. These words may also appear in this document in lower case as plain English words, absent their normative meanings. This document uses the Augmented BNF defined in and updated by . The definitions "representation", "selected representation", "representation data", "representation metadata", and "content" in this document are to be interpreted as described in . The definitions "digest-algorithm" and "representation-data-digest" in this document are to be interpreted as described in .

The "id-" prefix for digest-algorithms A new digest-algorithm to be registered within the HTTP Digest Algorithm Values Registry MUST NOT start with the string id-. The following two examples show two digest-algorithm names that cannot be registered For every digest-algorithm registered in the HTTP Digest Algorithm Values the associate id- digest-algorithm has the following properties:

• the checksum is computed on the representation-data of the resource when no content coding is applied;
• the checksum is computed according to the original digest-algorithm "Description" field, and uses the same encoding of the original digest-algorithm.

Security Considerations

Disclosure of encrypted content If the content coding provides encryption features, sending the checksum of unencoded representation can disclose information about the original content.

IANA Considerations Please, add the following text to the "Note" section of the HTTP Digest Algorithm Values. " For each registered Digest Algorithm, an associated id- algorithm is defined. The associated representation-data-digest is computed according to of this document. "

Normative References Team Digitale, Italian Government Cloudflare This document defines HTTP fields that support integrity checksums. The Digest field can be used for the integrity of HTTP representations. The Content-Digest field can be used for the integrity of HTTP message content. Want-Digest and Want-Content- Digest can be used to indicate a sender's desire to receive integrity fields respectively. This document obsoletes RFC 3230. Adobe Fastly greenbytes GmbH The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.

Examples

The id-sha-256 digest-algorithm The following request conveys a brotli encoded json object The Digest computed using the "sha-256" digest-algorithm present in HTTP Digest Algorithm Values is content coding aware, while its associated "id-" digest-algorithm is not.

FAQ RFC Editor: Please remove this section before publication.

Q: Why to convey the checksum independent from the content codings?

This is useful to identify and validate a resource downloaded from different sources using different content codings, or to compare a resource with its stored or signed counterpart.

Q: How does it improve the life of checksum providers?

If providers use reverse proxies to eg. compress responses, this could invalidate content coding aware checksums. Providing an id- algorithm, allows the digest checksum to be validated.

Code Samples RFC Editor: Please remove this section before publication. How can I generate an identity digest value? The following python3 code can be used to generate digests for json objects using crc32c algorithm. Note that these are formatted as base64. This function could be adapted to other algorithms and should take into account their specific formatting rules. bytes: json_bytes = json.dumps(item).encode() content_encoded = content_coding(json_bytes) checksum = algorithm(content_encoded) return base64.encodebytes(checksum.digest()) item = {"hello": "world"} print("sha-256 digest value for a br-coded representation: ", digest(item, content_coding=brotli.compress) ) print("id-sha-256 digest value for a br-coded representation: ", digest(item, content_coding=identity) ) ]]>

Acknowledgements This specification was born from a thread created by James Manger and the subsequent discussion here https://github.com/httpwg/http-extensions/issues/885.

Change Log RFC Editor: Please remove this section before publication.

Since draft-polli-id-digest-algorithms-01

• Include id-sha-256 and id-sha-512.