jiebi/CodeConvo huggingface dataset:
Change:
consumed by people, implementations MAY perform the steps below during certificate validation: <del> The implementation MAY examine the KeyPurposeId(s) included in the Extended Key Usage extension as follows: A Restriction on Extended Key Usage is derived and implemented from (or configured with) the policy to which the implementation conforms. </del> <ins> The following procedure is used to examine the KeyPurposeId(s) included in the Extended Key Usage extension.  Restrictions on Extended Key Usage is derived and implemented from (or configured with) the policy to which the implementation conforms. </ins> If there are no restrictions set for the relying party and the relying party software, the certificate is acceptable.

Discussion:
changes are followings We accepeted your comment We accepeted your comment we stop using term "trust program" and changed as following "KeyPurposeIds are used in a PKI governed by the vendor or a set of specific group of vendors." "Unless certificates are governed by a vendor(s) specific PKI, certificates that indicate usage for document signing.." We accepeted your comment >(e.g. - When the end user encounters... >Editorially, please split this large "(e.g.," text block into distinct sentences. we divided the sentence, and clarified the relationship between KeyPurposeIds owning vendor and another vendor. We accepeted your comment We accepeted your comment prescribed behavior for RFC8358. We accepeted your comment We accepeted your comment as follows We removed secound MAY, and numbering. We further clarified the " outside of scope" case where it is up to software. We clarified order of "Excluded KeyPurposeId procedure" and Permitted KeyPurposeId procedure. we accept your change and changed as follow. "TLS (id-kp-clientAuth) or S/MIME (id-kp-emailProtection) etc."
Change:
entity that is separate from the Origin.  The Origin trusts the joint Attester and Issuer to perform attestation and issue Tokens.  Clients interact with the joint Attester and Issuer for attestation and <del> issuance.  This arrangement is shown in the figure below. </del> <ins> issuance.  This arrangement is shown in fig-deploy-joint-issuer. </ins> This model is useful if an Origin wants to offload attestation and issuance to a trusted entity.  In this model, the Attester and Issuer

Discussion:
This is a little hard to process... An inbound PR I have proposes a change to the first diagram that might help here. A little work on this is probably necessary. !
A few things: When drawing arrows on lines, the line will connect with the line neatly if there is a connector or if there is an arrow adjacent to the line: This puts the arrow on the line, which renders a gap in the line. Avoid this: The bottom-left corner here is not curved, because the detection of corners needs three characters: the corner and a line either side of that, so... Not:
NAME can you say more about how it's hard to process? As we recently discussed, we're burdened by being too close to this work, so it's hard for me to see a substantial difference between the diagram in this issue and that which you proposed in the recently merged PR. Is it not clear who touches or sees each message? Part of the challenge in this particular diagram -- and any in which the attester is party to the protocol -- is that the attester may be inline or may not be! The architecture does not require the attester to be inline, it really only requires that the token request from a client be somehow blessed by the attester. I'll think about ways to better visualize this, but clarification about the source of confusion would be super helpful.
For me, the hardest part of these diagrams is that the start and end of the end of the arrows aren't really attached to anything in particular. You rely on horizontal alignment a fair bit (the arrow starts approximately under the label "Issuer", so it's probably a message from the issuer). In comparison, the diagram I provided had lines and boxes connecting them. This is probably a more illustrative example: ! Are the TokenRequest and TokenResponse labels on the lines? Where do these arrows start? Is the Client/Attester/Issuer box a single entity (obviously, no) given how the challenge arrows hit it. Which entities perform attestation? Then there are the formatting issues, some of which I will concede are specific to aasvg, see the above comment.
Thanks -- that's helpful. I think should resolve the confusion.
Change:
possible forms of initial candidates - host, server reflexive, and relay.  However, in certain cases, applications may want to have more specific control over the gathering process, due to privacy or <del> related concerns.  For example, one may want to suppress the use of host candidates, to avoid exposing information about the local network, or go as far as only using relay candidates, to leak as little location information as possible (note that these choices come with corresponding operational costs).  To accomplish this, the browser MUST allow the application to restrict which ICE candidates are used in a session.  Note that this filtering is applied on top of any restrictions the browser chooses to enforce regarding which IP addresses are permitted for the application, as discussed in I- D.ietf-rtcweb-ip-handling. </del> <ins> related concerns.  For example, one may want to only use relay candidates, to leak as little location information as possible (keeping in mind that this choice comes with corresponding operational costs).  To accomplish this, JSEP allows the application to restrict which ICE candidates are used in a session.  Note that this filtering is applied on top of any restrictions the browser chooses to enforce regarding which IP addresses are permitted for the application, as discussed in I-D.ietf-rtcweb-ip-handling. </ins> There may also be cases where the application wants to change which types of candidates are used while the session is active.  A prime

