jiebi/CodeConvo huggingface dataset:
Change:
of an Attester includes at least one root of trust.  In order to appraise Evidence generated by an Attester, the Verifier needs to trust the Attester's root of trust.  Trust in the Attester's root of <del> trust can be established either directly (e.g., the Verifier puts the root of trust's public key into its trust anchor store) or transitively via an Endorser (e.g., the Verifier puts the Endorser's public key into its trust anchor store).  In layered attestation, a root of trust is the initial Attesting Environment.  Claims can be collected from or about each layer.  The corresponding Claims can be structured in a nested fashion that reflects the nesting of the Attester's layers.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer. Claims about a root of trust typically are asserted by an Endorser. </del> <ins> trust can be established in various ways as discussed in verifier. In layered attestation, a root of trust is the initial Attesting Environment.  Claims can be collected from or about each layer.  The corresponding Claims can be structured in a nested fashion that reflects the nesting of the Attester's layers.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer.  Claims about a root of trust typically are asserted by an Endorser. </ins> The example device illustrated in layered includes (A) a BIOS stored in read-only memory, (B) a bootloader, and (C) an operating system

Discussion:
Uses text copied from the TEEP arch draft. Addresses Signed-off-by: Dave Thaler
Does “trust anchor store” in Layered Attestation Environments require an introduction?
I advocate taking it out. See and . If / when "trust anchor store" is in the architecture document it should be in the establishment of trust in the basic non-layered Attester. It should be somewhere in section 7.
PR addresses the original issue but there is more needed than just what is in PR to fully address this in my view. Two pieces remain: 1) Currently the trust anchor store is mentioned in the Verifier but not the Relying Party, and appropriate language should be updated in the Relying Party section also. 2) Unlike the TEEP architecture, the Security Consideration section focuses on the attester and so does not mention securing the trust anchor store on the Verifier and Relying Party.
Having merged , the definition of trust-anchor store definition will get moved upwards so that it can be referenced in Relying Party section, and then also a SC paragraph about securing the store.
Change:
However, if the Attestation Result contains an expiry time time(RX_v) then it could explicitly check "time(OP_r) < time(RX_v)". <del> 15.2. </del> <ins> 16.2. </ins> The following example illustrates a hypothetical Passport Model solution that uses nonces and thus does not require that any clocks

Discussion:
this is not complete and does not pass xml2rfc yet. Please add/fix your name/email. Or remove your email. Or foo at example dot com it.
Change:
5.2. <del> The Stream Cipher CID algorithm provides cryptographic protection at the cost of additional per-packet processing at the load balancer to decrypt every incoming connection ID. </del> <ins> The Encrypted Short CID algorithm provides cryptographic protection at the cost of additional per-packet processing at the load balancer to decrypt every incoming connection ID, unless the load balancer maintains state for the routing information of any given 4-tuple. </ins> 5.2.1.

Discussion:
Some have noted that "Stream Cipher" is now a misnomer. So this PR renames them.
Change:
As AES-128 is the mandatory to implement transform in RFC3711, AESKW128 MUST be implemented for EKT and AESKW256 MAY be implemented. <del> 2.3.2. </del> <ins> 2.4.2. </ins> Other specifications may extend this document by defining other EKTCiphers as described in iana.  This section defines how those

Discussion:
,
Changes look good , except for few typos .
Nothing to add beyond Suhas' comments.
Section 4 Each EKT cipher specifies a value T that is the maximum number of times a given key can be used. An endpoint MUST NOT send more than T Full EKT Field using the same EKTKey. In addition, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL described in Section 3.2.
ektttl: The maximum amount of time, in seconds, that this ektkeyvalue can be used. The ektkey_value in this message MUST NOT be used for encrypting or decrypting information after the TTL expires.
These functions have the property that D(K, E(K, P)) = ( P concatenated with optional padding) for all values of K and P. Each cipher also has a limit T on the number of times that it can be used with any fixed key value. The EKTKey MUST NOT be used more that T times.
Change:
resources. Calling this method may do things such as generating new ICE <del> credentials, but does not result in candidate gathering, or cause media to start or stop flowing.  Specifically, the offer is not applied, and does not become the pending local description, until setLocalDescription is called. </del> <ins> credentials, but does not change the PeerConnection state, trigger candidate gathering, or cause media to start or stop flowing. Specifically, the offer is not applied, and does not become the pending local description, until setLocalDescription is called. </ins> 4.1.7.

