jiebi/CodeConvo huggingface dataset:
Code change:
If the client instance is capable of displaying or otherwise communicating a short, human-entered code to the RO, the client <del> instance indicates this by sending the "user_code" field with the boolean value "true".  This code is to be entered at a static URL that does not change at runtime.  While this URL is generally hosted at the AS, the client instance can make no assumptions about its </del> <ins> instance indicates this by including "user_code" in the array under the "start" key.  This code is to be entered at a static URL that does not change at runtime.  While this URL is generally hosted at the AS, the client instance can make no assumptions about its </ins> contents, composition, or relationship to the AS grant URL. If this interaction mode is supported for this client instance and

Related discussion:
text: The boolean value "true" is no longer used to specify supported interaction start modes.
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: ef948b6b0b53f92352ec617e6074174e0a2eaa3f Inspect the deploy log: Browse the preview:
Code change:
7.2.2. A conventional Diffie-Hellman computation is performed.  The <del> negotiated key (Z) is used as the shared_secret, and is used in the </del> <ins> negotiated key (Z) is used as the shared secret, and is used in the </ins> key schedule as specified above.  Leading bytes of Z that contain all zero bits are stripped before it is used as the input to HKDF.

Related discussion:
text: Just a few things I noticed that I think make it a little bit easier to follow. Name resumption_secret consistently when used Show full legend for each handshake flow Simplify/clarify secret sources table a bit and make text cases consistent The resumption secret naming was also apparently noticed by NAME in issue . (Edited to note: this PR has been pruned down to a smaller list of changes; see commit message)
Ok, to respond to comments I've pushed a new commit. RE: capitalization: Upper or lower is fine, as long as it's consistent. I've switched it to all upper (title case) instead of all lower. RE: legend repetition: If you're just reading one section, e.g. got to it via TOC, you might not have seen the legend (recently). I've made it less wordy now and also added a line to indicate "+" is for extensions, as I realized that wasn't necessarily clear. (and added a "+" where the notation was inconsistent) We do have an extension that was previously a message, now. The basic point is consistency; make each handshake flow make sense on its own. I think repeating the legend is helpful, but if you really don't want to repeat it that I can cut this down to just the little stuff and table. Showing "N/A" instead of repeating things in the table is the most helpful part here, I think. It states that SS=ES in some circumstances elsewhere, but the table isn't clear that these are the exact same values, especially because the extracted ones are not.
Edited again and repushed for some more naming consistency.
Revised & rebased. Of note, I think these changes to the table make it far easier to see what's going on here.
NAME If you're going to be rewriting this, I'll just set those parts aside. The commit here is now just the little stuff: fix the spacing, add a line stating what SS/ES are in the list of derivations, and fix "shared_secret" (there's no such value named that; just drop the underscore).
NAME commit updated with fixes for your comments above
The key derivation process uses the "master secret" as the basis for application traffic keys and both the resumption and exporter secrets. There are lots of other secrets though.
Code change:
7.2.2. A conventional Diffie-Hellman computation is performed.  The <del> negotiated key (Z) is used as the shared_secret, and is used in the </del> <ins> negotiated key (Z) is used as the shared secret, and is used in the </ins> key schedule as specified above.  Leading bytes of Z that contain all zero bits are stripped before it is used as the input to HKDF.

Related discussion:
text: I don't have a better name right now, so close this if none better can be found. Also s/resumption master secret/resumption secret/ throughout, it's a little inconsistent.
Now master of more
Code change:
5.4. In order to maximize interoperability, DNS API clients and DNS API <del> servers MUST support the "message/dns" media type.  Other media types MAY be used as defined by HTTP Content Negotiation (RFC7231 Section 3.4). </del> <ins> servers MUST support the "application/dns-message" media type.  Other media types MAY be used as defined by HTTP Content Negotiation (RFC7231 Section 3.4). </ins> 6.

Related discussion:
text: Fixes issue
The message/ tree requires that the sub-types contain other MIME messages, which DOH does not. Maybe use application/dns-message instead.
Code change:
creator, because they are derived from an authenticated key exchange protocol.  Subsequent leaf keys are known only by their owner. <del> Note that the long-term identity keys used by the protocol MUST be </del> <ins> Note that the long-term signature keys used by the protocol MUST be </ins> distributed by an "honest" authentication service for clients to authenticate their legitimate peers.

Related discussion:
text: The credentials we have defined at the moment only contain a single public key and no information regarding what signature scheme that keypair works with (even though the Spec actually says it should include the signature scheme as well). It would be nice, however, to support potential CredentialTypes that, similar to KeyPackages, include multiple supported signature schemes, each accompanied by a corresponding public key. The Key that should be used in any given group is then determined by the CipherSuite of the group (which includes a Signature Scheme). When choosing a KeyPackage of a new member, it has to be one that contains a Credential which supports that Signature Scheme. Note, that I'm not suggesting that this be the case in all Credentials, or even that we change the BasicCredential. I understand that it's possible to have multiple credentials per identity, but in some authentication settings it can be beneficial to have a 1-to-1 mapping between Credential and identity.
KeyPackages don't support multiple signature schemes? In what scenario is it beneficial?
Ah, right. I think that was the case in the past, but you're right, they don't. Of course it's always possible to just bundle a bunch of certificates, each supporting a different signature scheme and then treat that as your "Multi-Scheme Credential" in the grand scheme of things. However, if you end up rotating them a lot, where you have to sign them and potentially store the whole chain for a longer period of time, being able to support multiple signature schemes in only one credential means less overhead.
Credentials are stored in each group's ratchet tree though, so you're keeping a bunch of unnecessary key material in the group's tree which everyone has to store
That's fair. And it's not something you have to do if you don't want to. I'm just proposing for MLS to support that type of Credential in general.
To support hybrid PQ/standard schemes at any point in the future, allowing for multiple schemes is reasonable (in addition to the above arguments for it). Most applications probably will not use the feature, especially to start with, but providing support for just the option is not going to cause any of the problems noted.
PQ schemes can be used by switching the entire group to a new ciphersuite using those schemes.
Code change:
creator, because they are derived from an authenticated key exchange protocol.  Subsequent leaf keys are known only by their owner. <del> Note that the long-term identity keys used by the protocol MUST be </del> <ins> Note that the long-term signature keys used by the protocol MUST be </ins> distributed by an "honest" authentication service for clients to authenticate their legitimate peers.

Related discussion:
text: Requiring everybody in the group to store a bunch of unused key material isn't reasonable
The statement was not about PQ, but hybrid PQ/standard schemes. Those require use to two signature schemes, for which both types of keying material are used.
Then you need a ciphersuite that specifies a hybrid scheme.
It would be ideal to have a ciphersuite specifying a single hybrid scheme, but even that does not imply use of a single credential, unfortunately. In fact, hybrid schemes may rely on two separate credentials, with the ciphersuite specifying the hybrid algorithm for combining them. Since the "main" method of building a solo hybrid credential is under patent, there is also additional motivation for applications to use two.
I concur with Brendan here. To be consistent with our earlier decisions to (a) keep KeyPackages to one ciphersuite and (b) include the signature algorithm in the ciphersuite, we should keep credentials to one signature algorithm as well. Propose closing this PR without merging.
Discussed at 2020-10-06 interim, TODO: Re-add SignatureScheme enum, re-using the TLS signature schemes Clarify that the main job of a Credential is to provide a public key for verifying messages How it provides the credential might be different per credential type e.g., in BasicCredential, it's provided directly, X509Credential, have to parse the leaf certificate
LGTM with a couple nits.
Code change:
JSEP implementations must comply with the specifications listed below that govern the creation and processing of offers and answers. <del> The first set of specifications is the "mandatory-to-implement" set. All implementations must support these behaviors, but may not use all of them if the remote side, which may not be a JSEP endpoint, does not support them. The second set of specifications is the "mandatory-to-use" set.  The local JSEP endpoint and any remote endpoint must indicate support for these specifications in their session descriptions. </del> 5.1.1. <del> Implementations of JSEP MUST conform to I-D.ietf-rtcweb-rtp-usage. This list of mandatory-to-implement specifications is derived from the requirements outlined in that document and from I-D.ietf-rtcweb- security-arch. RFC4566 is the base SDP specification and MUST be implemented. RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF RFC5764, TCP/DTLS/RTP/SAVPF RFC7850, "UDP/DTLS/SCTP" I-D.ietf- mmusic-sctp-sdp, and "TCP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp RTP profiles. RFC5245 MUST be implemented for signaling the ICE credentials and candidate lines corresponding to each media stream.  The ICE implementation MUST be a Full implementation, not a Lite implementation. RFC5763 MUST be implemented to signal DTLS certificate fingerprints. RFC5888 MUST be implemented for signaling grouping information, and MUST be used to identify m= lines via the a=mid attribute. I-D.ietf-mmusic-msid MUST be supported, in order to signal associations between RTP objects and W3C MediaStreams and MediaStreamTracks in a standard way. The bundle mechanism in I-D.ietf-mmusic-sdp-bundle-negotiation MUST be supported to signal the ability to multiplex RTP streams on a single UDP port, in order to avoid excessive use of port number resources. The SDP attributes of "sendonly", "recvonly", "inactive", and "sendrecv" from RFC4566 MUST be implemented to signal information about media direction. RFC5576 MUST be implemented to signal RTP SSRC values and grouping semantics. RFC4585 MUST be implemented to signal RTCP based feedback. RFC5761 MUST be implemented to signal multiplexing of RTP and RTCP. RFC5506 MUST be implemented to signal reduced-size RTCP messages. RFC4588 MUST be implemented to signal RTX payload type associations. RFC3556 MUST be supported for control of RTCP bandwidth limits. The SDES SRTP keying mechanism from RFC4568 MUST NOT be implemented, as discussed in I-D.ietf-rtcweb-security-arch. As required by RFC4566, Section 5.13, JSEP implementations MUST ignore unknown attribute (a=) lines. 5.1.2. </del> All session descriptions handled by JSEP implementations, both local and remote, MUST indicate support for the following specifications. If any of these are absent, this omission MUST be treated as an

Related discussion:
text: All the xref I removed are used elsewhere in spec other than the one which I added to where it is used.
Fixed as Justin suggested and ready for re review
NAME - have a look - I think I got all the changes
I tweaked the discussion of unknown a=; now LGTM
Code change:
signature, the Attester Identity, and the Handle, and then appraises the Claims.  Appraisal procedures are application-specific and can be conducted via comparison of the Claims with corresponding Reference <del> Claims, such as Reference Integrity Measurements.  The final output </del> <ins> Values, such as Reference Integrity Measurements.  The final output </ins> of the Verifier are Attestation Results.  Attestation Results constitute new Claim Sets about the properties and characteristics of an Attester, which enables Relying Parties, for example, to assess an

Related discussion:
text: Based on URL I suggest using Reference Values to keep consistent with the RATS arch.
+1 for "Reference Values"
on it Hi Henk, I've reviewed the reference interaction models I-D recently, I hope the comments below can help improve the draft before the IETF110 draft submission cut-off. Section 3 Disambiguation Comment > This section is talking about the disambiguation of terminology, so I suggest making it a sub-section of Section 2 Terminology. Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)). Comment > About "these types of co-located environments", The previous sentences are about the Verifier and Attester don't need to be remote. So "these" is weird here, because here is about the attesting environment and target environment. Section 5 Direct Anonymous Attestation Comment > I think it's better to move this section to the bottom of the draft. DAA doesn't introduce a new information elements, and only augments the scope/definition of Attester Identity and Authentication Secret IDs, describing it after the introduction of all the 3 basic interaction models would be better. Putting DAA in the middle makes me feel the basic interaction models rely upon DAA, but actually it's not. This document extends the duties of the Endorser role as defined by the RATS architecture with respect to the provision of these Attester Identity documents to Attesters. The existing duties of the Endorser role and the duties of a DAA Issuer are quite similar as illustrated in the following subsections. Comment > Without DAA, I think the Endorser also needs to provision the Attester Identity to Attesters. And as I understand, the DAA Issuer is a supply chain entity before the Attester being shipped, so it is the Endorser when DAA is used, right? If yes, then in the next sentence, the comparison between Endorser and DAA Issuer doesn't make sense to me.
Code change:
signature, the Attester Identity, and the Handle, and then appraises the Claims.  Appraisal procedures are application-specific and can be conducted via comparison of the Claims with corresponding Reference <del> Claims, such as Reference Integrity Measurements.  The final output </del> <ins> Values, such as Reference Integrity Measurements.  The final output </ins> of the Verifier are Attestation Results.  Attestation Results constitute new Claim Sets about the properties and characteristics of an Attester, which enables Relying Parties, for example, to assess an

Related discussion:
text: Section 5.1 Endorsers Comment > Does this section have difference with the definition of Endorser in architecture draft? If not, is it necessary to keep this section? Comment > This section only describes the Layered Attestation, but the scope of Endorsement is more than what's described here. Endorsement indicates the Attester's various capabilities such as Claims collection and Evidence signing. For other situations than Layered Attestation, the Endorser and Endorsement are also needed. So why only mention Layered Attestation here? I don't see any special relationship between DAA and Layered Attestation. Section 5.2 Endorsers for Direct Anonymous Attestation In order to enable the use of DAA, an Endorser role takes on the duties of a DAA Issuer in addition to its already defined duties. DAA Issuers offer zero-knowledge proofs based on public key certificates used for a group of Attesters [DAA]. Effectively, these certificates share the semantics of Endorsements, with the following exceptions: Comment > In the first sentence, I suggest saying that "a DAA Issuer takes on the role of an Endorser". o The associated private keys are used by the DAA Issuer to provide an Attester with a credential that it can use to convince the Verifier that its Evidence is valid. To keep their anonymity the Attester randomizes this credential each time that it is used. Comment > How to understand "Evidence is valid"? Does it mean the Evidence is sent from an authentic Attester and not tampered during the conveyance? Or does it mean the Evidence comes from a RoT and is trustable (although the Evidence can diverge from the Reference Values)? Comment > When saying "Attester randomizes this credential", how many credentials does an Attester have? 1) Can a DAA Issuer have multiple key pairs and use them for one Attester? 2) Can a DAA Issuer use one key pair to generate multiple credentials for one Attester? o A credential is conveyed from an Endorser to an Attester in combination with the conveyance of the public key certificates from Endorser to Verifier.
Code change:
signature, the Attester Identity, and the Handle, and then appraises the Claims.  Appraisal procedures are application-specific and can be conducted via comparison of the Claims with corresponding Reference <del> Claims, such as Reference Integrity Measurements.  The final output </del> <ins> Values, such as Reference Integrity Measurements.  The final output </ins> of the Verifier are Attestation Results.  Attestation Results constitute new Claim Sets about the properties and characteristics of an Attester, which enables Relying Parties, for example, to assess an

Related discussion:
text: Comment > Is there another way to convey the public key certificate, for example, can the public key certificates be conveyed from Endorser to Attester first and then from Attester to Verifier? The zero-knowledge proofs required cannot be created by an Attester alone - like the Endorsements of RoTs - and have to be created by a trustable third entity - like an Endorser. Due to that semantic overlap, the Endorser role is augmented via the definition of DAA duties as defined below. This augmentation enables the Endorser to convey trustable third party statements both to Verifier roles and Attester roles. Comment > For "the definition of DAA duties as defined below", what is the definition of DAA duties? Comment > In the last sentence, the Endorsement with its original definition is the third party statement for Verifier and Attester, isn't it? So, "augmentation" isn't the correct expression. Section 6 Normative Prerequisites Attester Identity: The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous. Comment > The Attester Identity is to identify which Attester the Evidence comes from. But if the Attester has multiple Attesting Environments, what should be the Attester Identity? Comment > The TPM's AIK certificate is one kind of Attester Identity, right? Attestation Evidence Authenticity: Attestation Evidence MUST be correct and authentic. Comment > Is it appropriate to say "correct Evidence"? If saying so, I think it means that the Evidence satisfies the Attestation Policy for Evidence. Authentication Secret: An Authentication Secret MUST be available exclusively to an Attester's Attesting Environment. The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence. The Authentication Secret MUST be established before RATS can take place. Comment > Does the Authentication Secret represent the identity of the Attesting Environment? Comment > How to understand the Authentication Secret, and is it necessary all the time? For example, in our implementation, during the router booting up, the BIOS measures the BootLoader and records the measured hash value into the TPM, and the BootLoader measures the OS Kernel and records the measured hash value into the TPM as well.
Code change:
signature, the Attester Identity, and the Handle, and then appraises the Claims.  Appraisal procedures are application-specific and can be conducted via comparison of the Claims with corresponding Reference <del> Claims, such as Reference Integrity Measurements.  The final output </del> <ins> Values, such as Reference Integrity Measurements.  The final output </ins> of the Verifier are Attestation Results.  Attestation Results constitute new Claim Sets about the properties and characteristics of an Attester, which enables Relying Parties, for example, to assess an

Related discussion:
text: From the Layered Attestation perspective, I think (BIOS + TPM) is the Attesting Environment and (BootLoader + TPM) is also the Attesting Environment. But the Claims (measured hash values) aren't protected separately, and they finally becomes the Evidence (TPM Quote) and it's only protected by the TPM's AIK. So, what is the Authentication Secret? Section 7 Generic Information Elements Attester Identity ('attesterIdentity'): mandatory A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. Comment > Previous section says "Attester Identity" is about "a distinguishable Attesting Environment", and here says it's about "a distinguishable Attester". Comment > How to understand "without accompanying evidence about its validity"? Attester Identity ('attesterIdentity'): mandatory In DAA, the Attester's identity is not revealed to the verifier. The Attester is issued with a credential by the Endorser that is randomized and then used to anonymously confirm the validity of their evidence. The evidence is verified using the Endorser's public key. Comment > I think here means the DAA credential represents the Attester Identity. Comment > There is ambiguity of "that is randomized", does it mean randomized Endorser or randomized credential? Comment > For "confirm the validity of their evidence", what does "their" refer to? And what does "the validity of evidence" mean? Authentication Secret IDs ('authSecID'): mandatory A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Evidence. Comment > Previous section says "Authentication Secret" is used to protect Claims, but here says it's used to protect Evidence. Comment > As I understand, if Authentication Secret represents the identity of Attesting Environment, then it's not mandatory, at least in our implementation. Authentication Secret IDs ('authSecID'): mandatory In DAA, Authentication Secret IDs are represented by the Endorser (DAA issuer)'s public key that MUST be used to create DAA credentials for the corresponding Authentication Secrets used to protect Evidence. In DAA, an Authentication Secret ID does not identify a unique Attesting Environment but associated with a group of Attesting Environments.