Discussion:
It’s an API requirement, so the MUST doesn’t belong here. Also remove discussion of application filtering of local addresses, which is no longer believed to be useful.
Originally raised by Christer Section 3.5.3 contains requirements regarding what a browser MUST do - e.g., allowing the application to select what types of ICE candidates are used. 1) I am not sure why such requirements are listed here. But, in any case, is there a mechanism for applications for selecting candidate types etc? If so, what mechanism?
This is ICE policy. Editorial
Suggested revision: to
Change:
VoiceActivityDetection to true would result in an answer with CN codecs and "usedtx=0"). <del> 5.3.4. RFC3264 direction attributes (defined in Section 6.1) in answers are chosen according to the direction attribute in the remote offer and the states of the RtpSender and RtpReceiver of the corresponding RtpTransceiver, as follows: </del> 5.4. When a SessionDescription is supplied to setLocalDescription, the

Discussion:
Can you separate this from the ICE changes that are also in this PR?
Oops, yeah
NAME PTAL
LGTM
See URL
Change:
Reorder original packets <del> An off-path attacker can modify packets that it has observed and inject them back into the network, potentially with spoofed source and destination addresses. </del> <ins> An off-path attacker can create modified copies of packets that it has observed and inject those copies into the network, potentially with spoofed source and destination addresses. </ins> For the purposes of this discussion, it is assumed that an off-path <del> attacker has the ability to observe, modify, and re-inject a packet into the network that will reach the destination endpoint prior to the arrival of the original packet observed by the attacker.  In other words, an attacker has the ability to consistently "win" a race with the legitimate packets between the endpoints, potentially causing the original packet to be ignored by the recipient. </del> <ins> attacker has the ability to inject a modified copy of a packet into the network that will reach the destination endpoint prior to the arrival of the original packet observed by the attacker.  In other words, an attacker has the ability to consistently "win" a race with the legitimate packets between the endpoints, potentially causing the original packet to be ignored by the recipient. </ins> It is also assumed that an attacker has the resources necessary to affect NAT state, potentially both causing an endpoint to lose its

Discussion:
We weren't being consistent. This should help.
NAME said:
The first here is in the process of being addressed, see . I agree regarding "strong", but also agree regarding what to do about it. My proposal is to let close this issue.
NAME said:
Proposed resolution is URL
This is an improvement. Thanks.
Change:
Construct an MLSPlaintext object containing the Commit object. Use the "commit_secret" to advance the key schedule and compute <del> the "confirmation" value in the MLSPlaintext.  Sign the </del> <ins> the "confirmation_tag" value in the MLSPlaintext.  Sign the </ins> MLSPlaintext using the current epoch's GroupContext as context. Update the tree in the provisional state by applying the direct

Discussion:
This PR gets rid of the explicit HMAC reference and uses KDF.Extract instead (which internally uses HMAC). Also is renamed to .
I don't love the extra , but I can live with it.
Change:
stream.  Once an endpoint sends a RESET_STREAM frame, no further STREAM frames are needed. <del> The most recent set of acknowledgments are sent in ACK frames.  An ACK frame SHOULD contain all unacknowledged acknowledgments, as described in sending-acknowledgements. </del> <ins> ACK frames carry the most recent set of acknowledgements and the Ack Delay from the largest acknowledged packet, as described in sending-acknowledgements.  Delaying the transmission of packets containing ACK frames or sending old ACK frames can cause the peer to generate an inflated RTT sample or unnecessarily disable ECN. </ins> Cancellation of stream transmission, as carried in a RESET_STREAM frame, is sent until acknowledged or until all stream data is

Discussion:
It can result in an inflated RTT, as well as being a waste of bytes.
Even though a sender is encouraged to assemble frames containing up-to-date information every time it sends a packet, it is not forbidden to retransmit copies of frames from lost packets. A receiver MUST accept packets containing an outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. URL If a packet containing an ACK is lost and the payload is retransmitted with a new packet number AND no ACKs are received prior to the retransmitted ACK frame arriving, the peer will calculate and RTT sample that is 2 RTTs + loss recovery delay. As such, I'd suggest we add a warning that retransmitting ACKs can cause RTT inflation and is heavily discouraged. There may be other issues with retransmitting ACKs, but this is the first that comes to mind.
Change:
The AES-GCM cryptographic algorithm introduces an additional 16 octets to the length of the packet.  When using AES-GCM for both the inner and outer cryptographic algorithms, the total additional length <del> is 32 octets.  If no other header extensions are present in the packet and the OHB is introduced, that will consume an additional 8 octets.  If other extensions are already present, the OHB will consume up to 4 additional octets.  Packets in repair mode will carry additional repair data, further increasing their size. </del> <ins> is 32 octets.  The OHB will consume an additional 1-4 octets. Packets in repair mode will carry additional repair data, further increasing their size. </ins> 9.

