jiebi/CodeConvo huggingface dataset:
Code change:
A couple of minor editorial changes to the current draft, namely: There was a missing grave accent in one of the paragraphs of the Commit section causing some formatting issues Before: ! After: ! Fix typo Pre-Shared Keys section [...], it does not necessarily provide the same [...] guarantees ~than~ as a Commit message. Resolve remaining reference to priorepoch In the Sequencing section there was a reference to a field that was introduced in 2fa6ed3c6afc7d308905255b4cabe154a48d1e4b. However, in 69e12cd61378aae4a81199c28a16e2802666b6e3, it was removed from the struct where it was added. That entire struct was then removed in 27c9c28f9634a06a9b7921ea9c15e276f8c9ff6f, after which the trail runs cold. So I wasn't able to figure out exactly what it must be based on what on what it originally was. Hence, I replaced it with something that makes sense in context. I based the new text on the following line found in the (current) Commit section: Rewrite paragraph on the new_member SenderType I found the phrase " In such cases" after the sentence "Proposals with types other than Add MUST NOT be sent with this sender type" slightly confusing and awkward. To improve this I rewrote the paragraph.
Couple of nits on your nits

Related discussion:
text: in MLSPlaintext. The "new_member" SenderType is used for clients proposing that they <del> themselves be added.  For this ID type the sender value MUST be zero. Proposals with types other than Add MUST NOT be sent with this sender type.  In such cases, the MLSPlaintext MUST be signed with the private key corresponding to the KeyPackage in the Add message. Recipients MUST verify that the MLSPlaintext carrying the Proposal message is validly signed with this key. </del> <ins> themselves be added.  For this ID type the sender value MUST be zero and the Proposal type MUST be Add. The MLSPlaintext MUST be signed with the private key corresponding to the KeyPackage in the Add message.  Recipients MUST verify that the MLSPlaintext carrying the Proposal message is validly signed with this key. </ins> The "preconfigured" SenderType is reserved for signers that are pre- provisioned to the clients within a group.  If proposals with these
Code change:
A couple of minor editorial changes to the current draft, namely: There was a missing grave accent in one of the paragraphs of the Commit section causing some formatting issues Before: ! After: ! Fix typo Pre-Shared Keys section [...], it does not necessarily provide the same [...] guarantees ~than~ as a Commit message. Resolve remaining reference to priorepoch In the Sequencing section there was a reference to a field that was introduced in 2fa6ed3c6afc7d308905255b4cabe154a48d1e4b. However, in 69e12cd61378aae4a81199c28a16e2802666b6e3, it was removed from the struct where it was added. That entire struct was then removed in 27c9c28f9634a06a9b7921ea9c15e276f8c9ff6f, after which the trail runs cold. So I wasn't able to figure out exactly what it must be based on what on what it originally was. Hence, I replaced it with something that makes sense in context. I based the new text on the following line found in the (current) Commit section: Rewrite paragraph on the new_member SenderType I found the phrase " In such cases" after the sentence "Proposals with types other than Add MUST NOT be sent with this sender type" slightly confusing and awkward. To improve this I rewrote the paragraph.
Couple of nits on your nits

