jiebi/CodeConvo huggingface dataset:
Change:
This process may be repeated to associate multiple identifiers to a key pair (e.g., to request certificates with multiple identifiers), or to associate multiple accounts with an identifier (e.g., to allow <del> multiple entities to manage certificates).  The server may declare that an authorization is only valid for a specific order by setting the "scope" field of the authorization to the URL for that order. </del> <ins> multiple entities to manage certificates). </ins> Authorization resources are created by the server in response to certificate orders or authorization requests submitted by an account

Discussion:
It is no longer necessary with the order based issuance flow that allows the server to specify which authorizations a client must satisfy to allow issuance of an order. See URL Section 7.1.4 "Authorization Objects" describes an optional "scope" field. If present it must be a URI pointing to an order and the authorization is considered to be valid only for that order. If no scope value is present it is assumed that the authorization is valid for any order. Looking back at the PR that introduced the "scope" field[0] and knowing the current state of order based issuance I'm not clear why this field is needed, or what a client could do with the scope information. Can someone clarify or should this part of the spec be removed? The server determines as a matter of policy which authorizations are required for an order and includes these in the order's array. If part of that server policy is to treat some valid authorizations as only being valid for a specific order then the server can simply not include those valid authorizations in the order's authorizations array and can instead create new pending authorizations for the client to solve. The client doesn't need to understand authorization scope it just needs to know which authorizations the server says are required and how to move these authorizations to a valid state. Since the client can't ask for specific authorizations to be used with specific orders and must react to what the server provides why is it helpful to tell a client that one of the authorizations it solved won't be used with future orders? Similarly I think the scope field interacts weirdly with pre-authorization. Are all authorization objects created with pre-authorization assumed to be global scope since they aren't associated with an order? Have any ACME clients or servers implemented order scope? Let's Encrypt/Boulder/Pebble have not. Daniel / cpu [0] - URL
Change:
address validation. The 96 bit unique token number is set to a random value using a <del> cryptography- grade random number generator. </del> <ins> cryptography-grade random number generator. </ins> The token key identifier and the corresponding AEAD key and AEAD IV are provisioned by the configuration agent.

Discussion:
detail info: fix a typo. change AEAD checksum to AEAD ICV(defined in rfc4106)
Hi martin: is not a standard name of AEAD verification message, which should be , see section 6 of rfc4106
Change:
using the EDHOC-Exporter interface defined as: where label is a registered tstr from the EDHOC Exporter Label <del> registry (exporter-label), context is a CBOR sequence defined by the </del> <ins> registry (exporter-label), context is a bstr defined by the </ins> application, and length is a uint defined by the application.  The (label, context) pair must be unique, i.e., a (label, context) MUST NOT be used for two different purposes.  However an application can

Discussion:
The new definition of info in th ecurrent specification is. I noticed two problems with this while implementing. To create the array you need to parse context to see how many items it contains. Unless context is validated, length is not strictly defined (an attacker could create collisions) I suggest that info is changed to:
In the exporter, the application using EDHOC could input a context (a encoded CBOR sequence) that is not valid CBOR. That is not a big problem, but might lead to security issues in the future, if is assumed that info is valid CBOR. URL prefered sequence to array. I don't think bstr wrapping the sequence has the same problems as array wrapping the sequence. Array wrapping the info sequence seems like an unesasary step. I suggest.
We have also gotten comments disliking the use of any
Current specification could give the impression that there is a single maclength. But the mac length in message2 and message_3 may be different.
One fix is to update to
Change:
in the transport layer.  QUIC recommends to retransmit lost data before new data, unless indicated differently by the application. Currently QUIC only provides fully reliable stream transmission, and <del> as such prioritization of retransmissionis likely beneficial in most </del> <ins> as such prioritization of retransmissions likely beneficial in most </ins> cases, as gaps that get filled up and thereby free up flow control. For not fully reliable streams priority scheduling of retransmissions over data of higher-priority streams might not be desired.  In this

