jiebi/CodeConvo huggingface dataset:
Change:
example, an "error of type 'badCSR'" refers to an error document with "type" value "urn:ietf:params:acme:error:badCSR". <del> 6.7.1. </del> <ins> 6.6.1. </ins> Sometimes a CA may need to return multiple errors in response to a request.  Additionally, the CA may need to attribute errors to

Discussion:
This is my attempt to find a quick way out of this content-type mess. Replaces and
This also looks good to me, thanks for drafting it!
+1 - This looks like a low complexity path forward that resolves ambiguity.
Change:
key, from which the server can look up related authorizations. A CSR encoding the parameters for the certificate being requested. <del> The CSR is sent in the Base64-encoded version of the DER format. (Note: This field uses the same modified Base64-encoding rules used elsewhere in this document, so it is different from PEM.) </del> <ins> The CSR is sent in the Base64url-encoded version of the DER format.  (Note: This field uses the same modified Base64 encoding rules used elsewhere in this document, so it is different from PEM.) </ins> The CSR encodes the client's requests with regard to the content of the certificate to be issued.  The CSR MUST indicate the requested

Discussion:
All of the Base64 strings are actually Base64 URL encoded In the Java support for big ints the top byte is set to 0 to eliminate issues with signs. The thumbprint used here does not support that. It would be useful to mention that in the spec. I think it would help if there was an appendix with a complete example from key to key authorization to help clarify the points above.
Right, point 3 is pretty unclear and requires searching with your favorite search engine.
Change:
%%% Updating Keys <del> The EndOfEarlyData message is sent by the client to indicate that all 0-RTT application_data messages have been transmitted (or none will be sent at all) and that the following records are protected under </del> <ins> If the server sent an "early_data" extension, the client MUST send an EndOfEarlyData after receiving the server Finished.  This indicates that all 0-RTT application_data messages, if any, have been transmitted and that the following records are protected under </ins> handshake traffic keys.  Servers MUST NOT send this message and clients receiving it MUST terminate the connection with an "unexpected_message" alert.  This message is encrypted under keys

Discussion:
31f836238e5968a85c9e4d64d8ab23c0bbed8061 missed a spot.
NAME
:+1: Having a definition on when EOED must be sent is good for both interoperability and as a guildeline of how 0RTT support should be implemented.
Change:
JWT with the header and body shown in ex-jwt.  This JWT would be valid until 2016-01-21T01:53:25Z RFC3339. <del> The first part of the JWT is effectively fixed.  Would be it acceptable to require that that segment is omitted from the header field? </del> 3. A new "WebPush" HTTP authentication scheme RFC7235 is defined.  This

Discussion:
What is "that segment"?
Optimizations, like dropping the header segment, tend to be problematic for some implementers, particularly since the final signature is derived from the first two segments. Also, dropping the header segment prevents possible future changes for encryption types, versioning, or other potentially required items.
Agreed. I was requesting clarification because it was unclear what omission was being proposed. For example, if it was the header, then that would be a problem because states that the alg parameter MUST be present and MUST be understood and processed by implementations.
I'll confirm with the list, but NAME is right here. We can pay a little extra here. It will mean that there is some possibility of variation in the header (whitespace), but we know how to do that.
Change:
Verify that the credential in the KeyPackage is valid according to the authentication service and the client's local policy.  These actions MUST be the same regardless of at what point in the <del> protocol the KeyPackage is being verified. </del> <ins> protocol the KeyPackage is being verified with the following exception: If the KeyPackage is an update to another KeyPackage, the authentication service MUST additionally validate that the set of identities attested by the credential in the new KeyPackage is acceptable relative to the identities attested by the old credential. </ins> Verify that the signature on the KeyPackage is valid using the public key in the KeyPackage's credential

Discussion:
This PR moves the remark that there has to be validation of the attested identities upon a credential update to the KeyPackage validation subsection. It also changes the responsibility for the check to be that of the AS rather than that of the application. Note, that the boundaries are somewhat arbitrary at this point, since the application running on the local device may well implement parts of the AS. The reason for this change is to ensure any validation checks that pertain to authentication are part of the AS.
NAME Please make any required changes to the architecture document as well. Since I think that's where the AS is defined.
Right now it says in the Update proposal section: "Verify that the set of identities attested by the credential is acceptable to the application for the participant being updated." Firstly, I think this is a matter of authentication and thus the AS' job and secondly, it's a validation step that should probably go into the section.
Discussion on virtual interim: Depends on what the boundary of the AS is: Checking credential is valid Also checking (credential -> credential) transitions Moving this check to KP validation section would make it clearer NAME to make a PR
Fixed by
Change:
routers (6LR) that the packet goes through from the RUL to the 6LBR. When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), <del> the 6LR_1 will insert an RPI, encapsulated in a IPv6-in-IPv6 header. The IPv6-in-IPv6 header is addressed to the root (Node A).  The root removes the header and processes the packet. </del> <ins> the 6LR_1 will insert encapsulate the packet in an IPv6-in-IPv6 header and prepend an RPI.  The IPv6-in-IPv6 header is addressed to the root (Node A).  The root removes the header and processes the packet. </ins> The Storing-notrpl2root shows the table that summarizes what headers are needed for this use case where the IPv6-in-IPv6 header is