Related discussion:
text: The "path" field of a Commit message MUST be populated if the Commit covers at least one Update or Remove proposal, i.e., if the length of <del> the "updates" or "removes vectors is greater than zero.  The "path"field MUST also be populated if the Commit covers no proposals at all (i.e., if all three proposal vectors are empty).  The "path"field MAY be omitted if the Commit covers only Add proposals. In pseudocode, the logic for whether the "path` field is required is as follows: </del> <ins> the "updates" or "removes" vectors is greater than zero.  The "path" field MUST also be populated if the Commit covers no proposals at all (i.e., if all three proposal vectors are empty).  The "path" field MAY be omitted if the Commit covers only Add proposals.  In pseudocode, the logic for whether the "path" field is required is as follows: </ins> To summarize, a Commit can have three different configurations, with different uses:
Code change:
A couple of minor editorial changes to the current draft, namely: There was a missing grave accent in one of the paragraphs of the Commit section causing some formatting issues Before: ! After: ! Fix typo Pre-Shared Keys section [...], it does not necessarily provide the same [...] guarantees ~than~ as a Commit message. Resolve remaining reference to priorepoch In the Sequencing section there was a reference to a field that was introduced in 2fa6ed3c6afc7d308905255b4cabe154a48d1e4b. However, in 69e12cd61378aae4a81199c28a16e2802666b6e3, it was removed from the struct where it was added. That entire struct was then removed in 27c9c28f9634a06a9b7921ea9c15e276f8c9ff6f, after which the trail runs cold. So I wasn't able to figure out exactly what it must be based on what on what it originally was. Hence, I replaced it with something that makes sense in context. I based the new text on the following line found in the (current) Commit section: Rewrite paragraph on the new_member SenderType I found the phrase " In such cases" after the sentence "Proposals with types other than Add MUST NOT be sent with this sender type" slightly confusing and awkward. To improve this I rewrote the paragraph.
Couple of nits on your nits

Related discussion:
text: 12. Each Commit message is premised on a given starting state, indicated <del> in its "prior_epoch" field.  If the changes implied by a Commit messages are made starting from a different state, the results will be incorrect. </del> <ins> by the "epoch" field of the enclosing MLSPlaintext message.  If the changes implied by a Commit messages are made starting from a different state, the results will be incorrect. </ins> This need for sequencing is not a problem as long as each time a group member sends a Commit message, it is based on the most current
Code change:
This is a simple rename of to to be more descriptive of the action being performed by the message. I'll open a separate PR after this PIR is merged with updates to the spec where it uses when instead it should say (since not every actually ratchets forward key material, as I understand). Some examples of where these clarifications should happen are: Line 1203 should instead say "each MLS UpdatePath message" The sections "Ratchet Tree Evolution" and "Sychronizing Views of the Tree" should describe the process of generating the key material for an message cc NAME
DirectPath corresponds to the graph theory term "direct path" of a leaf with the root
"Direct path" is still a thing, and the object in question here operates along a direct path, but I think "UpdatePath" indicates more clearly what it's doing.

Related discussion:
text: above), then it MUST be populated.  Otherwise, the sender MAY omit the "path" field at its discretion. <del> If populating the "path" field: Create a DirectPath using the new </del> <ins> If populating the "path" field: Create a UpdatePath using the new </ins> tree (which includes any new members).  The GroupContext for this operation uses the "group_id", "epoch", "tree_hash", and "confirmed_transcript_hash" values in the initial GroupContext object. <del> Assign this DirectPath to the "path" field in the Commit. </del> <ins> Assign this UpdatePath to the "path" field in the Commit. </ins> <del> Apply the DirectPath to the tree, as described in </del> <ins> Apply the UpdatePath to the tree, as described in </ins> synchronizing-views-of-the-tree.  Define "commit_secret" as the value "path_secret[n+1]" derived from the "path_secret[n]" value assigned to the root node.
Code change:
This is a simple rename of to to be more descriptive of the action being performed by the message. I'll open a separate PR after this PIR is merged with updates to the spec where it uses when instead it should say (since not every actually ratchets forward key material, as I understand). Some examples of where these clarifications should happen are: Line 1203 should instead say "each MLS UpdatePath message" The sections "Ratchet Tree Evolution" and "Sychronizing Views of the Tree" should describe the process of generating the key material for an message cc NAME
DirectPath corresponds to the graph theory term "direct path" of a leaf with the root
"Direct path" is still a thing, and the object in question here operates along a direct path, but I think "UpdatePath" indicates more clearly what it's doing.

Related discussion:
text: the ratchet tree the provisional GroupContext, to update the ratchet tree and generate the "commit_secret": <del> Apply the DirectPath to the tree, as described in </del> <ins> Apply the UpdatePath to the tree, as described in </ins> synchronizing-views-of-the-tree, and store "key_package" at the Committer's leaf.
Code change:
Rotating keys is important and in some cases, Signature Keys are not going to be very "long-term". Instead they're going to be rotated periodically. I thus propose we simply remove the assumption that Signature Keys are of a "long-term" nature (or otherwise "long-lived"). The second change in this PR is that I added a few words indicating explicitly that the identity must not change when updating a KeyPackage.

Related discussion:
text: A key package that is prepublished by a client, which other clients can use to introduce the client to a new group. <del> A long-lived signing key pair used to authenticate the sender of a message. </del> <ins> A signing key pair used to authenticate the sender of a message. </ins> Terminology specific to tree computations is described in ratchet- trees.
Code change:
Rotating keys is important and in some cases, Signature Keys are not going to be very "long-term". Instead they're going to be rotated periodically. I thus propose we simply remove the assumption that Signature Keys are of a "long-term" nature (or otherwise "long-lived"). The second change in this PR is that I added a few words indicating explicitly that the identity must not change when updating a KeyPackage.

Related discussion:
text: Provider (SP) as described in I-D.ietf-mls-architecture.  In particular, we assume the SP provides the following services: <del> A long-term signature key provider which allows clients to authenticate protocol messages in a group. </del> <ins> A signature key provider which allows clients to authenticate protocol messages in a group. </ins> A broadcast channel, for each group, which will relay a message to all members of a group.  For the most part, we assume that this
Code change:
Rotating keys is important and in some cases, Signature Keys are not going to be very "long-term". Instead they're going to be rotated periodically. I thus propose we simply remove the assumption that Signature Keys are of a "long-term" nature (or otherwise "long-lived"). The second change in this PR is that I added a few words indicating explicitly that the identity must not change when updating a KeyPackage.

Related discussion:
text: as well as providing a public key that others can use for key agreement.  The client's signature key can be updated throughout the lifetime of the group by sending a new KeyPackage with a new <del> signature key; the new signature key MUST be validated by the </del> <ins> Credential.  However, the identity MUST be the same in both Credentials and the new Credential MUST be validated by the </ins> authentication service. When used as InitKeys, KeyPackages are intended to be used only once
Code change:
Rotating keys is important and in some cases, Signature Keys are not going to be very "long-term". Instead they're going to be rotated periodically. I thus propose we simply remove the assumption that Signature Keys are of a "long-term" nature (or otherwise "long-lived"). The second change in this PR is that I added a few words indicating explicitly that the identity must not change when updating a KeyPackage.

Related discussion:
text: 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 signature keys used by the protocol MUST be distributed by an "honest" authentication service for clients to authenticate their legitimate peers. </del> <ins> Note that the signature keys used by the protocol MUST be distributed by an "honest" authentication service for clients to authenticate their legitimate peers. </ins> 14.2.
Code change:
In preparation for feature-freeze / post-first-WGLC living, this PR removes a few issues that have been discussed and pretty much resolved. It leaves a few OPEN ISSUES that could benefit from analysis during the feature freeze.

Related discussion:
text: client being added to new groups by exhausting all available InitKeys. <ins> 15.5. It is possible for a malicious member of a group to "fragment" the group by crafting an invalid UpdatePath.  Recall that an UpdatePath encrypts a sequence of path secrets to different subtrees of the group's ratchet trees.  These path secrets should be derived in a sequence as described in ratchet-tree-evolution, but the UpdatePath syntax allows the sender to encrypt arbitrary, unrelated secrets. The syntax also does not guarantee that the encrypted path secret encrypted for a given node corresponds to the public key provided for that node. Both of these types of corruption will cause processing of a Commit to fail for some members of the group.  If the public key for a node does not match the path secret, then the members that decrypt that path secret will reject the commit based on this mismatch.  If the path secret sequence is incorrect at some point, then members that can decrypt nodes before that point will compute a different public key for the mismatched node than the one in the UpdatePath, which also causes the Commit to fail.  Applications SHOULD provide mechanisms for failed commits to be reported, so that group members who were not able to recognize the error themselves can reject the commit and roll back to a previous state if necessary. Even with such an error reporting mechanism in place, however, it is still possible for members to get locked out of the group by a malformed commit.  Since malformed Commits can only be recognized by certain members of the group, in an asynchronous application, it may be the case that all members that could detect a fault in a Commit are offline.  In such a case, the Commit will be accepted by the group, and the resulting state possibly used as the basis for further Commits.  When the affected members come back online, they will reject the first commit, and thus be unable to catch up with the group. Applications can address this risk by requiring certain members of the group to acknowledge successful processing of a Commit before the group regards the Commit as accepted.  The minimum set of acknowledgements necessary to verify that a Commit is well-formed comprises an acknowledgement from one member per node in the UpdatePath, that is, one member from each subtree rooted in the copath node corresponding to the node in the UpdatePath. </ins> 16. This document requests the creation of the following new IANA
Code change:
Discussed at 20210526 Interim. Merge.
Good point about allowing PSKs in a partial Commit!

Related discussion:
text: committer's contribution to the group and provides PCS with regard to the committer. <del> An "add-only" Commit that references only Add proposals, in which the path is optional.  Such a commit provides PCS with regard to the committer only if the path field is present. </del> <ins> A "partial" Commit that references Add, PreSharedKey, or ReInit proposals but where the path is empty.  Such a commit doesn't provide PCS with regard to the committer. </ins> A "full" Commit that references proposals of any type, which provides FS with regard to any removed members and PCS for the
Code change:
draft-08 is the latest HPKE draft, which should be stable. It is also what's being used for interop testing right now.
Discussed 20210526 Interim: Merge.

Related discussion:
text: A signature algorithm <del> MLS uses draft-07 of HPKE I-D.irtf-cfrg-hpke for public-key </del> <ins> MLS uses draft-08 of HPKE I-D.irtf-cfrg-hpke for public-key </ins> encryption.  The "DeriveKeyPair" function associated to the KEM for the ciphersuite maps octet strings to HPKE key pairs.
Code change:
Right now, the vector is described in a couple of ways. This PR standardizes on "of length ".

Related discussion:
text: in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows: <del> Here "0" represents the all-zero vector of length KDF.Nh.  The </del> <ins> Here "0" represents the all-zero vector of length "KDF.Nh".  The </ins> "index" field in "PSKLabel" corresponds to the index of the PSK in the "psk" array, while the "count" field contains the total number of PSKs.  In other words, the PSKs are chained together with KDF.Extract
Code change:
Right now, the vector is described in a couple of ways. This PR standardizes on "of length ".

Related discussion:
text: If not populating the "path" field: Set the "path" field in the Commit to the null optional.  Define "commit_secret" as the all- <del> zero vector of the same length as a "path_secret" value would be. In this case, the new ratchet tree is the same as the provisional ratchet tree. </del> <ins> zero vector of length "KDF.Nh" (the same length as a "path_secret" value would be).  In this case, the new ratchet tree is the same as the provisional ratchet tree. </ins> Derive the "psk_secret" as specified in pre-shared-keys, where the order of PSKs in the derivation corresponds to the order of
Code change:
Right now, the vector is described in a couple of ways. This PR standardizes on "of length ".

Related discussion:
text: from the "path_secret[n]" value assigned to the root node. If the "path" value is not populated: Define "commit_secret" as <del> the all-zero vector of the same length as a "path_secret" value would be. </del> <ins> the all-zero vector of length "KDF.Nh" (the same length as a "path_secret" value would be). </ins> Update the confirmed and interim transcript hashes using the new Commit, and generate the new GroupContext.
Code change:
Any Update proposal for the sender is redundant if the Commit includes a .
This is true, but they're also harmless, since the information in the will overwrite all of their effects. Note that: A requirement to this effect would only be binding on a committer. The receiver of a Commit MUST process all of the referenced proposals, as prescribed in the Commit. A is required if a Commit covers Updates or Removes; if a Commit covers a self-Update, then it must have a . So there's no reasn to condition on "if a is included". This seems fine for some advisory text, but not an absolute prohibition.
The way I read Section 11.2 is that the receiver should verify that the committer has followed the rules, e.g. that the commit contains all valid proposals, etc., even if that is not explicit in the list of things the receiver of a commit should do. So any requirement on the committer would also affect the receiver. So if we mandate that a committer can't include self-updates if the path is populated, then it would be implicit that the receiver checks that the committer actually followed the rules when processing a commit. I'm not sure I understand your second point. My reasoning would be that if a committer wants to do an update, they would just include a path rather than an update proposal, which is redundant anyway.
Sorry NAME I missed that there was still conversation going on here before merging . On the latter point: All I'm saying is that there is no case where there is both (a) a self-update and (b) no . So you're always in the bad scenario :) In our Wire chat, you made a good point that repeated proposals for the same leaf are invalid, and self-Updates are effectively repeats of the . Reopening, will file a fresh PR to adjust the text.

Related discussion:
text: process the Commit (i.e., not including any members being added or removed by the Commit). <ins> The sender of a Commit SHOULD NOT include any Update proposals that the sender themselves generated.  If sender generated one or more Update proposals during an epoch, then it SHOULD instead update its leaf and direct path by sending "path" field in the Commit. </ins> If there are multiple proposals that apply to the same leaf, the committer chooses one and includes only that one in the Commit, considering the rest invalid.  The committer MUST prefer any Remove
Code change:
Adds the overview text proposed in .
Thanks NAME !
Thanks for putting together the overview. The figures are great :-) Looks good to me with one proposition.

Related discussion:
text: actually allowed to evict other members; groups can enforce access control policies on top of these basic mechanism. <ins> 4.3. A group comprises a single linear sequence of epochs and groups are generally independent of one-another.  However, it can sometimes be useful to link epochs cryptographically, either within a group or across groups.  MLS derives a resumption pre-shared key (PSK) from each epoch to allow entropy extracted from one epoch to be injected into a future epoch.  This link guarantees that members entering the new epoch agree on a key if and only if were members of the group during the epoch from which the resumption key was extracted. MLS supports two ways to tie a new group to an existing group.  Re- initialization closes one group and creates a new group comprising the same members with different parameters.  Branching starts a new group with a subset of the original group's participants (with no effect on the original group).  In both cases, the new group is linked to the old group via a resumption PSK. Applications may also choose to use resumption PSKs to link epochs in other ways.  For example, the following figure shows a case where a resumption PSK from epoch "n" is injected into epoch "n+k".  This demonstrates that the members of the group at epoch "n+k" were also members at epoch "n", irrespective of any changes to these members' keys due to Updates or Commits. </ins> 5. The protocol uses "ratchet trees" for deriving shared secrets among a
Code change:
Make the definition of descendant match the common-sense definition (you are not your own descendant), adjust the text which uses the definition. Note: this allows for a much clearer definition of the tree invariant as well.

Related discussion:
text: precisely two children, a _left_ child and a _right_ child.  A node is the _root_ of a tree if it has no parents, and _intermediate_ if it has both children and parents.  The _descendants_ of a node are <del> that node, its children, and the descendants of its children, and we say a tree _contains_ a node if that node is a descendant of the root of the tree.  Nodes are _siblings_ if they share the same parent. </del> <ins> that node's children, and the descendants of its children, and we say a tree _contains_ a node if that node is a descendant of the root of the tree, or if the node itself is the root of the tree.  Nodes are _siblings_ if they share the same parent. </ins> <del> A _subtree_ of a tree is the tree given by the descendants of any node, the _head_ of the subtree.  The _size_ of a tree or subtree is </del> <ins> A _subtree_ of a tree is the tree given by any node (the _head_ of the subtree) and its descendants.  The _size_ of a tree or subtree is </ins> the number of leaf nodes it contains.  For a given parent node, its _left subtree_ is the subtree with its left child as head (respectively _right subtree_).