jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-mls-protocol

Commentary: 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 .
Paragraph (version A):
The "preconfigured" SenderType is reserved for signers that are pre-
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
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.
Paragraph (version B):
The "preconfigured" SenderType is reserved for signers that are pre-
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
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.
Draft: draft-ietf-mls-protocol

Commentary: I think we need to clearly define " FS / PCS with regard to " , but once we do that , it seems like a fine phrase . That seems like a good topic for a review / update of the Security Considerations once we have the protocol mostly in shape , for which I have filed . 
 The not - protocol parts of the document , including security considerations and some of the operational considerations , are mostly untouched since the beginning of this work . As we get the protocol firmed up , we should revisit these parts to make sure they 're up to date and give an accurate reflection of the concerns around the protocol . 
 One particular thing related to this that I noticed is that in the the first sentence : is outdated as ( ii ) can now also be an all - zero vector , namely if is not required and not set ( as introduced in if I 'm not mistaken ) . 
 I did a review of the Security Considerations and did n't see anything that needs fixing before WGLC . The point that raises appears to have been fixed in some other PR . 
 Right now , it is possible to send a Commit that covers no proposals . This has the result that the leaf of the sender and its direct path are refreshed , but no other change to the tree is made . ( The epoch also advances , of course . ) This can be is a useful operation . For example , an Add wipes out the new joiner 's direct path , so having the new joiner send a Commit over no proposals would fill in that direct path and make subsequent operations more efficient . We should clarify in some prose that ( a ) this is possible and ( b ) why it might be useful . 
 That works fine . I am a bit bothered by the phrasing regarding properties « with regard to ... » . If you can find an alternate phrasing that would be
Paragraph (version B):
A member of the group MAY send a Commit that references no proposals
at all, which would thus have empty vectors for "updates", "removes",
and "adds".  Such a Commit resets the sender's leaf and the nodes
along its direct path, and provides forward secrecy and post-
compromise security with regard to the sender of the Commit.  An
Update proposal can be regarded as a "lazy" version of this
operation, where only the leaf changes and intermediate nodes are
blanked out.
Paragraph (version B):
An "empty" Commit that references no proposals, which updates the
committer's contribution to the group and provides PCS with regard
to the committer.
Paragraph (version B):
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.
Paragraph (version B):
A "full" Commit that references proposals of any type, which
provides FS with regard to any removed members and PCS for the
committer and any updated members.
Draft: draft-ietf-mls-protocol

Commentary: I seem to recall you had some opinions on node hashing ? 
 Right now the LeafNodeHashInput struct uses the index of the node among the leaves , while the ParentNodeHashInput struct uses the index of the node among all nodes . This means that , for example , the index value will be the same for the second leaf and its parent ( in both cases ) . We should probably just use the node index in both cases . 
 is a better solution
Paragraph (version B):
Note that the "node_index" field contains the index of the leaf among
the nodes in the tree, not its index among the leaves; "node_index =
2 * leaf_index".
Draft: draft-ietf-mls-protocol

Commentary: 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 does n'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 that way . The other elements of the GroupContext effectively overlap with the Epoch that is already signed . 
 Have n'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 wo n'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 .
Paragraph (version A):
Add and Remove proposals can be constructed and sent to the group by
a party that is outside the group.  For example, a Delivery Service
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
group are identified by an "preconfigured" or "new_member" SenderType
in MLSPlaintext.
Paragraph (version B):
Add and Remove proposals can be constructed and sent to the group by
a party that is outside the group.  For example, a Delivery Service
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
group are identified by a "preconfigured" or "new_member" SenderType
in MLSPlaintext.
Draft: draft-ietf-mls-protocol

Commentary: In the latest HPKE draft ( draft - irtf - cfrg - hpke-04 ) , " Initiator ( I ) " was renamed to " Sender ( S ) " .
Paragraph (version A):
where "node_public_key" is the public key of the node that the path
secret is being encrypted for, group_context is the current
GroupContext object for the group, and the functions "SetupBaseI" and
"Seal" are defined according to I-D.irtf-cfrg-hpke.
Paragraph (version B):
where "node_public_key" is the public key of the node that the path
secret is being encrypted for, group_context is the current
GroupContext object for the group, and the functions "SetupBaseS" and
"Seal" are defined according to I-D.irtf-cfrg-hpke.
Draft: draft-ietf-mls-protocol

Commentary: 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. : 
 - 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 .
Paragraph (version A):
Generate a provisional GroupContext object by applying the
proposals referenced in the initial Commit object in the order
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.
Paragraph (version B):
Generate a provisional GroupContext object by applying the
proposals referenced in the initial Commit object in the order
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.
Paragraph (version A):
Generate a provisional GroupContext object by applying the
proposals referenced in the commit object in the order 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.
Paragraph (version B):
Generate a provisional GroupContext object by applying the
proposals referenced in the commit object in the order 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.
Draft: draft-ietf-mls-protocol

Commentary: When we converted to the Proposal / Commit scheme , one of the consequences was that Adds became O(N ) instead of O(1 ) , since they had to Committed and commits encrypt the committer 's direct path to the remainder of the tree . This is ~log(N ) in the nice case and ~N in the worst case . At the time , we noted that one could special - case Add - only Commits in the future and make the update to the direct path optional in that case . This PR implements that suggestion . The leaf KeyPackage for the Commit is moved into the DirectPath struct , and the whole DirectPath is made optional . The optional value MUST be provided for : A Commit committing an update or remove A " just update my path " Commit covering no proposals 
 So we do go forward one epoch , but with an all - zero commit secret . Do I understand that correctly ? 
 That 's correct . The idea is that you do n't need to send the current group any additional entropy , you just need them to hash forward . Note that this could change the FS / PCS guarantees available . But I do n't think we ever proposed that Add would cause any FS / PCS changes to the group , so maybe this does n't matter . 
 Add should give FS guarantees in so far as that the new member should n't be able to decrypt old messages or derive old keys . But I think ratcheting forward should do the trick . We should note , though , that this breaks the ( implicit ) assumption that a commit always introduces fresh key material to the group . As far as I can see , that 's not breaking anything right now , but we should keep it in mind . 
 Note : The latest commit fixes a gap that was discovered in . 
 See the flexibility question .
Paragraph (version A):
Create a DirectPath using the new 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.
Paragraph (version A):
Assign this DirectPath to the "path" fields in the Commit.
Paragraph (version B):
Decide whether to populate the "path" field: If the "path" field
is required based on the proposals that are in the commit (see
above), then it MUST be populated.  Otherwise, the sender MAY omit
the "path" field at its discretion.
Paragraph (version A):
Compute an EncryptedGroupSecrets object that encapsulates the
"init_secret" for the current epoch and the path secret for the
common ancestor.
Paragraph (version B):
Compute an EncryptedGroupSecrets object that encapsulates the
"init_secret" for the current epoch and the path secret (if
present).
Paragraph (version A):
Identify the lowest common ancestor of the leaves at "index"
and at "GroupInfo.signer_index".  Set the private key for this
node to the private key derived from the "path_secret" in the
GroupSecrets object.
Paragraph (version B):
If the "path_secret" value is set in the GroupSecrets object:
Identify the lowest common ancestor of the leaves at "index"
and at "GroupInfo.signer_index".  Set the private key for this
node to the private key derived from the "path_secret".
Draft: draft-ietf-mls-protocol

Commentary: This PR addresses
Paragraph (version A):
Before the initialization of a group, clients publish InitKeys (as
KeyPackage objects) to a directory provided by the Messaging Service.
Paragraph (version B):
Before the initialization of a group, clients publish InitKeys (as
KeyPackage objects) to a directory provided by the Service Provider.
Draft: draft-ietf-mls-protocol

Commentary: 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 .
Paragraph (version A):
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.
Paragraph (version B):
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.
Draft: draft-ietf-mls-protocol

Commentary: required a common signature algorithm , but allowed credentials to deviate . This PR adds the requirement that credentials be consistent .
Paragraph (version A):
The signature algorithm specified in the ciphersuite is the mandatory
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.
Paragraph (version B):
The signature algorithm specified in the ciphersuite is the mandatory
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).
Draft: draft-ietf-mls-protocol