Discussion:
Tried to make '4. Use of Streams' a little more readable around exposing max allowed/used/open stream info to applications. (Not a native speaker but my best-effort after reading the draft.)
Change:
If the agent is in the controlling role, and the ICE-CONTROLLING attribute is present in the request: <del> If the agent's tie-breaker is larger than or equal to the </del> <ins> If the agent's tie-breaker value is larger than or equal to the </ins> contents of the ICE-CONTROLLING attribute, the agent generates a Binding error response and includes an ERROR-CODE attribute with a value of 487 (Role Conflict) but retains its role. <del> If the agent's tie-breaker is less than the contents of the ICE-CONTROLLING attribute, the agent switches to the controlled role. </del> <ins> If the agent's tie-breaker value is less than the contents of the ICE-CONTROLLING attribute, the agent switches to the controlled role. </ins> If the agent is in the controlled role, and the ICE-CONTROLLED attribute is present in the request: <del> If the agent's tie-breaker is larger than or equal to the </del> <ins> If the agent's tie-breaker value is larger than or equal to the </ins> contents of the ICE-CONTROLLED attribute, the agent switches to the controlling role. <del> If the agent's tie-breaker is less than the contents of the ICE-CONTROLLED attribute, the agent generates a Binding error response and includes an ERROR-CODE attribute with a value of 487 (Role Conflict) but retains its role. </del> <ins> If the agent's tie-breaker value is less than the contents of the ICE-CONTROLLED attribute, the agent generates a Binding error response and includes an ERROR-CODE attribute with a value of 487 (Role Conflict) but retains its role. </ins> If the agent is in the controlled role and the ICE-CONTROLLING attribute was present in the request, or the agent was in the

Discussion:
Trying to avoid conflicts with txt files by creating a new pull request for the tie-breaker and role changes.
Change:
When a server rejects a request because its nonce value was unacceptable (or not present), it MUST provide HTTP status code 400 <del> (Bad Request), and indicate the ACME error code </del> <ins> (Bad Request), and indicate the ACME error type </ins> "urn:ietf:params:acme:error:badNonce".  An error response with the <del> "badNonce" error code MUST include a Replay-Nonce header with a fresh </del> <ins> "badNonce" error type MUST include a Replay-Nonce header with a fresh </ins> nonce.  On receiving such a response, a client SHOULD retry the request using the new nonce.

Discussion:
Usage of is slightly confusing when we are not using int-enumerated error codes. RFC 7807 also refers to the problem document error types as and the field is called so this seems to make the most sense.
Change:
assumptions about its content or structure. Two messages carrying the same Request-Tag is a necessary but not <del> sufficient condition for being part of the same operation.  They can still be treated as independent messages by the server (e.g. when it sends 2.01/2.04 responses for every block), or initiate a new operation (overwriting kept context) when the later message carries Block1 number 0. </del> <ins> sufficient condition for being part of the same operation.  For one, a server may still treat them as independent messages when it sends 2.01/2.04 responses for every block.  Also, a client that lost interest in an old operation but wants to start over can overwrite the server's old state with a new initial (num=0) Block1 request and the same Request-Tag under some circumstances.  Likewise, that results in the new message not being part of he old operation. </ins> As it has always been, a server that can only serve a limited number of block-wise operations at the same time can delay the start of the

Discussion:
Also includes changes to a paragraph that will be Section 3 after the pending intro-shoving. Rationale as in the review response mail: Reference made more precise, "from a single endpopoint" added. Split up into separate sentences for better clarity. That requirement was already kind of conditional on the client using Request-Tag for a particular purpose -- for otherwise the "unless concluded" clause makes no sense, for that's defined by the purpose. Rephrased to pull in the purpose before the MUST and make that explicit. The "that support Request-Tag" comment should be obsolete by hat, for only who supports it can use it for something. (We did, in the chat earlier, consider asking the WG whether that'd all mean that we're updating RFC7959, but as we're now back to "If you want to achieve X, do Y" wording, I don't see necessity for such an update). Added to the initial (now split up) paragraph of that section. Explicitly included as an option now. (Would have been even easier if there were a once-and-for-all definition of a "request-tag value" that can be absent or have the option's data, but that had long-winded wording in the last version that was in, and still might be mistaken by readers that don't have the precise definition at hand).
Looks good.
Change:
It returns the certificate_request_context. <del> 5.3. </del> <ins> 6.3. </ins> The "authenticate" takes as input:

Discussion:
URL you don't want to provide one. TLS allows Certificate to be empty, with a missing CertificateVerify and Finished as normal. That would be a nice change. Alternatively, we could insist on the using application managing this, but it seems like an authenticated refusal is nice.
Resolved in PR
Change:
The procedure is intended to permit or prohibit presence of a certain EKU or complete absence of EKUs.  It is outside the scope of this <del> document, but the relying party can permit or prohibit conbinations of EKU.  A consideration on prohibiting combination of EKUs is </del> <ins> document, but the relying party can permit or prohibit combinations of EKU.  A consideration on prohibiting combinations of EKUs is </ins> described in the security consideration section of this document. 2.1.  Excluded EKUs procedure "Excluded EKU" is an EKU which the

