Fewer signatures in MLS

3.1. Creating a OneSignatureKeyPackage

A OneSignatureKeyPackage is created like a regular KeyPackage with the following exceptions.¶

• The signature around the outer KeyPackage is omitted¶

• An app_data_dictionary extension is added to the LeafNode (if not already present)¶

• An OuterKeyPackageHash component is included in the app_data_dictionary (see Section 3.2)¶

The original purpose of the signature over the KeyPackage is now served by the signature over the LeafNode, which by inclusion of the OuterKeyPackageHash provides authenticity for both the LeafNode itself and the OuterKeyPackage around it.¶

3.2. OuterKeyPackage hash component

struct {
  opaque outer_key_package_hash;
} OuterKeyPackageHash

The OuterKeyPackageHash can be created by hashing the TLS-serialized outer_key_package of a OneSignatureKeyPackage using the hash function of its ciphersuite.¶

A OuterKeyPackageHash is only valid if two conditions are met.¶

• The leaf_node_source of the LeafNode is KeyPackage¶

• If the LeafNode is verified in the context of a OneSignatureKeyPackage, the outer_key_package_hash is the hash of the outer_key_package of that OneSignatureKeyPackage.¶

3.3. Processing a OneSignatureKeyPackage

Recipients of a OneSignatureKeyPackage process is like a regular KeyPackage with two exceptions¶

• There is no signature over the outer KeyPackage to verify¶

• The app_data_dictionary extension in the leaf_node must contain a valid OuterKeyPackageHash as defined in Section 3.2 under the component_id TBD.¶

4.1. Changes in framing

The core change in framing an OSPublicMessage or OSPrivateMessage as compared to its regular counterparts is that the FramedContentAuthData is replaced by the OSFramedContentAuthData, where the latter lacks the signature that is part of the former. Other framing structs are changed as a result in that they contain an OSFramedContentAuthData struct instead of a FramedContentAuthData struct.¶

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

struct {
  WireFormat wire_format;
  FramedContent content;
  OSFramedContentAuthData auth;
} OSAuthenticatedContent;

struct {
  select (PrivateMessage.content_type) {
    case application:
      opaque application_data<V>;

      case proposal:
        Proposal proposal;

      case commit:
        Commit commit;
  };

  OSFramedContentAuthData auth;
  opaque padding[length_of_padding];
} OSPrivateMessageContent;

struct {
  FramedContent content;
  OSFramedContentAuthData auth;
  select (PublicMessage.content.sender.sender_type) {
      case member:
          MAC membership_tag;
      case external:
      case new_member_commit:
      case new_member_proposal:
          struct{};
  };
} OSPublicMessage;

4.2. Changes in membership tag and transcript hash computation

The structs involved in membership tag and transcript hash computation also change slightly.¶

struct {
  FramedContentTBS content_tbs;
  OSFramedContentAuthData auth;
} OSAuthenticatedContentTBM;

For OSPublicMessages, the membership_tag is computed over OSAuthenticatedContentTBM instead of the regular AuthenticatedContentTBM.¶

struct {
  WireFormat wire_format;
  FramedContent content; /* with content_type == commit */
} OSConfirmedTranscriptHashInput;

Due to the changes in framing, the transcript hash for OSPublicMessages and OSPrivateMessages is computed over OSConfirmedTranscriptHashInput instead of the regular ConfirmedTranscriptHash. Since the LeafNode is within FramedContent and its signature covers what the original signature would have covered, this does not affect transcript coverage.¶

4.3. Outer update hash component

The OuterUpdateHash component ensures that the signature over the LeafNode covers whatever the omitted signature would have covered.¶

struct {
  opaque outer_update_hash;
} OuterUpdateHash

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

    ContentType content_type;
    select (FramedContent.content_type) {
      case proposal:
        ProposalType proposal_type;
      case commit:
        ProposalOrRef proposals<V>;
        UpdatePathNode nodes<V>;
      case application:
        struct {};
    };
} OuterFramedContent

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

The outer_update_hash MUST be a hash over the message's TLS-serialized OSFramedContentTBH using the hash function of the group's ciphersuite.¶

OSFramedContentTBH is the same as the FramedContentTBS struct defined in [RFC9420], except that it always contains a GroupContext (because Commits and Update Proposals only have member or new_member_commit as sender_type) and that it contains an OuterFramedContent instead of a regular FramedContent.¶

OuterFramedContent in turn is the same as FramedContent except that, depending on content_type, it either contains only content relevant to a Commit with an UpdatePath or an Update Proposal. For Commits, the proposals MUST be the same as in the message's Commit and the nodes MUST be equal to the nodes in the Commit's UpdatePath. For Update Proposals, the proposal_type MUST be update. The proposal type is the only relevant content, as the Update Proposal otherwise only consists of the (omitted) LeafNode.¶

In both cases, the actual LeafNode is omitted to prevent a circular dependency when computing the outer_update_hash for inclusion in said LeafNode.¶

4.4. Creating an OSPublicMessage or OSPrivateMessage

Clients create an OSPublicMessage or OSPrivateMessage just like their non-OS counterpart with three exceptions:¶

• The signature in FramedContentData is omitted by using OSFramedContentData and the other modified structs introduced in Section 4.1 instead of their non-OS counterparts.¶

• An app_data_dictionary is included in the LeafNode (either in the UpdatePath or the Update Proposal) and within it an OuterUpdateHash component (see Section 4.3).¶

• The membership tag and transcript hash are computed as specified in Section 4.2.¶

4.5. Processing an OSPublicMessage or OSPrivateMessage

OSPublicMessages and OSPrivateMessages are processed like their regular counterparts with the following exceptions.¶

• One of the following MUST be true¶

  • content_type = commit and the Commit contained within MUST have an UpdatePath¶

  • content_type = proposal and proposal_type = update¶

• The signature public key in the LeafNode MUST be the same as the sender's current LeafNode. This MUST also be true for Commits with sender_type = new_member_commit that contain a Remove Proposal targeting the sender's original leaf.¶

• The LeafNode (either in the UpdatePath or in the Update Proposal) MUST contain an app_data_dictionary extension with a valid OuterUpdateHash component as specified in Section 4.3.¶

• Membership tag and transcript hash are computed as specified in Section 4.2.¶

The second check for signature public key equality is necessary to ensure that the authentication properties of one-signature message variants are equivalent to their counterparts defined in RFC9420. Clients that want to change their signature public key MUST use the normal (external) Commits and Update Proposals to ensure that the new signature public key is signed by the old one.¶

6.1. Component Types

This document requests the addition of two new Component Types under the heading of "Messaging Layer Security".¶

6.2. WireFormat

This document requests the addition of three new WireFormats under the heading of "Messaging Layer Security".¶