Draft: draft-ietf-mls-protocol

Commentary: This seems to be a layer of indirection that does n't add any value to implementation . 
 The Credentials section claims there is an epoch i d field in key packages . I do n't think that actually exists . My apologies if this is a duplicate issue . 
 Addressed in but may need to be pulled out depending on the fate of that PR 
 contains all of the Proposals that were previously sent within the same epoch . This seems unnecessary , since all members should have them anyway . The list of in the actual message should be enough for members to parse and validate a message . We should discuss if we can de - duplicate this , since the list of Proposals might be quite long . 
 The current definition of is as follows ; Maybe this issue is obsolete ? 
 Seems it is now obsolete indeed . 
 I do n't have a strong opinion on this question , but this change seems sensible to me . The use of LeafNodeRef requires either ( a ) a linear scan through the tree , which is time - expensive in large trees , or ( b ) keeping an index that maps LeafNodeRef values to indices , which is storage - intensive in large trees . IIRC , the change to LeafNodeRef was made in the context of work to make the tree description less tied to the array representation . In general , that is the right thing to do , and it 's good that we did it . But we still have leaf indices anyway , for . Since we still have the concept , we might as well use it where it makes sense . And it certainly seems to me like and make sense , since they are internal to the protocol . In case folks are worried about the application - facing API -- MLS stacks can certainly be more intelligent , e.g. , exposing or or . But they can do that regardless of this PR .
Paragraph (version A):
For a KeyPackageRef, the "value" input is the encoded KeyPackage, and
the ciphersuite specified in the KeyPackage determines the KDF used.
For a LeafNodeRef, the "value" input is the LeafNode object for the
leaf node in question.  For a ProposalRef, the "value" input is the
MLSMessageContentAuth carrying the proposal.  In the latter two
cases, the KDF is determined by the group's ciphersuite.
Paragraph (version B):
For a KeyPackageRef, the "value" input is the encoded KeyPackage, and
the ciphersuite specified in the KeyPackage determines the KDF used.
For a ProposalRef, the "value" input is the MLSMessageContentAuth
carrying the proposal.  In the latter two cases, the KDF is
determined by the group's ciphersuite.
Paragraph (version A):
The Credentials presented by the clients in a group authenticate
application-level identifiers for the clients.  These identifiers may
not uniquely identify clients.  For example, if a user has multiple
devices that are all present in an MLS group, then those devices'
clients could all present the user's application-layer identifiers.
Paragraph (version A):
Internally to the protocol, group members are uniquely identified by
their leaves, expressed as LeafNodeRef objects.  These identifiers
are unstable: They change whenever the member sends a Commit, or
whenever an Update proposal from the member is committed.
Paragraph (version A):
The application may also provide application-specific unique
identifiers in the "extensions" field of KeyPackage or LeafNode
objects.
Paragraph (version B):
Internally to the protocol, group members are uniquely identified by
their leaf index.  However, a leaf index is only valid for referring
to members in a given epoch.  The same leaf index may represent a
different member, or no member at all, in a subsequent epoch.
Paragraph (version B):
The Credentials presented by the clients in a group authenticate
application-level identifiers for the clients.  However, these
identifiers may not uniquely identify clients.  For example, if a
user has multiple devices that are all present in an MLS group, then
those devices' clients could all present the user's application-layer
identifiers.
Paragraph (version B):
If needed, applications may add application-specific unique
identifiers to the "extensions" field of KeyPackage or LeafNode
objects.
Paragraph (version A):
"external": The signature key contained in the Credential at the
index indicated by the "sender_index" in the "external_senders"
group context extension (see Section external-senders-extension).
In this case, the "content_type" of the message MUST NOT be
"commit", since only members of the group or new joiners can send
Commit messages.
Paragraph (version B):
"member": The signature key contained in the Credential at the
index indicated by "leaf_index" in the ratchet tree.
Paragraph (version B):
"external": The signature key contained in the Credential at the
index indicated by "sender_index" in the "external_senders" group
context extension (see Section external-senders-extension).  In
this case, the "content_type" of the message MUST NOT be "commit",
since only members of the group or new joiners can send Commit
messages.
Paragraph (version A):
MLSSenderData.sender is assumed to be a "member" sender type.  When
constructing an MLSSenderData from a Sender object, the sender MUST
verify Sender.sender_type is "member" and use Sender.sender for
MLSSenderData.sender.
Paragraph (version B):
When constructing an MLSSenderData from a Sender object, the sender
MUST verify Sender.sender_type is "member" and use Sender.leaf_index
for MLSSenderData.leaf_index.
Paragraph (version A):
When parsing a SenderData struct as part of message decryption, the
recipient MUST verify that the LeafNodeRef indicated in the "sender"
field identifies a member of the group.
Paragraph (version B):
When parsing a SenderData struct as part of message decryption, the
recipient MUST verify that the leaf index indicated in the
"leaf_index" field identifies a non-blank node.
Paragraph (version A):
A Remove proposal requests that the member with LeafNodeRef "removed"
be removed from the group.
Paragraph (version B):
A Remove proposal requests that the member with the leaf index
"removed" be removed from the group.
Paragraph (version A):
Verify the signature on the GroupInfo object.  The signature input
comprises all of the fields in the GroupInfo object except the
signature field.  The public key and algorithm are taken from the
credential in the leaf node of the member with LeafNodeRef
"signer".  If there is no matching leaf node, or if signature
verification fails, return an error.
Paragraph (version B):
Verify the signature on the GroupInfo object.  The signature input
comprises all of the fields in the GroupInfo object except the
signature field.  The public key and algorithm are taken from the
credential in the leaf node of the ratchet tree with leaf index
"signer".  If the node is blank or if signature verification
fails, return an error.
Paragraph (version A):
If the "path_secret" value is set in the GroupSecrets object:
Identify the lowest common ancestor of the leaf node "my_leaf"
and of the node of the member with LeafNodeRef
"GroupInfo.signer".  Set the private key for this node to the
private key derived from the "path_secret".
Paragraph (version B):
If the "path_secret" value is set in the GroupSecrets object:
Identify the lowest common ancestor of the leaf node "my_leaf"
and of the node of the member with leaf index
"GroupInfo.signer".  Set the private key for this node to the
private key derived from the "path_secret".