Draft: draft-ietf-mls-protocol

Commentary: and I have completed interop testing that covers all of the functionality in the spec . We found a couple of places where there were ambiguities in the spec that led to different implementation decisions , and in the process of resolving those , found a couple of errors / omissions in drarft-19 . The current PSK proposal validation forbids with other than . The branch and reinit sections call for the creation of PSK proposals with types and . Given the text in the PSK section , these proposals would be invalid . This PR explicitly allows and in the specific context of those operations . ( This is a little pro - forma , since the PSK proposals are only seen by the committer . But it seems good to allow the committer to have consistent PSK proposal validation logic . ) The text says that Add , Remove , and ReInit proposals can be sent by external senders , but is silent about other proposal types . This PR explicitly indicates which proposal types may be originated by external senders , and adds an IANA registry column to track . GREASE values for proposal types , credential types , and extension types are defined for use in Capabilities , but nothing currently forbids their use elsewhere . This PR forbids their use in actual  or Credential objects , and in GroupContext extensions . The field of the Proposal object was inconsistently referred to as both and . This PR changes it to be everywhere . 
 Merge when ready .
Paragraph (version A):
"external": The signature key at the index indicated by
"sender_index" in the "external_senders" group context extension
(see external-senders-extension).  The "content_type" of the
message MUST be "proposal".
Paragraph (version B):
"external": The signature key at the index indicated by
"sender_index" in the "external_senders" group context extension
(see external-senders-extension).  The "content_type" of the
message MUST be "proposal" and the "proposal_type" MUST be a value
that is allowed for external senders.
Paragraph (version A):
The "psktype" in the PreSharedKeyID struct is set to "resumption"
and the "usage" is "reinit" or "branch".
Paragraph (version B):
The PreSharedKey proposal is not being processed as part of a
reinitialization of the group (see reinitialization), and the
PreSharedKeyID has "psktype" set to "resumption" and "usage" set
to "reinit".
Paragraph (version B):
The PreSharedKey proposal is not being processed as part of a
subgroup branching operation (see subgroup-branching), and the
PreSharedKeyID has "psktype" set to "resumption" and "usage" set
to "branch".
Paragraph (version A):
Note that once the GroupContext is updated, its inclusion in the
confirmation_tag by way of the key schedule will confirm that all
members of the group agree on the extensions in use.
Paragraph (version A):
Add and Remove proposals can be constructed and sent to the group by
a party that is outside the group in two cases.  One case, indicated
by an "external" SenderType is useful in cases where, for example, an
automated service might propose to remove a member of a group who has
been inactive for a long time, or propose adding a newly-hired staff
member to a group representing a real-world team.
Paragraph (version A):
ReInit proposals can also be sent to the group by an "external"
sender, for example to enforce a changed policy regarding MLS version
or ciphersuite.
Paragraph (version B):
Note that once the GroupContext is updated, its inclusion in the
"confirmation_tag" by way of the key schedule will confirm that all
members of the group agree on the extensions in use.
Paragraph (version B):
Proposals can be constructed and sent to the group by a party that is
outside the group in two cases.  One case, indicated by an "external"
SenderType is useful in cases where, for example, an automated
service might propose to remove a member of a group who has been
inactive for a long time, or propose adding a newly-hired staff
member to a group representing a real-world team.  An "external"
sender might send a ReInit proposal, to enforce a changed policy
regarding MLS version or ciphersuite.
Paragraph (version B):
Messages from "external" senders containing proposal types other than
the above MUST be rejected as malformed.  New proposal types defined
in the future MUST define whether they may be sent by "external"
senders.  A column is defined in the relevant IANA registry (mls-
proposal-types) to reflect this property.
Paragraph (version A):
extensibility failures.  GREASE values MUST be handled using normal
logic for processing unsupported values.  When comparing lists of
capabilities to identify mutually-supported capabilities, clients
MUST represent their own capabilities with a list containing only the
capabilities actually supported, without any GREASE values.  In other
words, lists including GREASE values are only sent to other clients;
representations of a client's own capabilities MUST NOT contain
GREASE values.
Paragraph (version B):
extensibility failures.
Paragraph (version B):
GREASE values MUST be handled using normal logic for processing
unsupported values.  When comparing lists of capabilities to identify
mutually-supported capabilities, clients MUST represent their own
capabilities with a list containing only the capabilities actually
supported, without any GREASE values.  In other words, lists
including GREASE values are only sent to other clients;
representations of a client's own capabilities MUST NOT contain
GREASE values.
Paragraph (version B):
External: Whether a proposal of this type may be sent by an
"external" sender (see external-proposals).