SlimMLS

5.1. SlimLeafNode

SlimLeafNode replaces LeafNode. SlimLeafNodeTBS replaces the LeafNodeTBS input defined in Section 7.2 of [RFC9420].¶

SlimMLS uses the app_data_dictionary extension specified in Section 7.2.1 of [I-D.ietf-mls-extensions] to carry SlimMLS-specific components in a SlimLeafNode's extensions field.¶

struct {
  opaque sibling_hash<V>;
} SlimKeyPackageMerkleProofNode;

struct {
  uint32                         leaf_index;
  uint32                         tree_size;
  SlimKeyPackageMerkleProofNode  path<V>;
} SlimKeyPackageMerkleProof;

struct {
  HPKEPublicKeyRef      encryption_key_ref;
  SignaturePublicKeyRef signature_key_ref;
  CredentialRef         credential_ref;
  Capabilities          capabilities;

  LeafNodeSource leaf_node_source;
  select (SlimLeafNodeTBS.leaf_node_source) {
    case key_package:
      Lifetime lifetime;

    case update:
      struct{};

    case commit:
      opaque parent_hash<V>;
  };

  Extension extensions<V>;

  select (SlimLeafNodeTBS.leaf_node_source) {
    case key_package:
      struct{};

    case update:
      opaque group_id<V>;
      uint32 leaf_index;

    case commit:
      opaque group_id<V>;
      uint32 leaf_index;
  };
} SlimLeafNodeTBS;

struct {
  HPKEPublicKeyRef      encryption_key_ref;
  SignaturePublicKeyRef signature_key_ref;
  CredentialRef         credential_ref;
  Capabilities          capabilities;

  LeafNodeSource leaf_node_source;
  select (SlimLeafNode.leaf_node_source) {
    case key_package:
      Lifetime lifetime;

    case update:
      struct{};

    case commit:
      opaque parent_hash<V>;
  };

  Extension extensions<V>;

  /*
    For key_package leaves, this is a SignatureRef to the batch signature.
    For update and commit leaves, this is a SignatureRef to the normal
    SlimLeafNode signature over SlimLeafNodeTBS.
  */
  SignatureRef signature;

  select (SlimLeafNode.leaf_node_source) {
    case key_package:
      SlimKeyPackageMerkleProof proof;

    case update:
      struct{};

    case commit:
      struct{};
  };
} SlimLeafNode;

The proof field is present only when leaf_node_source = key_package. It is not part of SlimLeafNodeTBS to avoid a circulare dependency. Update and commit leaf nodes do not carry this field.¶

For leaf_node_source = key_package, the signature field references the SlimKeyPackage batch signature and validation MUST verify both this signature and the embedded proof as described in Section 7.1. This allows clients to validate a key-package SlimLeafNode even when it appears in a ratchet tree without the enclosing SlimKeyPackage. For leaf nodes whose source is update or commit, the signature field is the normal SlimLeafNode signature over SlimLeafNodeTBS, verified as in Section 7.3 of [RFC9420] after applying the slim substitutions in this document.¶

5.2. SlimParentNode and SlimParentHashInput

The following slim tree structures are used in tree-hash and parent-hash computations:¶

struct {
  HPKEPublicKeyRef encryption_key_ref;
  opaque           parent_hash<V>;
  uint32           unmerged_leaves<V>;
} SlimParentNode;

struct {
  HPKEPublicKeyRef encryption_key_ref;
  opaque           parent_hash<V>;
  opaque           original_sibling_tree_hash<V>;
} SlimParentHashInput;

SlimParentNode replaces ParentNode. SlimParentHashInput replaces the ParentHashInput defined in Section 7.9 of [RFC9420].¶

5.3. SlimGroupInfo

SlimGroupInfo is the slim replacement for the [RFC9420] GroupInfo struct. It uses the same fields and verification rules as GroupInfo, except that GroupInfo extensions use SlimMLS replacements and the signature is represented as SignatureOrRef.¶

