Draft: draft-ietf-mls-protocol

Commentary: Following the pattern of , this PR introduces a new section describing how a list of proposals is applied to make a new RatchetTree and GroupContext . It also moves the validation section introduced in that PR forward so that the sections on validating and applying proposal lists are within the Proposals subsection . 
 One thing I 'm not sure about , would like feedback on : When should GroupContextExtensions be applied ? It seems like you could do it either at the front or the back . I put it at the front so that it could set context for the remaining proposals . For example , if the GroupContextExtensions introduces a extension , then the Adds would be evaluated against it . 
 Yes agreed , you sort of need to apply it first so that you can use the RequiredCapabilities to check the other proposals 
 Fwiw all that 's in this PR currently is moving the validation section 
 Thanks forgot to push . Latest commit should have all the changes . 
 ~Specify inputs and outputs for creation~ ~Inputs : Group state , proposals , wire format ( pt / ct)~ ~Outputs : New group state , MLSMessageContentAuth(Commit ) ,  ~Clarify that the “ Provisional ” GroupContext includes the extensions specified in any GroupContextExtensions proposal , if any~ Expand the rules on applying proposals to clearly address how each proposal type is processed Maybe pull into a separate subsection ? “ Applying Proposals ” after " External Proposals " In Commit processing , remove text on applying proposals and just refer to creation steps ( The ~strikethrough~ items above have been fixed by more recent PRs . Renaming for clearer focus . )
Paragraph (version B):
Proposal types defined in the future may make updates to the above
validation logic to incorporate considerations related to proposals
of the new type.
Paragraph (version B):
If there is a GroupContextExtensions proposal, replace the
"extensions" field of the GroupContext for the group with the
contents of the proposal.  The new "extensions" MUST be used for
evaluating other proposals in this list.  For example, if a
GroupContextExtensions proposal adds a "required_capabilities"
extension, then any Add proposals need to indicate support for
those capabilities.
Paragraph (version B):
Apply any Update proposals to the ratchet tree, in any order.
Paragraph (version B):
Apply any Remove proposals to the ratchet tree, in any order.
Paragraph (version B):
Apply any Add proposals to the ratchet tree, in the order they
appear in the list.
Paragraph (version B):
Look up the PSK secrets for any PreSharedKey proposals, in the
order they appear in the list.  These secrets are then used to
advance the key schedule later in Commit processing.
Paragraph (version B):
If there is an ExternalInit proposal, use it to derive the
"init_secret" for use later in Commit processing.
Paragraph (version B):
If there is a ReInit proposal, note its parameters for application
later in Commit processing.
Paragraph (version B):
Proposal types defined in the future MUST specify how the above steps
are to be adjusted to accommodate the application of proposals of the
new type.
Paragraph (version A):
PreSharedKey proposals are processed later when deriving the
"psk_secret" for the Key Schedule.
Paragraph (version A):
Regardless of how the client obtains the tree, the client MUST verify
that the root hash of the ratchet tree matches the "tree_hash" of the
GroupContext before using the tree for MLS operations.