Discussion:
This PR responds to IESG review comments from Magnus Westerlund, except for his comments on RED, which I haven't quite figured out how to address yet.
LGTM with nits
Change:
Initial packets and Handshake packets could be never acknowledged, but they are removed from bytes in flight when the Initial and <del> Handshake keys are discarded.  When Initial or Handshake keys are discarded, the PTO and loss detection timers MUST be reset, because discarding keys indicates forward progress and the loss detection timer may have been set for a now discarded packet number space. </del> <ins> Handshake keys are discarded, as described below in Section discarding-packets.  When Initial or Handshake keys are discarded, the PTO and loss detection timers MUST be reset, because discarding keys indicates forward progress and the loss detection timer might have been set for a now discarded packet number space. </ins> <del> 5.3.1. </del> <ins> 5.2.3. </ins> When a PTO timer expires, a sender MUST send at least one ack- eliciting packet in the packet number space as a probe, unless there

Discussion:
I believe this section was mistakenly on the wrong level. I also added a reference to a later section to the last sentence. Alternatively this sentence could just be removed as this is normatively specified later on.
Change:
can be imposed by including a "required_capabilities" extension in the GroupContext. <del> This extension lists the extensions and proposal types that must be supported by all members of the group.  The "default" proposal and extension types defined in this document are assumed to be implemented by all clients, and need not be listed in </del> <ins> This extension lists the extensions, proposals, and credential types that must be supported by all members of the group.  The "default" proposal and extension types defined in this document are assumed to be implemented by all clients, and need not be listed in </ins> RequiredCapabilities in order to be safely used. For new members, support for required capabilities is enforced by

Discussion:
This PR adds a way for the members of a group to indicate the credential types they support, and how to negotiate which credential types may be used in a group.
I discussed this offline with NAME and we arrived at: We might need multiple credentials later (as I suspect) If we do that (say in an extension), we will need to update this text We should capture the general theory that covers both single- and multiple-credential cases The proposed additions here just abstract the principle of universal compatibility (which we need in a single-credential world) to one of "at least something" compatibility (which is more compatible with a multi-credential world).> The types of credential that may be used in a group is restricted to what all I think this is too restrictive if we adopt PR . I think it is between the client and its AS if all the clients need to support every credential type used in the group. If you agree with the concept, I am happy to propose slight changes.I think this makes sense.
Change:
Structure of this message: %%% Key Exchange Messages struct { ProtocolVersion server_version; <del> Random random; CipherSuite cipher_suite; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; } ServerHello; </del> <ins> Random random; CipherSuite cipher_suite; Extension extensions<0..2^16-1>; } ServerHello; </ins> <del> The presence of extensions can be detected by determining whether there are bytes following the cipher_suite field at the end of the ServerHello. </del> <ins> In prior versions of TLS, the extensions field could be omitted entirely if not needed, similar to ClientHello.  As of TLS 1.3, all clients and servers will send at least one extension (at least "key_share" or "pre_shared_key"). </ins> This field will contain the lower of that suggested by the client

