jiebi/CodeConvo huggingface dataset:
Change:
Blanking on add (I think) was obsoleted by unmerged leaves Add leaf to unmerged list for non-blank nodes on add There are now four elements in each node
Here's the Weekly Digest for : - - Last week 11 issues were created. Of these, 1 issues have been closed and 10 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 11 pull requests were created, updated or merged. Last week, 6 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Nice catch, Thank you !

Discussion:
for the specified KEM from a symmetric secret, using the specified hash function. <del> Each node in a ratchet tree contains up to three values: </del> <ins> Each node in a ratchet tree contains up to four values: </ins> A private key (only within direct path, see below)

If necessary, extend the tree to the right until it has at least index + 1 leaves <del> For each intermediate node along the path from the leaf at position "index" to the root, add "index" to the "unmerged_leaves" list for the node. Blank the path from the leaf at position "index" to the root </del> <ins> For each non-blank intermediate node along the path from the leaf at position "index" to the root, add "index" to the "unmerged_leaves" list for the node. </ins> Set the leaf node in the tree at position "index" to a new node containing the public key from the ClientInitKey in the Add, as
Change:
You can now rebase this on master for clarity.
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 3 comments. - - Last week, 8 pull requests were created, updated or merged. Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 3 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
This looks good, just one minor clarification

Discussion:
Construct an initial Commit object with "updates", "removes", and "adds" fields populated from Proposals received during the current <del> epoch, and an empty "path" field. </del> <ins> epoch, and empty "client_init_key" and "path" fields. </ins> Generate a provisional GroupContext object by applying the proposals referenced in the initial Commit object in the order

The "commit_secret" is the value "path_secret[n+1]" derived from the "path_secret[n]" value associated to the root node. <ins> Generate a new ClientInitKey for the Committer's own leaf.  Store it in the ratchet tree and assign it to the "client_init_key" field in the Commit object. </ins> Construct an MLSPlaintext object containing the Commit object. Use the "commit_secret" to advance the key schedule and compute the "confirmation" value in the MLSPlaintext.  Sign the
Change:
These are resolved in .
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 3 comments. - - Last week, 8 pull requests were created, updated or merged. Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 3 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .

Discussion:
While hashes at the nodes are used to check the integrity of the subtrees, signatures are required to provide authentication and group <del> agreement.  Siganatures are especially important in the case of </del> <ins> agreement.  Signatures are especially important in the case of </ins> newcomers and MUST be verified when joining.  All nodes in the tree MUST be signed to provide authentication and group agreement.
Change:
This PR aims to fix some odd formulations, whilst maintaining the intended meaning of the sentences.
Thank you!

Discussion:
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

For each parent of the common ancestor, up to the root of the tree, derive a new path secret and set the private key for the node to the private key derived from the path secret.  The <del> private key MUST be the private key that correspondns to the </del> <ins> private key MUST be the private key that corresponds to the </ins> public key in the node. Use the "epoch_secret" from the KeyPackage object to generate the

signatures on the messages under identity keys. [[ OPEN ISSUE: Signatures under the identity keys, while simple, have <del> the side-effect of preclude deniability.  We may wish to allow other options, such as (ii) a key chained off of the identity key, or (iii) some other key obtained through a different manner, such as a </del> <ins> the side-effect of precluding deniability.  We may wish to allow other options, such as (ii) a key chained off of the identity key, or (iii) some other key obtained through a different manner, such as a </ins> pairwise channel that provides deniability for the message contents.]]
Change:
Could you please just restore the PSK part of the KeySchedule, I’ll handle that separately. Ps: we wouldn’t have forgot you... :) we intended to go back to the list later, but I’ll merge it now...

Discussion:
An agent that uses this protocol to establish shared cryptographic state with other clients.  A client is defined by the <del> cryptographic keys it holds.  An application or user may use one client per device (keeping keys local to each device) or sync keys among a user's devices so that each user appears as a single client. </del> <ins> cryptographic keys it holds. </ins> A collection of clients with shared cryptographic state.
Change:
required a common signature algorithm, but allowed credentials to deviate. This PR adds the requirement that credentials be consistent.

