jiebi/CodeConvo huggingface dataset:
Code change:
represented as a quoted string or MUST NOT include ";" or "," in the character sets used for the encoding. <del> Deprecated digest algorithms MUST NOT be used. </del> <ins> Insecure digest algorithms MAY be used to preserve integrity against accidental change, but MUST NOT be used in a potentially adversarial setting; for example, when signing the digest of content for authenticity. </ins> The registry is initialized with the tokens listed below.

Related discussion:
text: Thanks, nice solution.
The latest draft of the Digest Fields RFC [0] deprecates all non-cryptographically secure algorithms (notably, MD5 and CRC32c). Given that the RFC is "not intended to be a general protection against malicious tampering with HTTP messages," I'd like to propose not deprecating at least these two algorithms, or changing "deprecated digest algorithms MUST NOT be used" to "should be used with caution" or similar. CRC32c is a very useful algorithm because it is composable (crc(A+B) == combine(crc(A), crc(B))). See [1] for an explainer and [2] for an implementation of combine() in zlib. MD5 is ubiquitous. AWS S3 and Google Cloud Storage both use it (see [3], which has similar syntax to this RFC except that the crc32c is base64 instead of hex). [0] URL [1] URL [2] URL [3] URL Sorry if this is the wrong forum. I saw some links from the w3c mailing list archive that looked like more discussions were happening here than there.
Hi NAME this is the right place, thanks for opening the issue. Do you have a use case where you'd like to use these algorithms with the Digest or Content-Digest header? They are pretty old and pretty bad at their intended purpose - what caution can we offer? The statement comes from URL, which is really about making it clear that applications do care about protecting messages also need to apply signatures that protect HTTP header or trailer sections. Otherwise, an attacker could just change the header at the same time as changing the representation.
Thanks for the fast reply. My use case is for detecting file corruption in internal HTTP communication, where we trust the network/server/client. Since it's internal, we don't have to obey a standard, but I was hoping to provide the CRC32C and MD5 that we already store to our end users -- provide something instead of nothing. Those algorithms provide an adequate level of error detection by our rough calculation (considering that TCP and other layers also checksum). Intel's implementation of CRC32C [0] runs at >19 GB/s, whereas SHA256 runs at only ~360 MB/s.
Code change:
represented as a quoted string or MUST NOT include ";" or "," in the character sets used for the encoding. <del> Deprecated digest algorithms MUST NOT be used. </del> <ins> Insecure digest algorithms MAY be used to preserve integrity against accidental change, but MUST NOT be used in a potentially adversarial setting; for example, when signing the digest of content for authenticity. </ins> The registry is initialized with the tokens listed below.

Related discussion:
text: We also take advantage of the ability of CRC32C to be combined, so we can concatenate files in O(1) time and get their CRC32C without calculating a SHA256/512 or MD5 over the whole content. We serve some millions of files. Google Cloud Storage and AWS S3 probably store many trillions of files and provide CRC32C+MD5 and MD5, respectively.1 It would be pretty impactful for servers to be able to pass along these digests and might make it worthwhile for browsers to start verifying digests for downloads (e.g. revive [1]). I might be under-appreciating the security intents of this RFC, but there is clear mention of the other benefits of the RFC (below), which are ones that non-cryptographically secure hashes are often good enough for. [0] URL [1] URL Edit: 1 Clarification: The S3 object is an MD5 in many scenarios, and S3 uses for integrity checks during uploads. They do not explicitly store the MD5 for all objects though.
Corruption in the network does happen, but HTTPS is a far better way of managing that risk. I know that you say that you trust them, but I would be worried about the network/server/client being - or becoming - untrustworthy. Obviously, if you are into high-volume transfers of bulk data, you are going to do what you need to do; specialized applications have specialized constraints. But that doesn't make unsecured transfers any less inadvisable; I'd stand by the deprecation here as a general statement.
Hi NAME Thanks for joining the discussion! Let me clarify one point: This just means that the part protected by Digest (the representation) is only a subset of an HTTP message. For the rest, while I agree on some of your considerations, eg. we had a very long discussion on that URL Maybe, since crc32 & co - while deprecated - are still defined in the digest algorithm table, I think that you wouldn't have particular interoperability issues if you need to use them in a specific environment.
Thanks NAME for the pointers to the earlier discussions. I'd thought I'd searched but somehow missed those.
Code change:
represented as a quoted string or MUST NOT include ";" or "," in the character sets used for the encoding. <del> Deprecated digest algorithms MUST NOT be used. </del> <ins> Insecure digest algorithms MAY be used to preserve integrity against accidental change, but MUST NOT be used in a potentially adversarial setting; for example, when signing the digest of content for authenticity. </ins> The registry is initialized with the tokens listed below.