Discussion:
Small simplification & clarification. Now that the server key share is in an extension, all TLS 1.3 endpoints will have at least one extension in their hello, either "keyshare" or "preshared_key", at minimum. This changeset simplifies the ServerHello struct in the same manner as was previously done for ClientHello and adds short notes explicitly stating this.
Change:
field section, some endpoints could be forced to commit a large amount of available memory for header fields. <del> An endpoint can use the SETTINGS_MAX_HEADER_LIST_SIZE (settings- </del> <ins> An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE (settings- </ins> parameters) setting to advise peers of limits that might apply on the size of field sections.  This setting is only advisory, so endpoints MAY choose to send field sections that exceed this limit and risk

Discussion:
Replace SETTINGSMAXHEADERLISTSIZE with SETTINGSMAXFIELDSECTIONSIZE in one last place. Add comment to HTTP/2 identifier mapping section about rename.
Change:
maximize the size of the anonymity set where possible.  This means client-facing servers should use the same ECHConfig for as many hosts as possible.  An attacker can distinguish two hosts that have <del> different ECHConfig values based on the ClientEncryptedCH.config_digest value.  This also means public information in a TLS handshake is also consistent across hosts.  For example, if a client-facing server services many backend origin hosts, only one of which supports some cipher suite, it may be possible to identify that host based on the contents of unencrypted handshake messages. </del> <ins> different ECHConfig values based on the ClientEncryptedCH.config_id value.  This also means public information in a TLS handshake is also consistent across hosts.  For example, if a client-facing server services many backend origin hosts, only one of which supports some cipher suite, it may be possible to identify that host based on the contents of unencrypted handshake messages. </ins> 10.2.

Discussion:
Also, rename configdigest to configid to avoid confusion with cryptographic hash digests. cc NAME NAME NAME
It's bound by the size o the HPKE KDF output size, which is unlikely to be larger than 32B. Let's make this:
We should also add a requirement for the HPKE ciphersuite. E.g., 'Nh <= 2^8`.
(Careful with fenceposts: .) If config_digest is the output of a KDF, why could you not fix the length to something that is enough to avoid collisions (16 bytes seems ample for this) and not worry about Nh at all?
I think it makes sense to let the KDF dictate the security level, i.e., the collision probability of the config_digest.
I would argue that collision probability here doesn't contribute to security. If a config is misidentified, the result will be failure, not a reduction in security. A failure either because the group doesn't match or because peers end up disagreeing on keys.
True that it's an operational consideration rather than a security one. I still think it makes sense to let the length of be dictated by the KDF, since whether truncation is an operational risk depends on the KDF.
I assume here that a KDF is capable of producing uniform random bytes of arbitrary length, meaning that truncation isn't a factor. That's what is for, right?
That assumption holds if the input has sufficient entropy. Since the public key is public, there's no entropy from the point of view of an adversary who wants to distinguish the output from random.
(To be clear, I think truncating to something reasonable, like 16 bytes, is low risk. I would be fine with doing this.)
Change:
same PPM task.  [[OPEN ISSUE: And the same batch, right?]] Let "[helper]" denote "Param.helper_url", where "Param" is the PPM <del> parameters structure associated with"AggregateReq.task.id".  The </del> <ins> parameters structure associated with "AggregateReq.task.id".  The </ins> leader sends a POST request to "[helper]/aggregate" with the following message:

Discussion:
Removes some TODOs, clarifies why we have HpkeConfig collectorconfigstruct PPMParamUrl collectorurl, and amends collect protocol so that leader output shares are encrypted to collector's HPKE config. Several response structures no longer have or fields if the appropriate task (and hence and hence ) can be inferred from the request.
I want to address in this PR as well, so downgrading to draft for now.
NAME NAME This is ready; please review at your convenience.
Thank you for the review, NAME This picked up some merge conflicts so I will wait for all of NAME changes to land and then rebase.
You should be able to rebase now. I am mostly done.
Rebased, reordered, ready for re-review
This seems to be a dupe fo -- can we close?
Per discussion in the call today, I think this issue is about updating the various PDU definitions to allow for multiple helpers. For instance, currently has fields and , but it should instead have . is the more complex problem of extending the protocol to handle >1 helper, which probably involves more rounds of communication. I'm going to grab this issue because I ran into which I think is related, so I'll fix both.
Right now only the helper's output share for a batch of reports is encrypted to the collector. We previously agreed that all input shares should be encrypted to the corresponding aggregator (URL). It makes sense to encrypt the leader's output share for the same reasons we discussed there. Along the way, the message format should be made to accommodate multiple helpers, as we did for the input shares.
Fixed in . Making "the message format [...] accommodate multiple helpers" is specifically tracked in and resolved by .
Change:
does not guarantee that the next request will be successful.  Server metrics may be subject to other conditions like the one shown in the <del> example from request-quota. </del> <ins> example from service-limit. </ins> A server MAY return "RateLimit" response fields independently of the response status code.  This includes throttled responses.

Discussion:
Improves terminology replacing with . cc: NAME NAME
It seems in the context of this design limit and quota terminology mean the same thing, however the header name to represent quota is RateLimit-Limit, which stutters. Would RateLimit-Quota not be better because it seems to mean the same thing and avoids stuttering?
Well, conveys the , which is expressed in terms of . The name makes me think more to a than to or . Since implementers already use , with NAME we decided not to change field names. WDYT to rename instead?
One potential issue with is that the quota can be not directly related to the amount of requests. For example it could be time based, just to name a simple criteria, but there are multiple other potential factors that could affect the units returned that could be confused when using that name. could arguably make for a better name.
Not sure this should be closed by the PR, so feel free to reopen if that's not the case.
NAME thanks for your feedback! You're welcome to provide more! NAME to me it's fine! Good merge and good idea about the new name is cool :)
Thanks both! I think this is more clear.
:+1:Thanks! I think this is more clear.
Change:
[38] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/105 [39] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/109 <del> [40] request </del>

Discussion:
fixed some typos fixed a broken reference HTTP -> HTTP to keep it consistent not sure if it is actually supposed to be "Key-Bound Token Access Tokens"
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 5faf7b6b37c82891ee35bd06e0a71419b2fbeddc Inspect the deploy log: Browse the preview: