jiebi/CodeConvo huggingface dataset:
Change:
This specification allocates a CBOR tag to mark Unprotected CWT Claims Sets (UCCS) as such and discusses conditions for its proper <del> use in the scope of Remote Attestation Procedures (RATS) in the usage scenario that is the conveyance of Evidence from an Attester to a Verifier. </del> <ins> use in the scope of Remote Attestation Procedures (RATS RFC9334) in the usage scenario that is the conveyance of Evidence from an Attester to a Verifier. </ins> This specification does not change RFC8392: A true CWT does not make use of the tag allocated here; the UCCS tag is an alternative to

Discussion:
Archived-At:
straight forward. :ship: it! A few comments/questions for WGLC: The secure channel definition in section 1.1 may benefit from stating that mutual authentication is not required. This is hinted at by stating "the same qualities" as CWT conveyance are required but, given the NIST definition requires mutual auth, additionally saying mutual auth is not required would be clearer.In section 3.1.2, perhaps change the end of the last sentence to "using a Detached-Submodule-Digest or Detached-EAT-Bundle" since the Detached-Submodule-Digest is what conveys the hash and can be used independent of a Detached-EAT-Bundle.In Table 1 in Section 4, should the Data Item be Claims-Set instead of map? The registry is inconsistent. Some definitions are general with only map or array listed, others identify a specific type, e.g., the COSE types.There is a TODO in Appendix A and a note to insert definitions from 9052.The CDDL should include the tag definition that is the focus of this draft, something like: UCCS = .TBD601(Claims-Set) Independent of this draft, many current specs that use CDDL (including this one) repeat definitions that appear elsewhere. Perhaps it is close to time to discontinue this practice, publish an I-D or two that provide CDDL definitions for specs that predate CDDL (like RFC5911 and 5912 did for ASN.1), and then have future specs only define new things. On 1/11/23, 1:27 PM, "RATS on behalf of Henk Birkholz" on behalf of EMAIL > wrote: Dear RATS WG, this I-D should now be ready for WGLC. Viele Grüße, Henk RATS mailing list EMAIL URL
Change:
Adding a digital signature to each encrypted frame will be an overkill, instead we propose adding signature over multiple frames. <del> The signature is calculated by contatenating the authentication tags </del> <ins> The signature is calculated by concatenating the authentication tags </ins> of the frames that the sender wants to authenticate (in reverse sent order) and signing it with the signature key.  Signature keys are exchanged out of band along the secret keys.

Discussion:
Rewrite the Key management section Add MLS subsection Update the SFrame format Fixed typos
Change:
are blocked by the captive portal This document is focused on the second step.  It is assumed that the <del> location of the Captive Portal API server has been provisioned as part of the first step.  The mechanism for discovering this value not covered by this document. </del> <ins> location of the Captive Portal API server has been discovered by the host as part of the first step.  The mechanism for discovering the API Server endpoint is not covered by this document. </ins> 3. 3.1. <del> In order to communicate with the captive portal API server, the URI provisioned to the host SHOULD use the form of a well-known URI RFC5785 ending with the string ".well-known/captive-portal.json".  If this suffix is not included in the URI already provisioned, a host SHOULD append the suffix when communicating to the server. The Captive Portal API MUST be accessed using HTTP over TLS on TCP port 443 (HTTPS) RFC2818. </del> <ins> The URI of the API endpoint MUST be accessed using HTTP over TLS (HTTPS) and SHOULD be served on port 443 RFC2818.  The host SHOULD NOT assume that the URI for a given network attachment will stay the same, and SHOULD rely on the discovery or provisioning process each time it joins the network.  Depending on how the Captive Portal system is configured, the URI may be unique for each host and between sessions for the same host. </ins> For example, if the Captive Portal API server is hosted at <del> example.org, the URI of the API would be: "https://example.org/.well- known/captive-portal.json". </del> <ins> example.org, the URI's of the API could be: "https://example.org/captive-portal/api" "https://example.org/captive-portal/api/X54PD" </ins> 3.2.

