jiebi/CodeConvo huggingface dataset:
Change:
As above, specific mechanisms for key management and discovery are out of scope for this document. <del> 3.2.2.2. Token issuance associates all issued tokens with a particular choice of key.  If an Issuer issues tokens with many keys, then this may harm the anonymity of the Client.  For example, they would be able to map the Client's access patterns by inspecting which key each token they possess has been issued under. To prevent against this, Issuers MUST only use one private key for issuing tokens at any given time.  Servers MAY use one or more keys for redemption to allow Issuers for seamless key rotation. Servers may rotate keys as a means of revoking tokens issued under old or otherwise expired keys.  Alternatively, Issuers may include expiration information as metadata alongside the token; See metadata for more discussion about metadata constraints.  Both techniques are equivalent since they cryptographically bind expiration to individual tokens.  Key rotations should be limited in frequency for similar reasons. </del> 3.2.3. Certain instantiations of the issuance protocol may permit public or

Discussion:
cc NAME
S3.2.2.2 states "Issuers MUST only use one private key for issuing tokens at any given time." The next section (3.2.3), however, suggests that multiple keys could be used to encode metadata, and indeed, I believe the latest draft of rate-limited tokens uses different issuance keys. These seem to be in conflict.
Change:
Initial or 0-RTT packets.  A server MUST NOT send more than one Retry packet in response to a single UDP datagram. <ins> 17.2.5.2. </ins> A client MUST accept and process at most one Retry packet for each connection attempt.  After the client has received and processed an Initial or Retry packet from the server, it MUST discard any

Discussion:
This was getting a little long. You could get lost in there. The text was fine, it was mostly well structured. All it needed was one small move and some headers.
Change:
received the client Finished message in the initial authentication. The PSK associated with the ticket depends on the client Finished and cannot be pre-computed in handshakes with client authentication.  The <del> NewSessionTicket message MUST NOT include an "early_data" extension. Servers should take into account that fewer newSessionTickets will likely be needed in EAP-TLS than in the usual HTTPS connection scenario.  In most cases a single newSessionTicket will be sufficient.  A mechanism by which clients can specify the desired number of tickets needed for future connections is defined in I- D.ietf-tls-ticketrequests. </del> <ins> NesSessionTicket MUST NOT be sent before the client's certificate has been validated.  The NewSessionTicket message MUST NOT include an "early_data" extension.  If the "early_data" extension is received then it MUST be ignored.  Servers should take into account that fewer newSessionTickets will likely be needed in EAP-TLS than in the usual HTTPS connection scenario.  In most cases a single newSessionTicket will be sufficient.  A mechanism by which clients can specify the desired number of tickets needed for future connections is defined in I-D.ietf-tls-ticketrequests. </ins> figbase2 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication and ticket establishment of a

Discussion:
Added text to make sure the client cert is validated before a NST is sent and stated that early data must be ignored: This is to address issue .
NAME does this PR address the issue?
yes, thanks.
From Alan's review: >
Change:
3.4. The "RateLimit-Reset" field response field indicates the number of <del> seconds until the quota resets. </del> <ins> seconds until the quota associated to the expiring-limit resets. </ins> The field is a non-negative Integer compatible with the delay-seconds rule, because:

