jiebi/CodeConvo huggingface dataset:
Code change:
how trailer field values can be safely merged. The presence of the keyword "trailers" in the TE header field <del> (field.te) indicates that the client is willing to accept trailer fields, on behalf of itself and any downstream clients.  For requests from an intermediary, this implies that all downstream clients are willing to accept trailer fields in the forwarded response.  Note that the presence of "trailers" does not mean that the client(s) will process any particular trailer field in the response; only that the trailer section(s) will not be dropped by any of the clients. </del> <ins> (field.te) of a request indicates that the client is willing to accept trailer fields, on behalf of itself and any downstream clients.  For requests from an intermediary, this implies that all downstream clients are willing to accept trailer fields in the forwarded response.  Note that the presence of "trailers" does not mean that the client(s) will process any particular trailer field in the response; only that the trailer section(s) will not be dropped by any of the clients. </ins> Because of the potential for trailer fields to be discarded in transit, a server SHOULD NOT generate trailer fields that it believes

Related discussion:
text: I know that this is pretty obvious and implied, but maybe it's worth saying.
maybe just s/TE header field/TE request header field/?
Code change:
header parameter MUST be used for the mode described in sec- timestamp-then-cose. <del> The "3161-ttc" protected header is defined as follows: Name: 3161-ttc Label: TBD Value Type: bstr Value Registry: Description: RFC 3161 timestamp token Reference: sec-tst-hdr-ttc of RFCthis The content of the byte string are the bytes of the DER-encoded RFC 3161 TimeStampToken structure. </del> <ins> The "3161-ttc" protected header parameter contains a DER-encoded RFC3161 TimeStampToken wrapped in a CBOR byte string (Major type 2). </ins> 3.2.

Related discussion:
text: and have pointed out that the current registration requests are rather informal and could be improved using the templates in . All, I have performed a read through of the doc. A few minor language preferences for clarity have been suggested here: URL Otherwise, I was able to implement and test both modes of operation and get the desired results (with stand in labels). That indicates to me that the draft is well formed, concise, and references the other specifications appropriately that I needed to reference. I find this document useful, and we would implement and utilize in production, and support moving this forward. Two minor additional nits below: One question for the group / authors - is there a preferred set of values for the TBDs in the COSE labels section, or should that just be left as is for now? An additional style question, is it better to restate the COSE headers requested in the IANA requested format, or is it fine to reference as is done in the draft currently? e.g. current draft reads: "IANA is requested to add the two COSE header parameters described in Section 3 to the "COSE Header Parameters" subregistry of the [URL] registry." This could obviously be detailed out. Mike Prorock On Tue, Aug 13, 2024 at 11:43 AM Michael Prorock wrote:
Answering Mike P.’s question about IANA registrations, it is strongly preferred to have the IANA Considerations section follow the registration template and contain the exact values to be placed in the registry (with the Label of course, being TBD). An example of such IANA Considerations text is URL Please update the draft to add this content. Thanks, -- Mike From: Michael Prorock Sent: Friday, August 23, 2024 5:40 AM To: Michael Prorock Cc: Michael Jones ; cose Subject: Re: [COSE] Re: WGLC for draft-ietf-cose-tsa-tst-header-parameter All, I have performed a read through of the doc. A few minor language preferences for clarity have been suggested here: URL Otherwise, I was able to implement and test both modes of operation and get the desired results (with stand in labels).
Code change:
header parameter MUST be used for the mode described in sec- timestamp-then-cose. <del> The "3161-ttc" protected header is defined as follows: Name: 3161-ttc Label: TBD Value Type: bstr Value Registry: Description: RFC 3161 timestamp token Reference: sec-tst-hdr-ttc of RFCthis The content of the byte string are the bytes of the DER-encoded RFC 3161 TimeStampToken structure. </del> <ins> The "3161-ttc" protected header parameter contains a DER-encoded RFC3161 TimeStampToken wrapped in a CBOR byte string (Major type 2). </ins> 3.2.

