Draft: draft-ietf-mls-protocol

Commentary: This PR refactors the two sections on Group Joining ( via Welcome and via External Init ) by changing the struct that can be used for both cases . The used in the course of an External Init is as an optional field . This PR also : removes the redundant ProtocolVersion in the GroupInfo adds a GroupInfoTBS struct to follow the convention of specifying a TBS struct for signed messages implicitly , the and is now used for external inits instead of the , which was not sufficient to create a valid commit 
 Thanks for the suggestions ! I agree that it 's a bit nicer to have an extension rather then an optional field . 
 I agree it 's good to align and ! 
 Hello , In the , my name is correctly written with the " é " accent , however when it is compiled , the accent is dropped , e.g. or . It looks like this letter is the only non - ascii character in the whole document , is this the expected behavior when compiling an RFC , or is it an issue in that I should track ? Thanks ! 
 This is a tooling issue . Currently , the only way to include non - ASCII characters in an RFC is for them to be wrapped in a element in the XML . Unfortunately , that ca n't be triggered from MD right now . One this is approved , the RFC editor can massage the XML to add the required wrapping . This was done in RFC 9147 ( , , , search for " Vyncke " ) . Flagging this for handling in AUTH48 , which is the step in the process where we work with the RFC editor on things like this . 
 Thanks for flagging this for AUTH48 . There is zero chance I would have remember this . 
 What 's wrong with the current kramdown - rfc support ? Please open an issue at ! 
 mnot wrote this up for your convenience ...
Paragraph (version A):
A _PublicGroupState_ object provides potential new group members
with information about the state of a group at an epoch, to allow
a new member to add themselves to the group.
Paragraph (version A):
KeyPackage, Welcome, and PublicGroupState messages are used to
initiate a group or introduce new members, so they are exchanged
between group members and clients not yet in the group.
Paragraph (version B):
KeyPackage and Welcome messages are used to initiate a group or
introduce new members, so they are exchanged between group members
and clients not yet in the group.
Paragraph (version A):
Within MLS, a KeyPackage is identified by its hash (see, e.g.,
welcoming-new-members).  The "external_key_id" extension allows
applications to add an explicit, application-defined identifier to a
KeyPackage.
Paragraph (version B):
Within MLS, a KeyPackage is identified by its hash (see, e.g.,
joining-via-welcome-message).  The "external_key_id" extension allows
applications to add an explicit, application-defined identifier to a
KeyPackage.
Paragraph (version A):
The public key "external_pub" can be published as part of the
"PublicGroupState" struct in order to allow non-members to join the
group using an external commit.
Paragraph (version B):
The public key "external_pub" can be published as part of the
GroupInfo struct in order to allow non-members to join the group
using an external commit.
Paragraph (version A):
In this process, the joiner sends a new "init_secret" value to the
group using the HPKE export method.  The joiner then uses that
"init_secret" with information provided in the PublicGroupState and
an external Commit to initialize their copy of the key schedule for
the new epoch.
Paragraph (version A):
In both cases, the "info" input to HPKE is set to the
PublicGroupState for the previous epoch, encoded using the TLS
serialization.
Paragraph (version B):
In this process, the joiner sends a new "init_secret" value to the
group using the HPKE export method.  The joiner then uses that
"init_secret" with information provided in the GroupInfo and an
external Commit to initialize their copy of the key schedule for the
new epoch.
Paragraph (version B):
In both cases, the "info" input to HPKE is set to the GroupInfo for
the previous epoch, encoded using the TLS serialization.
Paragraph (version A):
A group is always created with a single member, the "creator".  The
other members are added when the creator effectively sends itself an
Add proposal and commits it, then sends the corresponding Welcome
message to the new participants.  These processes are described in
detail in add, commit, and welcoming-new-members.
Paragraph (version B):
A group is always created with a single member, the "creator".  The
other members are added when the creator effectively sends itself an
Add proposal and commits it, then sends the corresponding Welcome
message to the new participants.  These processes are described in
detail in add, commit, and joining-via-welcome-message.
Paragraph (version A):
The recipient of a Welcome message processes it as described in
welcoming-new-members.
Paragraph (version B):
The recipient of a Welcome message processes it as described in
joining-via-welcome-message.
Paragraph (version B):
New members can join the group in two ways.  Either by being added by
a group member, or by adding themselves through an external Commit.
In both cases, the new members need information to bootstrap their
local group state.
Paragraph (version A):
This signature authenticates the HPKE public key, so that the joiner
knows that the public key was provided by a member of the group.  The
fields that are not signed are included in the key schedule via the
GroupContext object.  If the joiner is provided an inaccurate data
for these fields, then its external Commit will have an incorrect
"confirmation_tag" and thus be rejected.
Paragraph (version A):
The information in a PublicGroupState is not deemed public in
general, but applications can choose to make it available to new
members in order to allow External Commits.
Paragraph (version B):
In other words, to join a group via an External Commit, a new member
needs a GroupInfo with an "ExternalPub" extension present in the
"other_extensions".
Paragraph (version B):
Thus, a member of the group can enable new clients to join by making
a GroupInfo object available to them.  Note that because a GroupInfo
object is specific to an epoch, it will need to be updated as the
group advances.  In particular, each GroupInfo object can be used for
one external join, since that external join will cause the epoch to
change.
Paragraph (version B):
The "signature" on the GroupInfo struct authenticates the HPKE public
key, so that the joiner knows that the public key was provided by a
member of the group.  The fields that are not signed are included in
the key schedule via the GroupContext object.  If the joiner is
provided an inaccurate data for these fields, then its external
Commit will have an incorrect "confirmation_tag" and thus be
rejected.
Paragraph (version B):
The information in a GroupInfo is not deemed public in general, but
applications can choose to make it available to new members in order
to allow External Commits.
Paragraph (version A):
In other words, an application can use GroupContext extensions to
ensure that all members of the group agree on a set of parameters.
Clients indicate their support for parameters in KeyPackage
extensions.  New members of a group are informed of the group's
GroupContext extensions via the "group_context_extensions" field in
the GroupInfo or PublicGroupState object.  The "other_extensions"
field in a GroupInfo object can be used to provide additional
parameters to new joiners that are used to join the group.
Paragraph (version B):
In other words, an application can use GroupContext extensions to
ensure that all members of the group agree on a set of parameters.
Clients indicate their support for parameters in KeyPackage
extensions.  New members of a group are informed of the group's
GroupContext extensions via the "group_context_extensions" field in
the GroupInfo object.  The "other_extensions" field in a GroupInfo
object can be used to provide additional parameters to new joiners
that are used to join the group.