Draft: draft-ietf-mls-protocol

Commentary: Conflicts with ( in derivation of ) This is intended just to move around the required steps and give them clearer labels . Please keep an eye out for things that might have accidentally been or dropped . 
 Interim 2022 - 06 - 02 : to review , then clear to merge 
 Currently , we only have explicit algorithm steps for validating an UpdatePath . We should have a similar level of concreteness for the process of creating an UpdatePath .
Paragraph (version A):
Compute the updated path secrets.
Paragraph (version A):
Identify a node in the resolution of the copath node for which
the recipient has a private key.
Paragraph (version A):
Derive path secrets for ancestors of that node using the
algorithm described above.
Paragraph (version A):
The recipient SHOULD verify that the received public keys agree
with the public keys derived from the new path_secret values.
Paragraph (version A):
Merge the updated path secrets into the tree.
Paragraph (version A):
Set the public key to the received public key.
Paragraph (version A):
Store the updated hash of the next node on the filtered
direct path (represented as a ParentNode struct), going from
root to leaf, so that each hash incorporates all the non-
blank nodes above it.  The root node always has a zero-
length hash for this value.
Paragraph (version A):
For nodes where a path secret was recovered in step 1 ("Compute
the updated path secrets"), compute and store the node's
updated private key.
Paragraph (version A):
The path secrets used to derive each updated node key pair.
Paragraph (version B):
Blank all nodes along the direct path of the sender's leaf.
Paragraph (version B):
Compute updated path secrets and public keys for the nodes on the
sender's filtered direct path.
Paragraph (version B):
For each node in the filtered direct path, replace the node's
public key with the "node_pub[n]" value derived from the
corresponding path secret "path_secret[n]".
Paragraph (version B):
Compute the new parent hashes for the nodes along the filtered
direct path and the sender's leaf node.
Paragraph (version B):
Update the leaf node for the sender.
Paragraph (version B):
Set the "leaf_node_source" to "commit".
Paragraph (version B):
Set the parent hash to the parent hash for the leaf.
Paragraph (version B):
Since the new leaf node effectively updates an existing leaf node in
the group, it MUST adhere to the same restrictions as LeafNodes used
in "Update" proposals (aside from "leaf_node_source").  The
application MAY specify other changes to the leaf node, e.g.,
providing a new signature key, updated capabilities, or different
extensions.
Paragraph (version B):
Compute the resolution of the node's child that is on the copath
of the sender (the child that is not in the direct path of the
sender).  Any new member (from an Add proposal) added in the same
Commit MUST be excluded from this resolution.
Paragraph (version B):
Set the public key to the public key in the UpdatePath.
Paragraph (version B):
Compute parent hashes for the nodes in the sender's filtered
direct path, and verify that the "parent_hash" field of the leaf
node matches the parent hash for the first node in its filtered
direct path.
Paragraph (version B):
Note that these hashes are computed from root to leaf, so that
each hash incorporates all the non-blank nodes above it.  The
root node always has a zero-length hash for its parent hash.
Paragraph (version B):
Identify a node in the resolution of the copath node for which the
recipient has a private key.
Paragraph (version B):
Derive path secrets for ancestors of that node in the sender's
filtered direct path using the algorithm described above.
Paragraph (version B):
Derive the node secrets and node key pairs from the path secrets.
Paragraph (version B):
Verify that the derived public keys are the same as the
corresponding public keys sent in the UpdatePath.
Paragraph (version B):
Store the derived private keys in the corresponding ratchet tree
nodes.
Paragraph (version B):
A recipient at node A would decrypt "E(pk(A), path_secret\[0\])" to
obtain "path_secret\[0\]", then use it to derive "path_secret[1]" and
the resulting node secrets and key pairs.  Thus A would have the
private keys to nodes X' and Y', in accordance with the tree
invariant.
Paragraph (version B):
Similarly, a recipient at node D would decrypt "E(pk(Z),
path_secret[1])" to obtain "path_secret[1]", then use it to derive
the node secret and and key pair for the node Y'.  As required to
maintain the tree invariant, node D does not receive the private key
for the node X', since X' is not an ancestor of D.
Paragraph (version B):
The path secrets and node secrets used to derive each updated node
key pair.
Paragraph (version A):
Generate path secrets for the parent nodes along the sender's
filtered direct path, as described in synchronizing-views-of-
the-tree.  Define "commit_secret" as the value
"path_secret[n+1]" derived from the last path secret value
("path_secret[n]") derived for the UpdatePath.
Paragraph (version A):
Update the new ratchet tree by setting the parent nodes on the
sender's filtered direct path based on the path secrets.
Compute parent hashes for these nodes.  Set the sender's leaf
node in the new tree to a new leaf node including the resulting
parent hash for its nearest ancestor.
Paragraph (version A):
The new leaf node MUST have "leaf_node_source" set to
"commit".
Paragraph (version A):
Since the new leaf node effectively updates an existing leaf
node in the group, it MUST adhere to the same restrictions
as LeafNodes used in "Update" proposals (aside from
"leaf_node_source").
Paragraph (version A):
The application MAY specify other changes to the leaf node,
e.g., providing a new signature key, updated capabilities,
or different extensions.
Paragraph (version B):
Update the sender's direct path in the ratchet tree as
described in synchronizing-views-of-the-tree.  Define
"commit_secret" as the value "path_secret[n+1]" derived from
the last path secret value ("path_secret[n]") derived for the
UpdatePath.
Paragraph (version A):
Create an UpdatePath that encrypts the path secrets for the
nodes along the sender's filtered direct path to the new
ratchet tree, using the provisional GroupContext as context.
Any new member (from an Add proposal) MUST be excluded from the
resolution during the computation of the UpdatePath.
Paragraph (version A):
Assign this UpdatePath to the "path" field in the Commit.
Paragraph (version B):
Encrypt the path secrets resulting from the tree update to the
group as described in synchronizing-views-of-the-tree, using
the provisional group context as the context for HPKE
encryption.
Paragraph (version B):
Create an UpdatePath containing the sender's new leaf node and
the new public keys and encrypted path secrets along the
sender's filtered direct path.  Assign this UpdatePath to the
"path" field in the Commit.
Paragraph (version A):
Compute parent hashes for the parent nodes in the UpdatePath
(relative to the new ratchet tree) and verify that the
"parent_hash" field of the leaf node matches the parent hash
for the first node its filtered direct path.
Paragraph (version B):
Merge the UpdatePath into the new ratchet tree as described in
synchronizing-views-of-the-tree.
Paragraph (version A):
Apply the UpdatePath to the tree, as described in
synchronizing-views-of-the-tree, using the provisional
GroupContext when decrypting the path secret and storing
"leaf_node" at the committer's leaf.
Paragraph (version B):
Decrypt the path secrets for UpdatePath as described in
synchronizing-views-of-the-tree, using the provisional
GroupContext as the context for HPKE decryption.