jiebi/CodeConvo huggingface dataset:
Code change:
Reference: UNIX, this document. <del> Status: deprecated </del> <ins> Status: insecure </ins>

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:
Reference: UNIX, this document. <del> Status: deprecated </del> <ins> Status: insecure </ins>

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:
Reference: UNIX, this document. <del> Status: deprecated </del> <ins> Status: insecure </ins>

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:
Reference: UNIX, this document. <del> Status: deprecated </del> <ins> Status: insecure </ins>

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:
Change Controller: IETF <del> Specification Document(s): referenced-token-jwt of this </del> <ins> Specification Document(s): referenced-token-jose of this </ins> specification 14.3.

Related discussion:
text: Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho
Code change:
The Domain attribute specifies those hosts to which the cookie will be sent.  For example, if the value of the Domain attribute is <del> "example.com", the user agent will include the cookie in the Cookie header when making HTTP requests to example.com, www.example.com, and www.corp.example.com.  (Note that a leading %x2E ("."), if present, is ignored even though that character is not permitted, but a trailing %x2E ("."), if present, will cause the user agent to ignore the attribute.)  If the server omits the Domain attribute, the user agent will return the cookie only to the origin server. </del> <ins> "site.example", the user agent will include the cookie in the Cookie header when making HTTP requests to site.example, www.site.example, and www.corp.site.example.  (Note that a leading %x2E ("."), if present, is ignored even though that character is not permitted, but a trailing %x2E ("."), if present, will cause the user agent to ignore the attribute.)  If the server omits the Domain attribute, the user agent will return the cookie only to the origin server. </ins> WARNING: Some existing user agents treat an absent Domain attribute as if the Domain attribute were present and contained the current <del> host name.  For example, if example.com returns a Set-Cookie header </del> <ins> host name.  For example, if site.example returns a Set-Cookie header </ins> without a Domain attribute, these user agents will erroneously send <del> the cookie to www.example.com as well. </del> <ins> the cookie to www.site.example as well. </ins> The user agent will reject cookies unless the Domain attribute specifies a scope for the cookie that would include the origin server.  For example, the user agent will accept a cookie with a <del> Domain attribute of "example.com" or of "foo.example.com" from foo.example.com, but the user agent will not accept a cookie with a Domain attribute of "bar.example.com" or of "baz.foo.example.com". </del> <ins> Domain attribute of "site.example" or of "foo.site.example" from foo.site.example, but the user agent will not accept a cookie with a Domain attribute of "bar.site.example" or of "baz.foo.site.example". </ins> NOTE: For security reasons, many user agents are configured to reject Domain attributes that correspond to "public suffixes".  For example,

Related discussion:
text: This patch replaces with , and corrects inadvertant usage of non-example domains in the hopes of avoiding confusion. Closes httpwg/http-extensions.
NAME mind taking a look?
Landing this. NAME if you object, let me know.
There are still com TLD remaining: and
is real domain. (currently not owned) seems better to use example domain in rfc.
Should we use the .example TLD or stay with URL It's easier to contextualize with .example, in this case webmail.example and projects.example.
SGTM in projects.example, webmail.example etc also URL are fine too.
Code change:
instead of including a separate Key Binding JWT in the SD-JWT. The following non-normative example shows an SD-JWT Presentation <del> enveloped in a JWT payload: </del> <ins> enveloped in a JWT: </ins> Here, the SD-JWT is shown as the value of an

Related discussion:
text: first pass at addressing Issue and .
Does this touch all the mentions of random in URL and convey what the feedback was looking for? I'm honestly not sure. But I also think it doesn't really need changes in that area so I'm not too worried about it. So why am I writing this note? Good question. Just trying to "contribute" I guess.
Approved with the proposed changes.
Code change:
Each algorithm has a status field, which is intended to provide an aid to implementation selection. <del> Algorithms with a status value of "standard" are suitable for many </del> <ins> Algorithms with a status value of "Active" are suitable for many </ins> purposes and it is RECOMMENDED that applications use these algorithms.  These can be used in adversarial situations where hash functions might need to provide resistance to collision, first- preimage and second-preimage attacks.  For adversarial situations, <del> selecting which of the "standard" algorithms are acceptable will depend on the level of protection the circumstances demand.  More </del> <ins> selecting which of the "Active" algorithms are acceptable will depend on the level of protection the circumstances demand.  More </ins> considerations are presented in sec-agility. <del> Algorithms with a status value of "insecure" either provide none of </del> <ins> Algorithms with a status value of "Deprecated" either provide none of </ins> these properties, or are known to be weak (see NO-MD5 and NO-SHA). These algorithms MAY be used to preserve integrity against corruption, but MUST NOT be used in a potentially adversarial