Discussion:
clarify that we return only the values related to the quota policy identified by the expiring-limit
If there are multiple policies in effect, which is reflected in these fields? RateLimit-Limit has advice about this, but these do not.
Ok, we should clearly state that all the three basic fields return the values associated to the expiring-limit.
Change:
As the certificate messages in TLS 1.3 are encrypted, there is no need to send an empty certificate_list and perform a second handshake for privacy (as needed by EAP-TLS with earlier versions of TLS). <del> When EAP-TLS is used with TLS version 1.3 or higher the EAP-TLS peer and EAP-TLS server SHALL follow the processing specified by the used version of TLS.  For TLS 1.3 this means that the EAP-TLS peer only sends an empty certificate_list if it does not have an appropriate certificate to send, and the EAP-TLS server MAY treat an empty certificate_list as a terminal condition. </del> <ins> When EAP-TLS is used with TLS version 1.3 the EAP-TLS peer and EAP- TLS server SHALL follow the processing specified by the used version of TLS.  For TLS 1.3 this means that the EAP-TLS peer only sends an empty certificate_list if it does not have an appropriate certificate to send, and the EAP-TLS server MAY treat an empty certificate_list as a terminal condition. </ins> EAP-TLS with TLS 1.3 is always used with privacy.  This does not add any extra round-trips and the message flow with privacy is just the

Discussion:
Explain that the next version of TLS may not be compatible with this document. Remove "or higher" in several sections. This addresses issue
NAME does this commit address Issue ?
As an implementor, I'm not sure what it means to "automatically support" or "not automatically support" something. It's not clear to me what I do with that recommendation. I think it's best to make an explicit statement that That statement gives clear direction on exactly what to do. i.e. there are APIs to "limit the maximum TLS version". So I know what that phrase means. There are no APIs to "not automatically support" something. So I don't know what that phrase means, or what I should do in order to satisfy its' requirements. The rest of the changes are fine.
Thanks, I updated the text.
From Alan's review: Suggestion: remove all "or higher" text. Add in text which says that by default, EAP-TLS 1.3 implementations MUST limit the maximum TLS version to 1.3, unless later versions are explicitly enabled by the administrator.
It would help implementors to understand why this restriction is there. i.e. instead of just saying "use TLS 1.3", it would be good to note something like:
Change:
An example set of protocol messages for this method can be found in example-async. <del> 1.5.4. </del> <ins> 1.5.5. </ins> In this example flow, the AS policy allows the client instance to make a call on its own behalf, without the need for an RO to be

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: a48ba2e1204e2294f34f8550971f65f684ea7992 Inspect the deploy log: Browse the preview:
Sec. 1.5 (Sequences) would be clearer if we named the top sequence - all other sequences have been named. Maybe "main authorization flow"?
The sequences have not been names per say, they just happen to be related to a subtitle. We could of course create a new subsection, but the idea was to place this sequence above the others.
This is purely editorial. Naming it would make it easier to refer to this sequence.
Change:
1.3, a client receiving a CertificateRequest or NewSessionTicket MUST also ignore all unrecognized extensions. <del> An intermediary which terminates a TLS connection MUST behave as a </del> <ins> A middlebox which terminates a TLS connection MUST behave as a </ins> compliant TLS server (to the original client), including having a certificate which the client is willing to accept, and as a compliant TLS client (to the original server), including verifying

Discussion:
There are many sorts of TLS middleboxes (CDN, decrypting proxy, local antivirus, actual attack, etc), with acceptabilities ranging from reasonable to extremely questionable to a terrible idea. (Categorization is left as an exercise to the reader.) They also have very different security considerations. Fundamentally, TLS secures a connection between two endpoints. As such, we have something to say about the endpoint-to-endpoint connections that make up such a system, but we shouldn't imply this section is sufficient, merely necessary. Adjust the text accordingly. I wrote "intermediary" in the original PR, predictively based on PR . Since the spec seems to have settled on "middlebox", align the terminology. (I don't really care what is used, just that it is consistent.)
Ah yeah. Fixed. I used "implementations" for this one because there is an "(also known as ossification)" parenthetical and, in the general case, endpoints can cause ossification too. Even here, I dunno, maybe a sufficiently confused endpoint will do something silly there. :-)
Should the legacysessionid description, which also mentions intermediaries, also be tweaked?Thanks!
Change:
"unexpected_version" <ins> "invalid_initial" </ins> Note: sometimes packets are dropped before they can be associated with a particular connection (e.g., in case of "unsupported_version").  This situation is discussed in handling-

