jiebi/CodeConvo huggingface dataset:
Change:
5.2.1. <del> The Certificate message contains the certificate to be used for authentication and any supporting certificates in the chain.  This structure is defined in TLS13, Section 4.4.2. </del> <ins> The Certificate message contains the identity to be used for authentication, such as the end-entity certificate and any supporting certificates in the chain.  This structure is defined in TLS13, Section 4.4.2. </ins> <del> The certificate message contains an opaque string called </del> <ins> The Certificate message contains an opaque string called </ins> certificate_request_context, which is extracted from the authenticator request if present.  If no authenticator request is provided, the certificate_request_context can be chosen arbitrarily but MUST be unique within the scope of the connection and be unpredictable to the peer. <del> The certificates chosen in the Certificate message MUST conform to the requirements of a Certificate message in the negotiated version of TLS.  In particular, the certificate chain MUST be valid for the a </del> <ins> Certificates chosen in the Certificate message MUST conform to the requirements of a Certificate message in the negotiated version of TLS.  In particular, the certificate chain MUST be valid for the a </ins> signature algorithms indicated by the peer in the "signature_algorithms" and "signature_algorithms_cert" extension, as described in Section 4.2.3 of TLS13 for TLS 1.3 or the

Discussion:
This changes a lot of text, since many places (perhaps rightfully so) assume the contents of the Certificate message are a normal X509 certificate. Some uses of EAs might just use the Certificate message as a vehicle for other identifying information. Thus, rather than box ourselves into a corner, this change generalizes the purpose of this Certificate to be that of an identity. Addresses .
The document's currently written in such a way that one might assume it can only be used to authenticate additional certificates. For example, the introduction states: (emphasis mine!) However, [1] suggests that other authentication mechanisms are possible. (Meta observation and question: what are the contents of the Authenticator messages in the OPAQUE EA flow? Section 6 discusses the possibility of an empty Authenticator, but the OPAQUE flow uses the extension to provide the server response. What OPAQUE seems to require is an empty but non-empty .) Perhaps we should generalize certificate-based authentication to arbitrary challenge-response authentication mechanisms? [1] URL
cc NAME
Change:
RFC8406: End-to-End Coding (E2E), Network Coding (NC), Intra-Flow Coding (IntraF), Inter-Flow Coding (InterF), Single-Path Coding (SPC) and Multi-Path Coding (MPC).  This document refers to coding as both <del> End-to-End Coding and Network Coding, to cover cases where where recoding operation at intermediate nodes are or not.  From the UDP/IP </del> <ins> End-to-End Coding and Network Coding, to cover cases where recoding operation at intermediate nodes are or not.  From the UDP/IP </ins> packetization to the channel coding, link layer coding is required so that the physical-layer knows what coding scheme to use.  Following the taxonomy document RFC8406, channel and link codings are gathered

Discussion:
A few document nits… Section 2, 1st and 2nd Sentences “in satellite system” should be “in a satellite system”. Not clear what “lays” means here. “multi-gateway satellites network” should be “multi-gateway satellite network”. (Most of the uses cases have nothing to do with multi-gateway, though.) Section 3, 2nd Sentence Delete the duplicate “where”. Section 6, 2nd Sentence “that the some scenarios” should be “that some scenarios”.
Thanks for having identified the NITS. Closed by PR
Change:
This specification defines the following protocol messages, along with their corresponding media types: <ins> Token issuer directory: "application/token-issuer-directory" </ins> TokenRequest: "application/private-token-request" TokenResponse: "application/private-token-response"