Discussion:
Odd edge: The description createAnswer (in 4.1.7) leaves open the possibility that the application could call createAnswer twice (back-to-back with no intervening calls to other APIs) with different values in the options parameter. Is this ok? If not, should there be language that says not to do that somewhere?
This is explicitly OK, and the state machine makes it clear.
Not sure we need to say anything here, though, given the state machine.
NAME I forgot to mark this invalid but I think it may be.
Discussed with team and plan is to amend the paras that talk about cO/cA not changing media state to also mention that they don't change signaling state.
LGTM
Change:
This field indicates the hash algorithms which may be used.  The <del> values indicate support for unhashed data, MD5 RFC1321, SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 SHS, respectively.  The "none" value is provided for future extensibility, in case of a signature algorithm which does not require hashing before signing. The use of MD5, SHA-1, and SHA-224 are deprecated.  The md5_RESERVED and sha224_RESERVED values MUST NOT be offered by any implementations.  The sha1_RESERVED value SHOULD NOT be offered, however clients willing to negotiate use of TLS 1.2 MAY offer support for SHA-1 for backwards compatibility with old servers. </del> <ins> values indicate support for unhashed data, SHA-1, SHA-256, SHA- 384, and SHA-512 SHS, respectively.  The "none" value is provided for future extensibility, in case of a signature algorithm which does not require hashing before signing.  Previous versions of TLS supported MD5 and SHA-1.  These algorithms are now deprecated and MUST NOT be offered by TLS 1.3 implementations.  SHA-1 SHOULD NOT be offered, however clients willing to negotiate use of TLS 1.2 MAY offer support for SHA-1 for backwards compatibility with old servers. </ins> This field indicates the signature algorithm that may be used. <del> The values indicate anonymous signatures, RSASSA-PKCS1-v1_5, RFC3447, DSA DSS, ECDSA ECDSA, and RSASSA-PSS RFC3447 respectively.  Because all RSA signatures used in signed TLS handshake messages (see digital-signing), as opposed to those in certificates, are RSASSA-PSS, the "rsa" value refers solely to signatures which appear in certificates.  The use of DSA and anonymous is deprecated.  The anonymous_RESERVED value was used internally in prior versions of TLS and MUST NOT be offered or negotiated by any implementation of any TLS version.  The dsa_RESERVED value is deprecated as of TLS 1.3 and SHOULD NOT be offered or negotiated by any implementation. </del> <ins> The values indicate RSASSA-PKCS1-v1_5 RFC3447, DSA DSS, ECDSA ECDSA, and RSASSA-PSS RFC3447 respectively.  Because all RSA signatures used in signed TLS handshake messages (see digital- signing), as opposed to those in certificates, are RSASSA-PSS, the "rsa" value refers solely to signatures which appear in certificates.  The use of DSA and anonymous is deprecated. Previous versions of TLS supported DSA.  DSA is deprecated as of TLS 1.3 and SHOULD NOT be offered or negotiated by any implementation. </ins> The semantics of this extension are somewhat complicated because the cipher suite indicates permissible signature algorithms but not hash