struct {
  GroupContext group_context;
  Extension extensions<V>;
  MAC confirmation_tag;
  uint32 signer;
} SlimGroupInfoTBS;

struct {
  GroupContext group_context;
  Extension extensions<V>;
  MAC confirmation_tag;
  uint32 signer;

  /*
    SignWithLabel(., "GroupInfoTBS", SlimGroupInfoTBS)
  */
  SignatureOrRef signature;
} SlimGroupInfo;

The signature is computed and verified as in [RFC9420], except that the to-be-signed content is SlimGroupInfoTBS. A standalone SlimGroupInfo, or a SlimGroupInfo carried in WelcomeGroupInfo.info_type = plaintext, MUST use signature_type = signature_ref. A SlimGroupInfo encrypted into WelcomeGroupInfo.info_type = encrypted MUST use signature_type = signature so that the raw signature is protected by the SlimWelcome encryption.¶

6.1. Large Object Carrier

A client sending a SlimMLS struct over the wire MAY also send a LargeObjectCarrier struct that contains a subset of the large objects referenced by the SlimMLS struct or by an associated structure such as SlimUpdatePath (Section 9).¶

This document does not define a single MLSMessage wrapper for LargeObjectCarrier. When a carrier is sent on the wire, its encoding, multiplexing, and association with the SlimMLS message are provided by the application or DS protocol using SlimMLS.¶

For each large-object reference type that appears in a slim structure or an associated structure, the LargeObjectCarrier contains a vector of the corresponding large objects:¶

struct {
  HPKEPublicKey      hpke_public_keys<V>;
  SignaturePublicKey signature_public_keys<V>;
  Credential         credentials<V>;
  HPKECiphertext     hpke_ciphertexts<V>;
  Signature          signatures<V>;
} LargeObjectCarrier;

The carrier is NOT part of the signed structure. The DS MAY add, remove, reorder, or substitute entries on a per-recipient basis, e.g., to omit objects the recipient already has cached, or to distribute SlimUpdatePath ciphertexts (see Section 9). The LargeObjectCarrier is optional in the SlimMLS wire protocol. The DS MAY reject a message based on a missing LargeObjectCarrier, or on a LargeObjectCarrier that is missing the large objects that clients will need to process a message, if its local deployment policy requires senders to provide those objects proactively.¶

7.1. KeyPackage Batch Merkle Tree

The Merkle tree for a SlimKeyPackage batch is computed under the hash function of the SlimKeyPackage ciphersuite. A batch MUST contain at least one leaf. All SlimKeyPackages in a batch MUST have the same version, cipher_suite, and signature_key_ref.¶

The leaf hash for a SlimLeafNodeTBS is computed over the TLS-encoded SlimLeafNodeTBS:¶

HashWithLabel("SlimKeyPackageLeaf", SlimLeafNodeTBS)

The parent hash for two child hashes is computed over their TLS-encoded ordered pair:¶

struct {
  opaque left<V>;
  opaque right<V>;
} SlimKeyPackageMerkleParentInput;

HashWithLabel("SlimKeyPackageNode", SlimKeyPackageMerkleParentInput)

The tree is built bottom-up from the ordered list of leaf hashes. At each level, adjacent nodes are paired from left to right. If the final node at a level has no sibling, it is promoted unchanged to the next level. The single node remaining after this process is the Merkle root.¶

The path entries in SlimKeyPackageMerkleProof are ordered from the leaf level toward the root. To verify a proof, a recipient starts with the leaf hash of leaf_node_tbs, leaf_index, and tree_size. At each level, if the current level width is odd and the current index is width - 1, the current hash is promoted unchanged and no path entry is consumed. Otherwise, the next path entry is consumed as the sibling hash and the parent hash is computed with the sibling on the left when the current index is odd, and on the right when the current index is even. The index is then divided by two, rounding down, and the level width is divided by two, rounding up. A proof is valid only if tree_size is nonzero, leaf_index < tree_size, all path entries are consumed, and the final computed hash is the Merkle root.¶

The batch signature is computed over:¶