Related discussion:
text: During the SEC AD review, a DISCUSS was raised about the current status values. This change modifies the values to better align with Signatures. The guidance for registration and/or usage of an algorithm based on the status is not affected.
Code change:
registered in the HTTP Signatures Specialty Content Identifier Registry. (content-registry) <del> 2.4.1. </del> <ins> 2.3.1. </ins> The request target endpoint, consisting of the request method and the path and query of the effective request URI, is identified by the

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:
For each member mem of input_plist: <del> Let id be the result of applying Serializing a Token (ser- token) to mem's token. </del> <ins> Let item be the result of applying Serializing an item (ser- item) to mem's primary-item. </ins> <del> Append id to output. </del> <ins> Append item to output. </ins> For each parameter in mem's parameters:

Related discussion:
text: in , NAME asks about having Parameterised Lists whose parameterised identifiers are things other than Tokens. Because of the way SH is put together, I think this would be a fairly easy change, in terms of the spec and implementations; it would require a few more tests. The only downside I can think of immediately is that specs would need to constrain the type of the parameterised identifier themselves, and specify error handling (if it weren't the default "blow up"). Thoughts? I also wonder if we should come up with a better name than "parameterised identifier", especially since we've ditched "identifier" elsewhere. member name? member id? primary identifier?
That works, since splitting lists from parameterised lists. Are you thinking , or just adding a few types? It also changes my thinking a tiny bit on , although not much. I like "parameterised element" but that introduces a new word. "parameterised item" is a nice shade, if any item is allowed there, but "primary identifier" works too. :art: :paintbrush:
The downside here is that it would be very hard to represent in JSON -- e.g., in the . At least some programming languages support hashes/dictionaries/objects with arbitrary key types (e.g., Python, JavaScript, Ruby), but I'm not sure how widespread that is -- especially if folks represent the different between and with an object for . NAME is this a nice-to-have or something that's a blocker?
(Fwiw I do think we should call this a Parameterised Token)
At this point do we just have to accept that the SH data model is essentially a subset of the JavaScript model? Numbers are bounded by JavaScript's limitations, object keys have to be stringy, nobody likes 'token' because it isn't a native JS type... I don't mind if that's the case, but it would be good to just say it outright somewhere. It would also give us a solid position to start from when considering other proposals. Hmm, C++ and Go could be have issues mixing key types within a single map, and Perl is definitely not going to like non-string keys.
It doesn't have to be -- it's just easier for me to write tests this way :)
This was a nice-to-have for me. I’d worked around it by putting an unused string as the identifier. It looks like that workaround is no longer necessary?
Code change:
2. <del> This document applies to proposed congestion control algorithms that seek Experimental or Standards Track status.  Evaluation of both cases involves the same questions, but with different expectations for both the answers and the degree of certainty of the answers. Congestion control algorithms without experience of Internet-scale deployment SHOULD seek Experimental status until real-world data is able to answer the questions in general-use.  Congestion control </del> <ins> This document applies to proposed congestion control algorithms proposals that seek Experimental or Standards Track status. Evaluation of both cases involves the same questions, but with different expectations for both the answers and the degree of certainty of the answers. Congestion control algorithms without empirical evidence of Internet- scale deployment SHOULD seek Experimental status.  Congestion control </ins> algorithms with a record of measured Internet-scale deployment MAY <del> directly seek the Standards Track if the community believes it is safe, and the design is stable, guided by the considerations in general-use.  The existence of this data does not waive the other considerations in this document. </del> <ins> directly seek the Standards Track if there is solid data that reflects that it is safe, and the design is stable, guided by the considerations in general-use.  However, the existence of this data does not waive the other considerations in this document. </ins> Experimental specifications SHOULD NOT be deployed as a default. They SHOULD only be deployed in situations where they are being <del> actively measured, and where it is possible to deactivate if there are signs of pathological behavior. </del> <ins> actively measured, and where it is possible to deactivate them if there are signs of pathological behavior. </ins> Each published congestion control algorithm is REQUIRED to include a statement in the abstract indicating whether or not there is IETF