Discussion:
Note: unRESERVEDing SHA-1 and DSA is intentional. The point is that that things which are RESERVED are totally forbidden. Because you can offer SHA-1, we need the code point. If we decide to make DSA MUSTNOT, then I'll mark it reserved and update the text.
On Saturday, October 03, 2015 04:42:44 pm ekr wrote: Agreed. Using the "RESERVED" notation before was a bit iffy and with this new refactoring it has to be changed now. Just need to make sure it's mentioned explicitly that it's restricted.
Change:
3.1. <del> The first two bits of any connection-ID MUST encode the configuration phase of that ID.  QUIC-LB messages indicate the phase of the algorithm and parameters that they encode. A new configuration may change one or more parameters of the old configuration, or change the algorithm used. It is possible for servers to have mutually exclusive sets of supported algorithms, or for a transition from one algorithm to another to result in Fail Payloads.  The four states encoded in these two bits allow two mutually exclusive server pools to coexist, and for each of them to transition to a new set of parameters. </del> <ins> The first two bits of any connection ID MUST encode an identifier for the configuration that the connection ID uses.  This enables incremental deployment of new QUIC-LB settings (e.g., keys). </ins> When new configuration is distributed to servers, there will be a transition period when connection IDs reflecting old and new

Discussion:
Erik Fuller points out via email: He's right. We should just call it a configuration ID and be clearer on what's what.
Change:
specified via Provisioning Domain attributes (see prop-pvd) or another specific property. <ins> The default is to not set a preference for any interface. </ins> 5.2.11. pvd

Discussion:
Added defaults for interface and PvD following . Also, I caught one leftover "recommended default".
We require implementations to have default but we don't provide any recommendation for interface and PvD.
For Interface, this would the default be to set "Ignore" on all available interfaces, right? This indicates that the application has no preferences of its own, so the implementation can apply some default system policy. Also, if the application specified some local endpoint, this might constrain the actual interfaces used (related to ). If we try to phrase this as (Preference, Enumeration), it reads a bit weird though: ("Ignore", "Cellular") and ("Ignore", "WiFi"), for example. So perhaps we should just write text saying that the default is to set no application preference.
I think text is fine as well but we need to say something.
Thanks!
Change:
that the server is unwilling to use with "skR", the server returns an error. <del> Compute an HPKE context using "skR", a label of "ohttp request", and the encapsulated key "enc", yielding "context". </del> <ins> Compute an HPKE context using "skR", a label of "message/bhttp request", and the encapsulated key "enc", yielding "context". </ins> Construct additional associated data, "aad", from "keyID", "kemID", "kdfID", and "aeadID" or as the first seven bytes of

Discussion:
Test vectors generated from the .
With , we're enforcing a 1:1 mapping between message/ohttp-req and message/bhttp, but we don't have any cryptographic enforcement of this pairing. If someone were to reuse the encapsulation mechanism in this document with another message type, say, to encapsulate application/dns-message values with a application/oblivious-dns-message wrapper, then we'd probably want to ensure that targets can't get confused between these two types. We could use the HPKE info string to separate these two protocols. (This is related to .)
The encapsulated payload could be something other than HTTP. We should be clear about our decision to do that and how alternative payloads might be carried if people wanted to do that.
The clear example here would be allowing just a DNS message body. As long as the client and target agreed, they could use that without the proxy knowing. We could just loosen the restrictions on what the body is, or we could use different content types (if you want the proxy to know what it is?).
I think that the way you would do that is to define a new media type for DNS and then just go for it. (Of course, you need to debate whether to include a length field and a transaction ID field.) Maybe we don't need to do that in this draft, but we could explain how that might look.
I'd do the following here (in line with ): Replace as the HPKE info string with the content-type of the inner message, be it or . That way, both client and target must agree on the type of encapsulated payload to actually use it. Thoughts?
That might work. We have "ohttp response" as the label for HKDF expansion on the response. What would you include there? Maybe you should just extend with "message/bhttp request" and "message/bhttp response" and then the swapping in the media type becomes trivial.
Yeah, that's what I had in mind.
Sorry about that. Misremembered how this worked; I should have double-checked.
Change:
Identify the lowest common ancestor in the tree of the new member's leaf node and the member sending the Commit <del> Compute the path secret corresponding to the commonn ancestor </del> <ins> Compute the path secret corresponding to the common ancestor </ins> node Compute an EncryptedKeyPackage object that encapsulates the