SignWithLabel(., "SlimKeyPackageBatchTBS", SlimKeyPackageBatchTBS)

where version and cipher_suite are taken from outer_key_package, signature_key_ref is taken from leaf_node_tbs, tree_size is taken from the proof in leaf_node, and merkle_root is the Merkle root computed as above.¶

7.2. OuterKeyPackageHash component

struct {
  opaque outer_key_package_hash<V>;
} OuterKeyPackageHash;

outer_key_package_hash is the hash, under the SlimKeyPackage's ciphersuite hash function, of the TLS-encoded outer_key_package of the SlimKeyPackage in which the SlimLeafNode appears.¶

An OuterKeyPackageHash is valid only if the SlimLeafNode's leaf_node_source is key_package and outer_key_package_hash equals the hash of the enclosing SlimKeyPackage's outer_key_package.¶

The app_data_dictionary extension MUST contain exactly one OuterKeyPackageHash component under component identifier TBD. A missing, malformed, or duplicated OuterKeyPackageHash component makes the enclosing SlimKeyPackage invalid.¶

7.3. Creation and Processing

A sender constructs a SlimKeyPackage as follows:¶

1. Construct an OuterSlimKeyPackage with the desired version, cipher_suite, HPKEPublicKeyRef for the init key, and extensions.¶

2. Construct a SlimLeafNodeTBS with leaf_node_source = key_package. Add an app_data_dictionary extension containing an OuterKeyPackageHash whose value is the hash of the OuterSlimKeyPackage from step 1.¶

3. Construct all other SlimLeafNodeTBS values in the batch in the same way.¶

4. Build the KeyPackage batch Merkle tree over the SlimLeafNodeTBS values.¶

5. Construct a SlimKeyPackageBatchTBS for the root, sign it with the signature private key corresponding to signature_key_ref, and compute the SignatureRef over the raw signature bytes.¶

6. Emit each SlimKeyPackage with the common SignatureRef in leaf_node.signature and the leaf's inclusion proof in leaf_node.proof, optionally accompanied by a LargeObjectCarrier holding the referenced HPKEPublicKey and the large objects referenced by the SlimLeafNode and the batch signature bytes.¶

A recipient processes a SlimKeyPackage like a KeyPackage with the following exceptions:¶

• There is no outer signature to verify.¶

• There is no per-package LeafNode signature to verify.¶

• The SlimLeafNode MUST contain an app_data_dictionary extension with a valid OuterKeyPackageHash component.¶

• The SlimLeafNode MUST have leaf_node_source = key_package and therefore carry a proof field.¶

• The recipient resolves the batch signature bytes using leaf_node.signature, computes SignatureRef over those bytes, and verifies that it equals leaf_node.signature.¶

• The recipient verifies the Merkle inclusion proof in leaf_node.proof, reconstructs the SlimKeyPackageBatchTBS, resolves the SignaturePublicKey corresponding to signature_key_ref, and verifies the raw batch signature bytes identified by leaf_node.signature using VerifyWithLabel label "SlimKeyPackageBatchTBS".¶

• All large-object *Ref values are resolved per Section 6.¶

8.1. Sender and DS Behavior

The sender MUST construct SlimWelcome.secrets to contain one SlimEncryptedGroupSecrets for every recipient it intends to add, in the same order it would use under [RFC9420].¶

The DS MAY remove entries from SlimWelcome.secrets on a per-recipient basis, e.g., to deliver to each recipient only its own entry.¶

If the sender omits the group_info field (presence octet 0), the DS MUST populate it with a plaintext WelcomeGroupInfo before delivering the SlimWelcome to a recipient (Section 8.3). In this mode, the GroupInfo used by the sender to encrypt the SlimEncryptedGroupSecrets and the GroupInfo populated by the DS MUST be byte-for-byte identical SlimGroupInfo objects.¶

