Draft: draft-ietf-mls-protocol

Commentary: While landing , I noticed that there were some dangling references left over from the KeyPackage / LeafNode split , e.g. , to the " extension " or . This PR cleans those up .
Paragraph (version A):
Verify that the LeafNode is compatible with the group's
parameters.  The ciphersuite and protocol version of the
KeyPackage must match those in use in the group.  If the
GroupContext has a "required_capabilities" extension, then the
required extensions and proposals MUST be listed in the
KeyPackage's "capabilities" extension.
Paragraph (version B):
Verify that the LeafNode is compatible with the group's
parameters.  If the GroupContext has a "required_capabilities"
extension, then the required extensions and proposals MUST be
listed in the LeafNode's "capabilities" field.
Paragraph (version A):
Verify that the "membership" field has the appropriate contents
for the context in which the KeyPackage is being validated (as
defined in ratchet-tree-node-contents).
Paragraph (version B):
Verify that the "leaf_node_source" field has the appropriate value
for the context in which the LeafNode is being validated (as
defined in ratchet-tree-node-contents).
Paragraph (version A):
The "parent_hash" extension carries information to authenticate the
HPKE keys in the ratchet tree, as described below.
Paragraph (version A):
Consider a ratchet tree with a non-blank parent node P and children V
and S.  The parent hash of P changes whenever an "UpdatePath" object
is applied to the ratchet tree along a path from a leaf U traversing
node V (and hence also P).  The new "Parent Hash of P (with Co-Path
Child S)" is obtained by hashing P's "ParentHashInput" struct.
Paragraph (version B):
The "parent_hash" field in ratchet tree nodes carries information to
authenticate the information in the ratchet tree.  Parent hashes
chain together so that the signature on a leaf node, by covering the
leaf node's parent hash, indirectly includes information about the
structure of the tree at the time the leaf node was last updated.
Paragraph (version B):
Consider a ratchet tree with a non-blank parent node P and children V
and S.
Paragraph (version B):
The parent hash of P changes whenever an "UpdatePath" object is
applied to the ratchet tree along a path from a leaf U traversing
node V (and hence also P).  The new "Parent Hash of P (with Co-Path
Child S)" is obtained by hashing P's "ParentHashInput" struct.
Paragraph (version A):
To this end, when processing a Commit message clients MUST recompute
the expected value of "parent_hash" for the committer's new leaf and
verify that it matches the "parent_hash" value in the supplied
"leaf_key_package".  Moreover, when joining a group, new members MUST
authenticate each non-blank parent node P.  A parent node P is
authenticated by checking that there exists a child V of P and a node
U in the resolution of V such that V."parent_hash" is equal to the
Parent Hash of P with V's sibling as the co-path child.
Paragraph (version B):
If, on the other hand, V is the leaf U and its LeafNode has
"leaf_node_source" set to "commit", then the Parent Hash of P (with
V's sibling as co-path child) is stored in the "parent_hash" field.
This is true in particular of the LeafNode object sent in the
"leaf_node" field of an UpdatePath.  The signature of such a LeafNode
thus also attests to which keys the group member introduced into the
ratchet tree and to whom the corresponding secret keys were sent.
This helps prevent malicious insiders from constructing artificial
ratchet trees with a node V whose HPKE secret key is known to the
insider yet where the insider isn't assigned a leaf in the subtree
rooted at V.  Indeed, such a ratchet tree would violate the tree
invariant.
Paragraph (version B):
To this end, when processing a Commit message clients MUST recompute
the expected value of "parent_hash" for the committer's new leaf and
verify that it matches the "parent_hash" value in the supplied
"leaf_node".  Moreover, when joining a group, new members MUST
authenticate each non-blank parent node P.  A parent node P is
authenticated by checking that there exists a child V of P and a node
U in the resolution of V such that V."parent_hash" is equal to the
Parent Hash of P with V's sibling as the co-path child.
Paragraph (version B):
The "leaf_node_source" field of the LeafNode in a KeyPackage MUST be
set to "key_package".
Paragraph (version A):
Verify that the credential in the KeyPackage is valid according to
the authentication service and the client's local policy.  These
actions MUST be the same regardless of at what point in the
protocol the KeyPackage is being verified with the following
exception: If the KeyPackage is an update to another KeyPackage,
the authentication service MUST additionally validate that the set
of identities attested by the credential in the new KeyPackage is
acceptable relative to the identities attested by the old
credential.
Paragraph (version A):
Verify that the KeyPackage is compatible with the group's
parameters.  The ciphersuite and protocol version of the
KeyPackage must match those in use in the group.  If the
GroupContext has a "required_capabilities" extension, then the
required extensions and proposals MUST be listed in the
KeyPackage's "capabilities" extension.
Paragraph (version B):
Verify the LeafNode in the KeyPackage according to the process
defined in leaf-node-validation.
Paragraph (version B):
Verify that the ciphersuite and protocol version of the LeafNode
match those in use in the group.
Paragraph (version B):
Validate the KeyPackage as specified in keypackage-validation.
The "leaf_node_source" field in the LeafNode MUST be set to
"key_package".
Paragraph (version A):
Verify that the "public_key" value is different from the
corresponding field in the LeafNode being replaced.
Paragraph (version B):
Validate the LeafNode as specified in leaf-node-validation.  The
"leaf_node_source" field MUST be set to "update".
Paragraph (version B):
Verify that the "public_key" value in the LeafNode is different
from the corresponding field in the LeafNode being replaced.
Paragraph (version A):
If populating the "path" field: Create an UpdatePath using the
provisional ratchet tree and GroupContext.  Any new member (from
an add proposal) MUST be excluded from the resolution during the
computation of the UpdatePath.  The "leaf_key_package" for this
UpdatePath must have a "parent_hash" extension.  Note that the
LeafNode in the "UpdatePath" effectively updates an existing
LeafNode in the group and thus MUST adhere to the same
restrictions as LeafNodess used in "Update" proposals.
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 excluded from the resolution during the
computation of the UpdatePath.  The "leaf_node" for this
UpdatePath MUST have "leaf_node_source" set to "commit".  Note
that the LeafNode in the "UpdatePath" effectively updates an
existing LeafNode in the group and thus MUST adhere to the same
restrictions as LeafNodes used in "Update" proposals (aside from
"leaf_node_source").
Paragraph (version A):
Apply the UpdatePath to the tree, as described in
synchronizing-views-of-the-tree, and store "leaf_key_package"
at the Committer's leaf.
Paragraph (version B):
Validate the LeafNode as specified in leaf-node-validation.
The "leaf_node_source" field MUST be set to "commit".
Paragraph (version B):
Verify that the "public_key" value in the LeafNode is different
from the committer's current leaf node.
Paragraph (version B):
Apply the UpdatePath to the tree, as described in
synchronizing-views-of-the-tree, and store "leaf_node" at the
committer's leaf.
Paragraph (version A):
External Commits MUST be signed by the new member.  In particular,
the signature on the enclosing MLSPlaintext MUST verify using the
public key for the credential in the "leaf_key_package" of the
"path" field.
Paragraph (version B):
External Commits MUST be signed by the new member.  In particular,
the signature on the enclosing MLSPlaintext MUST verify using the
public key for the credential in the "leaf_node" of the "path"
field.