jiebi/CodeConvo huggingface dataset:
Code change:
Reference: RFC1321, RFC4648, 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: RFC1321, RFC4648, 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: RFC1321, RFC4648, 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: RFC1321, RFC4648, 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:
There are two different modes of composing COSE protection and timestamping, motivated by the usage scenarios discussed above. <ins> The diagrams in this section illustrate the processing flow of the specified modes.  For simplicity, only the "COSE_Sign1" processing is shown.  Similar diagrams for "COSE_Sign" can be derived by allowing multiple "private-key" boxes and replacing the label "[signature]" with "[signatures]". </ins> 2.1. fig-timestamp-then-cose shows the case where a datum is first

Related discussion:
text: https://ietf-URL
NAME NAME please have a look
TSA is good enough
Code change:
This section marks the <del> header field registered in RFC7540 as obsoleted.  The registration is updated to include the details as required by HTTP: </del> <ins> header field registered in RFC7540 as obsoleted.  This capability has been removed: see versioning.  The registration is updated to include the details as required by HTTP: </ins> 11.6.

Related discussion:
text: The HTTP2-Settings header field and the h2c Upgrade token are both obsolete in the same way for the same reason, but it's rendered differently in their respective IANA sections. HTTP2-Settings is marked as Obsolete in the registry, with a reference back to the IANA Considerations of this document h2c gives no instructions to IANA, but includes explanatory text that the capability is removed and refers to Section 3.1. I would suggest that these should be aligned and combined, such that each one does two things: Instructs IANA to mark the entry as Obsolete Add a note that the element was used for Upgrade and reference Section 3.1 for more detail on Upgrade's removal
Code change:
Also, note that unsafe requests might invalidate already-stored responses; see invalidation. <ins> A response that is stored or storable can be used to satisfy multiple requests, provided that it is allowed to reuse that response for the requests in question.  This enables caches to "collapse" multiple incoming requests into a single forward request upon a cache miss, thereby reducing load on the origin server and network.  However, note that if the response returned is not able to be used for some or all of the collapsed requests, additional latency might be introduced, because they will need to be forwarded to be satisfied. </ins> When more than one suitable response is stored, a cache MUST use the most recent one (as determined by the

Related discussion:
text: We should really mention this, as it's common and can cause misunderstanding. I also am likely to need to reference it in .
Maybe add a minimal explanation of "collapse"?
Code change:
granularity for prioritizing responses for ordinary web browsing, at minimal complexity. <del> The value is encoded as an sh-integer.  The default value is 1. </del> <ins> The value is encoded as an sh-integer.  The default value is 3. </ins> This parameter indicates the sender's recommendation, based on the expectation that the server would transmit HTTP responses in the

Related discussion:
text: When we discussed removing the semantics of urgency levels, we also thought it would be a good idea to change the default from 1 to 3. We agreed to do this and landed a change that removed the semantic text but unfortunately forgot to also change the default. This change simple fixes the oversight.
See URL for background
Thank you for the fix!
Code change:
key or other structure, as appropriate.  It can be a non-root certificate when it is a certificate. <del> A provider of a Transparency Service is, however, expected to indicate what Registration Policy is used in a given deployment and inform its users about changes to the Registration Policy. 5.2.3. </del> <ins> 5.2.4. </ins> There are many different candidate verifiable data structures that may be used to implement an Append-only Log, such as chronological

Related discussion:
text: Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.
Code change:
2.1. <del> Clients control which Client Hints are sent in requests, based on their default settings, user configuration, and server preferences. The client and server can use an opt-in mechanism outlined below to negotiate which header fields need to be sent to allow for efficient content adaption, and optionally use additional mechanisms to negotiate delegation policies that control access of third parties to same header fields. </del> <ins> Clients choose what Client Hints to send in a request based on their default settings, user configuration, and server preferences expressed in "Accept-CH".  The client and server can use an opt-in mechanism outlined below to negotiate which header fields need to be sent to allow for efficient content adaption, and optionally use additional mechanisms to negotiate delegation policies that control access of third parties to same header fields. </ins> Implementers SHOULD be aware of the passive fingerprinting implications when implementing support for Client Hints, and follow

Related discussion:
text: LGTM! thx
Some of this is very nit-picky; feel free to do what you like with it... ^ There's something weird going on with tense in this sentence. "Such techniques are expensive... are not portable... and make it hard..." The third doesn't fit with the first two. "Client Hints mitigate the performance concerns..." probably just "Client Hints mitigate performance concerns..." Likewise for "the privacy concerns" below. "This document defines the Client Hints infrastructure, a framework that enables servers to opt-in to specific proactive content negotiation features, which will enable them to adapt their content accordingly." --> "This document defines Client Hints, a framework that enables servers to opt-in to specific proactive content negotiation features, adapting their content accordingly." as a normative reference probably isn't going to fly, given its status. Why is it normative? maybe instead: Be aware that HTTP doesn't require presence of when proactive conneg is in use; if the response is truly uncacheable, it isn't necessary. maybe instead: instead: BTW, nothing is said about precedence between the two different mechanisms; separate issue? The reference to 6454 is spurious, and it's pretty indirect. Perhaps: It's kind of weird to have this list just appear. Perhaps turn these into prose? Put "For example" above the example to introduce it. Limits CH to just "optimisation." Probably should just be:
Thanks for reviewing! :) PR underway The here is conditional on cacheability. Is that OK? We're now considering removing http-equiv support for this: URL Maybe it's best to simply remove that reference here?
Ah, I missed that, sorry. WRT http-equiv; that might be best, then.
Code change:
A successful response to a Txn-Token Request by a Transaction Token Service is called a Txn-Token Response.  If the Transaction Token Service responds with an error, the error response is as described in <del> Section 5.2 of RFC6749.  The following describes required values of a Txn-Token Response: </del> <ins> Section 5.2 of RFC6749.  The following values defined in RFC8693 MUST be included in the Txn-Token Response: </ins> The "token_type" value MUST be set to "N_A" per guidance in OAuth 2.0 Token Exchange

