Draft: draft-ietf-mls-protocol

Commentary: add the missing field to the sections for the sender and receiver seem to have gotten out of sync . I tried to sync them up ( but let me know if I messed something up ) fix a typo 
 I 've tried to align with the current mlspp code for how to process commits . If the current mlspp code is incorrect , or if I 'm reading it incorrectly , I 'm more than happy to fix my changes to reflect the correct behaviour . 
 took action item to review editorial changes . 
 I think I 've addressed all the comments . I also realized that the calculation of the new GroupContext was in the wrong spot ( it has to be done after the MLSPlaintext is created ( sans confirmation_tag ) , and then the confirmed transcript hash is created , then the new GroupContext , then the secrets , then the confirmation tag -- that 's what mlspp does AFAICT ) , so I 've fixed that up as well . 
 I think if you 're OK with this , we 're clear to merge . 
 As discussed at interim . review . If good , then merge . 
 Ready to be merged from my side .
Paragraph (version B):
The "parent_hash" extension carries information to authenticate the
structure of the tree, as described below.
Paragraph (version A):
If populating the "path" field: Create an UpdatePath using the new
tree.  Any new member (from an add proposal) MUST be exluded from
the resolution during the computation of the UpdatePath.  The
GroupContext for this operation uses the "group_id", "epoch",
"tree_hash", and "confirmed_transcript_hash" values in the initial
GroupContext object.  The "leaf_key_package" for this UpdatePath
must have a "parent_hash" extension.
Paragraph (version A):
Apply the UpdatePath to the tree, as described in
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.
Paragraph (version B):
If populating the "path" field: Create an UpdatePath using the
provisional ratchet tree and GroupContext.  Any new member (from
an add proposal) MUST be exluded from the resolution during the
computation of the UpdatePath.  The "leaf_key_package" for this
UpdatePath must have a "parent_hash" extension.
Paragraph (version B):
If not populating the "path" field: Set the "path" field in the
Commit to the null optional.  Define "commit_secret" as the all-
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.
Paragraph (version A):
Construct an MLSPlaintext object containing the Commit object.
Sign the MLSPlaintext using the current epoch's GroupContext as
context.  Use the signature, the "commit_secret" and the
"psk_secret" to advance the key schedule and compute the
"confirmation_tag" value in the MLSPlaintext.
Paragraph (version B):
Construct an MLSPlaintext object containing the Commit object.
Sign the MLSPlaintext using the old GroupContext as context.
Paragraph (version B):
Use the MLSPlaintext to update the confirmed transcript hash
and generate the new GroupContext.
Paragraph (version B):
Use the "init_secret" from the previous epoch, the
"commit_secret" and the "psk_secret" as defined in the previous
steps, and the new GroupContext to compute the new
"joiner_secret", "welcome_secret", "epoch_secret", and derived
secrets for the new epoch.
Paragraph (version B):
Use the "confirmation_key" for the new epoch to compute the
"confirmation_tag" value, and the "membership_key" for the old
epoch to compute the "membership_tag" value in the
MLSPlaintext.
Paragraph (version B):
Calculate the interim transcript hash using the new confirmed
transcript hash and the "confirmation_tag" from the
MLSPlaintext.
Paragraph (version B):
Update the confirmed and interim transcript hashes using the new
Commit, and generate the new GroupContext.
Paragraph (version A):
Use the "commit_secret", the "psk_secret", the provisional
GroupContext, and the init secret from the previous epoch to
compute the epoch secret and derived secrets for the new epoch.
Paragraph (version B):
Use the "init_secret" from the previous epoch, the "commit_secret"
and the "psk_secret" as defined in the previous steps, and the new
GroupContext to compute the new "joiner_secret", "welcome_secret",
"epoch_secret", and derived secrets for the new epoch.
Paragraph (version B):
If the above checks are successful, consider the new GroupContext
object as the current state of the group.
Paragraph (version B):
Identify a leaf in the "tree" array (any even-numbered node) whose
"key_package" field is identical to the KeyPackage.  If no such
field exists, return an error.  Let "index" represent the index of
this node among the leaves in the tree, namely the index of the
node in the "tree" array divided by two.
Paragraph (version B):
The second form of authentication is that group members can verify a
message originated from a particular member of the group.  This is
guaranteed by a digital signature on each message from the sender's
signature key.