Related discussion:
text: I'll yield, although I remain in favor of saying these "SHOULD NOT" instead of "MUST NOT" be used at least because of their ubiquity, performance and the composability of CRCs. One last question: does the Digest header provide better security than, or any additional beyond, what TLS provides? My reading of the RFC is that TLS is the typical primary protection layer (since doesn't protect headers; indeed, itself could be altered) and is primarily useful for finding ~bugs. (PS: I really like the digests, nice idea.)
NAME you've made some good points. Adding accommodation for these algorithms, given the proliferation of e.g. MD5 for this kind of integrity checking could be better than nothing, or hoping that everyone would run a SHA-algo over all of their existing assets. The thorny part is how to square the circle on relaxing the rule and providing clear, meaningful guidance to implementers. The MUSTNOT helps set a clear bar, this means its unambiguous what the spec thinks about the relationship of Digest to secure usage scenarios. Anything else needs careful wording and is hard to get right. The current MUSTNOT is slightly odd in so far as we don't state the ramifications if it is used. Part of that is a product of how Digest has been defined and how apps use it
NAME The actual work on digest was driven by its usage in signing http messages (eg URL and URL ) This is at a different layer wrt TLS. So you can see Digest as a building block for creating non-repudiable HTTP exchanges without altering the payload (since signatures are conveyed via http headers). Hth, R.
Personally -- I think there's something here worth considering. AIUI the primary use case for headers is not adversarial -- it's end-to-end (i.e., through various intermediaries, toolkits, perhaps a data store) integrity. If someone has lots of content they've calculated CRC or MD5 for, it seems reasonable to allow them to use it in ; not only is it more efficient, but it saves them recalculating a value for all of that content (and possibly getting it wrong -- that's effectively "end-to-end over time"). OTOH, there are adversarial use cases for too -- mostly, signing the digest as a proxy for signing the content.
Code change:
represented as a quoted string or MUST NOT include ";" or "," in the character sets used for the encoding. <del> Deprecated digest algorithms MUST NOT be used. </del> <ins> Insecure digest algorithms MAY be used to preserve integrity against accidental change, but MUST NOT be used in a potentially adversarial setting; for example, when signing the digest of content for authenticity. </ins> The registry is initialized with the tokens listed below.

Related discussion:
text: Here, using CRC or MD5 can be bad, and shouldn't be encouraged (or perhaps allowed) by the spec. This leads me to think that deprecating them isn't the right thing to do; instead, what about marking them as insecure in the registry, and putting language into the spec to explain how to use that? If folks think that's a good idea, I can do a PR.
Thanks for the background NAME . NAME NAME I think that sounds reasonable to state something like "insecure digests {MUST NOT be used|are not suitable} for protection against malicious actors." The final part of this I think would be allowing for the insecure digests.
I like NAME idea of introducing "insecure". It's not trivial how to state that insecure algorithms must not be used in signatures/adversarial use cases. I'm waiting for Mark's proposal :)
Maybe "Checksum Only" to imply a more narrow purpose. "Insecure" is not the opposite of "secure".
LGTMA pragmatic approach.
Code change:
header field that is not present in the message, is not a Dictionary Structured Field, or whose value is malformed. <del> The identifier is a List Prefix member identifier that references a header field that is not present in the message, is not a List Structured Field, or whose value is malformed. </del> The identifier is a Dictionary member identifier that references a member that is not present in the header field value, or whose value is malformed.  E.g., the identifier is ""x-dictionary";key=c" and the value of the "x-dictionary" header field is "a=1, b=2" <del> The identifier is a List Prefix member identifier that specifies more List members than are present the header field.  E.g., the identifier is ""x-list";prefix=3" and the value of the "x-list" header field is "(1, 2)". </del> In the following non-normative example, the HTTP message being signed is the following request:

Related discussion:
text: Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?
Code change:
the transaction at hand.  SD-JWTs defined in this document enable such selective disclosure of JWT claims. <del> One example of a multi-use JWT is a verifiable credential, an issuer- </del> <ins> One example of a multi-use JWT is a verifiable credential, an Issuer- </ins> signed credential that contains the claims about a subject, and whose authenticity can be cryptographically verified.