Discussion:
This PR contains corrections to more accurate expression. This PR does not contains modification related to backwards compatibility and interoperability.
Thanks Sean I approved all above modifications.
Change:
designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page. <del> 4.3. </del> <ins> 4.4. </ins> As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running

Discussion:
LGTM too, will resolve conflicts
If we resolve a name N1 to 1.1.1.1, should we pair it with relay candidates? If we do so, 1.1.1.1 will be sent to the TURN server, which seems like a leak (could be under the control of the web app). Probably need to add a section in the privacy considerations saying any remote mdns candidates MUST NOT be paired with local relay candidates (although the reverse should be OK).
I am thinking about the impact on the connectivity, and if we can ever resolve the remote mdns candidate, the chance of selecting relaymdns even if this is allowed could probably be low if the local side also gathers a host candidate. The MUST level lgtm.
yeah, and keep in mind that usually these host IPs will be things like 192.168.1.3 that are not even reachable by the outside world.
Well thought! Agreed, I always thought TURN and STUN were intertwined (TURN server is probably also a STUN server or at least hosted in the same network) so that we can use server reflexive candidates for TURN without losing much.
yeah - we already throw away private IPs for TURN to avoid creating connections that won't work, so the actual impact here is negligible.
LGTM
Change:
17.6. <del> A Handshake packet uses long headers with a type value of 0x3.  It is </del> <ins> A Handshake packet uses long headers with a type value of 0x2.  It is </ins> used to carry acknowledgments and cryptographic handshake messages from the server and client.

Discussion:
Handshake and Retry have the same type number in the text; assuming the table is correct, this aligns the text with the table.
Change:
The attacker redirects the "Finished" message to "C".  "C" has completed the handshake with "A". <del> This attack violates the peer authentication property, and if "C" supports a weaker set of cipher suites than "B", this attack also violates the downgrade protection property.  This rerouting is a type of identity misbinding attack Sethi.  Selfie attack Selfie is a </del> <ins> In this attack, peer authentication is not provided.  Also, if "C" supports a weaker set of cipher suites than "B", cryptographic algorithm downgrade attacks might be possible.  This rerouting is a type of identity misbinding attack Sethi.  Selfie attack Selfie is a </ins> special case of the rerouting attack against a group member that can act both as TLS server and client.  In the Selfie attack, a malicious non-member reroutes a connection from the client to the server on the

Discussion:
This deals with many comments from the AD Evaluation. The comment on section 6.1 still needs to be resolved, and the NITS need to be addressed.
Chris's suggestions generally seem reasonable
Change:
anchors.  Clients can fetch these alternates and use their own heuristics to decide which is optimal. <ins> An ACME client MAY attempt to fetch the certificate with a GET request.  If the server does not allow GET requests for certificate resources, then it will return an error as described in post-as-get. On receiving such an error, the client SHOULD fall back to a POST-as- GET request. </ins> A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new order process to request one.

Discussion:
As suggested by David Hancock, change the certificate fetch examples to use POST-as-GET, noting that GET is optional As suggested by Felix Fontein, use the correct error code for "malformed" in the description of what servers should do in response to inappropriate GET requests
Since doesn't look like it will be merged anytime soon, would it be possible to move the editorial (undisputed) stuff (trailing comma, authz -> challenge in URL) into this PR?
NAME I think I've gotten all the trailing commas and errant headersgit di.
NAME Looks good to me!
editorial clarifications, looks good to me.
Change:
In response to this request, the push server MUST generate a server push for all push messages that have not yet been delivered.  In addition, the push service SHOULD return link references to the push <del> and receipt subscribe resources, plus expiration information for the subscription. </del> <ins> and receipt subscribe resources. </ins> A user agent can request the contents of the push message subscription resource immediately by including a RFC7240 with a

