<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.4) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-mahy-mimi-msgid-aad-02" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->
  <front>
    <title abbrev="MIMI Message ID in AAD">Conveying the More Instant Messaging Interoperability Message ID in Messaging Layer Security Additional Authenticated Data</title>
    <seriesInfo name="Internet-Draft" value="draft-mahy-mimi-msgid-aad-02"/>
    <author fullname="Rohan Mahy">
      <organization/>
      <address>
        <email>rohan.mahy@gmail.com</email>
      </address>
    </author>
    <date year="2026" month="April" day="19"/>
    <area/>
    <workgroup>More Instant Messaging Interoperability</workgroup>
    <keyword>message ID</keyword>
    <keyword>AAD</keyword>
    <keyword>Additional Authenticated Data</keyword>
    <keyword>message ID component</keyword>
    <abstract>
      <?line 38?>

<t>The More Instant Messaging Interoperability (MIMI) content format defines a MIMI Message ID, communicated only to members of the Messaging Layer Security (MLS) group in which the message was sent.
This document defines a way to share a Message ID in the MLS Additional Authenticated Data (AAD) so it is visible to MIMI providers.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://rohanmahy.github.io/mimi-msgid-aad/draft-mahy-mimi-msgid-aad.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-mahy-mimi-msgid-aad/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        More Instant Messaging Interoperability  mailing list (<eref target="mailto:mimi@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/mimi/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/mimi/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/rohanmahy/mimi-msgid-aad"/>.</t>
    </note>
  </front>
  <middle>
    <?line 43?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Many messaging protocols and formats have a Message ID.
The MIMI content format defines how to calculate a MIMI Message ID (See <xref section="3.3" sectionFormat="of" target="I-D.ietf-mimi-content"/>) for an application/mimi-content application message.
A MIMI Message ID is currently only shared end-to-end encrypted with members of the MLS <xref target="RFC9420"/> group in which the message was sent.
This document defines an optional mechanism to share a Message ID in the
MLS AAD, so it is visible to intermediary providers.
This greatly facilitates debugging and troubleshooting, but causes a modest reduction in privacy.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

</section>
    <section anchor="mechanism">
      <name>Mechanism</name>
      <t>This document defines a new Safe AAD <tt>message_id</tt> component as described in <xref section="4.9" sectionFormat="of" target="I-D.ietf-mls-extensions"/>.</t>
      <t>When the content of an MLS application message is a MIMI content message (media type <tt>application/mimi-content</tt>), if the <tt>message_id</tt> component is present inside <tt>SafeAAD.aad_items</tt>, it <bcp14>MUST</bcp14> contain the MIMI content Message ID calculated as described in <xref section="3.3" sectionFormat="of" target="I-D.ietf-mimi-content"/>.</t>
      <ul empty="true">
        <li>
          <t>To the extent that other application formats or media types have a Message ID, the Message ID for an application message of that type or format <bcp14>MAY</bcp14> be conveyed in this extension, using a message ID appropriate to the media type of the content.</t>
        </li>
      </ul>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>An attacker or provider with access to a fragment of message history, and the message logs of a MIMI provider in the path of a message could potentially learn more about the participants of a particular MIMI room or the room's corresponding MLS group if it can see message IDs.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="messageid-mls-component-type">
        <name>message_id MLS Component Type</name>
        <t>This document registers a new MLS Component Type in the Specification Required range with the following template:</t>
        <ul spacing="normal">
          <li>
            <t>Value: TBD (suggested value 0x0040)</t>
          </li>
          <li>
            <t>Name: message_id</t>
          </li>
          <li>
            <t>Where: AD</t>
          </li>
          <li>
            <t>Recommended: Y</t>
          </li>
          <li>
            <t>Reference: RFC XXXX</t>
          </li>
        </ul>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="I-D.ietf-mimi-content">
        <front>
          <title>More Instant Messaging Interoperability (MIMI) message content</title>
          <author fullname="Rohan Mahy" initials="R." surname="Mahy">
            <organization>Rohan Mahy Consulting Services</organization>
          </author>
          <date day="2" month="March" year="2026"/>
          <abstract>
            <t>   This document describes content semantics common in Instant Messaging
   (IM) systems and describes a profile suitable for instant messaging
   interoperability of messages end-to-end encrypted inside the MLS
   (Message Layer Security) Protocol.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-mimi-content-08"/>
      </reference>
      <reference anchor="RFC9420" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9420.xml">
        <front>
          <title>The Messaging Layer Security (MLS) Protocol</title>
          <author fullname="R. Barnes" initials="R." surname="Barnes"/>
          <author fullname="B. Beurdouche" initials="B." surname="Beurdouche"/>
          <author fullname="R. Robert" initials="R." surname="Robert"/>
          <author fullname="J. Millican" initials="J." surname="Millican"/>
          <author fullname="E. Omara" initials="E." surname="Omara"/>
          <author fullname="K. Cohn-Gordon" initials="K." surname="Cohn-Gordon"/>
          <date month="July" year="2023"/>
          <abstract>
            <t>Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9420"/>
        <seriesInfo name="DOI" value="10.17487/RFC9420"/>
      </reference>
      <reference anchor="RFC2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <reference anchor="I-D.ietf-mls-extensions">
        <front>
          <title>The Messaging Layer Security (MLS) Extensions</title>
          <author fullname="Raphael Robert" initials="R." surname="Robert">
            <organization>Phoenix R&amp;D</organization>
          </author>
          <date day="2" month="March" year="2026"/>
          <abstract>
            <t>   The Messaging Layer Security (MLS) protocol is an asynchronous group
   authenticated key exchange protocol.  MLS provides a number of
   capabilities to applications, as well as several extension points
   internal to the protocol.  This document provides a consolidated
   application API, guidance for how the protocol's extension points
   should be used, and a few concrete examples of both core protocol
   extensions and uses of the application API.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-mls-extensions-09"/>
      </reference>
    </references>
    <?line 105?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA6VXbW/bNhD+zl9xVT8sGSI7aQOsNbpubtyiBuKki9N1xTAs