Discussion:
Removed language for /.well-known URI. Made serving over port 443 a SHOULD requirement. Other editorial changes
Added your updated language, should be good to go.
I don't think that we need this. 7710 gives us an entire URI, as can PvD.
I agree that we can use the URI from the DHCP option or from PvD. The reason I went this route was to avoid the scheme that was in the API draft to start with, which seemed to be: If you access the 7710 URI with a GET, you'll receive the HTTP for the user interactive portal If you access the 7710 URI with a POST, you'll get the JSON API That seemed problematic (a) because it implies the user portal and API are co-located and (b) it seemed overly complex. Do you have a preference for what methods are valid to access the JSON API, and whether we should specify that the URI needs to be JSON? My concern was that if the DHCP option or whatever pointed to something that was clearly .html, something's wrong, and using a well-known JSON URI to compare against would be a way to detect that.
NAME Thoughts on the method for fetching the JSON API, or if that's a non-issue?
Let's take this to the list.
PR fixes the well-known URI language. For now there is indication of Accept and Conent-Type header usage but we haven't explicitly called it out until we get a final decision. We can close this issue though.
Change:
CWT, X.509, C509).  None of the credential types are mandatory-to- implement. <del> Implementations MUST support the EDHOC-Exporter.  Implementations SHOULD support EDHOC-KeyUpdate. </del> <ins> Implementations MUST support the EDHOC-Exporter. </ins> Implementations MAY support message_4.  Error codes (ERR_CODE) 1 and 2 MUST be supported.

Discussion:
Replacing a session key with its hash for forward secrecy as specified with EDHOC-KeyUpdate, can alternatively be defined by the application as is done in KUDOS (draft-core-oscore-key-update). For this reason there is no need to recommend EDHOC-KeyUpdate as is done in Section 7. "Implementations SHOULD support EDHOC-KeyUpdate." EDHOC-KeyUpdate can useful in other applications but the description should be moved out of the body in the interest of focusing on the core functionality of EDHOC.
Discussed in the interim and PR merged.
Change:
The parties exchanging messages are called Initiator (I) and Responder (R).  They exchange ephemeral public keys, compute a shared <del> secret key PRK_out, and derive symmetric application keys used to protect application data. </del> <ins> secret session key PRK_out, and derive symmetric application keys used to protect application data. </ins> G_X and G_Y are the ECDH ephemeral public keys of I and R, respectively.

Discussion:
Issue
Minor comment, but reading through all the security claims, they multiple times refer to the term (for instance in ), which is not per say completely defined. I am not even sure there is any ambiguity, but is it still worth adding somewhere that this relates to ?
Yes, I assume session key most often refer to PRK_out. Could maybe refer to the exported application keys in some sentence. Let's go through all instances and make it clear what it refers to.
Change:
suites can be identified with any of the four values -24, -23, -22, -21. <del> The following cipher suites are for constrained IoT where message overhead is a very important factor: The following cipher suite is for general non-constrained applications.  It uses very high performance algorithms that also are widely supported: The following cipher suite is for high security application such as government use and financial applications.  It is compatible with the CNSA suite CNSA. </del> <ins> The following CCM cipher suites are for constrained IoT where message overhead is a very important factor.  Cipher suites 1 and 3 use a larger tag length (128-bit) in the EDHOC AEAD algorithm than the Application AEAD algorithm (64-bit): The following ChaCha20 cipher suites are for less constrained applications and only use 128-bit tag lengths. The following GCM cipher suite is for general non-constrained applications.  It uses high performance algorithms that are widely supported: The following two cipher suites are for high security application such as government use and financial applications.  The two cipher suites do not share any algorithms.  The first of the two cipher suites is compatible with the CNSA suite CNSA. </ins> The different methods use the same cipher suites, but some algorithms are not used in some methods.  The EDHOC signature algorithm is not

Discussion:
Looks good. One inconsistency is that there is no cipher suite with AES-GCM and NIST curves, like (A128GCM, SHA-256, P-256, ES256, A128GCM, SHA-256). This could be a new cipher suite 5. Then all non-CNSA suites would come in pairs.
That is very intentional. The GCM cipher suite uses X25519 for key exchange and ECDSA for authentication. This seems to be the dominant choice for HTTPS on the Web. Unless you are constrained you typically use X25519 for key exchange for speed and ECDSA for authentication as that is what the CAs support. For an IoT device you probably want to have a single curve implemented. Also it might be much easier to switch to EdDSA as you might not have to rely on Global CAs and all other HTTPS nodes to support EdDSA. You can just deploy you own CWT server and make sure the nodes in you new IoT deployment support EdDSA. I have not heard any IoT people very interested in GCM. People seems far more interested in ChaCha20.
Ready to merge?
Is it worth having 4 diiference CCM based ciphser suites. And are they the correct 4?EDHOC should probably have a ChaCha20-Poly1305 cipher suite from start. Probably with SHA-256. X25519 and EdDSA.The CNSA cipher suite does not really need a 1 byte value. Could live with 2 byte value.
-Agreement during interim is that the 4 different CCM are all needed and that they are the correct ones. -ChaCha20 should be combined with both P-256 and X25519 -CNSA suite can have two bytes.
I think we should specify a X448/SHAKE256 suite to complement the CNSA suite.
The GCM suite is chosen to match what is currently used on the web which is X25519 combined with P-256 ECDSA. Not sure we need to specify anything else here. IoT community seems more interested in ChaCha20 than GCM. ~~
URL
Resolved with .
Change:
By default, WebRTC should be able to negotiate direct peer-to-peer connections between endpoints (i.e., without traversing a NAT or <del> relay server).  This ensures that applications that need true peer-to-peer routing for bandwidth or latency reasons can operate successfully. </del> <ins> relay server) when such connections are possible.  This ensures that applications that need true peer-to-peer routing for bandwidth or latency reasons can operate successfully. </ins> It should be possible to configure WebRTC to not disclose private local IP addresses, to avoid the issues associated with web

