Change:
Also copies the "Recommended" field by reference, instead of reciting it in each registry. Note that this has a conflict with that will not catch -- "MLSContentTBS" will have to be changed to whatever new name is agreed in that PR.
The of absolutely needs to be unique for every signature happening in the protocol, for security and avoid signature ambiguity. That includes signatures happening in extensions. Should this be referenced in a IANA considerations to ensure there is no conflict in the future? Or at least say something about this somewhere? We have to think how to design things well here to be future-proof: the structure must be used for every signature done with the leaf signature keys, which includes what might happen in extensions but also in future versions of MLS. If future versions of MLS could avoid doing , that would be great!
This seems to come down to whether we expect the signature keys used for MLS authentication to be used outside of MLS (otherwise there's no risk of confusion) and if so, whether this spec has any influence on that usage. If you're using your MLS key to sign Bitcoin transactions, we can't do much to help that. Note that there is not an issue for future version of MLS here. The label is constructed as , so a future version could just increment the part of that. Given all that, I might prefer a recommendation that signature keys not be reused across contexts, rather than trying to accommodate reuse. If we do something here, we should do something analogous to the registry, which are similarly intended for domain separation between different use cases. We should probably consider making an exporter label registry anyway.
I agree, we shouldn't do anything about someone using the MLS signature key in another protocol. About future MLS versions: I agree, but note that there is a length tag before that. It means that we impose to all signature of future MLS versions to start with (including the quic integer) Is it something acceptable or not, I don't now. I just think we should have in mind that the decisions we make now on will have an impact on the design of future MLS versions. About extensions: in the extensions document, there is a signature computed with If two extensions were to use the same label then this could lead to security problems, this is why I think the labels should be in some registry to ensure they are all unique. One other thing we could do is to separate all extensions signatures from the core MLS signatures, for exemple using the label "MLS 1.0 extension [label from extension]"? Like that a bogus extension can't introduce a security flaw in core MLS that way?

Discussion:
And its fields set to: Here, the functions "Signature.Sign" and "Signature.Verify" are <del> defined by the signature algorithm. </del> <ins> defined by the signature algorithm.  If MLS extensions require signatures by group members, they should re-use the SignWithLabel construction, using a distinct label.  To avoid collisions in these labels, an IANA registry is defined in mls-signature-labels. </ins> The ciphersuites are defined in section mls-ciphersuites.

Applications SHOULD provide a unique label to "MLS-Exporter" that identifies the secret's intended purpose.  This is to help prevent the same secret from being generated and used in two different <del> places. </del> <ins> places.  To help avoid the same label being used in different applications, an IANA registry for these labels has been defined in mls-exporter-labels. </ins> The exported values are bound to the group epoch from which the "exporter_secret" is derived, and hence reflect a particular state of

MLS Credential Types (mls-credential-types) <ins> MLS Signature Labels (mls-signature-labels) MLS Exporter Labels (mls-exporter-labels) </ins> All of these registries should be under a heading of "Messaging Layer Security", and assignments are made via the Specification Required policy RFC8126.  See de for additional information about the MLS

Name: The name of the wire format <del> Recommended: Whether support for this wire format is recommended by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. </del> <ins> Recommended: Same as in </ins> Reference: The document where this wire format is defined

GI: GroupInfo objects <del> Recommended: Whether support for this extension is recommended by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. </del> <ins> Recommended: Same as in </ins> Reference: The document where this extension is defined

Name: The name of the proposal type <del> Recommended: Whether support for this extension is recommended by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. </del> <ins> Recommended: Same as in </ins> Path Required: Whether a Commit covering a proposal of this type is required to have its "path" field populated (see commit).

Name: The name of the credential type <del> Recommended: Whether support for this credential is recommended by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. </del> <ins> Recommended: Same as in </ins> Reference: The document where this credential is defined

16.6. <ins> The "SignWithLabel" function defined in ciphersuites avoids the risk of confusion between signatures in different contexts.  Each context is assigned a distinct label that is incorporated into the signature. This registry records the labels defined in this document, and allows additional labels to be registered in case extensions add other types of signature using the same signature keys used elsewhere in MLS. Template: Label: The string to be used as the "Label" parameter to "SignWithLabel" Recommended: Same as in Reference: The document where this credential is defined Initial contents: 16.7. The exporter function defined in exporters allows applications to derive key material from the MLS key schedule.  Like the TLS exporter RFC8446, the MLS exporter uses a label to distinguish between different applications' use of the exporter.  This registry allows applications to register their usage to avoid collisions. Template: Label: The string to be used as the "Label" parameter to "MLS- Exporter" Recommended: Same as in Reference: The document where this credential is defined The registry has no initial contents, since it is intended to be used by applications, not the core protocol.  The table below is intended only to show the column layout of the registry. 16.8. </ins> Specification Required RFC8126 registry requests are registered after a three-week review period on the MLS DEs' mailing list: mls-reg- review@ietf.org [1], on the advice of one or more of the MLS DEs.

be perceived as creating a conflict of interest for a particular MLS DE, that MLS DE SHOULD defer to the judgment of the other MLS DEs. <del> 16.7. </del> <ins> 16.9. </ins> This document registers the "message/mls" MIME media type in order to allow other protocols (e.g., HTTP RFC7540) to convey MLS messages.