Discussion:
This covers the text from the beginning up to Section 7.2.1. These were reviewed with Pascal on March 26th. I will continue my review from Section 7.2.2 forward. More trivial editorial suggestions to follow, as well.
Many thanks for these fixs.
Change:
Merge client and server key shares into a single extension. <ins> Remove sequence number and version from additional_data, which is now empty. </ins> draft-09 Change to RSA-PSS signatures for handshake messages.

Discussion:
Starts in this thread: URL spt
It's the nonce after all. On Monday, October 19, 2015, Martin Thomson wrote: I don't believe that there's any reason to include the sequence number in the AD input of an AEAD. I think that an empty AD for TLS would be fine now that the content type is encrypted. (Not that I deeply care either way.) Cheers AGL Adam Langley EMAIL URL
Change:
If the first byte is alert(21), handshake(22), or ack(proposed, 25), the record MUST be interpreted as a DTLSPlaintext record. <del> If the first byte is any other other value, then receivers MUST check to see if the leading bits of the first byte are 001.  If so, the implementation MUST process the record as DTLSCiphertext; the true content type will be inside the protected portion. </del> <ins> If the first byte is any other value, then receivers MUST check to see if the leading bits of the first byte are 001.  If so, the implementation MUST process the record as DTLSCiphertext; the true content type will be inside the protected portion. </ins> Otherwise, the record MUST be rejected as if it had failed deprotection, as described in handling-invalid-records.

Discussion:
I read through the draft and amassed a number of comments. This PR resolves the easy stuff. I'll send an email to the WG list with the more interesting ones shortly. Grammar fixes.The text describing sequence number encryption doesn't say how the receiver handles short ciphertexts. It's also phrased oddly. It says "In some (rare) cases the ciphertext may be less than 16 bytes", but the whole point of the text is to ensure it cannot be less than 16 bytes. Reword it. Whether there's a Certificate message is no longer a function of the ciphersuite, but of parameters in general. (With resumption that was already true.) The bits talking about epoch 1-3 so far before the definitions of those epochs should link to the section. Remove some remnants of EndOfEarlyData. They're still in the definition of the Handshake struct. I wasn't sure how to handle that since it was in the HandshakeType enum and we probably shouldn't call it RESERVED when it exists in TLS? Spell out [sender]applicationtrafficsecret since trafficsecret isn't defined.
This looks good to me.
These changes look good to me! NAME can you please have a look?
Change:
perspective there is no practical difference based on the origin of flow mapping related information (management plane or control plane). <ins> The following summarizes the set of information that is needed to configure DetNet IP over TSN: DetNet IP related configuration information according to the DetNet role of the DetNet IP node, as per I-D.ietf-detnet-ip. TSN related configuration information according to the TSN role of the DetNet IP node, as per IEEE8021Q, IEEE8021CB and IEEEP8021CBdb. Mapping between DetNet IP flow(s) (as flow identification defined in I-D.ietf-detnet-ip, it is summarized in Section 5.1 of that document, and includes all wildcards, port ranges and the ability to ignore specific IP fields) and TSN Stream(s) (as stream identification information defined in IEEE8021CB and IEEEP8021CBdb).  Note, that managed objects for TSN Stream identification can be found in IEEEP8021CBcv. This information MUST be provisioned per DetNet flow. </ins> TSN-aware IP DetNet nodes are member of both the DetNet domain and the TSN sub-network.  Within the TSN sub-network the TSN-aware IP (DetNet) node has a TSN-aware Talker/Listener role, so TSN specific

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
TLS SignatureScheme Registry: Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required <del> RFC2434.  Values with the first byte 255 (decimal) are reserved for Private Use RFC2434.  Values with the first byte in the range </del> <ins> RFC5226.  Values with the first byte 255 (decimal) are reserved for Private Use RFC5226.  Values with the first byte in the range </ins> 0-6 or with the second byte in the range 0-3 that are not currently allocated are reserved for backwards compatibility. This registry SHALL have a "Recommended" column.  The registry

