Draft: draft-ietf-mls-protocol

Commentary: This PR adds a way for the members of a group to indicate the credential types they support , and how to negotiate which credential types may be used in a group . 
 I discussed this offline with and we arrived at : We might need multiple credentials later ( as I suspect ) If we do that ( say in an extension ) , we will need to update this text We should capture the general theory that covers both single- and multiple - credential cases The proposed additions here just abstract the principle of universal compatibility ( which we need in a single - credential world ) to one of " at least something " compatibility ( which is more compatible with a multi - credential world).The types of credential that may be used in a group is restricted to what all I think this is too restrictive if we adopt PR . I think it is between the client and its AS if all the clients need to support every credential type used in the group . If you agree with the concept , I am happy to propose slight changes . I think this makes sense .
Paragraph (version A):
The "capabilities" field 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.  Extensions that
appear in the "extensions" field of a LeafNode MUST be included in
the "extensions" field of the "capabilities" field.
Paragraph (version B):
The "capabilities" field indicates what protocol versions,
ciphersuites, extensions, credential types, and non-default proposal
types are supported by a client.  Proposal and extension types
defined in this document are considered "default" and thus need not
be listed, while any credential types the application wishes to use
MUST be listed.  Extensions that appear in the "extensions" field of
a LeafNode MUST be included in the "extensions" field of the
"capabilities" field, and the credential type used in the LeafNode
MUST be included in the "credentials" field of the "capabilities"
field.
Paragraph (version A):
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 B):
Verify that the LeafNode is compatible with the group's
parameters.  If the GroupContext has a "required_capabilities"
extension, then the required extensions, proposals, and credential
types MUST be listed in the LeafNode's "capabilities" field.
Paragraph (version B):
Verify that the credential type is supported by all members of the
group, as specified by the "capabilities" field of each member's
LeafNode, and that the "capabilities" field of this LeafNode
indicates support for all the credential types currently in use by
other members.
Paragraph (version A):
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.capabilities" indicates what protocol versions,
ciphersuites, credential types, and non-default proposal/extension
types are supported by the client.  (Proposal and extension 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 A):
This extension lists the extensions and proposal types that must be
supported by all members of the group.  The "default" proposal and
extension types defined in this document are assumed to be
implemented by all clients, and need not be listed in
RequiredCapabilities in order to be safely used.
Paragraph (version B):
This extension lists the extensions, proposals, and credential types
that must be supported by all members of the group.  The "default"
proposal and extension types defined in this document are assumed to
be implemented by all clients, and need not be listed in
RequiredCapabilities in order to be safely used.
Paragraph (version B):
In order to ensure that MLS provides meaningful authentication it is
important that each member is able to authenticate some identity
information for each other member.  Identity information is encoded
in Credentials, so this property is assured by ensuring that members
use compatible credential types.
Paragraph (version B):
The types of credential that may be used in a group is restricted to
what all members of the group support, as specified by the
"capabilities" field of each LeafNode in the RatchetTree.  An
application can introduce new credential types by choosing an
unallocated identifier from the registry in mls-credential-types and
indicating support for the credential type in published LeafNodes,
whether in Update proposals to existing groups or KeyPackages that
are added to new groups.  Once all members in a group indicate
support for the credential type, members can start using LeafNodes
with the new credential.  Application may enforce that certain
credential types always remain supported by adding a
"required_capabilities" extension to the group's GroupContext, which
would prevent any member from being added to the group that doesn't
support them.