jiebi/CodeConvo huggingface dataset:
Code change:
recommendations can be found in the OWASP SSRF Prevention Cheat Sheet OWASP.SSRF. <del> 7.7. </del> <ins> 7.8. </ins> This specification may be deployed in a scenario where the desired HTTP resource is identified by a user-selected URL.  If this resource

Related discussion:
text: The security concern is when there are two separate RSs with different sets of scopes, it shouldn't be possible for RS1 to tell the client to ask for scopes for RS2, and then have RS1 be able to use the access token at RS2. Audience-restricted access tokens and resource indicators are a solution.
Apply my wording suggestion if you like it or don't if you don't. Then merge.
Code change:
recommendations can be found in the OWASP SSRF Prevention Cheat Sheet OWASP.SSRF. <del> 7.7. </del> <ins> 7.8. </ins> This specification may be deployed in a scenario where the desired HTTP resource is identified by a user-selected URL.  If this resource

Related discussion:
text: From BC's comments: URL FAPI Message Signing talks about the RS signing resource responses. This specification could be how the RS publishes the public key, as mentioned in 5.6.6.2 URL
I can see why this one was tricky. One more suggestion to approve, then merge.
Code change:
3.5. <ins> In contrast to operating systems or user space software components of a large and complex systems, firmware components are often already executed during boot-cycles before there is an opportunity to authenticate them. Authentication takes place, for example, by validating a signature or by creating a hash of measurements and comparing them to a reference value.  Corresponding procedures are often called authenticated, measured, or secure boot.  The output of these high assurance boot procedures is often used as input to more complex verification known as remote attestation procedures. If measurements before execution are not possible, static after-the- fact analysis is required. When best practices are followed, in such cases measurements (e.g., a hash or digests) are stored in a protected or shielded environment (e.g., TEEs or TPMs). After finishing a high assurance boot sequence, these measurements about foundational firmware are retrieved after-the-fact from shielded locations and must be compared to reference values that are part of Reference Integrity Manifests (RIMs). A verifying system appraising the integrity of a high assurance boot sequence must identify, locate, retrieve, and authenticate corresponding RIMs. A consumer of published software wants: to easily identify sources for RIMs to select appropriate RIMs and download them for the appraisal of measurements to be able to assure the authenticity, applicability, and freshness of RIMs over time There is no standardized way to: identify, locate, retrieve and authenticate RIMs in a uniform fashion to uniquely identify among multiple potential available RIMs (e.g., by age, source, signing authority, etc.) to store RIMs in a fashion that enables their usage in appraisal procedures years after they were created in a secure and believable fashion 3.6. </ins> An organization has established procurement requirements and compliance policies for software use.  In order to allow the acquisition and deployment of software in certain security domains of

Related discussion:
text: Signed-off-by: Henk Birkholz
Looks good.
If there are no objections until the end of Fri, I'll merge for the meeting on Mon.
No objections with merging these changes.
My feedback is non blocking, PR authors may dismiss my suggestions.
LGTM!
Code change:
Abstract <del> There have been proposals to extend or update the standard IETF congestion control schemes.  Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles.  Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control.  Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals.  The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. </del> <ins> Introducing new or modified congestion controllers in the global Internet have possible ramifications to both the traffic using the new congestion controller and to traffic using a standardized congestion controller.  Therefore, the IETF must proceed with caution when evaluating alternate congestion control proposals.  The goal of this document is to provide guidance for considering standardization of alternate congestion controllers at the IETF.  It replaces RFC5033 to reflect changes in the congestion control landscape. </ins> 1.

Related discussion:
text: eliminate some awkward/unnecessary phrases. Include brief rationale for a bis.
done
OK, how about now?
Code change:
CT logs produce Signed Certificate Timestamps (Transparent Statements) <del> SCTs are checked by browsers (Verifiers) </del> <ins> Signed Certificate Timestamps are checked by Verifiers. </ins> <del> The Append-only Log can be checked by Auditors Note that just like CT logs are independent and their contents need not be consistent, Transparency Services are similarly independent of each other. </del> <ins> The Append-only Log can be checked by Verifiers and Auditors </ins> 3.