Related discussion:
text: That indicates to me that the draft is well formed, concise, and references the other specifications appropriately that I needed to reference. I find this document useful, and we would implement and utilize in production, and support moving this forward. Two minor additional nits below: One question for the group / authors - is there a preferred set of values for the TBDs in the COSE labels section, or should that just be left as is for now? An additional style question, is it better to restate the COSE headers requested in the IANA requested format, or is it fine to reference as is done in the draft currently? e.g. current draft reads: "IANA is requested to add the two COSE header parameters described in Section 3 to the "COSE Header Parameters" subregistry of the [URL] registry." This could obviously be detailed out. Mike Prorock On Tue, Aug 13, 2024 at 11:43 AM Michael Prorock > wrote: Thanks for the additional time Mike and Ivo. I support moving this along, but I would like to perform a detailed read through. I have some time set aside for this and will have comments back next week. Mike Prorock founder - URL Ivo and I reviewed the results of the WGLC and there have been no responses whatsoever – even from the authors. We are therefore extending the WGLC for another two weeks until Tuesday, August 27th. Unless multiple people support progressing the draft, we will not request publication. Please send your reviews and feedback on the draft. Thank you, -- Mike and Ivo From: Michael Jones > Sent: Tuesday, July 30, 2024 10:53 AM To: EMAIL Subject: [COSE] WGLC for draft-ietf-cose-tsa-tst-header-parameter Hi all, This message starts the Working Group Last Call (WGLC) for URL The WGLC will run for two weeks, ending on Tuesday, August 13, 2024. Please review and send any comments or feedback to the working group. Even if your feedback is “this is ready for publication”, please let us know. Thank you, -- Mike and Ivaylo, COSE Chairs COSE mailing list -- EMAIL To unsubscribe send an email to EMAIL
Code change:
6. <del> The MD5 algorithm is NOT RECOMMENDED as it's now vulnerable to </del> <ins> The MD5 algorithm MUST NOT be used as it's now vulnerable to </ins> collision attacks CMU-836068. The SHA algorithm is NOT RECOMMENDED as it's now vulnerable to

Related discussion:
text: States that MUST NOT be used. Sets the MD5 status to deprecated.
Looks good, thanks!
Code change:
Status: As specified in algorithms. <del> 9.7. </del> <ins> 9.8. </ins> The status of "MD5" has been updated to "deprecated", and its description states that this algoritm MUST NOT be used.

Related discussion:
text: Obsolete ADLER-32 but don't forbid it.
NAME will this work for you?
I think the pull request is OK as-is, but might be improved slightly. In particularly, I'm wondering if SHOULD NOT is too strong for the server. A server could support ADLER32 without that support impacting on cryptographic data integrity provided that server also supports a cryptographically secure hash; e.g., SHA-512. Clients that wish to protect against malicious actor changes would use the SHA-512 hash and not request (or ignore) the ADLER32 value. Therefore, I would suggest that, for the server, the document says a server MAY implement ADLER32. I think it is perfectly reasonable for the document to say the client SHOULD NOT use ADLER32, for the reasons stated. That said, I can't decide if this distinction is really helpful, so I defer to your judgement, here.
I'm not so sure we want to make a distinction between client and server as you write it. Both client and server can attach Digest header to request or response. It is the receiver of Digest that is exposed to the risk of using a weak digest. The current language avoids mentioning either endpoint so we leave it to implementers. I'm not opposed to spelling things out more clearly but we'd really need to nail down what we mean by "using Digest algorithms" because that relates to requesting them, generating them, regenerating them (proxy), validating them (endpoint or proxy) etc.
That's a good point about client/server. Sorry, I had that wrong. As you say, it's the recipient of a Digest that must decide whether the algorithm is sufficient. This recipient may be either the client or the server. I think the document is right to point out the dangers of accepting a weak digest. Perhaps there is a useful distinction between generating a digest and accepting a digest; e.g., an agent MAY support generating a weak digest but SHOULD NOT accept a weak digest.
Not wrong, just partially true. That could work for me. I'll leave it to NAME to decide what he things makes sense to do.
NAME NAME as this issue is for ADLER, I moved the discussion to As it's in the listed algorithms, the server MAY already implement ADLER32, though it SHOULD NOT be used by both sides of the communication. I think sender and receiver should behave consistently (see again).
Merging as for the positive feedback from NAME and NAME comment URL
Code change:
5.2.2.1. <del> A standard under development as part of the Financial-grade API (FAPI) family of standards that allows a device or service (e.g., a personal computer, Smart TV, Kiosk) to request the OpenID Provider to initiate an authentication flow if it knows a valid identifier for the user.  The user completes the authentication flow using a second device (e.g., a mobile phone).  In this flow the user does not scan a QR code or obtain a user code from the initiating device. </del> <ins> Client Initiated Back-Channel Authentication (CIBA) CIBA: A standard developed in the OpenID Foundation that allows a device or service (e.g., a personal computer, Smart TV, Kiosk) to request the OpenID Provider to initiate an authentication flow if it knows a valid identifier for the user.  The user completes the authentication flow using a second device (e.g., a mobile phone).  In this flow the user does not scan a QR code or obtain a user code from the initiating device, but is instead contacted by the OpenID Provider to complete the authentication using a push notification, e-mail, text message or any other suitable mechanism. </ins> 5.2.2.2.