tETbRCVRIym7XpD/st+yX7bnKMkveelWLB9i6nTHOz733B0Vx7Hw2meqR9GJ
KRZqpYsZ+bmikbGKhoXzsvA0Us7JGb8aFl5ZUyorJzrTftW8guqAdLGleCpX
ytJYJZVltX6aaq9NITPqV9i/8DqRXqU0kF5GQk4mVi0QxGg4Gt7as98fRIKV
Z8auepBMjRCpSQqZI+zUyqmPczlfxbnOdZy7mU5jKdP48Ilw1STXzsGvX5VQ
Hr6+fEP0mGTmDJzpIlWlwr/CRwcUKYRorJYZPwz7r/BjLFYXl28iUVT5RNme
SBFITySmcKpwleuRt5USCP2pkFZJ7BqJpbGfZtZUJR/ov+EYiU9qBbu0Jyim
fA0APwGA8PMlCHetKDF5aQqoiIUqKgRM9NUBEdWgRbzMpc6wZIh/1MpPO8bO
WC5tMod87n3pet0uq7FIL1SnVeuyoDuxZulUlzfosuFM+3k1gak1c1lw/rq7
+WOlDOdzfmv/tXKntu9oc8us+yAhOnOfZ5EQEuAZyzjDA9G0yrKaStEF704j
mEbhFYKXhf5TMuq9IFENDiGODjv5ccaiDgDH1oWxObQXAFwwTzdPIo5jkhPn
rUy8EJdfUWF7XBP7SCleQLPelVI11YVyJOlWyRxw8vOqaMhhimxF3oAczF9H
ZlqX90OFujc6He/XZOHiW851Mg8WLbuW0hG47zs4hHaEQqxyjmsT0FIGj26O
guD4dqo5OD8df5nNtAfO75MzpD3ByUI7PckU7xpOW1qz0CmO06mBzXWaZkqI
x4yeNWmV8NZCjGSxagLno8LMm8RkCLJIGyAdzeViN8xOnR529ADoc7PkWBKZ
JRVz9G4WaG+sFF1fA1cOhZ52njL0j4bxIBRGzc1m+5ubffaAqEiWZcZAwKa7
rbL9ok1FR/TvuAVYSKSFBdIech/SkBLaXOxNjB8sE7sqGesliugOM5Cc6+tH
F29Onh8/Oby5+V9cKMiUTZZzlaBmtMu/yA0RuNEHi+9LvubayNGnpV1tkyB4
n6H98qmnMuHC4daBQCbVLOSeMw5qVNjJzY3xkB3QpPJIYuUCbXOTotkQwKrp
wxGVVi9ksgLNwK0wIAt+VRNowKcMJHZ1RaOFE/dwhy77fnzJY4R/6ew8rC9e
//R+ePF6wOvx2/7p6XohGo3x2/P3p4PNamN5cj4avT4b1MaQ0o5IRKP+R7zh
qKLzd5fD87P+aVRDup0XBh0wTlSNZGkVs0A6gZMnVk/wAJtXJ+/+/uvouGHB
k6Oj52BB/fDs6LtjPCxRr7W3QLH6EdlbCdBUScu7yCwDtiUSkTnogiiomoLm
yoK44ttfGZnfevRikpRHxy8bAR94R9hitiMMmN2V3DGuQbxHdI+bNZo78ltI
78bb/7jz3OK+JXzxQ4Y6oPjo2Q8vReDQqK0C8WD7LNSSxnKquAzoqim133V6
tZnqDOdOyjaN5rjz/FajyVysPqOH8DXI3dwA/A/IV6jjtrnAgAcfSu+eNsM1
KHfbYftmL9RiuCfQ1UOt62r/gHTdWx44DRyAii4sEWYKRQYA5+9gbv+uvcrd
1QG3g8AR3le2o2Q7rK1usm7N6Rew+pemDKReXprgJgDoscQQMBDYHaDaSYIW
vgHknsFysDV6Q5R3m/4a2tCN4S1gC7VmAoF0XL5JuKvX5wklvs7wAVUu9Lvt
6yAc4EqBq60P9V+38HXmmsbfnLvudev7AJoeZ8TKps/1Ea73MvkEDBBW24Tr
USKTBE7ZhaSplbO8IVcbCiLFDXtVt47tQZKZWRhAcne+txeGUmLz8Lo1SEyV
pVQajhg3djShDH0H8PGlSk5M5RtDi3uFLnHFavavJaCGrV1ZY3I+CGvz+hsM
UIMB6sDNlIHkqmhG4JQpmCBhTqkteF0N2bB/1r8D1+PHtOF82OtkTftLgH+7
DVg1A0Y8jutGcNeixWRcqkRPW9pcqD8qzXPeyoIHM2eDtaYmy8wyfNSpvMzC
x4uI6WeZ4auALl/houIwITH4YLtgKR1+Pjw8PtyH1lm4Fm/ih+gD9+8e4Ysk
hk++afL3U9qjj0EwxdsigQJmBf2Cv+bmOwFhGKN+8qkwy0ylgRpOXPfq7yqV
fh9NMShUdANEzgfnoFKriXHxD/odyJSnDgAA

-->

</rfc>
