Draft: draft-ietf-mls-protocol

Commentary: This PR picks up changes from clarifying and cleaning up a few issues around LeafNode . 
 A big improvement in readability and correctness .
Paragraph (version A):
The "public_key" field conains an HPKE public key whose private key
is held only by the member occupying this leaf.  The "credential"
contains authentication information for this member, as described in
credentials.
Paragraph (version B):
The "public_key" field conains an HPKE public key whose private key
is held only by the member occupying this leaf (or in the case of a
LeafNode in a KeyPackage object, the issuer of the KeyPackage).  The
"credential" contains authentication information for this member, as
described in credentials.
Paragraph (version A):
The "leaf_node_source" field indicates how this LeafNode came to be
added to the tree.
Paragraph (version B):
The "leaf_node_source" field indicates how this LeafNode came to be
added to the tree.  This signal tells other members of the group
whether the leaf node is required to have a "lifetime" or
"parent_hash", and whether the "group_id" is added as context to the
signature.  Whether these fields can be computed by the client
represented by the LeafNode depends on when the LeafNode was created.
For example, a KeyPackage is created before the client knows which
group it will be used with, so its signature can't bind to a
"group_id".
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 B):
Verify that the credential in the LeafNode 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 LeafNode is being verified with the following
exception: If the LeafNode is an update to another LeafNode, the
authentication service MUST additionally validate that the set of
identities attested by the credential in the new LeafNode is
acceptable relative to the identities attested by the old
credential.
Paragraph (version A):
When validating a downloaded KeyPackage, the current time MUST
be within the "lifetime" range.  A KeyPackage that is expired
or not yet valid MUST NOT be sent in an Add proposal.
Paragraph (version B):
When validating a LeafNode in a KeyPackage before sending an
Add proposal, the current time MUST be within the "lifetime"
range.  A KeyPackage containing a LeafNode that is expired or
not yet valid MUST NOT be sent in an Add proposal.
Paragraph (version B):
Verify that the extensions in the leaf node are supported.  The ID
for each extension in the "extensions" field MUST be listed in the
field "capabilities.extensions" of the LeafNode.
Paragraph (version A):
The value for "init_key" MUST be a public key for the asymmetric
encryption scheme defined by cipher_suite, and it MUST be unique
among the set of KeyPackages created by this client.  Likewise, the
"leaf_node" field MUST be valid for the ciphersuite, including both
the "hpke_key" and "credential" fields.  The whole structure is
signed using the client's signature key.  A KeyPackage object with an
invalid signature field MUST be considered malformed.
Paragraph (version B):
The value for "init_key" MUST be a public key for the asymmetric
encryption scheme defined by "cipher_suite", and it MUST be unique
among the set of KeyPackages created by this client.  Likewise, the
"leaf_node" field MUST be valid for the ciphersuite, including both
the "public_key" and "credential" fields.  The whole structure is
signed using the client's signature key.  A KeyPackage object with an
invalid signature field MUST be considered malformed.
Paragraph (version A):
The "capabilities" field in the "leaf_node" allows MLS session
establishment to be safe from downgrade attacks on the parameters
described (as discussed in group-creation), while still only
advertising one version / ciphersuite per KeyPackage.
Paragraph (version A):
The "leaf_node_source" field of the LeafNode in a KeyPackage MUST be
set to "key_package".
Paragraph (version B):
The field "leaf_node.capabilities" indicates what protocol versions,
ciphersuites, protocol extensions, and non-default proposal types are
supported by the client.  (Proposal types defined in this document
are considered "default" and not listed.)  This information allows
MLS session establishment to be safe from downgrade attacks on the
parameters described (as discussed in group-creation), while still
only advertising one version / ciphersuite per KeyPackage.
Paragraph (version B):
The field "leaf_node.leaf_node_source" of the LeafNode in a
KeyPackage MUST be set to "key_package".
Paragraph (version B):
Extension included in the "extensions" or "leaf_node.extensions"
fields MUST be included in the "leaf_node.capabilities" field.
Paragraph (version A):
Verify the LeafNode in the KeyPackage according to the process
defined in leaf-node-validation.
Paragraph (version A):
Verify that the ciphersuite and protocol version of the LeafNode
match those in use in the group.
Paragraph (version A):
The "capabilities" extension indicates what protocol versions,
ciphersuites, protocol extensions, and non-default proposal types are
supported by a client.  Proposal types defined in this document are
considered "default" and thus need not be listed.
Paragraph (version A):
This extension MUST be always present in a KeyPackage.  Extensions
that appear in the "extensions" field of a KeyPackage MUST be
included in the "extensions" field of the "capabilities" extension.
Paragraph (version A):
The "lifetime" extension represents the times between which clients
will consider a KeyPackage valid.  This time is represented as an
absolute time, measured in seconds since the Unix epoch
(1970-01-01T00:00:00Z).  A client MUST NOT use the data in a
KeyPackage for any processing before the "not_before" date, or after
the "not_after" date.
Paragraph (version A):
Applications MUST define a maximum total lifetime that is acceptable
for a KeyPackage, and reject any KeyPackage where the total lifetime
is longer than this duration.
Paragraph (version A):
This extension MUST always be present in a KeyPackage.
Paragraph (version B):
Verify that the ciphersuite and protocol version of the KeyPackage
match those in use in the group.
Paragraph (version B):
Verify the "leaf_node" field of the KeyPackage according to the
process defined in leaf-node-validation.
Paragraph (version B):
Verify that the signature on the KeyPackage is valid using the
public key in "leaf_node.credential".