Discussion:
There is an implicit "where possible" here. The specific scenario is for two devices behind the same NAT who could communicate directly if only they knew each others' addresses; in this case, a direct connection should be possible, which implies that there needs to be some way for the two sides to share their machine addresses. Naturally, devices behind different NATs will not be able to do this. Noted.
Change:
by the recipient, the remainder of the stream cannot be consumed as the semantics are unknown.  Recipients of unknown stream types MAY trigger a QUIC STOP_SENDING frame with an error code of <del> HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT consider such streams to be a connection error of any kind. </del> <ins> HTTP_STREAM_CREATION_ERROR, but MUST NOT consider such streams to be a connection error of any kind. </ins> Implementations MAY send stream types before knowing whether the peer supports them.  However, stream types which could modify the state or

Discussion:
There are presently several kinds of very similar error when creating streams: HTTPUNKNOWNSTREAMTYPE MAY be used to tell a peer to STOPSENDING on a stream type that is unknown by the local peer. It is not a connection error. HTTPWRONGSTREAMCOUNT MUST be used if a peer tries to open more than one critical stream (control, QPACK). Connection error. HTTPWRONGSTREAMDIRECTION MUST be used if a client tries to open a push stream. More generally this could be used if a peer attempts to open a stream type that is not allowed to, but push is the only example today. Connection error. The suggestion is to rationalize these into a single error code - HTTPSTREAMCREATIONERROR - that can be used in STOPSENDING or CLOSECONNECTION. The impact of merging COUNT and DIRECTION is minimal because implementations fundamentally have to open streams correctly in order to interop. PS. The eagle eyes will notice I omitted the HTTPDUPLICATE_PUSH creation error. This is on the chopping block in . I class it differently because it is about parsing information after the stream type.
Should a client respond with STREAMCREATIONERROR when it sees the server opening a bidirectional stream? At the moment the designated error code is HTTPGENERALPROTOCOLERROR, but STREAMCREATIONERROR might be a better fit. Or if we are not going to use STREAMCREATIONERROR for server-initiated bidirectional streams, I think we should better rename it to UNIDIRECTIONALSTREAMCREATIONERROR to avoid confusion.
This relates to some earlier discussion on URL and its now-merged PR URL We only recently added text to specify the use of HTTPGENERALPROTOCOLERROR in this case, I think it fits to modify this to STREAMCREATION_ERROR.
Changed in URL
Change:
CollectReq pa-collect: "message/ppm-collect-req" <del> CollectResult pa-collect: "message/ppm-collect-result" </del> <ins> CollectResp pa-collect: "message/ppm-collect-resp" </ins> The definition for each media type is in the following subsections.

Discussion:
CollectResp is paired with CollectReq; naming things this way matches other {Req, Resp} message pairs.
Change:
"encrypted_client_hello" appears in OuterExtensions. <del> OuterExtensions contains duplicate values. </del> The extensions in ClientHelloOuter corresponding to those in OuterExtensions do not occur in the same order.

Discussion:
There are two reasons for this. First, the algorithm in Appendix B for decoding the EncodedClientHelloInner doesn't actually enforce this. Second, aborting on duplicated extensions is slightly stricter than RFC 8446 requires. It states that "[t]here MUST NOT be more than one extension of the same type in a given extension block", but doesn't specify what the receiver does in this case.
Change:
First the aggregator checks that the request's batch interval respects the boundaries defined by the PPM task's parameters. Namely, it checks that both "batch_interval.start" and <del> "batch_interval.end" are divisible by "min_batch_duration" and that "batch_interval.end - batch_interval.start >= min_batch_duration". Unless both these conditions are true, it aborts and alerts the peer with "invalid batch interval". </del> <ins> "batch_interval.duration" are divisible by "min_batch_duration" and that "batch_interval.duration >= min_batch_duration".  Unless both these conditions are true, it aborts and alerts the peer with "invalid batch interval". </ins> Next, the aggregator checks that the request respects the generic privacy parameters of the PPM task.  Let "X" denote the set of