Commentary: Could you please just restore the PSK part of the KeySchedule , I ’ll handle that separately . Ps : we would n’t have forgot you ... :) we intended to go back to the list later , but I ’ll merge it now ...
Paragraph (version A):
An agent that uses this protocol to establish shared cryptographic
state with other clients.  A client is defined by the
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.
Paragraph (version B):
An agent that uses this protocol to establish shared cryptographic
state with other clients.  A client is defined by the
cryptographic keys it holds.
Draft: draft-ietf-mls-protocol

Commentary: This PR aims to fix some odd formulations , whilst maintaining the intended meaning of the sentences . 
 Thank you !
Paragraph (version A):
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
private key MUST be the private key that correspondns to the
public key in the node.
Paragraph (version B):
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
private key MUST be the private key that corresponds to the
public key in the node.
Draft: draft-ietf-mls-protocol

Commentary: This PR adapts the Welcome logic so that the new joiners get their path secrets directly , rather than from a DirectPath . This cleans things up in a few ways . The new joiners no longer have to have the context for the previous epoch ( which was used to encrypt the DirectPath ) . And we can get away with one HPKE operation per new joiner instead of two ( one for the EncryptedKeyPackage and one for the DirectPath ) . The major cost is that there 's a bit more complexity in the TreeKEM . Instead of just producing and consuming  , you now need to know which path secrets go with which nodes . You also need tree math to identify the common ancestor of two leaves , but there 's a simple closed - form formula for that , expressed in the Python code here . 
 - Curious if this seems implementable to you . Clearly it 's possible , since I did it in Go :) But it also needs to make sense to other people .
