setting, HSMs and secure enclaves can be used to protect signature keys. <ins> 6.6. Various academic works have analyzed MLS and the different security guarantees it aims to provide.  The security of large parts of the protocol has been analyzed by [BBN19] (draft 7), [ACDT21] (draft 11) and [AJM20] (draft 12). Individual components of various drafts of the MLS protocol have been analyzed in isolation and with differing adversarial models, for example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20] and [ACJM20] analyze the ratcheting tree as the sub-protocol of MLS that facilitates key agreement, while [BCK21] analyzes the key derivation paths in the ratchet tree and key schedule.  Finally, [CHK19] analyzes the authentication and cross-group healing guarantees provided by MLS. </ins> 7. <ins> ACDT19: https://eprint.iacr.org/2019/1189 ACCKKMPPWY19: https://eprint.iacr.org/2019/1489 ACJM20: https://eprint.iacr.org/2020/752 AJM20: https://eprint.iacr.org/2020/1327 ACDT21: https://eprint.iacr.org/2021/1083 AHKM21: https://eprint.iacr.org/2021/1456 CHK19: https://eprint.iacr.org/2021/137 BCK21: https://eprint.iacr.org/2021/137 BBR18: https://hal.inria.fr/hal-02425247 BBN19: https://hal.laas.fr/INRIA/hal-02425229 8. </ins> This document makes no requests of IANA.


node for which this node has a private key * Decrypt the secret value for the parent of the copath node using the private key from the resolution node * Derive secret values for ancestors of that <del> node using the KDF keyed with the decrypted secret </del> <ins> node using the KDF keyed with the decrypted secret * The recipient SHOULD verify that the received public keys agree with the public keys derived from the new node_secret values </ins> Merge the updated secrets into the tree * Replace the public keys for nodes on the direct path with the received public keys * For


9.1. <del> [[ OPEN ISSUE: Direct initialization is currently undefined.  A client can create a group by initializing its own state to reflect a group including only itself, then adding the initial members.  This has computation and communication complexity O(N log N) instead of the O(N) complexity of direct initialization. ]] </del> <ins> A group can always be created by initializing a one-member group and using adding members individually.  For cases where the initial list of members is known, the Init message allows a group to be created more efficiently. The creator of the group constructs an Init message as follows: Fetch a UserInitKey for each member (including the creator) Identify a protocol version and cipher suite that is supported by all proposed members. Construct a ratchet tree with its leaves populated with the public keys and credentials from the UserInitKeys of the members, and all other nodes blank. Generate a fresh leaf key pair for the first leaf Compute its direct path in this ratchet tree Each member of the newly-created group initializes its state from the Init message as follows: Note the group ID, protocol version, and cipher suite in use Construct a ratchet tree as above Update the cached ratchet tree by replacing nodes in the direct path from the first leaf using the direct path Update the cached ratchet tree by replacing nodes in the direct path from the first leaf using the information contained in the "path" attribute The update secret for this interaction, used with an all-zero init secret to generate the first epoch secret, is the "path_secret[i+1]" derived from the "path_secret[i]" associated to the root node.  The members learn the relevant path secrets by decrypting one of the encrypted path secrets in the DirectPath and working back to the root (as in normal DirectPath processing). [[ OPEN ISSUE: This approach leaks the initial contents of the tree to the Delivery Service, unlike the sequential-Add case. ]] [[ OPEN ISSUE: It might be desireable for the group creator to be able to "pre-warm" the tree, by providing values for some nodes not on its direct path.  This would violate the tree invariant, so we would need to figure out what mitigations would be necessary. ]] </ins> 9.2.


information about a client that any existing member can use to add this client to the group asynchronously. <del> A ClientInitKey object specifies what ciphersuites a client supports, as well as providing public keys that the client can use for key derivation and signing.  The client's identity key is intended to be stable throughout the lifetime of the group; there is no mechanism to change it.  Init keys are intended to be used a very limited number of times, potentially once. (see init-key-reuse).  ClientInitKeys also contain an identifier chosen by the client, which the client MUST assure uniquely identifies a given ClientInitKey object among the set of ClientInitKeys created by this client. The init_keys array MUST have the same length as the cipher_suites array, and each entry in the init_keys array MUST be a public key for the asymmetric encryption scheme defined in the cipher_suites array and used in the HPKE construction for TreeKEM. The whole structure is signed using the client's identity key.  A ClientInitKey object with an invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </del> <ins> A ClientInitKey object specifies a ciphersuite that the client supports, as well as providing a public key that others can use for key agreement.  The client's identity key is intended to be stable throughout the lifetime of the group; there is no mechanism to change it.  Init keys are intended to be used a very limited number of times, ideally only once.  (See init-key-reuse).  Clients MAY generate and publish multiple ClientInitKey objects to support multiple ciphersuites, or to reduce the likelihood of init key reuse. ClientInitKeys contain an identifier chosen by the client, which the client MUST assure uniquely identifies a given ClientInitKey object among the set of ClientInitKeys created by this client. The value for init_key MUST be a public key for the asymmetric encryption scheme defined by cipher_suite.  The whole structure is signed using the client's identity key.  A ClientInitKey object with an invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </ins> 8.


The creator of the group constructs an Init message as follows: <del> Fetch a ClientInitKey for each member (including the creator) </del> <ins> Fetch one or more ClientInitKeys for each member (including the creator) </ins> Identify a protocol version and cipher suite that is supported by all proposed members.


needs to initialize a GroupContext object that can be updated to the current state using the Add message.  This information is encrypted for the new member using HPKE.  The recipient key pair for the HPKE <del> encryption is the one included in the indicated ClientInitKey, corresponding to the indicated ciphersuite.  The "add_key_nonce" field contains the key and nonce used to encrypt the corresponding Add message; if it is not encrypted, then this field MUST be set to the null optional value. </del> <ins> encryption is the one included in the indicated ClientInitKey.  The "add_key_nonce" field contains the key and nonce used to encrypt the corresponding Add message; if it is not encrypted, then this field MUST be set to the null optional value. </ins> In the description of the tree as a list of nodes, the "credential" field for a node MUST be populated if and only if that node is a leaf


direct path of the new node Set the leaf node in the tree at position "index" to a new node <del> containing the public key from the ClientInitKey in the Add corresponding to the ciphersuite in use, as well as the credential under which the ClientInitKey was signed </del> <ins> containing the public key from the ClientInitKey in the Add, as well as the credential under which the ClientInitKey was signed </ins> The "update_secret" resulting from this change is an all-zero octet string of length Hash.length.


A credential (only for leaf nodes) <ins> A signature over the content of the node </ins> The conditions under which each of these values must or must not be present are laid out in views.


Zero or more encrypted copies of the path secret corresponding to the node <ins> A signature over the node content </ins> The path secret value for a given node is encrypted for the subtree corresponding to the parent's non-updated child, i.e., the child on the copath of the leaf node.  There is one encrypted path secret for


ratchet tree and the members' ClientInitKeys. The hash of a tree is the hash of its root node, which we define <del> recursively, starting with the leaves.  The hash of a leaf node is the hash of a "LeafNodeHashInput" object: </del> <ins> recursively, starting with the leaves. While hashes at the nodes are used to check the integrity of the subtrees, signatures are required to provide authentication and group agreement.  Siganatures are especially important in the case of newcomers and MUST be verified when joining.  All nodes in the tree MUST be signed to provide authentication and group agreement. </ins> <del> The content within the leaf of a ratchet tree is composed of a "ClientInitKey" when the leaf is populated.  The "info" field is equal to the null optional value when the leaf is blank (i.e., no member occupies that leaf). </del> <ins> Elements of the ratchet tree are called "RatchetNode" objects and contain optionally a "ClientInitKey" when at the leaves or an optional "ParentNode" above. </ins> <del> The intermediate nodes contain less information, the hash of a parent node (including the root) is the hash of a "ParentNodeHashInput" struct: </del> <ins> When computing the hash of a parent node AB the "ParentNodeHash" structure is used: </ins> The "left_hash" and "right_hash" fields hold the hashes of the node's <del> left and right children, respectively.  The "public_key" field holds the hash of the public key stored at this node, represented as an "optional<HPKEPublicKey>" object, which is null if and only if the node is blank. </del> <ins> left (A) and right (B) children, respectively.  The signature within the "ParentNode" is computed over the its prefix within the serialized "ParentNodeHash" struct to cover all information about the sub-tree.  The "committer_index" is required for a member to determine the signing key needed to perform the signature verification. To compute the hash of a leaf node is the hash of a "LeafNodeHash" object: Note that unlike a ParentNode, a ClientInitKey already contains a signature. </ins> 7.4.


the "tree" array divided by two. Construct a new group state using the information in the GroupInfo <del> object.  The new member's position in the tree is "index", as defined above. </del> <ins> object and verify the integrity of the tree using the "tree_hash". The new member's position in the tree is "index", as defined above. </ins> Identify the lowest node at which the direct paths from "index" and "signer_index" overlap.  Set private keys for that node and


An AEAD encryption algorithm <ins> A signature algorithm </ins> The ciphersuite's Diffie-Hellman group is used to instantiate an HPKE I-D.irtf-cfrg-hpke instance for the purpose of public-key encryption. The ciphersuite must specify an algorithm "Derive-Key-Pair" that maps