Discussion:
The caption for is: "'xxx' Well-Known URI", which is probably wrong.
This is a bit of a hard one to decide for me, but I think that you want to define a media type for the JSON directory. I know that in most cases the content will be served from a .well-known location, but that isn't always.
What would be the benefit of a media type here if the content will always be JSON? That is, I don't see how a media type would influence consumers of the resource.
So that you can make it clear that it is this specific JSON, as opposed to some other JSON.
The table appears without the text referring to it, even with an "as follows". It might be better to reference it directly.
Change:
The cryptographic methods used by GNAP for key-proofing can support both asymmetric and symmetric cryptography, and can be extended to <del> use a wide variety of mechanisms.  While symmetric cryptographic systems have some benefits in speed and simplicity, they have a distinct drawback that both parties need access to the same key in order to do both signing and verification of the message.  This means that when the client instance calls the AS to request a token, the AS needs to know the exact value of the client instance's key (or be able to derive it) in order to validate the key proof signature. With asymmetric keys, the client needs only to send its public key to the AS to allow for verification that the client holds the associated private key, regardless of whether that key was pre-registered or not with the AS. </del> <ins> use a wide variety of mechanisms.  Implementers will find useful the available guidelines on cryptographic key management provided in RFC4107.  While symmetric cryptographic systems have some benefits in speed and simplicity, they have a distinct drawback that both parties need access to the same key in order to do both signing and verification of the message.  This means that when the client instance calls the AS to request a token, the AS needs to know the exact value of the client instance's key (or be able to derive it) in order to validate the key proof signature.  With asymmetric keys, the client needs only to send its public key to the AS to allow for verification that the client holds the associated private key, regardless of whether that key was pre-registered or not with the AS. </ins> When used to bind to an access token, a key value must be known by the RS in order to validate the proof signature on the request.

Discussion:
Built To edit notification comments on pull requests, go to your .
Please take a look a BCP 107 (a.k.a. RFC 4107). You may need a reference here. Originally posted by NAME in URL
Ok but should this text be updated ? In 2005, potential quantum threats were not even anticipated (with impacts on key size for instance)
I think the overall message remains accurate, but you are right that quantum computing was not a concern when RFC 4107 was written. Any updates to RFC 4107 are not part of your task in the GNAP WG.
Sure, thanks for the feedback.
Change:
Note: The connection_id extension is defined in DTLS-CID, which is used in ClientHello and ServerHello messages. <ins> If no CID is negotiated, then the receiver MUST reject any records it receives that contain a CID. </ins> 10. Application data messages are carried by the record layer and are

Discussion:
NAME NAME
Well, clients can recover by tearing down the connection and starting over.
Sure, sure. I think this was in the context of a "single" connection. Perhaps it's not that important to clarify?
I'll add text.
I think the only comment that's left to be addressed is this: Perhaps what's missing is precisely that clarifying statement. Namely, that clients which find themselves in such a situation cannot recover.
Change:
described in relative-indexing. To save space, the Base is encoded relative to the Insert Count using <del> a one-bit sign and the "Delta Base" value.  A sign bit of 0 indicates that the Base is greater than or equal to the value of the Insert Count; the value of Delta Base is added to the Insert Count to </del> <ins> a one-bit sign ('S') and the "Delta Base" value.  A sign bit of 0 indicates that the Base is greater than or equal to the value of the Insert Count; the value of Delta Base is added to the Insert Count to </ins> determine the value of the Base.  A sign bit of 1 indicates that the Base is less than the Insert Count.  That is:

Discussion:
Renamed S bit for static vs dynamic table to T bit (for Table) Replaced backticks with single quotes around individual bits (previously, about half used single, half used double) Added explicit references to bit letter indicators where they were missing (e.g., for 'H') Fixed broken reference to "blocked-decoding" section
As for 'B' vs , transport doc just uses (B). Maybe we should follow suit, bui I can do in a separate pass.
Change:
community for many reasons, and may be significantly changed in the future.  One example of the difficulty of calling a domain a public suffix is that designation can change over time as the <del> registration policy for the zone changes, such as the case of the "uk" TLD around the time this document is published. </del> <ins> registration policy for the zone changes, such as was the case with the "uk" TLD in 2014. </ins> 3.

Discussion:
…st label', and remove dbound. Fix affiliation. I suggest these before publication. This addresses issue 18.
Yep, these all seem great.
Change:
If any of these conditions is not met, the Issuer MUST return an HTTP 400 error to the Client, which will forward the error to the client. <del> 6.2. If the Issuer is willing to produce a token token to the Client, the Issuer completes the issuance flow by computing a blinded response as follows: </del> <ins> Otherwise, if the Issuer is willing to produce a token token to the Client, the Issuer completes the issuance flow by computing a blinded response as follows: </ins> This is encoded and transmitted to the client in the following TokenResponse structure:

Discussion:
ends with two paragraphs that really belong in Section 5.2, because they are about the processing of the request.
Change:
Also, features of the target dialect such as capture groups may be triggered inadvertently, reducing performance. <del> The present specification defines an interoperable regexp flavor for matching, I-Regexp.  This flavor is a subset of XSD regexps.  It also comes with defined rules for converting the regexp into common parsing regexp dialects. 2. I-Regexps should handle the vast majority of practical cases where a matching regexp is needed in a data model specification or a query language expression. A brief survey of published RFCs yielded the regexp patterns in Appendix A (with no attempt at completeness).  These should be covered by I-Regexps, both syntactically and with their intended semantics. 3. </del> <ins> 6.1. </ins> XSD Regexps are relatively easy to implement or map to widely implemented parsing regexp dialects, with a small number of notable

Discussion:
This has had the motivation and background material moved into new sections after the syntax and semantics. The opening section have been RFC-i-fied a bit, with one MUST each for syntax and semantics.
Change:
UDP Connections can only generate errors on initiation due to port conflicts on the local system. <del> Once in use, UDP throws "soft errors" (ERROR.UDP(-Lite)) upon receiving ICMP notifications indicating failures in the network. Additional information can also be provided when this is available to the system (e.g.  ICMP error code and quoted packet header). </del> <ins> UDP Connections can only generate connection errors in response to "Abort" calls.  (Once in use, UDP Connections can also generate "SoftError" Events (ERROR.UDP(-Lite)) upon receiving ICMP notifications indicating failures in the network.) </ins> LISTEN.UDP.  Calling "Listen" for UDP binds a local port and prepares it to receive inbound UDP datagrams from peers.

Discussion:
This PR covers steps 1 and 2 in . When aligning the error events for UDP multicast I also noticed that the text for UDP was not correct as soft errors do not generate ConnectionError events so also attempted to fix this.
NAME what's the reason for having Abort cause an error, rather than just moving to closed?
NAME This comes from the API draft, which says:
Great, thank you!
Change:
TLS consists of two primary components: <del> A handshake protocol (handshake-protocol) which authenticates the </del> <ins> A handshake protocol (handshake-protocol) that authenticates the </ins> communicating parties, negotiates cryptographic modes and parameters, and establishes shared keying material.  The handshake protocol is designed to resist tampering; an active attacker

Discussion:
Some suggested nits for s1: adding a semi-colon and swapping two whichs for thats.
Change:
elliptic curve certificates for DC-enabled traffic, while using RSA certificates without the DelegationUsage certificate extension for non-DC traffic; this completely prevents such attacks. <ins> Note that if a signature can be forged over an arbitrary credential, the attacker can choose any value for the valid_time field.  Repeated signature forgeries therefore allow the attacker to create multiple delegated credentials that can cover the entire validity period of the certificate.  Temporary exposure of the key or a signing oracle may allow the attacker to impersonate a server for the lifetime of the certificate. </ins>

Discussion:
NAME please go ahead and merge after resolving conflicts!
From Martin: The security considerations don't cover the potential for misissuance creating a credential that is as long-lived as the certificate, but they probably should.
NAME I'm not sure what you mean here. Are you talking about explicitly calling out the possibility that the credential may expire after the certificate and that this should be forbidden?
If you are able to access the signing key of the certificate, or are otherwise able to construct a DC, you can create multiple DCs that cover the time from now until the certificate expires. It's not a big deal, but I thought it might be worth noting.
Gotcha. I'll note this.
Closed in
Change:
11. Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran, <del> Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, and Will Law for very helpful suggestions, reviews and comments. </del> <ins> Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, and Will Law for very helpful suggestions, reviews and comments. </ins> 12.  References

Discussion:
I made one change to the links, because this gets a 404: URL But a web search for "SCTE-214-1" found this instead, which seems to be a new location for the same thing: URL Additionally, There were 3 more links that failed check-URL URL URL URL All of these get something with chrome, but fail with curl. The datazoom links get a 403 and the iabtechlab gets a 406. (Changing the UA header to match chrome's made curl succeed with iabtechlab, but not the datazoom links. Didn't dig deeper yet.) I haven't put in automation for this, but I figure it's useful to have something at least to do a quick scan.
This works. These work just fine for me on chrome no 403 or 406, plain 200.
They work for me in chrome also, but they don't work in curl or wget so the script complains about them.
Looks good to me, modulo a Github Action error that we don't understand. Will merge now, so we can move forward.
Just make the change for ACM Mile-High Video Conference.
Change:
expected use of OSCORE, to prevent weakening the security assurances provided by OSCORE. <del> 6. </del> <ins> TODO: explain the rationale for the nonces construction, and the security implications for Man-in-the-Middle attacks. 7. </ins> TBD. <del> 7. </del> <ins> 8. </ins> Note to RFC Editor: Please replace all occurrences of "[[this specification]]" with the RFC number of this specification and delete