Related discussion:
text: changes. created a common sd-jwt verification section wallet processing section talks only about presentation creation verifier processing section talks only about key binding JWT processing and refers to a common sd-jwt verification section Note that the terminology is new - based on the PR that NAME is doing for issue (probably not touching these sections in your PR might be the best to minimize conflict, Brian, or I can push later to your branch - wanted to do this PR while I had the idea fresh in my head). I used as a placeholder.
The direction of this looks good. Thanks for putting together the PR! I made just a few cleanup type comments/suggestions. Some do touch on the terminology, but otherwise think I can avoid this section in the in-progress PR
I do think a document history bullet should be added - "Consolidate processing rules for Holder and Verifier"
As discussed on a recent call - merging this now and closing the associated issues. NAME intends to look at it in the main branch and propose additional changes in a new PR, if there are opportunities for improvement.
Code change:
facing edge might support HTTP/2 and HTTP/3 while communication to back end servers is done using HTTP/1.1.  Unlike with connection coalescing, the CDN will "de-mux" requests into discrete connections <del> to the back end.  As HTTP/1.1 and older do not provide a way to concurrently transmit multiple responses, there is no immediate fairness issue in protocol.  However, back end servers MAY still use client headers for request scheduling.  Back end servers SHOULD only schedule based on client priority information where that information can be scoped to individual end clients.  Authentication and other session information might provide this linkability. </del> <ins> to the back end.  HTTP/1.1 and older do not support response multiplexing in a single connection, so there is not a fairness problem.  However, back end servers MAY still use client headers for request scheduling.  Back end servers SHOULD only schedule based on client priority information where that information can be scoped to individual end clients.  Authentication and other session information might provide this linkability. </ins> 13.3.

Related discussion:
text: NAME noted a bunch of minor editorial issues, so this fixes them.
Thank you for working on the changes. They look like great improvements to me modulo the concern below.
Code change:
If the final response to the last request on a connection has been completely received and there remains additional data to read, a user agent MAY discard the remaining data or attempt to determine if that <del> data belongs as part of the prior response body, which might be the </del> <ins> data belongs as part of the prior message body, which might be the </ins> case if the prior message's Content-Length value is incorrect.  A client MUST NOT process, cache, or forward such extra data as a separate response, since such behavior would be vulnerable to cache

Related discussion:
text: I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?
Code change:
If the final response to the last request on a connection has been completely received and there remains additional data to read, a user agent MAY discard the remaining data or attempt to determine if that <del> data belongs as part of the prior response body, which might be the </del> <ins> data belongs as part of the prior message body, which might be the </ins> case if the prior message's Content-Length value is incorrect.  A client MUST NOT process, cache, or forward such extra data as a separate response, since such behavior would be vulnerable to cache

Related discussion:
text: This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.
Code change:
Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree. <del> At least one identifier for an identity document MUST be included in the protected header of the COSE Envelope, as one of "x5t" or "kid". Additionally, "x5chain" that corresponds to either "x5t" or "kid" identifying the leaf certificate in the included certification path MAY be included in the unprotected header of the COSE Envelope. </del> <ins> At least one identifier representing one credential MUST be included in the protected header of the COSE Envelope, as one of "x5t" or "kid".  Additionally, "x5chain" that corresponds to either "x5t" or "kid" identifying the leaf certificate in the included certification path MAY be included in the unprotected header of the COSE Envelope. </ins> When using x509, Support for "x5t" is mandatory to implement.

Related discussion:
text: Reason: Term was used only twice, not defined, and does not seem to play an important role. !
fiddled with a phrasing nit. This approval is not about the diagram picture, but the content of md that substitutes Identity Documents with URL
Code change:
3. <del> The priority scheme defined by this document considers only the prioritization of HTTP messages and tunnels, see client-scheduling, server-scheduling, and connect-scheduling. Where HTTP extensions change stream behavior or define new data carriage mechanisms, they can also define how this priority scheme can be applied. </del> <ins> The priority scheme defined by this document is primarily focused on the prioritization of HTTP response messages (see HTTP).  It defines new priority parameters (parameters) and their conveyors (header- field and frame) intended to communicate the priority of responses to a server that is responsible for prioritizing them. server-scheduling provides considerations for servers about acting on those signals in combination with other inputs and factors. The CONNECT method (see HTTP) can be used to establish tunnels. Signaling applies similarly to tunnels; additional considerations for server prioritization are given in connect-scheduling. client-scheduling describes how clients can optionally apply elements of this scheme locally to the request messages that they generate. Some forms of HTTP extensions might change HTTP/2 or HTTP/3 stream behavior or define new data carriage mechanisms.  Such extensions can define themselves how this priority scheme is to be applied. </ins> 4.