Ciphersuites are represented with the CipherSuite type.  HPKE public keys are opaque values in a format defined by the underlying Diffie- Hellman protocol (see the Ciphersuites section of the HPKE <del> specification for more information): 6.1.1. This ciphersuite uses the following primitives: </del> <ins> specification for more information). </ins> <del> Hash function: SHA-256 </del> <ins> The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for the signatutes in MLSPlaintext and the tree signatures.  It can be different from the signature algorithm specified in credential fielf of ClientInitKeys. </ins> <del> AEAD: AES-128-GCM </del> <ins> The ciphersuites are defined in section mls-ciphersuites. </ins> <del> When HPKE is used with this ciphersuite, it uses the following algorithms: KEM: 0x0002 = DHKEM(Curve25519) </del> <ins> 6.1.1. </ins> <del> KDF: 0x0001 = HKDF-SHA256 </del> <ins> Depending on the Diffie-Hellman group of the ciphersuite, different rules apply to private key derivation and public key verification. </ins> <del> AEAD: 0x0001 = AES-GCM-128 </del> <ins> 6.1.1.1. </ins> Given an octet string X, the private key produced by the Derive-Key- <del> Pair operation is SHA-256(X).  (Recall that any 32-octet string is a valid Curve25519 private key.)  The corresponding public key is </del> <ins> Pair operation is SHA-256(X) (Recall that any 32-octet string is a valid X25519 private key).  The corresponding public key is </ins> X25519(SHA-256(X), 9). Implementations SHOULD use the approach specified in RFC7748 to


curves, they SHOULD perform the additional checks specified in Section 7 of <del> 6.1.2. This ciphersuite uses the following primitives: </del> <ins> 6.1.1.2. </ins> <del> Hash function: SHA-256 AEAD: AES-128-GCM When HPKE is used with this ciphersuite, it uses the following algorithms: KEM: 0x0001 = DHKEM(P-256) </del> <ins> Given an octet string X, the private key produced by the Derive-Key- Pair operation is SHA-512(X) truncated to 448 bits (Recall that any 56-octet string is a valid X448 private key).  The corresponding public key is X448(SHA-512(X), 5). </ins> <del> KDF: 0x0001 = HKDF-SHA256 </del> <ins> Implementations SHOULD use the approach specified in RFC7748 to calculate the Diffie-Hellman shared secret.  Implementations MUST check whether the computed Diffie-Hellman shared secret is the all- zero value and abort if so, as described in Section 6 of RFC7748.  If implementers use an alternative implementation of these elliptic curves, they SHOULD perform the additional checks specified in Section 7 of </ins> <del> AEAD: 0x0001 = AES-GCM-128 </del> <ins> 6.1.1.3. </ins> Given an octet string X, the private key produced by the Derive-Key- Pair operation is SHA-256(X), interpreted as a big-endian integer.


14. This document requests the creation of the following new IANA <del> registries: MLS Ciphersuites All of these registries should be under a heading of "Message Layer Security", and administered under a Specification Required policy RFC8126. </del> <ins> registries: MLS Ciphersuites (mls-ciphersuites).  All of these registries should be under a heading of "Message Layer Security", and assignments are made via the Specification Required policy RFC8126. See de for additional information about the MLS Designated Experts (DEs). </ins> 14.1. <del> The "MLS Ciphersuites" registry lists identifiers for suites of cryptographic algorithms defined for use with MLS.  These are two- byte values, so the maximum possible value is 0xFFFF = 65535.  Values in the range 0xF000 - 0xFFFF are reserved for vendor-internal usage. Template: Value: The two-byte identifier for the ciphersuite Name: The name of the ciphersuite Reference: Where this algorithm is defined The initial contents for this registry are as follows: [[ Note to RFC Editor: Please replace "XXXX" above with the number assigned to this RFC. ]] </del> <ins> A ciphersuite is a combination of a protocol version and the set of cryptographic algorithms that should be used. Ciphersuite names follow the naming convention: Where VALUE is represented as two 8bit octets: This specification defines the following ciphersuites for use with MLS 1.0. The KEM/DEM constructions used for HPKE are defined by 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. It is advisable to keep the number of ciphersuites low to increase the chances clients can interoperate in a federated environment, therefore the ciphersuites only inlcude modern, yet well-established algorithms.  Depending on their requirements, clients can choose between two security levels (roughly 128-bit and 256-bit).  Within the security levels clients can choose between faster X25519/X448 curves and FIPS 140-2 compliant curves for Diffie-Hellman key negotiations.  Additionally clients that run predominantly on mobile processors can choose ChaCha20Poly1305 over AES-GCM for performance reasons.  Since ChaCha20Poly1305 is not listed by FIPS 140-2 it is not paired with FIPS 140-2 compliant curves.  The security level of symmetric encryption algorithms and hash functions is paired with the security level of the curves. The mandatory-to-implement ciphersuite for MLS 1.0 is "MLS10_128_HPKE25519_AES128GCM_SHA256_Ed25519" which uses Curve25519, HKDF over SHA2-256 and AES-128-GCM for HPKE, and AES- 128-GCM with Ed25519 for symmetric encryption and signatures. Values with the first byte 255 (decimal) are reserved for Private Use. New ciphersuite values are assigned by IANA as described in iana- considerations. 14.2. [[ OPEN ISSUE: pick DE mailing address.  Maybe mls-des@ or mls-de- pool. ]] 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. Registration requests sent to the MLS DEs mailing list for review SHOULD use an appropriate subject (e.g., "Request to register value in MLS Bar registry"). Within the review period, the MLS DEs will either approve or deny the registration request, communicating this decision to the MLS DEs mailing list and IANA.  Denials SHOULD include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention for resolution using the iesg@ietf.org [2] mailing list. Criteria that SHOULD be applied by the MLS DEs includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or useful only for a single application, and whether the registration description is clear.  For example, the MLS DEs will apply the ciphersuite-related advisory found in ciphersuites. IANA MUST only accept registry updates from the MLS DEs and SHOULD direct all requests for registration to the MLS DEs' mailing list. It is suggested that multiple MLS DEs be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly informed review of registration decisions.  In cases where a registration decision could 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. 15.  References 15.1.  URIs [1] mailto:TBD@ietf.org [2] mailto:iesg@ietf.org </ins>


D.ietf-trans-rfc6962-bis.) The _direct path_ of a root is the empty list, and of any other node <del> is the concatenation of that node with the direct path of its parent. The _copath_ of a node is the list of siblings of nodes in its direct </del> <ins> is the concatenation of that node's parent along with the parent's direct path.  The _copath_ of a node is the node's sibling concatenated with the list of siblings of all the nodes in its direct </ins> path.  The _frontier_ of a tree is the list of heads of the maximal full subtrees of the tree, ordered from left to right. For example, in the below tree: <del> The direct path of C is (C, CD, ABCD) </del> <ins> The direct path of C is (CD, ABCD, ABCDEFG) </ins> The copath of C is (D, AB, EFG)


The path secret value for a given node is encrypted for the subtree corresponding to the parent's non-updated child, that is, the child on the copath of the leaf node.  There is one encrypted path secret <del> for each public key in the resolution of the non-updated child.  In particular, for the leaf node, there are no encrypted secrets, since a leaf node has no children. </del> <ins> for each public key in the resolution of the non-updated child. </ins> The recipient of a path update processes it with the following steps:


unoccupied leaf, or appended to the right edge of the tree if all leaves are occupied. <del> Create an initial, partial GroupInfo object reflecting the following values: Group ID: The group ID for the group Epoch: The epoch ID for the next epoch Tree: The group's ratchet tree after the commit has been applied Prior confirmed transcript hash: The confirmed transcript hash for the current state of the group (not the provisional state) </del> Create a DirectPath using the new tree (which includes any new members).  The GroupContext for this operation uses the "group_id", "epoch", "tree", and "prior_confirmed_transcript_hash"


the "confirmation" value in the MLSPlaintext.  Sign the MLSPlaintext using the current epoch's GroupContext as context. <del> Complete the GroupInfo by populating the following fields: </del> <ins> Update the tree in the provisional state by applying the direct path </ins> <del> Confirmed transcript hash: The confirmed transcript hash including the current Commit object </del> <ins> Construct a GroupInfo reflecting the new state: </ins> <del> Interim transcript hash: The interim transcript hash including the current Commit object </del> <ins> Group ID, epoch, tree, confirmed transcript hash, and interim transcript hash from the new state </ins> <del> Confirmation: The confirmation from the MLSPlaintext </del> <ins> The confirmation from the MLSPlaintext object </ins> Sign the GroupInfo using the member's private signing key Encrypt the GroupInfo using the key and nonce derived from the <del> "init_secret" for the current epoch (see welcoming-new-members) </del> <ins> "epoch_secret" for the new epoch (see welcoming-new-members) For each new member in the group: Identify the lowest common ancestor in the tree of the new member's leaf node and the member sending the Commit Compute the path secret corresponding to the commonn ancestor node Compute an EncryptedKeyPackage object that encapsulates the "init_secret" for the current epoch and the path secret for the common ancestor. </ins> <del> For each new member in the group, compute an EncryptedKeyPackage object that encapsulates the "init_secret" for the current epoch. </del> Construct a Welcome message from the encrypted GroupInfo object and the encrypted key packages.


the new state is the "prior_confirmed_transcript_hash" in the GroupInfo object. <del> Process the "path" field in the GroupInfo to update the new group state: </del> <ins> Update the leaf at index "index" with the private key corresponding to the public key in the node. </ins> <del> Apply the DirectPath to the tree, as described in synchronizing-views-of-the-tree. </del> <ins> Identify the lowest common ancestor of the leaves at "index" and at "GroupInfo.signer_index".  Set the private key for this node to the private key derived from the "path_secret" in the KeyPackage object. </ins> <del> Define "commit_secret" as the value "path_secret[n+1]" derived from the "path_secret[n]" value assigned to the root node. </del> <ins> For each parent of the common ancestor, up to the root of the tree, derive a new path secret and set the private key for the node to the private key derived from the path secret.  The private key MUST be the private key that correspondns to the public key in the node. </ins> Use the "epoch_secret" from the KeyPackage object to generate the epoch secret and other derived secrets for the current epoch.


