Draft: draft-ietf-mls-protocol

Commentary: 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
Paragraph (version A):
The SignatureScheme type represents a signature algorithm.  Signature
public keys are opaque values in a format defined by the signature
scheme.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
This document requests the creation of the following new IANA
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).
Paragraph (version B):
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).
Paragraph (version A):
This specification defines the following ciphersuites for use with
MLS 1.0.
Paragraph (version A):
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.
Paragraph (version B):
The hash used for HKDF computations in MLS is the same hash used in
the HPKE KDF for the ciphersuite.
Paragraph (version A):
Specification Required RFC8126 registry requests are registered after
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
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.