Discussion:
specification for more information). The signature algorithm specified in the ciphersuite is the mandatory <del> algorithm to be used for the signatutes in MLSPlaintext and the tree signatures.  It can be different from the signature algorithm specified in credential field of ClientInitKeys. </del> <ins> algorithm to be used for signatures in MLSPlaintext and the tree signatures.  It MUST be the same as the signature algorithm specified in the credential field of the ClientInitKey objects in the leaves of the tree (including the ClientInitKeys used to add new members). </ins> The ciphersuites are defined in section mls-ciphersuites.
Change:
Since draft-08, we have neglected to update the changelog, despite a bunch of significant changes. Also, because our CI is busted, some build failures crept in.

Discussion:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-09 Remove blanking of nodes on Add (*) Change epoch numbers to uint64 (*) Add PSK inputs (*) Add key schedule exporter (*) Sign the updated direct path on Commit, using "parent hashes" and one signature per leaf (*) Use structured types for external senders (*) Redesign Welcome to include confirmation and use derived keys (*) Remove ignored proposals (*) Always include an Update with a Commit (*) Add per-message entropy to guard against nonce reuse (*) Use the same hash ratchet construct for both application and handshake keys (*) Add more ciphersuites Use HKDF to derive key pairs (*) Mandate expiration of ClientInitKeys (*) Add extensions to GroupContext and flesh out the extensibility story (*) </ins> draft-08 Change ClientInitKeys so that they only refer to one ciphersuite

This specification defines the following ciphersuites for use with MLS 1.0. <del> The KEM/DEM constructions used for HPKE are defined by HPKE.  The corresponding AEAD algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM, are defined in RFC5116.  AEAD_CHACHA20_POLY1305 is defined in RFC7539.  The corresponding hash algorithms are defined in SHS. </del> <ins> The KEM/DEM constructions used for HPKE are defined by I-D.irtf-cfrg- hpke.  The corresponding AEAD algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM, are defined in RFC5116.  AEAD_CHACHA20_POLY1305 is defined in RFC7539.  The corresponding hash algorithms are defined in SHS. </ins> It is advisable to keep the number of ciphersuites low to increase the chances clients can interoperate in a federated environment,
Change:
by updating the description for creating a commit to explicitly mention that first all update proposals are applied, then remove proposals, and last add proposals.
The writes: However, from this it is not immediately clear to me in which order the collections of proposals , , and are to be applied. I assume it should be in that order because it makes practical sense and because they're written in that order in the Commit struct. If my guess is correct, perhaps it would be useful to make this explicit? E.g.:
NAME - I agree with your interpretation here. Could you make a PR with some proposed wording?
Apologies for closing/opening the issue. I will open a PR to update the wording.

Discussion:
Generate a provisional GroupContext object by applying the proposals referenced in the initial Commit object in the order <del> provided, as described in proposals.  Add proposals are applied left to right: Each Add proposal is applied at the leftmost unoccupied leaf, or appended to the right edge of the tree if all leaves are occupied. </del> <ins> provided, as described in proposals.  First the list of update proposals, then the list of remove proposals, and last the list of add proposals.  Add proposals are applied left to right: Each Add proposal is applied at the leftmost unoccupied leaf, or appended to the right edge of the tree if all leaves are occupied. </ins> Create a DirectPath using the new tree (which includes any new members).  The GroupContext for this operation uses the