Discussion:
This PR aims to fix some odd formulations, whilst maintaining the intended meaning of the sentences.
Thank you!
Change:
with the new key.  Failure to do so may allow message truncation attacks. <ins> With a 128-bit key as in AES-128, rekeying 2^64 times has a high probability of key reuse within a given connection.  Note that even if the key repeats, the IV is also independently generated, so the chance of a joint key/IV collision is much lower.  In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch - and hence the number of key updates - to exceed 2^48-1.  In order to allow this value to be changed later - for instance for ciphers with more than 128-bit keys - receiving implementations MUST NOT enforce this rule.  If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits and SHOULD instead ignore the "update_requested" flag.  This may result in an eventual need to terminate the connection when the limits in limits-on-key-usage are reached. </ins> 5. The TLS record protocol takes messages to be transmitted, fragments

Discussion:
Note that this is precisely the language that appears in 9147.
I made some updates, and am just merging in anticipation of the draft deadline. Feel free to file a PR if you think changes are indicated. NAME
In URL we added some text to DTLS about how rekeying too many times (2^64 is allowed with the 64-bit DTLS 1.3 epoch) risks key reuse within a connection, and accompanied it with a MUST NOT guidance to rekey more than 2^48 times (but receivers MUST NOT enforce the rule); this overrides the usual MUST-level requirement to match an "update_requested" KeyUpdate with another KeyUpdate before sending more data. It seems that some similar considerations apply for non-D TLS as well.
Change:
An in-network observer assuming that a set of packets belongs to a QUIC flow can infer the version number in use by observing the <del> handshake: an Initial packet with a given version from a client to which a server responds with an Initial packet with the same version implies acceptance of that version. </del> <ins> handshake: for QUIC version 1 if the version number in the Initial packet from a client is the same as the version number in Initial packet of the server response, that version has been accepted by both endpoints to be used for the rest of the connection. </ins> Negotiated version cannot be identified for flows for which a handshake is not observed, such as in the case of connection

Discussion:
This is not a declared invariant, but a property of version 1. As this pertains to version numbers, it might be assumed to be invariant. Maybe by scoping this to v1 explicitly here is the right answer.
lgtm
Change:
This document <del> 9.2. </del> <ins> 10.2. </ins> The following entries are added to the "HTTP Capsule Types" registry established by HTTP-DATAGRAM:

Discussion:
Chair: discussed during editors' call, plan is to go with Martin's simpler proposed encoding. We might want to discuss non-zero defaults later, but that'll be its own separate issue.
The document currently does not specify what the initial flow control windows are, nor how to change those. We have two options: Add WT_SETTINGS capsule Put those into headers
Discussed in editor's meeting, initial thinking is to put these values into the headers on the CONNECT message, rather than defining a new capsule or otherwise polluting HTTP/2's settings
Is there any reason that you want to avoid settings? The main thing that using settings would do is to provide the client with non-zero initial flow control limits on WT streams, so that it can send application data with zero latency. You can't get that without using settings. Functionally speaking, there is no real difference between a new capsule and a field, except that you can be a little more efficient with a capsule, modulo some issues regarding sequencing (do you allow it to appear anywhere? how do you manage changing values? etc...)
If we're talking about H2-connection level settings, then those are scoped to the entire connection. Using those would bring us closer to how H3 behaves (where connection-level stream configuration applies to WebTransport stream due to WT streams also being QUIC streams). On the other hand, we have designed WebTransport over HTTP/2 so that everything that happens within the CONNECT stream, so using headers/capsule instead of settings would be consistent with that. It would also mean you can transparently proxy WT-H2 to WT-H2 without parsing it (I do realize we currently say that you're not supposed to do that). Agreed. I have a mild preference for header fields since those are guaranteed to always arrive before any payload, making reasoning about their properties slightly easier.
The problem, as I see it, is that fields or capsules both lead to a situation where the client is unable to send any application data in its first flight (that is, along with the CONNECT-wossname request). What I want to avoid is the case where clients decide to improve performance by remembering initial values. I'm very much inclined to implement that caching, if only because it means that we can start using a session more quickly (for anything other than 0-RTT).