Discussion:
restructuring for readability adding a section for protocol overview adding examples for each message adding details about updating clients rights (request new token with only scope different) where before there were ref to the framework, explicitly state all the normative text add mechanism during OSCORE Setup for making sure the context is not reused on the server if token is re-posted after it has been lost/removed (nonces) added section about access rights verification between OSCORE layer and CoAP (handling of the resource) layer
Change:
Therefore, it is not favorable to use a vendor defined EKU for signing a document that is not governed by the vendor. <del> This document defines a general Document Signing extended key usage. </del> <ins> This document defines a general Document Signing extended key purpose identifier. </ins> 2.

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:
Intra-data-center communication.  Machine-to-machine communication within a single data center or PoP may use externally provisioned PSKs, primarily for the purposes of supporting TLS connections <del> with fast open (0-RTT data). </del> <ins> with early data. </ins> Certificateless server-to-server communication.  Machine-to- machine communication may use externally provisioned PSKs,

Discussion:
Since the term 'fast open' isn't used in RFC 8446, replace 'fast open' with the term that RFC 8446 uses for '0-RTT data'--namely, 'early data.'
Change:
implementer.  An implementation MUST ensure that the length of a frame exactly matches the length of the fields it contains. <del> 10.3. </del> <ins> 10.9. </ins> The use of 0-RTT with HTTP/3 creates an exposure to replay attack. The anti-replay mitigations in HTTP-REPLAY MUST be applied when using HTTP/3 with 0-RTT. <del> 10.4. </del> <ins> 10.10. </ins> Certain HTTP implementations use the client address for logging or access-control purposes.  Since a QUIC client's address might change

Discussion:
The follow-on to ; depends on . DO NOT MERGE before lands. Imports most of the HTTP/2 Security Considerations text, modulo updates to reference HTTP/3 or http-core concepts. Suggestions on a more sensible structuring of concerns welcome; this still feels like a bit of a grab-bag.
There's a few places where it seems the new "field" terminology is applied inconsistently, but given the PR dependency chain maybe that will shake out. I'll take another look once other things have landed.
Given the chain, this PR should consistently use the new terminology. If I missed something, please flag it.
HTTP-core is making some terminology changes that HTTP/3 should track: In URL, "non-final" responses are "interim" responses In URL, terminology around header, field, value is changing Related to , but this is more than just pointing at the new documents.
NAME these comments/suggestion address my earlier one about use of headers. I might be applying things wrong.Looks good to me. Thanks for doing the hard work here.
Change:
Abstract This document provides usage guidance for external Pre-Shared Keys <del> (PSKs) in Transport Layer Security (TLS) version 1.3 as defined in RFC 8446.  It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  It discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  It provides advice for applications in various use cases to help meet these assumptions.  It also lists the privacy and security properties that are not provided by TLS when external PSKs are used. </del> <ins> (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. This document lists TLS security properties provided by PSKs under certain assumptions, and then demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases and provisioning processes.  This document provides advice for applications to help meet these assumptions.  This document also lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. </ins> 1. This document provides guidance on the use of external Pre-Shared <del> Keys (PSKs) in Transport Layer Security (TLS) version 1.3 RFC8446. This document lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  This document also provides advice for applications in various use cases to help meet these assumptions. </del> <ins> Keys (PSKs) in Transport Layer Security (TLS) 1.3 RFC8446.  This guidance also applies to Datagram TLS (DTLS) 1.3 I-D.ietf-tls-dtls13 and Compact TLS 1.3 I-D.ietf-tls-ctls.  For readability, this document uses the term TLS to refer to all such versions.  External PSKs are symmetric secret keys provided to the TLS protocol implementation as external inputs.  External PSKs are provisioned out-of-band.  This document lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  This document also provides advice for applications in various use cases to help meet these assumptions. </ins> There are many resources that provide guidance for password generation and verification aimed towards improving security. However, there is no such equivalent for external Pre-Shared Keys (PSKs) in TLS.  This document aims to reduce that gap. <del> The guidance provided in this document is applicable across TLS RFC8446, DTLS I-D.ietf-tls-dtls13, and Compact TLS I-D.ietf-tls-ctls. </del> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

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