jiebi/CodeConvo huggingface dataset:
Change:
6.4. <ins> A client may wish to change the public key that is associated with a registration, e.g., in order to mitigate the risk of key compromise. To do this, the client first constructs a JSON object representing a request to update the registration: The string "reg", indicating an update to the registration. The JWK thumbprint of the old key RFC7638, base64url-encoded The client signs this object with the new key pair and encodes the object and signature as a JWS.  The client then sends this JWS to the server in the "newKey" field of a request to update the registration. On receiving a request to the registration URL with the "newKey" attribute set, the server MUST perform the following steps: Check that the contents of the "newKey" attribute are a valid JWS Check that the "newKey" JWS verifies using the key in the "jwk" header parameter of the JWS Check that the payload of the JWS is a valid JSON object Check that the "resource" field of the object has the value "reg" Check that the "oldKey" field of the object contains the JWK thumbprint of the account key for this registration If all of these checks pass, then the server updates the registration by replacing the old account key with the public key carried in the "jwk" header parameter of the "newKey" JWS object. 6.5. </ins> Once a client has created an account with an ACME server, it is possible that the private key for the account will be lost.  The recovery contacts included in the registration allows the client to

Discussion:
What advantage does including the old key provide?
Having the new key sign over the field makes the hand-over mutual -- the old key blesses the new key by signing over the JWS and the new key accepts by signing over the thumbprint. Basically, the field is acting as an identifier for the registration for purposes of the new key's acceptance of the hand-over. Note that this is well-defined because the server is required to only have one registration for a given key-pair (it MUST return a 409/Conflict if there's an attempt to duplicate).
Account keys should change over time to improve security. We should have a way to change the key associated with an account with changing anything else about the account. Something liike: Post: /rotate-key { "key": { / JWK key / } } Note: The request should be signed with the old key. All authorizations should remain with the account. If there are any requests being validated then they should still use the old key (as specified by the oriignal authorization request.
Change:
S was used to encrypt or (successfully) decrypt a message, or if a key, nonce, or secret derived from S has been consumed.  (This <del> goes for values derived via Derive-Secret as well as HKDF-Expand- Label.) </del> <ins> goes for values derived via DeriveSecret as well as ExpandWithLabel.) </ins> Here, S may be the "init_secret", "commit_secret", "epoch_secret", "application_secret" as well as any secret in the AS Tree or one of

Discussion:
In , we changed from using HKDF to using the KDF from HPKE, which I thought removed the need for the ciphersuite to specify a hash function. As a result, ciphersuites no longer needed to specify a hash. However, the transcript computations still have a raw invocation, not a KDF invocation. So we need to either: Change the transcript hash computations to use the KDF, or Clarify that ciphersuites still specify a hash function (as before)
What about the call in the and the "hashes" for ?
Our HPKE dependency provides a perfectly usable KDF. We should just use that instead of nailing a dependency to HKDF. This will mainly be a matter of changing and calls to the corresponding calls on the HPKE KDF.
I can't wait to see the implementations.
Thanks for the enthusiasm, but I don't think this is a spec issue :)
Change:
4. <del> To prevent PSK Importers from being confused with standard OOB PSKs we change the label used in the computation of the PSK binder key. In TLS 1.3 the PSK binder key computation is defined as follows: </del> <ins> A key importer diversifies an input EPSK into one or more PSKs advertised on the wire via a target protocol, KDF identifier, and optional context string.  Additionally, the resulting PSK binder key is modified with a new derivation label to prevent confusion with non-imported PSKs.  This section describes the diversification mechanism and binder key computation change. </ins> <del> We replace the string "ext binder" with "imp binder".  This means the binder key is now computed as follows: This new label differentiates non-imported and imported external PSKs.  Specifically, a client and server will negotiate use of an external PSK if and only if (a) both endpoints import the PSK or (b) neither endpoint imports the PSK.  The "binder_key" is a leaf key. Therefore, changing its computation doesn't affect any other key. 5. </del> <ins> 4.1. </ins> A key importer takes as input an EPSK with external identity "external_identity" and base key "epsk", as defined in terminology,

Discussion:
Addresses . cc NAME
The document says: Aside from this statement needing update in light of the changes to the binder label, the core statement here isn't expanded upon. The document needs to very clearly say that the PSK ID that is sent in the psk extension is literally the serialized content of .
Fixed in .
Change:
a comparison using the operator "==" yields true if and only if the comparison is between: <del> equal primitive values, </del> <ins> numbers expected to interoperate as per RFC7493 that compare equal using normal mathematical equality, numbers at least one of which is not expected to interoperate as per I-JSON, where the numbers compare equal using an implementation specific equality, equal primitive values which are not numbers, </ins> equal arrays, that is arrays of the same length where each element of the first array is equal to the corresponding