A DS that supplies large objects alongside a SlimWelcome can distinguish between basic-processing delivery and update-capable delivery. Basic-processing delivery contains the large objects needed for the recipient to validate the SlimWelcome, derive the epoch secrets, receive subsequent MLS messages, and send application messages. It can omit HPKE public keys that are only needed to construct a future Commit with an update path. Update-capable delivery additionally includes enough HPKE public keys for the recipient to construct an update path without a later fetch, such as the HPKE public keys for the recipient's copath resolution in the delivered tree. A recipient that has only basic-processing state MUST resolve the missing HPKEPublicKeyRefs before sending a Commit with an update path.¶

8.2. SlimEncryptedGroupSecrets

SlimEncryptedGroupSecrets extends the [RFC9420] EncryptedGroupSecrets to allow either of two recipient identifiers:¶

enum {
  reserved(0),
  slim_key_package_ref(1),
  leaf_node_index(2),
  (255)
} RecipientIdentifierType;

struct {
  RecipientIdentifierType recipient_type;
  select (SlimEncryptedGroupSecrets.recipient_type) {
    case slim_key_package_ref:
      SlimKeyPackageRef new_member;
    case leaf_node_index:
      uint32 leaf_node_index;
  };
  HPKECiphertext encrypted_group_secrets;
} SlimEncryptedGroupSecrets;

A recipient locates the entry intended for it by matching either its own SlimKeyPackageRef or its leaf in the group's ratchet tree via the leaf index.¶

The leaf_node_index recipient type MUST be used only when the SlimEncryptedGroupSecrets is encrypted using a plaintext SlimGroupInfo as context and the delivered SlimWelcome carries WelcomeGroupInfo.info_type = plaintext. Otherwise, the sender MUST use slim_key_package_ref.¶

8.3. WelcomeGroupInfo

WelcomeGroupInfo is a tagged union over two presentations of the SlimGroupInfo: an encrypted form or a plaintext form:¶

enum {
  reserved(0),
  encrypted(1),
  plaintext(2),
  (255)
} WelcomeGroupInfoType;

struct {
  WelcomeGroupInfoType info_type;
  select (WelcomeGroupInfo.info_type) {
    case encrypted:
      opaque encrypted_group_info<V>;
    case plaintext:
      SlimGroupInfo group_info;
  };
} WelcomeGroupInfo;

The encrypted variant is encrypted under a key derived from the joiner secret, as in the encrypted_group_info field of the [RFC9420] Welcome. Its plaintext is a SlimGroupInfo whose SignatureOrRef uses signature_type = signature. A sender MUST NOT encrypt a SlimGroupInfo with signature_type = signature_ref into this field.¶

The plaintext variant carries a SlimGroupInfo in the clear. Its SignatureOrRef MUST use signature_type = signature_ref, which is resolved per Section 6 before signature verification.¶

The HPKE context used to encrypt and decrypt SlimEncryptedGroupSecrets.encrypted_group_secrets depends on the GroupInfo presentation. For the encrypted variant, the context is the encrypted_group_info value, as in [RFC9420]. For the plaintext variant, and for SlimWelcomes sent with group_info absent, the context is the TLS-encoded SlimGroupInfo.¶

The outer optional<WelcomeGroupInfo> in the SlimWelcome additionally allows the sender to omit the GroupInfo. This mode is intended for server-assisted deployments where the sender and recipient can obtain the exact GroupInfo by some channel other than the SlimWelcome.¶

A recipient that receives a SlimWelcome whose group_info field is absent MUST consider the SlimWelcome invalid.¶

9.1. SlimUpdatePath

The path is conveyed separately from the framed SlimCommit:¶

struct {
  HPKEPublicKeyRef  encryption_key_ref;
  HPKECiphertextRef encrypted_path_secret_refs<V>;
} SlimUpdatePathNode;

struct {
  SlimUpdatePathNode nodes<V>;
} SlimUpdatePath;