Discussion:
RFC 5226 obsoleted RFC 2434 so we should refer to that to avoid a GENART review comment.
Change:
POSIX time (see Sec.  4.16 of TIME_T). Opaque Data: The server may use this field to encode additional <del> information, such as congestion window, RTT, or MTU.  Opaque data MAY also allow servers to distinguish between retry tokens (which trigger use of certain transport parameters) and NEW_TOKEN frame tokens. </del> <ins> information, such as congestion window, RTT, or MTU.  The Retry Service MUST have zero-length opaque data. </ins> Some implementations of QUIC encode in the token the Initial Packet Number used by the client, in order to verify that the client sends the retried Initial with a PN larger that the triggering Initial. Such implementations will encode the Initial Packet Number as part of <del> the opaque data. </del> <ins> the opaque data.  As tokens may be generated by the Service, servers MUST NOT reject tokens because they lack opaque data and therefore the packet number. </ins> 6.3.1.

Discussion:
and
Thanks Christian, Your comments ended up as an editorial rewrite of the section, with port verification added.
The diagrams indicate they are in the range 0..160. This is incorrect.
SS Tokens can have this, because they could be NEW_TOKEN tokens. But the shared state format is limited to 64.
Fixed by
A few more issues with Retry tokens: For Retry, we're supposed to check the client port. Because this isn't true for NEW_TOKEN, we probably can't put it in the shared-state pseudoheader. Relatedly, we currently just say that the shared-state Retry Service has to be behind any NAT. This isn't enough. For non-shared-state, we're probably fine. For a Retry, the NAT will keep the 4-tuple binding so that on either side there is something to validate. For shared-state: if the service is in front of the NAT, the server can't validate the address. if the service is behind the NAT, it'll "work" but to add any value at all there really has to be a port in there somewhere. We can probably assume that the alternate path that creates the need for shared state won't cause a service-generated token to suddenly appear on the unprotected path.
Fixed by
We should tighten up the rules for Resumption Token processing by the Retry Service. When active, it should reject the packet, but it should send Retry. I believe we can distinguish resumption from Retry because the CID length fields are zero; as any Retry token must have a ODCIDL of at least 8, this would appear to be robust. On a related note, the requirement on servers to encode a way to distinguish the two token types is silly, because of this propery.
Fixed by
Currently the Initial Packet number MAY be encoded in the Retry Token. We must either: Include language that a server MUST NOT reject a token because this information is not present; OR Just make it part of the format. (IMO this would be bad, because then the Retry service would have to decrypt the packet number)
Most changes appear editorial, except for the addition of the port number field. If you add that port, you need to also specify how it should be processed!
Change:
5.6.4. An identity assertion binds the user's identity (as asserted by the <del> IdP) to the SDP offer/exchange transaction and specifically to the media.  In order to achieve this, the PeerConnection must provide the DTLS-SRTP fingerprint to be bound to the identity.  This is provided as a JavaScript object (also known as a dictionary or hash) with a single "fingerprint" key, as shown below: </del> <ins> IdP) to the SDP offer/answer exchange and specifically to the media. In order to achieve this, the PeerConnection must provide the DTLS- SRTP fingerprint to be bound to the identity.  This is provided as a JavaScript object (also known as a dictionary or hash) with a single "fingerprint" key, as shown below: </ins> The "fingerprint" value is an array of objects.  Each object in the array contains "algorithm" and "digest" values, which correspond

Discussion:
Just some tweaks to consistently use offer/answer exchange and to explain that the offer/answer includes the caller's/callee's assertion, respectively.
Change:
Rename UserInitKey to ClientInitKey <ins> Resolve the circular dependency that draft-05 introduced in the confirmation MAC calculation (*) Cover the entire MLSPlaintext in the transcript hash (*) </ins> draft-05 Common framing for handshake and application messages (*)

Discussion:
This PR addresses two issues that were noted in draft-05, one that is definitely a bug, and one that should improve security analysis. In draft-05, a circular dependency was introduced, wherein the confirmation MAC was calculated from the transcript, which includes the GroupOperation, which includes the confirmation MAC. Here we move the confirmation MAC up to the MLSPlaintext object to avoid this circularity. In all prior versions, the transcript covered only the GroupOperation objects, not the sender metadata or signatures. Here we cover the whole MLSPlaintext object, but in "staggered" form -- the confirmation MAC and signature aren't entered into the transcript until the next epoch.
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 2 issues have been closed and 0 issues are still open. :heart: , by :heart: , by - - Last week, 4 pull requests were created, updated or merged. Last week, 4 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 9 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened.

:greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
Other message components MAY also be included. <ins> The signer MUST include the "tag" signature parameter with the value "gnap", and the verifier MUST verify that the parameter exists with this value.  The signer MUST include the "created" signature parameter with a timestamp of when the signature was created, and the verifier MUST ensure that the creation timestamp is sufficiently close to the current time given expected network delay and clock skew.  The signer SHOULD include the "nonce" parameter with a unique and unguessable value.  When included, the verifier MUST determine that the nonce value is unique within a reasonably short time period such as several minutes. </ins> If the signer's key presented is a JWK, the "keyid" parameter of the signature MUST be set to the "kid" value of the JWK, the signing algorithm used MUST be the JWS algorithm denoted by the key's "alg"

Discussion:
To edit notification comments on pull requests, go to your .
From the HTTP message sig spec : "tag: An application-specific tag for the signature as a String value. This value is used by applications to help identify signatures relevant for specific applications or protocols." Fair enough, but does a MUST requirement improve the security of the protocol ?
Yes, because it prevents cross-protocol confusion attacks. Where an attacker tries to use a signed HTTP message from another protocol in GNAP, or vice versa.
This was recently added to HTTP Signatures. Please add a standard value for GNAP messages.
LGTM
Change:
the server has ignored any early data and an ordinary 1-RTT handshake is required. <del> Return an empty extension, indicating that it intends to process </del> <ins> Return its own extension, indicating that it intends to process </ins> the early data.  It is not possible for the server to accept only a subset of the early data messages.

Discussion:
This extension is now empty. Minor cleanup.
I think "it's own" is useful, but my instinct is that having the empty struct makes life easier.
If you would rather keep the empty struct, I don't have a strong objection. Repushed with just the minor wording tweak.
Change:
of the Mask with the sequence number.  Decryption is accomplished by the same process. <del> In some (rare) cases the ciphertext may be less than 16 bytes.  This cannot happen with most of the DTLS AEAD algorithms because the authentication tag itself is 16 bytes, however some algorithms such as TLS_AES_128_CCM_8_SHA256 have a shorter authentication tag, and in combination with a short plaintext, the result might be less than 16 bytes.  In this case, implementations MUST pad the plaintext out (using the conventional record padding mechanism) in order to make a suitable-length ciphertext. </del> <ins> This procedure requires the ciphertext length be at least 16 bytes. Receivers MUST reject shorter records as if they had failed deprotection, as described in handling-invalid-records.  Senders MUST pad short plaintexts out (using the conventional record padding mechanism) in order to make a suitable-length ciphertext.  Note most of the DTLS AEAD algorithms have a 16-byte authentication tag and need no padding.  However, some algorithms such as TLS_AES_128_CCM_8_SHA256 have a shorter authentication tag and may require padding for short inputs. </ins> Note that sequence number encryption is only applied to the DTLSCiphertext structure and not to the DTLSPlaintext structure,

Discussion:
I read through the draft and amassed a number of comments. This PR resolves the easy stuff. I'll send an email to the WG list with the more interesting ones shortly. Grammar fixes.The text describing sequence number encryption doesn't say how the receiver handles short ciphertexts. It's also phrased oddly. It says "In some (rare) cases the ciphertext may be less than 16 bytes", but the whole point of the text is to ensure it cannot be less than 16 bytes. Reword it. Whether there's a Certificate message is no longer a function of the ciphersuite, but of parameters in general. (With resumption that was already true.) The bits talking about epoch 1-3 so far before the definitions of those epochs should link to the section. Remove some remnants of EndOfEarlyData. They're still in the definition of the Handshake struct. I wasn't sure how to handle that since it was in the HandshakeType enum and we probably shouldn't call it RESERVED when it exists in TLS? Spell out [sender]applicationtrafficsecret since trafficsecret isn't defined.
This looks good to me.
These changes look good to me! NAME can you please have a look?
Change:
5.9. <ins> Section 7.1 of RFC8446 specifies that HKDR-Expand-Label uses a label prefix of "tls13 ".  For DTLS 1.3, that label SHALL be "dtls13". This ensures key separation between DTLS 1.3 and TLS 1.3.  Note that there is no trailing space; this is necessary in order to keep the overall label size inside of one hash iteration because "DTLS" is one letter longer than "TLS". 5.10. </ins> Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake.  However, a DTLS implementation which would ordinarily issue an alert SHOULD generate a new alert

Discussion:
omit the trailing space because TLS 1.3 went right up to the limit.
No, no, DTLS also uses HKDR for Key Separation++
Hearing no objections, we're merging this change. I'll fix the HKDR->HKDF typo in a followup PR.
This is perfectly fine. Thanks for making the edit.