A hash function <del> A Diffie-Hellman finite-field group or elliptic curve group </del> <ins> A key encapsulation mechanism (KEM) </ins> An AEAD encryption algorithm A signature algorithm <del> The ciphersuite's Diffie-Hellman group is used to instantiate an HPKE I-D.irtf-cfrg-hpke instance for the purpose of public-key encryption. The ciphersuite must specify an algorithm "Derive-Key-Pair" that maps octet strings with length Hash.length to HPKE key pairs. </del> <ins> The ciphersuite's KEM used to instantiate an HPKE I-D.irtf-cfrg-hpke instance for the purpose of public-key encryption.  Each ciphersuite has a "Derive-Key-Pair" function that maps octet strings of length "Nsk" (a KEM-specific constant defined by HPKE) to HPKE key pairs. This function is defined to be HPKE's "DeriveKeyPair" function. </ins> Ciphersuites are represented with the CipherSuite type.  HPKE public <del> keys are opaque values in a format defined by the underlying Diffie- Hellman protocol (see the Ciphersuites section of the HPKE specification for more information). </del> <ins> keys are opaque values in a format defined by the underlying protocol (see the Cryptographic Dependencies section of the HPKE specification for more information). </ins> The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for signatures in MLSPlaintext and the tree


The ciphersuites are defined in section mls-ciphersuites. <del> Depending on the Diffie-Hellman group of the ciphersuite, different rules apply to private key derivation and public key verification. For all ciphersuites defined in this document, the Derive-Key-Pair function begins by deriving a "key pair secret" of appropriate length, then converting it to a private key in the required group. The ciphersuite specifies the required length and the conversion. 6.1.1. For X25519, the key pair secret is 32 octets long.  No conversion is required, since any 32-octet string is a valid X25519 private key. The corresponding public key is X25519(SHA-256(X), 9). For X448, the key pair secret is 56 octets long.  No conversion is required, since any 56-octet string is a valid X448 private key.  The corresponding public key is X448(SHA-256(X), 5). Implementations MUST use the approach specified in RFC7748 to calculate the Diffie-Hellman shared secret.  Implementations MUST check whether the computed Diffie-Hellman shared secret is the all- zero value and abort if so, as described in Section 6 of RFC7748.  If implementers use an alternative implementation of these elliptic curves, they MUST perform the additional checks specified in Section 7 of 6.1.2. For P-256, the key pair secret is 32 octets long.  For P-521, the key pair secret is 66 octets long.  In either case, the private key derived from a key pair secret is computed by interpreting the key pair secret as a big-endian integer. ECDH calculations for these curves (including parameter and key generation as well as the shared secret calculation) are performed according to IEEE1363 using the ECKAS-DH1 scheme with the identity map as key derivation function (KDF), so that the shared secret is the x-coordinate of the ECDH shared secret elliptic curve point represented as an octet string.  Note that this octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the Field Element to Octet String Conversion Primitive, has constant length for any given field; leading zeros found in this octet string MUST NOT be truncated. (Note that this use of the identity KDF is a technicality.  The complete picture is that ECDH is employed with a non-trivial KDF because MLS does not directly use this secret for anything other than for computing other secrets.) Clients MUST validate remote public values by ensuring that the point is a valid point on the elliptic curve.  The appropriate validation procedures are defined in Section 4.3.7 of X962 and alternatively in Section 5.6.2.3 of keyagreement.  This process consists of three steps: (1) verify that the value is not the point at infinity (O), (2) verify that for Y = (x, y) both integers are in the correct interval, (3) ensure that (x, y) is a correct solution to the elliptic curve equation.  For these curves, implementers do not need to verify membership in the correct subgroup. </del> 6.2. A member of a group authenticates the identities of other


Note that, as a PSK may have a different lifetime than an update, it does not necessarily provide the same Forward Secrecy (FS) or Post- <del> Compromise Security (PCS) guarantees than a Commit message. </del> <ins> Compromise Security (PCS) guarantees as a Commit message. </ins> 7.10.


in MLSPlaintext. The "new_member" SenderType is used for clients proposing that they <del> themselves be added.  For this ID type the sender value MUST be zero. Proposals with types other than Add MUST NOT be sent with this sender type.  In such cases, the MLSPlaintext MUST be signed with the private key corresponding to the KeyPackage in the Add message. Recipients MUST verify that the MLSPlaintext carrying the Proposal message is validly signed with this key. </del> <ins> themselves be added.  For this ID type the sender value MUST be zero and the Proposal type MUST be Add. The MLSPlaintext MUST be signed with the private key corresponding to the KeyPackage in the Add message.  Recipients MUST verify that the MLSPlaintext carrying the Proposal message is validly signed with this key. </ins> The "preconfigured" SenderType is reserved for signers that are pre- provisioned to the clients within a group.  If proposals with these