Discussion:
Fixes URL
The ABNF is not currently subject to the I-JSON range restriction that applies to array indices and array slice parameters, but I don't see why it shouldn't be.
I don't understand -- the grammar cannot express this restriction. Indices and slice parameters are integers, not numbers, BTW.
I was thinking of the integer subset of . It seems strange to have to cope with arbitrary precision integers there, but not for array indices and slices.
As for the grammar expressing the restriction, this is a question of validity rather than well-formedness.
Ah, so this would be a text fix.
Indeed. Sorry for the ABNF red herring. I was trying to be precise about which "number" I was talking about.
I guess we'll have to worry about decimal as well as integers in , for consistency. I wonder if there's a suitable precedent like the I-JSON range?
Hmm, is not really discussed in the unnumbered (argh) section "comparisons". (There is text for .)
How about this text?
(and in case anyone thinks we could get away with comparing the string forms of the numbers, remember scientific notation .)
Oh, I see now. We should mention the I-JSON restrictions for numbers, in the comparison section. That seems like a reasonable way to fix this issue.
the complement of "both interoperate" is "at least one doesn't interoperate"...
Change:
2. Clients are configured to use UDP Proxying over HTTP via an URI <del> Template TEMPLATE.  The URI template MUST contain exactly two variables: "target_host" and "target_port".  Examples are shown below: </del> <ins> Template TEMPLATE with the variables "target_host" and "target_port". Examples are shown below: The URI template MUST be a level 3 template or lower.  The URI template MUST be in absolute form, and MUST include non-empty scheme, authority and path components.  The path component of the URI template MUST start with a slash "/".  All template variables MUST be within the path component of the URI.  The URI template MUST contain the two variables "target_host" and "target_port" and MAY contain other variables.  The URI template MUST NOT contain any non-ASCII unicode characters and MUST only contain ASCII characters in the range 0x21-0x7E inclusive (note that percent-encoding is allowed). The URI template MUST NOT use Reserved Expansion ("+" operator), Fragment Expansion ("#" operator), Label Expansion with Dot-Prefix, Path Segment Expansion with Slash-Prefix, nor Path-Style Parameter Expansion with Semicolon-Prefix.  If any of the requirements above are not met by a URI template, the client MUST reject its configuration and fail the request without sending it to the proxy. </ins> Since the original HTTP CONNECT method allowed conveying the target host and port but not the scheme, proxy authority, path, nor query,

Discussion:
. That template contains the and variables which convey the target host/port in the pseudo-header. This has the following benefits: allows custom schemes allows proxy to pick path they use However it has downsides: it requires parsing URI templates which is more of a pain than it seems it prevents reusing the same configuration between CONNECT-UDP and CONNECT-IP Alternatively, we could replace the configuration URI template with a configuration URL, and instead convey the target host/port in separate HTTP headers. This has the same benefits of the URI template without the downsides.
Discussed this issue at IETF 112, consensus in the room was to keep the URI template but to tighten the template restrictions.
Change:
intervening servers, and the APIs that are offered for a Javascript application to take advantage of the browser's functionality. <del> Note that HTTP and WebSockets are also offered to the Javascript </del> <ins> Note that HTTPS and WebSockets are also offered to the Javascript </ins> application through browser APIs. As for all protocol and API specifications, there is no restriction

Discussion:
LGMT
ekr provided the following comment for s3: I would say HTTP(S) in this diagram.
Change:
signing contents that are consumed by people.  To be more precise, contents are intended to be shown to a person with printable or displayable form by means of services or software, rather than <del> processed by machines. </del> <ins> primarily processed by machines. </ins> 3.1.

Discussion:
Addressing Erik's . Given that documents may be presented to people "by means of ... software" perhaps a slight tweak to the "rather than processed by machines", e.g.: "rather than processed primarily by machines", or "rather than processed principally by machines" s/instead of single/instead of a single/ s/proresses/processes/ I think?
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, and without quotes. </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 specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234 and includes, by reference, the IMF-fixdate rule

Discussion:
This: Gets the editors' draft generated by the template using GitHub actions (was never set up) Fixes up some document metadata Updates the IANA considerations section to fit current practice
looks like this one didn't work as expected, NAME URL
Fixed.
Change:
Next, the leader extracts its own report shares and computes the initial preparation state for each as described in prep-start.  It then removes from the report sequence any report for which the <del> transition state is FAILED. </del> <ins> transition state is FAILED.  If the resulting sequence is empty, then the leader halts without issuing a request. </ins> Let "[aggregator]" denote the helper's API endpoint.  The leader extracts the sequence of report shares for "[aggregator]" and sends