Related discussion:
text: Addressed Ea of Reference the HTTP terms we are using. Be clearer that we focus on "normal" responses and that there are other possible uses. But avoid making the entire document a piece of abstract art.
Code change:
Protected resources supporting metadata MUST make a JSON document containing metadata as specified in PRMetadata available at a path <del> formed by concatenating a well-known URI string such as "/.well- known/oauth-protected-resource" to the protected resource's resource identifier.  The syntax and semantics of ".well-known" are defined in RFC5785.  The well-known URI path suffix used MUST be registered in the IANA "Well-Known URIs" registry IANA.well-known. </del> <ins> formed by inserting a well-known URI string into the protected resource's resource identifier between the host component and the path component, if any.  By default, the well-known URI string used is "/.well-known/oauth-protected-resource".  The syntax and semantics of ".well-known" are defined in RFC5785.  The well-known URI path suffix used MUST be registered in the IANA "Well-Known URIs" registry IANA.well-known. </ins> Different applications utilizing OAuth protected resources in application-specific ways may define and register different well-

Related discussion:
text: As discussed during IETF 118.
The draft (and the examples in it) follow this language This means (taken from an example in the draft): This is inconsistent with RFC8414 (and its normative dependencies) which says This means (taken from an example in RFC8414): The RFC8414 way kind of hampers the ability to host these documents in multi-tenant system on certain deployments but i'm unsure if we can justify not doing it this way.
Thanks NAME this was the subject of my comments in . I do think that the way it's done in the draft currently makes sense for the context and is preferable. But it might raise some objections in IESG etc. review. I don't honestly know what the best course of action is. But wanted to bring it up earlier rather than later. Perhaps Roman's suggestion of asking the HTTP directorate for an early review in hope of avoiding surprise down the line?
The draft does say the following , which maybe provides sufficient justification. Maybe.
Code change:
Let param_value be the result of running Parsing a Bare Item (parse-bare-item) with input_string. <del> Append key param_name with value param_value to parameters. </del> <ins> Append key param_name with value param_value to parameters.  If parameters already contains a name param_name (comparing character-for-character), overwrite its value. </ins> Return parameters.

Related discussion:
text: NAME thanks for the review, see latest commit. is talking about the abstract model for dictionaries, so they are required to be unique. I've removed "required to be" so that people don't misread this.
allows a sender to generate multiple header fields with the same name, if the field is defined as a comma-separated list [i.e., #(values)], and that such duplicates are semantically equivalent to them concatenated into a single header field. I think that this property has been useful for us, when annotating header fields. Can we allow such duplicates for Structured Headers too, when a list or a dictionary is being used? Note that we have merged based on the assumption that it is okay to require the consumer of SH header fields to have the knowledge on what the top type is.
That's always been the intent; are you saying that we should have text specifically enabling this for serialisation of dictionaries and lists?
Good to know that that has been the intent. Yes, I think we should clarify that explicitly for dictionaries and lists, because RFC 7230 can be interpreted to allow duplicates only for those using notation (which we do not use in SH). Also, it might be a good idea to revisit the rule for duplicate dictionary values, as I'd assume that people would try to append a header field without checking the values that already exist. IMO, the rule should be that the dictionary element that appears later overwrites the one that precedes.
PTAL
NAME Thank you! cb76bf1 looks good to me. Is your intention to retain the forbidding of duplicate dictionary values, even when the dictionary members are split into different header fields? For example, in the hypothetical world where cache-control is sent using SH, all the cache-control directives in the following example would be considered invalid and ignored. I am not strongly opposed to that, though my weak preference goes to requiring decoders to use the dictionary member that appears later when there is a collision.
NAME the problem is that ignoring duplicates can cause security issues for some headers (the headers that WebAppSec in the W3C are particularly sensitive about this). The only way to address it would be to add a flag to the API to control what to do with dups -- but that adds complexity (more to specifications than to implementations, but still). I'm not crazy about that; what do others think?