The "path" field of a Commit message MUST be populated if the Commit covers at least one Update or Remove proposal, i.e., if the length of <del> the "updates" or "removes vectors is greater than zero.  The "path"field MUST also be populated if the Commit covers no proposals at all (i.e., if all three proposal vectors are empty).  The "path"field MAY be omitted if the Commit covers only Add proposals. In pseudocode, the logic for whether the "path` field is required is as follows: </del> <ins> the "updates" or "removes" vectors is greater than zero.  The "path" field MUST also be populated if the Commit covers no proposals at all (i.e., if all three proposal vectors are empty).  The "path" field MAY be omitted if the Commit covers only Add proposals.  In pseudocode, the logic for whether the "path" field is required is as follows: </ins> To summarize, a Commit can have three different configurations, with different uses:


12. Each Commit message is premised on a given starting state, indicated <del> in its "prior_epoch" field.  If the changes implied by a Commit messages are made starting from a different state, the results will be incorrect. </del> <ins> by the "epoch" field of the enclosing MLSPlaintext message.  If the changes implied by a Commit messages are made starting from a different state, the results will be incorrect. </ins> This need for sequencing is not a problem as long as each time a group member sends a Commit message, it is based on the most current


above), then it MUST be populated.  Otherwise, the sender MAY omit the "path" field at its discretion. <del> If populating the "path" field: Create a DirectPath using the new </del> <ins> If populating the "path" field: Create a UpdatePath using the new </ins> tree (which includes any new members).  The GroupContext for this operation uses the "group_id", "epoch", "tree_hash", and "confirmed_transcript_hash" values in the initial GroupContext object. <del> Assign this DirectPath to the "path" field in the Commit. </del> <ins> Assign this UpdatePath to the "path" field in the Commit. </ins> <del> Apply the DirectPath to the tree, as described in </del> <ins> Apply the UpdatePath to the tree, as described in </ins> synchronizing-views-of-the-tree.  Define "commit_secret" as the value "path_secret[n+1]" derived from the "path_secret[n]" value assigned to the root node.


the ratchet tree the provisional GroupContext, to update the ratchet tree and generate the "commit_secret": <del> Apply the DirectPath to the tree, as described in </del> <ins> Apply the UpdatePath to the tree, as described in </ins> synchronizing-views-of-the-tree, and store "key_package" at the Committer's leaf.


A key package that is prepublished by a client, which other clients can use to introduce the client to a new group. <del> A long-lived signing key pair used to authenticate the sender of a message. </del> <ins> A signing key pair used to authenticate the sender of a message. </ins> Terminology specific to tree computations is described in ratchet- trees.


Provider (SP) as described in I-D.ietf-mls-architecture.  In particular, we assume the SP provides the following services: <del> A long-term signature key provider which allows clients to authenticate protocol messages in a group. </del> <ins> A signature key provider which allows clients to authenticate protocol messages in a group. </ins> A broadcast channel, for each group, which will relay a message to all members of a group.  For the most part, we assume that this


as well as providing a public key that others can use for key agreement.  The client's signature key can be updated throughout the lifetime of the group by sending a new KeyPackage with a new <del> signature key; the new signature key MUST be validated by the </del> <ins> Credential.  However, the identity MUST be the same in both Credentials and the new Credential MUST be validated by the </ins> authentication service. When used as InitKeys, KeyPackages are intended to be used only once


creator, because they are derived from an authenticated key exchange protocol.  Subsequent leaf keys are known only by their owner. <del> Note that the long-term signature keys used by the protocol MUST be distributed by an "honest" authentication service for clients to authenticate their legitimate peers. </del> <ins> Note that the signature keys used by the protocol MUST be distributed by an "honest" authentication service for clients to authenticate their legitimate peers. </ins> 14.2.


This information is aggregated in a "PublicGroupState" object as follows: <del> "struct { CipherSuite cipher_suite; opaque group_id<0..255>; uint64 epoch; opaque tree_hash<0..255>; opaque interim_transcript_hash<0..255>; Extension extensions<0..2^32-1>; HPKEPublicKey external_pub; } PublicGroupState; " </del> Note that the "tree_hash" field is used the same way as in the Welcome message.  The full tree can be included via the "ratchet_tree" extension ratchet-tree-extension. <del> The information above are not deemed public data in general, but applications can choose to make them available to new members in order to allow External Commits. </del> <ins> The signature MUST verify using the public key taken from the credential in the leaf node at position "signer_index".  The signature covers the following structure, comprising all the fields in the PublicGroupState above "signer_index": This signature authenticates the HPKE public key, so that the joiner knows that the public key was provided by a member of the group.  The fields that are not signed are included in the key schedule via the GroupContext object.  If the joiner is provided an inaccurate data for these fields, then its external Commit will have an incorrect "confirmation_tag" and thus be rejected. The information in a PublicGroupState is not deemed public in general, but applications can choose to make it available to new members in order to allow External Commits. </ins> External Commits work like regular Commits, with a few differences:


client being added to new groups by exhausting all available InitKeys. <ins> 15.5. It is possible for a malicious member of a group to "fragment" the group by crafting an invalid UpdatePath.  Recall that an UpdatePath encrypts a sequence of path secrets to different subtrees of the group's ratchet trees.  These path secrets should be derived in a sequence as described in ratchet-tree-evolution, but the UpdatePath syntax allows the sender to encrypt arbitrary, unrelated secrets. The syntax also does not guarantee that the encrypted path secret encrypted for a given node corresponds to the public key provided for that node. Both of these types of corruption will cause processing of a Commit to fail for some members of the group.  If the public key for a node does not match the path secret, then the members that decrypt that path secret will reject the commit based on this mismatch.  If the path secret sequence is incorrect at some point, then members that can decrypt nodes before that point will compute a different public key for the mismatched node than the one in the UpdatePath, which also causes the Commit to fail.  Applications SHOULD provide mechanisms for failed commits to be reported, so that group members who were not able to recognize the error themselves can reject the commit and roll back to a previous state if necessary. Even with such an error reporting mechanism in place, however, it is still possible for members to get locked out of the group by a malformed commit.  Since malformed Commits can only be recognized by certain members of the group, in an asynchronous application, it may be the case that all members that could detect a fault in a Commit are offline.  In such a case, the Commit will be accepted by the group, and the resulting state possibly used as the basis for further Commits.  When the affected members come back online, they will reject the first commit, and thus be unable to catch up with the group. Applications can address this risk by requiring certain members of the group to acknowledge successful processing of a Commit before the group regards the Commit as accepted.  The minimum set of acknowledgements necessary to verify that a Commit is well-formed comprises an acknowledgement from one member per node in the UpdatePath, that is, one member from each subtree rooted in the copath node corresponding to the node in the UpdatePath. </ins> 16. This document requests the creation of the following new IANA


committer's contribution to the group and provides PCS with regard to the committer. <del> An "add-only" Commit that references only Add proposals, in which the path is optional.  Such a commit provides PCS with regard to the committer only if the path field is present. </del> <ins> A "partial" Commit that references Add, PreSharedKey, or ReInit proposals but where the path is empty.  Such a commit doesn't provide PCS with regard to the committer. </ins> A "full" Commit that references proposals of any type, which provides FS with regard to any removed members and PCS for the


A signature algorithm <del> MLS uses draft-07 of HPKE I-D.irtf-cfrg-hpke for public-key </del> <ins> MLS uses draft-08 of HPKE I-D.irtf-cfrg-hpke for public-key </ins> encryption.  The "DeriveKeyPair" function associated to the KEM for the ciphersuite maps octet strings to HPKE key pairs.


External Commits work like regular Commits, with a few differences: <del> External Commits MUST reference an Add Proposal that adds the issuing new member to the group </del> <ins> The proposals included by value in an External Commit MUST meet the following conditions: There MUST be a single Add proposal that adds the new issuing new member to the group There MUST be a single ExternalInit proposal There MUST NOT be any Update proposals If a Remove proposal is present, then the "credential" and "endpoint_id" of the removed leaf MUST be the same as the corresponding values in the Add KeyPackage. The proposals included by reference in an External Commit MUST meet the following conditions: There MUST NOT be any ExternalInit proposals </ins> External Commits MUST contain a "path" field (and is therefore a "full" Commit)


public key for the credential in the "leaf_key_package" of the "path" field. <del> An external commit MUST reference no more than one ExternalInit proposal, and the ExternalInit proposal MUST be supplied by value, not by reference.  When processing a Commit, both existing and new members MUST use the external init secret as described in external-initialization. </del> <ins> When processing a Commit, both existing and new members MUST use the external init secret as described in external-initialization. </ins> The sender type for the MLSPlaintext encapsulating the External Commit MUST be "new_member" <del> If the Add Proposal is also issued by the new member, its member SenderType MUST be "new_member" </del> <ins> In other words, External Commits come in two "flavors" - a "join" commit that adds the sender to the group or a "resync" commit that replaces a member's prior appearance with a new one. Note that the "resync" operation allows an attacker that has compromised a member's signature private key to introduce themselves into the group and remove the prior, legitimate member in a single Commit.  Without resync, this can still be done, but requires two operations, the external Commit to join and a second Commit to remove the old appearance.  Applications for whom this distinction is salient can choose to disallow external commits that contain a Remove, or to allow such resync commits only if they contain a "reinit" PSK proposal that demonstrates the joining member's presence in a prior epoch of the group.  With the latter approach, the attacke would need to compromise the PSK as well as the signing key, but the application will need to ensure that continuing, non-resync'ing members have the required PSK. </ins> 11.2.2.


guaranteed by a digital signature on each message from the sender's signature key. <ins> The signature keys held by group members are critical to the security of MLS against active attacks.  If a member's signature key is compromised, then an attacker can create KeyPackages impersonating the member; depending on the application, this can then allow the attacker to join the group with the compromised member's identity. For example, if a group has enabled external parties to join via external commits, then an attacker that has compromised a member's signature key could use an external commit to insert themselves into the group - even using a "resync"-style external commit to replace the compromised member in the group. Applications can mitigate the risks of signature key compromise using pre-shared keys.  If a group requires joiners to know a PSK in addition to authenticating with a credential, then in order to mount an impersonation attack, the attacker would need to compromise the relevant PSK as well as the victim's signature key.  The cost of this mitigation is that the application needs some external arrangement that ensures that the legitimate members of the group to have the required PSKs. </ins> 15.3. Post-compromise security is provided between epochs by members


Tree hash: The root hash of the above ratchet tree <del> Confirmed transcript hash: the zero-length octet string </del> <ins> Confirmed transcript hash: The zero-length octet string </ins> <del> Interim transcript hash: the zero-length octet string </del> <ins> Interim transcript hash: The zero-length octet string </ins> <del> Init secret: a fresh random value of size "KDF.Nh" </del> <ins> Init secret: A fresh random value of size "KDF.Nh" Extensions: Any values of the creator's choosing </ins> For each member, construct an Add proposal from the KeyPackage for that member (see add)


10.1. <ins> The configuration of a group imposes certain requirements on clients in the group.  At a minimum, all members of the group need to support the ciphersuite and protocol version in use.  Additional requirements can be imposed by including a "required_capabilities" extension in the GroupContext. This extension lists the extensions and proposal types that must be supported by all members of the group.  For new members, it is enforced by existing members during the application of Add commits. Existing members should of course be in compliance already.  In order to ensure this continues to be the case even as the group's extensions can be updated, a GroupContextExtensions proposal is invalid if it contains a "required_capabilities" extension that requires capabililities not supported by all current members. 10.2. </ins> A new group may be tied to an already existing group for the purpose of re-initializing the existing group, or to branch into a sub-group. Re-initializing an existing group may be used, for example, to


object must be a randomly sampled nonce of length "KDF.Nh" to avoid key re-use. <del> 10.1.1. </del> <ins> 10.2.1. </ins> If a client wants to create a subgroup of an existing group, they MAY choose to include a "PreSharedKeyID" in the "GroupSecrets" object of


11.1.1. An Add proposal requests that a client with a specified KeyPackage be <del> added to the group. </del> <ins> added to the group.  The proposer of the Add MUST validate the KeyPackage in the same way as receipients are required to do below. </ins> The proposer of the Add does not control where in the group's ratchet tree the new member is added.  Instead, the sender of the Commit


in the tree, for the second Add, the next empty leaf to the right, etc. <ins> Validate the KeyPackage: Verify that the signature on the KeyPackage is valid using the public key in the KeyPackage's credential Verify that the following fields in the KeyPackage are unique among the members of the group (including any other members added in the same Commit): "(credential.identity, endpoint_id)" tuple "credential.signature_key" "hpke_init_key" Verify that the KeyPackage is compatible with the group's parameters.  The ciphersuite and protocol version of the KeyPackage must match those in use in the group.  If the GroupContext has a "required_capabilities" extension, then the required extensions and proposals MUST be listed in the KeyPackage's "capabilities" extension. </ins> If necessary, extend the tree to the right until it has at least index + 1 leaves


"struct { Extension extensions<0..2^32-1>; } GroupContextExtensions; " <del> A member of the group applies a GroupContextExtensions proposal by removing all of the existing extensions from the GroupContext object for the group and replacing them with the list of extensions in the proposal.  (This is a wholesale replacement, not a merge.  An extension is only carried over if the sender of the proposal includes it in the new list.)  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. </del> <ins> A member of the group applies a GroupContextExtensions proposal with the following steps: If the new extensions include a "required_capabilities" extension, verify that all members of the group support the required capabilities (including those added in the same commit, and excluding those removed). Remove all of the existing extensions from the GroupContext object for the group and replacing them with the list of extensions in the proposal.  (This is a wholesale replacement, not a merge.  An extension is only carried over if the sender of the proposal includes it in the new list.) 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. </ins> 11.1.9.


DeriveSecret takes its Secret argument from the incoming arrow <ins> "0" represents an all-zero byte string of length "KDF.Nh". </ins> When processing a handshake message, a client combines the following information to derive new epoch secrets:


in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows: <del> Here "0" represents the all-zero vector of length KDF.Nh.  The </del> <ins> Here "0" represents the all-zero vector of length "KDF.Nh".  The </ins> "index" field in "PSKLabel" corresponds to the index of the PSK in the "psk" array, while the "count" field contains the total number of PSKs.  In other words, the PSKs are chained together with KDF.Extract


If not populating the "path" field: Set the "path" field in the Commit to the null optional.  Define "commit_secret" as the all- <del> zero vector of the same length as a "path_secret" value would be. In this case, the new ratchet tree is the same as the provisional ratchet tree. </del> <ins> zero vector of length "KDF.Nh" (the same length as a "path_secret" value would be).  In this case, the new ratchet tree is the same as the provisional ratchet tree. </ins> Derive the "psk_secret" as specified in pre-shared-keys, where the order of PSKs in the derivation corresponds to the order of


from the "path_secret[n]" value assigned to the root node. If the "path" value is not populated: Define "commit_secret" as <del> the all-zero vector of the same length as a "path_secret" value would be. </del> <ins> the all-zero vector of length "KDF.Nh" (the same length as a "path_secret" value would be). </ins> Update the confirmed and interim transcript hashes using the new Commit, and generate the new GroupContext.


process the Commit (i.e., not including any members being added or removed by the Commit). <ins> The sender of a Commit SHOULD NOT include any Update proposals that the sender themselves generated.  If sender generated one or more Update proposals during an epoch, then it SHOULD instead update its leaf and direct path by sending "path" field in the Commit. </ins> If there are multiple proposals that apply to the same leaf, the committer chooses one and includes only that one in the Commit, considering the rest invalid.  The committer MUST prefer any Remove


on PSKs. Each PSK in MLS has a type that designates how it was provisioned. <del> External PSKs are provided by the application, while recovery and re- init PSKs are derived from the MLS key schedule and used in cases where it is necessary to authenticate a member's participation in a prior group state.  In particular, in addition to external PSK types, a PSK derived from within MLS may be used in the following cases: Re-Initialization: If during the lifetime of a group, the group members decide to switch to a more secure ciphersuite or newer protocol version, a PSK can be used to carry entropy from the old group forward into a new group with the desired parameters. Branching: A PSK may be used to bootstrap a subset of current group members into a new group.  This applies if a subset of current group members wish to branch based on the current group state. </del> <ins> External PSKs are provided by the application, while resumption PSKs are derived from the MLS key schedule and used in cases where it is necessary to authenticate a member's participation in a prior epoch. </ins> The injection of one or more PSKs into the key schedule is signaled <del> in two ways: 1) as a "PreSharedKey" proposal, and 2) in the "GroupSecrets" object of a Welcome message sent to new members added in that epoch. </del> <ins> in two ways: Existing members are informed via PreSharedKey proposals covered by a Commit, and new members added in the Commit are informed via GroupSecrets object in the Welcome message corresponding to the Commit.  To ensure that existing and new members compute the same PSK input to the key schedule, the Commit and GroupSecrets objects MUST indicate the same set of PSKs, in the same order. </ins> On receiving a Commit with a "PreSharedKey" proposal or a GroupSecrets object with the "psks" field set, the receiving Client


8.7. <del> The main MLS key schedule provides a "resumption_secret" which can provide extra security in some cross-group operations. </del> <ins> The main MLS key schedule provides a "resumption_secret" that is used as a PSK to inject entropy from one epoch into another.  This functionality is used in the reinitialization and branching processes described in reinitialization and sub-group-branching, but may be used by applications for other purposes. </ins> <del> The application SHOULD specify an upper limit on the number of past epochs for which the "resumption_secret" may be stored. There are two ways in which a "resumption_secret" can be used: to re- initialize the group with different parameters, or to create a sub- group of an existing group as detailed in pre-shared-keys. Resumption keys are distinguished from exporter keys in that they have specific use inside the MLS protocol, whereas the use of exporter secrets may be decided by an external application.  They are thus derived separately to avoid key material reuse. </del> <ins> Some uses of resumption PSKs might call for the use of PSKs from historical epochs.  The application SHOULD specify an upper limit on the number of past epochs for which the "resumption_secret" may be stored. </ins> 8.8.


Transmit the Welcome message to the other new members The recipient of a Welcome message processes it as described in <del> joining-via-welcome-message. </del> <ins> joining-via-welcome-message.  If application context informs the recipient that the Welcome should reflect the creation of a new group (for example, due to a branch or reinitialization), then the recipient MUST verify that the epoch value in the GroupInfo is equal to 1. </ins> In principle, the above process could be streamlined by having the creator directly create a tree and choose a random value for first epoch's epoch secret.  We follow the steps above because it removes unnecessary choices, by which, for example, bad randomness could be introduced.  The only choices the creator makes here are its own <del> KeyPackage, the leaf secret from which the Commit is built, and the intermediate key pairs along the direct path to the root. </del> <ins> KeyPackage and the leaf secret from which the Commit is built. </ins> 10.1.


10.2. <del> A new group may be tied to an already existing group for the purpose of re-initializing the existing group, or to branch into a sub-group. Re-initializing an existing group may be used, for example, to restart the group with a different ciphersuite or protocol version. Branching may be used to bootstrap a new group consisting of a subset of current group members, based on the current group state. </del> <ins> A group may be reinitialized by creating a new group with the same membership and different parameters, and linking it to the old group via a resumption PSK.  The members of a group reinitialize it using the following steps: A member of the old group sends a ReInit proposal (see reinit) A member of the old group sends a Commit covering the ReInit proposal A member of the old group sends a Welcome message for the new group that matches the ReInit The "group_id", "version", and "cipher_suite" fields in the Welcome message MUST be the same as the corresponding fields in the ReInit proposal. The "epoch" in the Welcome message MUST be 1 The Welcome MUST specify a PreSharedKey of type "resumption" with usage "reinit".  The "group_id" must match the old group, and the "epoch" must indicate the epoch after the Commit covering the ReInit. The "psk_nonce" included in the "PreSharedKeyID" of the resumption PSK MUST be a randomly sampled nonce of length "KDF.Nh", for the KDF defined by the new grou's ciphersuite. Note that these three steps may be done by the same group member or different members.  For example, if a group member sends a commit with an inline ReInit proposal (steps 1 and 2), but then goes offline, another group member may send the corresponding Welcome. This flexibility avoids situations where a group gets stuck between steps 2 and 3. </ins> <del> In both cases, the "psk_nonce" included in the "PreSharedKeyID" object must be a randomly sampled nonce of length "KDF.Nh" to avoid key re-use. </del> <ins> Resumption PSKs with usage "reinit" MUST NOT be used in other contexts.  A PreSharedKey proposal with type "resumption" and usage "reinit" MUST be considered invalid. </ins> <del> 10.2.1. </del> <ins> 10.3. </ins> <del> If a client wants to create a subgroup of an existing group, they MAY choose to include a "PreSharedKeyID" in the "GroupSecrets" object of the Welcome message choosing the "psktype" "branch", the "group_id" of the group from which a subgroup is to be branched, as well as an epoch within the number of epochs for which a "resumption_secret" is kept. </del> <ins> A new group can be formed from a subset of an existing group's members, using the same parameters as the old group.  The creator of the group indicates this situation by including a PreSharedKey of type "resumption" with usage "branch" in the Welcome message that creates the branched subgroup. A client receiving a Welcome including a PreSharedKey of type "resumption" with usage "branch" MUST verify that the new group reflects a subgroup branched from the referenced group. The "version" and "ciphersuite" values in the Welcome MUST be the same as those used by the old group. Each KeyPackage in a leaf node of the new group's tree MUST be a leaf in the old group's tree at the epoch indicated in the PreSharedKey. In addition, to avoid key re-use, the "psk_nonce" included in the "PreSharedKeyID" object MUST be a randomly sampled nonce of length "KDF.Nh". Resumption PSKs with usage "branch" MUST NOT be used in other contexts.  A PreSharedKey proposal with type "resumption" and usage "branch" MUST be considered invalid. </ins> 11.


11.1.5. <del> A ReInit proposal represents a request to re-initialize the group with different parameters, for example, to increase the version number or to change the ciphersuite.  The re-initialization is done by creating a completely new group and shutting down the old one. </del> <ins> A ReInit proposal represents a request to reinitialize the group with different parameters, for example, to increase the version number or to change the ciphersuite.  The reinitialization is done by creating a completely new group and shutting down the old one. </ins> A member of the group applies a ReInit proposal by waiting for the <del> committer to send the Welcome message and by checking that the "group_id" and the parameters of the new group corresponds to the ones specified in the proposal.  The Welcome message MUST specify exactly one pre-shared key with "psktype = reinit", and with "psk_group_id" and "psk_epoch" equal to the "group_id" and "epoch" of the existing group after the Commit containing the "reinit" Proposal was processed.  The Welcome message may specify the inclusion of other pre-shared keys with a "psktype" different from "reinit". </del> <ins> committer to send the Welcome message that matches the ReInit, according to the criteria in reinitialization. </ins> If a ReInit proposal is included in a Commit, it MUST be the only proposal referenced by the Commit.  If other non-ReInit proposals


If a ReInit proposal was part of the Commit, the committer MUST create a new group with the parameters specified in the ReInit proposal, and with the same members as the original group.  The <del> Welcome message MUST include a "PreSharedKeyID" with "psktype" "reinit" and with "psk_group_id" and "psk_epoch" corresponding to the current group and the epoch after the commit was processed. </del> <ins> Welcome message MUST include a "PreSharedKeyID" with the following parameters: "psktype": "resumption" "usage": "reinit" "group_id": The group ID for the current group "epoch": The epoch that the group will be in after this Commit </ins> A member of the group applies a Commit message by taking the following steps:


If the Commit included a ReInit proposal, the client MUST NOT use the group to send messages anymore.  Instead, it MUST wait for a <del> Welcome message from the committer and check that The "version", "cipher_suite" and "extensions" fields of the new group corresponds to the ones in the "ReInit" proposal, and that the "version" is greater than or equal to that of the original group. The "psks" field in the Welcome message includes a "PreSharedKeyID" with "psktype" = "reinit", and "psk_epoch" and "psk_group_id" equal to the epoch and group ID of the original group after processing the Commit. </del> <ins> Welcome message from the committer meeting the requirements of reinitialization. </ins> The confirmation tag value confirms that the members of the group have arrived at the same state of the group:


in the credential field of the KeyPackage objects in the leaves of the tree (including the InitKeys used to add new members). <ins> To disambiguate different signatures used in MLS, each signed value is prefixed by a label as shown below: Here, the functions "Signature.Sign" and "Signature.Verify" are defined by the signature algorithm. </ins> The ciphersuites are defined in section mls-ciphersuites. 6.2.


The value for hpke_init_key MUST be a public key for the asymmetric encryption scheme defined by cipher_suite.  The whole structure is signed using the client's signature key.  A KeyPackage object with an <del> invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </del> <ins> invalid signature field MUST be considered malformed. The signature is computed by the function "SignWithLabel" with a label "KeyPackage" and a content comprising of all of the fields except for the signature field. </ins> KeyPackage objects MUST contain at least two extensions, one of type "capabilities", and one of type "lifetime".  The "capabilities"


The "signature" field in an MLSPlaintext object is computed using the signing private key corresponding to the public key, which was authenticated by the credential at the leaf of the tree indicated by <del> the sender field.  The signature covers the plaintext metadata and message content, which is all of MLSPlaintext except for the "signature", the "confirmation_tag" and "membership_tag" fields.  If the sender is a member of the group, the signature also covers the GroupContext for the current epoch, so that signatures are specific to a given group and epoch. </del> <ins> the sender field.  The signature is computed using "SignWithLabel" with label ""MLSPlaintextTBS"" and with a content that covers the plaintext metadata and message content, which is all of MLSPlaintext except for the "signature", the "confirmation_tag" and "membership_tag" fields.  If the sender is a member of the group, the content also covers the GroupContext for the current epoch, so that signatures are specific to a given group and epoch. </ins> The "membership_tag" field in the MLSPlaintext object authenticates the sender's membership in the group.  For an MLSPlaintext with a


actually allowed to evict other members; groups can enforce access control policies on top of these basic mechanism. <ins> 4.3. A group comprises a single linear sequence of epochs and groups are generally independent of one-another.  However, it can sometimes be useful to link epochs cryptographically, either within a group or across groups.  MLS derives a resumption pre-shared key (PSK) from each epoch to allow entropy extracted from one epoch to be injected into a future epoch.  This link guarantees that members entering the new epoch agree on a key if and only if were members of the group during the epoch from which the resumption key was extracted. MLS supports two ways to tie a new group to an existing group.  Re- initialization closes one group and creates a new group comprising the same members with different parameters.  Branching starts a new group with a subset of the original group's participants (with no effect on the original group).  In both cases, the new group is linked to the old group via a resumption PSK. Applications may also choose to use resumption PSKs to link epochs in other ways.  For example, the following figure shows a case where a resumption PSK from epoch "n" is injected into epoch "n+k".  This demonstrates that the members of the group at epoch "n+k" were also members at epoch "n", irrespective of any changes to these members' keys due to Updates or Commits. </ins> 5. The protocol uses "ratchet trees" for deriving shared secrets among a


precisely two children, a _left_ child and a _right_ child.  A node is the _root_ of a tree if it has no parents, and _intermediate_ if it has both children and parents.  The _descendants_ of a node are <del> that node, its children, and the descendants of its children, and we say a tree _contains_ a node if that node is a descendant of the root of the tree.  Nodes are _siblings_ if they share the same parent. </del> <ins> that node's children, and the descendants of its children, and we say a tree _contains_ a node if that node is a descendant of the root of the tree, or if the node itself is the root of the tree.  Nodes are _siblings_ if they share the same parent. </ins> <del> A _subtree_ of a tree is the tree given by the descendants of any node, the _head_ of the subtree.  The _size_ of a tree or subtree is </del> <ins> A _subtree_ of a tree is the tree given by any node (the _head_ of the subtree) and its descendants.  The _size_ of a tree or subtree is </ins> the number of leaf nodes it contains.  For a given parent node, its _left subtree_ is the subtree with its left child as head (respectively _right subtree_).


the GroupContext. This extension lists the extensions and proposal types that must be <del> supported by all members of the group.  For new members, it is enforced by existing members during the application of Add commits. Existing members should of course be in compliance already.  In order to ensure this continues to be the case even as the group's extensions can be updated, a GroupContextExtensions proposal is invalid if it contains a "required_capabilities" extension that requires capabilities not supported by all current members. </del> <ins> supported by all members of the group.  The "default" proposal and extension types defined in this document are assumed to be implemented by all clients, and need not be listed in RequiredCapabilities in order to be safely used. For new members, support for required capabilities is enforced by existing members during the application of Add commits.  Existing members should of course be in compliance already.  In order to ensure this continues to be the case even as the group's extensions can be updated, a GroupContextExtensions proposal is invalid if it contains a "required_capabilities" extension that requires non- default capabilities not supported by all current members. </ins> 10.2.


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. <ins> 18.6. This document registers the "message/mls" MIME media type in order to allow other protocols (ex: HTTP RFC7540) to convey MLS messages. </ins> 19.  References 19.1.  URIs


Terminology specific to tree computations is described in ratchet- tree-terminology. <ins> 2.1. </ins> We use the TLS presentation language RFC8446 to describe the <del> structure of protocol messages. </del> <ins> structure of protocol messages.  In addition to the base syntax, we add two additional features, the ability for fields to be optional and the ability for vectors to have variable-size length headers. 2.1.1. An optional value is encoded with a presence-signaling octet, followed by the value itself if present.  When decoding, a presence octet with a value other than 0 or 1 MUST be rejected as malformed. 2.1.2. In the TLS presentation language, vectors are encoded as a sequence of encoded elements prefixed with a length.  The length field has a fixed size set by specifying the minimum and maximum lengths of the encoded sequence of elements. In MLS, there are several vectors whose sizes vary over significant ranges.  So instead of using a fixed-size length field, we use a variable-size length using a variable-length integer encoding based on the one in Section 16 of RFC9000.  (They differ only in that the one here requires a minimum-size encoding.)  Instead of presenting min and max values, the vector description simply includes a "V". For example: Such a vector can represent values with length from 0 bytes to 2^62 bytes.  The variable-length integer encoding reserves the two most significant bits of the first byte to encode the base 2 logarithm of the integer encoding length in bytes.  The integer value is encoded on the remaining bits, in network byte order.  The encoded value MUST use the smallest number of bits required to represent the value. When decoding, values using more bits than necessary MUST be treated as malformed. This means that integers are encoded on 1, 2, 4, or 8 bytes and can encode 6-, 14-, 30-, or 62-bit values respectively. For example, the eight-byte sequence c2 19 7c 5e ff 14 e8 8c (in hexadecimal) decodes to the decimal value 151288809941952652; the four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 (as does the two byte sequence 40 25). The following figure adapts the pseudocode provided in RFC9000 to add a check for minimum-length encoding: The use of variable-size integers for vector lengths allows vectors to grow very large, up to 2^62 bytes.  Implementations should take care not to allow vectors to overflow available storage.  To facilitate debugging of potential interoperatbility problems, implementations should provide a clear error when such an overflow condition occurs. </ins> 3.


The tree hash of a tree is the tree hash of its root node, which we define recursively, starting with the leaves. <del> As some nodes may be blank while others contain data we use the following struct to include data if present. </del> The tree hash of a leaf node is the hash of leaf's "LeafNodeHashInput" object which might include a "LeafNode" object depending on whether or not it is blank.


A GroupContextExtensions proposal is used to update the list of extensions in the GroupContext for the group. <del> "struct { Extension extensions<0..2^32-1>; } GroupContextExtensions; " </del> <ins> "struct { Extension extensions<V>; } GroupContextExtensions; " </ins> A member of the group applies a GroupContextExtensions proposal with the following steps:


Verify that the signature on the KeyPackage is valid using the public key in "leaf_node.credential". <ins> Verify that the value of "leaf_node.public_key" is different from the value of the "init_key" field. </ins> 11.2. Within MLS, a KeyPackage is identified by its hash (see, e.g.,


Given these inputs, the derivation of secrets for an epoch proceeds as shown in the following diagram: <del> A number of secrets are derived from the epoch secret for different </del> <ins> A number of values are derived from the epoch secret for different </ins> purposes: <del> The "external secret" is used to derive an HPKE key pair whose </del> <ins> (In general, we use "secret" to refer to a value that is used derive further secret values, and "key" to refer to a value that is used with an algorithm such as HMAC or an AEAD algorithm.) The "external_secret" is used to derive an HPKE key pair whose </ins> private key is held by the entire group: The public key "external_pub" can be published as part of the


GroupSecrets object with the "psks" field set, the receiving Client includes them in the key schedule in the order listed in the Commit, or in the "psks" field respectively.  For resumption PSKs, the PSK is <del> defined as the "resumption_secret" of the group and epoch specified in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows: </del> <ins> defined as the "resumption_psk" of the group and epoch specified in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows: </ins> Here "0" represents the all-zero vector of length "KDF.Nh".  The "index" field in "PSKLabel" corresponds to the index of the PSK in


9.6. <del> The main MLS key schedule provides a "resumption_secret" that is used as a PSK to inject entropy from one epoch into another.  This </del> <ins> The main MLS key schedule provides a "resumption_psk" that is used as a PSK to inject entropy from one epoch into another.  This </ins> functionality is used in the reinitialization and branching processes described in reinitialization and sub-group-branching, but may be used by applications for other purposes. Some uses of resumption PSKs might call for the use of PSKs from historical epochs.  The application SHOULD specify an upper limit on <del> the number of past epochs for which the "resumption_secret" may be </del> <ins> the number of past epochs for which the "resumption_psk" may be </ins> stored. 9.7. <del> The main MLS key schedule provides a per-epoch "authentication_secret".  If one of the parties is being actively impersonated by an attacker, their "authentication_secret" will differ from that of the other group members.  Thus, members of a group MAY use their "authentication_secrets" within an out-of-band authentication protocol to ensure that they share the same view of the group. </del> <ins> The main MLS key schedule provides a per-epoch "authentication_code". If one of the parties is being actively impersonated by an attacker, their "authentication_code" will differ from that of the other group members.  Thus, members of a group MAY verify out of band that their "authentication_code" values are all the same, in order to ensure that they share the same view of the group. </ins> 10.


The ciphertext content is encoded using the MLSCiphertextContent structure. <ins> The "padding" field is set by the sender, by first encoding the content (via the "select") and the "auth" field, then appending the chosen number of zero bytes.  A receiver identifies the padding field in a plaintext decoded from "MLSCiphertext.ciphertext" by first decoding the content and the "auth" field; then the "padding" field comprises any remaining octets of plaintext.  The "padding" field MUST be filled with all zero bytes.  A receiver MUST verify that there are no non-zero bytes in the "padding" field, and if this check fails, the enclosing MLSCiphertext MUST be rejected as malformed. </ins> In the MLS key schedule, the sender creates two distinct key ratchets for handshake and application messages for each member of the group. When encrypting a message, the sender looks at the ratchets it


The key and nonce provided to the AEAD are computed as the KDF of the first "KDF.Nh" bytes of the ciphertext generated in the previous section.  If the length of the ciphertext is less than "KDF.Nh", the <del> whole ciphertext is used without padding.  In pseudocode, the key and nonce are derived as: </del> <ins> whole ciphertext is used.  In pseudocode, the key and nonce are derived as: </ins> The Additional Authenticated Data (AAD) for the SenderData ciphertext is the first three fields of MLSCiphertext:


find out the plaintext by correlation between the question and the length. <del> The content and length of the "padding" field in "MLSCiphertextContent" can be chosen at the time of message encryption by the sender.  It is recommended that padding data is comprised of zero-valued bytes and follows an established deterministic padding scheme. </del> <ins> The length of the "padding" field in "MLSCiphertextContent" can be chosen at the time of message encryption by the sender.  Senders may use padding to reduce the ability of attackers outside the group to infer the size of the encrypted content. </ins> 16.2.


13.1.7. <del> An AppAck proposal is used to acknowledge receipt of application messages.  Though this information implies no change to the group, it is structured as a Proposal message so that it is included in the group's transcript by being included in Commit messages. An AppAck proposal represents a set of messages received by the sender in the current epoch.  Messages are represented by the "sender" and "generation" values in the MLSCiphertext for the message.  Each MessageRange represents receipt of a span of messages whose "generation" values form a continuous range from "first_generation" to "last_generation", inclusive. AppAck proposals are sent as a guard against the Delivery Service dropping application messages.  The sequential nature of the "generation" field provides a degree of loss detection, since gaps in the "generation" sequence indicate dropped messages.  AppAck completes this story by addressing the scenario where the Delivery Service drops all messages after a certain point, so that a later generation is never observed.  Obviously, there is a risk that AppAck messages could be suppressed as well, but their inclusion in the transcript means that if they are suppressed then the group cannot advance at all. The schedule on which sending AppAck proposals are sent is up to the application, and determines which cases of loss/suppression are detected.  For example: The application might have the committer include an AppAck proposal whenever a Commit is sent, so that other members could know when one of their messages did not reach the committer. The application could have a client send an AppAck whenever an application message is sent, covering all messages received since its last AppAck.  This would provide a complete view of any losses experienced by active members. The application could simply have clients send AppAck proposals on a timer, so that all participants' state would be known. An application using AppAck proposals to guard against loss/ suppression of application messages also needs to ensure that AppAck messages and the Commits that reference them are not dropped.  One way to do this is to always encrypt Proposal and Commit messages, to make it more difficult for the Delivery Service to recognize which messages contain AppAcks.  The application can also have clients enforce an AppAck schedule, reporting loss if an AppAck is not received at the expected time. 13.1.8. </del> A GroupContextExtensions proposal is used to update the list of extensions in the GroupContext for the group.


confirmation_tag by way of the key schedule will confirm that all members of the group agree on the extensions in use. <del> 13.1.9. </del> <ins> 13.1.8. </ins> Add and Remove proposals can be constructed and sent to the group by a party that is outside the group.  For example, a Delivery Service


the sender will not have the keys necessary to construct an MLSCiphertext object. <del> 13.1.9.1. </del> <ins> 13.1.8.1. </ins> The "external_senders" extension is a group context extension that contains credentials of senders that are permitted to send external


"psk" <del> "app_ack" </del> "reinit" New proposal types MUST state whether they require a path.  If any


For a KeyPackageRef, the "value" input is the encoded KeyPackage, and the ciphersuite specified in the KeyPackage determines the KDF used. <del> For a LeafNodeRef, the "value" input is the LeafNode object for the leaf node in question.  For a ProposalRef, the "value" input is the MLSMessageContentAuth carrying the proposal.  In the latter two cases, the KDF is determined by the group's ciphersuite. </del> <ins> For a ProposalRef, the "value" input is the MLSMessageContentAuth carrying the proposal.  In the latter two cases, the KDF is determined by the group's ciphersuite. </ins> 6.3.


clients using some identifier.  MLS clients have a few types of identifiers, with different operational properties. <del> The Credentials presented by the clients in a group authenticate application-level identifiers for the clients.  These identifiers may not uniquely identify clients.  For example, if a user has multiple devices that are all present in an MLS group, then those devices' clients could all present the user's application-layer identifiers. </del> Internally to the protocol, group members are uniquely identified by <del> their leaves, expressed as LeafNodeRef objects.  These identifiers are unstable: They change whenever the member sends a Commit, or whenever an Update proposal from the member is committed. MLS provides two unique client identifiers that are stable across epochs: </del> <ins> their leaf index.  However, a leaf index is only valid for referring to members in a given epoch.  The same leaf index may represent a different member, or no member at all, in a subsequent epoch. </ins> <del> The index of a client among the leaves of the tree The "epoch_id" field in the key package The application may also provide application-specific unique identifiers in the "extensions" field of KeyPackage or LeafNode </del> <ins> The Credentials presented by the clients in a group authenticate application-level identifiers for the clients.  However, these identifiers may not uniquely identify clients.  For example, if a user has multiple devices that are all present in an MLS group, then those devices' clients could all present the user's application-layer identifiers. If needed, applications may add application-specific unique identifiers to the "extensions" field of KeyPackage or LeafNode </ins> objects. 7.


signature key depending on the sender's "sender_type": "member": The signature key contained in the Credential at the <del> leaf with the sender's "LeafNodeRef" </del> <ins> index indicated by "leaf_index" in the ratchet tree. </ins> "external": The signature key contained in the Credential at the <del> index indicated by the "sender_index" in the "external_senders" group context extension (see Section external-senders-extension). In this case, the "content_type" of the message MUST NOT be "commit", since only members of the group or new joiners can send Commit messages. </del> <ins> index indicated by "sender_index" in the "external_senders" group context extension (see Section external-senders-extension).  In this case, the "content_type" of the message MUST NOT be "commit", since only members of the group or new joiners can send Commit messages. </ins> "new_member": The signature key depends on the "content_type":


content.  Before being encrypted, the sender data is encoded as an object of the following form: <del> MLSSenderData.sender is assumed to be a "member" sender type.  When constructing an MLSSenderData from a Sender object, the sender MUST verify Sender.sender_type is "member" and use Sender.sender for MLSSenderData.sender. </del> <ins> When constructing an MLSSenderData from a Sender object, the sender MUST verify Sender.sender_type is "member" and use Sender.leaf_index for MLSSenderData.leaf_index. </ins> The "reuse_guard" field contains a fresh random value used to avoid nonce reuse in the case of state loss or corruption, as described in


is the first three fields of MLSCiphertext: When parsing a SenderData struct as part of message decryption, the <del> recipient MUST verify that the LeafNodeRef indicated in the "sender" field identifies a member of the group. </del> <ins> recipient MUST verify that the leaf index indicated in the "leaf_index" field identifies a non-blank node. </ins> 8.


13.1.3. <del> A Remove proposal requests that the member with LeafNodeRef "removed" be removed from the group. </del> <ins> A Remove proposal requests that the member with the leaf index "removed" be removed from the group. </ins> A member of the group applies a Remove message by taking the following steps:


local group state. New members MUST verify the "signature" using the public key taken <del> from the credential in the leaf node of the member with LeafNodeRef "signer".  The signature covers the following structure, comprising all the fields in the GroupInfo above "signature": </del> <ins> from the credential in the leaf node of the ratchet tree with leaf index "signer".  The signature covers the following structure, comprising all the fields in the GroupInfo above "signature": </ins> 13.2.3.1.


Verify the signature on the GroupInfo object.  The signature input comprises all of the fields in the GroupInfo object except the signature field.  The public key and algorithm are taken from the <del> credential in the leaf node of the member with LeafNodeRef "signer".  If there is no matching leaf node, or if signature verification fails, return an error. </del> <ins> credential in the leaf node of the ratchet tree with leaf index "signer".  If the node is blank or if signature verification fails, return an error. </ins> Verify the integrity of the ratchet tree.


If the "path_secret" value is set in the GroupSecrets object: Identify the lowest common ancestor of the leaf node "my_leaf" <del> and of the node of the member with LeafNodeRef </del> <ins> and of the node of the member with leaf index </ins> "GroupInfo.signer".  Set the private key for this node to the private key derived from the "path_secret".


Transmit the Welcome message to the other new members <ins> Group IDs SHOULD be constructed in such a way that there's an overwhelmingly low probability of honest group creators generating the same group ID, even without assistance from the Delivery Service. For example, by making the group ID a freshly generated random value of size "KDF.Nh".  The Delivery Service MAY attempt to ensure that group IDs are globally unique by rejecting the creation of new groups with a previously used ID. </ins> The recipient of a Welcome message processes it as described in joining-via-welcome-message.  If application context informs the recipient that the Welcome should reflect the creation of a new group


In both cases, the new members need information to bootstrap their local group state. <del> New members MUST verify the "signature" using the public key taken from the credential in the leaf node of the ratchet tree with leaf index "signer".  The signature covers the following structure, comprising all the fields in the GroupInfo above "signature": </del> <ins> New members MUST verify that "group_id" is unique among the groups they're currently participating in. New members also MUST verify the "signature" using the public key taken from the leaf node of the ratchet tree with leaf index "signer".  The signature covers the following structure, comprising all the fields in the GroupInfo above "signature": </ins> 13.2.3.1.


"signer".  If the node is blank or if signature verification fails, return an error. <ins> Verify that the "group_id" is unique among the groups that the client is currently participating in. </ins> Verify the integrity of the ratchet tree. Verify that the tree hash of the ratchet tree matches the


identical to the "signature_key" in the LeafNode containing this credential. <del> Each new credential that has not already been validated by the application MUST be validated against the Authentication Service. Applications SHOULD require that a client present the same set of identifiers throughout its presence in the group, even if its Credential is changed in a Commit or Update.  If an application allows clients to change identifiers over time, then each time the client presents a new credential, the application MUST verify that the set of identifiers in the credential is acceptable to the application for this client. </del> 6.3.1. <ins> The application using MLS is responsible for specifying which identifiers it finds acceptable for each member in a group.  In other words, following the model that RFC6125 describes for TLS, the application maintains a list of "reference identifiers" for the members of a group, and the credentials provide "presented identifiers".  A member of a group is authenticated by first validating that the member's credential legitimately represents some presented identifiers, and then ensuring that the reference identifiers for the member are authenticated by those presented identifiers. The parts of the system that perform these functions are collectively referred to as the Authentication Service (AS) I-D.ietf-mls- architecture.  A member's credential is said to be _validated with the AS_ when the AS verifies the credential's presented identifiers, and verifies that those identifiers match the reference identifiers for the member. Whenever a new credential is introduced in the group, it MUST be validated with the AS.  In particular, at the following events in the protocol: When a member receives a KeyPackage that it will use in an Add proposal to add a new member to the group. When a member receives a GroupInfo object that it will use to join a group, either via a Welcome or via an External Commit When a member receives an Add proposal adding a member to the group. When a member receives an Update proposal whose LeafNode has a new credential for the member. When a member receives a Commit with an UpdatePath whose LeafNode has a new credential for the committer. When an "external_senders" extension is added to the group, or an existing "external_senders" extension is updated. In cases where a member's credential is being replaced, such as Update and Commit cases above, the AS MUST also verify that the set of presented identifiers in the new credential is valid as a successor to the set of presented identifiers in the old credential, according to the application's policy. 6.3.2. </ins> MLS implementations will presumably provide applications with a way to request protocol operations with regard to other clients (e.g., removing clients).  Such functions will need to refer to the other


The client verifies the validity of a LeafNode using the following steps: <del> Verify that the credential in the LeafNode is valid according to the authentication service and the client's local policy.  These actions MUST be the same regardless of at what point in the protocol the LeafNode is being verified with the following exception: If the LeafNode is an update to another LeafNode, the authentication service MUST additionally validate that the set of identities attested by the credential in the new LeafNode is acceptable relative to the identities attested by the old credential.  For example: An Update proposal updates the sender's old LeafNode to a new one A "resync" external commit removes the joiner's old LeafNode via a Remove proposal and replaces it with a new one </del> <ins> Verify that the credential in the LeafNode is valid as described in credential-validation. </ins> Verify that the signature on the LeafNode is valid using "signature_key".


17.6. This document registers the "message/mls" MIME media type in order to <del> allow other protocols (ex: HTTP RFC7540) to convey MLS messages. </del> <ins> allow other protocols (e.g., HTTP RFC7540) to convey MLS messages. </ins> message


for key exchange, AES-128-GCM for HPKE, HKDF over SHA2-256, and Ed25519 for signatures. <del> Values with the first byte 255 (decimal) are reserved for Private Use. </del> New ciphersuite values are assigned by IANA as described in iana- considerations.


produces a single ciphertext output from AEAD encryption (aligning with RFC5116), as opposed to a separate ciphertext and tag. <del> Ciphersuites are represented with the CipherSuite type.  HPKE public keys are opaque values in a format defined by the underlying protocol (see the Cryptographic Dependencies section of the HPKE specification for more information). </del> <ins> Ciphersuites are represented with the CipherSuite type.  The ciphersuites are defined in mls-ciphersuites. </ins> <del> The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for signatures in FramedContentAuthData and the tree signatures.  It MUST be the same as the signature algorithm specified in the credentials in the leaves of the tree (including the leaf node information in KeyPackages used to add new members). </del> <ins> 5.1.1. </ins> <del> Like HPKE public keys, signature public keys are represented as opaque values in a format defined by the ciphersuite's signature scheme. </del> <ins> HPKE public keys are opaque values in a format defined by the underlying protocol (see the Cryptographic Dependencies section of the HPKE specification for more information). Signature public keys are likewise represented as opaque values in a format defined by the ciphersuite's signature scheme. </ins> For ciphersuites using Ed25519 or Ed448 signature schemes, the public key is in the format specified in RFC8032.  For ciphersuites using


is represented as an encoded UncompressedPointRepresentation struct, as defined in RFC8446. <ins> 5.1.2. The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for signatures in FramedContentAuthData and the tree signatures.  It MUST be the same as the signature algorithm specified in the credentials in the leaves of the tree (including the leaf node information in KeyPackages used to add new members). </ins> The signatures used in this document are encoded as specified in RFC8446.  In particular, ECDSA signatures are DER-encoded and EdDSA signatures are defined as the concatenation of "r" and "s" as


construction, using a distinct label.  To avoid collisions in these labels, an IANA registry is defined in mls-signature-labels. <del> The ciphersuites are defined in section mls-ciphersuites. </del> <ins> 5.1.3. As with signing, MLS includes a label and context in encryption operations to avoid confusion between ciphertexts produced for different purposes.  Encryption and decryption including this label and context are done as follows: Where EncryptContext is specified as: And its fields set to: Here, the functions "SealBase" and "OpenBase" are defined RFC9180, using the HPKE algorithms specified by the group's ciphersuite.  If MLS extensions require HPKE encryption operations, they should re-use the EncryptWithLabel construction, using a distinct label.  To avoid collisions in these labels, an IANA registry is defined in mls- public-key-encryption-labels. </ins> 5.2.


new leaf nodes), with each ciphertext being the encryption to the respective resolution node. <del> The HPKECiphertext values are computed as where "node_public_key" is the public key of the node that the path secret is being encrypted for, group_context is the provisional GroupContext object for the group, and the functions "SetupBaseS" and "Seal" are defined according to RFC9180. </del> <ins> The HPKECiphertext values are encrypted and decrypted as follows: </ins> <del> Decryption is performed in the corresponding way, using the private key of the resolution node. </del> <ins> Here "node_public_key" is the public key of the node for which the path secret is encrypted, "group_context" is the provisional GroupContext object for the group, and the "EncryptWithLabel" function is as defined in public-key-encryption. </ins> 7.7.


match the one in the Welcome message, return an error. Decrypt the "encrypted_group_secrets" value with the algorithms <del> indicated by the ciphersuite and the private key corresponding to "init_key" in the referenced KeyPackage. </del> <ins> indicated by the ciphersuite and the private key "init_key_priv" corresponding to "init_key" in the referenced KeyPackage. </ins> If a "PreSharedKeyID" is part of the GroupSecrets and the client is not in possession of the corresponding PSK, return an error.


MLS Signature Labels (mls-signature-labels) <ins> MLS Public Key Encryption Labels (mls-public-key-encryption- labels) </ins> MLS Exporter Labels (mls-exporter-labels) All of these registries should be under a heading of "Messaging Layer


17.6. <del> 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. </del> <ins> The "SignWithLabel" function defined in signing avoids the risk of confusion between signatures in different contexts.  Each context is assigned a distinct label that is incorporated into the signature. </ins> 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.


17.7. <ins> The "EncryptWithLabel" function defined in public-key-encryption avoids the risk of confusion between ciphertexts produced for different purposes 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 public-key encryption using the same HPKE keys used elsewhere in MLS. Template: Label: The string to be used as the "Label" parameter to "EncryptWithLabel" Recommended: Same as in Reference: The document where this credential is defined Initial contents: 17.8. </ins> 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


by applications, not the core protocol.  The table below is intended only to show the column layout of the registry. <del> 17.8. </del> <ins> 17.9. </ins> Specification Required RFC8126 registry requests are registered after a three-week review period on the MLS DEs' mailing list: mls-reg-


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> 17.9. </del> <ins> 17.10. </ins> This document registers the "message/mls" MIME media type in order to allow other protocols (e.g., HTTP RFC7540) to convey MLS messages.


that the epoch secret is confidential to the members in the current epoch. <del> For each Commit that adds one or more members to the group, there is a single corresponding Welcome message.  The Welcome message provides all the new members with the information they need to initialize </del> <ins> For each Commit that adds one or more members to the group, there are one or more corresponding Welcome messages.  Each Welcome message provides new members with the information they need to initialize </ins> their views of the key schedule and ratchet tree, so that these views align with the views held by other members of the group in this epoch.


additional information.  The format of the encoded identity is defined by the application. <del> For an X.509 credential, each entry in the chain represents a single DER-encoded X.509 certificate.  The chain is ordered such that the first entry (chain[0]) is the end-entity certificate and each subsequent certificate in the chain MUST be the issuer of the previous certificate.  The public key encoded in the "subjectPublicKeyInfo" of the end-entity certificate MUST be identical to the "signature_key" in the LeafNode containing this credential. </del> <ins> For an X.509 credential, each entry in the "certificates" field represents a single DER-encoded X.509 certificate.  The chain is ordered such that the first entry (chain[0]) is the end-entity certificate.  The public key encoded in the "subjectPublicKeyInfo" of the end-entity certificate MUST be identical to the "signature_key" in the LeafNode containing this credential.  A chain MAY omit any non-leaf certificates that supported peers are known to already possess. </ins> 5.3.1.


on multiple already existing media types. Applications using the application/multipart-core Content-Format <del> define the internal structure of the application/multipart-core representation. </del> <ins> define the semantics as well as the internal structure of the application/multipart-core representation according to the syntax described by the CDDL in mct-cddl. </ins> For example, one way to structure the sub-types specific to an application/multipart-core container is to always include them at the