Hey Sarah (and thanks Lucas!),
The markdown file for -05 is
https://raw.githubusercontent.com/httpwg/http-extensions/refs/tags/draft-ietf-httpbis-unencoded-digest-05/draft-ietf-httpbis-unencoded-digest.md.
I'll attach it as well, just in case that's simpler.
Thanks!
-mike
On Tue, Jun 23, 2026 at 4:11 PM Sarah Tarrant <[email protected]>
wrote:
> Hi Lucas,
>
> Thank you for your reply.
>
> I appreciate your enthusiasm for markdown. Could you send me the
> self-contained markdown file that matches the approved version in
> datatracker?
>
> Sincerely,
> Sarah Tarrant
> RFC Production Center
>
> > On Jun 22, 2026, at 5:50 PM, Lucas Pardue <[email protected]> wrote:
> >
> > Hi,
> >
> > Thanks for the email, I will be answering on behalf of the authors.
> Please see responses in line:
> >
> > On Mon, Jun 22, 2026, at 22:27, [email protected] wrote:
> >>
> >>
> >> Author(s),
> >>
> >> Congratulations, your document has been successfully added to the RFC
> Editor queue!
> >> The team at the RFC Production Center (RPC) is looking forward to
> working with you
> >> as your document moves forward toward publication. To help reduce
> processing time
> >> and improve editing accuracy, please respond to the questions below.
> Please confer
> >> with your coauthors (or authors of other documents if your document is
> in a
> >> cluster) as necessary prior to taking action in order to streamline
> communication.
> >> If your document has multiple authors, only one author needs to reply
> to this
> >> message.
> >>
> >> As you read through the rest of this email:
> >>
> >> * If you need/want to make updates to your document, we encourage you
> to make those
> >> changes and resubmit to the Datatracker. This allows for the easy
> creation of diffs,
> >> which facilitates review by interested parties (e.g., authors, ADs, doc
> shepherds).
> >>
> >> * If you feel no updates to the document are necessary, please reply
> with any
> >> applicable rationale/comments.
> >>
> >>
> >> Please note that the RPC team will not work on your document until we
> receive a
> >> reply. We require a reply, even if you don’t have guidance or don’t
> feel that you
> >> need to make any updates to the document. After we hear from you, your
> document
> >> will start moving through the queue. You will be able to review and
> approve our
> >> updates during Final Review (formerly AUTH48).
> >>
> >> Please feel free to contact us with any questions you may have at
> >> [email protected].
> >>
> >> Thank you!
> >> The RPC Team
> >>
> >> --
> >>
> >> 1) As there may have been multiple updates made to the document during
> Last Call,
> >> please review the current version of the document:
> >>
> >> * Is the text in the Abstract still accurate?
> >
> > Yes
> >>
> >>
> >>
> >> * Are the Authors' Addresses, Contributors, and Acknowledgments
> >> sections current?
> >
> > Yes
> >>
> >>
> >>
> >>
> >> 2) Please share any style information that could help us with editing
> your
> >> document. For example:
> >>
> >> * Is your document's format or its terminology based on another
> document,
> >> WG style guide, etc.? If so, please provide a pointer to that
> information
> >> (e.g., "This document's terminology should match DNS terminology in
> >> RFC 9499." or "This document uses the style info at
> >> <https://httpwg.org/admin/editors/style-guide>.").
> >>
> >> * Is there a general pattern of capitalization or formatting of terms
> that
> >> editors can follow (e.g., "Field names should have initial
> capitalization."
> >> or "Parameter names should be in double quotes." or "<tt/> should be
> used
> >> for token names." etc.)?
> >
> > To answer both of these, we have attempted to match the style and
> terminology of RFC 9530, which itself attempts to channel the HTTP
> editorial style guidelines in https://httpwg.org/admin/editors/style-guide.
> We expect readers to use this doc in combination with RFC 9530 so
> consistency with it is important. If there is a conflict, prefer RFC 9530.
> >
> > HTTP Header field names, e.g. Repr-Digest or Unencoded-Digest, should be
> capital cased in <tt>
> >>
> >>
> >> 3) Please carefully review the entries and their URLs in the
> >> References section with the following in mind. Note that we will
> >> update as follows unless we hear otherwise at this time:
> >>
> >> * References to obsoleted RFCs will be updated to point to the current
> >> RFC on the topic in accordance with Section 4.8.6 of RFC 7322
> >> (RFC Style Guide).
> >>
> >> * References to I-Ds that have been replaced by another I-D will be
> >> updated to point to the replacement I-D.
> >>
> >> * References to documents from other organizations that have been
> >> superseded will be updated to their superseding version.
> >>
> >> Note: To check for outdated RFC and I-D references, you can use
> >> idnits <https://author-tools.ietf.org/idnits>.
> >
> > There are a small number of references and they all look ok to me.
> >>
> >>
> >>
> >> 4) Is there any text that requires special handling? For example:
> >>
> >> * Are there any sections that were contentious when the document was
> drafted?
> >
> > No
> >>
> >>
> >>
> >> * Are any sections that need to be removed before publication marked as
> such
> >> (e.g., Implementation Status sections (per RFC 7942))?
> >
> > Yes, the "About This Document" section
> >>
> >>
> >>
> >> * Are there any instances of repeated text/sections that should be
> edited
> >> the same way?
> >
> > N/A
> >>
> >>
> >>
> >>
> >> 5) This document uses one or more of the following text styles.
> >> Are these elements used consistently?
> >>
> >> * fixed width font (<tt/> or `)
> >> * italics (<em/> or *)
> >> * bold (<strong/> or **)
> >
> > We _tried_ to apply them consistently. I suspect we may have failed to
> hit 100% success :-)
> >>
> >>
> >>
> >> 6) This document appears to contain a formal language (or code / code
> >> snippets that will be marked with <sourcecode> in this document's
> >> XML file). See https://authors.ietf.org/formal-languages.
> >>
> >> * Does it validate?
> >
> > Several instance are of type '<sourcecode type="http-message" ...',
> these are automatically validated as part of the HTTP WG drafting process.
> There were also semantically validated during last call and directorate
> reviews.
> >>
> >>
> >>
> >> * Some formal languages (e.g., YANG) require certain reference entries
> >> and/or boilerplate in the Security Considerations section (see the link
> >> above for more information). Please confirm that this document matches
> >> the current guidance for the language type.
> >
> > Confirmed
> >>
> >>
> >>
> >> * Unless already indicated in a submitted XML file for this document,
> >> please let us know what type should be used for the <sourcecode>
> element
> >> for each module/snippet/etc. (See information about <sourcecode> types
> >> at https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types.)
> >
> > Several instance are of type '<sourcecode type="http-message" ...'
> >
> >>
> >>
> >> 7) Because this document updates RFC 9530, please review
> >> the reported errata and confirm whether they have been addressed in
> this
> >> document or are not relevant:
> >>
> >> * RFC 9530 (https://www.rfc-editor.org/errata/rfc9530)
> >
> > All errata have been checked and are not relevant to be addressed in
> this document.
> >>
> >>
> >>
> >>
> >> 8) Is there anything else that the RPC should be aware of while editing
> this
> >> document?
> > Our authoring process uses Markdown. If there's any way for us to be
> opted in to the markdown RFC process we'd love to do that. If that's not
> possible, we'll deal with it.
> >
> > Kind regards
> > Lucas
>
>
>
---
title: "HTTP Unencoded Digest"
abbrev: "HTTP Unencoded Digest"
category: std
docname: draft-ietf-httpbis-unencoded-digest-latest
submissiontype: IETF
number:
date: {DATE}
v: 3
area: Web and Internet Transport
workgroup: HTTP
keyword:
- next generation
- unicorn
- sparkling distributed ledger
venue:
group: HTTP
type: Working Group
home: https://httpwg.org/
mail: [email protected]
arch: https://lists.w3.org/Archives/Public/ietf-http-wg/
repo: https://github.com/httpwg/http-extensions/labels/unencoded-digest
github-issue-label: unencoded-digest
updates: 9530
author:
-
fullname: Lucas Pardue
organization: Cloudflare
email: [email protected]
-
fullname: Mike West
organization: Google
email: [email protected]
normative:
informative:
--- abstract
The Repr-Digest and Content-Digest integrity fields are subject to HTTP content
coding considerations. There are some use cases that benefit from the
unambiguous exchange of integrity digests of unencoded representation. The
Unencoded-Digest and Want-Unencoded-Digest fields complement existing integrity
fields for this purpose.
This document updates the definitions of the terms "Integrity fields" and "Integrity preference
fields" originally defined in RFC 9530.
--- middle
# Introduction
The `Repr-Digest` and `Content-Digest` integrity fields defined in
{{!DIGEST-FIELDS=RFC9530}} are suitable for a range of use cases. However,
because the fields are subject to HTTP content coding considerations, it is
difficult to support use cases that could benefit from the exchange of integrity
digests of the unencoded representation.
As a simple example, an application using HTTP might be presented with request
or response representation data that has been transparently decoded. Attempting
to verify the integrity of the data against the `Repr-Digest` would first require
re-encoding that data using the same coding indicated by the Content-Encoding
header field ({{Section 8.4 of !HTTP=RFC9110}}), which is not always possible
(see {{Section 6.5 of DIGEST-FIELDS}}).
Although receivers could feasibly re-encode data in order to carry out
`Repr-Digest` validation, it might be impractical for certain kinds of
environments. For instance, browsers tend to provide built-in support for
transparent decoding but little support for encoding; while this could be done
via the use of additional libraries it would create work in JavaScript that
could contend with other activities. Even on the server side, the re-encoding of
received data might not be acceptable; some coding algorithms are optimized
towards efficient decoding at the cost of complex encoding. A Content-Encoding
field value that indicates a series of encodings adds further complexity.
A more complex example involves HTTP Range Requests ({{Section 14 of
HTTP}}), where a client issues multiple requests to obtain partial representations
and "stitches" them back into a whole. Unfortunately, if the responses have
different content codings, the `Repr-Digest` field will vary by the
server's selected encoding (i.e., the Content-Encoding header field, {{Section
8.4 of HTTP}}). This provides a challenge for a client - in order to verify the
integrity of the pieced-together whole it would need to remove the encoding of
each part, combine them, and then encode the result in order to compare against
one or more `Repr-Digest`s.
The Accept-Encoding header field ({{Section 12.5.3 of HTTP}}) provides the means
to indicate preferences for content codings. It is possible for an endpoint to
indicate a preference for no encoding, for example, by sending the "identity"
token. However, codings often provide data compression that is advantageous.
Disabling content coding in order to simplify integrity checking might not be
an acceptable trade-off.
For a variety of reasons, decoding and re-encoding content in order to benefit
from HTTP integrity fields is not preferable. This specification defines the
Unencoded-Digest and Want-Unencoded-Digest fields to support a simpler validation
workflow in some scenarios where content coding is applied. These fields
complement the other integrity fields defined in {{DIGEST-FIELDS}}.
This document updates the definition of terms originally defined in {{DIGEST-FIELDS}}.
"Integrity fields" is updated to also include the Unencoded-Digest field ({{unencoded-digest}}.
"Integrity preference fields" is updated Want-Unencoded-Digest field ({{want-unencoded-digest}}).
# Conventions and Definitions
{::boilerplate bcp14-tagged}
This document uses the following terminology from {{Section 3 of
!STRUCTURED-FIELDS=RFC9651}} to specify syntax and parsing: Byte Sequence,
Dictionary, and Integer.
The definitions "representation", "selected representation", "representation
data", "representation metadata", and "content" in this document are to be
interpreted as described in {{!HTTP=RFC9110}}.
This document uses the line folding strategies described in {{?FOLDING=RFC8792}}.
The term "digest" is to be interpreted as described in {{DIGEST-FIELDS}}.
"Integrity fields" is the collective term for `Content-Digest`, `Repr-Digest`,
and `Unencoded-Digest`.
"Integrity preference fields" is the collective term for `Want-Repr-Digest`,
`Want-Content-Digest`, and `Want-Unencoded-Digest`.
# The Unencoded-Digest Field {#unencoded-digest}
The `Unencoded-Digest` HTTP field can be used in requests and responses to
communicate digests that are calculated using a hashing algorithm applied to the
entire selected representation data with no content codings applied ({{Section
8.4.1 of HTTP}}).
Apart from the content coding concerns, `Unencoded-Digest` behaves similarly
to `Repr-Digest` ({{Section 3 of DIGEST-FIELDS}}).
`Unencoded-Digest` can be sent in messages with and without content codings.
When there is no content coding, `Unencoded-Digest` acts identically to
`Repr-Digest`; for the same hashing algorithm the computed value would be the
same.
`Unencoded-Digest` is a `Dictionary` (see {{Section 3.2 of STRUCTURED-FIELDS}})
where each:
* key conveys the hashing algorithm (see {{Section 5 of DIGEST-FIELDS}}) used to
compute the digest;
* value is a `Byte Sequence` ({{Section 3.3.5 of STRUCTURED-FIELDS}}), that
conveys an encoded version of the byte output produced by the digest
calculation.
Each Dictionary value can have zero or more Parameters ({{Section 3.1.2 of
STRUCTURED-FIELDS}}). This specification does not define any Parameters;
future extensions may do so. Unknown Parameters MUST be ignored.
In the following examples of `Unencoded-Digest` fields, the representation data
with no content codings applied is: "An unexceptional string" followed by a
line feed character (0xA).
~~~ http-message
NOTE: '\' line wrapping per RFC 8792
Unencoded-Digest: \
sha-512=:WjyMuMD9EI/v0RoJchcevbo6lF498VyE9564OgXf+98iJptoSvb1Czo9\
uVJu2bVU/tOv90huiMG3+YaMX1kipw==:
~~~
The `Dictionary` type can be used, for example, to attach multiple digests
calculated using different hashing algorithms in order to support a population
of endpoints with different or evolving capabilities. Such an approach could
support transitions away from weaker algorithms (see
{{Section 6.6 of DIGEST-FIELDS}}).
~~~ http-message
NOTE: '\' line wrapping per RFC 8792
Unencoded-Digest: \
sha-256=:5Bv3NIx05BPnh0jMph6v1RJ5Q7kl9LKMtQxmvc9+Z7Y=:,\
sha-512=:WjyMuMD9EI/v0RoJchcevbo6lF498VyE9564OgXf+98iJptoSvb1Czo9\
uVJu2bVU/tOv90huiMG3+YaMX1kipw==:
~~~
A recipient MAY ignore any or all digests. Application-specific behavior or
local policy MAY set additional constraints on the processing and validation
practices of the conveyed digests. Security considerations related to ignoring
digests or validating multiple digests are presented in {{Sections 6.6 and
6.7 of DIGEST-FIELDS}} respectively.
A sender MAY send a digest without knowing whether the recipient supports a
given hashing algorithm. A sender MAY send a digest if it knows the recipient
will ignore it.
`Unencoded-Digest` can be sent in a trailer section. In this case,
`Unencoded-Digest` MAY be merged into the header section; see {{Section 6.5.1 of
HTTP}}.
# The Want-Unencoded-Digest Field {#want-unencoded-digest}
`Want-Unencoded-Digest` is an integrity preference field; see {{Section 4 of
DIGEST-FIELDS}}. It indicates that the sender would like to receive (via the
`Unencoded-Digest` field) a representation digest on messages associated with the
request URI and representation metadata where no content coding is applied.
If `Want-Unencoded-Digest` is used in a response, it indicates that the server
would like the client to provide the `Unencoded-Digest` field on future requests.
`Want-Unencoded-Digest` is only a hint. The receiver of the field can ignore it
and send an `Unencoded-Digest` field using any algorithm or omit the field
entirely. It is not a protocol error if preferences are ignored. Applications
that use `Unencoded-Digest` and `Want-Unencoded-Digest` can define expectations
or constraints that operate in addition to this specification. Ignored
preferences are an application-specific concern.
`Want-Unencoded-Digest` is of type `Dictionary` where each:
* key conveys the hashing algorithm;
* value is an `Integer` ({{Section 3.3.1 of STRUCTURED-FIELDS}}) that conveys an
ascending, relative, weighted preference. It must be in the range 0 to 10
inclusive. 1 is the least preferred, 10 is the most preferred, and a value of
0 means "not acceptable".
Each Dictionary value can have zero or more Parameters ({{Section 3.1.2 of
STRUCTURED-FIELDS}}). This specification does not define any Parameters;
future extensions may do so. Unknown Parameters MUST be ignored.
Examples:
~~~ http-message
Want-Unencoded-Digest: sha-256=1
Want-Unencoded-Digest: sha-512=3, sha-256=10, unixsum=0
~~~
# Messages containing both Unencoded-Digest and Content-Encoding {#encoding-and-unencoded}
Digests delivered through `Unencoded-Digest` apply to the unencoded
representation. If a message is received with content codings, a recipient needs
to decode the message in order to calculate the digest that can subsequently be
used for validation. If multiple content codings are applied, the recipient
needs to decode all encodings in order before validation.
Since the digest is calculated on unencoded representation bytes, validation of
a message with content codings (as described above) can only succeed where the
decoded output produces the same byte sequence as the input. While {{Section
8.4.1 of !HTTP=RFC9110}} describes content codings to operate "without loss of
information", that doesn't necessarily mean a byte-for-byte equivalence. A
content coding could perform semantically-meaningless
transformations that nevertheless result in a decoded byte sequence that does
not exactly match the original unencoded representation. In order to avoid
unintended validation failures, care is advised when selecting content codings
for use with `Unencoded-Digest`; that said, most registered content codings do provide
byte-for-byte equivalence and are appropriate.
# Integrity Fields are Complementary
Integrity fields can be used in combination to address different and
complementary needs, particularly the cases described in {{introduction}}.
In the following examples, the selected representation data with no content
codings applied is: "An unexceptional string" followed by a line feed character
(0xA). For presentation purposes, the response content is displayed as a
sequence of hex-encoded bytes because it contains non-printable characters.
The first example demonstrates a request that uses content negotiation.
~~~ http-message
GET /boringstring HTTP/1.1
Host: example.org
Accept-Encoding: gzip
~~~
{: title="GET request with content negotiation"}
The server responds with the full GZIP-encoded representation. The `Repr-Digest`
and `Unencoded-Digest` therefore differ.
~~~ http-message
NOTE: '\' line wrapping per RFC 8792
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Encoding: gzip
Repr-Digest: \
sha-256=:kwcdt3RBGcsLaj7QSz9AW8MuwJaLjOJqUU/jKixF2oU=:
Unencoded-Digest: \
sha-256=:5Bv3NIx05BPnh0jMph6v1RJ5Q7kl9LKMtQxmvc9+Z7Y=:
1f 8b 08 00 79 1f 08 64 00 ff
73 cc 53 28 cd 4b ad 48 4e 2d
28 c9 cc cf 4b cc 51 28 2e 29
ca cc 4b e7 02 00 7e af 07 44
18 00 00 00
~~~
{: title="GET response with GZIP content coding"}
The second example demonstrates a range request that uses content negotiation.
~~~ http-message
GET /boringstring HTTP/1.1
Host: example.org
Accept-Encoding: gzip
Range: bytes=0-9
~~~
{: title="Range request with content negotiation"}
The server responds with a 206 (Partial Content) response using GZIP content
coding, it has three different Integrity fields. The `Content-Digest` relates to
the response content that can be used to validate the integrity of the
received part. `Repr-Digest` and `Unencoded-Digest` can be used later once the
entire object is reconstructed. The choice of which to use is left to the
application that would consider a range of factors outside the scope of this
document.
~~~ http-message
NOTE: '\' line wrapping per RFC 8792
HTTP/1.1 206 Partial Content
Content-Type: text/plain
Content-Encoding: gzip
Content-Range: bytes 0-9/44
Content-Digest: \
sha-256=:SotB7Pa5A7iHSBdh9mg1Ev/ktAzrxU4Z8ldcCIUyfI4=:
Repr-Digest: \
sha-256=:kwcdt3RBGcsLaj7QSz9AW8MuwJaLjOJqUU/jKixF2oU=:
Unencoded-Digest: \
sha-256=:5Bv3NIx05BPnh0jMph6v1RJ5Q7kl9LKMtQxmvc9+Z7Y=:
1f 8b 08 00 79 1f 08 64 00 ff
~~~
{: title="Partial response with GZIP content coding"}
# Security Considerations
All the same considerations documented in {{DIGEST-FIELDS}} apply.
This document introduces a further consideration related to the process of
validation when an HTTP message contains both Content-Encoding and
Unencoded-Digest ({{encoding-and-unencoded}}). In order to validate the
Unencoded-Digest, encoded content needs to be decoded. This provides an
opportunity for an attacker to direct malicious data into a decoder. One
possible mitigation would be to also provide a Content-Digest or Repr-Digest in
the message, allowing for validation of the received bytes before further
processing. An attacker that can substitute various parts of an HTTP message
presents several risks; {{Sections 6.1, 6.2, and 6.3 of DIGEST-FIELDS}}
describe relevant considerations and mitigations.
A content coding might provide encryption capabilities, for example "aes128gcm"
({{?RFC8188}}). Using Unencoded-Digest with such content codings can leak
information about the original data because header fields are visible to anyone
who can read the HTTP message. For instance, an attacker that can access
Unencoded-Digest values could infer details about the unencrypted content
without decrypting it if, for example, the unencrypted content has a predictable
pattern. When the "aes128gcm" content coding is used, the security
considerations in {{Section 4 of ?RFC8188}} apply. Namely, the Unencoded-Digest
field is considered sensitive information and SHOULD be omitted unless a means
of encrypting the Unencoded-Digest field is used.
# IANA Considerations
IANA is asked to update the "Hypertext Transfer Protocol (HTTP) Field Name
Registry" {{!HTTP=RFC9110}} as shown in the table below:
|-----------------------|-----------|-----------------|--------------------------------------------|
| Field Name | Status | Structured Type | Reference |
|-----------------------|-----------|-----------------|--------------------------------------------|
| Unencoded-Digest | permanent | Dictionary | {{unencoded-digest}} of this document |
| Want-Unencoded-Digest | permanent | Dictionary | {{want-unencoded-digest}} of this document |
|-----------------------|-----------|-----------------|--------------------------------------------|
{: #iana-field-name-table title="Hypertext Transfer Protocol (HTTP) Field Name Registry Update"}
--- back
# Acknowledgments
{:numbered="false"}
Early drafts of {{DIGEST-FIELDS}} included a mechanism to support the exchange
of digests where no content coding is applied, which was removed before
publication. While the design here is different, it is motivated by discussion
of the previous design in the HTTP WG. The motivating use cases still mostly
apply identically.
The following people provided detailed feedback on the document: Mike Bishop,
Mallory Knodel, Roberto Polli, Rifaat Shekh-Yusef, and Martin Thomson.
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
