Draft: draft-ietf-mls-protocol

Commentary: Replaces This PR attempts to add precision to the credential validation requirements in the document , along the lines suggests in , in the spirit of what wrote up in and drawing inspiration from what RFC 6125 does in the context of TLS . It seems like this gives a clearer definition of ( a ) what the AS 's job is and ( b ) when it needs to be done . 
 While this is spread out throughout the document , it would be beneficial to spell out in which scenarios a Credential MUST be verified ( with the AS ): When fetching a KeyPackage to add a new member When discovering a KeyPackage in an AddProposal from another member When joining a new group ( verify all other members ' Credentials ) , both when receiving a Welcome message and when joining through an External Commit When a member updates its leaf ... anywhere else ? 
 Thanks for picking it up !
Paragraph (version A):
Each new credential that has not already been validated by the
application MUST be validated against the Authentication Service.
Applications SHOULD require that a client present the same set of
identifiers throughout its presence in the group, even if its
Credential is changed in a Commit or Update.  If an application
allows clients to change identifiers over time, then each time the
client presents a new credential, the application MUST verify that
the set of identifiers in the credential is acceptable to the
application for this client.
Paragraph (version B):
The application using MLS is responsible for specifying which
identifiers it finds acceptable for each member in a group.  In other
words, following the model that RFC6125 describes for TLS, the
application maintains a list of "reference identifiers" for the
members of a group, and the credentials provide "presented
identifiers".  A member of a group is authenticated by first
validating that the member's credential legitimately represents some
presented identifiers, and then ensuring that the reference
identifiers for the member are authenticated by those presented
identifiers.
Paragraph (version B):
The parts of the system that perform these functions are collectively
referred to as the Authentication Service (AS) I-D.ietf-mls-
architecture.  A member's credential is said to be _validated with
the AS_ when the AS verifies the credential's presented identifiers,
and verifies that those identifiers match the reference identifiers
for the member.
Paragraph (version B):
When a member receives a KeyPackage that it will use in an Add
proposal to add a new member to the group.
Paragraph (version B):
When a member receives an Add proposal adding a member to the
group.
Paragraph (version B):
When a member receives an Update proposal whose LeafNode has a new
credential for the member.
Paragraph (version B):
When a member receives a Commit with an UpdatePath whose LeafNode
has a new credential for the committer.
Paragraph (version B):
When an "external_senders" extension is added to the group, or an
existing "external_senders" extension is updated.
Paragraph (version B):
In cases where a member's credential is being replaced, such as
Update and Commit cases above, the AS MUST also verify that the set
of presented identifiers in the new credential is valid as a
successor to the set of presented identifiers in the old credential,
according to the application's policy.
Paragraph (version B):
Verify that the credential in the LeafNode is valid as described
in credential-validation.