Discussion:
There are two conditions an Initial packet has to fulfill: It's DCID must be >= 8 bytes long. The size of the datagram must be >= 1200. None of the other triggers for the event seem appropriate for this.
Change:
Verify that the resulting URI is well-formed. Dereference the URI using an HTTP GET request.  This request MUST <del> be sent to TCP port 80 on the server. </del> <ins> be sent to TCP port 80 on the HTTP server. </ins> Verify that the body of the response is well-formed key authorization.  The server SHOULD ignore whitespace characters at the end of the body. <del> Verify that key authorization provided by the server matches the token for this challenge and the client's account key. </del> <ins> Verify that key authorization provided by the HTTP server matches the token for this challenge and the client's account key. </ins> If all of the above verifications succeed, then the validation is successful.  If the request fails, or the body does not pass these

Discussion:
As pointed out by NAME on the ACME mailing list there are a few places where there was some potential ambiguity about what "server" meant. This PR is the result of a once-through pass looking for places where we could be more specific when saying "server". In most cases the default definition of "server" from the Terminology section applied and no change was made. I attempted to clarify any usage of "server" that wasn't qualified sufficiently to differentiate from the ACME server.
Change:
An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control <del> information to modification and manipulation in the network.  Further downgrades to older TLS versions than 1.3, which is used in QUIC version 1, might result in significantly weaker cryptographic </del> <ins> information to modification and manipulation in the network. Further, downgrades to older TLS versions than 1.3, which is used in QUIC version 1, might result in significantly weaker cryptographic </ins> protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used.

Discussion:
All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions.
Change:
"unsupported_version" <ins> "unexpected_packet" "unexpected_source_connection_id" "unexpected_version" </ins> Note: sometimes packets are dropped before they can be associated with a particular connection (e.g., in case of "unsupported_version").  This situation is discussed in handling-

Discussion:
Per discussion on slack, and can be merged into , given that we have a field for the disambiguation.
NAME Done. Updated the PR.
Change:
<del> YAML Media Types </del> <ins> YAML Media Type </ins> draft-ietf-httpapi-yaml-mediatypes-latest Abstract

Discussion:
addressing (and a few minor editorial changes thrown in as well).
This is probably left over from earlier drafts that did cover multiple media types.
There are a couple more places that use the plural form "media types". Unless I am missing something, these all should be changed to singular form.
It's and . I don't have preferences and the singular is OK to me. Feel free to PR :)
that's what i also thought but then again isn't a media type (as i am sure you know). let's make NAME the tie-breaker!
Let's go with the singular form.
fixed via
Change:
the new connection ID being negotiated via encrypted frames.  See Section 5.1 of QUIC-TRANSPORT. <ins> Server-generated connection IDs should seek to obscure any encoding, of routing identities or any other information.  Exposing the server mapping would allow linkage of multiple IP addresses to the same host if the server also supports migration.  Furthermore, this opens an attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the Connection ID in the Connection ID itself, instead of remembering it, e.g. by using the first few bits to indicate a certain size of a well-known set of possible sizes with multiple values that indicate the same size but are selected randomly. QUIC_LB further specified possible algorithms to generate Connection IDs at load balancers. </ins> 2.7. The packet number field is always present in the QUIC packet header;

Discussion:
addresses issue
Is this something application designers need to think about or manage? I would hope QUIC implementations would handle this transparently. To the extent you have to configure something like QUIC-LB, that's a manageability thing.
Connection IDs are weird, in that they are important to both implementors / deployers (so applicability) as opposed to operators of networks that are not necessarily at the endpoints (so manageability)
There is text about Connection ID in both documents. We can double-check though that the text is well aligned and splitter correctly.
Well, implementors are explicitly out of scope according to the document's introduction. I would hope that apps didn't have to worry about Connection ID properties very much, or at all. Maybe there is knob or two for information exposure, at most, but I'd consider most of this text to be extraneous to the applicabilty draft.
I think we actually put some text in the wrong doc. PR moves this text from applicability to manageability.
Change:
independent of the method or some means to detect that the original request was never applied.  See HTTP for more details. <del> 4.1.3. </del> <ins> 4.1.2. </ins> A malformed request or response is one that is an otherwise valid sequence of frames but is invalid due to:

Discussion:
The diff looks larger than it is; I moved some sections around to more closely resemble the TOC of the HTTP/2 spec, and changed a section title that seemed a bit odd a year later. The relocated sections haven't changed. Old TOC: HTTP Request Lifecycle HTTP Message Exchanges Field Formatting and Compression Request Cancellation and Rejection Malformed Requests and Responses The CONNECT Method HTTP Upgrade Server Push New TOC: Expressing HTTP Semantics in HTTP/3 HTTP Message Framing Request Cancellation and Rejection Malformed Requests and Responses HTTP Fields HTTP Control Data Request Pseudo-Header Fields Response Pseudo-Header Fields The CONNECT Method HTTP Upgrade Server Push Comparison H2 TOC: Expressing HTTP Semantics in HTTP/2 HTTP Message Framing Malformed Messages HTTP Fields Field Validity Connection-Specific Header Fields Compressing the Cookie Header Field HTTP Control Data Request Pseudo-Header Fields Response Pseudo-Header Fields Server Push Push Requests Push Responses The CONNECT Method The Upgrade Header Field URL then some further sections as well.
Http-core introduces a new term, "control data," and HTTP/2 has been updated to use this term. HTTP/3 has not. While it was not raised in Auth48, it might be appropriate to align this terminology before we publish these documents together.
This seems like a good change for consistency, even if it might cause the document editor some short term pain.
Closed in .
Change:
GNAP seeks to provide functionality and solve use cases that OAuth 2.0 cannot easily or cleanly address. vs-oauth2 further details the protocol rationale compared to OAuth 2.0.  GNAP and OAuth 2.0 will <del> exist in parallel for many deployments, and considerations have been taken to facilitate the mapping and transition from legacy systems to GNAP.  Some examples of these can be found in example-oauth2. </del> <ins> likely exist in parallel for many deployments, and considerations have been taken to facilitate the mapping and transition from legacy systems to GNAP.  Some examples of these can be found in example- oauth2. </ins> 1.1.

Discussion:
adds a paragraph to the introduction adds specific examples under roles
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit aa65f1110cdcc11a60ca4d2d284e78f7909d0817 https://deploy-preview-254--gnap-core-protocol-editors-URL
Change:
permitted hash algorithm, subject to restrictions in the certificate, if any.  RSA signatures MUST be based on RSASSA-PSS, regardless of whether RSASSA-PKCS-v1_5 appears in <ins> "signature_algorithms".  SHA-1 MUST NOT be used in any signatures in CertificateVerify, regardless of whether SHA-1 appears in </ins> "signature_algorithms". 6.3.12.

Discussion:
This completes the removal of SHA-1 for CertificateVerify. There's no reason to allow it there at all
LGTM
Change:
expression, usually involving the current node, is evaluated and the current node is selected if and only if the expression yields true. <ins> As the expression is composed of side-effect free components, the order of evaluation does not need to be (and is not) defined. Similarly, for "&&"/"||", both a short-circuiting and a fully evaluating implementation will lead to the same result; both implementation strategies are therefore valid. </ins> The current node is accessible via the current node identifier "@". This identifier addresses the current node of the filter-selector that is directly enclosing the identifier; note that within nested