Perhaps the right answer is that we need some sort of way to encapsulate origin-wide per-resource configuration (that is, a baseline configuration that applies to all resources on the origin) and - until then - we stick with populating each resource with fields.
Chair: discussed during editors' call, see URL
Any reason why you did not do a single header field, like: Then at least the common repetitive stuff isn't repeated.
Change:
In this example, the AS is returning set of response-subject, simultaneously as an opaque identifier, an email address, and a <del> decentralized identifier URL (DID). </del> <ins> decentralized identifier (DID). </ins> 3.1.

Discussion:
updated examples updated examples for httpsig
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: a6cdcdcaf974e575a7e246dca7ada0e9b72e25cf Inspect the deploy log: Browse the preview:
Change:
4.1.5. The setLocalDescription method instructs the PeerConnection to apply <del> the supplied SDP blob as its local configuration.  The type field indicates whether the blob should be processed as an offer, provisional answer, or final answer; offers and answers are checked differently, using the various rules that exist for each SDP line. </del> <ins> the supplied session description as its local configuration.  The type field indicates whether the description should be processed as an offer, provisional answer, or final answer; offers and answers are checked differently, using the various rules that exist for each SDP line. </ins> This API changes the local media state; among other things, it sets up local resources for receiving and decoding media.  In order to

Discussion:
lgtm
need to be to "an" like in line 854?? URL
Fixed by
The word Blob is missing? URL
Change:
4.1.5. The setLocalDescription method instructs the PeerConnection to apply <del> the supplied SDP blob as its local configuration.  The type field indicates whether the blob should be processed as an offer, provisional answer, or final answer; offers and answers are checked differently, using the various rules that exist for each SDP line. </del> <ins> the supplied session description as its local configuration.  The type field indicates whether the description should be processed as an offer, provisional answer, or final answer; offers and answers are checked differently, using the various rules that exist for each SDP line. </ins> This API changes the local media state; among other things, it sets up local resources for receiving and decoding media.  In order to

Discussion:
This Replaces PR URL This fixes URL
I cleaned up the text here.
The structure of this looks good - just think the text should be expanded a bit.
This should incorporate the change in - and reference URL there as well.
lgtm
While cname for offers is described quite clearly, the sections describing answers don't mention CNAME.
This should get handled in NAME
I don't think that is the place. Looking at section 5.3.1. Initial answer, there is text saying 'If a local MediaStreamTrack has been associated, an "a=ssrc" line, as specified in [RFC5576], Section 4.1, indicating the SSRC to be used for sending media.' There should be something about cname here as well, just as it is for the corresponding part in section 5.2.1 Initial Offer.
Right, but is making changes to 5.2.1, so that's probably the right place to change 5.3.1 as well.
I saw Ekr updated and closed this one. Makes sense. , Justin Uberti EMAIL wrote:
Section 5.2.1: in accordance with [RFC7022]. [OPEN ISSUE: How are CNAMEs specified for MSTs? Are they randomly generated for each MediaStream? If so, can two MediaStreams be synced?]
Discussion on rtp usage more or less concluded that we'd use the same CNAME for an entire RTCPeerConnection, unless the tracks had different clock sources. And require different CNAMEs for different RTCPeerConnections, unless something had forced them to be the same. API affordances for this are TBD and for the W3C WG, Magnus suggested some sort of binding between RTCPeerConnection instances to allow for CNAME copying, rather than provide the footgun that direct overwriting permits (i.e., the browser is given the ability to mark unsynchronized tracks differently, rather than be forced to falsely claim synchronization).
Discussed in DC: this resolution is OK. Question about the use of LS groups for legacy gear, as opposed to MSID. See .
Related but URL
What are next steps here?
Propose browser generates one CNAME (or more if multiple clock sources). Later API may add ways to set the CNAME from JS.
That would be consistent with the RTP usage conclusions.