Each SlimUpdatePathNode carries an HPKEPublicKeyRef for the new ParentNode public key and a vector of HPKECiphertextRefs. In the sender-to-DS SlimUpdatePath, the encrypted_path_secret_refs vector has the same order and cardinality as the encrypted_path_secret vector in the corresponding [RFC9420] UpdatePathNode. In a DS-to-recipient SlimUpdatePath, the DS MAY reduce each encrypted_path_secret_refs vector to the subset the recipient needs. The reduced path MUST contain enough HPKECiphertextRefs for the recipient to decrypt one path secret and derive the remaining path secrets it needs to process the Commit. The corresponding HPKECiphertexts, and any HPKEPublicKeys that are functionally needed, are resolved per Section 6.¶

The SlimUpdatePath is not signed. Its HPKEPublicKeyRefs are authenticated by the parent hash in the committer's SlimLeafNode, as in Section 7.9 of [RFC9420], with HPKEPublicKeyRef replacing HPKEPublicKey in the parent-hash computation. Its HPKECiphertextRefs are unauthenticated delivery objects: a recipient validates them by decrypting the referenced HPKECiphertext, deriving the path public keys, checking that the derived public keys hash to the authenticated HPKEPublicKeyRefs, and verifying the Commit confirmation tag.¶

9.2. Slim Framing

In a SlimMLS group, public and private message framing uses dedicated SlimMLS structures. They are the same as [RFC9420] PublicMessage and PrivateMessage, except that:¶

• the framed content carries a SlimCommit or SlimProposal where [RFC9420] carries a Commit or Proposal,¶

• the authentication data is a SlimFramedContentAuthData, and¶

• when the content is a SlimCommit, the unsigned SlimUpdatePath is carried alongside the framed content, outside the authenticated content.¶

SlimProposal is the slim variant of the [RFC9420] Proposal struct obtained by the mechanical-substitution rule of Section 5: an Add proposal carries a SlimKeyPackage and an Update proposal carries a SlimLeafNode. Other proposal variants are unchanged.¶

struct {
  opaque group_id<V>;
  uint64 epoch;
  Sender sender;
  opaque authenticated_data<V>;

  ContentType content_type;
  select (SlimFramedContent.content_type) {
    case application:
      opaque application_data<V>;
    case proposal:
      SlimProposal proposal;
    case commit:
      SlimCommit commit;
  };
} SlimFramedContent;

struct {
  /*
    SignWithLabel(., "FramedContentTBS", SlimFramedContentTBS)
  */
  optional<SignatureOrRef> signature;

  select (SlimFramedContent.content_type) {
    case commit:
      /*
        MAC(confirmation_key,
            GroupContext.confirmed_transcript_hash)
      */
      MAC confirmation_tag;
    case application:
    case proposal:
      struct{};
  };
} SlimFramedContentAuthData;

struct {
  ProtocolVersion    version = mls10;
  WireFormat         wire_format;
  SlimFramedContent  content;
  select (SlimFramedContentTBS.content.sender.sender_type) {
    case member:
    case new_member_commit:
      GroupContext context;
    case external:
    case new_member_proposal:
      struct{};
  };
} SlimFramedContentTBS;

struct {
  WireFormat         wire_format;
  SlimFramedContent  content;
  SlimFramedContentAuthData auth;
} SlimAuthenticatedContent;

struct {
  SlimFramedContent         content;
  SlimFramedContentAuthData auth;
  select (SlimPublicMessage.content.sender.sender_type) {
    case member:
      MAC membership_tag;
    case external:
    case new_member_commit:
    case new_member_proposal:
      struct{};
  };
  select (SlimPublicMessage.content.content_type) {
    case commit:
      optional<SlimUpdatePath> path;
    case application:
    case proposal:
      struct{};
  };
} SlimPublicMessage;

struct {
  select (SlimPrivateMessage.content_type) {
    case application:
      opaque application_data<V>;
    case proposal:
      SlimProposal proposal;
    case commit:
      SlimCommit commit;
  };
  SlimFramedContentAuthData auth;
  opaque                    padding[length_of_padding];
} SlimPrivateMessageContent;