Related discussion:
text: Make it clear this is about guidelines for authors, not status of this document avoid redundant guidance avoid "subjective" guidance such as "believes"
thanks
Code change:
sending a payload body on a DELETE request might cause some existing implementations to reject the request. <del> Responses to the DELETE method are not cacheable.  If a DELETE request passes through a cache that has one or more stored responses for the effective request URI, those stored responses will be invalidated (see invalidation). </del> <ins> Responses to the DELETE method are not cacheable.  If a successful DELETE request passes through a cache that has one or more stored responses for the effective request URI, those stored responses will be invalidated (see invalidation). </ins> 7.3.6.

Related discussion:
text: I think this is ready.
I think the registry is supposed to reference the obsolete spec where it was last defined, not the spec that mentions it briefly in a change note. In this case, it should be referring to RFC2616 Section 14.15.
NAME - I think the IANA registry should point to both - pull request updated.
Code change:
The payload of a PRIORITY frame contains a single reserved bit and a 31-bit priority. <del> The PRIORITY frame does not define any type-specific flags. </del> <ins> The PRIORITY frame does not define any flags. </ins> The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the

Related discussion:
text: Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.
Code change:
correctly enabled.  The requested URL is the root path of the TIPS view, appended with "push", as shown below. <del> The server returns an JSON object with content type "application/ alto-tipsparams+json".  The response MUST include only one field "server-push".  If the server push is enabled, the value of the "server-push" field MUST be the JSONBool value "true" (without the quote marks), and otherwise JSONBool value "false" (without the quote marks). </del> <ins> The server returns a JSON object with content type "application/alto- tipsparams+json".  The response MUST include only one field "server- push".  If the server push is enabled, the value of the "server-push" field MUST be the JSONBool value "true" (without the quote marks), and otherwise JSONBool value "false" (without the quote marks). </ins> 8.1.3.

Related discussion:
text: Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.
Code change:
whitespace, while names and values are separated by "=" (without whitespace).  For example: <ins> Members whose value is Boolean true MUST omit that value when serialised, unless it has parameters.  For example, here both "b" and "c" are true, but "c"'s value is serialised because it has parameters: Note that this requirement is only on serialisation; parsers are still required to correctly handle the true value when it appears in dictionary values. </ins> A dictionary with a member whose value is an inner-list of tokens: A dictionary with a mix of singular and list values, some with

Related discussion:
text: For . Note that this makes missing values ; if we like that approach, I think we should do it for missing parameter values too (currently they use , which isn't part of our type system). I used because it aligns with the semantics of current uses nicely.
OK with me.
NAME This is a keen observation. Assuming that we are fine with requiring that knowledge on what the top type is, maybe we should also consider adding support for rule. It has been my understanding that the only reason we do not support rule in SH is because can only be applied for certain top types (but we are now requiring that knowledge).
We've discussed requiring knowledge of top-level types extensively, and I think we have agreement that it's OK. I"m not sure what you want regarding support for ; can you give an example (or open a new issue)?
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. A number of headers are failing because they have valueless dictionary members; e.g., , , . It should be pretty easy to accommodate these, as we already have optional values on parameters.
PTAL at the PR, especially the note about using True for missing parameter values.
Ping NAME NAME
Seems like a reasonable change. I'm happy to remove the 'null' from parameters too.
(already OK'ed in the PR)
Code change:
whitespace, while names and values are separated by "=" (without whitespace).  For example: <ins> Members whose value is Boolean true MUST omit that value when serialised, unless it has parameters.  For example, here both "b" and "c" are true, but "c"'s value is serialised because it has parameters: Note that this requirement is only on serialisation; parsers are still required to correctly handle the true value when it appears in dictionary values. </ins> A dictionary with a member whose value is an inner-list of tokens: A dictionary with a mix of singular and list values, some with

Related discussion:
text: I'm really not sure what happened there, but don't have time to investigate. I suspect GitHub didn't actually merge.