Discussion:
While reviewing , NAME and I figured out a way to redefine so that invalid values cannot be represented[1]. The existing representation contains and , which means an interval could be defined with , which is invalid. Redefining as a start instant and a duration makes it impossible to represent invalid s (since is an unsigned integer). Additionally, this implicitly fixes a bug in the batch interval validation logic: we asserted that should be divisible by , but since is excluded from the , I think that was incorrect. Instead, should be divisible by . In any case, this is simpler with the new definition of : needs to be a multiple of . [1]: URL
Nice!
Change:
"recvonly", enable receipt and decoding of media. Finally, if this description is of type "pranswer" or "answer", <del> follow the processing defined in the sec.applying-an-answer section below. </del> <ins> follow the processing defined in sec.applying-an-answer below. </ins> 5.9.

Discussion:
This addresses Adam's actual comment - and adds the first references to rollback in the processing section - but leaves the details to be filled in by a future PR.
LGTM
Change:
A random value that uniquely identifies the challenge.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters <del> outside the URL-safe Base64 alphabet and MUST NOT contain any padding characters ("="). </del> <ins> outside the base64url alphabet and MUST NOT contain any padding characters ("="). </ins> A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and

Discussion:
Also fix an example date and fix an RFC reference to not be redundant.
Merging based on manual review, since CircleCI for PRs seems to be busted.
Change:
a sequence of 32-bit little-endian integers. The encryption mask is produced by invoking ChaCha20 to protect 5 <del> zero bytes.  In pseudocode: </del> <ins> zero bytes.  In pseudocode, the header protection function is defined as: </ins> 5.5.

Discussion:
This could have been more explicit, so now it is. Doubly so.
Section 5.4.1, Figure 6: mask = headerprotection(hpkey, sample) I think it is a bit unclear that the headerprotection function is what is producing the stream cipher cipher text that will be masked and xored with the header bits. Especially as the instantiations of these functions for AESGCM (Section 5.4.3) and ChaCha20 (Section 5.4.4) is not defined as instantiation of that function, only as providing the same variable output. I think this could be clarified in both places so that the linkage between the general application and the stream cipher producing function is clear.
Looks good and resolve my issue.
indubitably
Change:
formats, a way to describe them, a session description, is needed. Connection management: Setting up connections, agreeing on data <del> formats, changing data formats during the duration of a call; SIP and Jingle/XMPP belong in this category. </del> <ins> formats, changing data formats during the duration of a call; SDP, SIP, and Jingle/XMPP belong in this category. </ins> Presentation and control: What needs to happen in order to ensure that interactions behave in a non-surprising manner.  This can

Discussion:
ekr had the following comment: You should probably list DTLS, SCTP, and SDP in this section. It's not like we haven't decided we need them.
LGTM with nits
Change:
malformed or incomplete message.  In particular, redundant length encodings MUST be verified to be self-consistent. <del> When a stream carrying capsules terminates cleanly, if the last capsule on the stream was truncated, this MUST be treated as a malformed or incomplete message. </del> <ins> If the receive side of a stream carrying capsules is terminated cleanly (for example, in HTTP/3 this is defined as receiving a QUIC STREAM frame with the FIN bit set) and the last capsule on the stream was truncated, this MUST be treated as a malformed or incomplete message. </ins> 3.4.

Discussion:
End of section 3.3. (error handing) says: Not sure I can parse that sentence correctly. Is that ?
"terminates cleanly" is an abstract way of covering all HTTP versions notion of a stream FIN. This is not well defined (maybe lost in one of the restructuring edits?). If we think of HTTP/3 and the request stream being FIN'd at a particular offset, that is independent of a parser acting on the data in the stream. I think the way to make this clearer is to define or reference stream closures in respective HTTP docs.
How about this?
I don't understand the sentence structure here: When ..., if ..., then. Why is there a when and an if with a comma? May this should be: When ... and if ..., then? Sorry if that is grammatically correct but it really confuses me what the sentence is supposed to say... P.S.: clarifying the term "terminates cleanly" is also a good idea though.
We could rephrase as How does that sound?
Yes, that works for me. Thanks!
LGTM modulo nit
Change:
If multiple nodes would match a fragment identifier, the first such match is selected. <del> A fragment identifier is not guaranteed to reference an existing node.  Therefore, applications SHOULD define how an unresolved alias node ought to be handled. </del> Users concerned with interoperability of fragment identifiers: SHOULD limit alias nodes to a set of characters that do not

Discussion:
includes clarification on JSON Pointer and alias nodes compatibility includes FAQ fragment identifier moved from media type to section empty fragment + are both under JSON Pointer
cc: NAME NAME PTAL
According to NAME this PR should better clarify JSON Pointer use, so I am going to merge it. The decision on forcing +yaml fragment is deferred to that I will rebase.