Related discussion:
text: Related to issue
Section 7.2 includes a "access_token", which is part of the token exchange protocol. RFC 8693 makes it clear that it des not need to be an OAuth token, but perhaps we can reference that this parameter is define in RFC 8693? Perhaps something like: "The following describes required values of the token exchange protocol as defined in RFC 8693 which must be included in the Txn-Token Response:" or "A successful response to a Txn-Token Request by a Transaction Token Service is called a Txn-Token Response. The Txn-Token Response is a profile of the token exchange response defined in RFC 8693. If the Transaction Token Service responds with an error, the error response is as described in Section 5.2 of RFC6749. The following describes required values of the token exchange protocol as defined in RFC 8693 which must be included in the Txn-Token Response:"
I'm not seeing access_token mentioned in section 7.2 other than implicitly when referencing the token types defined by 8693. Did you mean section 7.4? I'm fine with the first suggestion.
Yes, section 7.4.
I'm good with this
Code change:
inputs.  However, the canonicalized component value is never parsed by the message signature process, merely used as part of the signature base in create-sig-input.  Even so, caution needs to be <del> taken when including such fields in signatures, see security-non-list for more discussion of this issue. </del> <ins> taken when including such fields in signatures, and the "bs" parameter defined in http-header-byte-sequence provides a method for wrapping such problematic fields.  See security-non-list for more discussion of this issue. </ins> If the combined value is not available for a given header, the following algorithm will produce canonicalized results for an