Discussion:
Minor changes/clarifications: Clarify how to handle empty Transition sequences Handle repeated nonces by aborting. While at it, this changes how the helper handles unrecognized nonces to be consistent with how the leader handles unrecognized nonces. Move task/job ID to top of AggregateReq
Change:
MinimaLT <del> IKEv2 </del> <ins> IPsec </ins> Shared Secret Export (PSKE): The handshake protocol may provide an interface for producing shared secrets for application-specific

Discussion:
Address
URL Hi, I concur. However, I'd suggest changing the title of the section from "IKEv2 with ESP" to "IPsec". Regards, Valery.
Change:
A set of rules that direct how a Relying Party uses the Attestation Results regarding an Attester generated by the <del> Verifiers.  Compare /security policy/ in RFC4949. </del> <ins> Verifiers.  Compare: /security policy/ in RFC4949. </ins> Consumed by: Relying Party

Discussion:
Despite fixes in , Roman asks: [Roman's comments on -13] -- Section 4.1. In the definition of relying party, what does the sentence fragment "Compare /relying party/ in [RFC4949]" mean? -- Section 4.2. Per the definition of "Claim", what does "Compare /claim/ in [RFC7519]" mean? -- Section 4.2. Per the definition of "Appraisal Policy for Attestation Results", what does "Compare /security policy/ in [RFC4949]" mean? I continue to hold the position that this language "Compare /xxx/ in RFC####" is not clear. In the natural language sense, that phrase doesn't parse. If the semantics are being taken from Section 2.6 of RFC4949, please explain that. However, it seems confusing to explicitly be listing antonyms (which RF4949 suggests is the meaning of the "Compare" notation). In the case of a claim, is it an antonym -- isn't a claim here in fact similar to the one in Section 2 of RFC7519?
`
Change:
marked "No" range from "good" to "bad" from a cryptographic standpoint. <del> CCM_8 cipher suites are not marked as Recommended.  These cipher </del> <ins> CCM_8 cipher suites are not marked as recommended.  These cipher </ins> suites have a significantly truncated authentication tag that represents a security trade-off that may not be appropriate for general environments. <ins> IANA [SHALL add/has added] the following notes for additional information: </ins> The designated expert RFC8126 only ensures that the specification is publicly available. <ins> As specified in RFC8126, assignments made in the Private Use space are not generally useful for broad interoperability.  It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available. </ins> IANA [SHALL update/has updated] the reference for this registry to also refer to this document.

Discussion:
NAME let me know what you think.
I.e., if you actually deploy on the Internet with these experimental code points, and you run into someone using the same code point, you're going to have a bad day. For widespread experiments, we should really be using temporary reservations of some kind instead.
NAME NAME How about we add the following note everywhere we added private use: NOTE: : As specified in {{RFC5226}}, assignments made in the Private Use space "are not generally useful for broad interoperability." It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available.
LGTM.
Addressed by .
Change:
GI: GroupInfo objects <del> Recommended: Whether support for this extension is recommended by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. </del> <ins> Recommended: Same as in </ins> Reference: The document where this extension is defined

Discussion:
Also copies the "Recommended" field by reference, instead of reciting it in each registry. Note that this has a conflict with that will not catch -- "MLSContentTBS" will have to be changed to whatever new name is agreed in that PR.
The of absolutely needs to be unique for every signature happening in the protocol, for security and avoid signature ambiguity. That includes signatures happening in extensions. Should this be referenced in a IANA considerations to ensure there is no conflict in the future? Or at least say something about this somewhere? We have to think how to design things well here to be future-proof: the structure must be used for every signature done with the leaf signature keys, which includes what might happen in extensions but also in future versions of MLS. If future versions of MLS could avoid doing , that would be great!
This seems to come down to whether we expect the signature keys used for MLS authentication to be used outside of MLS (otherwise there's no risk of confusion) and if so, whether this spec has any influence on that usage. If you're using your MLS key to sign Bitcoin transactions, we can't do much to help that. Note that there is not an issue for future version of MLS here. The label is constructed as , so a future version could just increment the part of that. Given all that, I might prefer a recommendation that signature keys not be reused across contexts, rather than trying to accommodate reuse. If we do something here, we should do something analogous to the registry, which are similarly intended for domain separation between different use cases. We should probably consider making an exporter label registry anyway.
I agree, we shouldn't do anything about someone using the MLS signature key in another protocol. About future MLS versions: I agree, but note that there is a length tag before that. It means that we impose to all signature of future MLS versions to start with (including the quic integer) Is it something acceptable or not, I don't now. I just think we should have in mind that the decisions we make now on will have an impact on the design of future MLS versions. About extensions: in the extensions document, there is a signature computed with If two extensions were to use the same label then this could lead to security problems, this is why I think the labels should be in some registry to ensure they are all unique.

One other thing we could do is to separate all extensions signatures from the core MLS signatures, for exemple using the label "MLS 1.0 extension [label from extension]"? Like that a bogus extension can't introduce a security flaw in core MLS that way?
Change:
Note that the issuance protocol may separately involve user interaction if the client needs to be newly validated. <del> The use of interactive tokens can add user-perceivable latency, since such tokens cannot be pre-fetched.  Origins need not block useful work on token authentication.  Instead, token authentication can be used in similar ways to CAPTCHA validation today, but without the need for user interaction.  If issuance is taking a long time, a website could show an indicator that it is waiting, or fall back to another method of user validation. An origin MUST NOT issue more than one interactive challenge for a </del> <ins> If a client cannot use cached tokens to respond to a challenge (either because it has run out of cached tokens or the associated context is unique), the token issuance process can add user- perceivable latency.  Origins need not block useful work on token authentication.  Instead, token authentication can be used in similar ways to CAPTCHA validation today, but without the need for user interaction.  If issuance is taking a long time, a website could show an indicator that it is waiting, or fall back to another method of user validation. An origin MUST NOT use more than one redemption context value for a </ins> given token type and issuer per client request.  If an origin issues <del> a large number of challenges, such as more than once for each request, this can indicate that the origin is either not functioning correctly or is trying to attack or overload the client or issuance server.  In such cases, a client MUST ignore redundant token challenges for the same request and SHOULD alert the user if possible. </del> <ins> a large number of challenges with unique contexts, such as more than once for each request, this can indicate that the origin is either not functioning correctly or is trying to attack or overload the client or issuance server.  In such cases, a client MUST ignore redundant token challenges for the same request and SHOULD alert the user if possible. </ins> Origins MAY include multiple challenges, where each challenge refers to a different issuer or a different token type, to allow clients to

Discussion:
We should consider renaming to . This value doesn't need to be a nonce, it's just some origin-selected context that it is binding to. We can also rename the in the Token struct to to make it clear what role it has.
Change:
force the width definition without defining a superfluous element. In the following example, Taste will consume two bytes in the data <del> stream but can only assume the values 1, 2, or 4. </del> <ins> stream but can only assume the values 1, 2, or 4 in current version of protocol. </ins> The names of the elements of an enumeration are scoped within the defined type.  In the first example, a fully qualified reference to

Discussion:
with few possible exceptions, enumerateds will assume values different than the ones they were originally defined with. Backwards compatibility of Client Hello is dependent on implementations being able to ignore values they do not know about.
This doesn't seem quite right. Some enums are complete in the sense that you should not ignore unknown ones (HandshakeType) and some are not complete (ExtensionType, CipherSuite).
How about then "URL parse and ignore them unless the their deifnition states otherwise".?
sure that would be fine
Change:
the delegation, even though they are not themselves authoritative data. <ins> RFC4033, Section 2, defines "Authoritative RRset" which is related to authoritative data but has a more precise definition. </ins> "A lame delegations exists when a nameserver is delegated responsibility for providing nameservice for a zone (via NS records) but is not performing nameservice for that zone (usually

Discussion:
There is one typo at "Authoritative data:". Other differences are OK. | , Section 2, defines "Authoritative RRset" which is related | to authoritative data [bu] has a more precise definition. ("bu"is "but" ?)
I missed to change branch and I commited to this branch. please review "f172affe0f5d111af23f8c48f9ed5715e7b314d0".
Change:
The remainder of the Version Negotiation packet is a list of 32-bit versions which the server supports. <del> A Version Negotiation packet cannot be explicitly acknowledged in an ACK frame by a client.  Receiving another Initial packet implicitly acknowledges a Version Negotiation packet. </del> <ins> A Version Negotiation packet is not acknowledged.  It is only sent in response to a packet that indicates an unsupported version; see server-pkt-handling. </ins> The Version Negotiation packet does not include the Packet Number and Length fields present in other packets that use the long header form.

Discussion:
This is a left-over from removing version negotiation from the draft.
by a client. Receiving another Initial packet implicitly acknowledges a Version Negotiation packet. This seems like old text from when we removed real VN. I think that you just need to say that no ACK is required because you only send it in response to Initial.
LGTM