Change:
This started off just fixing , then grew a bit. Defines an IANA registry for ExtensionType values Defines an IANA registry for CredentialType values Updates the Ciphersuites registry to share formatting with the other two, and to be more explicit about its ties to HPKE algorithms Removes the unnecessary field from ... and as a result removes the definition of (which is used nowhere else)
Now that we have a more robust extension mechanism, we need to have an IANA registry to manage extensions, including: Registry structure Registry policy and (probably) designated experts Reserved vendor space

Discussion:
Credentials MAY also include information that allows a relying party to verify the identity / signing key binding. <del> The SignatureScheme type represents a signature algorithm.  Signature public keys are opaque values in a format defined by the signature scheme. </del> <ins> A BasicCredential is a raw, unauthenticated assertion of an identity/ key binding.  The format of the key in the "public_key" field is defined by the relevant ciphersuite: the group ciphersuite for a credential in a ratchet tree, the KeyPackage ciphersuite for a credential in a KeyPackage object. For ciphersuites using Ed25519 or Ed448 signature schemes, the public key is in the format specified RFC8032.  For ciphersuites using ECDSA with the NIST curves P-256 or P-521, the public key is the output of the uncompressed Elliptic-Curve-Point-to-Octet-String conversion according to SECG. </ins> Note that each new credential that has not already been validated by the application MUST be validated against the Authentication Service.

15. This document requests the creation of the following new IANA <del> registries: MLS Ciphersuites (mls-ciphersuites).  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 Designated Experts (DEs). </del> <ins> registries: MLS Ciphersuites (mls-ciphersuites) MLS Extension Types (mls-extension-types) MLS Credential Types (mls-credential-types) 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 Designated Experts (DEs). [[ RFC EDITOR: Please replace XXXX throughout with the RFC number assigned to this document ]] </ins> 15.1.

Ciphersuite names follow the naming convention: <del> Where VALUE is represented as two 8bit octets: </del> <ins> Where VALUE is represented as a sixteen-bit integer: The columns in the registry are as follows: Value: The numeric value of the ciphersuite Name: The name of the ciphersuite </ins> <del> This specification defines the following ciphersuites for use with MLS 1.0. </del> <ins> 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. </ins> <del> The KEM/DEM constructions used for HPKE are defined by I-D.irtf-cfrg- hpke.  The corresponding AEAD algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM, are defined in RFC5116.  AEAD_CHACHA20_POLY1305 is defined in RFC7539.  The corresponding hash algorithms are defined in SHS. </del> <ins> Reference: The document where this ciphersuite is defined Initial contents: These ciphersuites map to HPKE primitives and TLS signature schemes as follows I-D.irtf-cfrg-hpke RFC8446: The hash used for HKDF computations in MLS is the same hash used in the HPKE KDF for the ciphersuite. </ins> It is advisable to keep the number of ciphersuites low to increase the chances clients can interoperate in a federated environment,

15.2. <del> [[ OPEN ISSUE: pick DE mailing address.  Maybe mls-des@ or mls-de- pool. ]] </del> <ins> This registry lists identifiers for extensions to the MLS protocol. The extension type field is two bytes wide, so valid extension type values are in the range 0x0000 to 0xffff. Template: Value: The numeric value of the extension type Name: The name of the extension type Message(s): The messages in which the extension may appear, drawn from the following list: KP: KeyPackage messages W: Welcome messages 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. Reference: The document where this extension is defined Initial contents: 15.3. This registry lists identifiers for types of credentials that can be used for authentication in the MLS protocol.  The extension type field is two bytes wide, so valid extension type values are in the range 0x0000 to 0xffff. Template: Value: The numeric value of the credential type Name: The name of the credential type 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. Reference: The document where this extension is defined Initial contents: 15.4. </ins> Specification Required RFC8126 registry requests are registered after <del> a three-week review period on the MLS DEs' mailing list: TBD@ietf.org [1], on the advice of one or more of the MLS DEs.  However, to allow for the allocation of values prior to publication, the MLS DEs may approve registration once they are satisfied that such a specification will be published. </del> <ins> 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. However, to allow for the allocation of values prior to publication, the MLS DEs may approve registration once they are satisfied that such a specification will be published. </ins> Registration requests sent to the MLS DEs mailing list for review SHOULD use an appropriate subject (e.g., "Request to register value

16.1.  URIs <del> [1] mailto:TBD@ietf.org </del> <ins> [1] mailto:mls-reg-review@ietf.org </ins> [2] mailto:iesg@ietf.org