struct {
  opaque group_id<V>;
  uint64 epoch;
  ContentType content_type;
  opaque authenticated_data<V>;
  opaque encrypted_sender_data<V>;
  opaque ciphertext<V>;
  select (SlimPrivateMessage.content_type) {
    case commit:
      optional<SlimUpdatePath> path;
    case application:
    case proposal:
      struct{};
  };
} SlimPrivateMessage;

The optional signature field in SlimFramedContentAuthData MUST be present whenever content_type is application or proposal. For content_type = commit, signature MUST be absent if and only if the single-signature construction of Section 9.4 applies.¶

When present in a SlimPublicMessage, signature MUST use signature_type = signature_ref. When present in a SlimPrivateMessage, signature MUST use signature_type = signature. This ensures that a SlimPrivateMessage framing signature is encrypted as part of SlimPrivateMessageContent.¶

When a framing signature is present, it is computed and verified as in [RFC9420], except that the to-be-signed content is SlimFramedContentTBS and the WireFormat is either mls_slim_public_message or mls_slim_private_message.¶

For SlimPrivateMessage, the ciphertext field encrypts a SlimPrivateMessageContent. The sender data encryption, content encryption, padding, and decryption rules are otherwise the same as for PrivateMessage in [RFC9420].¶

After decrypting a SlimPrivateMessage, the recipient reconstructs the SlimFramedContent from the outer group_id, epoch, content_type, and authenticated_data fields, the decrypted sender, and the decrypted content. The reconstructed SlimFramedContent is used with the decrypted SlimFramedContentAuthData for signature verification and, for commits, for OuterUpdateHash verification, transcript hash computation, and confirmation tag verification.¶

For SlimPublicMessage, the membership tag is computed over the following structure:¶

struct {
  SlimFramedContentTBS       content_tbs;
  SlimFramedContentAuthData  auth;
} SlimAuthenticatedContentTBM;

For commits, the input to the confirmed transcript hash is:¶

struct {
  WireFormat        wire_format;
  SlimFramedContent content;
} SlimConfirmedTranscriptHashInput;

The SlimUpdatePath is not part of SlimFramedContent, SlimAuthenticatedContentTBM, or SlimConfirmedTranscriptHashInput. It is therefore not authenticated by the membership tag, the framing signature, or the transcript hash. In a SlimPrivateMessage carrying a commit, the path is carried outside the ciphertext so the DS can reduce it per recipient.¶

9.3. SlimMessage

SlimMessage is the generic term for the two concrete wire presentations, SlimPublicMessage and SlimPrivateMessage. Both presentations are used for sender-to-DS transport and for DS-to-recipient delivery. For commits, the difference between the two is the cardinality of the HPKECiphertextRef vectors in path.¶

In a SlimMLS group, the [RFC9420] PublicMessage and PrivateMessage wire formats MUST NOT be used. A SlimMLS-aware sender MUST emit a SlimPublicMessage or SlimPrivateMessage in their place.¶

9.4. Single Signature Construction

When a SlimCommit is sent by a member, contains a SlimLeafNode, and the sender's signature key is unchanged, the framing signature is omitted, and authenticity is provided by the SlimLeafNode's own signature in combination with an OuterUpdateHash component placed in the SlimLeafNode's app_data_dictionary extension. The confirmation tag is still present and processed as in [RFC9420].¶

The OuterUpdateHash binds the framed SlimCommit (excluding the SlimLeafNode itself, to avoid a circular dependency) and the GroupContext to the SlimLeafNode:¶

struct {
  opaque outer_update_hash<V>;
} OuterUpdateHash;

struct {
  opaque       group_id<V>;
  uint64       epoch;
  Sender       sender;
  opaque       authenticated_data<V>;
  ContentType  content_type;
  select (OuterFramedContent.content_type) {
    case commit:
      ProposalOrRef proposals<V>;
  };
} OuterFramedContent;

struct {
  ProtocolVersion    version = mls10;
  WireFormat         wire_format;
  OuterFramedContent content;
  GroupContext       context;
} SlimFramedContentTBH;