Related discussion:
text: Added clarification that CIBA is not a standard under development, but was completed in September 2021 and added references to the completed standard.
Refer back to issue
Thanks for that bit of historic context Brian. I will remove those references.
Thanks NAME and NAME - I also added you to the acknowledgment section.
Code change:
Issuers that chose to blind claim names MUST ensure not to inadvertently leak information about the blinded claim names to verifiers.  In particular, issuers MUST choose placeholder claim <del> names accordingly.  It is RECOMMENDED to use cryptographically random values with at least 128 bits of entropy as placeholder claim names. </del> <ins> names accordingly. It is RECOMMENDED to use cryptographically random values with at least 128 bits of entropy as placeholder claim names. </ins> The order of elements in JSON-encoded objects is not relevant to applications, but the order may reveal information about the blinded

Related discussion:
text: added HMAC algorithm to supported identifiers replaced with to enable random value being a cryptographic key
NAME ready from my side
Looks good, I just had a few nitpicks here and there.
resolve conflicts, change to sddigestderivation_alg check if renders correctly...
Verbal approval from NAME
NAME sorry for the late revision it seems that here we have merge conflicts exposed URL
thanks! yes, fixed them in a PR that was merged
Code change:
straightforward as connecting a new host to the same infrastructure network. <ins> Stub routers can be attached to any network.  However, there are network configurations where a stub router will not work.  An analysis of networks where stub routers could be attached is provided in net-analysis. </ins> 2. 3.

Related discussion:
text: NAME The new sections need to go in just after all the "", otherwise the XML doesn't build (order is fixed).
Question on the cases included: isn't there a case possible where network is managed and is IPv6 only DHCPv6 addressing is used (as intended by operator) - assume DHCPv6 hands out ULA addresses no RA-Guard is applied user brings stub router, plugs it in, and it advertises a ULA prefix in PIO other devices on the link start configuring a SLAAC IPv6 address and try to use this to communicate (and routing fails because the DHCP managed ULA was not used as the source, but rather the SLAAC based ULA) But maybe this is not relevant because the source address selection algorithm would always pick the correct, managed ULA due to a better prefix match with the IPv6 destination address ?
Regarding the DHCPv6-only use case, we are assuming that the network operator wants to control which devices have addresses on the local link. In this case, they MUST use RA Guard. If they do not, then there is no protection against random devices sending RAs. So this would be a misconfiguration, and hence we don't need to do anything about it.
NAME Right, I also agree we don't have to do anything about solving this "problem" other than pointing to RA guard. But still I think it's worth mentioning: it's the one identified corner case where the SNAC router has unwanted side effects. I wasn't even sure if I was correct in predicting the effects. Considering that there is I think no other IETF-specified / IETF-compliant device that, when plugged in, would instantly disrupt this network in the way that the stub router does. If this is the worst case we can find, it should actually show that our stub router is good to go.
During email discussion in 2023, there were worries that placing a SNAC stub router in a network (with its default configurations) would disturb / harm the existing network / AIL. For example due to the advertising of extra prefixes, or advertising particular (deviating?) values of bits, routes or time-durations in the RA. One proposed solution was to provide a taxonomy (e.g.
Code change:
straightforward as connecting a new host to the same infrastructure network. <ins> Stub routers can be attached to any network.  However, there are network configurations where a stub router will not work.  An analysis of networks where stub routers could be attached is provided in net-analysis. </ins> 2. 3.

Related discussion:
text: an appendix) that explains which particular topologies/configurations a SNAC stub router can work, and in which ones it doesn't work, and in which ones it can cause malfunctions (if any). Some examples: stub router doesn't work in a network that has RA-guard in a network without RA guard, and where no suitable prefix is advertised on AIL, stub router can "disrupt" by advertising its ULA prefix. In this case we assume the ULA prefix is not intended by the admin. (Maybe the admin and/or network users should know better here, but anyhow it's a possibility.) Having a better overview of success/fail cases also helps reviewers of the document to judge the risk. FYI here's a pointer to one of the messages in the thread of 2023 that summarizes some cases and how it could be documented: URL
PR resolves this issue.
In -04, "'L' bit is set" is required for a suitable prefix. However section 5.1.2.3 allows sending PIO with L flag cleared, in particular cases. This leads to the issue that the generated PIO AIL prefix won't be recognized as a "suitable prefix" by other stub routers. So the requirement "'L' bit is set" must be relaxed for particular link layer technologies where L=0. Taking one step back – I just tried to summarize SNAC stub router scenario archetypes; both good and bad. Of the below it seems that only scenario 4 is now discussed as having a risk of breaking the network, correct? 1) Non-expert home user connects stub router to own unmanaged home network; it magically works and provides IPv6 stub/AIL routing – no matter whether user’s ISP offers IPv6 or not.
Code change:
straightforward as connecting a new host to the same infrastructure network. <ins> Stub routers can be attached to any network.  However, there are network configurations where a stub router will not work.  An analysis of networks where stub routers could be attached is provided in net-analysis. </ins> 2. 3.

Related discussion:
text: 2) Ignorant employee brings stub router to work and plugs it into well-managed network; companies’ IT network magically protects the network from ill effects (RA guard, and/or port-based access control, … ) 3) Ignorant employee brings stub router to work and plugs it into unmanaged (IPv6) network; nothing bad happens - there’s already a PIO prefix with ‘A’ on the AIL 4) Ignorant employee brings stub router to work and plugs it into not-so-well managed DHCPv6-only network; stub router sends RA PIO; many hosts on the link now autoconfigure a ULA which somehow breaks connectivity for these existing hosts. 5) Ignorant network admin connects stub router to company network without changing the default settings; then it becomes similar to 4. This case is btw probably out of our scope to solve and could be solved by the mantra “don’t do that then”. (The stub router is only intended for case 1, but of course the stub router cannot tell apart cases 1,4,5.) +1 on clearly defining the possible breakage scenarios. E.g. some devices may not configure multiple addresses and get stuck with a ULA only? Or known issues with source address selection; IPv4 interactions, etc. in presence of ULAs. When doing this the Type A, B and C IPv6 hosts may also be considered. If we find no issues then we may also state this in the draft in an Appendix – what was considered, and why it isn’t a problem. Esko From: Lorenzo Colitti Sent: Friday, September 8, 2023 11:38 To: Ole Trøan Cc: Lorenzo Colitti ; Ted Lemon ; Juliusz Chroboczek ; Esko Dijk ; Michael Richardson ; Handa Wang ; EMAIL Subject: Re: [Snac] Should a stub router learn RA header parameters from other routers? I am not OK with a SNAC router connecting to an existing IPv6 network and breaking it. If you can elaborate on the type of breakage you are concerned about, then we can discuss it and possibly design for it. FWIW, just the fact of the hosts getting new addresses does not qualify as breakage IMO. All IPv6 hosts have multiple addresses and source address selection generally gets hosts to do the right thing.
Code change:
Automatically Connecting Stub Networks to Unmanaged Infrastructure <del> draft-ietf-snac-simple-04 </del> <ins> draft-ietf-snac-simple-05 </ins> Abstract