Related discussion:
text: A set of consistency fixes for the next draft.
See URL for discussion on the terminology.
The doc uses the three interchangeably Is there a preferred reference to be consistent?
URL is about Media Type. And then references payload and content type. I've been through this confusion before, where Media Type is the definition of a type of identifier. The challenge becomes when using that type of identifier for different parts of a document. When does the media type refer to the envelope itself? When does the media type refer to a property (aka payload)?
I don't understand the question. is of content type and . It is generally a good idea to use a more specific media type. The payload of a cose-sign1 can have a media type, such as or .
It cuts out cruft, so I support this edit, just one minor nit (take or leave it, it's minor to me), before moving onto .
Code change:
"Content-Encoding: aesgcm", a single zero octet and an optional context string: <ins> Concatenation of octet sequences is represented by the "||" operator. </ins> Unless otherwise specified, the context is a zero length octet sequence.  Specifications that use this content coding MAY specify the use of an expanded context to cover additional inputs in the key

Related discussion:
text: This moves the values that were in the Encryption header field to the start of the payload. This provides a meagre efficiency gain as well as removing the need to have two correlated header fields. This should go most of the way to address WGLC comments.
Looks good to me in general. That said; this removes the parsing weirdness for "Encryption" (good), but not for "Crypto-Key", right?
NAME happy to correct any parsing weirdness, but need to know precisely what it is first.
Code change:
to be advertised.  Whether or not such a prefix is advertised, and what exactly is advertised regarding that prefix, is determined by the state machine.  The other set of information is a set of routes <del> to prefixes on the SNAC network.  Whenever we know of a reachable (scope is not link-local) prefix on the SNAC network, we include an </del> <ins> to prefixes on the stub network.  Whenever we know of a reachable (scope is not link-local) prefix on the stub network, we include an </ins> RIO option in the RA on the infrastructure network indicating that that prefix is reachable through the SNAC router. It is important to note that it is possible for an on-link, routable <del> prefix to be advertised and then withdrawn on the SNAC network, but </del> <ins> prefix to be advertised and then withdrawn on the stub network, but </ins> for it to still be valid, and for there to still be some communication occurring using that prefix.  In order to avoid prematurely interrupting such communication, the SNAC router MUST <del> maintain a list of prefixes known to be valid on the SNAC network, </del> <ins> maintain a list of prefixes known to be valid on the stub network, </ins> even if those prefixes have been deprecated, and MUST include RIO options for all such prefixes in the RAs that it sends on the adjacent infrastructure link.

Related discussion:
text: As Esko pointed out, the term "SNAC network" crept in during editing a few weeks ago, and doesn't add value. This pull request changes all instances of "SNAC network" to "stub network".
In -05, the term "SNAC network" is now used but not defined. Could we use the more generic term "stub network" instead? I.e. a SNAC router is able to automatically connect a stub network to an infrastructure network. So the stub network served by this SNAC router is still a "stub network". Or we could use the term "SNAC network" for any stub network that gets automatically connected via a SNAC router. But doing this adds an extra term throughout the document: it's not possible to mass-replace all occurrences of "stub network".
See also which overlaps with this issue, but targets a specific definition paragraph.
Right, this happened when we added a bunch of text in the last interim, and I think was a mistake. I think we just want to use the term "stub network" and not invent a new term. The thing that's new here is the "SNAC router", not the stub network.
I agree - "stub network" makes more sense here.
removed
Code change:
of this data does not waive the other considerations in this document. <del> Experimental specifications SHOULD NOT be deployed as a default. They SHOULD only be deployed in situations where they are being actively measured, and where it is possible to deactivate them if there are signs of pathological behavior. </del> Each published congestion control algorithm is REQUIRED to include a statement in the abstract indicating whether or not there is IETF consensus that the proposed congestion control algorithm is

Related discussion:
text: Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.
Code change:
This may involve registering the same Signed Statements at different Transparency Services, each with their own purpose and Registration <del> Policy.  This may also involve attaching multiple Receipts to the same Signed Statements, each Receipt endorsing the Issuer signature and a subset of prior Receipts, and each Transparency Service verifying prior Receipts as part of their Registration Policy. For example, a supplier may provide a complete, authoritative Transparency Service for its Signed Statements, whereas a Verifiers's Transparency Service may collect different kinds of Signed Statements to ensure complete auditing for a specific use case, and possibly require additional reviews before registering some of these Signed </del> <ins> Policy. This may also involve attaching multiple Receipts to the same Signed </ins> Statements. <del> An independent entities (security companies) may Issue statements of quality about different artifacts on their own Transparency Service. Verifiers choose which independent entities they trust, just as entities choose different security companies today. </del> <ins> For example, a software producer of a supply chain artifact might rely on multiple independent software producers operating transparency services for their upstream artifacts.  Downstream producers benefit from upstream producers providing higher transparency regarding their artifacts. </ins> 8.

Related discussion:
text: This PR makes it clearer that merkle trees are not required, and what the structure of a receipt is.
Just to be clear, we very much appreciate the work on the cose merkle proof format and intend to use that by default where we can.
And also of course, LGTM
If you approved this PR, you should probably review and approve URL
NAME I added the changes from the IETF Hackathon, including the new statement-specific registration information in the receipt and the description of transparent statement verification algorithm. The examples will have to be aligned to the new CDDL
These improvements seem excellent... I would approve them, if I could, but I opened the PR.
NAME , can you please re-review your "requested changes" review
Merging as Henks comment was resolved
I also suggest we merge then work on the details. LGTM:+1:
Code change:
(remote)" or "closed" - state, this frame can only affect processing of the current stream and not frame transmission. <del> The PRIORITY frame is the only frame that can be sent for a stream in the "idle" or "closed" states.  This allows for the reprioritization of a group of dependent streams by altering the priority of an unused or closed parent stream. </del> <ins> The PRIORITY frame can be sent for a stream in the "idle" or "closed" states.  This allows for the reprioritization of a group of dependent streams by altering the priority of an unused or closed parent stream. </ins> A PRIORITY frame with a length other than 5 octets MUST be treated as a StreamErrorHandler of type

Related discussion:
text: As discussed on the mailing list.
:+1:
Make it so that PRIORITY can be sent on a stream in ANY state. i.e., change so that PRIORITY is permitted in the "idle" state.
Discussed in Honolulu; seems reasonable and no objection. Take to list to confirm.
Code change:
8.2. Holders can manipulate the Disclosures by changing the values of the <del> claims before sending them to the Issuer.  The Issuer MUST check the Disclosures to ensure that the values of the claims are correct, </del> <ins> claims before sending them to the Verifier.  The Verifier MUST check the Disclosures to ensure that the values of the claims are correct, </ins> i.e., the digests of the Disclosures are actually present in the signed SD-JWT.

Related discussion:
text: Discussions around defining SD-JWT-VC show that it would be very helpful for interoperability if HB JWT is normatively defined in SD-JWT specification itself. Using HB JWT is optional, but if used, it should be compliant to the definitions in SD-JWT. How to represent validity (iat, exp, nbf) will probably need the most discussion... also we should introduce an abbreviation .... cc NAME
need to re-generate example 4b, and 4a to update hb jwt header....
cc NAME please take a look (can't ask review from you...)
This change is sufficient to warrant an entry in the doc history like just, "Defined the structure of the Holder Binding JWT"
done, thank you, Brian
lgtm
Code change:
8.2. Holders can manipulate the Disclosures by changing the values of the <del> claims before sending them to the Issuer.  The Issuer MUST check the Disclosures to ensure that the values of the claims are correct, </del> <ins> claims before sending them to the Verifier.  The Verifier MUST check the Disclosures to ensure that the values of the claims are correct, </ins> i.e., the digests of the Disclosures are actually present in the signed SD-JWT.

Related discussion:
text: to
I think the first paragraph mixes Issuer with Verifier. Old: New:
Thanks for catching that. We'll fix.
Code change:
9.3. <del> IANA is requested to create the "Cookie Attribute Registry", defining </del> <ins> IANA is requested to create the "Cookie Attribute" registry, defining </ins> the name space of attribute used to control cookies' behavior.  The registry should be maintained at https://www.iana.org/assignments/ cookie-attribute-names [1].

Related discussion:
text: Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.
Code change:
9.3. <del> IANA is requested to create the "Cookie Attribute Registry", defining </del> <ins> IANA is requested to create the "Cookie Attribute" registry, defining </ins> the name space of attribute used to control cookies' behavior.  The registry should be maintained at https://www.iana.org/assignments/ cookie-attribute-names [1].

Related discussion:
text: Adds suggestions for how servers could fulfill the requirement Adds suggestion that servers be mindful of the number and size of the cookies they set to avoid hitting their own header length limits. Also mention that UA should consider splitting longer fields.
If that's the case, I'd recommend punting on getting this in 6265bis - which has had a goal of documenting reality.
It is not unusual for servers to reject HTTP requests that contain individual headers longer than a certain limit. If a client sends a header longer than around 8-9K bytes, the risk is quite large that it will get a 40x response back which effectively blocks the client from continuing what it is set out to do. Because of the rather complicated results of such a "too long" cookie header, I think it could be worth mentioning this in the spec. For newcomers in cookie land, this is perhaps not completely obvious. The spec currently mentions size-limits per cookie, but a server can easily send a few large cookies and have the combined size of them outgrow 8K. I would perhaps suggest wording that says a client SHOULD keep its lines shorter than NNN bytes and servers SHOULD accept cookie lines up to at least NNN bytes. (in curl we have the limit set to 8190 bytes) HTTP related specs rarely speak of this kind of size limits, but I know my implementation could have avoided some issues if this real-world limit had been mentioned.
Seems like a worthwhile warning to me.
RFC 6265 had a requirement that a client MUST generate a single cookie header. HTTP/2 and HTTP/3 allow "cookie crumbling" that permits multiple Cookie headers. 6265bis says in URL What is tolerance really? Why are we stating MUST requirement that are immediately invalidated by two of the versions of HTTP in wide usage? Section 5 is huge, what requirement is the text in section 4.2 forward referencing to? I think there's some room for improvement in this area. An HTTP/2 or HTTP/3 is being instructed as a MUST requirement in the relevant RFCs to combine multiple cookie headers into one e.g. URL but if the server MUST be tolerant to multiple Cookies, maybe we can relax the HTTP/2 or HTTP/3 requirements?
This was the output of the discussion in URL
Thanks Mike, I missed that discussion first time around.
Code change:
9.3. <del> IANA is requested to create the "Cookie Attribute Registry", defining </del> <ins> IANA is requested to create the "Cookie Attribute" registry, defining </ins> the name space of attribute used to control cookies' behavior.  The registry should be maintained at https://www.iana.org/assignments/ cookie-attribute-names [1].

Related discussion:
text: My question comes about because of some HTTP/2 code I looked at that simply implements HTTP/2 and so combines the multiple fields back into one. But as NAME and NAME alluded to their comments on , the splitting could be done for some reason thst isn't purely about H2 or H3 compression optimization. It seems there are actually use cases where keeping the split is useful, and not just in a private deployment. Of course relaxing things more might have unintended consequences. I find the current text too terse to be useful. This is a cookie spec, it seems like the right place to ba adding commentary about how to handle cookies across various version and conversions. Especially some anecdotal examples about why some clients actually do it.
Mentioning why a server should be tolerant, and what shape that could take, seems reasonable to me. Especially given how nicely it dovetails with . What forward reference are you referring to? ?
In that mention, I think it's worth including that re-combining the Cookie lines before passing to the next layer is a form of tolerance from the client's perspective.
Some more text sounds good and I'm happy to review. In Section 4.2.1:
Still LGTM, thanks!
Code change:
ephemeral keys to acquire access to geography- or capability-specific resources, as issued by an entity whose user base is larger than the available resources can support (by having that entity metering the <del> availability of keys temporally or geographically).  Unprompted Authentication is also useful for cases where a service provider wants to distribute user-provisioning information for its resources without exposing the provisioning location to non-users. </del> <ins> availability of keys temporally or geographically).  The Signature HTTP authentication scheme is also useful for cases where a service provider wants to distribute user-provisioning information for its resources without exposing the provisioning location to non-users. </ins> There are scenarios where servers may want to expose the fact that authentication is required for access to specific resources.  This is

Related discussion:
text: From Ilari Liusvaara on the : From NAME on the :
Maybe also consider for identification. That's not perfect, because of the "none" thing, but it might be a better fit. The TLS schemes are generally OK provided that you only use the recommended ones (of which there aren't many).
I don't love JWA since , but using TLS SignatureScheme with a requirement to only use the recommended ones sounds good to me.
NAME Doesn't it define the algorithm and then define the subkey types and in ?
NAME that could be made to work though it's quite clunky since it requires a separate string parameter for "alg". Overall I think the is a much better fit for signatures here. We already tightly integrate with TLS but not JWA. All that said, the closest option for hashes is the and that's been orphaned by RFC 8447. At this point I guess we should bite the bullet and define a new registry. Perhaps we include as current values: hmac-sha256 hmac-sha384 hmac-sha512 signature-rsapkcs1sha256 signature-rsapkcs1sha384 signature-rsapkcs1sha512 signature-ecdsasecp256r1sha256 signature-ecdsasecp384r1sha384 signature-ecdsasecp521r1sha512 signature-rsapssrsaesha256 signature-rsapssrsaesha384 signature-rsapssrsaesha512 signature-rsapsspsssha256 signature-rsapsspsssha384 signature-rsapsspsssha512 signature-ed25519 signature-ed448 Of course this requires to paint the bikeshed one of two colors: HMAC and Signatures in the same registry, using a single new auth scheme Separate registries, using separate auth schemes Thoughts? At this point I suspect this issue will need WG discussion at IETF 116.
I had to implement rsapsspss_shaX algorithms to produce test vectors for DCs, and unless there's a really compelling reason to include them, I'd really rather not. They're just such a pain to use, and the support for them is very poor (thus me needing to implement them).
FWIW, adding an entry in the registry doesn't mean it'll be mandatory to implement so there's not much of a cost.