outer_update_hash is the hash, under the group's ciphersuite hash function, of the TLS-encoded SlimFramedContentTBH. Fields of OuterFramedContent are populated from the SlimCommit being framed. The SlimLeafNode is omitted to prevent the circular dependency that would arise from including the very component being computed.¶

The app_data_dictionary extension MUST contain exactly one OuterUpdateHash component under component identifier TBD. A missing, malformed, or duplicated OuterUpdateHash component makes the single-signature construction invalid.¶

The OuterUpdateHash authenticates the non-path commit contents that the omitted framing signature would otherwise cover. The path's HPKEPublicKeyRefs are authenticated separately by parent hash validation. The path's HPKECiphertextRefs are not authenticated by the signature and do not contribute to the group state. Tampering with them can only cause decryption, derived-key, or confirmation-tag validation to fail.¶

When the construction applies, the SignaturePublicKeyRef in the SlimLeafNode MUST equal the sender's current SignaturePublicKeyRef. A sender that wishes to change its signature key MUST instead emit a SlimCommit whose authentication data carries a framing signature, so that the new key is bound by a signature under the old one.¶

A SlimCommit without a SlimLeafNode (e.g., a commit containing only Add or Remove proposals) does not use this construction. Its authentication data carries a framing signature.¶

A SlimCommit whose sender type is not member does not use this construction. Its authentication data carries a framing signature.¶

9.5. Sender, DS, and Recipient Behavior

A committer constructs a SlimMessage carrying a SlimCommit as follows:¶

1. Perform the steps of an [RFC9420] commit, deriving the path's HPKEPublicKeys, HPKECiphertexts, parent hashes, and the new epoch's key schedule. Parent hashes are computed over the slim parent-hash inputs, with HPKEPublicKeyRef replacing HPKEPublicKey.¶

2. Build a SlimCommit containing the committed proposals and, if the commit contains a path, the committer's new SlimLeafNode. The SlimLeafNode's parent hash MUST authenticate the HPKEPublicKeyRefs in the SlimUpdatePath.¶

3. Compute the confirmation tag for the new epoch as in [RFC9420].¶

4. If the single-signature construction applies, include a valid OuterUpdateHash in the SlimLeafNode and leave the optional signature field absent. If the construction does not apply, include the normal framing signature in SlimFramedContentAuthData, using signature_type = signature_ref for SlimPublicMessage and signature_type = signature for SlimPrivateMessage.¶

5. Build a SlimUpdatePath whose SlimUpdatePathNodes carry the HPKEPublicKeyRefs and HPKECiphertextRefs of the path, and emit a SlimPublicMessage or SlimPrivateMessage, optionally accompanied by a LargeObjectCarrier holding the corresponding HPKEPublicKeys, HPKECiphertexts, and any public-message framing signature referenced by the SignatureOrRef.¶

The DS, knowing the ratchet tree before and after the commit, produces a per-recipient SlimMessage by reducing each SlimUpdatePathNode's HPKECiphertextRef vector to the subset needed by that recipient. The DS MUST retain the HPKEPublicKeyRef in every SlimUpdatePathNode, and MUST retain enough HPKECiphertextRefs for the recipient to decrypt one path secret and derive the remaining path secrets it needs to process the Commit. If a LargeObjectCarrier is present, the DS reduces it accordingly, retaining only any HPKEPublicKeys the recipient must receive and the HPKECiphertexts corresponding to the retained HPKECiphertextRefs. If the commit removes the recipient, path is omitted.¶

For basic-processing delivery of a Commit with an update path, a recipient needs enough ciphertext material to derive the epoch secrets and verify the Commit, but does not necessarily need every HPKE public key referenced by the path. Such a recipient can process the Commit, receive subsequent MLS messages, and send application messages, but might not be able to construct its own Commit with an update path until it resolves additional HPKEPublicKeyRefs. To make the recipient immediately update-capable, the DS MAY include any updated HPKE public keys in the recipient's copath that the recipient cannot derive from its retained path secret. In a full tree with no blank nodes, this is one HPKE public key for each non-committing recipient.¶

