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 HTTP field. This prefix explicits that the value of the digest-algorithm 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-Retry-Scope.

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 "payload body" 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 digest-algorithm to be registered within the HTTP Digest Algorithm Values 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.

This definition is compatible, and thus extends, the definition of the "id-sha-256" and "id-sha-512" digest-algorithms contained in Section X of .

Security Considerations

Disclosure of encrypted content Like the "id-sha-256" digest-algoritm defined in if the content-coding provides encryption features, sending the checksum of unencoded representation can disclose information.

IANA Considerations

TBD how to reserve "id-" prefix?

Examples

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

Normative References This document defines the HTTP Digest and Want-Digest fields, thus allowing client and server to negotiate an integrity checksum of the exchanged resource representation data. This document obsoletes RFC 3230. It replaces the term "instance" with "representation", which makes it consistent with the HTTP Semantic and Context defined in draft-ietf-httpbis-semantics. The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation. 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.

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.

FAQ

Q: Question 1

Answer 1

Code Samples RFC Editor: Please remove this section before publication. How can I generate and validate the Digest values shown in the examples throughout this document? 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.

Change Log RFC EDITOR PLEASE DELETE THIS SECTION.