Related discussion:
text: Update draft version "stub router flag" -> SNAC router flag fix a few cases where Esko (I think!) missed changing stub router to SNAC router but should have (there are some cases where "stub router" is correct and I hope I did not change any of those.
In the update to the 'SNAC router' name () the flag name was not yet taken along in the update. This issue is to decide on that change also, and if needed make the change. (The 6man document would also need to change the flag name then, first.)
Code change:
key as described above and the claim name in <del> MUST be replaced by a placeholder value that does not leak information about the claim's original name.  The same placeholder value is to be used in the II-Disclosures and HS-Disclosures described below. </del> <ins> MUST be replaced by a placeholder name that does not leak information about the claim's original name.  The same placeholder name will be used in the II-Disclosures ( ) and HS-Disclosures ( ) described below. To this end, the issuer MUST choose a random placeholder name for each claim that is to be blinded.  It is RECOMMENDED to do so by base64url-encoding a cryptographically secure nonce.  See blinding- claim-names for further requirements. </ins> 5.2.1.1.

Related discussion:
text: Addresses Issue
I also revisited the security recommendations for the salt and made some smaller changes there.
user has 2 SD-JWTs from the same issuer, same blinded claim names can be used to correlate the user. advice to have a fresh blinded claim name for each credential.
Instead of opening a new issue from our conversation this morning - here is the excerpt & suggestion from the document we discussed: First off, maybe it's informational or maybe it's specified - issuers should not include "secrets" in claim labels. If a label for something is actually a secret, it should be treated as such. That said, I get that this scenario must be addressed. Sensitive predicates or graduated disclosure contexts can benefit from this capability. It seems to me that the most useful and easy algorithm to implement is to use the same hash algorithm + salt for the node value to blind the label where: SALTED LABEL = HASHALGO(LABEL + SALT) Of course, this assumes that specific guidance is included for best practice salt generation (fresh entropy gathering for each attribute block salt, sufficient bits of entropy, etc.) for strong cryptographic outcomes. In this representation, the salted hash of the label's value ("name") "9-J2445ap91..." can be addressed directly by the digest "h" value in compact form: Side-note: Informative statements that recommend large sd-jwt claim sets should be 'broken down' into much smaller sets, or individual claims, then wrapped and sealed as a JWP may be better than including too many claims in an sd-jwt.
Right now, it is RECOMMENDED that a random string is chosen for the blinded claim name. HMAC(salt, claim-name) and HASHALGO(LABEL + SALT) would be fine as well, but there's more room for errors, especially as holders/verifiers might expect a specific format and then reject an SD-JWT when, e.g., the issuer chose a wrong encoding or similar. I don't see a real advantage of using HMAC/HASHALGO for the blinded claim name. I therefore propose to stick with the current recommendation. We should stress that a fresh random value must be chosen for each claim in each issued credential.