A recipient processes a SlimMessage carrying a SlimCommit by:¶

1. Resolving the HPKECiphertextRefs required for the recipient and any HPKEPublicKeyRefs that are functionally needed, per Section 6. For SlimPublicMessage, this also includes any SignatureRef in the SlimFramedContentAuthData SignatureOrRef. For SlimPrivateMessage, the recipient decrypts SlimPrivateMessageContent and uses the inline SignatureOrRef value when one is present.¶

2. If the authentication data contains a framing signature, verifying it per [RFC9420] using SlimFramedContentTBS. If the SignatureOrRef uses signature_type = signature_ref, the recipient first resolves the referenced signature. If it uses signature_type = signature, the recipient uses the inline signature. If the framing signature is absent, verifying the SlimLeafNode signature and OuterUpdateHash per Section 9.4.¶

3. Decrypting the resolved HPKECiphertext, deriving the path public keys, and verifying that the derived public keys hash to the authenticated HPKEPublicKeyRefs.¶

4. Applying the path update and verifying parent hashes over the slim encodings per Section 7.9.2 of [RFC9420].¶

5. Processing the commit per Section 12.4 of [RFC9420], deriving the new epoch, and verifying the confirmation tag. If confirmation tag validation fails, the recipient MUST reject the commit.¶

The input to the confirmed transcript hash is SlimConfirmedTranscriptHashInput (Section 9.2). The interim transcript hash is computed from the confirmed transcript hash and the confirmation tag as in [RFC9420].¶

DSs that do not maintain the ratchet tree cannot perform the per-recipient reduction described above. Strategies for such deployments are out of scope.¶

10.1. Storing Partial Trees

SlimMLS clients need the slim public tree for MLS tree computations, but they do not need to fetch every large object referenced by that tree. Tree hashes, parent hashes, and GroupInfo validation are computed over SlimLeafNode and SlimParentNode encodings, so the references to public keys and credentials are the values committed to by those computations. A client can therefore defer fetching large objects that are not functionally needed, such as HPKE public keys outside the client's copath. This is especially relevant when joining a group, where the DS can selectively include the public keys and credentials the joiner needs immediately.¶

10.2. Omitting Cached Large Objects

If the DS keeps track of the group's public state, clients that send a commit with an update path only need to proactively provide the signature public key and credential if either of them change as part of the commit.¶

10.3. Cross-group Credential Caching

If clients use the same credential across multiple groups, other clients can cache them and pull new credentials selectively when they encounter credential references they can't resolve. Whether this is a performance increase depends on the context of the application.¶

The DS can similarly deduplicate stored credentials.¶

10.4. Delayed Fetching of Large Objects

A client that has been offline for some time can fetch and process slim messages first. It can wait to fetch large objects that are not relevant for processing (such as HPKE public keys) until it has arrived at the current group state. The client thus avoids downloading stale, intermediate large objects.¶

16.1. SlimMLS MLS Extension Types

IANA is requested to add the following entries to the "MLS Extension Types" registry defined in Section 17.3 of [RFC9420]:¶

(Values are SlimMLS's suggested allocations. IANA may pick others.)¶

The "Message(s)" abbreviations are those used in Section 17.3 of [RFC9420]. "GC" denotes a GroupContext extension and "GI" denotes a GroupInfo extension. RFC XXXX is to be replaced with the RFC number assigned to this document upon publication.¶

16.2. SlimMLS Wire Formats

IANA is requested to add the following entries to the "MLS Wire Formats" registry defined in Section 17.2 of [RFC9420]:¶

(Values are SlimMLS's suggested allocations. IANA may pick others.)¶

17.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9420]

Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, July 2023, <https://www.rfc-editor.org/rfc/rfc9420>.

17.2. Informative References

[I-D.ietf-mls-extensions]

Robert, R., "The Messaging Layer Security (MLS) Extensions", Work in Progress, Internet-Draft, draft-ietf-mls-extensions-09, 2 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-mls-extensions-09>.