Discussion:
clarify that filter expressions are side-effect free and therefore, short-circuiting does not make a difference
In C# (and probably other C-style languages), there are two variants for these operators. and are simple boolean logic. They evaluate all of their operands always (left to right). and are "short-circuit" logic. Their operands are evaluated left to right, and as soon as an outcome is known, it stops evaluating. For example, in , the is never evaluated because returns false so the evaluator knows the entire expression will be false. This becomes important for C# as the operands may be methods which have side effects. If I am trying to parse a , then use the I parsed, I can do that all in one statement: (assume returns a ) In this case, never gets called, which means that no log entry is made. But if I use instead will always be called and a log entry will always be created. ( will be the default (0), but it will still be called.) I'm not sure whether we care about such side effects in JSON Path (I'm leaning towards probably not), but it seems necessary to raise the issue. I expect that if we don't care about side effects, this comes down to an optimization strategy and implementor's choice.
This may become more important if certain function extensions end up having side effects. Perhaps we should say implementations MAY short circuit evaluation. Then it's up to users and function extensions to cope.
Actually, it would already become important as soon as we have exception-like semantics on subexpressions. I'd prefer not to have them.
2023-01-10 Interim: Add text that explicitly excludes side effects that affect the evaluation of JSONpath (e.g., beyond memoization or logging), but makes clear that short-circuiting is a valid implementation strategy; functions need to be pure functions.
Change:
according to this encoding, then the verifier MUST reject the JWS as malformed. <del> 5.5. </del> <ins> 5.6. </ins> Creation of resources can be rate limited to ensure fair usage and prevent abuse.  Once the rate limit is exceeded, the server MUST

Discussion:
As discussed (too ambiguously) at IETF 96, this refactor uses two nested JWS objects instead of one parallel JWS object. This preserves the pattern that every ACME message sent by the client is signed by exactly one account key, and saves clients from having to search through multiple signatures in the verification process.
Looking at the current mechanism in a little more detail, I have a few concerns with the parallel-signature approach that's there now: It's not clear which signature is by the old key and which is by the new key, and the new key doesn't sign over the old key. Both signatures have to include the parameter, so this request burns two nonces unnecessarily The server's JWS checking code now has to switch between validating one signature and two Lots of JWS implementations don't support multiple signatures If not for this, we could require the flattened JSON serialization You need a lot of duplication to deal with the copy/paste attacks (cf. ). (On the other hand, I like that both signatures cover the parameter; reduces replayability.) I would propose that we change the signatures from parallel back to serial, as illustrated below. It would cost a little bit of payload bloat (due to another layer of base64url encoding), but I think the benefits in terms of conceptual simplicity would be worth it.
Just noticed that if we keep to one signature per object, you can do nice stuff like this on the server:
Change:
5.2. <del> All ACME requests with a non-empty body MUST encapsulate the body in a JWS object, signed using the account key pair.  The server MUST verify the JWS before processing the request.  (For readability, however, the examples below omit this encapsulation.)  Encapsulating request bodies in JWS provides a simple authentication of requests by way of key continuity. </del> <ins> All ACME requests with a non-empty body MUST encapsulate their payload in a JWS object, signed (in most cases) using the account's private key.  The server MUST verify the JWS before processing the request.  Encapsulating request bodies in JWS provides a simple authentication of requests. </ins> JWS objects sent in ACME requests MUST meet the following additional criteria:

Discussion:
Several places talked about account key pairs as being the primary notion of an account, while the account is now primary and has a public key associated with it. Updated to clarify that. Clarified that the account request can contain more than just contact information. Fixed the order of operations in protocol summary to reflect new-order flow.
Change:
groups marked "No" range from "good" to "bad" from a cryptographic standpoint. <ins> The designated expert RFC8126 only ensures that the specification is publicly available. </ins> Despite the following behavior being crazy, experience has shown that some customers use the IANA registry as checklist against which to measure an implemention's completeness and some implementers blindly

Discussion:
This adds the designated expert note to supported groups to address issue 32
NAME Just setting this up to auto address .
I believe specification required still involves a designated expert review.
Yes expert review is implied by specification required, but you're right we should also include the same note about the experts just making sure it's publicly available.