Discussion:
Removed references to HTTP cache headers and RFC7234
LGTM
Tracking Darshak Thakore feedback: There was ambiguity about the type of "expiration information" returned: Also I'm assuming here that the "expiration information" refers to the expiration info of the push messages (i.e their TTL), correct? NAME has added a small clarification: URL but an example should be developed.
As discussed on the , the use of HTTP cache headers for graceful subscription expiration was deprecated. Our implementation is currently only reactive when it comes to subscription expiration. That means that we tolerate a break if the server is forced to expire a subscription. Note that the discussion from before was all predicated on a different design, one where individual subscriptions were subjugate to a larger "registration". The current design, even the with the addition of subscription sets, doesn't suffer from the ambiguity problem you described. However, after reviewing the HTTP cache control stuff in more detail, I think that it might be best to remove this feature. The use case (graceful replacement of a subscription), might be important, but I don't think that using response freshness as a proxy for subscription lifetime is correct. If we discover that there is a need, I think that an alternative mechanism will be required. A more direct signal an explicit "refresh now" message - might be a superior option. The consequence of that is that we will rely on the 4xx responses to inform user agents of when the push service has expired a subscription. For the moment, that's probably OK. The consequential drop in reliability should be low.
Change:
QUIC supports connection migration by the client.  If an IP address changes, a QUIC endpoint can still associate packets with an existing <del> transport connection using the destination connection ID field (see also connid) in the QUIC header, unless a zero-length value is used. This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an indication in the handshake of the server for a preferred address to be used. </del> <ins> transport connection using the Destination Connection ID field (see also connid) in the QUIC header.  This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an indication in the handshake of the server for a preferred address to be used. </ins> Use of a non-zero-length connection ID for the server is strongly recommended if any clients are behind a NAT or could be.  A non-zero-

Discussion:
You can associate packets with connections without a connection ID. So rather than say something that is factually incorrect, let's just leave the next paragraph to establish the right impression (that a connection ID is highly recommended). This text works without talking about zero-length connection IDs.
Change:
MUST provide a URI for the push resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push".  This enables the user agent to differentiate <del> the source of the message.  The response headers SHOULD provide a URI for the receipt subscribe resource in a link relation of type "urn:ietf:params:push:receipt".  The response body is the entity body from the most recent request sent to the push resource by an application server. </del> <ins> the source of the message.  The response body is the entity body from the most recent request sent to the push resource by an application server. </ins> A user agent can request the contents of the push message subscription set resource immediately by including a RFC7240 with a

Discussion:
LGTM, just one nit.
I think that having the push service return the link relation on requests to subscriptions (and subscription sets) is enough. I think that perhaps it was added to push messages in error.
cc NAME
Change:
These dependencies cause problems in practice.  Server operators often want to create short-lived certificates for servers in low- <del> trust zones such as Content Delivery Network (CDNs) or remote data </del> <ins> trust zones such as Content Delivery Networks (CDNs) or remote data </ins> centers.  This allows server operators to limit the exposure of keys <del> in cases that they do not realize a compromise has occurred.  The risk inherent in cross-organizational transactions makes it operationally infeasible to rely on an external CA for such short- lived credentials.  In Online Certificate Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension type ocsp RFC8446, if an operator chooses to talk frequently to the CA to obtain stapled responses, then failure to fetch an OCSP stapled response results only in degraded performance.  On the other hand, failure to fetch a potentially large number of short lived certificates would result in the service not being available, which creates greater operational risk. </del> <ins> in cases where they do not realize a compromise has occurred. However, the risk inherent in cross-organizational transactions makes it operationally infeasible to rely on an external CA for such short- lived credentials.  For instance, in the case of Online Certificate Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension type ocsp RFC8446), a CA may fail to deliver OCSP stapled response.  While this will result in degraded performance, the ramifications of failing to deliver short-lived certificates are even worse: the service that depends on those certificates would go down entirely.  Thus, ensuring independence from CAs for short-lived certificates is critical to the uptime of a service. </ins> To remove these dependencies, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own

Discussion:
Also fixed a few smaller grammatical/punctuation errors. Rationale from the mailing list: I think OCSP is being brought up here as an example of a way that dependence on a CA can go wrong, but that isn't really made explicit.I'm not sure what "only" means in "only in degraded performance." Is it "the worst that can happen is just degraded performance" or "it can result only in degraded performance, as opposed to better performance"? At first I thought it was the latter, but after reading the subsequent sentence, I realized it was probably the former.The use of "On the other hand" sounds like the rest of the sentence is going to describe a way that failure to receive something from a CA resulted in better performance, which obviously would be silly.
Change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This document uses the terminology established in QUIC-TRANSPORT.

Discussion:
For those drafts that are in AUTH48.
This PR makes me happy.9000! Very cool!
Change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This document uses the terminology established in QUIC-TRANSPORT.

Discussion:
kramdown-rfc2629 inserts a non-breaking space when expanding , which xml2rfc subsequently mangles to produce invalid XML. Rather than deal with that, insert the boilerplate with regular spaces instead. Note that this is necessary to make work properly, as that tool drops the non-breaking whitespace character between "BCP" and "14".
URL (I need to follow up regarding the use of non-breaking whitespace generally).
This seems fine, but I assume you've separately filed the appropriate bugs to fix the regular tools?