Draft: draft-ietf-mls-protocol

Commentary: Overall , this seems OK . Just using " InitKey " would be clear and less wordy . 
 I tried this and that led people to confuse and 
 Here 's the Weekly Digest for : - - Last week 5 issues were created . Of these , 1 issues have been closed and 4 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : heart : , by - - Last week , 9 pull requests were created , updated or merged . Last week , 3 pull requests were opened . : greenheart : , by : greenheart : , by : greenheart : , by Last week , 1 pull request was updated . : yellowheart : , by Last week , 5 pull requests were merged . : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by - - Last week there were 8 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there were 2 contributors . : bustinsilhouette : : bustinsilhouette : - - Last week there was 1 stargazer . : star : You are the star ! : star2 : - - Last week there were no releases . - - That 's all for last week , please < kbd : eyes : Watch</kbdand < kbd : star : Star</kbdthe repository to receive next weekly updates . : smiley : You can also . 
 These keys are  one - time use keys , so " UserInitKey " seems like a strange name . 
 I 'm fine with ClientInitKey , as long as a client is not only a physical endpoint . Changes in the architecture doc should make this clear soon .
Paragraph (version A):
A short-lived HPKE key pair used to introduce a new client to a
group.  Initialization keys are published for each client
(UserInitKey).
Paragraph (version B):
A short-lived HPKE key pair used to introduce a new client to a
group.  Initialization keys are published for each client
(ClientInitKey).
Paragraph (version A):
Before the initialization of a group, clients publish UserInitKey
objects to a directory provided to the Messaging Service.
Paragraph (version A):
When a client A wants to establish a group with B and C, it first
downloads UserInitKeys for B and C.  It then initializes a group
state containing only itself and uses the UserInitKeys to compute
Welcome and Add messages to add B and C, in a sequence chosen by A.
The Welcome messages are sent directly to the new members (there is
no need to send them to the group).  The Add messages are broadcasted
to the group, and processed in sequence by B and C.  Messages
received before a client has joined the group are ignored.  Only
after A has received its Add messages back from the server does it
update its state to reflect their addition.
Paragraph (version B):
Before the initialization of a group, clients publish ClientInitKey
objects to a directory provided to the Messaging Service.
Paragraph (version B):
When a client A wants to establish a group with B and C, it first
downloads ClientInitKeys for B and C.  It then initializes a group
state containing only itself and uses the ClientInitKeys to compute
Welcome and Add messages to add B and C, in a sequence chosen by A.
The Welcome messages are sent directly to the new members (there is
no need to send them to the group).  The Add messages are broadcasted
to the group, and processed in sequence by B and C.  Messages
received before a client has joined the group are ignored.  Only
after A has received its Add messages back from the server does it
update its state to reflect their addition.
Paragraph (version A):
Subsequent additions of group members proceed in the same way.  Any
member of the group can download an UserInitKey for a new client and
broadcast an Add message that the current group can use to update
their state and the new client can use to initialize its state.
Paragraph (version B):
Subsequent additions of group members proceed in the same way.  Any
member of the group can download an ClientInitKey for a new client
and broadcast an Add message that the current group can use to update
their state and the new client can use to initialize its state.
Paragraph (version A):
In order to facilitate asynchronous addition of clients to a group,
it is possible to pre-publish initialization keys that provide some
public information about a user.  UserInitKey messages provide
information about a client that any existing member can use to add
this client to the group asynchronously.
Paragraph (version A):
A UserInitKey object specifies what ciphersuites a client supports,
as well as providing public keys that the client can use for key
derivation and signing.  The client's identity key is intended to be
stable throughout the lifetime of the group; there is no mechanism to
change it.  Init keys are intended to be used a very limited number
of times, potentially once. (see init-key-reuse).  UserInitKeys also
contain an identifier chosen by the client, which the client MUST
assure uniquely identifies a given UserInitKey object among the set
of UserInitKeys created by this client.
Paragraph (version B):
In order to facilitate asynchronous addition of clients to a group,
it is possible to pre-publish initialization keys that provide some
public information about a user.  ClientInitKey messages provide
information about a client that any existing member can use to add
this client to the group asynchronously.
Paragraph (version B):
A ClientInitKey object specifies what ciphersuites a client supports,
as well as providing public keys that the client can use for key
derivation and signing.  The client's identity key is intended to be
stable throughout the lifetime of the group; there is no mechanism to
change it.  Init keys are intended to be used a very limited number
of times, potentially once. (see init-key-reuse).  ClientInitKeys
also contain an identifier chosen by the client, which the client
MUST assure uniquely identifies a given ClientInitKey object among
the set of ClientInitKeys created by this client.
Paragraph (version A):
The whole structure is signed using the client's identity key.  A
UserInitKey object with an invalid signature field MUST be considered
malformed.  The input to the signature computation comprises all of
the fields except for the signature field.
Paragraph (version B):
The whole structure is signed using the client's identity key.  A
ClientInitKey object with an invalid signature field MUST be
considered malformed.  The input to the signature computation
comprises all of the fields except for the signature field.
Paragraph (version A):
The Welcome message contains the information that the new member
needs to initialize a GroupContext object that can be updated to the
current state using the Add message.  This information is encrypted
for the new member using HPKE.  The recipient key pair for the HPKE
encryption is the one included in the indicated UserInitKey,
corresponding to the indicated ciphersuite.
Paragraph (version B):
The Welcome message contains the information that the new member
needs to initialize a GroupContext object that can be updated to the
current state using the Add message.  This information is encrypted
for the new member using HPKE.  The recipient key pair for the HPKE
encryption is the one included in the indicated ClientInitKey,
corresponding to the indicated ciphersuite.
Paragraph (version A):
A group member generates this message by requesting a UserInitKey
from the directory for the user to be added, and encoding it into an
Add message.
Paragraph (version B):
A group member generates this message by requesting a ClientInitKey
from the directory for the user to be added, and encoding it into an
Add message.