Generate a provisional GroupContext object by applying the proposals referenced in the commit object in the order provided, <del> as described in proposals.  Add proposals are applied left to right: Each Add proposal is applied at the leftmost unoccupied leaf, or appended to the right edge of the tree if all leaves are occupied. </del> <ins> as described in proposals.  First the list of update proposals, then the list of remove proposals, and last the list of add proposals.  Add proposals are applied left to right: Each Add proposal is applied at the leftmost unoccupied leaf, or appended to the right edge of the tree if all leaves are occupied. </ins> Process the "path" value using the ratchet tree the provisional GroupContext, to update the ratchet tree and generate the
Change:
by special-casing external senders. Removing the GroupContext would allow me to take messages that user A sent in one instance of a group, and make it look like they're speaking in another group by re-encrypting the ciphertext.
Right now, the signature on an MLSPlaintext includes the GroupContext for the group. If we are going to allow Add proposals signed by the new member, then this will need to change, because the new member doesn't know the GroupContext. My preference would be to simply remove the GroupContext from the plaintext. The Group ID is already included, so copy/paste protection can be added that way. The other elements of the GroupContext effectively overlap with the Epoch that is already signed.
Haven't thought about this too deeply, but having the full GroupContext in MLSPlaintextTBS means that we know all the members agree on the state of the ratchet tree, the transcript, the extensions. Removing it means we would no longer have agreement on those, right?
We won't have confirmation of agreement as a result of signature verification. The question is whether that is necessary. If the MLSPlaintext was decrypted from an MLSCiphertext, for example, then the successful decryption of the MLSCiphertext implies agreement on all those things. I suppose you could also switch the signature input based on SenderType, but that seems messier.
I'm not so sure that decrypting an MLSCiphertext implies agreement, because the crypto is symmetric. A man-in-the-middle can re-encrypt but not re-sign.

Discussion:
GroupContext for the current epoch, so that signatures are specific to a given group and epoch. <ins> [[OPEN ISSUE: group_id and epoch are duplicated in the TBS and in GroupContext.  Think about how to de-duplicate.]] </ins> The ciphertext field of the MLSCiphertext object is produced by supplying the inputs described below to the AEAD function specified by the ciphersuite in use.  The plaintext input contains content and

might propose to remove a member of a group has been inactive for a long time, or propose adding a newly-hired staff member to a group representing a real-world team.  Proposals originating outside the <del> group are identified by an "preconfigured" or "new_member" SenderType </del> <ins> group are identified by a "preconfigured" or "new_member" SenderType </ins> in MLSPlaintext. The "new_member" SenderType is used for clients proposing that they
Change:
This stuck out to me while reading because verification is explicitly specified for the 'newmember' sender type in the paragraph above this and not for the 'preconfigured' sender type. I think it would be better to specify this as the verification flow is different for these external proposals i.e. the KeyPackage in the proposal is used for newmember sender types, and the key corresponding to an authorized sender is used for preconfigured senders.

Discussion:
provisioned to the clients within a group.  If proposals with these sender IDs are to be accepted within a group, the members of the group MUST be provisioned by the application with a mapping between <del> these IDs and authorized signing keys.  To ensure consistent handling of external proposals, the application MUST ensure that the members of a group have the same mapping and apply the same policies to external proposals. </del> <ins> these IDs and authorized signing keys.  Recipients MUST verify that the MLSPlaintext carrying the Proposal message is validly signed with the corresponding key.  To ensure consistent handling of external proposals, the application MUST ensure that the members of a group have the same mapping and apply the same policies to external proposals. </ins> An external proposal MUST be sent as an MLSPlaintext object, since the sender will not have the keys necessary to construct an
Change:
This PR makes a few minor fixes to extensions: Coalesces and into a single extension Adds a list of supported extensions in parallel with the versions and ciphersuites Adds a missing value to the IANA table for the extension

Discussion:
the signature computation comprises all of the fields except for the signature field. <del> KeyPackage objects MUST contain at least three extensions, one of type "supported_versions", one of type "supported_ciphersuites", and one of type "lifetime".  The "supported_versions" and "supported_ciphersuites" extensions allow MLS session establishment to be safe from downgrade attacks on these two parameters (as discussed in group-creation), while still only advertising one version / ciphersuite per KeyPackage. </del> <ins> KeyPackage objects MUST contain at least two extensions, one of type "capabilities", and one of type "lifetime".  The "capabilities" extension allow MLS session establishment to be safe from downgrade attacks on the parameters described (as discussed in group-creation), while still only advertising one version / ciphersuite per KeyPackage. </ins> As the "KeyPackage" is a structure which is stored in the Ratchet Tree and updated depending on the evolution of this tree, each

