Draft: draft-ietf-mls-protocol

Commentary: Action item from Singapore : it seems better to specify directly in the message if we have an external sender instead of using reserved ranges . 
 Here 's the Weekly Digest for : - - Last week 3 issues were created . Of these , 0 issues have been closed and 3 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : speaker : , by It received 1 comments . - - Last week , 7 pull requests were created , updated or merged . Last week , 2 pull requests were opened . : greenheart : , by : greenheart : , by Last week , 4 pull requests were updated . : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by Last week , 1 pull request was merged . : purpleheart : , by - - Last week there were 3 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there were 2 contributors . : bustinsilhouette : : bustinsilhouette : - - Last week there were 2 stagazers . : star : : star : You all are the stars ! : 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 . 
 Here 's the Weekly Digest for : - - Last week 4 issues were created . Of these , 0 issues have been closed and 4 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by - - Last week , 14 pull requests were created , updated or merged . Last week , 8 pull requests were updated . : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by Last week , 6 pull requests were merged . : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by - - Last week there were 10 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there were 3 contributors . : bustinsilhouette : : bustinsilhouette : : bustinsilhouette : - - Last week there were no stargazers . - - 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 .
Paragraph (version A):
The group identifier, epoch, content_type and authenticated data
fields are copied from the MLSPlaintext object directly.  The content
encryption process populates the ciphertext field of the
MLSCiphertext object.  The metadata encryption step populates the
encrypted_sender_data field.
Paragraph (version A):
Decryption follows the same step in reverse: Decrypt the metadata,
then the message and verify the content signature.
Paragraph (version B):
External sender types are sent as MLSPlaintext, see external-
proposals for their use.
Paragraph (version B):
Decryption is done by decrypting the metadata, then the message, and
then verifying the content signature.
Paragraph (version B):
The following sections describe the encryption and signing processes
in detail.
Paragraph (version B):
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 A):
Add and Remove proposals can be constructed and sent to the group by
a party that is outside the group.  For example, a Delivery Service
might propose to remove a member of a group has been inactive for a
long time, or propose adding a newly-hired staff member to a group
representing a real-world team.  Proposals originating outside the
group are identified by having a "sender" value in the range
0xFFFFFF00 - 0xFFFFFFFF.
Paragraph (version A):
The specific value 0xFFFFFFFF is reserved for clients proposing that
they themselves be added.  Proposals with types other than Add MUST
NOT be sent with this sender index.  In such cases, the MLSPlaintext
MUST be signed with the private key corresponding to the
ClientInitKey in the Add message.  Recipients MUST verify that the
MLSPlaintext carrying the Proposal message is validly signed with
this key.
Paragraph (version A):
The remaining values 0xFFFFFF00 - 0xFFFFFFFE are reserved for signer
that are pre-provisioned to the clients within a group.  If proposals
with these sender IDs are to be accepted within a group, the members
of the group MUST be provisioned by the application with a mapping
between sender indices in this range and authorized signing keys.  To
ensure consistent handling of external proposals, the application
MUST ensure that the members of a group have the same mapping and
apply the same policies to external proposals.
Paragraph (version B):
Add and Remove proposals can be constructed and sent to the group by
a party that is outside the group.  For example, a Delivery Service
might propose to remove a member of a group has been inactive for a
long time, or propose adding a newly-hired staff member to a group
representing a real-world team.  Proposals originating outside the
group are identified by an "preconfigured" or "new_member" SenderType
in MLSPlaintext.
Paragraph (version B):
The "new_member" SenderType is used for clients proposing that they
themselves be added.  For this ID type the sender value MUST be zero.
Proposals with types other than Add MUST NOT be sent with this sender
type.  In such cases, the MLSPlaintext MUST be signed with the
private key corresponding to the ClientInitKey in the Add message.
Recipients MUST verify that the MLSPlaintext carrying the Proposal
message is validly signed with this key.
Paragraph (version B):
The "preconfigured" SenderType is reserved for signers that are pre-
provisioned to the clients within a group.  If proposals with these
sender IDs are to be accepted within a group, the members of the
group MUST be provisioned by the application with a mapping between
these IDs and authorized signing keys.  To ensure consistent handling
of external proposals, the application MUST ensure that the members
of a group have the same mapping and apply the same policies to
external proposals.