Network Working Group R. Polli Internet-Draft Digital Transformation Department, Italian Government Intended status:Standards Track 18Experimental 2 December20202021 Expires:215 June20212022 The "id-" prefix for Digest Algorithmsdraft-polli-id-digest-algorithms-01draft-polli-id-digest-algorithms-02 Abstract This document defines the "id-" prefix for digest-algorithms used in the DigestHTTP field.Fields. This prefix explicits that the computed checksum valueof the digest-algorithmis 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/ (https://lists.w3.org/Archives/Public/ietf-http-wg/). The source code and issues list for this draft can be found athttps://github.com/ioggstream/draft-polli-Retry-Scope (https://github.com/ioggstream/draft-polli-Retry-Scope).https://github.com/ioggstream/draft-polli-id-digest-algorithms (https://github.com/ioggstream/draft-polli-id-digest-algorithms). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on215 June2021.2022. Copyright Notice Copyright (c)20202021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must includeSimplifiedRevised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in theSimplifiedRevised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 2. The "id-" prefix for digest-algorithms . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . .43 3.1. Disclosure of encrypted content . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44.1. TBD how to reserve "id-" prefix?5. Normative References . . . . . . . . . . . .4 5. Examples. . . . . . . . 4 Appendix A. Examples . . . . . . . . . . . . . . . . . .4 5.1. The id-crc32c digest-algorithm. . . . 5 A.1. The id-sha-256 digest-algorithm . . . . . . . . .4 6. Normative References. . . . 5 FAQ . . . . . . . . . . . . . . . .4 Appendix A. Acknowledgements. . . . . . . . . . . . . . . 5 Code Samples . . .5 FAQ. . . . . . . . . . . . . . . . . . . . . . . 5 Acknowledgements . . . . . . . .5 Code Samples. . . . . . . . . . . . . . . . 6 Change Log . . . . . . . . . .5 Change Log. . . . . . . . . . . . . . . . . 6 Since draft-polli-id-digest-algorithms-01 . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The [DIGEST] defines a way to convey a checksum of a representation- data as specified in [SEMANTICS]. As the representation data depends on the value of"Content- Encoding",Content-Encoding, it is useful to convey the checksum value of a representation without anycontent-codingcontent coding applied. This proposal introduces the"id-"id- prefix to specify that the provided digest-algorithm value is computed on therepresentation- datarepresentation-data without anycontent-codingcontent coding applied. 1.1. 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 [RFC2119] [RFC8174] 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 [RFC5234] and updated by [RFC7405]. The definitions "representation", "selected representation", "representation data", "representation metadata", and"payload body""content" in this document are to be interpreted as described in [SEMANTICS]. The definitions "digest-algorithm" and "representation-data-digest" in this document are to be interpreted as described in [DIGEST]. 2. The "id-" prefix for digest-algorithms A new digest-algorithm to be registered within the HTTP Digest Algorithm Values(https://www.iana.org/assignments/http-dig-alg/http-dig- alg.xhtml)Registry (https://www.iana.org/assignments/http-dig- alg/) MUST NOT start with the string"id-".id-. The following two examples show two digest-algorithm names that cannot be registeredid-crc32c id-adler32id-sha-256 id-sha-512 For every digest-algorithm registered in the HTTP Digest Algorithm Values(https://www.iana.org/assignments/http-dig-alg/http-dig- alg.xhtml)(https://www.iana.org/assignments/http-dig-alg/) the associate"id-"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- algorithmDescription"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 [DIGEST].3. Security Considerations 3.1. Disclosure of encrypted contentLike the "id-sha-256" digest-algoritm defined in [DIGEST] ifIf thecontent-codingcontent coding provides encryption features, sending the checksum of unencoded representation can discloseinformation.information about the original content. 4. IANA Considerations4.1. TBD how to reserve "id-" prefix? 5. Examples 5.1. The id-crc32c digest-algorithm ThePlease, add the followingrequest conveys a brotli encoded json object {"hello": "world"} The "Digest" computed usingtext to the "Note" section of the"crc32c" digest-algorithm present inHTTP Digest Algorithm Values(https://www.iana.org/assignments/http- dig-alg/http-dig-alg.xhtml)(https://www.iana.org/assignments/http-dig- alg/). " For each registered Digest Algorithm, an associated id- algorithm iscontent-coding aware, while itsdefined. The associated"id-" digest-algorithmrepresentation-data-digest isnot "id-crc32c" POST /data HTTP/1.1 Content-Type: application/json Content-Encoding: br Digest: id-crc32c=43794720, crc32c=DB329237 CwGAZG9nAw== 6.computed according to Section 2 of this document. " 5. Normative References [DIGEST] Polli, R. and L. Pardue, "DigestHeaders",Fields", Work in Progress, Internet-Draft, draft-ietf-httpbis-digest-headers-04, 17 October 2020, <http://www.ietf.org/ internet-drafts/draft-ietf-httpbis-digest-headers-04.txt>.headers-07, 16 November 2021, <https://www.ietf.org/archive/id/draft-ietf-httpbis- digest-headers-07.txt>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>. [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [SEMANTICS] Fielding,R., Ed.R. T., Nottingham, M., and J. Reschke,Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>."HTTP Semantics", Work in Progress, Internet-Draft, draft-ietf- httpbis-semantics-19, 12 September 2021, <https://www.ietf.org/archive/id/draft-ietf-httpbis- semantics-19.txt>. Appendix A.Acknowledgements This specification was born fromExamples A.1. The id-sha-256 digest-algorithm The following request conveys athread created by James Manger andbrotli encoded json object {"hello": "world"} The Digest computed using thesubsequent discussion here https://github.com/httpwg/http- extensions/issues/885."sha-256" digest-algorithm present in HTTP Digest Algorithm Values (https://www.iana.org/assignments/http- dig-alg/) is content coding aware, while its associated "id-" digest- algorithm is not. POST /data HTTP/1.1 Content-Type: application/json Content-Encoding: br Digest: sha-256=4REjxQ4yrqUVicfSKYNO/cF9zNj5ANbzgDZt3/h3Qxo=, id-sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE= CwGAZiwiAeyJoZWxsbyI6ICJ3b3JsZCJ9Aw== 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:Question 1 Answer 1How 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 generateand validate the "Digest" values shown in the examples throughout this document?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. import base64, json, brotli,crc32chashlib identity = lambda x: x def digest(item, content_coding=identity,algorithm=crc32c.crc32c):algorithm=hashlib.sha256) -> bytes: json_bytes = json.dumps(item).encode() content_encoded = content_coding(json_bytes) checksum = algorithm(content_encoded)# encode result has uppercase hexreturnhex(checksum)[2:].upper()base64.encodebytes(checksum.digest()) item = {"hello": "world"}print("crc32cprint("sha-256 digest value for a br-coded representation: ", digest(item, content_coding=brotli.compress) )print("id-crc32cprint("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 LogRFC EDITOR PLEASE DELETE THIS SECTION._RFC Editor: Please remove this section before publication._ Since draft-polli-id-digest-algorithms-01 * Include id-sha-256 and id-sha-512. Author's Address Roberto Polli Digital Transformation Department, Italian Government Italy Email: robipolli@gmail.com