7.1. <del> The "supported_versions" extension contains a list of MLS versions that are supported by the client.  The "supported_ciphersuites" extension contains a list of MLS ciphersuites that are supported by the client. </del> <ins> The "capabilities" extension indicates what protocol versions, ciphersuites, and protocol extensions are supported by a client. </ins> <del> These extensions MUST be always present in a KeyPackage. </del> <ins> This extension MUST be always present in a KeyPackage.  Extensions that appear in the "extensions" field of a KeyPackage MUST be included in the "extensions" field of the "capabilities" extension. </ins> 7.2.

Fetch KeyPackages for the members to be added, and selects a version and ciphersuite according to the capabilities of the members.  To protect against downgrade attacks, the creator MUST <del> use the "supported_versions" and "supported_ciphersuites" fields in these KeyPackages to verify that the chosen version and ciphersuite is the best option supported by all members. </del> <ins> use the "capabilities" extensions in these KeyPackages to verify that the chosen version and ciphersuite is the best option supported by all members. </ins> Initialize a one-member group with the following initial values (where "0" represents an all-zero vector of size Hash.length):

KP: KeyPackage messages <del> W: Welcome messages </del> <ins> GI: GroupInfo objects </ins> Recommended: Whether support for this extension is recommended by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended"
Change:
This PR tries to clarify these paragraphs by the following: Differentiating between HPKE public/private keys when describing how these keys are rotated for a commit Clarifying who does the actions associated with a commit Adding consistency fixes between the two paragraphs Let me know if these fixes are not quite right, as this PR tries to clarify where I had questions when reading.

Discussion:
5.4. <del> When performing a Commit, the leaf KeyPackage of the committer and its direct path to the root are updated with new secret values.  The HPKE leaf public key within the KeyPackage MUST be a freshly generated value to provide post-compromise security. The generator of the Commit starts by using the HPKE secret key "leaf_hpke_secret" associated with the new leaf KeyPackage (see key- packages) to compute "path_secret[0]" and generate a sequence of "path secrets", one for each ancestor of its leaf.  That is, path_secret[0] is used for the node directly above the leaf, </del> <ins> When performing a Commit, the generator of the Commit updates its leaf KeyPackage and its direct path to the root with new secret values.  The HPKE leaf public key within the KeyPackage MUST be derived from a freshly generated HPKE secret key to provide post- compromise security. The generator of the Commit starts by sampling a fresh random value called "leaf_secret", and uses the leaf_secret to generate their leaf HPKE key pair (see key-packages) and to seed a sequence of "path secrets", one for each ancestor of its leaf.  In this setting, path_secret[0] refers to the node directly above the leaf, </ins> path_secret[1] for its parent, and so on.  At each step, the path secret is used to derive a new secret value for the corresponding node, from which the node's key pair is derived.

For example, suppose there is a group with four members: If member B subsequently generates a Commit based on a secret <del> "leaf_hpke_secret", then it would generate the following sequence of path secrets: </del> <ins> "leaf_secret", then it would generate the following sequence of path secrets: </ins> After the Commit, the tree will have the following structure, where "np[i]" represents the node_priv values generated as described above: <ins> After performing these operations, the generator of the Commit MUST delete the leaf_secret. </ins> 5.5. The members of the group need to keep their views of the tree in sync
Change:
This PR adds a fix mentioned in but was not included in the PR that was eventually merged. Specifically, both public and encrypted private values are sent in a message containing key material to ratchet the tree forward.

Discussion:
of the group, who apply it to keep their local views of the tree in sync with the sender's.  When a client commits a change to the tree (e.g., to add or remove a member), it transmits a handshake message <del> containing a set of public values for intermediate nodes in the direct path of a leaf.  The other members of the group can use these public values to update their view of the tree, aligning their copy of the tree to the sender's. </del> <ins> containing a set of public and encrypted private values for intermediate nodes in the direct path of a leaf.  The other members of the group can use these values to update their view of the tree, aligning their copy of the tree to the sender's. </ins> To perform an update for a path (a Commit), the sender broadcasts to the group the following information for each node in the direct path