Related discussion:
text: This adds a binary wrapper for fields that don't follow the List or Dictionary format for multiple values, such as Set-Cookie. The wrapper is selected using the parameter, and the component value is made by wrapping each individual field value in a Byte Sequence and putting them into a List, then doing a strict serialization on those values.
In general, is this even needed or are we over-engineering here? If the main use case is , do we think it is likely to be signed?
Some fields, like , have an internal syntax that allows unquoted commas and messes things up when multiple lines are combined for the signature base, leading to the potential case where two semantically different inputs have the same signature base. This means that: And: Both produce the same signature input line: Even though the two-line and single-line versions are processed differently by the application. To counter this, we could have a distinct encoding flag that wraps the field values, similar to . This can be used to protect problematic fields like Set-Cookie so that we get something like this for the multiple line version: But you'd get this for the single-line version: The background of this has been discussed in and
Code change:
7.1.  URIs <del> [1] https://openjdk.java.net/groups/net/httpclient/intro.html </del> <ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [2] https://httpwg.org/ [3] https://github.com/httpwg/http-extensions/labels/signatures [4] https://openjdk.java.net/groups/net/httpclient/intro.html </ins> <del> [2] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ </del> <ins> [5] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ </ins> V1_chap04.html#tag_04_16

Related discussion:
text: This removes the in-document "issues" list and background introduction note paragraph, in line with the document's status as a working group draft backed with an issue tracker. All removed items should have corresponding issues tagged with in this repository's issue tracker (some have already been closed), so keeping them in the document was redundant and artificially inflated the page count.
NAME good idea, note added to the top, following the pattern in other drafts
LGTM. You might want to add a note at the top directing folks to the issues list, etc.; see other drafts.
Code change:
This example shows the catalog for a media producer that is outputting two streaming formats simultaneously under different namespaces.  Note that each track name referenced points at another <del> catalog object. </del> <ins> catalog object and that only the first catalog supports incremental delta updates. </ins> 4.

Related discussion:
text: by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.
Code change:
other than specified. Applications that use HTTP in a manner that involves modification of <del> implementations - for example, requiring support for a new URL </del> <ins> implementations - for example, requiring support for a new URI </ins> scheme, or a non-standard method - risk having those implementations "fork" from their parent HTTP implementations, with the possible result that they do not benefit from patches and other security

Related discussion:
text: This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL
Code change:
10.3. The security model that conceals the plaintext claims relies on the <del> fact that salts not revealed to an attacker cannot be learned or guessed by the attacker, even if other salts have been revealed.  It is vitally important to adhere to this principle.  As such, each salt MUST be created in such a manner that it is cryptographically random, long enough, and has high entropy that it is not practical for the attacker to guess.  A new salt MUST be chosen for each claim independently from other salts.  See Randomness Requirements for </del> <ins> high entropy random data of the salt as additional input to the hash function.  The randomness ensures that the same plaintext claim value does not produce the same digest value.  It also makes it infeasible to guess the preimage of the digest (thereby learning the plaintext claim value) by enumerating the potential value space for a claim into the hash function to search for a matching digest value.  It is therefore vitally important that unrevealed salts cannot be learned or guessed, even if other salts have been revealed.  As such, each salt MUST be created in such a manner that it is cryptographically random, sufficiently long, and has high enough entropy that it is infeasible to guess.  A new salt MUST be chosen for each claim independently of other salts.  See Randomness Requirements for </ins> Security RFC4086 for considerations on generating random values. <del> 10.4. </del> The RECOMMENDED minimum length of the randomly-generated portion of the salt is 128 bits.

Related discussion:
text: Attempt to better explain how salt in the Disclosure makes guessing the preimage of the digest infeasible Consolidate salt entropy and length security consideration subsections
question from an email, my response: The exchange makes me think a brief mention/explanation what salt does/provides in the SD-JWT context would be a worthwhile addition. Maybe just add or modify a sentence or two in sec 10.3. And/or something in URL where the salt value in the Disclosure is introduced/described.
Hi Brian, just check for understanding: does the issuer send the clear text values of the disclosed claims to the holder and verifier or does the issuer only send the salted hashes? +------------+ +------------+ | Issues SD-JWT including all Disclosures | v +------------+ +------------+ | Presents SD-JWT including selected Disclosures | v +-------------+ + + +-------------+ +-------------+| +-------------+
I'm sorry but I don't quite understand the question or how it relates to the small change I'm suggesting in this issue.
FYI, I was asked what the salt does by an IETF attendee yesterday. I support explaining this in the draft.
PR has some proposed text