Paragraph (version A):
For each new member in the group, compute an EncryptedKeyPackage
object that encapsulates the "init_secret" for the current epoch.
Construct a Welcome message from the encrypted GroupInfo object
and the encrypted key packages.
Paragraph (version B):
Compute an EncryptedKeyPackage object that encapsulates the
"init_secret" for the current epoch and the path secret for the
common ancestor.
Paragraph (version B):
Construct a Welcome message from the encrypted GroupInfo object
and the encrypted key packages.
Paragraph (version A):
Apply the DirectPath to the tree, as described in
synchronizing-views-of-the-tree.
Paragraph (version A):
Define "commit_secret" as the value "path_secret[n+1]" derived
from the "path_secret[n]" value assigned to the root node.
Paragraph (version B):
Update the leaf at index "index" with the private key
corresponding to the public key in the node.
Paragraph (version B):
Identify the lowest common ancestor of the leaves at "index"
and at "GroupInfo.signer_index".  Set the private key for this
node to the private key derived from the "path_secret" in the
KeyPackage object.
Paragraph (version B):
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
private key MUST be the private key that correspondns to the
public key in the node.
Draft: draft-ietf-mls-protocol

Commentary: You can also strike this sentence further down : " In particular , for the leaf node , there are no encrypted secrets , since a leaf node has no children . " 
 Note that this severs the connection between the HPKE key in the leaf and the parent of the leaf . Whereas before , the leaf HPKE key was derived from a path secret , and the parent HPKE key was derived from the next path secret . Now the parent path secret is set directly , and the leaf HPKE key is set completely independently , with no dependency on a path secret . So we 're losing a bit of internal structure in the tree . But this seems OK because that structure was never observable to the group -- only the holder of the leaf knows the leaf path secret , so nobody else could verify that the leaf was related to its parent .
Paragraph (version A):
The _direct path_ of a root is the empty list, and of any other node
is the concatenation of that node with the direct path of its parent.
The _copath_ of a node is the list of siblings of nodes in its direct
path.  The _frontier_ of a tree is the list of heads of the maximal
full subtrees of the tree, ordered from left to right.
Paragraph (version B):
The _direct path_ of a root is the empty list, and of any other node
is the concatenation of that node's parent along with the parent's
direct path.  The _copath_ of a node is the node's sibling
concatenated with the list of siblings of all the nodes in its direct
path.  The _frontier_ of a tree is the list of heads of the maximal
full subtrees of the tree, ordered from left to right.
Paragraph (version A):
The path secret value for a given node is encrypted for the subtree
corresponding to the parent's non-updated child, that is, the child
on the copath of the leaf node.  There is one encrypted path secret
for each public key in the resolution of the non-updated child.  In
particular, for the leaf node, there are no encrypted secrets, since
a leaf node has no children.
Paragraph (version B):
The path secret value for a given node is encrypted for the subtree
corresponding to the parent's non-updated child, that is, the child
on the copath of the leaf node.  There is one encrypted path secret
for each public key in the resolution of the non-updated child.
Draft: draft-ietf-mls-protocol

Commentary: 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 < kbd : eyes : Watch</kbdand < kbd : star : Star</kbdthe repository to receive next weekly updates . : smiley : You can also .
Paragraph (version A):
While hashes at the nodes are used to check the integrity of the
subtrees, signatures are required to provide authentication and group
agreement.  Siganatures are especially important in the case of
newcomers and MUST be verified when joining.  All nodes in the tree
MUST be signed to provide authentication and group agreement.
Paragraph (version B):
While hashes at the nodes are used to check the integrity of the
subtrees, signatures are required to provide authentication and group
agreement.  Signatures are especially important in the case of
newcomers and MUST be verified when joining.  All nodes in the tree
MUST be signed to provide authentication and group agreement.