rfc9420.original.xml   rfc9420.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <rfc version="3" category="std" consensus="true" docName="draft-ietf-mls-protoco
<!ENTITY nbsp "&#160;"> l-20" ipr="trust200902" number="9420" obsoletes="" sortRefs="true" submissionTyp
<!ENTITY zwsp "&#8203;"> e="IETF" symRefs="true" tocInclude="true" updates="" xml:lang="en" prepTime="202
<!ENTITY nbhy "&#8209;"> 3-07-12T13:09:27" indexInclude="true" scripts="Common,Latin" tocDepth="3">
<!ENTITY wj "&#8288;"> <link href="https://datatracker.ietf.org/doc/draft-ietf-mls-protocol-20" rel="
]> prev"/>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <link href="https://dx.doi.org/10.17487/rfc9420" rel="alternate"/>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.26 (Ruby 3.1. <link href="urn:issn:2070-1721" rel="alternate"/>
3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-mls-protocol-20" category="std" consensus="true" tocInclude="true" sortRef
s="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.17.0 -->
<front> <front>
<title abbrev="MLS">The Messaging Layer Security (MLS) Protocol</title> <title abbrev="MLS">The Messaging Layer Security (MLS) Protocol</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mls-protocol-20"/> <seriesInfo name="RFC" value="9420" stream="IETF"/>
<author initials="R." surname="Barnes" fullname="Richard Barnes"> <author fullname="Richard Barnes" initials="R." surname="Barnes">
<organization>Cisco</organization> <organization showOnFrontPage="true">Cisco</organization>
<address> <address>
<email>rlb@ipv.sx</email> <email>rlb@ipv.sx</email>
</address> </address>
</author> </author>
<author initials="B." surname="Beurdouche" fullname="Benjamin Beurdouche"> <author fullname="Benjamin Beurdouche" initials="B." surname="Beurdouche">
<organization>Inria &amp; Mozilla</organization> <organization showOnFrontPage="true">Inria &amp; Mozilla</organization>
<address> <address>
<email>ietf@beurdouche.com</email> <email>ietf@beurdouche.com</email>
</address> </address>
</author> </author>
<author initials="R." surname="Robert" fullname="Raphael Robert"> <author fullname="Raphael Robert" initials="R." surname="Robert">
<organization>Phoenix R&amp;D</organization> <organization showOnFrontPage="true">Phoenix R&amp;D</organization>
<address> <address>
<email>ietf@raphaelrobert.com</email> <email>ietf@raphaelrobert.com</email>
</address> </address>
</author> </author>
<author initials="J." surname="Millican" fullname="Jon Millican"> <author fullname="Jon Millican" initials="J." surname="Millican">
<organization>Meta Platforms</organization> <organization showOnFrontPage="true">Meta Platforms</organization>
<address> <address>
<email>jmillican@meta.com</email> <email>jmillican@meta.com</email>
</address> </address>
</author> </author>
<author initials="E." surname="Omara" fullname="Emad Omara"> <author fullname="Emad Omara" initials="E." surname="Omara">
<organization>Google</organization> <organization showOnFrontPage="true"/>
<address> <address>
<email>emadomara@google.com</email> <email>emad.omara@gmail.com</email>
</address> </address>
</author> </author>
<author initials="K." surname="Cohn-Gordon" fullname="Katriel Cohn-Gordon"> <author fullname="Katriel Cohn-Gordon" initials="K." surname="Cohn-Gordon">
<organization>University of Oxford</organization> <organization showOnFrontPage="true">University of Oxford</organization>
<address> <address>
<email>me@katriel.co.uk</email> <email>me@katriel.co.uk</email>
</address> </address>
</author> </author>
<date year="2023" month="March" day="27"/> <date month="07" year="2023"/>
<area>Security</area> <area>sec</area>
<keyword>Internet-Draft</keyword> <workgroup>mls</workgroup>
<abstract> <keyword>security</keyword>
<t>Messaging applications are increasingly making use of end-to-end <keyword>authenticated key exchange</keyword>
<keyword>end-to-end encryption</keyword>
<abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">Messaging applications are increasin
gly making use of end-to-end
security mechanisms to ensure that messages are only accessible to security mechanisms to ensure that messages are only accessible to
the communicating endpoints, and not to any servers involved in delivering the communicating endpoints, and not to any servers involved in delivering
messages. Establishing keys to provide such protections is messages. Establishing keys to provide such protections is
challenging for group chat settings, in which more than two 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 clients need to agree on a key but may not be online at the same
time. In this document, we specify a key establishment time. In this document, we specify a key establishment
protocol that provides efficient asynchronous group key establishment protocol that provides efficient asynchronous group key establishment
with forward secrecy and post-compromise security for groups with forward secrecy (FS) and post-compromise security (PCS) for groups
in size ranging from two to thousands.</t> in size ranging from two to thousands.</t>
</abstract> </abstract>
<note removeInRFC="true"> <boilerplate>
<name>Discussion Venues</name> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<t>Source for this draft and an issue tracker can be found at "exclude" pn="section-boilerplate.1">
<eref target="https://github.com/mlswg/mls-protocol">https://github.com/mlswg/ <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
mls-protocol</eref>.</t> >
</note> <t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc9420" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form
at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-terminology">Terminology</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent=
"2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-presentation-language"
>Presentation Language</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.2.2.1.2">
<li pn="section-toc.1-1.2.2.1.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.
2.1.1"><xref derivedContent="2.1.1" format="counter" sectionFormat="of" target="
section-2.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" tar
get="name-optional-value">Optional Value</xref></t>
</li>
<li pn="section-toc.1-1.2.2.1.2.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.
2.2.1"><xref derivedContent="2.1.2" format="counter" sectionFormat="of" target="
section-2.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" tar
get="name-variable-size-vector-length">Variable-Size Vector Length Headers</xref
></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-protocol-overview">Protocol Overvi
ew</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent=
"3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-cryptographic-state-an
d-evo">Cryptographic State and Evolution</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-example-protocol-execu
tion">Example Protocol Execution</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3">
<t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent=
"3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-external-joins">Extern
al Joins</xref></t>
</li>
<li pn="section-toc.1-1.3.2.4">
<t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent=
"3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-relationships-between-
epoch">Relationships between Epochs</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-ratchet-tree-concepts">Ratchet Tre
e Concepts</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-ratchet-tree-terminolo
gy">Ratchet Tree Terminology</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.1.2">
<li pn="section-toc.1-1.4.2.1.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.2.1.1"><xref derived
Content="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-ratchet-tr
ee-nodes">Ratchet Tree Nodes</xref></t>
</li>
<li pn="section-toc.1-1.4.2.1.2.2">
<t indent="0" pn="section-toc.1-1.4.2.1.2.2.1"><xref derived
Content="4.1.2" format="counter" sectionFormat="of" target="section-4.1.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-paths-thro
ugh-a-ratchet-tre">Paths through a Ratchet Tree</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-views-of-a-ratchet-tre
e">Views of a Ratchet Tree</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-cryptographic-objects">Cryptograph
ic Objects</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-cipher-suites">Cipher
Suites</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.5.2.1.2">
<li pn="section-toc.1-1.5.2.1.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.2.1.1"><xref derived
Content="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-public-key
s">Public Keys</xref></t>
</li>
<li pn="section-toc.1-1.5.2.1.2.2">
<t indent="0" pn="section-toc.1-1.5.2.1.2.2.1"><xref derived
Content="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-signing">S
igning</xref></t>
</li>
<li pn="section-toc.1-1.5.2.1.2.3">
<t indent="0" pn="section-toc.1-1.5.2.1.2.3.1"><xref derived
Content="5.1.3" format="counter" sectionFormat="of" target="section-5.1.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-public-key
-encryption">Public Key Encryption</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-hash-based-identifiers
">Hash-Based Identifiers</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3">
<t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent=
"5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-credentials">Credentia
ls</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.5.2.3.2">
<li pn="section-toc.1-1.5.2.3.2.1">
<t indent="0" pn="section-toc.1-1.5.2.3.2.1.1"><xref derived
Content="5.3.1" format="counter" sectionFormat="of" target="section-5.3.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-credential
-validation">Credential Validation</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.2">
<t indent="0" pn="section-toc.1-1.5.2.3.2.2.1"><xref derived
Content="5.3.2" format="counter" sectionFormat="of" target="section-5.3.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-credential
-expiry-and-revoc">Credential Expiry and Revocation</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.3">
<t indent="0" pn="section-toc.1-1.5.2.3.2.3.1"><xref derived
Content="5.3.3" format="counter" sectionFormat="of" target="section-5.3.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-uniquely-i
dentifying-client">Uniquely Identifying Clients</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-message-framing">Message Framing</
xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-content-authentication
">Content Authentication</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-encoding-and-decoding-
a-pub">Encoding and Decoding a Public Message</xref></t>
</li>
<li pn="section-toc.1-1.6.2.3">
<t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent=
"6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-encoding-and-decoding-
a-pri">Encoding and Decoding a Private Message</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.6.2.3.2">
<li pn="section-toc.1-1.6.2.3.2.1">
<t indent="0" pn="section-toc.1-1.6.2.3.2.1.1"><xref derived
Content="6.3.1" format="counter" sectionFormat="of" target="section-6.3.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-content-en
cryption">Content Encryption</xref></t>
</li>
<li pn="section-toc.1-1.6.2.3.2.2">
<t indent="0" pn="section-toc.1-1.6.2.3.2.2.1"><xref derived
Content="6.3.2" format="counter" sectionFormat="of" target="section-6.3.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-sender-dat
a-encryption">Sender Data Encryption</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-ratchet-tree-operations">Ratchet T
ree Operations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
"7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-parent-node-contents">
Parent Node Contents</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
"7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-leaf-node-contents">Le
af Node Contents</xref></t>
</li>
<li pn="section-toc.1-1.7.2.3">
<t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent=
"7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-leaf-node-validation">
Leaf Node Validation</xref></t>
</li>
<li pn="section-toc.1-1.7.2.4">
<t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent=
"7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-ratchet-tree-evolution
">Ratchet Tree Evolution</xref></t>
</li>
<li pn="section-toc.1-1.7.2.5">
<t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent=
"7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-synchronizing-views-of
-the-">Synchronizing Views of the Tree</xref></t>
</li>
<li pn="section-toc.1-1.7.2.6">
<t indent="0" pn="section-toc.1-1.7.2.6.1"><xref derivedContent=
"7.6" format="counter" sectionFormat="of" target="section-7.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-update-paths">Update P
aths</xref></t>
</li>
<li pn="section-toc.1-1.7.2.7">
<t indent="0" pn="section-toc.1-1.7.2.7.1"><xref derivedContent=
"7.7" format="counter" sectionFormat="of" target="section-7.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-adding-and-removing-le
aves">Adding and Removing Leaves</xref></t>
</li>
<li pn="section-toc.1-1.7.2.8">
<t indent="0" pn="section-toc.1-1.7.2.8.1"><xref derivedContent=
"7.8" format="counter" sectionFormat="of" target="section-7.8"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-tree-hashes">Tree Hash
es</xref></t>
</li>
<li pn="section-toc.1-1.7.2.9">
<t indent="0" pn="section-toc.1-1.7.2.9.1"><xref derivedContent=
"7.9" format="counter" sectionFormat="of" target="section-7.9"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-parent-hashes">Parent
Hashes</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.7.2.9.2">
<li pn="section-toc.1-1.7.2.9.2.1">
<t indent="0" pn="section-toc.1-1.7.2.9.2.1.1"><xref derived
Content="7.9.1" format="counter" sectionFormat="of" target="section-7.9.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-using-pare
nt-hashes">Using Parent Hashes</xref></t>
</li>
<li pn="section-toc.1-1.7.2.9.2.2">
<t indent="0" pn="section-toc.1-1.7.2.9.2.2.1"><xref derived
Content="7.9.2" format="counter" sectionFormat="of" target="section-7.9.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-verifying-
parent-hashes">Verifying Parent Hashes</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-key-schedule">Key Schedule</xref><
/t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-group-context">Group C
ontext</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
"8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-transcript-hashes">Tra
nscript Hashes</xref></t>
</li>
<li pn="section-toc.1-1.8.2.3">
<t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent=
"8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-external-initializatio
n">External Initialization</xref></t>
</li>
<li pn="section-toc.1-1.8.2.4">
<t indent="0" pn="section-toc.1-1.8.2.4.1"><xref derivedContent=
"8.4" format="counter" sectionFormat="of" target="section-8.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-pre-shared-keys">Pre-S
hared Keys</xref></t>
</li>
<li pn="section-toc.1-1.8.2.5">
<t indent="0" pn="section-toc.1-1.8.2.5.1"><xref derivedContent=
"8.5" format="counter" sectionFormat="of" target="section-8.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-exporters">Exporters</
xref></t>
</li>
<li pn="section-toc.1-1.8.2.6">
<t indent="0" pn="section-toc.1-1.8.2.6.1"><xref derivedContent=
"8.6" format="counter" sectionFormat="of" target="section-8.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-resumption-psk">Resump
tion PSK</xref></t>
</li>
<li pn="section-toc.1-1.8.2.7">
<t indent="0" pn="section-toc.1-1.8.2.7.1"><xref derivedContent=
"8.7" format="counter" sectionFormat="of" target="section-8.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-epoch-authenticators">
Epoch Authenticators</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-secret-tree">Secret Tree</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.9.2">
<li pn="section-toc.1-1.9.2.1">
<t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent=
"9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-encryption-keys">Encry
ption Keys</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2">
<t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent=
"9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-deletion-schedule">Del
etion Schedule</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-key-packages">Key Packages</xref
></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.10.2">
<li pn="section-toc.1-1.10.2.1">
<t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent
="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-keypackage-validati
on">KeyPackage Validation</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-group-creation">Group Creation</
xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.11.2">
<li pn="section-toc.1-1.11.2.1">
<t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent
="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-required-capabiliti
es">Required Capabilities</xref></t>
</li>
<li pn="section-toc.1-1.11.2.2">
<t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent
="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-reinitialization">R
einitialization</xref></t>
</li>
<li pn="section-toc.1-1.11.2.3">
<t indent="0" pn="section-toc.1-1.11.2.3.1"><xref derivedContent
="11.3" format="counter" sectionFormat="of" target="section-11.3"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-subgroup-branching"
>Subgroup Branching</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-group-evolution">Group Evolution
</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.12.2">
<li pn="section-toc.1-1.12.2.1">
<t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent
="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-proposals">Proposal
s</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.12.2.1.2">
<li pn="section-toc.1-1.12.2.1.2.1">
<t indent="0" pn="section-toc.1-1.12.2.1.2.1.1"><xref derive
dContent="12.1.1" format="counter" sectionFormat="of" target="section-12.1.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-add">Ad
d</xref></t>
</li>
<li pn="section-toc.1-1.12.2.1.2.2">
<t indent="0" pn="section-toc.1-1.12.2.1.2.2.1"><xref derive
dContent="12.1.2" format="counter" sectionFormat="of" target="section-12.1.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-update"
>Update</xref></t>
</li>
<li pn="section-toc.1-1.12.2.1.2.3">
<t indent="0" pn="section-toc.1-1.12.2.1.2.3.1"><xref derive
dContent="12.1.3" format="counter" sectionFormat="of" target="section-12.1.3"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-remove"
>Remove</xref></t>
</li>
<li pn="section-toc.1-1.12.2.1.2.4">
<t indent="0" pn="section-toc.1-1.12.2.1.2.4.1"><xref derive
dContent="12.1.4" format="counter" sectionFormat="of" target="section-12.1.4"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-preshar
edkey">PreSharedKey</xref></t>
</li>
<li pn="section-toc.1-1.12.2.1.2.5">
<t indent="0" pn="section-toc.1-1.12.2.1.2.5.1"><xref derive
dContent="12.1.5" format="counter" sectionFormat="of" target="section-12.1.5"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-reinit"
>ReInit</xref></t>
</li>
<li pn="section-toc.1-1.12.2.1.2.6">
<t indent="0" pn="section-toc.1-1.12.2.1.2.6.1"><xref derive
dContent="12.1.6" format="counter" sectionFormat="of" target="section-12.1.6"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-externa
linit">ExternalInit</xref></t>
</li>
<li pn="section-toc.1-1.12.2.1.2.7">
<t indent="0" pn="section-toc.1-1.12.2.1.2.7.1"><xref derive
dContent="12.1.7" format="counter" sectionFormat="of" target="section-12.1.7"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-groupco
ntextextensions">GroupContextExtensions</xref></t>
</li>
<li pn="section-toc.1-1.12.2.1.2.8">
<t indent="0" pn="section-toc.1-1.12.2.1.2.8.1"><xref derive
dContent="12.1.8" format="counter" sectionFormat="of" target="section-12.1.8"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-externa
l-proposals">External Proposals</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.12.2.2">
<t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent
="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-proposal-list-valid
ation">Proposal List Validation</xref></t>
</li>
<li pn="section-toc.1-1.12.2.3">
<t indent="0" pn="section-toc.1-1.12.2.3.1"><xref derivedContent
="12.3" format="counter" sectionFormat="of" target="section-12.3"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-applying-a-proposal
-list">Applying a Proposal List</xref></t>
</li>
<li pn="section-toc.1-1.12.2.4">
<t indent="0" pn="section-toc.1-1.12.2.4.1"><xref derivedContent
="12.4" format="counter" sectionFormat="of" target="section-12.4"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-commit">Commit</xre
f></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.12.2.4.2">
<li pn="section-toc.1-1.12.2.4.2.1">
<t indent="0" pn="section-toc.1-1.12.2.4.2.1.1"><xref derive
dContent="12.4.1" format="counter" sectionFormat="of" target="section-12.4.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-creatin
g-a-commit">Creating a Commit</xref></t>
</li>
<li pn="section-toc.1-1.12.2.4.2.2">
<t indent="0" pn="section-toc.1-1.12.2.4.2.2.1"><xref derive
dContent="12.4.2" format="counter" sectionFormat="of" target="section-12.4.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-process
ing-a-commit">Processing a Commit</xref></t>
</li>
<li pn="section-toc.1-1.12.2.4.2.3">
<t indent="0" pn="section-toc.1-1.12.2.4.2.3.1"><xref derive
dContent="12.4.3" format="counter" sectionFormat="of" target="section-12.4.3"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-adding-
members-to-the-group">Adding Members to the Group</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" fo
rmat="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-extensibility">Extensibility</xr
ef></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.13.2">
<li pn="section-toc.1-1.13.2.1">
<t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent
="13.1" format="counter" sectionFormat="of" target="section-13.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-additional-cipher-s
uites">Additional Cipher Suites</xref></t>
</li>
<li pn="section-toc.1-1.13.2.2">
<t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent
="13.2" format="counter" sectionFormat="of" target="section-13.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-proposals-2">Propos
als</xref></t>
</li>
<li pn="section-toc.1-1.13.2.3">
<t indent="0" pn="section-toc.1-1.13.2.3.1"><xref derivedContent
="13.3" format="counter" sectionFormat="of" target="section-13.3"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-credential-extensib
ility">Credential Extensibility</xref></t>
</li>
<li pn="section-toc.1-1.13.2.4">
<t indent="0" pn="section-toc.1-1.13.2.4.1"><xref derivedContent
="13.4" format="counter" sectionFormat="of" target="section-13.4"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-extensions">Extensi
ons</xref></t>
</li>
<li pn="section-toc.1-1.13.2.5">
<t indent="0" pn="section-toc.1-1.13.2.5.1"><xref derivedContent
="13.5" format="counter" sectionFormat="of" target="section-13.5"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-grease">GREASE</xre
f></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" fo
rmat="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-sequencing-of-state-changes">Seq
uencing of State Changes</xref></t>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="15" fo
rmat="counter" sectionFormat="of" target="section-15"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-application-messages">Applicatio
n Messages</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.15.2">
<li pn="section-toc.1-1.15.2.1">
<t indent="0" pn="section-toc.1-1.15.2.1.1"><xref derivedContent
="15.1" format="counter" sectionFormat="of" target="section-15.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-padding">Padding</x
ref></t>
</li>
<li pn="section-toc.1-1.15.2.2">
<t indent="0" pn="section-toc.1-1.15.2.2.1"><xref derivedContent
="15.2" format="counter" sectionFormat="of" target="section-15.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-restrictions">Restr
ictions</xref></t>
</li>
<li pn="section-toc.1-1.15.2.3">
<t indent="0" pn="section-toc.1-1.15.2.3.1"><xref derivedContent
="15.3" format="counter" sectionFormat="of" target="section-15.3"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-delayed-and-reorder
ed-appli">Delayed and Reordered Application Messages</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.16">
<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="16" fo
rmat="counter" sectionFormat="of" target="section-16"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-security-considerations">Securit
y Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.16.2">
<li pn="section-toc.1-1.16.2.1">
<t indent="0" pn="section-toc.1-1.16.2.1.1"><xref derivedContent
="16.1" format="counter" sectionFormat="of" target="section-16.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-transport-security"
>Transport Security</xref></t>
</li>
<li pn="section-toc.1-1.16.2.2">
<t indent="0" pn="section-toc.1-1.16.2.2.1"><xref derivedContent
="16.2" format="counter" sectionFormat="of" target="section-16.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-confidentiality-of-
group-se">Confidentiality of Group Secrets</xref></t>
</li>
<li pn="section-toc.1-1.16.2.3">
<t indent="0" pn="section-toc.1-1.16.2.3.1"><xref derivedContent
="16.3" format="counter" sectionFormat="of" target="section-16.3"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-confidentiality-of-
sender-d">Confidentiality of Sender Data</xref></t>
</li>
<li pn="section-toc.1-1.16.2.4">
<t indent="0" pn="section-toc.1-1.16.2.4.1"><xref derivedContent
="16.4" format="counter" sectionFormat="of" target="section-16.4"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-confidentiality-of-
group-me">Confidentiality of Group Metadata</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.16.2.4.2">
<li pn="section-toc.1-1.16.2.4.2.1">
<t indent="0" pn="section-toc.1-1.16.2.4.2.1.1"><xref derive
dContent="16.4.1" format="counter" sectionFormat="of" target="section-16.4.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-groupid
-epoch-and-message-f">GroupID, Epoch, and Message Frequency</xref></t>
</li>
<li pn="section-toc.1-1.16.2.4.2.2">
<t indent="0" pn="section-toc.1-1.16.2.4.2.2.1"><xref derive
dContent="16.4.2" format="counter" sectionFormat="of" target="section-16.4.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-group-e
xtensions">Group Extensions</xref></t>
</li>
<li pn="section-toc.1-1.16.2.4.2.3">
<t indent="0" pn="section-toc.1-1.16.2.4.2.3.1"><xref derive
dContent="16.4.3" format="counter" sectionFormat="of" target="section-16.4.3"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-group-m
embership">Group Membership</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.16.2.5">
<t indent="0" pn="section-toc.1-1.16.2.5.1"><xref derivedContent
="16.5" format="counter" sectionFormat="of" target="section-16.5"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-authentication">Aut
hentication</xref></t>
</li>
<li pn="section-toc.1-1.16.2.6">
<t indent="0" pn="section-toc.1-1.16.2.6.1"><xref derivedContent
="16.6" format="counter" sectionFormat="of" target="section-16.6"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-forward-secrecy-and
-post-co">Forward Secrecy and Post-Compromise Security</xref></t>
</li>
<li pn="section-toc.1-1.16.2.7">
<t indent="0" pn="section-toc.1-1.16.2.7.1"><xref derivedContent
="16.7" format="counter" sectionFormat="of" target="section-16.7"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-uniqueness-of-ratch
et-tree-">Uniqueness of Ratchet Tree Key Pairs</xref></t>
</li>
<li pn="section-toc.1-1.16.2.8">
<t indent="0" pn="section-toc.1-1.16.2.8.1"><xref derivedContent
="16.8" format="counter" sectionFormat="of" target="section-16.8"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-keypackage-reuse">K
eyPackage Reuse</xref></t>
</li>
<li pn="section-toc.1-1.16.2.9">
<t indent="0" pn="section-toc.1-1.16.2.9.1"><xref derivedContent
="16.9" format="counter" sectionFormat="of" target="section-16.9"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-delivery-service-co
mpromise">Delivery Service Compromise</xref></t>
</li>
<li pn="section-toc.1-1.16.2.10">
<t indent="0" pn="section-toc.1-1.16.2.10.1"><xref derivedConten
t="16.10" format="counter" sectionFormat="of" target="section-16.10"/>. <xref de
rivedContent="" format="title" sectionFormat="of" target="name-authentication-se
rvice-comp">Authentication Service Compromise</xref></t>
</li>
<li pn="section-toc.1-1.16.2.11">
<t indent="0" pn="section-toc.1-1.16.2.11.1"><xref derivedConten
t="16.11" format="counter" sectionFormat="of" target="section-16.11"/>. <xref de
rivedContent="" format="title" sectionFormat="of" target="name-additional-policy
-enforceme">Additional Policy Enforcement</xref></t>
</li>
<li pn="section-toc.1-1.16.2.12">
<t indent="0" pn="section-toc.1-1.16.2.12.1"><xref derivedConten
t="16.12" format="counter" sectionFormat="of" target="section-16.12"/>. <xref de
rivedContent="" format="title" sectionFormat="of" target="name-group-fragmentati
on-by-mali">Group Fragmentation by Malicious Insiders</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.17">
<t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="17" fo
rmat="counter" sectionFormat="of" target="section-17"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
erations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.17.2">
<li pn="section-toc.1-1.17.2.1">
<t indent="0" pn="section-toc.1-1.17.2.1.1"><xref derivedContent
="17.1" format="counter" sectionFormat="of" target="section-17.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-mls-cipher-suites">
MLS Cipher Suites</xref></t>
</li>
<li pn="section-toc.1-1.17.2.2">
<t indent="0" pn="section-toc.1-1.17.2.2.1"><xref derivedContent
="17.2" format="counter" sectionFormat="of" target="section-17.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-mls-wire-formats">M
LS Wire Formats</xref></t>
</li>
<li pn="section-toc.1-1.17.2.3">
<t indent="0" pn="section-toc.1-1.17.2.3.1"><xref derivedContent
="17.3" format="counter" sectionFormat="of" target="section-17.3"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-mls-extension-types
">MLS Extension Types</xref></t>
</li>
<li pn="section-toc.1-1.17.2.4">
<t indent="0" pn="section-toc.1-1.17.2.4.1"><xref derivedContent
="17.4" format="counter" sectionFormat="of" target="section-17.4"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-mls-proposal-types"
>MLS Proposal Types</xref></t>
</li>
<li pn="section-toc.1-1.17.2.5">
<t indent="0" pn="section-toc.1-1.17.2.5.1"><xref derivedContent
="17.5" format="counter" sectionFormat="of" target="section-17.5"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-mls-credential-type
s">MLS Credential Types</xref></t>
</li>
<li pn="section-toc.1-1.17.2.6">
<t indent="0" pn="section-toc.1-1.17.2.6.1"><xref derivedContent
="17.6" format="counter" sectionFormat="of" target="section-17.6"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-mls-signature-label
s">MLS Signature Labels</xref></t>
</li>
<li pn="section-toc.1-1.17.2.7">
<t indent="0" pn="section-toc.1-1.17.2.7.1"><xref derivedContent
="17.7" format="counter" sectionFormat="of" target="section-17.7"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-mls-public-key-encr
yption-l">MLS Public Key Encryption Labels</xref></t>
</li>
<li pn="section-toc.1-1.17.2.8">
<t indent="0" pn="section-toc.1-1.17.2.8.1"><xref derivedContent
="17.8" format="counter" sectionFormat="of" target="section-17.8"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-mls-exporter-labels
">MLS Exporter Labels</xref></t>
</li>
<li pn="section-toc.1-1.17.2.9">
<t indent="0" pn="section-toc.1-1.17.2.9.1"><xref derivedContent
="17.9" format="counter" sectionFormat="of" target="section-17.9"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-mls-designated-expe
rt-pool">MLS Designated Expert Pool</xref></t>
</li>
<li pn="section-toc.1-1.17.2.10">
<t indent="0" pn="section-toc.1-1.17.2.10.1"><xref derivedConten
t="17.10" format="counter" sectionFormat="of" target="section-17.10"/>. <xref de
rivedContent="" format="title" sectionFormat="of" target="name-the-message-mls-m
edia-type">The "message/mls" Media Type</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.18">
<t indent="0" pn="section-toc.1-1.18.1"><xref derivedContent="18" fo
rmat="counter" sectionFormat="of" target="section-18"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-references">References</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.18.2">
<li pn="section-toc.1-1.18.2.1">
<t indent="0" pn="section-toc.1-1.18.2.1.1"><xref derivedContent
="18.1" format="counter" sectionFormat="of" target="section-18.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.18.2.2">
<t indent="0" pn="section-toc.1-1.18.2.2.1"><xref derivedContent
="18.2" format="counter" sectionFormat="of" target="section-18.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.19">
<t indent="0" pn="section-toc.1-1.19.1"><xref derivedContent="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-protocol-origin
s-of-example">Protocol Origins of Example Trees</xref></t>
</li>
<li pn="section-toc.1-1.20">
<t indent="0" pn="section-toc.1-1.20.1"><xref derivedContent="Append
ix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-evolution-of-pa
rent-hashes">Evolution of Parent Hashes</xref></t>
</li>
<li pn="section-toc.1-1.21">
<t indent="0" pn="section-toc.1-1.21.1"><xref derivedContent="Append
ix C" format="default" sectionFormat="of" target="section-appendix.c"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-array-based-tre
es">Array-Based Trees</xref></t>
</li>
<li pn="section-toc.1-1.22">
<t indent="0" pn="section-toc.1-1.22.1"><xref derivedContent="Append
ix D" format="default" sectionFormat="of" target="section-appendix.d"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-link-based-tree
s">Link-Based Trees</xref></t>
</li>
<li pn="section-toc.1-1.23">
<t indent="0" pn="section-toc.1-1.23.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-contributors">Contributors</xre
f></t>
</li>
<li pn="section-toc.1-1.24">
<t indent="0" pn="section-toc.1-1.24.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.f"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction" numbered="true" removeInRFC="false" toc="incl
<name>Introduction</name> ude" pn="section-1">
<t>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for <name slugifiedName="name-introduction">Introduction</name>
this draft is maintained in GitHub. Suggested changes should be <t indent="0" pn="section-1-1">A group of users who want to send each othe
submitted as pull requests at https://github.com/mlswg/mls-protocol. r encrypted messages needs
Instructions are on that page as well. Editorial changes can be
managed in GitHub, but any substantive change should be discussed on
the MLS mailing list.</t>
<t>A group of users who want to send each other encrypted messages needs
a way to derive shared symmetric encryption keys. For two parties, a way to derive shared symmetric encryption keys. For two parties,
this problem has been studied thoroughly, with the Double Ratchet this problem has been studied thoroughly, with the Double Ratchet
emerging as a common solution <xref target="DoubleRatchet"/> <xref target="Signa l"/>. emerging as a common solution <xref target="DoubleRatchet" format="default" sect ionFormat="of" derivedContent="DoubleRatchet"/> <xref target="Signal" format="de fault" sectionFormat="of" derivedContent="Signal"/>.
Channels implementing the Double Ratchet enjoy fine-grained forward secrecy Channels implementing the Double Ratchet enjoy fine-grained forward secrecy
as well as post-compromise security, but are nonetheless efficient as well as post-compromise security, but are nonetheless efficient
enough for heavy use over low-bandwidth networks.</t> enough for heavy use over low-bandwidth networks.</t>
<t>For a group of size greater than two, a common strategy is to <t indent="0" pn="section-1-2">For a group of size greater than two, a com mon strategy is to
distribute symmetric "sender keys" over existing 1:1 distribute symmetric "sender keys" over existing 1:1
secure channels, and then for each member to send messages to the secure channels, and then for each member to send messages to the
group encrypted with their own sender key. On the one hand, using sender keys group encrypted with their own sender key. On the one hand, using sender keys
improves efficiency relative to pairwise transmission of individual messages, an d improves efficiency relative to pairwise transmission of individual messages, an d
it provides forward secrecy (with the addition of a hash ratchet). it provides forward secrecy (with the addition of a hash ratchet).
On the other hand, it is difficult to achieve post-compromise security with On the other hand, it is difficult to achieve post-compromise security with
sender keys, requiring a number of key update messages that scales as the square sender keys, requiring a number of key update messages that scales as the square
of the group size. of the group size.
An adversary who learns a sender key can often indefinitely and An adversary who learns a sender key can often indefinitely and
passively eavesdrop on that member's messages. Generating and passively eavesdrop on that member's messages. Generating and
distributing a new sender key provides a form of post-compromise distributing a new sender key provides a form of post-compromise
security with regard to that sender. However, it requires security with regard to that sender. However, it requires
computation and communications resources that scale linearly with computation and communications resources that scale linearly with
the size of the group.</t> the size of the group.</t>
<t>In this document, we describe a protocol based on tree structures <t indent="0" pn="section-1-3">In this document, we describe a protocol ba
that enable asynchronous group keying with forward secrecy and sed on tree structures
that enables asynchronous group keying with forward secrecy and
post-compromise security. Based on earlier work on "asynchronous post-compromise security. Based on earlier work on "asynchronous
ratcheting trees" <xref target="ART"/>, the protocol presented here uses an ratcheting trees" <xref target="ART" format="default" sectionFormat="of" derived Content="ART"/>, the protocol presented here uses an
asynchronous key-encapsulation mechanism for tree structures. asynchronous key-encapsulation mechanism for tree structures.
This mechanism allows the members of the group to derive and update This mechanism allows the members of the group to derive and update
shared keys with costs that scale as the log of the group size.</t> shared keys with costs that scale as the log of the group size.</t>
<section anchor="change-log">
<name>Change Log</name>
<t>RFC EDITOR PLEASE DELETE THIS SECTION.</t>
<t>draft-18</t>
<ul spacing="normal">
<li>Make the document standards track</li>
<li>Make the ratchet tree non-malleable (*)</li>
<li>Use ExpandWithLabel to derive welcome key (*)</li>
<li>Change MLS-Exporter label from "exporter" to "exported" (*)</li>
<li>Loosen chain requirements (*)</li>
<li>Clarify transcript hash initialization</li>
<li>GREASE for MLS registries</li>
<li>Move pseudocode out of KDFLabel definition.</li>
<li>Rename PrivateContentTBE to PrivateMessageContent</li>
<li>Fix DecryptWithLabel argument order for Welcome</li>
<li>Responses to IESG reviews</li>
<li>Describe varint length check more clearly</li>
</ul>
<t>draft-17</t>
<ul spacing="normal">
<li>Rename MLSCiphertext and MLSPlaintext to PrivateMessage and Public
Messsage respectively (*)</li>
<li>Add label and context to public-key encryption (*)</li>
<li>Include leaf index in LeafNodeTBS for better parent-hash guarantee
s (*)</li>
<li>Make ProtocolVersion two bytes (*)</li>
<li>Clarify group creation (*)</li>
<li>Validate additional properties of unmerged leaves (*)</li>
<li>Clarify that the AS needs to vet the signature key</li>
<li>Remove "MLS" prefix on structs</li>
<li>Credentials should be replaced before expiring</li>
<li>Add a section discussing the security of the sender data protectio
n</li>
<li>Minor fixes in presentation language.</li>
<li>Allow multiple welcomes per commit</li>
<li>Remove reference to BasicCredential.</li>
<li>Client aware of its own removal in group</li>
<li>Create IANA registries for signature and export labels</li>
<li>Complete IANA media type registration</li>
<li>Make more vendor code points available</li>
<li>Update Recommended column definition to match 8447bis</li>
<li>Responses to early ARTART review</li>
<li>Responses to early OPSDIR review</li>
<li>Responses to early TSV-ART review</li>
</ul>
<t>draft-16</t>
<ul spacing="normal">
<li>Fix GroupInfoTBS (*)</li>
<li>Make reference to h2 informative</li>
</ul>
<t>draft-15</t>
<ul spacing="normal">
<li>Include ciphersuite in group context (*)</li>
<li>Add new new_proposal_member SenderType (*)</li>
<li>Always use a full tree (*)</li>
<li>Change KeyPackage identifier extension to be LeafNode identifier (
*)</li>
<li>Use new tree for context in path secret encryption (*)</li>
<li>Use a hash function for hash identifiers (*)</li>
<li>Add a marker byte to tree hash input structs (*)</li>
<li>Recommend that group ids are generated randomly (*)</li>
<li>Update external senders extension to have SignaturePublicKey and C
redential (*)</li>
<li>Replace LeafNodeRef with leaf index (*)</li>
<li>Remove AppAck proposal (*)</li>
<li>Make padding arbitrary-size and all-zero (*)</li>
<li>Require that unmerged_leaves be ordered</li>
<li>Derive the commit secret from the end of the UpdatePath, not the r
oot</li>
<li>Specify the precise points in the protocol where credential valida
tion must be done</li>
<li>Make PSK provisions more uniform, e.g., always generating a fresh
random nonce</li>
<li>Improve parent hash guarantees with stricter checks on tree correc
tness</li>
<li>Streamline some structs, e.g., folding GroupContext into GroupInfo
</li>
<li>Provide clearer rules for validating and applying commits</li>
<li>Clarify tree hash and parent hash, and correct examples</li>
<li>Clean up struct names and references to outdated structs</li>
<li>Cite AEAD limits draft</li>
</ul>
<t>draft-14</t>
<ul spacing="normal">
<li>Ensure that a signature public key is always intelligible (*)</li>
<li>Clean up terminology of derived secrets/keys</li>
<li>Fix parent hash (*)</li>
<li>Specify compatibility behavior around new credentials</li>
<li>Add Path Required to Proposal Type template</li>
<li>Sub-group branching requires fresh key packages for each member</l
i>
<li>Use <tt>aasvg</tt> and typed code blocks</li>
<li>Require init key and leaf key to be different</li>
<li>Preconfigured senders extension and removal of signature key indir
ection</li>
</ul>
<t>draft-13</t>
<ul spacing="normal">
<li>TLS syntax updates (including variable-header-length vectors) (*)<
/li>
<li>Stop generating redundant PKE key pairs. (*)</li>
<li>Move validation of identity change to the AS</li>
<li>Add message/mls MIME type registration</li>
<li>Split LeafNode from KeyPackage (*)</li>
<li>Remove endpoint_id (*)</li>
<li>Reorganize to make section layout more sane</li>
<li>Forbid proposals by reference in external commits (*)</li>
<li>Domain separation for KeyPackage and Proposal references (*)</li>
<li>Downgrade MUST to SHOULD for commit senders including all valid co
mmits</li>
<li>Stronger parent hashes for authenticated identities (*)</li>
<li>Move wire_format to a separate tagged-union structure MLSMessage</
li>
<li>Generalize tree extend/truncate algorithms</li>
<li>Add algorithms for link-based trees</li>
<li>Forbid self-Update entirely (*)</li>
<li>Consolidate resumption PSK cases (*)</li>
<li>384 Ciphersuite Addition</li>
<li>Remove explicit version pin on HPKE (*)</li>
<li>Remove the requirement for Add in external commit (*)</li>
<li>Use smaller, fixed-size hash-based identifiers (*)</li>
<li>Be explicit that Credentials can attest to multiple identities (*)
</li>
</ul>
<t>draft-12</t>
<ul spacing="normal">
<li>Use the GroupContext to derive the joiner_secret (*)</li>
<li>Make PreSharedKeys non optional in GroupSecrets (*)</li>
<li>Update name for this particular key (*)</li>
<li>Truncate tree size on removal (*)</li>
<li>Use HPKE draft-08 (*)</li>
<li>Clarify requirements around identity in MLS groups (*)</li>
<li>Signal the intended wire format for MLS messages (*)</li>
<li>Inject GroupContext as HPKE info instead of AAD (*)</li>
<li>Clarify extension handling and make extension updatable (*)</li>
<li>Improve extensibility of Proposals (*)</li>
<li>Constrain proposal in External Commit (*)</li>
<li>Remove the notion of a 'leaf index' (*)</li>
<li>Add group_context_extensions proposal ID (*)</li>
<li>Add RequiredCapabilities extension (*)</li>
<li>Use cascaded KDF instead of concatenation to consolidate PSKs (*)<
/li>
<li>Use key package hash to index clients in message structs (*)</li>
<li>Don't require PublicGroupState for external init (*)</li>
<li>Make ratchet tree section clearer.</li>
<li>Handle non-member sender cases in MLSPlaintextTBS</li>
<li>Clarify encoding of signatures with NIST curves</li>
<li>Remove OPEN ISSUEs and TODOs</li>
<li>Normalize the description of the zero vector</li>
</ul>
<t>draft-11</t>
<ul spacing="normal">
<li>Include subtree keys in parent hash (*)</li>
<li>Pin HPKE to draft-07 (*)</li>
<li>Move joiner secret to the end of the first key schedule epoch (*)<
/li>
<li>Add an AppAck proposal</li>
<li>Make initializations of transcript hashes consistent</li>
</ul>
<t>draft-10</t>
<ul spacing="normal">
<li>Allow new members to join via an external Commit (*)</li>
<li>Enable proposals to be sent inline in a Commit (*)</li>
<li>Re-enable constant-time Add (*)</li>
<li>Change expiration extension to lifetime extension (*)</li>
<li>Make the tree in the Welcome optional (*)</li>
<li>PSK injection, re-init, sub-group branching (*)</li>
<li>Require the initial init_secret to be a random value (*)</li>
<li>Remove explicit sender data nonce (*)</li>
<li>Do not encrypt to joiners in UpdatePath generation (*)</li>
<li>Move MLSPlaintext signature under the confirmation tag (*)</li>
<li>Explicitly authenticate group membership with MLSPLaintext (*)</li
>
<li>Clarify X509Credential structure (*)</li>
<li>Remove unneeded interim transcript hash from GroupInfo (*)</li>
<li>IANA considerations</li>
<li>Derive an authentication secret</li>
<li>Use Extract/Expand from HPKE KDF</li>
<li>Clarify that application messages MUST be encrypted</li>
</ul>
<t>draft-09</t>
<ul spacing="normal">
<li>Remove blanking of nodes on Add (*)</li>
<li>Change epoch numbers to uint64 (*)</li>
<li>Add PSK inputs (*)</li>
<li>Add key schedule exporter (*)</li>
<li>Sign the updated direct path on Commit, using "parent hashes" and
one
signature per leaf (*)</li>
<li>Use structured types for external senders (*)</li>
<li>Redesign Welcome to include confirmation and use derived keys (*)<
/li>
<li>Remove ignored proposals (*)</li>
<li>Always include an Update with a Commit (*)</li>
<li>Add per-message entropy to guard against nonce reuse (*)</li>
<li>Use the same hash ratchet construct for both application and hands
hake keys (*)</li>
<li>Add more ciphersuites</li>
<li>Use HKDF to derive key pairs (*)</li>
<li>Mandate expiration of ClientInitKeys (*)</li>
<li>Add extensions to GroupContext and flesh out the extensibility sto
ry (*)</li>
<li>Rename ClientInitKey to KeyPackage</li>
</ul>
<t>draft-08</t>
<ul spacing="normal">
<li>Change ClientInitKeys so that they only refer to one ciphersuite (
*)</li>
<li>Decompose group operations into Proposals and Commits (*)</li>
<li>Enable Add and Remove proposals from outside the group (*)</li>
<li>Replace Init messages with multi-recipient Welcome message (*)</li
>
<li>Add extensions to ClientInitKeys for expiration and downgrade resi
stance (*)</li>
<li>Allow multiple Proposals and a single Commit in one MLSPlaintext (
*)</li>
</ul>
<t>draft-07</t>
<ul spacing="normal">
<li>Initial version of the Tree based Application Key Schedule (*)</li
>
<li>Initial definition of the Init message for group creation (*)</li>
<li>Fix issue with the transcript used for newcomers (*)</li>
<li>Clarifications on message framing and HPKE contexts (*)</li>
</ul>
<t>draft-06</t>
<ul spacing="normal">
<li>Reorder blanking and update in the Remove operation (*)</li>
<li>Rename the GroupState structure to GroupContext (*)</li>
<li>Rename UserInitKey to ClientInitKey</li>
<li>Resolve the circular dependency that draft-05 introduced in the
confirmation MAC calculation (*)</li>
<li>Cover the entire MLSPlaintext in the transcript hash (*)</li>
</ul>
<t>draft-05</t>
<ul spacing="normal">
<li>Common framing for handshake and application messages (*)</li>
<li>Handshake message encryption (*)</li>
<li>Convert from literal state to a commitment via the "tree hash" (*)
</li>
<li>Add credentials to the tree and remove the "roster" concept (*)</l
i>
<li>Remove the secret field from tree node values</li>
</ul>
<t>draft-04</t>
<ul spacing="normal">
<li>Updating the language to be similar to the Architecture document</
li>
<li>ECIES is now renamed in favor of HPKE (*)</li>
<li>Using a KDF instead of a Hash in TreeKEM (*)</li>
</ul>
<t>draft-03</t>
<ul spacing="normal">
<li>Added ciphersuites and signature schemes (*)</li>
<li>Re-ordered fields in UserInitKey to make parsing easier (*)</li>
<li>Fixed inconsistencies between Welcome and GroupState (*)</li>
<li>Added encryption of the Welcome message (*)</li>
</ul>
<t>draft-02</t>
<ul spacing="normal">
<li>Removed ART (*)</li>
<li>Allowed partial trees to avoid double-joins (*)</li>
<li>Added explicit key confirmation (*)</li>
</ul>
<t>draft-01</t>
<ul spacing="normal">
<li>Initial description of the Message Protection mechanism. (*)</li>
<li>Initial specification proposal for the Application Key Schedule
using the per-participant chaining of the Application Secret design. (*)</li>
<li>Initial specification proposal for an encryption mechanism to prot
ect
Application Messages using an AEAD scheme. (*)</li>
<li>Initial specification proposal for an authentication mechanism
of Application Messages using signatures. (*)</li>
<li>Initial specification proposal for a padding mechanism to improvin
g
protection of Application Messages against traffic analysis. (*)</li>
<li>Inversion of the Group Init Add and Application Secret derivations
in the Handshake Key Schedule to be ease chaining in case we switch
design. (*)</li>
<li>Removal of the UserAdd construct and split of GroupAdd into Add
and Welcome messages (*)</li>
<li>Initial proposal for authenticating handshake messages by signing
over group state and including group state in the key schedule (*)</li>
<li>Added an appendix with example code for tree math</li>
<li>Changed the ECIES mechanism used by TreeKEM so that it uses nonces
generated from the shared secret</li>
</ul>
<t>draft-00</t>
<ul spacing="normal">
<li>Initial adoption of draft-barnes-mls-protocol-01 as a WG item.</li
>
</ul>
</section>
</section> </section>
<section anchor="terminology"> <section anchor="terminology" numbered="true" removeInRFC="false" toc="inclu
<name>Terminology</name> de" pn="section-2">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name slugifiedName="name-terminology">Terminology</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <t indent="0" pn="section-2-1">The key words "<bcp14>MUST</bcp14>", "<bcp1
"OPTIONAL" in this document are to be interpreted as described in 4>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, th SHALL NOT</bcp14>",
ey appear in all "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14
capitals, as shown here.</t> >", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
<dl> "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in
<dt>Client:</dt> BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent
<dd> ="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedC
<t>An agent that uses this protocol to establish shared cryptographic ontent="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.</t>
<dl indent="3" newline="false" spacing="normal" pn="section-2-2">
<dt pn="section-2-2.1">Client:</dt>
<dd pn="section-2-2.2">An agent that uses this protocol to establish sha
red cryptographic
state with other clients. A client is defined by the state with other clients. A client is defined by the
cryptographic keys it holds.</t> cryptographic keys it holds.</dd>
</dd> <dt pn="section-2-2.3">Group:</dt>
<dt>Group:</dt> <dd pn="section-2-2.4">A group represents a logical collection of client
<dd> s that share a common
<t>A group represents a logical collection of clients that share a com
mon
secret value at any given time. Its state is represented as a linear secret value at any given time. Its state is represented as a linear
sequence of epochs in which each epoch depends on its predecessor.</t> sequence of epochs in which each epoch depends on its predecessor.</dd>
</dd> <dt pn="section-2-2.5">Epoch:</dt>
<dt>Epoch:</dt> <dd pn="section-2-2.6">A state of a group in which a specific set of aut
<dd> henticated clients hold
<t>A state of a group in which a specific set of authenticated clients shared cryptographic state.</dd>
hold <dt pn="section-2-2.7">Member:</dt>
shared cryptographic state.</t> <dd pn="section-2-2.8">A client that is included in the shared state of
</dd> a group and hence
<dt>Member:</dt> has access to the group's secrets.</dd>
<dd> <dt pn="section-2-2.9">Key Package:</dt>
<t>A client that is included in the shared state of a group, hence <dd pn="section-2-2.10">A signed object describing a client's identity a
has access to the group's secrets.</t> nd capabilities, including
</dd> a hybrid public key encryption (HPKE) <xref target="RFC9180" format="default" se
<dt>Key Package:</dt> ctionFormat="of" derivedContent="RFC9180"/> public key that
<dd> can be used to encrypt to that client. Other clients can use a client's
<t>A signed object describing a client's identity and capabilities, an KeyPackage to introduce the client to a new group.</dd>
d including <dt pn="section-2-2.11">Group Context:</dt>
a hybrid public-key encryption (HPKE <xref target="RFC9180"/>) public key that <dd pn="section-2-2.12">An object that summarizes the shared, public sta
can be used to encrypt to that client, and which other clients can use to te of the group. The group
introduce the client to a new group.</t>
</dd>
<dt>Group Context:</dt>
<dd>
<t>An object that summarizes the shared, public state of the group. Th
e group
context is typically distributed in a signed GroupInfo message, which is provide d context is typically distributed in a signed GroupInfo message, which is provide d
to new members to help them join a group.</t> to new members to help them join a group.</dd>
</dd> <dt pn="section-2-2.13">Signature Key:</dt>
<dt>Signature Key:</dt> <dd pn="section-2-2.14">A signing key pair used to authenticate the send
<dd> er of a message.</dd>
<t>A signing key pair used to authenticate the sender of a message.</t <dt pn="section-2-2.15">Proposal:</dt>
> <dd pn="section-2-2.16">A message that proposes a change to the group, e
</dd> .g., adding or removing a
<dt>Proposal:</dt> member.</dd>
<dd> <dt pn="section-2-2.17">Commit:</dt>
<t>A message that proposes a change to the group, e.g., adding or remo <dd pn="section-2-2.18">A message that implements the changes to the gro
ving a up proposed in a set of
member.</t> Proposals.</dd>
</dd> <dt pn="section-2-2.19">PublicMessage:</dt>
<dt>Commit:</dt> <dd pn="section-2-2.20">An MLS protocol message that is signed by its se
<dd> nder and authenticated as
<t>A message that implements the changes to the group proposed in a se coming from a member of the group in a particular epoch, but not encrypted.</dd>
t of <dt pn="section-2-2.21">PrivateMessage:</dt>
Proposals.</t> <dd pn="section-2-2.22">An MLS protocol message that is signed by its se
</dd> nder, authenticated as
<dt>PublicMessage:</dt>
<dd>
<t>An MLS protocol message that is signed by its sender and authentica
ted as
coming from a member of the group in a particular epoch, but not encrypted.</t>
</dd>
<dt>PrivateMessage:</dt>
<dd>
<t>An MLS protocol message that is both signed by its sender, authenti
cated as
coming from a member of the group in a particular epoch, and encrypted so coming from a member of the group in a particular epoch, and encrypted so
that it is confidential to the members of the group in that epoch.</t> that it is confidential to the members of the group in that epoch.</dd>
</dd> <dt pn="section-2-2.23">Handshake Message:</dt>
<dt>Handshake Message:</dt> <dd pn="section-2-2.24">A PublicMessage or PrivateMessage carrying an ML
<dd> S Proposal or Commit
<t>A PublicMessage or PrivateMessage carrying an MLS Proposal or Commi object, as opposed to application data.</dd>
t <dt pn="section-2-2.25">Application Message:</dt>
object, as opposed to application data.</t> <dd pn="section-2-2.26">A PrivateMessage carrying application data.</dd>
</dd>
<dt>Application Message:</dt>
<dd>
<t>A PrivateMessage carrying application data.</t>
</dd>
</dl> </dl>
<t>Terminology specific to tree computations is described in <t indent="0" pn="section-2-3">Terminology specific to tree computations i
<xref target="ratchet-tree-terminology"/>.</t> s described in
<t>In general, symmetric values are referred to as "keys" or "secrets" <xref target="ratchet-tree-terminology" format="default" sectionFormat="of" deri
interchangeably. Either term denotes a value that MUST be kept confidential to vedContent="Section 4.1"/>.</t>
a Client. When labeling individual values, we typically use "secret" to refer <t indent="0" pn="section-2-4">In general, symmetric values are referred t
to a value that is used derive further secret values, and "key" to refer to a o as "keys" or "secrets"
value that is used with an algorithm such as HMAC or an AEAD algorithm.</t> interchangeably. Either term denotes a value that <bcp14>MUST</bcp14> be kept c
<t>The PublicMessage and PrivateMessage formats are defined in <xref targe onfidential to
t="message-framing"/>. a client. When labeling individual values, we typically use "secret" to refer
to a value that is used to derive further secret values and "key" to refer to a
value that is used with an algorithm such as Hashed Message Authentication Code
(HMAC) or an Authenticated Encryption with Associated Data (AEAD) algorithm.</t>
<t indent="0" pn="section-2-5">The PublicMessage and PrivateMessage format
s are defined in <xref target="message-framing" format="default" sectionFormat="
of" derivedContent="Section 6"/>.
Security notions such as forward secrecy and post-compromise Security notions such as forward secrecy and post-compromise
security are defined in <xref target="security-considerations"/>.</t> security are defined in <xref target="security-considerations" format="default"
<t>As detailed in <xref target="grease"/>, MLS uses the "Generate Random E sectionFormat="of" derivedContent="Section 16"/>.</t>
xtensions And Sustain <t indent="0" pn="section-2-6">As detailed in <xref target="grease" format
="default" sectionFormat="of" derivedContent="Section 13.5"/>, MLS uses the "Gen
erate Random Extensions And Sustain
Extensibility" (GREASE) approach to maintaining extensibility, where senders ins ert random Extensibility" (GREASE) approach to maintaining extensibility, where senders ins ert random
values into fields in which receivers are required to ignore unknown values. values into fields in which receivers are required to ignore unknown values.
Specific "GREASE values" for this purpose are registered in the appropriate IANA Specific "GREASE values" for this purpose are registered in the appropriate IANA
registries.</t> registries.</t>
<section anchor="presentation-language"> <section anchor="presentation-language" numbered="true" removeInRFC="false
<name>Presentation Language</name> " toc="include" pn="section-2.1">
<t>We use the TLS presentation language <xref target="RFC8446"/> to desc <name slugifiedName="name-presentation-language">Presentation Language</
ribe the structure of name>
<t indent="0" pn="section-2.1-1">We use the TLS presentation language <x
ref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446
"/> to describe the structure of
protocol messages. In addition to the base syntax, we add two additional 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 features: the ability for fields to be optional and the ability for vectors to
have variable-size length headers.</t> have variable-size length headers.</t>
<section anchor="optional-value"> <section anchor="optional-value" numbered="true" removeInRFC="false" toc
<name>Optional Value</name> ="include" pn="section-2.1.1">
<t>An optional value is encoded with a presence-signaling octet, follo <name slugifiedName="name-optional-value">Optional Value</name>
wed by the <t indent="0" pn="section-2.1.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 value itself if present. When decoding, a presence octet with a value other
than 0 or 1 MUST be rejected as malformed.</t> than 0 or 1 <bcp14>MUST</bcp14> be rejected as malformed.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-2.1.1-
2">
struct { struct {
uint8 present; uint8 present;
select (present) { select (present) {
case 0: struct{}; case 0: struct{};
case 1: T value; case 1: T value;
}; };
} optional<T>; } optional&lt;T&gt;;
]]></sourcecode> </sourcecode>
</section> </section>
<section anchor="variable-size-vector-length-headers"> <section anchor="variable-size-vector-length-headers" numbered="true" re
<name>Variable-size Vector Length Headers</name> moveInRFC="false" toc="include" pn="section-2.1.2">
<t>In the TLS presentation language, vectors are encoded as a sequence <name slugifiedName="name-variable-size-vector-length">Variable-Size V
of encoded ector Length Headers</name>
<t indent="0" pn="section-2.1.2-1">In the TLS presentation language, v
ectors are encoded as a sequence of encoded
elements prefixed with a length. The length field has a fixed size set by 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.< /t> specifying the minimum and maximum lengths of the encoded sequence of elements.< /t>
<t>In MLS, there are several vectors whose sizes vary over significant ranges. So <t indent="0" pn="section-2.1.2-2">In MLS, there are several vectors w hose sizes vary over significant ranges. So
instead of using a fixed-size length field, we use a variable-size length using 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 a variable-length integer encoding based on the one described in
<xref target="RFC9000"/>. They differ only in that the one here requires a minim <xref section="16" sectionFormat="of" target="RFC9000" format="default" derivedL
um-size ink="https://rfc-editor.org/rfc/rfc9000#section-16" derivedContent="RFC9000"/>.
They differ only in that the one here requires a minimum-size
encoding. Instead of presenting min and max values, the vector description encoding. Instead of presenting min and max values, the vector description
simply includes a <tt>V</tt>. For example:</t> simply includes a <tt>V</tt>. For example:</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-2.1.2- 3">
struct { struct {
uint32 fixed<0..255>; uint32 fixed&lt;0..255&gt;;
opaque variable<V>; opaque variable&lt;V&gt;;
} StructWithVectors; } StructWithVectors;
]]></sourcecode> </sourcecode>
<t>Such a vector can represent values with length from 0 bytes to 2^30 <t indent="0" pn="section-2.1.2-4">Such a vector can represent values
bytes. with length from 0 bytes to 2<sup>30</sup> bytes.
The variable-length integer encoding reserves the two most significant bits 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 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, so that the in bytes. The integer value is encoded on the remaining bits, so that the
overall value is in network byte order. overall value is in network byte order.
The encoded value MUST use the smallest number of bits required to The encoded value <bcp14>MUST</bcp14> use the smallest number of bits required t
represent the value. When decoding, values using more bits than necessary MUST o
represent the value. When decoding, values using more bits than necessary <bcp1
4>MUST</bcp14>
be treated as malformed.</t> be treated as malformed.</t>
<t>This means that integers are encoded on 1, 2, or 4 bytes and can en <t indent="0" pn="section-2.1.2-5">This means that integers are encode
code 6-, d in 1, 2, or 4 bytes and can encode 6-,
14-, or 30-bit values respectively.</t> 14-, or 30-bit values, respectively.</t>
<table anchor="integer-summary"> <table anchor="integer-summary" align="center" pn="table-1">
<name>Summary of Integer Encodings</name> <name slugifiedName="name-summary-of-integer-encoding">Summary of In
teger Encodings</name>
<thead> <thead>
<tr> <tr>
<th align="left">Prefix</th> <th align="left" colspan="1" rowspan="1">Prefix</th>
<th align="left">Length</th> <th align="left" colspan="1" rowspan="1">Length</th>
<th align="left">Usable Bits</th> <th align="left" colspan="1" rowspan="1">Usable Bits</th>
<th align="left">Min</th> <th align="left" colspan="1" rowspan="1">Min</th>
<th align="left">Max</th> <th align="left" colspan="1" rowspan="1">Max</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">00</td> <td align="left" colspan="1" rowspan="1">00</td>
<td align="left">1</td> <td align="left" colspan="1" rowspan="1">1</td>
<td align="left">6</td> <td align="left" colspan="1" rowspan="1">6</td>
<td align="left">0</td> <td align="left" colspan="1" rowspan="1">0</td>
<td align="left">63</td> <td align="left" colspan="1" rowspan="1">63</td>
</tr> </tr>
<tr> <tr>
<td align="left">01</td> <td align="left" colspan="1" rowspan="1">01</td>
<td align="left">2</td> <td align="left" colspan="1" rowspan="1">2</td>
<td align="left">14</td> <td align="left" colspan="1" rowspan="1">14</td>
<td align="left">64</td> <td align="left" colspan="1" rowspan="1">64</td>
<td align="left">16383</td> <td align="left" colspan="1" rowspan="1">16383</td>
</tr> </tr>
<tr> <tr>
<td align="left">10</td> <td align="left" colspan="1" rowspan="1">10</td>
<td align="left">4</td> <td align="left" colspan="1" rowspan="1">4</td>
<td align="left">30</td> <td align="left" colspan="1" rowspan="1">30</td>
<td align="left">16384</td> <td align="left" colspan="1" rowspan="1">16384</td>
<td align="left">1073741823</td> <td align="left" colspan="1" rowspan="1">1073741823</td>
</tr> </tr>
<tr> <tr>
<td align="left">11</td> <td align="left" colspan="1" rowspan="1">11</td>
<td align="left">invalid</td> <td align="left" colspan="1" rowspan="1">invalid</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Vectors that start with "11" prefix are invalid and MUST be rejecte <t indent="0" pn="section-2.1.2-7">Vectors that start with the prefix
d.</t> "11" are invalid and <bcp14>MUST</bcp14> be rejected.</t>
<t>For example:</t> <t indent="0" pn="section-2.1.2-8">For example:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>The four byte length value 0x9d7f3e7d decodes to 494878333.</li> -2.1.2-9">
<li>The two byte length value 0x7bbd decodes to 15293.</li> <li pn="section-2.1.2-9.1">The four-byte length value 0x9d7f3e7d dec
<li>The single byte length value 0x25 decodes to 37.</li> odes to 494878333.</li>
<li pn="section-2.1.2-9.2">The two-byte length value 0x7bbd decodes
to 15293.</li>
<li pn="section-2.1.2-9.3">The single-byte length value 0x25 decodes
to 37.</li>
</ul> </ul>
<t>The following figure adapts the pseudocode provided in <xref target ="RFC9000"/> to add a <t indent="0" pn="section-2.1.2-10">The following figure adapts the ps eudocode provided in <xref target="RFC9000" format="default" sectionFormat="of" derivedContent="RFC9000"/> to add a
check for minimum-length encoding:</t> check for minimum-length encoding:</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-2.1.2-11">
ReadVarint(data): ReadVarint(data):
// The length of variable-length integers is encoded in the // The length of variable-length integers is encoded in the
// first two bits of the first byte. // first two bits of the first byte.
v = data.next_byte() v = data.next_byte()
prefix = v >&gt; 6 prefix = v >&gt; 6
if prefix == 3: if prefix == 3:
raise Exception('invalid variable length integer prefix') raise Exception('invalid variable length integer prefix')
length = 1 <&lt; prefix length = 1 <&lt; prefix
// Once the length is known, remove these bits and read any // Once the length is known, remove these bits and read any
// remaining bytes. // remaining bytes.
v = v & 0x3f v = v &amp; 0x3f
repeat length-1 times: repeat length-1 times:
v = (v <&lt; 8) + data.next_byte() v = (v <&lt; 8) + data.next_byte()
// Check if the value would fit in half the provided length. // Check if the value would fit in half the provided length.
if prefix >= 1 && v < (1 <&lt; (8*(length/2) - 2)): if prefix >= 1 &amp;&amp; v &lt; (1 &lt;&lt; (8*(length/2) - 2)):
raise Exception('minimum encoding was not used') raise Exception('minimum encoding was not used')
return v return v
]]></sourcecode> </sourcecode>
<t>The use of variable-size integers for vector lengths allows vectors <t indent="0" pn="section-2.1.2-12">The use of variable-size integers
to grow for vector lengths allows vectors to grow
very large, up to 2^30 bytes. Implementations should take care not to allow very large, up to 2<sup>30</sup> bytes. Implementations should take care not to
allow
vectors to overflow available storage. To facilitate debugging of potential vectors to overflow available storage. To facilitate debugging of potential
interoperability problems, implementations SHOULD provide a clear error when interoperability problems, implementations <bcp14>SHOULD</bcp14> provide a clear error when
such an overflow condition occurs.</t> such an overflow condition occurs.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="protocol-overview"> <section anchor="protocol-overview" numbered="true" removeInRFC="false" toc=
<name>Protocol Overview</name> "include" pn="section-3">
<t>MLS is designed to operate in the context described in <name slugifiedName="name-protocol-overview">Protocol Overview</name>
<xref target="I-D.ietf-mls-architecture"/>. In particular, we assume that the fo <t indent="0" pn="section-3-1">MLS is designed to operate in the context d
llowing escribed in
<xref target="I-D.ietf-mls-architecture" format="default" sectionFormat="of" der
ivedContent="MLS-ARCH"/>. In particular, we assume that the following
services are provided:</t> services are provided:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-2
<li>An Authentication Service (AS) that enables group members to authent ">
icate the <li pn="section-3-2.1">An Authentication Service (AS) that enables group
members to authenticate the
credentials presented by other group members.</li> credentials presented by other group members.</li>
<li>A Delivery Service (DS) that routes MLS messages among the participa nts in the <li pn="section-3-2.2">A Delivery Service (DS) that routes MLS messages among the participants in the
protocol.</li> protocol.</li>
</ul> </ul>
<t>MLS assumes a trusted AS but a largely untrusted DS. <xref target="auth entication-service-compromise"/> <t indent="0" pn="section-3-3">MLS assumes a trusted AS but a largely untr usted DS. <xref target="authentication-service-compromise" format="default" sect ionFormat="of" derivedContent="Section 16.10"/>
describes the impact of compromise or describes the impact of compromise or
misbehavior of an AS. MLS is designed to protect the confidentiality and integri ty of misbehavior of an AS. MLS is designed to protect the confidentiality and integri ty of
the group data even in the face of a compromised DS; the group data even in the face of a compromised DS;
in general, the DS is just expected to reliably deliver messages. in general, the DS is only expected to reliably deliver messages.
<xref target="delivery-service-compromise"/> describes the impact of compromise <xref target="delivery-service-compromise" format="default" sectionFormat="of" d
or erivedContent="Section 16.9"/> describes the impact of compromise or
misbehavior of a DS.</t> misbehavior of a DS.</t>
<t>The core functionality of MLS is continuous group authenticated key exc hange <t indent="0" pn="section-3-4">The core functionality of MLS is continuous group authenticated key exchange
(AKE). As with other authenticated key exchange protocols (such as TLS), the (AKE). As with other authenticated key exchange protocols (such as TLS), the
participants in the protocol agree on a common secret value, and each participants in the protocol agree on a common secret value, and each
participant can verify the identity of the other participants. That secret participant can verify the identity of the other participants. That secret
can then be used to protect messages sent from one participant in the can then be used to protect messages sent from one participant in the
group to the other participants using the MLS framing layer group to the other participants using the MLS framing layer
or can be exported for use with other protocols. MLS provides or can be exported for use with other protocols. MLS provides
group AKE in the sense that there can be more than two participants in the group AKE in the sense that there can be more than two participants in the
protocol, and continuous group AKE in the sense that the set of participants in protocol, and continuous group AKE in the sense that the set of participants in
the protocol can change over time.</t> the protocol can change over time.</t>
<t>The core organizing principles of MLS are <em>groups</em> and <em>epoch s</em>. A group <t indent="0" pn="section-3-5">The core organizing principles of MLS are < em>groups</em> and <em>epochs</em>. A group
represents a logical collection of clients that share a common secret value at represents a logical collection of clients that share a common secret value at
any given time. The history of a group is divided into a linear sequence of any given time. The history of a group is divided into a linear sequence of
epochs. In each epoch, a set of authenticated <em>members</em> agree on an <em> epoch epochs. In each epoch, a set of authenticated <em>members</em> agree on an <em> epoch
secret</em> that is known only to the members of the group in that epoch. The s et secret</em> that is known only to the members of the group in that epoch. The s et
of members involved in the group can change from one epoch to the next, and MLS of members involved in the group can change from one epoch to the next, and MLS
ensures that only the members in the current epoch have access to the epoch ensures that only the members in the current epoch have access to the epoch
secret. From the epoch secret, members derive further shared secrets for secret. From the epoch secret, members derive further shared secrets for
message encryption, group membership authentication, and so on.</t> message encryption, group membership authentication, and so on.</t>
<t>The creator of an MLS group creates the group's first epoch unilaterall y, with <t indent="0" pn="section-3-6">The creator of an MLS group creates the gro up's first epoch unilaterally, with
no protocol interactions. Thereafter, the members of the group advance their no protocol interactions. Thereafter, the members of the group advance their
shared cryptographic state from one epoch to another by exchanging MLS messages. </t> shared cryptographic state from one epoch to another by exchanging MLS messages. </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-7
<li>A <em>KeyPackage</em> object describes a client's capabilities and p ">
rovides keys that <li pn="section-3-7.1">A <em>KeyPackage</em> object describes a client's
capabilities and provides keys that
can be used to add the client to a group.</li> can be used to add the client to a group.</li>
<li>A <em>Proposal</em> message proposes a change to be made in the next <li pn="section-3-7.2">A <em>Proposal</em> message proposes a change to
epoch, such as be made in the next epoch, such as
adding or removing a member</li> adding or removing a member.</li>
<li>A <em>Commit</em> message initiates a new epoch by instructing membe <li pn="section-3-7.3">A <em>Commit</em> message initiates a new epoch b
rs of the group y instructing members of the group
to implement a collection of proposals</li> to implement a collection of proposals.</li>
<li>A <em>Welcome</em> message provides a new member to the group with t <li pn="section-3-7.4">A <em>Welcome</em> message provides a new member
he information to to the group with the information to
initialize their state for the epoch in which they were added or in which they initialize their state for the epoch in which they were added or in which they
want to add themselves to the group</li> want to add themselves to the group.</li>
</ul> </ul>
<t>KeyPackage and Welcome messages are used to initiate a group or introdu ce new <t indent="0" pn="section-3-8">KeyPackage and Welcome messages are used to initiate a group or introduce new
members, so they are exchanged between group members and clients not yet in the members, so they are exchanged between group members and clients not yet in the
group. A client publishes a KeyPackage via the DS, thus enabling other group. A client publishes a KeyPackage via the DS, thus enabling other
clients to add it to groups. When a group member wants to add a new member clients to add it to groups. When a group member wants to add a new member to a
to a group it uses the new member's KeyPackage to add the new member to group, it uses the new member's KeyPackage to add them and constructs a Welcome
the group and construct a Welcome message with which the new member can message with which the new member can initialize their local state.</t>
initialize its local state.</t> <t indent="0" pn="section-3-9">Proposal and Commit messages are sent from
<t>Proposal and Commit messages are sent from one member of a group to the one member of a group to the others.
others.
MLS provides a common framing layer for sending messages within a group: MLS provides a common framing layer for sending messages within a group:
A <em>PublicMessage</em> provides sender authentication for unencrypted Proposal and Commit A <em>PublicMessage</em> provides sender authentication for unencrypted Proposal and Commit
messages. A <em>PrivateMessage</em> provides encryption and authentication for messages. A <em>PrivateMessage</em> provides encryption and authentication for
both Proposal/Commit messages as well as any application data.</t> both Proposal/Commit messages as well as any application data.</t>
<section anchor="cryptographic-state-and-evolution"> <section anchor="cryptographic-state-and-evolution" numbered="true" remove
<name>Cryptographic State and Evolution</name> InRFC="false" toc="include" pn="section-3.1">
<t>The cryptographic state at the core of MLS is divided into three area <name slugifiedName="name-cryptographic-state-and-evo">Cryptographic Sta
s of responsibility:</t> te and Evolution</name>
<figure> <t indent="0" pn="section-3.1-1">The cryptographic state at the core of
<name>Overview of MLS group evolution</name> MLS is divided into three areas of responsibility:</t>
<artset> <figure align="left" suppress-title="false" pn="figure-1">
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= <name slugifiedName="name-overview-of-mls-group-evolu">Overview of MLS
"1.1" height="400" width="584" viewBox="0 0 584 400" class="diagram" text-anchor Group Evolution</name>
="middle" font-family="monospace" font-size="13px"> <artset pn="section-3.1-2.1">
<artwork type="svg" align="left" pn="section-3.1-2.1.1">
<svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-famil
y="monospace" font-size="13px" height="400" text-anchor="middle" version="1.1" v
iewBox="0 0 584 400" width="584">
<path d="M 8,128 L 8,288" fill="none" stroke="black"/> <path d="M 8,128 L 8,288" fill="none" stroke="black"/>
<path d="M 208,48 L 208,200" fill="none" stroke="black"/> <path d="M 208,48 L 208,200" fill="none" stroke="black"/>
<path d="M 208,216 L 208,368" fill="none" stroke="black"/> <path d="M 208,216 L 208,368" fill="none" stroke="black"/>
<path d="M 272,64 L 272,96" fill="none" stroke="black"/> <path d="M 272,64 L 272,96" fill="none" stroke="black"/>
<path d="M 272,120 L 272,192" fill="none" stroke="black"/> <path d="M 272,120 L 272,192" fill="none" stroke="black"/>
<path d="M 272,216 L 272,288" fill="none" stroke="black"/> <path d="M 272,216 L 272,288" fill="none" stroke="black"/>
<path d="M 272,312 L 272,352" fill="none" stroke="black"/> <path d="M 272,312 L 272,352" fill="none" stroke="black"/>
<path d="M 336,48 L 336,200" fill="none" stroke="black"/> <path d="M 336,48 L 336,200" fill="none" stroke="black"/>
<path d="M 336,216 L 336,368" fill="none" stroke="black"/> <path d="M 336,216 L 336,368" fill="none" stroke="black"/>
<path d="M 576,128 L 576,288" fill="none" stroke="black"/> <path d="M 576,128 L 576,288" fill="none" stroke="black"/>
skipping to change at line 686 skipping to change at line 852
<path d="M 336,208 L 352,208" fill="none" stroke="black"/> <path d="M 336,208 L 352,208" fill="none" stroke="black"/>
<path d="M 512,208 L 528,208" fill="none" stroke="black"/> <path d="M 512,208 L 528,208" fill="none" stroke="black"/>
<path d="M 8,128 L 48,208" fill="none" stroke="black"/> <path d="M 8,128 L 48,208" fill="none" stroke="black"/>
<path d="M 536,208 L 576,288" fill="none" stroke="black"/> <path d="M 536,208 L 576,288" fill="none" stroke="black"/>
<path d="M 8,288 L 48,208" fill="none" stroke="black"/> <path d="M 8,288 L 48,208" fill="none" stroke="black"/>
<path d="M 536,208 L 576,128" fill="none" stroke="black"/> <path d="M 536,208 L 576,128" fill="none" stroke="black"/>
<path d="M 224,32 C 215.16936,32 208,39.16936 208,48" fill="none " stroke="black"/> <path d="M 224,32 C 215.16936,32 208,39.16936 208,48" fill="none " stroke="black"/>
<path d="M 320,32 C 328.83064,32 336,39.16936 336,48" fill="none " stroke="black"/> <path d="M 320,32 C 328.83064,32 336,39.16936 336,48" fill="none " stroke="black"/>
<path d="M 224,384 C 215.16936,384 208,376.83064 208,368" fill=" none" stroke="black"/> <path d="M 224,384 C 215.16936,384 208,376.83064 208,368" fill=" none" stroke="black"/>
<path d="M 320,384 C 328.83064,384 336,376.83064 336,368" fill=" none" stroke="black"/> <path d="M 320,384 C 328.83064,384 336,376.83064 336,368" fill=" none" stroke="black"/>
<polygon class="arrowhead" points="536,208 524,202.4 524,213.6" <polygon class="arrowhead" fill="black" points="536,208 524,202.
fill="black" transform="rotate(0,528,208)"/> 4 524,213.6" transform="rotate(0,528,208)"/>
<polygon class="arrowhead" points="360,208 348,202.4 348,213.6" <polygon class="arrowhead" fill="black" points="360,208 348,202.
fill="black" transform="rotate(0,352,208)"/> 4 348,213.6" transform="rotate(0,352,208)"/>
<polygon class="arrowhead" points="280,352 268,346.4 268,357.6" <polygon class="arrowhead" fill="black" points="280,352 268,346.
fill="black" transform="rotate(90,272,352)"/> 4 268,357.6" transform="rotate(90,272,352)"/>
<polygon class="arrowhead" points="280,288 268,282.4 268,293.6" <polygon class="arrowhead" fill="black" points="280,288 268,282.
fill="black" transform="rotate(90,272,288)"/> 4 268,293.6" transform="rotate(90,272,288)"/>
<polygon class="arrowhead" points="280,192 268,186.4 268,197.6" <polygon class="arrowhead" fill="black" points="280,192 268,186.
fill="black" transform="rotate(90,272,192)"/> 4 268,197.6" transform="rotate(90,272,192)"/>
<polygon class="arrowhead" points="280,96 268,90.4 268,101.6" fi <polygon class="arrowhead" fill="black" points="280,96 268,90.4
ll="black" transform="rotate(90,272,96)"/> 268,101.6" transform="rotate(90,272,96)"/>
<polygon class="arrowhead" points="224,208 212,202.4 212,213.6" <polygon class="arrowhead" fill="black" points="224,208 212,202.
fill="black" transform="rotate(0,216,208)"/> 4 212,213.6" transform="rotate(0,216,208)"/>
<polygon class="arrowhead" points="80,208 68,202.4 68,213.6" fil <polygon class="arrowhead" fill="black" points="80,208 68,202.4
l="black" transform="rotate(0,72,208)"/> 68,213.6" transform="rotate(0,72,208)"/>
<g class="text"> <g class="text">
<text x="272" y="36">...</text> <text x="272" y="36">...</text>
<text x="360" y="84">Key</text> <text x="360" y="84">Key</text>
<text x="412" y="84">Schedule</text> <text x="412" y="84">Schedule</text>
<text x="276" y="116">epoch_secret</text> <text x="276" y="116">epoch_secret</text>
<text x="56" y="148">Ratchet</text> <text x="56" y="148">Ratchet</text>
<text x="532" y="148">Secret</text> <text x="532" y="148">Secret</text>
<text x="52" y="164">Tree</text> <text x="52" y="164">Tree</text>
<text x="532" y="164">Tree</text> <text x="532" y="164">Tree</text>
<text x="136" y="212">commit_secret</text> <text x="136" y="212">commit_secret</text>
<text x="276" y="212">epoch_secret</text> <text x="276" y="212">epoch_secret</text>
<text x="432" y="212">encryption_secret</text> <text x="432" y="212">encryption_secret</text>
<text x="276" y="308">epoch_secret</text> <text x="276" y="308">epoch_secret</text>
<text x="272" y="388">...</text> <text x="272" y="388">...</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-3.1-2.1.2">
.- ... -. .- ... -.
| | | |
| | | | | |
| | | Key Schedule | | | Key Schedule
| V | | V |
| epoch_secret | | epoch_secret |
. | | | . . | | | .
|\ Ratchet | | | Secret /| |\ Ratchet | | | Secret /|
| \ Tree | | | Tree / | | \ Tree | | | Tree / |
| \ | | | / | | \ | | | / |
| \ | V | / | | \ | V | / |
| +--> commit_secret --> epoch_secret --> encryption_secret -->+ | | +--> commit_secret --&gt; epoch_secret --&gt; encryption_secret --&gt;+ |
| / | | | \ | | / | | | \ |
| / | | | \ | | / | | | \ |
| / | | | \ | | / | | | \ |
|/ | | | \| |/ | | | \|
' | V | ' ' | V | '
| epoch_secret | | epoch_secret |
| | | | | |
| | | | | |
| V | | V |
| | | |
'- ... -' '- ... -'
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3
<li>A <em>ratchet tree</em> that represents the membership of the grou .1-3">
p, providing group <li pn="section-3.1-3.1">A <em>ratchet tree</em> that represents the m
embership of the group, providing group
members a way to authenticate each other and efficiently encrypt messages to members a way to authenticate each other and efficiently encrypt messages to
subsets of the group. Each epoch has a distinct ratchet tree. It seeds the subsets of the group. Each epoch has a distinct ratchet tree. It seeds the
<em>key schedule</em>.</li> <em>key schedule</em>.</li>
<li> <li pn="section-3.1-3.2">
<t>A <em>key schedule</em> that describes the chain of key derivatio <t indent="0" pn="section-3.1-3.2.1">A <em>key schedule</em> that de
ns used to progress from scribes the chain of key derivations used to progress from
epoch to epoch (mainly using the <em>init_secret</em> and <em>epoch_secret</em>) , as well as the derivation of epoch to epoch (mainly using the <em>init_secret</em> and <em>epoch_secret</em>) , as well as the derivation of
a variety of other secrets (see <xref target="epoch-derived-secrets"/>), for exa mple: a variety of other secrets (see <xref target="epoch-derived-secrets" format="def ault" sectionFormat="of" derivedContent="Table 4"/>). For example:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>An <em>encryption secret</em> that is used to initialize the s on-3.1-3.2.2">
ecret tree for the <li pn="section-3.1-3.2.2.1">An <em>encryption secret</em> that is
used to initialize the secret tree for the
epoch.</li> epoch.</li>
<li>An <em>exporter secret</em> that allows other protocols to lev erage MLS as a <li pn="section-3.1-3.2.2.2">An <em>exporter secret</em> that allo ws other protocols to leverage MLS as a
generic authenticated group key exchange.</li> generic authenticated group key exchange.</li>
<li>A <em>resumption secret</em> that members can use to prove the ir membership in the <li pn="section-3.1-3.2.2.3">A <em>resumption secret</em> that mem bers can use to prove their membership in the
group, e.g., when creating a subgroup or a successor group.</li> group, e.g., when creating a subgroup or a successor group.</li>
</ul> </ul>
</li> </li>
<li>A <em>secret tree</em> derived from the key schedule that represen ts shared secrets <li pn="section-3.1-3.3">A <em>secret tree</em> derived from the key s chedule that represents shared secrets
used by the members of the group for encrypting and authenticating messages. used by the members of the group for encrypting and authenticating messages.
Each epoch has a distinct secret tree.</li> Each epoch has a distinct secret tree.</li>
</ul> </ul>
<t>Each member of the group maintains a partial view of these components of the group's <t indent="0" pn="section-3.1-4">Each member of the group maintains a pa rtial view of these components of the group's
state. MLS messages are used to initialize these views and keep them in sync as state. MLS messages are used to initialize these views and keep them in sync as
the group transitions between epochs.</t> the group transitions between epochs.</t>
<t>Each new epoch is initiated with a Commit message. The Commit instru cts <t indent="0" pn="section-3.1-5">Each new epoch is initiated with a Comm it message. The Commit instructs
existing members of the group to update their views of the ratchet tree by apply ing existing members of the group to update their views of the ratchet tree by apply ing
a set of Proposals, and uses the updated ratchet tree to distribute fresh a set of Proposals, and uses the updated ratchet tree to distribute fresh
entropy to the group. This fresh entropy is provided only to members in the new entropy to the group. This fresh entropy is provided only to members in the new
epoch and not to members who have been removed. Commits thus maintain the proper ty that epoch and not to members who have been removed. Commits thus maintain the proper ty that
the epoch secret is confidential to the members in the current epoch.</t> the epoch secret is confidential to the members in the current epoch.</t>
<t>For each Commit that adds one or more members to the group, there are one or more corresponding <t indent="0" pn="section-3.1-6">For each Commit that adds one or more m embers to the group, there are one or more corresponding
Welcome messages. Each Welcome message provides new members with the informatio n Welcome messages. Each Welcome message provides new members with the informatio n
they need to initialize their views of the key schedule and ratchet tree, so they need to initialize their views of the key schedule and ratchet tree, so
that these views align with the views held by other members of the group that these views align with the views held by other members of the group
in this epoch.</t> in this epoch.</t>
</section> </section>
<section anchor="example-protocol-execution"> <section anchor="example-protocol-execution" numbered="true" removeInRFC="
<name>Example Protocol Execution</name> false" toc="include" pn="section-3.2">
<t>There are three major operations in the lifecycle of a group:</t> <name slugifiedName="name-example-protocol-execution">Example Protocol E
<ul spacing="normal"> xecution</name>
<li>Adding a member, initiated by a current member;</li> <t indent="0" pn="section-3.2-1">There are three major operations in the
<li>Updating the keys that represent a member in the tree;</li> life of a group:</t>
<li>Removing a member.</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3
.2-2">
<li pn="section-3.2-2.1">Adding a member, initiated by a current membe
r;</li>
<li pn="section-3.2-2.2">Updating the keys that represent a member in
the tree; and</li>
<li pn="section-3.2-2.3">Removing a member.</li>
</ul> </ul>
<t>Each of these operations is "proposed" by sending a message of the co rresponding <t indent="0" pn="section-3.2-3">Each of these operations is "proposed" by sending a message of the corresponding
type (Add / Update / Remove). The state of the group is not changed, however, type (Add / Update / Remove). The state of the group is not changed, however,
until a Commit message is sent to provide the group with fresh entropy. In this until a Commit message is sent to provide the group with fresh entropy. In this
section, we show each proposal being committed immediately, but in more advanced section, we show each proposal being committed immediately, but in more advanced
deployment cases an application might gather several proposals before deployment cases, an application might gather several proposals before
committing them all at once. In the illustrations below, we show the Proposal committing them all at once. In the illustrations below, we show the Proposal
and Commit messages directly, while in reality they would be sent encapsulated i n and Commit messages directly, while in reality they would be sent encapsulated i n
PublicMessage or PrivateMessage objects.</t> PublicMessage or PrivateMessage objects.</t>
<t>Before the initialization of a group, clients publish KeyPackages to <t indent="0" pn="section-3.2-4">Before the initialization of a group, c
a directory lients publish KeyPackages to a directory
provided by the DS (see <xref target="prepublish-flow"/>).</t> provided by the DS (see <xref target="prepublish-flow" format="default" sectionF
<figure anchor="prepublish-flow"> ormat="of" derivedContent="Figure 2"/>).</t>
<name>Clients A, B, and C publish KeyPackages to the directory</name> <figure anchor="prepublish-flow" align="left" suppress-title="false" pn=
<artset> "figure-2">
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= <name slugifiedName="name-clients-a-b-and-c-publish-k">Clients A, B, a
"1.1" height="288" width="568" viewBox="0 0 568 288" class="diagram" text-anchor nd C publish KeyPackages to the directory</name>
="middle" font-family="monospace" font-size="13px"> <artset pn="section-3.2-5.1">
<artwork type="svg" align="left" pn="section-3.2-5.1.1">
<svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-famil
y="monospace" font-size="13px" height="288" text-anchor="middle" version="1.1" v
iewBox="0 0 568 288" width="568">
<path d="M 8,128 L 8,272" fill="none" stroke="black"/> <path d="M 8,128 L 8,272" fill="none" stroke="black"/>
<path d="M 144,128 L 144,152" fill="none" stroke="black"/> <path d="M 144,128 L 144,152" fill="none" stroke="black"/>
<path d="M 144,168 L 144,272" fill="none" stroke="black"/> <path d="M 144,168 L 144,272" fill="none" stroke="black"/>
<path d="M 280,128 L 280,152" fill="none" stroke="black"/> <path d="M 280,128 L 280,152" fill="none" stroke="black"/>
<path d="M 280,168 L 280,200" fill="none" stroke="black"/> <path d="M 280,168 L 280,200" fill="none" stroke="black"/>
<path d="M 280,216 L 280,272" fill="none" stroke="black"/> <path d="M 280,216 L 280,272" fill="none" stroke="black"/>
<path d="M 416,128 L 416,272" fill="none" stroke="black"/> <path d="M 416,128 L 416,272" fill="none" stroke="black"/>
<path d="M 536,128 L 536,272" fill="none" stroke="black"/> <path d="M 536,128 L 536,272" fill="none" stroke="black"/>
<path d="M 400,64 L 456,64" fill="none" stroke="black"/> <path d="M 400,64 L 456,64" fill="none" stroke="black"/>
<path d="M 488,64 L 544,64" fill="none" stroke="black"/> <path d="M 488,64 L 544,64" fill="none" stroke="black"/>
<path d="M 8,160 L 408,160" fill="none" stroke="black"/> <path d="M 8,160 L 408,160" fill="none" stroke="black"/>
<path d="M 144,208 L 408,208" fill="none" stroke="black"/> <path d="M 144,208 L 408,208" fill="none" stroke="black"/>
<path d="M 280,256 L 408,256" fill="none" stroke="black"/> <path d="M 280,256 L 408,256" fill="none" stroke="black"/>
<path d="M 400,64 C 391.16936,64 384,71.16936 384,80" fill="none " stroke="black"/> <path d="M 400,64 C 391.16936,64 384,71.16936 384,80" fill="none " stroke="black"/>
<path d="M 456,64 C 464.83064,64 472,56.83064 472,48" fill="none " stroke="black"/> <path d="M 456,64 C 464.83064,64 472,56.83064 472,48" fill="none " stroke="black"/>
<path d="M 488,64 C 479.16936,64 472,56.83064 472,48" fill="none " stroke="black"/> <path d="M 488,64 C 479.16936,64 472,56.83064 472,48" fill="none " stroke="black"/>
<path d="M 544,64 C 552.83064,64 560,71.16936 560,80" fill="none " stroke="black"/> <path d="M 544,64 C 552.83064,64 560,71.16936 560,80" fill="none " stroke="black"/>
<polygon class="arrowhead" points="416,256 404,250.4 404,261.6" <polygon class="arrowhead" fill="black" points="416,256 404,250.
fill="black" transform="rotate(0,408,256)"/> 4 404,261.6" transform="rotate(0,408,256)"/>
<polygon class="arrowhead" points="416,208 404,202.4 404,213.6" <polygon class="arrowhead" fill="black" points="416,208 404,202.
fill="black" transform="rotate(0,408,208)"/> 4 404,213.6" transform="rotate(0,408,208)"/>
<polygon class="arrowhead" points="416,160 404,154.4 404,165.6" <polygon class="arrowhead" fill="black" points="416,160 404,154.
fill="black" transform="rotate(0,408,160)"/> 4 404,165.6" transform="rotate(0,408,160)"/>
<g class="text"> <g class="text">
<text x="436" y="36">Delivery</text> <text x="436" y="36">Delivery</text>
<text x="504" y="36">Service</text> <text x="504" y="36">Service</text>
<text x="528" y="100">Group</text> <text x="528" y="100">Group</text>
<text x="8" y="116">A</text> <text x="8" y="116">A</text>
<text x="144" y="116">B</text> <text x="144" y="116">B</text>
<text x="280" y="116">C</text> <text x="280" y="116">C</text>
<text x="416" y="116">Directory</text> <text x="416" y="116">Directory</text>
<text x="536" y="116">Channel</text> <text x="536" y="116">Channel</text>
<text x="64" y="148">KeyPackageA</text> <text x="64" y="148">KeyPackageA</text>
<text x="200" y="196">KeyPackageB</text> <text x="200" y="196">KeyPackageB</text>
<text x="336" y="244">KeyPackageC</text> <text x="336" y="244">KeyPackageC</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-3.2-5.1.2">
Delivery Service Delivery Service
| |
.--------' '--------. .--------' '--------.
| | | |
Group Group
A B C Directory Channel A B C Directory Channel
| | | | | | | | | |
| KeyPackageA | | | | | KeyPackageA | | | |
+------------------------------------------------->| | +-------------------------------------------------&gt;| |
| | | | | | | | | |
| | KeyPackageB | | | | | KeyPackageB | | |
| +-------------------------------->| | | +--------------------------------&gt;| |
| | | | | | | | | |
| | | KeyPackageC | | | | | KeyPackageC | |
| | +--------------->| | | | +---------------&gt;| |
| | | | | | | | | |
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t><xref target="create-flow"/> shows how these prepublished KeyPackages <t indent="0" pn="section-3.2-6"><xref target="create-flow" format="defa
are used to create a group. ult" sectionFormat="of" derivedContent="Figure 3"/> shows how these pre-publishe
When a client A wants to establish a group with B and C, it first initializes a d KeyPackages are used to create a group.
When client A wants to establish a group with clients B and C, it first initiali
zes a
group state containing only itself and downloads KeyPackages for B and C. For group state containing only itself and downloads KeyPackages for B and C. For
each member, A generates an Add and Commit message adding that member, and each member, A generates an Add proposal and a Commit message to add that member
broadcasts them to the group. It also generates a Welcome message and sends this and then
broadcasts the two messages to the group. Client A also generates a Welcome mess
age and sends it
directly to the new member (there's no need to send it to the group). Only after directly to the new member (there's no need to send it to the group). Only after
A has received its Commit message back from the Delivery Service does it update its A has received its Commit message back from the Delivery Service does it update its
state to reflect the new member's addition.</t> state to reflect the new member's addition.</t>
<t>Once A has updated its state, the new member has processed the Welcom e, and any <t indent="0" pn="section-3.2-7">Once A has updated its state, the new m ember has processed the Welcome, and any
other group members have processed the Commit, they will all have consistent other group members have processed the Commit, they will all have consistent
representations of the group state, including a group secret that is known only representations of the group state, including a group secret that is known only
to the members the group. The new member will be able to read and send new to the members the group. The new member will be able to read and send new
messages to the group, but messages sent before they were added to the group messages to the group, but messages sent before they were added to the group
will not be accessible.</t> will not be accessible.</t>
<figure anchor="create-flow"> <figure anchor="create-flow" align="left" suppress-title="false" pn="fig
<name>Client A creates a group with clients B and C</name> ure-3">
<artset> <name slugifiedName="name-client-a-creates-a-group-wi">Client A create
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= s a group with clients B and C</name>
"1.1" height="512" width="560" viewBox="0 0 560 512" class="diagram" text-anchor <artset pn="section-3.2-8.1">
="middle" font-family="monospace" font-size="13px"> <artwork type="svg" align="left" pn="section-3.2-8.1.1">
<svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-famil
y="monospace" font-size="13px" height="512" text-anchor="middle" version="1.1" v
iewBox="0 0 560 512" width="560">
<path d="M 8,64 L 8,496" fill="none" stroke="black"/> <path d="M 8,64 L 8,496" fill="none" stroke="black"/>
<path d="M 128,104 L 128,152" fill="none" stroke="black"/> <path d="M 128,104 L 128,152" fill="none" stroke="black"/>
<path d="M 128,168 L 128,264" fill="none" stroke="black"/> <path d="M 128,168 L 128,264" fill="none" stroke="black"/>
<path d="M 128,280 L 128,344" fill="none" stroke="black"/> <path d="M 128,280 L 128,344" fill="none" stroke="black"/>
<path d="M 128,360 L 128,392" fill="none" stroke="black"/> <path d="M 128,360 L 128,392" fill="none" stroke="black"/>
<path d="M 128,408 L 128,456" fill="none" stroke="black"/> <path d="M 128,408 L 128,456" fill="none" stroke="black"/>
<path d="M 128,472 L 128,496" fill="none" stroke="black"/> <path d="M 128,472 L 128,496" fill="none" stroke="black"/>
<path d="M 248,104 L 248,152" fill="none" stroke="black"/> <path d="M 248,104 L 248,152" fill="none" stroke="black"/>
<path d="M 248,168 L 248,264" fill="none" stroke="black"/> <path d="M 248,168 L 248,264" fill="none" stroke="black"/>
<path d="M 248,280 L 248,344" fill="none" stroke="black"/> <path d="M 248,280 L 248,344" fill="none" stroke="black"/>
skipping to change at line 895 skipping to change at line 1063
<path d="M 368,360 L 368,456" fill="none" stroke="black"/> <path d="M 368,360 L 368,456" fill="none" stroke="black"/>
<path d="M 528,64 L 528,496" fill="none" stroke="black"/> <path d="M 528,64 L 528,496" fill="none" stroke="black"/>
<path d="M 16,96 L 368,96" fill="none" stroke="black"/> <path d="M 16,96 L 368,96" fill="none" stroke="black"/>
<path d="M 8,160 L 520,160" fill="none" stroke="black"/> <path d="M 8,160 L 520,160" fill="none" stroke="black"/>
<path d="M 8,208 L 120,208" fill="none" stroke="black"/> <path d="M 8,208 L 120,208" fill="none" stroke="black"/>
<path d="M 16,272 L 528,272" fill="none" stroke="black"/> <path d="M 16,272 L 528,272" fill="none" stroke="black"/>
<path d="M 8,352 L 520,352" fill="none" stroke="black"/> <path d="M 8,352 L 520,352" fill="none" stroke="black"/>
<path d="M 8,400 L 240,400" fill="none" stroke="black"/> <path d="M 8,400 L 240,400" fill="none" stroke="black"/>
<path d="M 16,464 L 528,464" fill="none" stroke="black"/> <path d="M 16,464 L 528,464" fill="none" stroke="black"/>
<path d="M 136,480 L 528,480" fill="none" stroke="black"/> <path d="M 136,480 L 528,480" fill="none" stroke="black"/>
<polygon class="arrowhead" points="528,352 516,346.4 516,357.6" <polygon class="arrowhead" fill="black" points="528,352 516,346.
fill="black" transform="rotate(0,520,352)"/> 4 516,357.6" transform="rotate(0,520,352)"/>
<polygon class="arrowhead" points="528,160 516,154.4 516,165.6" <polygon class="arrowhead" fill="black" points="528,160 516,154.
fill="black" transform="rotate(0,520,160)"/> 4 516,165.6" transform="rotate(0,520,160)"/>
<polygon class="arrowhead" points="248,400 236,394.4 236,405.6" <polygon class="arrowhead" fill="black" points="248,400 236,394.
fill="black" transform="rotate(0,240,400)"/> 4 236,405.6" transform="rotate(0,240,400)"/>
<polygon class="arrowhead" points="144,480 132,474.4 132,485.6" <polygon class="arrowhead" fill="black" points="144,480 132,474.
fill="black" transform="rotate(180,136,480)"/> 4 132,485.6" transform="rotate(180,136,480)"/>
<polygon class="arrowhead" points="128,208 116,202.4 116,213.6" <polygon class="arrowhead" fill="black" points="128,208 116,202.
fill="black" transform="rotate(0,120,208)"/> 4 116,213.6" transform="rotate(0,120,208)"/>
<polygon class="arrowhead" points="24,464 12,458.4 12,469.6" fil <polygon class="arrowhead" fill="black" points="24,464 12,458.4
l="black" transform="rotate(180,16,464)"/> 12,469.6" transform="rotate(180,16,464)"/>
<polygon class="arrowhead" points="24,272 12,266.4 12,277.6" fil <polygon class="arrowhead" fill="black" points="24,272 12,266.4
l="black" transform="rotate(180,16,272)"/> 12,277.6" transform="rotate(180,16,272)"/>
<polygon class="arrowhead" points="24,96 12,90.4 12,101.6" fill= <polygon class="arrowhead" fill="black" points="24,96 12,90.4 12
"black" transform="rotate(180,16,96)"/> ,101.6" transform="rotate(180,16,96)"/>
<g class="text"> <g class="text">
<text x="528" y="36">Group</text> <text x="528" y="36">Group</text>
<text x="8" y="52">A</text> <text x="8" y="52">A</text>
<text x="128" y="52">B</text> <text x="128" y="52">B</text>
<text x="248" y="52">C</text> <text x="248" y="52">C</text>
<text x="368" y="52">Directory</text> <text x="368" y="52">Directory</text>
<text x="528" y="52">Channel</text> <text x="528" y="52">Channel</text>
<text x="128" y="68">|</text> <text x="128" y="68">|</text>
<text x="248" y="68">|</text> <text x="248" y="68">|</text>
<text x="132" y="84">KeyPackageB,</text> <text x="132" y="84">KeyPackageB,</text>
skipping to change at line 929 skipping to change at line 1097
<text x="428" y="324">Add(AB-&gt;ABC)</text> <text x="428" y="324">Add(AB-&gt;ABC)</text>
<text x="424" y="340">Commit(Add)</text> <text x="424" y="340">Commit(Add)</text>
<text x="188" y="388">Welcome(C)</text> <text x="188" y="388">Welcome(C)</text>
<text x="428" y="436">Add(AB-&gt;ABC)</text> <text x="428" y="436">Add(AB-&gt;ABC)</text>
<text x="424" y="452">Commit(Add)</text> <text x="424" y="452">Commit(Add)</text>
<text x="248" y="500">|</text> <text x="248" y="500">|</text>
<text x="368" y="500">|</text> <text x="368" y="500">|</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-3.2-8.1.2">
Group Group
A B C Directory Channel A B C Directory Channel
| | | | | | | | | |
| KeyPackageB, KeyPackageC | | | KeyPackageB, KeyPackageC | |
|<-------------------------------------------+ | |&lt;-------------------------------------------+ |
| | | | | | | | | |
| | | | Add(A->AB) | | | | | Add(A-&gt;AB) |
| | | | Commit(Add) | | | | | Commit(Add) |
+--------------------------------------------------------------->| +---------------------------------------------------------------&gt;|
| | | | | | | | | |
| Welcome(B) | | | | | Welcome(B) | | | |
+------------->| | | | +-------------&gt;| | | |
| | | | | | | | | |
| | | | Add(A->AB) | | | | | Add(A-&gt;AB) |
| | | | Commit(Add) | | | | | Commit(Add) |
|<---------------------------------------------------------------+ |&lt;---------------------------------------------------------------+
| | | | | | | | | |
| | | | | | | | | |
| | | | Add(AB->ABC) | | | | | Add(AB-&gt;ABC) |
| | | | Commit(Add) | | | | | Commit(Add) |
+--------------------------------------------------------------->| +---------------------------------------------------------------&gt;|
| | | | | | | | | |
| | Welcome(C) | | | | | Welcome(C) | | |
+---------------------------->| | | +----------------------------&gt;| | |
| | | | | | | | | |
| | | | Add(AB->ABC) | | | | | Add(AB-&gt;ABC) |
| | | | Commit(Add) | | | | | Commit(Add) |
|<---------------------------------------------------------------+ |&lt;---------------------------------------------------------------+
| |<------------------------------------------------+ | |&lt;------------------------------------------------+
| | | | | | | | | |
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>Subsequent additions of group members proceed in the same way. Any <t indent="0" pn="section-3.2-9">Subsequent additions of group members p
member of the group can download a KeyPackage for a new client roceed in the same way. Any
and broadcast Add and Commit messages that the current group will use to update member of the group can download a KeyPackage for a new client,
their state, and a Welcome message that the new client can use to broadcast Add and Commit messages that the current group will use to update
their state, and send a Welcome message that the new client can use to
initialize its state and join the group.</t> initialize its state and join the group.</t>
<t>To enforce the forward secrecy and post-compromise security of messag es, each <t indent="0" pn="section-3.2-10">To enforce the forward secrecy and pos t-compromise security of messages, each
member periodically updates the keys that represent them to the group. A member member periodically updates the keys that represent them to the group. A member
does this by sending a Commit (possibly with no proposals), or by sending an does this by sending a Commit (possibly with no proposals) or by sending an
Update message that is committed by another member (see <xref target="update-flo Update message that is committed by another member (see <xref target="update-flo
w"/>). w" format="default" sectionFormat="of" derivedContent="Figure 4"/>).
Once the other members of Once the other members of
the group have processed these messages, the group's secrets will be unknown to the group have processed these messages, the group's secrets will be unknown to
an attacker that had compromised the secrets corresponding to the sender's leaf an attacker that had compromised the secrets corresponding to the sender's leaf
in the tree.</t> in the tree.
<t>Update messages SHOULD be sent at regular intervals of time as long a At the end of the scenario shown in <xref target="update-flow" format="default"
s the group sectionFormat="of" derivedContent="Figure 4"/>, the group has
is active, and members that don't update SHOULD eventually be removed from the post-compromise security with respect to both A and B.</t>
<t indent="0" pn="section-3.2-11">Update messages <bcp14>SHOULD</bcp14>
be sent at regular intervals of time as long as the group
is active, and members that don't update <bcp14>SHOULD</bcp14> eventually be rem
oved from the
group. It's left to the application to determine an appropriate amount of time group. It's left to the application to determine an appropriate amount of time
between Updates. Since the purpose of sending an Update is to proactively between Updates. Since the purpose of sending an Update is to proactively
constrain a compromise window, the right frequency is usually on the order of constrain a compromise window, the right frequency is usually on the order of
hours or days, not milliseconds. For example, an application might send an hours or days, not milliseconds. For example, an application might send an
Update each time a member sends an application message after receiving from Update each time a member sends an application message after receiving any
other members, or daily if no application messages are sent.</t> message from another member, or daily if no application messages are sent.</t>
<t>The MLS architecture recommends that MLS be operated over a secure tr <t indent="0" pn="section-3.2-12">The MLS architecture recommends that M
ansport LS be operated over a secure transport
(see <xref section="7.1" sectionFormat="of" target="I-D.ietf-mls-architecture"/> (see <xref section="7.1" sectionFormat="of" target="I-D.ietf-mls-architecture" f
). Such transport protocols ormat="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-ml
s-architecture-10#section-7.1" derivedContent="MLS-ARCH"/>). Such transport pro
tocols
will typically provide functions such as congestion control that manage the will typically provide functions such as congestion control that manage the
impact of an MLS-using application on other applications sharing the same impact of an MLS-using application on other applications sharing the same
network. Applications should take care that they do not send MLS messages at a network. Applications should take care that they do not send MLS messages at a
rate that will cause problems such as network congestion, especially if they are rate that will cause problems such as network congestion, especially if they are
not following the above recommendation (e.g., sending MLS directly over UDP inst ead).</t> not following the above recommendation (e.g., sending MLS directly over UDP inst ead).</t>
<figure anchor="update-flow"> <figure anchor="update-flow" align="left" suppress-title="false" pn="fig
<name>Client B proposes to update its key, and client A commits the pr ure-4">
oposal. As a result, the keys for both B and A updated, so the group has post-c <name slugifiedName="name-client-b-proposes-to-update">Client B propos
ompromise security with respect to both of them.</name> es to update its key, and client A commits the proposal</name>
<artset> <artset pn="section-3.2-13.1">
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= <artwork type="svg" align="left" pn="section-3.2-13.1.1">
"1.1" height="304" width="528" viewBox="0 0 528 304" class="diagram" text-anchor <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-famil
="middle" font-family="monospace" font-size="13px"> y="monospace" font-size="13px" height="304" text-anchor="middle" version="1.1" v
iewBox="0 0 528 304" width="528">
<path d="M 8,64 L 8,288" fill="none" stroke="black"/> <path d="M 8,64 L 8,288" fill="none" stroke="black"/>
<path d="M 128,64 L 128,120" fill="none" stroke="black"/> <path d="M 128,64 L 128,120" fill="none" stroke="black"/>
<path d="M 128,136 L 128,200" fill="none" stroke="black"/> <path d="M 128,136 L 128,200" fill="none" stroke="black"/>
<path d="M 128,248 L 128,288" fill="none" stroke="black"/> <path d="M 128,248 L 128,288" fill="none" stroke="black"/>
<path d="M 248,64 L 248,88" fill="none" stroke="black"/> <path d="M 248,64 L 248,88" fill="none" stroke="black"/>
<path d="M 248,152 L 248,200" fill="none" stroke="black"/> <path d="M 248,152 L 248,200" fill="none" stroke="black"/>
<path d="M 248,264 L 248,288" fill="none" stroke="black"/> <path d="M 248,264 L 248,288" fill="none" stroke="black"/>
<path d="M 368,64 L 368,88" fill="none" stroke="black"/> <path d="M 368,64 L 368,88" fill="none" stroke="black"/>
<path d="M 368,168 L 368,200" fill="none" stroke="black"/> <path d="M 368,168 L 368,200" fill="none" stroke="black"/>
<path d="M 488,64 L 488,288" fill="none" stroke="black"/> <path d="M 488,64 L 488,288" fill="none" stroke="black"/>
<path d="M 128,96 L 480,96" fill="none" stroke="black"/> <path d="M 128,96 L 480,96" fill="none" stroke="black"/>
<path d="M 16,128 L 488,128" fill="none" stroke="black"/> <path d="M 16,128 L 488,128" fill="none" stroke="black"/>
<path d="M 136,144 L 488,144" fill="none" stroke="black"/> <path d="M 136,144 L 488,144" fill="none" stroke="black"/>
<path d="M 256,160 L 488,160" fill="none" stroke="black"/> <path d="M 256,160 L 488,160" fill="none" stroke="black"/>
<path d="M 8,208 L 480,208" fill="none" stroke="black"/> <path d="M 8,208 L 480,208" fill="none" stroke="black"/>
<path d="M 16,240 L 488,240" fill="none" stroke="black"/> <path d="M 16,240 L 488,240" fill="none" stroke="black"/>
<path d="M 136,256 L 488,256" fill="none" stroke="black"/> <path d="M 136,256 L 488,256" fill="none" stroke="black"/>
<path d="M 256,272 L 488,272" fill="none" stroke="black"/> <path d="M 256,272 L 488,272" fill="none" stroke="black"/>
<polygon class="arrowhead" points="488,208 476,202.4 476,213.6" <polygon class="arrowhead" fill="black" points="488,208 476,202.
fill="black" transform="rotate(0,480,208)"/> 4 476,213.6" transform="rotate(0,480,208)"/>
<polygon class="arrowhead" points="488,96 476,90.4 476,101.6" fi <polygon class="arrowhead" fill="black" points="488,96 476,90.4
ll="black" transform="rotate(0,480,96)"/> 476,101.6" transform="rotate(0,480,96)"/>
<polygon class="arrowhead" points="264,272 252,266.4 252,277.6" <polygon class="arrowhead" fill="black" points="264,272 252,266.
fill="black" transform="rotate(180,256,272)"/> 4 252,277.6" transform="rotate(180,256,272)"/>
<polygon class="arrowhead" points="264,160 252,154.4 252,165.6" <polygon class="arrowhead" fill="black" points="264,160 252,154.
fill="black" transform="rotate(180,256,160)"/> 4 252,165.6" transform="rotate(180,256,160)"/>
<polygon class="arrowhead" points="144,256 132,250.4 132,261.6" <polygon class="arrowhead" fill="black" points="144,256 132,250.
fill="black" transform="rotate(180,136,256)"/> 4 132,261.6" transform="rotate(180,136,256)"/>
<polygon class="arrowhead" points="144,144 132,138.4 132,149.6" <polygon class="arrowhead" fill="black" points="144,144 132,138.
fill="black" transform="rotate(180,136,144)"/> 4 132,149.6" transform="rotate(180,136,144)"/>
<polygon class="arrowhead" points="24,240 12,234.4 12,245.6" fil <polygon class="arrowhead" fill="black" points="24,240 12,234.4
l="black" transform="rotate(180,16,240)"/> 12,245.6" transform="rotate(180,16,240)"/>
<polygon class="arrowhead" points="24,128 12,122.4 12,133.6" fil <polygon class="arrowhead" fill="black" points="24,128 12,122.4
l="black" transform="rotate(180,16,128)"/> 12,133.6" transform="rotate(180,16,128)"/>
<g class="text"> <g class="text">
<text x="488" y="36">Group</text> <text x="488" y="36">Group</text>
<text x="8" y="52">A</text> <text x="8" y="52">A</text>
<text x="128" y="52">B</text> <text x="128" y="52">B</text>
<text x="184" y="52">...</text> <text x="184" y="52">...</text>
<text x="248" y="52">Z</text> <text x="248" y="52">Z</text>
<text x="368" y="52">Directory</text> <text x="368" y="52">Directory</text>
<text x="496" y="52">Channel</text> <text x="496" y="52">Channel</text>
<text x="176" y="84">Update(B)</text> <text x="176" y="84">Update(B)</text>
<text x="248" y="116">|</text> <text x="248" y="116">|</text>
skipping to change at line 1041 skipping to change at line 1212
<text x="416" y="116">Update(B)</text> <text x="416" y="116">Update(B)</text>
<text x="64" y="196">Commit(Upd)</text> <text x="64" y="196">Commit(Upd)</text>
<text x="128" y="228">|</text> <text x="128" y="228">|</text>
<text x="248" y="228">|</text> <text x="248" y="228">|</text>
<text x="368" y="228">|</text> <text x="368" y="228">|</text>
<text x="424" y="228">Commit(Upd)</text> <text x="424" y="228">Commit(Upd)</text>
<text x="368" y="292">|</text> <text x="368" y="292">|</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-3.2-13.1.2">
Group Group
A B ... Z Directory Channel A B ... Z Directory Channel
| | | | | | | | | |
| | Update(B) | | | | | Update(B) | | |
| +------------------------------------------->| | +-------------------------------------------&gt;|
| | | | Update(B) | | | | | Update(B) |
|<----------------------------------------------------------+ |&lt;----------------------------------------------------------+
| |<-------------------------------------------+ | |&lt;-------------------------------------------+
| | |<----------------------------+ | | |&lt;----------------------------+
| | | | | | | | | |
| Commit(Upd) | | | | | Commit(Upd) | | | |
+---------------------------------------------------------->| +----------------------------------------------------------&gt;|
| | | | Commit(Upd) | | | | | Commit(Upd) |
|<----------------------------------------------------------+ |&lt;----------------------------------------------------------+
| |<-------------------------------------------+ | |&lt;-------------------------------------------+
| | |<----------------------------+ | | |&lt;----------------------------+
| | | | | | | | | |
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>Members are removed from the group in a similar way, as shown in <xre f target="remove-flow"/>. <t indent="0" pn="section-3.2-14">Members are removed from the group in a similar way, as shown in <xref target="remove-flow" format="default" sectionFo rmat="of" derivedContent="Figure 5"/>.
Any member of the group can send a Remove proposal followed by a Any member of the group can send a Remove proposal followed by a
Commit message. The Commit message provides new entropy to all members of the Commit message. The Commit message provides new entropy to all members of the
group except the removed member. This new entropy is added to the epoch secret group except the removed member. This new entropy is added to the epoch secret
for the new epoch so that it is not known to the removed member. for the new epoch so that it is not known to the removed member.
Note that this does not necessarily imply that any member Note that this does not necessarily imply that any member
is actually allowed to evict other members; groups can is actually allowed to evict other members; groups can
enforce access control policies on top of these enforce access control policies on top of these
basic mechanisms.</t> basic mechanisms.</t>
<figure anchor="remove-flow"> <figure anchor="remove-flow" align="left" suppress-title="false" pn="fig
<name>Client Z removes client B from the group</name> ure-5">
<artset> <name slugifiedName="name-client-z-removes-client-b-f">Client Z remove
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= s client B from the group</name>
"1.1" height="240" width="520" viewBox="0 0 520 240" class="diagram" text-anchor <artset pn="section-3.2-15.1">
="middle" font-family="monospace" font-size="13px"> <artwork type="svg" align="left" pn="section-3.2-15.1.1">
<svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-famil
y="monospace" font-size="13px" height="240" text-anchor="middle" version="1.1" v
iewBox="0 0 520 240" width="520">
<path d="M 8,64 L 8,224" fill="none" stroke="black"/> <path d="M 8,64 L 8,224" fill="none" stroke="black"/>
<path d="M 128,64 L 128,168" fill="none" stroke="black"/> <path d="M 128,64 L 128,168" fill="none" stroke="black"/>
<path d="M 128,184 L 128,224" fill="none" stroke="black"/> <path d="M 128,184 L 128,224" fill="none" stroke="black"/>
<path d="M 248,64 L 248,168" fill="none" stroke="black"/> <path d="M 248,64 L 248,168" fill="none" stroke="black"/>
<path d="M 248,200 L 248,224" fill="none" stroke="black"/> <path d="M 248,200 L 248,224" fill="none" stroke="black"/>
<path d="M 368,64 L 368,104" fill="none" stroke="black"/> <path d="M 368,64 L 368,104" fill="none" stroke="black"/>
<path d="M 368,120 L 368,168" fill="none" stroke="black"/> <path d="M 368,120 L 368,168" fill="none" stroke="black"/>
<path d="M 488,64 L 488,224" fill="none" stroke="black"/> <path d="M 488,64 L 488,224" fill="none" stroke="black"/>
<path d="M 248,112 L 480,112" fill="none" stroke="black"/> <path d="M 248,112 L 480,112" fill="none" stroke="black"/>
<path d="M 16,176 L 488,176" fill="none" stroke="black"/> <path d="M 16,176 L 488,176" fill="none" stroke="black"/>
<path d="M 136,192 L 488,192" fill="none" stroke="black"/> <path d="M 136,192 L 488,192" fill="none" stroke="black"/>
<path d="M 256,208 L 488,208" fill="none" stroke="black"/> <path d="M 256,208 L 488,208" fill="none" stroke="black"/>
<polygon class="arrowhead" points="488,112 476,106.4 476,117.6" <polygon class="arrowhead" fill="black" points="488,112 476,106.
fill="black" transform="rotate(0,480,112)"/> 4 476,117.6" transform="rotate(0,480,112)"/>
<polygon class="arrowhead" points="264,208 252,202.4 252,213.6" <polygon class="arrowhead" fill="black" points="264,208 252,202.
fill="black" transform="rotate(180,256,208)"/> 4 252,213.6" transform="rotate(180,256,208)"/>
<polygon class="arrowhead" points="144,192 132,186.4 132,197.6" <polygon class="arrowhead" fill="black" points="144,192 132,186.
fill="black" transform="rotate(180,136,192)"/> 4 132,197.6" transform="rotate(180,136,192)"/>
<polygon class="arrowhead" points="24,176 12,170.4 12,181.6" fil <polygon class="arrowhead" fill="black" points="24,176 12,170.4
l="black" transform="rotate(180,16,176)"/> 12,181.6" transform="rotate(180,16,176)"/>
<g class="text"> <g class="text">
<text x="488" y="36">Group</text> <text x="488" y="36">Group</text>
<text x="8" y="52">A</text> <text x="8" y="52">A</text>
<text x="128" y="52">B</text> <text x="128" y="52">B</text>
<text x="184" y="52">...</text> <text x="184" y="52">...</text>
<text x="248" y="52">Z</text> <text x="248" y="52">Z</text>
<text x="368" y="52">Directory</text> <text x="368" y="52">Directory</text>
<text x="488" y="52">Channel</text> <text x="488" y="52">Channel</text>
<text x="296" y="84">Remove(B)</text> <text x="296" y="84">Remove(B)</text>
<text x="304" y="100">Commit(Rem)</text> <text x="304" y="100">Commit(Rem)</text>
<text x="416" y="148">Remove(B)</text> <text x="416" y="148">Remove(B)</text>
<text x="424" y="164">Commit(Rem)</text> <text x="424" y="164">Commit(Rem)</text>
<text x="368" y="228">|</text> <text x="368" y="228">|</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-3.2-15.1.2">
Group Group
A B ... Z Directory Channel A B ... Z Directory Channel
| | | | | | | | | |
| | | Remove(B) | | | | | Remove(B) | |
| | | Commit(Rem) | | | | | Commit(Rem) | |
| | +---------------------------->| | | +----------------------------&gt;|
| | | | | | | | | |
| | | | Remove(B) | | | | | Remove(B) |
| | | | Commit(Rem) | | | | | Commit(Rem) |
|<----------------------------------------------------------+ |&lt;----------------------------------------------------------+
| |<-------------------------------------------+ | |&lt;-------------------------------------------+
| | |<----------------------------+ | | |&lt;----------------------------+
| | | | | | | | | |
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>Note that the flows in this section are examples; applications can ar range <t indent="0" pn="section-3.2-16">Note that the flows in this section ar e examples; applications can arrange
message flows in other ways. For example:</t> message flows in other ways. For example:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3
<li>Welcome messages don't necessarily need to be sent directly to new .2-17">
joiners. <li pn="section-3.2-17.1">Welcome messages don't necessarily need to b
e sent directly to new joiners.
Since they are encrypted to new joiners, they could be distributed more Since they are encrypted to new joiners, they could be distributed more
broadly, say if the application only had access to a broadcast channel for the broadly, say if the application only had access to a broadcast channel for the
group.</li> group.</li>
<li>Proposal messages don't need to be immediately sent to all group m <li pn="section-3.2-17.2">Proposal messages don't need to be immediate
embers. They need to ly sent to all group members. They need to
be available to the committer before generating a commit, and to other members b be available to the committer before generating a Commit, and to other members b
efore efore
processing the commit.</li> processing the Commit.</li>
<li>The sender of a Commit doesn't necessarily have to wait to receive <li pn="section-3.2-17.3">The sender of a Commit doesn't necessarily h
its own ave to wait to receive its own
Commit back before advancing its state. It only needs to know that its Commit Commit back before advancing its state. It only needs to know that its Commit
will be the next one applied by the group, say based on a promise from an will be the next one applied by the group, say based on a promise from an
orchestration server.</li> orchestration server.</li>
</ul> </ul>
</section> </section>
<section anchor="external-joins"> <section anchor="external-joins" numbered="true" removeInRFC="false" toc="
<name>External Joins</name> include" pn="section-3.3">
<t>In addition to the Welcome-based flow for adding a new member to the <name slugifiedName="name-external-joins">External Joins</name>
group, it <t indent="0" pn="section-3.3-1">In addition to the Welcome-based flow f
or adding a new member to the group, it
is also possible for a new member to join by means of an "external Commit". is also possible for a new member to join by means of an "external Commit".
This mechanism can be used when the existing members don't have a KeyPackage for This mechanism can be used when the existing members don't have a KeyPackage for
the new member, for example, in the case of an "open" group that can be joined the new member, for example, in the case of an "open" group that can be joined
by new members without asking permission from existing members.</t> by new members without asking permission from existing members.</t>
<t><xref target="groupinfo-flow"/> shows a typical message flow for an external join. To enable <t indent="0" pn="section-3.3-2"><xref target="groupinfo-flow" format="d efault" sectionFormat="of" derivedContent="Figure 6"/> shows a typical message flow for an external join. To enable
a new member to join the group in this way, a member of the group (A, B) a new member to join the group in this way, a member of the group (A, B)
publishes a GroupInfo object that includes the GroupContext for the group as publishes a GroupInfo object that includes the GroupContext for the group as
well as a public key that can be used to encrypt a secret to the existing well as a public key that can be used to encrypt a secret to the existing
members of the group. When the new member Z wishes to join, they download the members of the group. When the new member Z wishes to join, they download the
GroupInfo object and use it to form a Commit of a special form that adds Z to GroupInfo object and use it to form a Commit of a special form that adds Z to
the group (as detailed in <xref target="joining-via-external-commits"/>). The e xisting the group (as detailed in <xref target="joining-via-external-commits" format="de fault" sectionFormat="of" derivedContent="Section 12.4.3.2"/>). The existing
members of the group process this external Commit in a similar way to a normal members of the group process this external Commit in a similar way to a normal
Commit, advancing to a new epoch in which Z is now a member of the group.</t> Commit, advancing to a new epoch in which Z is now a member of the group.</t>
<figure anchor="groupinfo-flow"> <figure anchor="groupinfo-flow" align="left" suppress-title="false" pn="
<name>Client A publishes a GroupInfo object and Client Z uses it to jo figure-6">
in the group</name> <name slugifiedName="name-client-a-publishes-a-groupi">Client A publis
<artwork><![CDATA[ hes a GroupInfo object, and Client Z uses it to join the group</name>
<artwork align="left" pn="section-3.3-3.1">
Group Group
A B Z Directory Channel A B Z Directory Channel
| | | | | | | | | |
| GroupInfo | | | | | GroupInfo | | | |
+------------------------------------------->| | +-------------------------------------------&gt;| |
| | | GroupInfo | | | | | GroupInfo | |
| | |<-------------+ | | | |&lt;-------------+ |
| | | | | | | | | |
| | | Commit(ExtZ) | | | | | Commit(ExtZ) | |
| | +---------------------------->| | | +----------------------------&gt;|
| | | | Commit(ExtZ) | | | | | Commit(ExtZ) |
|<----------------------------------------------------------+ |&lt;----------------------------------------------------------+
| |<-------------------------------------------+ | |&lt;-------------------------------------------+
| | |<----------------------------+ | | |&lt;----------------------------+
| | | | | | | | | |
]]></artwork> </artwork>
</figure> </figure>
</section> </section>
<section anchor="relationships-between-epochs"> <section anchor="relationships-between-epochs" numbered="true" removeInRFC
<name>Relationships Between Epochs</name> ="false" toc="include" pn="section-3.4">
<t>A group has a single linear sequence of epochs. Groups and epochs are <name slugifiedName="name-relationships-between-epoch">Relationships bet
generally ween Epochs</name>
<t indent="0" pn="section-3.4-1">A group has a single linear sequence of
epochs. Groups and epochs are generally
independent of one another. However, it can sometimes be useful to link epochs independent of one another. However, it can sometimes be useful to link epochs
cryptographically, either within a group or across groups. MLS derives a cryptographically, either within a group or across groups. MLS derives a
resumption pre-shared key (PSK) from each epoch to allow entropy extracted from resumption pre-shared key (PSK) from each epoch to allow entropy extracted from
one epoch to be injected into a future epoch. A group member that wishes to one epoch to be injected into a future epoch. A group member that wishes to
inject a PSK issues a PreSharedKey proposal (<xref target="presharedkey"/>) desc ribing the inject a PSK issues a PreSharedKey proposal (<xref target="presharedkey" format= "default" sectionFormat="of" derivedContent="Section 12.1.4"/>) describing the
PSK to be injected. When this proposal is committed, the corresponding PSK will PSK to be injected. When this proposal is committed, the corresponding PSK will
be incorporated into the key schedule as described in <xref target="pre-shared-k be incorporated into the key schedule as described in <xref target="pre-shared-k
eys"/>.</t> eys" format="default" sectionFormat="of" derivedContent="Section 8.4"/>.</t>
<t>Linking epochs in this way <t indent="0" pn="section-3.4-2">Linking epochs in this way
guarantees that members entering the new epoch agree on a key if and only if guarantees that members entering the new epoch agree on a key if and only if
they were members of the group during the epoch from which the resumption key they were members of the group during the epoch from which the resumption key
was extracted.</t> was extracted.</t>
<t>MLS supports two ways to tie a new group to an existing group, illust <t indent="0" pn="section-3.4-3">MLS supports two ways to tie a new grou
rated in p to an existing group, which are illustrated in
<xref target="psk-reinit"/> and <xref target="psk-branch"/>. Reinitialization Figures <xref format="counter" target="psk-reinit" sectionFormat="of" derivedCon
tent="7"/> and <xref format="counter" target="psk-branch" sectionFormat="of" der
ivedContent="8"/>. Reinitialization
closes one group and creates a new group comprising the same members with 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 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, 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.</t> the new group is linked to the old group via a resumption PSK.</t>
<figure anchor="psk-reinit"> <figure anchor="psk-reinit" align="left" suppress-title="false" pn="figu
<name>Reinitializing a group</name> re-7">
<artset> <name slugifiedName="name-reinitializing-a-group">Reinitializing a Gro
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= up</name>
"1.1" height="240" width="272" viewBox="0 0 272 240" class="diagram" text-anchor <artset pn="section-3.4-4.1">
="middle" font-family="monospace" font-size="13px"> <artwork type="svg" align="left" pn="section-3.4-4.1.1">
<svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-famil
y="monospace" font-size="13px" height="240" text-anchor="middle" version="1.1" v
iewBox="0 0 272 240" width="272">
<path d="M 48,40 L 48,112" fill="none" stroke="black"/> <path d="M 48,40 L 48,112" fill="none" stroke="black"/>
<path d="M 224,136 L 224,208" fill="none" stroke="black"/> <path d="M 224,136 L 224,208" fill="none" stroke="black"/>
<path d="M 56,80 L 72,80" fill="none" stroke="black"/> <path d="M 56,80 L 72,80" fill="none" stroke="black"/>
<polygon class="arrowhead" points="232,208 220,202.4 220,213.6" <polygon class="arrowhead" fill="black" points="232,208 220,202.
fill="black" transform="rotate(90,224,208)"/> 4 220,213.6" transform="rotate(90,224,208)"/>
<polygon class="arrowhead" points="64,80 52,74.4 52,85.6" fill=" <polygon class="arrowhead" fill="black" points="64,80 52,74.4 52
black" transform="rotate(180,56,80)"/> ,85.6" transform="rotate(180,56,80)"/>
<polygon class="arrowhead" points="56,112 44,106.4 44,117.6" fil <polygon class="arrowhead" fill="black" points="56,112 44,106.4
l="black" transform="rotate(90,48,112)"/> 44,117.6" transform="rotate(90,48,112)"/>
<g class="text"> <g class="text">
<text x="56" y="36">epoch_A_[n-1]</text> <text x="56" y="36">epoch_A_[n-1]</text>
<text x="108" y="84">ReInit</text> <text x="108" y="84">ReInit</text>
<text x="48" y="132">epoch_A_[n]</text> <text x="48" y="132">epoch_A_[n]</text>
<text x="224" y="132">epoch_B_[0]</text> <text x="224" y="132">epoch_B_[0]</text>
<text x="48" y="148">.</text> <text x="48" y="148">.</text>
<text x="48" y="164">.</text> <text x="48" y="164">.</text>
<text x="136" y="164">PSK(usage=reinit)</text> <text x="136" y="164">PSK(usage=reinit)</text>
<text x="132" y="180">.....................&gt;</text> <text x="132" y="180">.....................&gt;</text>
<text x="224" y="228">epoch_B_[1]</text> <text x="224" y="228">epoch_B_[1]</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-3.4-4.1.2">
epoch_A_[n-1] epoch_A_[n-1]
| |
| |
|<-- ReInit |&lt;-- ReInit
| |
V V
epoch_A_[n] epoch_B_[0] epoch_A_[n] epoch_B_[0]
. | . |
. PSK(usage=reinit) | . PSK(usage=reinit) |
.....................>| .....................&gt;|
| |
V V
epoch_B_[1] epoch_B_[1]
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<figure anchor="psk-branch"> <figure anchor="psk-branch" align="left" suppress-title="false" pn="figu
<name>Branching a group</name> re-8">
<artset> <name slugifiedName="name-branching-a-group">Branching a Group</name>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= <artset pn="section-3.4-5.1">
"1.1" height="144" width="272" viewBox="0 0 272 144" class="diagram" text-anchor <artwork type="svg" align="left" pn="section-3.4-5.1.1">
="middle" font-family="monospace" font-size="13px"> <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-famil
y="monospace" font-size="13px" height="144" text-anchor="middle" version="1.1" v
iewBox="0 0 272 144" width="272">
<path d="M 48,40 L 48,112" fill="none" stroke="black"/> <path d="M 48,40 L 48,112" fill="none" stroke="black"/>
<path d="M 224,40 L 224,112" fill="none" stroke="black"/> <path d="M 224,40 L 224,112" fill="none" stroke="black"/>
<polygon class="arrowhead" points="232,112 220,106.4 220,117.6" <polygon class="arrowhead" fill="black" points="232,112 220,106.
fill="black" transform="rotate(90,224,112)"/> 4 220,117.6" transform="rotate(90,224,112)"/>
<polygon class="arrowhead" points="56,112 44,106.4 44,117.6" fil <polygon class="arrowhead" fill="black" points="56,112 44,106.4
l="black" transform="rotate(90,48,112)"/> 44,117.6" transform="rotate(90,48,112)"/>
<g class="text"> <g class="text">
<text x="48" y="36">epoch_A_[n]</text> <text x="48" y="36">epoch_A_[n]</text>
<text x="224" y="36">epoch_B_[0]</text> <text x="224" y="36">epoch_B_[0]</text>
<text x="136" y="68">PSK(usage=branch)</text> <text x="136" y="68">PSK(usage=branch)</text>
<text x="136" y="84">....................&gt;</text> <text x="136" y="84">....................&gt;</text>
<text x="56" y="132">epoch_A_[n+1]</text> <text x="56" y="132">epoch_A_[n+1]</text>
<text x="224" y="132">epoch_B_[1]</text> <text x="224" y="132">epoch_B_[1]</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-3.4-5.1.2">
epoch_A_[n] epoch_B_[0] epoch_A_[n] epoch_B_[0]
| | | |
| PSK(usage=branch) | | PSK(usage=branch) |
|....................>| |....................&gt;|
| | | |
V V V V
epoch_A_[n+1] epoch_B_[1] epoch_A_[n+1] epoch_B_[1]
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>Applications may also choose to use resumption PSKs to link epochs in <t indent="0" pn="section-3.4-6">Applications may also choose to use res
other umption PSKs to link epochs in other
ways. For example, <xref target="psk-reinject"/> shows a case where a resumptio ways. For example, <xref target="psk-reinject" format="default" sectionFormat="
n PSK of" derivedContent="Figure 9"/> shows a case where a resumption PSK
from epoch <tt>n</tt> is injected into epoch <tt>n+k</tt>. This demonstrates th at the members from epoch <tt>n</tt> is injected into epoch <tt>n+k</tt>. This demonstrates th at the members
of the group at epoch <tt>n+k</tt> were also members at epoch <tt>n</tt>, irresp ective of any of the group at epoch <tt>n+k</tt> were also members at epoch <tt>n</tt>, irresp ective of any
changes to these members' keys due to Updates or Commits.</t> changes to these members' keys due to Updates or Commits.</t>
<figure anchor="psk-reinject"> <figure anchor="psk-reinject" align="left" suppress-title="false" pn="fi
<name>Reinjecting entropy from an earlier epoch</name> gure-9">
<artset> <name slugifiedName="name-reinjecting-entropy-from-an">Reinjecting Ent
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= ropy from an Earlier Epoch</name>
"1.1" height="304" width="248" viewBox="0 0 248 304" class="diagram" text-anchor <artset pn="section-3.4-7.1">
="middle" font-family="monospace" font-size="13px"> <artwork type="svg" align="left" pn="section-3.4-7.1.1">
<svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-famil
y="monospace" font-size="13px" height="304" text-anchor="middle" version="1.1" v
iewBox="0 0 248 304" width="248">
<path d="M 48,40 L 48,176" fill="none" stroke="black"/> <path d="M 48,40 L 48,176" fill="none" stroke="black"/>
<path d="M 48,200 L 48,272" fill="none" stroke="black"/> <path d="M 48,200 L 48,272" fill="none" stroke="black"/>
<polygon class="arrowhead" points="56,272 44,266.4 44,277.6" fil <polygon class="arrowhead" fill="black" points="56,272 44,266.4
l="black" transform="rotate(90,48,272)"/> 44,277.6" transform="rotate(90,48,272)"/>
<polygon class="arrowhead" points="56,176 44,170.4 44,181.6" fil <polygon class="arrowhead" fill="black" points="56,176 44,170.4
l="black" transform="rotate(90,48,176)"/> 44,181.6" transform="rotate(90,48,176)"/>
<g class="text"> <g class="text">
<text x="48" y="36">epoch_A_[n]</text> <text x="48" y="36">epoch_A_[n]</text>
<text x="156" y="68">PSK(usage=application)</text> <text x="156" y="68">PSK(usage=application)</text>
<text x="136" y="84">.....................</text> <text x="136" y="84">.....................</text>
<text x="216" y="100">.</text> <text x="216" y="100">.</text>
<text x="216" y="116">.</text> <text x="216" y="116">.</text>
<text x="40" y="132">.</text> <text x="40" y="132">.</text>
<text x="56" y="132">.</text> <text x="56" y="132">.</text>
<text x="216" y="132">...</text> <text x="216" y="132">...</text>
<text x="216" y="148">.</text> <text x="216" y="148">.</text>
skipping to change at line 1300 skipping to change at line 1475
<text x="216" y="180">.</text> <text x="216" y="180">.</text>
<text x="64" y="196">epoch_A_[n+k-1]</text> <text x="64" y="196">epoch_A_[n+k-1]</text>
<text x="216" y="196">.</text> <text x="216" y="196">.</text>
<text x="216" y="212">.</text> <text x="216" y="212">.</text>
<text x="216" y="228">.</text> <text x="216" y="228">.</text>
<text x="136" y="244">&lt;....................</text> <text x="136" y="244">&lt;....................</text>
<text x="56" y="292">epoch_A_[n+k]</text> <text x="56" y="292">epoch_A_[n+k]</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-3.4-7.1.2">
epoch_A_[n] epoch_A_[n]
| |
| PSK(usage=application) | PSK(usage=application)
|..................... |.....................
| . | .
| . | .
... ... ... ...
| . | .
| . | .
V . V .
epoch_A_[n+k-1] . epoch_A_[n+k-1] .
| . | .
| . | .
|<.................... |&lt;....................
| |
V V
epoch_A_[n+k] epoch_A_[n+k]
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="ratchet-tree-concepts"> <section anchor="ratchet-tree-concepts" numbered="true" removeInRFC="false"
<name>Ratchet Tree Concepts</name> toc="include" pn="section-4">
<t>The protocol uses "ratchet trees" for deriving shared secrets among a g <name slugifiedName="name-ratchet-tree-concepts">Ratchet Tree Concepts</na
roup of me>
<t indent="0" pn="section-4-1">The protocol uses "ratchet trees" for deriv
ing shared secrets among a group of
clients. A ratchet tree is an arrangement of secrets and key pairs among the clients. A ratchet tree is an arrangement of secrets and key pairs among the
members of a group in a way that allows for secrets to be efficiently updated to members of a group in a way that allows for secrets to be efficiently updated to
reflect changes in the group.</t> reflect changes in the group.</t>
<t>Ratchet trees allow a group to efficiently remove any member by encrypt ing new <t indent="0" pn="section-4-2">Ratchet trees allow a group to efficiently remove any member by encrypting new
entropy to a subset of the group. A ratchet tree assigns shared keys to entropy to a subset of the group. A ratchet tree assigns shared keys to
subgroups of the overall group, so that, for example, encrypting to all but one subgroups of the overall group, so that, for example, encrypting to all but one
member of the group requires only <tt>log(N)</tt> encryptions to subtrees, inste ad of the <tt>N-1</tt> member of the group requires only <tt>log(N)</tt> encryptions to subtrees, inste ad of the <tt>N-1</tt>
encryptions that would be needed to encrypt to each participant individually encryptions that would be needed to encrypt to each participant individually
(where N is the number of members in the group).</t> (where N is the number of members in the group).</t>
<t>This remove operation allows MLS to efficiently achieve <t indent="0" pn="section-4-3">This remove operation allows MLS to efficie ntly achieve
post-compromise security. In an Update proposal or a full Commit message, an ol d (possibly post-compromise security. In an Update proposal or a full Commit message, an ol d (possibly
compromised) representation of a member is efficiently removed from the group an d compromised) representation of a member is efficiently removed from the group an d
replaced with a freshly generated instance.</t> replaced with a freshly generated instance.</t>
<section anchor="ratchet-tree-terminology"> <section anchor="ratchet-tree-terminology" numbered="true" removeInRFC="fa
<name>Ratchet Tree Terminology</name> lse" toc="include" pn="section-4.1">
<t>Trees consist of <em>nodes</em>. A node is a <name slugifiedName="name-ratchet-tree-terminology">Ratchet Tree Termino
<em>leaf</em> if it has no children, and a <em>parent</em> otherwise; note that logy</name>
all <t indent="0" pn="section-4.1-1">Trees consist of <em>nodes</em>. A node
parents in our trees have precisely is a
<em>leaf</em> if it has no children; otherwise, it is a <em>parent</em>.
All parents in our trees have precisely
two children, a <em>left</em> child and a <em>right</em> child. A node is the <e m>root</em> two children, a <em>left</em> child and a <em>right</em> child. A node is the <e m>root</em>
of a tree if it has no parents, and <em>intermediate</em> if it has both of a tree if it has no parent, and <em>intermediate</em> if it has both
children and parents. The <em>descendants</em> of a node are that node's children and a parent. The <em>descendants</em> of a node are that node's
children, and the descendants of its children, and we say a tree children, and the descendants of its children. We say a tree
<em>contains</em> a node if that node is a descendant of the root of the tree, <em>contains</em> 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 <em>siblings</em> if th ey share the same parent.</t> or if the node itself is the root of the tree. Nodes are <em>siblings</em> if th ey share the same parent.</t>
<t>A <em>subtree</em> of a tree is the tree given by any node (the <em>h ead</em> of the <t indent="0" pn="section-4.1-2">A <em>subtree</em> of a tree is the tre e given by any node (the <em>head</em> of the
subtree) and its descendants. The <em>size</em> of a tree or subtree is the subtree) and its descendants. The <em>size</em> of a tree or subtree is the
number of leaf nodes it contains. For a given parent node, its <em>left number of leaf nodes it contains. For a given parent node, its <em>left
subtree</em> is the subtree with its left child as head (respectively subtree</em> is the subtree with its left child as head and its
<em>right subtree</em>).</t> <em>right subtree</em> is the subtree with its right child as head.</t>
<t>Every tree used in this protocol is a perfect binary tree, that is, a <t indent="0" pn="section-4.1-3">Every tree used in this protocol is a p
complete erfect binary tree, that is, a complete
balanced binary tree with <tt>2^d</tt> leaves all at the same depth <tt>d</tt>. balanced binary tree with 2<sup>d</sup> leaves all at the same depth <tt>d</tt>.
This This
structure is unique for a given depth <tt>d</tt>.</t> structure is unique for a given depth <tt>d</tt>.</t>
<t>There are multiple ways that an implementation might represent a ratc het tree in <t indent="0" pn="section-4.1-4">There are multiple ways that an impleme ntation might represent a ratchet tree in
memory. A convenient property of left-balanced binary trees (including the memory. A convenient property of left-balanced binary trees (including the
complete trees used here) is that they can be represented as an array of nodes, complete trees used here) is that they can be represented as an array of nodes,
with node relationships computed based on the nodes' indices in the array. A with node relationships computed based on the nodes' indices in the array. A
more traditional representation based on linked node objects may also be used. more traditional representation based on linked node objects may also be used.
<xref target="array-based-trees"/> and <xref target="link-based-trees"/> provide some details on how to Appendices <xref format="counter" target="array-based-trees" sectionFormat="of" derivedContent="C"/> and <xref format="counter" target="link-based-trees" sectio nFormat="of" derivedContent="D"/> provide some details on how to
implement the tree operations required for MLS in these representations. MLS implement the tree operations required for MLS in these representations. MLS
places no requirements on implementations' internal representations of ratchet places no requirements on implementations' internal representations of ratchet
trees. An implementation may use any tree representation and associated trees. An implementation may use any tree representation and associated
algorithms, as long as they produce correct protocol messages.</t> algorithms, as long as they produce correct protocol messages.</t>
<section anchor="ratchet-tree-nodes"> <section anchor="ratchet-tree-nodes" numbered="true" removeInRFC="false"
<name>Ratchet Tree Nodes</name> toc="include" pn="section-4.1.1">
<t>Each leaf node in a ratchet tree is given an <em>index</em> (or <em <name slugifiedName="name-ratchet-tree-nodes">Ratchet Tree Nodes</name
>leaf index</em>), starting >
at <tt>0</tt> from the left to <tt>2^d - 1</tt> at the right (for a tree with <t <t indent="0" pn="section-4.1.1-1">Each leaf node in a ratchet tree is
t>2^d</tt> leaves). A tree given an <em>index</em> (or <em>leaf index</em>), starting
with <tt>2^d</tt> leaves has <tt>2^(d+1) - 1</tt> nodes, including parent nodes. at 0 from the left to 2<sup>d</sup> - 1 at the right (for a tree with 2<sup>d</s
</t> up> leaves). A tree
<t>Each node in a ratchet tree is either <em>blank</em> (containing no with 2<sup>d</sup> leaves has 2<sup>d+1</sup> - 1 nodes, including parent nodes.
value) or it holds </t>
<t indent="0" pn="section-4.1.1-2">Each node in a ratchet tree is eith
er <em>blank</em> (containing no value) or it holds
an HPKE public key with some associated data:</t> an HPKE public key with some associated data:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>A public key (for the HPKE scheme in use, see <xref target="ciph -4.1.1-3">
ersuites"/>)</li> <li pn="section-4.1.1-3.1">A public key (for the HPKE scheme in use;
<li>A credential (only for leaf nodes, see <xref target="credentials see <xref target="cipher-suites" format="default" sectionFormat="of" derivedCon
"/>)</li> tent="Section 5.1"/>)</li>
<li>An ordered list of "unmerged" leaves (see <xref target="views"/> <li pn="section-4.1.1-3.2">A credential (only for leaf nodes; see <x
)</li> ref target="credentials" format="default" sectionFormat="of" derivedContent="Sec
<li>A hash of certain information about the node's parent, as of the tion 5.3"/>)</li>
last time the <li pn="section-4.1.1-3.3">An ordered list of "unmerged" leaves (see
node was changed (see <xref target="parent-hashes"/>).</li> <xref target="views" format="default" sectionFormat="of" derivedContent="Sectio
n 4.2"/>)</li>
<li pn="section-4.1.1-3.4">A hash of certain information about the n
ode's parent, as of the last time the
node was changed (see <xref target="parent-hashes" format="default" sectionForma
t="of" derivedContent="Section 7.9"/>).</li>
</ul> </ul>
<t>As described in <xref target="views"/>, different members know diff erent subsets of the set <t indent="0" pn="section-4.1.1-4">As described in <xref target="views " format="default" sectionFormat="of" derivedContent="Section 4.2"/>, different members know different subsets of the set
of private keys corresponding to the public keys in nodes in the tree. The of private keys corresponding to the public keys in nodes in the tree. The
private key corresponding to a parent node is known only to members at leaf private key corresponding to a parent node is known only to members at leaf
nodes that are descedants of that node. The private key corresponding to a leaf nodes that are descendants of that node. The private key corresponding to a lea f
node is known only to the member at that leaf node. A leaf node is <em>unmerged </em> node is known only to the member at that leaf node. A leaf node is <em>unmerged </em>
relative to one of its ancestor nodes if the member at the leaf node does not relative to one of its ancestor nodes if the member at the leaf node does not
know the private key corresponding to the ancestor node.</t> know the private key corresponding to the ancestor node.</t>
<t>Every node, regardless of whether the node is blank or populated, h as <t indent="0" pn="section-4.1.1-5">Every node, regardless of whether t he node is blank or populated, has
a corresponding <em>hash</em> that summarizes the contents of the subtree a corresponding <em>hash</em> that summarizes the contents of the subtree
below that node. The rules for computing these hashes are described below that node. The rules for computing these hashes are described
in <xref target="tree-hashes"/>.</t> in <xref target="tree-hashes" format="default" sectionFormat="of" derivedContent
<t>The <em>resolution</em> of a node is an ordered list of non-blank n ="Section 7.8"/>.</t>
odes <t indent="0" pn="section-4.1.1-6">The <em>resolution</em> of a node i
s an ordered list of non-blank nodes
that collectively cover all non-blank descendants of the node. that collectively cover all non-blank descendants of the node.
The resolution of the root contains the set of keys which are collectively neces sary to The resolution of the root contains the set of keys that are collectively necess ary to
encrypt to every node in the group. The resolution encrypt to every node in the group. The resolution
of a node is effectively a depth-first, left-first enumeration of the nearest of a node is effectively a depth-first, left-first enumeration of the nearest
non-blank nodes below the node:</t> non-blank nodes below the node:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>The resolution of a non-blank node comprises the node itself, -4.1.1-7">
followed by its list of unmerged leaves, if any</li> <li pn="section-4.1.1-7.1">The resolution of a non-blank node compri
<li>The resolution of a blank leaf node is the empty list</li> ses the node itself,
<li>The resolution of a blank intermediate node is the result of followed by its list of unmerged leaves, if any.</li>
<li pn="section-4.1.1-7.2">The resolution of a blank leaf node is th
e empty list.</li>
<li pn="section-4.1.1-7.3">The resolution of a blank intermediate no
de is the result of
concatenating the resolution of its left child with the resolution concatenating the resolution of its left child with the resolution
of its right child, in that order</li> of its right child, in that order.</li>
</ul> </ul>
<t>For example, consider the following subtree, where the <tt>_</tt> c haracter <t indent="0" pn="section-4.1.1-8">For example, consider the following subtree, where the <tt>_</tt> character
represents a blank node and unmerged leaves are indicated in square represents a blank node and unmerged leaves are indicated in square
brackets:</t> brackets:</t>
<figure anchor="resolution-tree"> <figure anchor="resolution-tree" align="left" suppress-title="false" p
<name>A tree with blanks and unmerged leaves</name> n="figure-10">
<artwork type="ascii-art"><![CDATA[ <name slugifiedName="name-a-tree-with-blanks-and-unme">A Tree with B
lanks and Unmerged Leaves</name>
<artwork type="ascii-art" align="left" pn="section-4.1.1-9.1">
... ...
/ /
_ _
______|______ ______|______
/ \ / \
X[B] _ X[B] _
__|__ __|__ __|__ __|__
/ \ / \ / \ / \
_ _ Y _ _ _ Y _
/ \ / \ / \ / \ / \ / \ / \ / \
A B _ D E F _ H A B _ D E F _ H
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
]]></artwork> </artwork>
</figure> </figure>
<t>In this tree, we can see all of the above rules in play:</t> <t indent="0" pn="section-4.1.1-10">In this tree, we can see all of th
<ul spacing="normal"> e above rules in play:</t>
<li>The resolution of node X is the list [X, B]</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>The resolution of leaf 2 or leaf 6 is the empty list []</li> -4.1.1-11">
<li>The resolution of top node is the list [X, B, Y, H]</li> <li pn="section-4.1.1-11.1">The resolution of node X is the list [X,
B].</li>
<li pn="section-4.1.1-11.2">The resolution of leaf 2 or leaf 6 is th
e empty list [].</li>
<li pn="section-4.1.1-11.3">The resolution of top node is the list [
X, B, Y, H].</li>
</ul> </ul>
</section> </section>
<section anchor="paths-through-a-ratchet-tree"> <section anchor="paths-through-a-ratchet-tree" numbered="true" removeInR
<name>Paths through a Ratchet Tree</name> FC="false" toc="include" pn="section-4.1.2">
<t>The <em>direct path</em> of a root is the empty list, and of any ot <name slugifiedName="name-paths-through-a-ratchet-tre">Paths through a
her node Ratchet Tree</name>
<t indent="0" pn="section-4.1.2-1">The <em>direct path</em> of a root
is the empty list. The direct path of any other node
is the concatenation of that node's parent along with the parent's direct path.< /t> is the concatenation of that node's parent along with the parent's direct path.< /t>
<t>The <em>copath</em> of a node is the node's sibling concatenated wi th the list of <t indent="0" pn="section-4.1.2-2">The <em>copath</em> of a node is th e node's sibling concatenated with the list of
siblings of all the nodes in its direct path, excluding the root.</t> siblings of all the nodes in its direct path, excluding the root.</t>
<t>The <em>filtered direct path</em> of a leaf node L is the node's di rect path, with any <t indent="0" pn="section-4.1.2-3">The <em>filtered direct path</em> o f a leaf node L is the node's direct path, with any
node removed whose child on the copath of L has an empty resolution (keeping in node removed whose child on the copath of L has an empty resolution (keeping in
mind that any unmerged leaves of the copath child count toward its resolution). mind that any unmerged leaves of the copath child count toward its resolution).
The removed nodes do not need their own key pairs because encrypting to the The removed nodes do not need their own key pairs because encrypting to the
node's key pair would be equivalent to encrypting to its non-copath child.</t> node's key pair would be equivalent to encrypting to its non-copath child.</t>
<t>For example, consider the following tree (where blank nodes are ind icated with <t indent="0" pn="section-4.1.2-4">For example, consider the following tree (where blank nodes are indicated with
<tt>_</tt>, but also assigned a label for reference):</t> <tt>_</tt>, but also assigned a label for reference):</t>
<figure anchor="full-tree"> <figure anchor="full-tree" align="left" suppress-title="false" pn="fig
<name>A complete tree with five members, with labels for blank paren ure-11">
t nodes</name> <name slugifiedName="name-a-complete-tree-with-five-m">A Complete Tr
<artset> ee with Five Members, with Labels for Blank Parent Nodes</name>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" versio <artset pn="section-4.1.2-5.1">
n="1.1" height="240" width="256" viewBox="0 0 256 240" class="diagram" text-anch <artwork type="svg" align="left" pn="section-4.1.2-5.1.1">
or="middle" font-family="monospace" font-size="13px"> <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-fam
ily="monospace" font-size="13px" height="240" text-anchor="middle" version="1.1"
viewBox="0 0 256 240" width="256">
<path d="M 56,104 L 56,128" fill="none" stroke="black"/> <path d="M 56,104 L 56,128" fill="none" stroke="black"/>
<path d="M 120,48 L 120,64" fill="none" stroke="black"/> <path d="M 120,48 L 120,64" fill="none" stroke="black"/>
<path d="M 184,112 L 184,128" fill="none" stroke="black"/> <path d="M 184,112 L 184,128" fill="none" stroke="black"/>
<path d="M 72,64 L 168,64" fill="none" stroke="black"/> <path d="M 72,64 L 168,64" fill="none" stroke="black"/>
<path d="M 40,128 L 72,128" fill="none" stroke="black"/> <path d="M 40,128 L 72,128" fill="none" stroke="black"/>
<path d="M 168,128 L 200,128" fill="none" stroke="black"/> <path d="M 168,128 L 200,128" fill="none" stroke="black"/>
<path d="M 72,128 L 80,144" fill="none" stroke="black"/> <path d="M 72,128 L 80,144" fill="none" stroke="black"/>
<path d="M 92,168 L 96,176" fill="none" stroke="black"/> <path d="M 92,168 L 96,176" fill="none" stroke="black"/>
<path d="M 168,64 L 176,80" fill="none" stroke="black"/> <path d="M 168,64 L 176,80" fill="none" stroke="black"/>
<path d="M 200,128 L 208,144" fill="none" stroke="black"/> <path d="M 200,128 L 208,144" fill="none" stroke="black"/>
skipping to change at line 1501 skipping to change at line 1677
<text x="40" y="228">1</text> <text x="40" y="228">1</text>
<text x="72" y="228">2</text> <text x="72" y="228">2</text>
<text x="104" y="228">3</text> <text x="104" y="228">3</text>
<text x="136" y="228">4</text> <text x="136" y="228">4</text>
<text x="168" y="228">5</text> <text x="168" y="228">5</text>
<text x="200" y="228">6</text> <text x="200" y="228">6</text>
<text x="232" y="228">7</text> <text x="232" y="228">7</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-4.1.2-5.1.2">
W = root W = root
| |
.-----+-----. .-----+-----.
/ \ / \
_=U Y _=U Y
| | | |
.-+-. .-+-. .-+-. .-+-.
/ \ / \ / \ / \
T _=V X _=Z T _=V X _=Z
/ \ / \ / \ / \ / \ / \ / \ / \
A B _ _ E F G _=H A B _ _ E F G _=H
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>In this tree, the direct paths, copaths, and filtered direct paths for the leaf <t indent="0" pn="section-4.1.2-6">In this tree, the direct paths, cop aths, and filtered direct paths for the leaf
nodes are as follows:</t> nodes are as follows:</t>
<table> <table align="center" pn="table-2">
<thead> <thead>
<tr> <tr>
<th align="left">Node</th> <th align="left" colspan="1" rowspan="1">Node</th>
<th align="left">Direct path</th> <th align="left" colspan="1" rowspan="1">Direct path</th>
<th align="left">Copath</th> <th align="left" colspan="1" rowspan="1">Copath</th>
<th align="left">Filtered Direct Path</th> <th align="left" colspan="1" rowspan="1">Filtered Direct Path</t
h>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">A</td> <td align="left" colspan="1" rowspan="1">A</td>
<td align="left">T, U, W</td> <td align="left" colspan="1" rowspan="1">T, U, W</td>
<td align="left">B, V, Y</td> <td align="left" colspan="1" rowspan="1">B, V, Y</td>
<td align="left">T, W</td> <td align="left" colspan="1" rowspan="1">T, W</td>
</tr> </tr>
<tr> <tr>
<td align="left">B</td> <td align="left" colspan="1" rowspan="1">B</td>
<td align="left">T, U, W</td> <td align="left" colspan="1" rowspan="1">T, U, W</td>
<td align="left">A, V, Y</td> <td align="left" colspan="1" rowspan="1">A, V, Y</td>
<td align="left">T, W</td> <td align="left" colspan="1" rowspan="1">T, W</td>
</tr> </tr>
<tr> <tr>
<td align="left">E</td> <td align="left" colspan="1" rowspan="1">E</td>
<td align="left">X, Y, W</td> <td align="left" colspan="1" rowspan="1">X, Y, W</td>
<td align="left">F, Z, U</td> <td align="left" colspan="1" rowspan="1">F, Z, U</td>
<td align="left">X, Y, W</td> <td align="left" colspan="1" rowspan="1">X, Y, W</td>
</tr> </tr>
<tr> <tr>
<td align="left">F</td> <td align="left" colspan="1" rowspan="1">F</td>
<td align="left">X, Y, W</td> <td align="left" colspan="1" rowspan="1">X, Y, W</td>
<td align="left">E, Z, U</td> <td align="left" colspan="1" rowspan="1">E, Z, U</td>
<td align="left">X, Y, W</td> <td align="left" colspan="1" rowspan="1">X, Y, W</td>
</tr> </tr>
<tr> <tr>
<td align="left">G</td> <td align="left" colspan="1" rowspan="1">G</td>
<td align="left">Z, Y, W</td> <td align="left" colspan="1" rowspan="1">Z, Y, W</td>
<td align="left">H, X, U</td> <td align="left" colspan="1" rowspan="1">H, X, U</td>
<td align="left">Y, W</td> <td align="left" colspan="1" rowspan="1">Y, W</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="views"> <section anchor="views" numbered="true" removeInRFC="false" toc="include"
<name>Views of a Ratchet Tree</name> pn="section-4.2">
<t>We generally assume that each participant maintains a complete and <name slugifiedName="name-views-of-a-ratchet-tree">Views of a Ratchet Tr
ee</name>
<t indent="0" pn="section-4.2-1">We generally assume that each participa
nt maintains a complete and
up-to-date view of the public state of the group's ratchet tree, up-to-date view of the public state of the group's ratchet tree,
including the public keys for all nodes and the credentials including the public keys for all nodes and the credentials
associated with the leaf nodes.</t> associated with the leaf nodes.</t>
<t>No participant in an MLS group knows the private key associated with <t indent="0" pn="section-4.2-2">No participant in an MLS group knows th e private key associated with
every node in the tree. Instead, each member is assigned to a leaf of the tree, every node in the tree. Instead, each member is assigned to a leaf of the tree,
which determines the subset of private keys it knows. The which determines the subset of private keys it knows. The
credential stored at that leaf is one provided by the member.</t> credential stored at that leaf is one provided by the member.</t>
<t>In particular, MLS maintains the members' views of the tree in such <t indent="0" pn="section-4.2-3">In particular, MLS maintains the member s' views of the tree in such
a way as to maintain the <em>tree invariant</em>:</t> a way as to maintain the <em>tree invariant</em>:</t>
<artwork><![CDATA[ <blockquote pn="section-4.2-4">
The private key for a node in the tree is known to a member of The private key for a node in the tree is known to a member of
the group only if the node's subtree contains that member's leaf. the group only if the node's subtree contains that member's leaf.
]]></artwork> </blockquote>
<t>In other words, if a node is not blank, then it holds a public key. <t indent="0" pn="section-4.2-5">In other words, if a node is not blank,
then it holds a public key.
The corresponding private key is known only to members occupying The corresponding private key is known only to members occupying
leaves below that node.</t> leaves below that node.</t>
<t>The reverse implication is not true: A member may not know the privat e key of <t indent="0" pn="section-4.2-6">The reverse implication is not true: A member may not know the private key of
an intermediate node above them. Such a member has an <em>unmerged</em> leaf at the an intermediate node above them. Such a member has an <em>unmerged</em> leaf at the
intermediate node. Encrypting to an intermediate node requires encrypting to intermediate node. Encrypting to an intermediate node requires encrypting to
the node's public key, as well as the public keys of all the unmerged leaves the node's public key, as well as the public keys of all the unmerged leaves
below it. A leaf is unmerged with regard to all of its ancestors when it is below it. A leaf is unmerged with regard to all of its ancestors when it is
first added, because the process of adding the leaf does not give it access to first added, because the process of adding the leaf does not give it access to
the private keys for all of the nodes above it in the tree. Leaves are "merged" the private keys for all of the nodes above it in the tree. Leaves are "merged"
as they receive the private keys for nodes, as described in as they receive the private keys for nodes, as described in
<xref target="ratchet-tree-evolution"/>.</t> <xref target="ratchet-tree-evolution" format="default" sectionFormat="of" derive
<t>For example, consider a four-member group (A, B, C, D) where the node dContent="Section 7.4"/>.</t>
above the <t indent="0" pn="section-4.2-7">For example, consider a four-member gro
up (A, B, C, D) where the node above the
right two members is blank. (This is what it would look like if A created a right two members is blank. (This is what it would look like if A created a
group with B, C, and D.) Then the public state of the tree and the views of the group with B, C, and D.) Then the public state of the tree and the views of the
private keys of the tree held by each participant would be as follows, where <tt >_</tt> private keys of the tree held by each participant would be as follows, where <tt >_</tt>
represents a blank node, <tt>?</tt> represents an unknown private key, and <tt>p k(X)</tt> represents a blank node, <tt>?</tt> represents an unknown private key, and <tt>p k(X)</tt>
represents the public key corresponding to the private key <tt>X</tt>:</t> represents the public key corresponding to the private key <tt>X</tt>:</t>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-4.2-8">
Public Tree Public Tree
============================ ============================
pk(ABCD) pk(ABCD)
/ \ / \
pk(AB) _ pk(AB) _
/ \ / \ / \ / \
pk(A) pk(B) pk(C) pk(D) pk(A) pk(B) pk(C) pk(D)
Private @ A Private @ B Private @ C Private @ D Private @ A Private @ B Private @ C Private @ D
============= ============= ============= ============= ============= ============= ============= =============
ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
/ \ / \ / \ / \ / \ / \ / \ / \
AB _ AB _ ? _ ? _ AB _ AB _ ? _ ? _
/ \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \
A ? ? ? ? B ? ? ? ? C ? ? ? ? D A ? ? ? ? B ? ? ? ? C ? ? ? ? D
]]></artwork> </artwork>
<t>Note how the tree invariant applies: Each member knows only their own <t indent="0" pn="section-4.2-9">Note how the tree invariant applies: Ea
leaf, ch member knows only their own leaf,
the private key AB is known only to A and B, and the private key ABCD the private key AB is known only to A and B, and the private key ABCD
is known to all four members. This also illustrates another important is known to all four members. This also illustrates another important
point: it is possible for there to be "holes" on the path from a member's leaf point: it is possible for there to be "holes" on the path from a member's leaf
to the root in which the member knows the key both above and below to the root in which the member knows the key both above and below
a given node, but not for that node, as in the case with D.</t> a given node, but not for that node, as in the case with D.</t>
</section> </section>
</section> </section>
<section anchor="cryptographic-objects"> <section anchor="cryptographic-objects" numbered="true" removeInRFC="false"
<name>Cryptographic Objects</name> toc="include" pn="section-5">
<section anchor="ciphersuites"> <name slugifiedName="name-cryptographic-objects">Cryptographic Objects</na
<name>Ciphersuites</name> me>
<t>Each MLS session uses a single ciphersuite that specifies the <section anchor="cipher-suites" numbered="true" removeInRFC="false" toc="i
nclude" pn="section-5.1">
<name slugifiedName="name-cipher-suites">Cipher Suites</name>
<t indent="0" pn="section-5.1-1">Each MLS session uses a single cipher s
uite that specifies the
following primitives to be used in group key computations:</t> following primitives to be used in group key computations:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5
<li> .1-2">
<t>HPKE parameters: <li pn="section-5.1-2.1">
<t indent="0" pn="section-5.1-2.1.1">HPKE parameters:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>A Key Encapsulation Mechanism (KEM)</li> on-5.1-2.1.2">
<li>A Key Derivation Function (KDF)</li> <li pn="section-5.1-2.1.2.1">A Key Encapsulation Mechanism (KEM)</
<li>An Authenticated Encryption with Associated Data (AEAD) encryp li>
tion algorithm</li> <li pn="section-5.1-2.1.2.2">A Key Derivation Function (KDF)</li>
<li pn="section-5.1-2.1.2.3">An Authenticated Encryption with Asso
ciated Data (AEAD) encryption algorithm</li>
</ul> </ul>
</li> </li>
<li>A hash algorithm</li> <li pn="section-5.1-2.2">A hash algorithm</li>
<li>A MAC algorithm</li> <li pn="section-5.1-2.3">A Message Authentication Code (MAC) algorithm
<li>A signature algorithm</li> </li>
<li pn="section-5.1-2.4">A signature algorithm</li>
</ul> </ul>
<t>MLS uses HPKE for public-key encryption <xref target="RFC9180"/>. Th <t indent="0" pn="section-5.1-3">MLS uses HPKE for public key encryption
e <xref target="RFC9180" format="default" sectionFormat="of" derivedContent="RFC9
<tt>DeriveKeyPair</tt> function associated to the KEM for the ciphersuite maps o 180"/>. The
ctet <tt>DeriveKeyPair</tt> function associated to the KEM for the cipher suite maps
octet
strings to HPKE key pairs. As in HPKE, MLS assumes that an AEAD algorithm strings to HPKE key pairs. As in HPKE, MLS assumes that an AEAD algorithm
produces a single ciphertext output from AEAD encryption (aligning with produces a single ciphertext output from AEAD encryption (aligning with
<xref target="RFC5116"/>), as opposed to a separate ciphertext and tag.</t> <xref target="RFC5116" format="default" sectionFormat="of" derivedContent="RFC51
<t>Ciphersuites are represented with the CipherSuite type. The ciphersui 16"/>), as opposed to a separate ciphertext and tag.</t>
tes are <t indent="0" pn="section-5.1-4">Cipher suites are represented with the
defined in <xref target="mls-ciphersuites"/>.</t> CipherSuite type. The cipher suites are
<section anchor="public-keys"> defined in <xref target="mls-cipher-suites" format="default" sectionFormat="of"
<name>Public Keys</name> derivedContent="Section 17.1"/>.</t>
<t>HPKE public keys are opaque values in a format defined by the under <section anchor="public-keys" numbered="true" removeInRFC="false" toc="i
lying nclude" pn="section-5.1.1">
protocol (see Section 4 of <xref target="RFC9180"/> for more information).</t> <name slugifiedName="name-public-keys">Public Keys</name>
<sourcecode type="tls"><![CDATA[ <t indent="0" pn="section-5.1.1-1">HPKE public keys are opaque values
opaque HPKEPublicKey<V>; in a format defined by the underlying
]]></sourcecode> protocol (see <xref section="4" sectionFormat="of" target="RFC9180" format="defa
<t>Signature public keys are likewise represented as opaque values in ult" derivedLink="https://rfc-editor.org/rfc/rfc9180#section-4" derivedContent="
a format RFC9180"/> for more information).</t>
defined by the ciphersuite's signature scheme.</t> <sourcecode type="tls-presentation" markers="false" pn="section-5.1.1-
<sourcecode type="tls"><![CDATA[ 2">
opaque SignaturePublicKey<V>; opaque HPKEPublicKey&lt;V&gt;;
]]></sourcecode> </sourcecode>
<t>For ciphersuites using Ed25519 or Ed448 signature schemes, the publ <t indent="0" pn="section-5.1.1-3">Signature public keys are likewise
ic key is in represented as opaque values in a format
the format specified in <xref target="RFC8032"/>. For ciphersuites using ECDSA defined by the cipher suite's signature scheme.</t>
with the <sourcecode type="tls-presentation" markers="false" pn="section-5.1.1-
NIST curves (P-256, P-384, or P-521), the public key is represented as an 4">
encoded UncompressedPointRepresentation struct, as defined in <xref target="RFC8 opaque SignaturePublicKey&lt;V&gt;;
446"/>.</t> </sourcecode>
<t indent="0" pn="section-5.1.1-5">For cipher suites using the Edwards
-curve Digital Signature Algorithm (EdDSA)
signature schemes (Ed25519 or Ed448), the public key is in the format specified
in <xref target="RFC8032" format="default" sectionFormat="of" derivedContent="RF
C8032"/>.</t>
<t indent="0" pn="section-5.1.1-6">For cipher suites using the Ellipti
c Curve Digital Signature Algorithm (ECDSA)
with the NIST curves (P-256, P-384, or P-521), the public key is represented as
an encoded UncompressedPointRepresentation struct, as defined in <xref target="R
FC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>.</t>
</section> </section>
<section anchor="signing"> <section anchor="signing" numbered="true" removeInRFC="false" toc="inclu
<name>Signing</name> de" pn="section-5.1.2">
<t>The signature algorithm specified in a group's ciphersuite is the m <name slugifiedName="name-signing">Signing</name>
andatory algorithm <t indent="0" pn="section-5.1.2-1">The signature algorithm specified i
n a group's cipher suite is the mandatory algorithm
to be used for signing messages within the group. It to be used for signing messages within the group. It
MUST be the same as the signature algorithm specified in the credentials in the <bcp14>MUST</bcp14> be the same as the signature algorithm specified in the cred entials in the
leaves of the tree (including the leaf node information in KeyPackages used to leaves of the tree (including the leaf node information in KeyPackages used to
add new members).</t> add new members).</t>
<t>The signatures used in this document are encoded as specified in <x <t indent="0" pn="section-5.1.2-2">The signatures used in this documen
ref target="RFC8446"/>. t are encoded as specified in <xref target="RFC8446" format="default" sectionFor
In particular, ECDSA signatures are DER-encoded and EdDSA signatures are defined mat="of" derivedContent="RFC8446"/>.
as the concatenation of <tt>r</tt> and <tt>s</tt> as specified in <xref target=" In particular, ECDSA signatures are DER encoded, and EdDSA signatures are define
RFC8032"/>.</t> d
<t>To disambiguate different signatures used in MLS, each signed value as the concatenation of <tt>R</tt> and <tt>S</tt>, as specified in <xref target=
is prefixed "RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>.</t>
<t indent="0" pn="section-5.1.2-3">To disambiguate different signature
s used in MLS, each signed value is prefixed
by a label as shown below:</t> by a label as shown below:</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-5.1.2-4">
SignWithLabel(SignatureKey, Label, Content) = SignWithLabel(SignatureKey, Label, Content) =
Signature.Sign(SignatureKey, SignContent) Signature.Sign(SignatureKey, SignContent)
VerifyWithLabel(VerificationKey, Label, Content, SignatureValue) = VerifyWithLabel(VerificationKey, Label, Content, SignatureValue) =
Signature.Verify(VerificationKey, SignContent, SignatureValue) Signature.Verify(VerificationKey, SignContent, SignatureValue)
]]></sourcecode> </sourcecode>
<t>Where SignContent is specified as:</t> <t indent="0" pn="section-5.1.2-5">Where SignContent is specified as:<
<sourcecode type="tls"><![CDATA[ /t>
<sourcecode type="tls-presentation" markers="false" pn="section-5.1.2-
6">
struct { struct {
opaque label<V>; opaque label&lt;V&gt;;
opaque content<V>; opaque content&lt;V&gt;;
} SignContent; } SignContent;
]]></sourcecode> </sourcecode>
<t>And its fields set to:</t> <t indent="0" pn="section-5.1.2-7">And its fields are set to:</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-5.1.2-8">
label = "MLS 1.0 " + Label; label = "MLS 1.0 " + Label;
content = Content; content = Content;
]]></sourcecode> </sourcecode>
<t>Here, the functions <tt>Signature.Sign</tt> and <tt>Signature.Verif <t indent="0" pn="section-5.1.2-9">The functions <tt>Signature.Sign</t
y</tt> are defined by the t> and <tt>Signature.Verify</tt> are defined by the
signature algorithm. If MLS extensions require signatures by group members, signature algorithm. If MLS extensions require signatures by group members,
they should re-use the SignWithLabel construction, using a distinct label. To they should reuse the SignWithLabel construction, using a distinct label. To
avoid collisions in these labels, an IANA registry is defined in avoid collisions in these labels, an IANA registry is defined in
<xref target="mls-signature-labels"/>.</t> <xref target="mls-signature-labels" format="default" sectionFormat="of" derivedC ontent="Section 17.6"/>.</t>
</section> </section>
<section anchor="public-key-encryption"> <section anchor="public-key-encryption" numbered="true" removeInRFC="fal
<name>Public-Key Encryption</name> se" toc="include" pn="section-5.1.3">
<t>As with signing, MLS includes a label and context in encryption ope <name slugifiedName="name-public-key-encryption">Public Key Encryption
rations to </name>
<t indent="0" pn="section-5.1.3-1">As with signing, MLS includes a lab
el and context in encryption operations to
avoid confusion between ciphertexts produced for different purposes. Encryption avoid confusion between ciphertexts produced for different purposes. Encryption
and decryption including this label and context are done as follows:</t> and decryption including this label and context are done as follows:</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-5.1.3-2">
EncryptWithLabel(PublicKey, Label, Context, Plaintext) = EncryptWithLabel(PublicKey, Label, Context, Plaintext) =
SealBase(PublicKey, EncryptContext, "", Plaintext) SealBase(PublicKey, EncryptContext, "", Plaintext)
DecryptWithLabel(PrivateKey, Label, Context, KEMOutput, Ciphertext) = DecryptWithLabel(PrivateKey, Label, Context, KEMOutput, Ciphertext) =
OpenBase(KEMOutput, PrivateKey, EncryptContext, "", Ciphertext) OpenBase(KEMOutput, PrivateKey, EncryptContext, "", Ciphertext)
]]></sourcecode> </sourcecode>
<t>Where EncryptContext is specified as:</t> <t indent="0" pn="section-5.1.3-3">Where EncryptContext is specified a
<sourcecode type="tls"><![CDATA[ s:</t>
<sourcecode type="tls-presentation" markers="false" pn="section-5.1.3-
4">
struct { struct {
opaque label<V>; opaque label&lt;V&gt;;
opaque context<V>; opaque context&lt;V&gt;;
} EncryptContext; } EncryptContext;
]]></sourcecode> </sourcecode>
<t>And its fields set to:</t> <t indent="0" pn="section-5.1.3-5">And its fields are set to:</t>
<artwork><![CDATA[ <artwork align="left" pn="section-5.1.3-6">
label = "MLS 1.0 " + Label; label = "MLS 1.0 " + Label;
context = Context; context = Context;
]]></artwork> </artwork>
<t>Here, the functions <tt>SealBase</tt> and <tt>OpenBase</tt> are def <t indent="0" pn="section-5.1.3-7">The functions <tt>SealBase</tt> and
ined <xref target="RFC9180"/>, using the <tt>OpenBase</tt> are defined in <xref section="6.1" sectionFormat="of" target=
HPKE algorithms specified by the group's ciphersuite. If MLS extensions "RFC9180" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9180#secti
require HPKE encryption operations, they should re-use the EncryptWithLabel on-6.1" derivedContent="RFC9180"/> (with "Base" as the MODE), using the HPKE alg
construction, using a distinct label. To avoid collisions in these labels, an orithms specified by the
IANA registry is defined in <xref target="mls-public-key-encryption-labels"/>.</ group's cipher suite. If MLS extensions require HPKE encryption operations, the
t> y
should reuse the EncryptWithLabel construction, using a distinct label. To
avoid collisions in these labels, an IANA registry is defined in
<xref target="mls-public-key-encryption-labels" format="default" sectionFormat="
of" derivedContent="Section 17.7"/>.</t>
</section> </section>
</section> </section>
<section anchor="hash-based-identifiers"> <section anchor="hash-based-identifiers" numbered="true" removeInRFC="fals
<name>Hash-Based Identifiers</name> e" toc="include" pn="section-5.2">
<t>Some MLS messages refer to other MLS objects by hash. For example, W <name slugifiedName="name-hash-based-identifiers">Hash-Based Identifiers
elcome </name>
<t indent="0" pn="section-5.2-1">Some MLS messages refer to other MLS ob
jects by hash. For example, Welcome
messages refer to KeyPackages for the members being welcomed, and Commits refer messages refer to KeyPackages for the members being welcomed, and Commits refer
to Proposals they cover. These identifiers are computed as follows:</t> to Proposals they cover. These identifiers are computed as follows:</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-5.2-2">
opaque HashReference<V>; opaque HashReference&lt;V&gt;;
HashReference KeyPackageRef; HashReference KeyPackageRef;
HashReference ProposalRef; HashReference ProposalRef;
]]></sourcecode> </sourcecode>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-5.2-3">
MakeKeyPackageRef(value) = RefHash("MLS 1.0 KeyPackage Reference", value) MakeKeyPackageRef(value)
MakeProposalRef(value) = RefHash("MLS 1.0 Proposal Reference", value) = RefHash("MLS 1.0 KeyPackage Reference", value)
MakeProposalRef(value)
= RefHash("MLS 1.0 Proposal Reference", value)
RefHash(label, value) = Hash(RefHashInput) RefHash(label, value) = Hash(RefHashInput)
]]></sourcecode> </sourcecode>
<t>Where RefHashInput is defined as:</t> <t indent="0" pn="section-5.2-4">Where RefHashInput is defined as:</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-5.2-5">
struct { struct {
opaque label<V>; opaque label&lt;V&gt;;
opaque value<V>; opaque value&lt;V&gt;;
} RefHashInput; } RefHashInput;
]]></sourcecode> </sourcecode>
<t>And its fields set to:</t> <t indent="0" pn="section-5.2-6">And its fields are set to:</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-5.2-7">
label = label; label = label;
value = value; value = value;
]]></sourcecode> </sourcecode>
<t>For a KeyPackageRef, the <tt>value</tt> input is the encoded KeyPacka <t indent="0" pn="section-5.2-8">For a KeyPackageRef, the <tt>value</tt>
ge, and the input is the encoded KeyPackage, and the
ciphersuite specified in the KeyPackage determines the KDF used. For a cipher suite specified in the KeyPackage determines the KDF used. For a
ProposalRef, the <tt>value</tt> input is the AuthenticatedContent carrying the ProposalRef, the <tt>value</tt> input is the AuthenticatedContent carrying the
proposal. In the latter two cases, the KDF is determined by the group's Proposal. In the latter two cases, the KDF is determined by the group's
ciphersuite.</t> cipher suite.</t>
</section> </section>
<section anchor="credentials"> <section anchor="credentials" numbered="true" removeInRFC="false" toc="inc
<name>Credentials</name> lude" pn="section-5.3">
<t>Each member of a group presents a credential that provides one or mor <name slugifiedName="name-credentials">Credentials</name>
e <t indent="0" pn="section-5.3-1">Each member of a group presents a crede
identities for the member, and associates them with the member's signing key. ntial that provides one or more
identities for the member and associates them with the member's signing key.
The identities and signing key are verified by the Authentication Service in use The identities and signing key are verified by the Authentication Service in use
for a group.</t> for a group.</t>
<t>It is up to the application to decide which identifier or identifiers to use at <t indent="0" pn="section-5.3-2">It is up to the application to decide w hich identifiers to use at
the application level. For example, the application level. For example,
a certificate in an X509Credential may attest to several domain names or email a certificate in an X509Credential may attest to several domain names or email
addresses in its subjectAltName extension. An application may decide to addresses in its subjectAltName extension. An application may decide to
present all of these to a user, or if it knows a "desired" domain name or email present all of these to a user, or if it knows a "desired" domain name or email
address, it can check that the desired identifier is among those attested. address, it can check that the desired identifier is among those attested.
Using the terminology from <xref target="RFC6125"/>, a Credential provides "pres ented Using the terminology from <xref target="RFC6125" format="default" sectionFormat ="of" derivedContent="RFC6125"/>, a credential provides "presented
identifiers", and it is up to the application to supply a "reference identifier" identifiers", and it is up to the application to supply a "reference identifier"
for the authenticated client, if any.</t> for the authenticated client, if any.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-5.3-3">
// See IANA registry for registered values // See the "MLS Credential Types" IANA registry for values
uint16 CredentialType; uint16 CredentialType;
struct { struct {
opaque cert_data<V&gt;; opaque cert_data<V&gt;;
} Certificate; } Certificate;
struct { struct {
CredentialType credential_type; CredentialType credential_type;
select (Credential.credential_type) { select (Credential.credential_type) {
case basic: case basic:
opaque identity<V&gt;; opaque identity<V&gt;;
case x509: case x509:
Certificate certificates<V&gt;; Certificate certificates<V&gt;;
}; };
} Credential; } Credential;
]]></sourcecode> </sourcecode>
<t>A "basic" credential is a bare assertion of an identity, without any <t indent="0" pn="section-5.3-4">A "basic" credential is a bare assertio
additional n of an identity, without any additional
information. The format of the encoded identity is defined by the application.< /t> information. The format of the encoded identity is defined by the application.< /t>
<t>For an X.509 credential, each entry in the <tt>certificates</tt> fiel d represents a single DER-encoded <t indent="0" pn="section-5.3-5">For an X.509 credential, each entry in the <tt>certificates</tt> field represents a single DER-encoded
X.509 certificate. The chain is ordered such that the first entry (certificates[ 0]) is X.509 certificate. The chain is ordered such that the first entry (certificates[ 0]) is
the end-entity certificate. The public key encoded in the the end-entity certificate. The public key encoded in the
<tt>subjectPublicKeyInfo</tt> of the end-entity certificate MUST be identical to <tt>subjectPublicKeyInfo</tt> of the end-entity certificate <bcp14>MUST</bcp14>
the be identical to the
<tt>signature_key</tt> in the LeafNode containing this credential. A chain MAY o <tt>signature_key</tt> in the LeafNode containing this credential. A chain <bcp1
mit any 4>MAY</bcp14> omit any
non-leaf certificates that supported peers are known to already possess.</t> non-leaf certificates that supported peers are known to already possess.</t>
<section anchor="credential-validation"> <section anchor="credential-validation" numbered="true" removeInRFC="fal
<name>Credential Validation</name> se" toc="include" pn="section-5.3.1">
<t>The application using MLS is responsible for specifying which ident <name slugifiedName="name-credential-validation">Credential Validation
ifiers it </name>
<t indent="0" pn="section-5.3.1-1">The application using MLS is respon
sible for specifying which identifiers it
finds acceptable for each member in a group. In other words, following the finds acceptable for each member in a group. In other words, following the
model that <xref target="RFC6125"/> describes for TLS, the application maintains a list of model that <xref target="RFC6125" format="default" sectionFormat="of" derivedCon tent="RFC6125"/> describes for TLS, the application maintains a list of
"reference identifiers" for the members of a group, and the credentials provide "reference identifiers" for the members of a group, and the credentials provide
"presented identifiers". A member of a group is authenticated by first "presented identifiers". A member of a group is authenticated by first
validating that the member's credential legitimately represents some presented validating that the member's credential legitimately represents some presented
identifiers, and then ensuring that the reference identifiers for the member are identifiers, and then ensuring that the reference identifiers for the member are
authenticated by those presented identifiers.</t> authenticated by those presented identifiers.</t>
<t>The parts of the system that perform these functions are collective <t indent="0" pn="section-5.3.1-2">The parts of the system that perfor
ly referred m these functions are collectively referred
to as the Authentication Service (AS) <xref target="I-D.ietf-mls-architecture"/> to as the Authentication Service (AS) <xref target="I-D.ietf-mls-architecture" f
. A ormat="default" sectionFormat="of" derivedContent="MLS-ARCH"/>. A
member's credential is said to be <em>validated with the AS</em> when the AS ver ifies member's credential is said to be <em>validated with the AS</em> when the AS ver ifies
that the credential's presented identifiers are correctly associated with the that the credential's presented identifiers are correctly associated with the
<tt>signature_key</tt> field in the member's LeafNode, and verifies that those <tt>signature_key</tt> field in the member's LeafNode, and that those
identifiers match the reference identifiers for the member.</t> identifiers match the reference identifiers for the member.</t>
<t>Whenever a new credential is introduced in the group, it MUST be va lidated with <t indent="0" pn="section-5.3.1-3">Whenever a new credential is introd uced in the group, it <bcp14>MUST</bcp14> be validated with
the AS. In particular, at the following events in the protocol:</t> the AS. In particular, at the following events in the protocol:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>When a member receives a KeyPackage that it will use in an Add p -5.3.1-4">
roposal to add <li pn="section-5.3.1-4.1">When a member receives a KeyPackage that
a new member to the group.</li> it will use in an Add proposal to add
<li>When a member receives a GroupInfo object that it will use to jo a new member to the group</li>
in a group, <li pn="section-5.3.1-4.2">When a member receives a GroupInfo object
either via a Welcome or via an External Commit</li> that it will use to join a group,
<li>When a member receives an Add proposal adding a member to the gr either via a Welcome or via an external Commit</li>
oup.</li> <li pn="section-5.3.1-4.3">When a member receives an Add proposal ad
<li>When a member receives an Update proposal whose LeafNode has a n ding a member to the group</li>
ew credential <li pn="section-5.3.1-4.4">When a member receives an Update proposal
for the member.</li> whose LeafNode has a new credential
<li>When a member receives a Commit with an UpdatePath whose LeafNod for the member</li>
e has a new <li pn="section-5.3.1-4.5">When a member receives a Commit with an U
credential for the committer.</li> pdatePath whose LeafNode has a new
<li>When an <tt>external_senders</tt> extension is added to the grou credential for the committer</li>
p, or an existing <li pn="section-5.3.1-4.6">When an <tt>external_senders</tt> extensi
<tt>external_senders</tt> extension is updated.</li> on is added to the group</li>
<li pn="section-5.3.1-4.7">When an existing <tt>external_senders</tt
> extension is updated</li>
</ul> </ul>
<t>In cases where a member's credential is being replaced, such as Upd <t indent="0" pn="section-5.3.1-5">In cases where a member's credentia
ate and l is being replaced, such as the Update and
Commit cases above, the AS MUST also verify that the set of presented Commit cases above, the AS <bcp14>MUST</bcp14> also verify that the set of prese
nted
identifiers in the new credential is valid as a successor to the set of 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 presented identifiers in the old credential, according to the application's
policy.</t> policy.</t>
</section> </section>
<section anchor="credential-expiry-and-revocation"> <section anchor="credential-expiry-and-revocation" numbered="true" remov
<name>Credential Expiry and Revocation</name> eInRFC="false" toc="include" pn="section-5.3.2">
<t>In some credential schemes, a valid credential can "expire", or bec <name slugifiedName="name-credential-expiry-and-revoc">Credential Expi
ome invalid ry and Revocation</name>
<t indent="0" pn="section-5.3.2-1">In some credential schemes, a valid
credential can "expire" or become invalid
after a certain point in time. For example, each X.509 certificate has a after a certain point in time. For example, each X.509 certificate has a
<tt>notAfter</tt> field, expressing a time after which the certificate is not va lid.</t> <tt>notAfter</tt> field, expressing a time after which the certificate is not va lid.</t>
<t>Expired credentials can cause operational problems in light of the <t indent="0" pn="section-5.3.2-2">Expired credentials can cause opera
validation tional problems in light of the validation
requirements of <xref target="credential-validation"/>. Applications can apply requirements of <xref target="credential-validation" format="default" sectionFor
some mat="of" derivedContent="Section 5.3.1"/>. Applications can apply some
operational practices and adaptations to Authentication Service policies to operational practices and adaptations to Authentication Service policies to
moderate these impacts.</t> moderate these impacts.</t>
<t>In general, to avoid operational problems such as new joiners rejec ting expired <t indent="0" pn="section-5.3.2-3">In general, to avoid operational pr oblems such as new joiners rejecting expired
credentials in a group, applications that use such credentials should ensure to credentials in a group, applications that use such credentials should ensure to
the extent practical that all of the credentials in use in a group are valid at the extent practical that all of the credentials in use in a group are valid at
all times.</t> all times.</t>
<t>If a member finds that its credential has expired (or will soon), i t should <t indent="0" pn="section-5.3.2-4">If a member finds that its credenti al has expired (or will soon), it should
issue an Update or Commit that replaces it with a valid credential. For this issue an Update or Commit that replaces it with a valid credential. For this
reason, members SHOULD accept Update proposals and Commits issued by members reason, members <bcp14>SHOULD</bcp14> accept Update proposals and Commits issued by members
with expired credentials, if the credential in the Update or Commit is valid.</t > with expired credentials, if the credential in the Update or Commit is valid.</t >
<t>Similarly, when a client is processing messages sent some time in t <t indent="0" pn="section-5.3.2-5">Similarly, when a client is process
he past ing messages sent some time in the past
(e.g., syncing up with a group after being offline), the client SHOULD accept (e.g., syncing up with a group after being offline), the client <bcp14>SHOULD</b
cp14> accept
signatures from members with expired credentials, since the credential may signatures from members with expired credentials, since the credential may
have been valid at the time the message was sent.</t> have been valid at the time the message was sent.</t>
<t>If a member finds that another member's credential has expired, the y may issue a <t indent="0" pn="section-5.3.2-6">If a member finds that another memb er's credential has expired, they may issue a
Remove that removes that member. For example, an application could require a Remove that removes that member. For example, an application could require a
member preparing to issue a Commit to check the tree for expired credentials and member preparing to issue a Commit to check the tree for expired credentials and
include Remove proposals for those members in its Commit. In situations where include Remove proposals for those members in its Commit. In situations where
the group tree is known to the DS, the DS could also monitor the tree for the group tree is known to the DS, the DS could also monitor the tree for
expired credentials and issue external Remove proposals.</t> expired credentials and issue external Remove proposals.</t>
<t>Some credential schemes also allow credentials to be revoked. Revo <t indent="0" pn="section-5.3.2-7">Some credential schemes also allow
cation is credentials to be revoked. Revocation is
similar to expiry, in that a previously valid credential becomes invalid. similar to expiry in that a previously valid credential becomes invalid.
As such, most of the considerations above also apply to revoked credentials. As such, most of the considerations above also apply to revoked credentials.
However, applications may want to treat revoked credentials differently, e.g., However, applications may want to treat revoked credentials differently, e.g.,
removing members with revoked credentials while allowing members with expired by removing members with revoked credentials while allowing members with expired
credentials time to update.</t> credentials time to update.</t>
</section> </section>
<section anchor="uniquely-identifying-clients"> <section anchor="uniquely-identifying-clients" numbered="true" removeInR
<name>Uniquely Identifying Clients</name> FC="false" toc="include" pn="section-5.3.3">
<t>MLS implementations will presumably provide applications with a way <name slugifiedName="name-uniquely-identifying-client">Uniquely Identi
to request fying Clients</name>
<t indent="0" pn="section-5.3.3-1">MLS implementations will presumably
provide applications with a way to request
protocol operations with regard to other clients (e.g., removing clients). Such protocol operations with regard to other clients (e.g., removing clients). Such
functions will need to refer to the other clients using some identifier. MLS functions will need to refer to the other clients using some identifier. MLS
clients have a few types of identifiers, with different operational properties.< /t> clients have a few types of identifiers, with different operational properties.< /t>
<t>Internally to the protocol, group members are uniquely identified b y their leaf <t indent="0" pn="section-5.3.3-2">Internally to the protocol, group m embers are uniquely identified by their leaf
index. However, a leaf index is only valid for referring to members in a given 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 epoch. The same leaf index may represent a different member, or no member at
all, in a subsequent epoch.</t> all, in a subsequent epoch.</t>
<t>The Credentials presented by the clients in a group authenticate <t indent="0" pn="section-5.3.3-3">The Credentials presented by the cl ients in a group authenticate
application-level identifiers for the clients. However, these identifiers may n ot application-level identifiers for the clients. However, these identifiers may n ot
uniquely identify clients. For example, if a user has multiple devices that are 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 all present in an MLS group, then those devices' clients could all present the
user's application-layer identifiers.</t> user's application-layer identifiers.</t>
<t>If needed, applications may add application-specific identifiers to the <t indent="0" pn="section-5.3.3-4">If needed, applications may add app lication-specific identifiers to the
<tt>extensions</tt> field of a LeafNode object with the <tt>application_id</tt> extension.</t> <tt>extensions</tt> field of a LeafNode object with the <tt>application_id</tt> extension.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-5.3.3-
opaque application_id<V>; 5">
]]></sourcecode> opaque application_id&lt;V&gt;;
<t>However, applications MUST NOT rely on the data in an <tt>applicati </sourcecode>
on_id</tt> extension <t indent="0" pn="section-5.3.3-6">However, applications <bcp14>MUST N
as if it were authenticated by the Authentication Service, and SHOULD gracefully OT</bcp14> rely on the data in an <tt>application_id</tt> extension
as if it were authenticated by the Authentication Service, and <bcp14>SHOULD</bc
p14> gracefully
handle cases where the identifier presented is not unique.</t> handle cases where the identifier presented is not unique.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="message-framing"> <section anchor="message-framing" numbered="true" removeInRFC="false" toc="i
<name>Message Framing</name> nclude" pn="section-6">
<t>Handshake and application messages use a common framing structure. <name slugifiedName="name-message-framing">Message Framing</name>
<t indent="0" pn="section-6-1">Handshake and application messages use a co
mmon framing structure.
This framing provides encryption to ensure confidentiality within the This framing provides encryption to ensure confidentiality within the
group, as well as signing to authenticate the sender.</t> group, as well as signing to authenticate the sender.</t>
<t>In most of the protocol, messages are handled in the form of <t indent="0" pn="section-6-2">In most of the protocol, messages are handl ed in the form of
AuthenticatedContent objects. These structures contain the content of the AuthenticatedContent objects. These structures contain the content of the
message itself as well as information to authenticate the sender (see message itself as well as information to authenticate the sender (see
<xref target="content-authentication"/>). The additional protections required t o transmit <xref target="content-authentication" format="default" sectionFormat="of" derive dContent="Section 6.1"/>). The additional protections required to transmit
these messages over an untrusted channel (group membership authentication or these messages over an untrusted channel (group membership authentication or
AEAD encryption) are added by encoding the AuthenticatedContent as an AEAD encryption) are added by encoding the AuthenticatedContent as a
PublicMessage or PrivateMessage message, which can then be sent as an MLSMessage . PublicMessage or PrivateMessage message, which can then be sent as an MLSMessage .
Likewise, these protections are enforced (via membership verification or AEAD Likewise, these protections are enforced (via membership verification or AEAD
decryption) when decoding an PublicMessage or PrivateMessage into an decryption) when decoding a PublicMessage or PrivateMessage into an
AuthenticatedContent object.</t> AuthenticatedContent object.</t>
<t>PrivateMessage represents a signed and encrypted message, with <t indent="0" pn="section-6-3">PrivateMessage represents a signed and encr ypted message, with
protections for both the content of the message and related protections for both the content of the message and related
metadata. PublicMessage represents a message that is only signed, metadata. PublicMessage represents a message that is only signed,
and not encrypted. Applications MUST use PrivateMessage to encrypt and not encrypted. Applications <bcp14>MUST</bcp14> use PrivateMessage to encry
application messages and SHOULD use PrivateMessage to encode pt
handshake messages, but MAY transmit handshake messages encoded application messages and <bcp14>SHOULD</bcp14> use PrivateMessage to encode
handshake messages, but they <bcp14>MAY</bcp14> transmit handshake messages enco
ded
as PublicMessage objects in cases where it is necessary for the as PublicMessage objects in cases where it is necessary for the
Delivery Service to examine such messages.</t> Delivery Service to examine such messages.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-6-4">
enum { enum {
reserved(0), reserved(0),
mls10(1), mls10(1),
(65535) (65535)
} ProtocolVersion; } ProtocolVersion;
enum { enum {
reserved(0), reserved(0),
application(1), application(1),
proposal(2), proposal(2),
skipping to change at line 1969 skipping to change at line 2150
case member: case member:
uint32 leaf_index; uint32 leaf_index;
case external: case external:
uint32 sender_index; uint32 sender_index;
case new_member_commit: case new_member_commit:
case new_member_proposal: case new_member_proposal:
struct{}; struct{};
}; };
} Sender; } Sender;
// See IANA registry for registered values // See the "MLS Wire Formats" IANA registry for values
uint16 WireFormat; uint16 WireFormat;
struct { struct {
opaque group_id<V&gt;; opaque group_id<V&gt;;
uint64 epoch; uint64 epoch;
Sender sender; Sender sender;
opaque authenticated_data<V&gt;; opaque authenticated_data<V&gt;;
ContentType content_type; ContentType content_type;
select (FramedContent.content_type) { select (FramedContent.content_type) {
case application: case application:
opaque application_data<V&gt;; opaque application_data<V&gt;;
case proposal: case proposal:
Proposal proposal; Proposal proposal;
case commit: case commit:
Commit commit; Commit commit;
}; };
} FramedContent; } FramedContent;
struct { struct {
ProtocolVersion version = mls10; ProtocolVersion version = mls10;
WireFormat wire_format; WireFormat wire_format;
skipping to change at line 2005 skipping to change at line 2186
case mls_private_message: case mls_private_message:
PrivateMessage private_message; PrivateMessage private_message;
case mls_welcome: case mls_welcome:
Welcome welcome; Welcome welcome;
case mls_group_info: case mls_group_info:
GroupInfo group_info; GroupInfo group_info;
case mls_key_package: case mls_key_package:
KeyPackage key_package; KeyPackage key_package;
}; };
} MLSMessage; } MLSMessage;
]]></sourcecode> </sourcecode>
<t>Messages from senders that aren't in the group are sent as PublicMessag <t indent="0" pn="section-6-5">Messages from senders that aren't in the gr
e. See oup are sent as PublicMessage. See
<xref target="external-proposals"/> and <xref target="joining-via-external-commi Sections <xref format="counter" target="external-proposals" sectionFormat="of" d
ts"/> for more details.</t> erivedContent="12.1.8"/> and <xref format="counter" target="joining-via-external
<t>The following structure is used to fully describe the data transmitted -commits" sectionFormat="of" derivedContent="12.4.3.2"/> for more details.</t>
in <t indent="0" pn="section-6-6">The following structure is used to fully de
scribe the data transmitted in
plaintexts or ciphertexts.</t> plaintexts or ciphertexts.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-6-7">
struct { struct {
WireFormat wire_format; WireFormat wire_format;
FramedContent content; FramedContent content;
FramedContentAuthData auth; FramedContentAuthData auth;
} AuthenticatedContent; } AuthenticatedContent;
]]></sourcecode> </sourcecode>
<t>The following figure illustrates how the various structures described i <t indent="0" pn="section-6-8">The following figure illustrates how the va
n this rious structures described in this
section relate to each other, and the high-level operations used to produce and section relate to each other, and the high-level operations used to produce and
consume them:</t> consume them:</t>
<figure> <figure align="left" suppress-title="false" pn="figure-12">
<name>Relationships among MLS objects</name> <name slugifiedName="name-relationships-among-mls-obj">Relationships amo
<artset> ng MLS Objects</name>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 <artset pn="section-6-9.1">
.1" height="512" width="728" viewBox="0 0 728 512" class="diagram" text-anchor=" <artwork type="svg" align="left" pn="section-6-9.1.1">
middle" font-family="monospace" font-size="13px"> <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-family=
<path d="M 32,416 L 32,448" fill="none" stroke="black"/> "monospace" font-size="13px" height="480" text-anchor="middle" version="1.1" vie
<path d="M 120,416 L 120,448" fill="none" stroke="black"/> wBox="0 0 520 480" width="520">
<path d="M 208,416 L 208,448" fill="none" stroke="black"/> <path d="M 64,48 L 64,64" fill="none" stroke="black"/>
<path d="M 248,448 L 248,480" fill="none" stroke="black"/> <path d="M 88,144 L 88,176" fill="none" stroke="black"/>
<path d="M 272,48 L 272,64" fill="none" stroke="black"/> <path d="M 88,208 L 88,224" fill="none" stroke="black"/>
<path d="M 296,160 L 296,192" fill="none" stroke="black"/> <path d="M 112,304 L 112,336" fill="none" stroke="black"/>
<path d="M 296,224 L 296,240" fill="none" stroke="black"/> <path d="M 112,368 L 112,416" fill="none" stroke="black"/>
<path d="M 320,352 L 320,384" fill="none" stroke="black"/> <path d="M 160,128 L 160,144" fill="none" stroke="black"/>
<path d="M 320,416 L 320,448" fill="none" stroke="black"/> <path d="M 160,224 L 160,256" fill="none" stroke="black"/>
<path d="M 368,128 L 368,160" fill="none" stroke="black"/> <path d="M 184,48 L 184,96" fill="none" stroke="black"/>
<path d="M 368,240 L 368,272" fill="none" stroke="black"/> <path d="M 184,128 L 184,256" fill="none" stroke="black"/>
<path d="M 392,48 L 392,96" fill="none" stroke="black"/> <path d="M 184,288 L 184,304" fill="none" stroke="black"/>
<path d="M 392,128 L 392,272" fill="none" stroke="black"/> <path d="M 256,304 L 256,336" fill="none" stroke="black"/>
<path d="M 392,304 L 392,352" fill="none" stroke="black"/> <path d="M 256,368 L 256,448" fill="none" stroke="black"/>
<path d="M 464,352 L 464,384" fill="none" stroke="black"/> <path d="M 304,48 L 304,64" fill="none" stroke="black"/>
<path d="M 464,416 L 464,448" fill="none" stroke="black"/> <path d="M 304,400 L 304,416" fill="none" stroke="black"/>
<path d="M 512,48 L 512,64" fill="none" stroke="black"/> <path d="M 336,144 L 336,240" fill="none" stroke="black"/>
<path d="M 544,144 L 544,256" fill="none" stroke="black"/> <path d="M 336,304 L 336,336" fill="none" stroke="black"/>
<path d="M 544,320 L 544,384" fill="none" stroke="black"/> <path d="M 392,400 L 392,416" fill="none" stroke="black"/>
<path d="M 272,64 L 512,64" fill="none" stroke="black"/> <path d="M 480,400 L 480,416" fill="none" stroke="black"/>
<path d="M 296,160 L 368,160" fill="none" stroke="black"/> <path d="M 64,64 L 304,64" fill="none" stroke="black"/>
<path d="M 544,192 L 560,192" fill="none" stroke="black"/> <path d="M 88,144 L 160,144" fill="none" stroke="black"/>
<path d="M 296,240 L 368,240" fill="none" stroke="black"/> <path d="M 336,176 L 352,176" fill="none" stroke="black"/>
<path d="M 320,352 L 464,352" fill="none" stroke="black"/> <path d="M 88,224 L 160,224" fill="none" stroke="black"/>
<path d="M 544,352 L 560,352" fill="none" stroke="black"/> <path d="M 112,304 L 256,304" fill="none" stroke="black"/>
<path d="M 32,448 L 464,448" fill="none" stroke="black"/> <path d="M 336,320 L 352,320" fill="none" stroke="black"/>
<path d="M 528,128 C 536.83064,128 544,135.16936 544,144" fill="no <path d="M 112,416 L 480,416" fill="none" stroke="black"/>
ne" stroke="black"/> <path d="M 320,128 C 328.83064,128 336,135.16936 336,144" fill="no
<path d="M 528,272 C 536.83064,272 544,264.83064 544,256" fill="no ne" stroke="black"/>
ne" stroke="black"/> <path d="M 320,256 C 328.83064,256 336,248.83064 336,240" fill="no
<path d="M 528,304 C 536.83064,304 544,311.16936 544,320" fill="no ne" stroke="black"/>
ne" stroke="black"/> <path d="M 320,288 C 328.83064,288 336,295.16936 336,304" fill="no
<path d="M 528,400 C 536.83064,400 544,392.83064 544,384" fill="no ne" stroke="black"/>
ne" stroke="black"/> <path d="M 320,352 C 328.83064,352 336,344.83064 336,336" fill="no
<polygon class="arrowhead" points="472,384 460,378.4 460,389.6" fi ne" stroke="black"/>
ll="black" transform="rotate(90,464,384)"/> <polygon class="arrowhead" fill="black" points="264,448 252,442.4
<polygon class="arrowhead" points="400,272 388,266.4 388,277.6" fi 252,453.6" transform="rotate(90,256,448)"/>
ll="black" transform="rotate(90,392,272)"/> <polygon class="arrowhead" fill="black" points="264,336 252,330.4
<polygon class="arrowhead" points="400,96 388,90.4 388,101.6" fill 252,341.6" transform="rotate(90,256,336)"/>
="black" transform="rotate(90,392,96)"/> <polygon class="arrowhead" fill="black" points="192,256 180,250.4
<polygon class="arrowhead" points="376,272 364,266.4 364,277.6" fi 180,261.6" transform="rotate(90,184,256)"/>
ll="black" transform="rotate(90,368,272)"/> <polygon class="arrowhead" fill="black" points="192,96 180,90.4 18
<polygon class="arrowhead" points="328,384 316,378.4 316,389.6" fi 0,101.6" transform="rotate(90,184,96)"/>
ll="black" transform="rotate(90,320,384)"/> <polygon class="arrowhead" fill="black" points="168,256 156,250.4
<polygon class="arrowhead" points="304,192 292,186.4 292,197.6" fi 156,261.6" transform="rotate(90,160,256)"/>
ll="black" transform="rotate(90,296,192)"/> <polygon class="arrowhead" fill="black" points="120,336 108,330.4
<polygon class="arrowhead" points="256,480 244,474.4 244,485.6" fi 108,341.6" transform="rotate(90,112,336)"/>
ll="black" transform="rotate(90,248,480)"/> <polygon class="arrowhead" fill="black" points="96,176 84,170.4 84
,181.6" transform="rotate(90,88,176)"/>
<g class="text"> <g class="text">
<text x="276" y="36">Proposal</text> <text x="68" y="36">Proposal</text>
<text x="396" y="36">Commit</text> <text x="188" y="36">Commit</text>
<text x="504" y="36">Application</text> <text x="296" y="36">Application</text>
<text x="572" y="36">Data</text> <text x="364" y="36">Data</text>
<text x="384" y="116">FramedContent</text> <text x="176" y="116">FramedContent</text>
<text x="612" y="196">Asymmetric</text> <text x="404" y="180">Asymmetric</text>
<text x="296" y="212">FramedContentAuthData</text> <text x="88" y="196">FramedContentAuthData</text>
<text x="588" y="212">Sign</text> <text x="380" y="196">Sign</text>
<text x="616" y="212">/</text> <text x="408" y="196">/</text>
<text x="652" y="212">Verify</text> <text x="444" y="196">Verify</text>
<text x="396" y="292">AuthenticatedContent</text> <text x="188" y="276">AuthenticatedContent</text>
<text x="608" y="356">Symmetric</text> <text x="400" y="324">Symmetric</text>
<text x="600" y="372">Protect</text> <text x="392" y="340">Protect</text>
<text x="640" y="372">/</text> <text x="432" y="340">/</text>
<text x="688" y="372">Unprotect</text> <text x="480" y="340">Unprotect</text>
<text x="32" y="404">Welcome</text> <text x="112" y="356">PublicMessage</text>
<text x="116" y="404">KeyPackage</text> <text x="252" y="356">PrivateMessage</text>
<text x="208" y="404">GroupInfo</text> <text x="304" y="388">Welcome</text>
<text x="320" y="404">PublicMessage</text> <text x="388" y="388">KeyPackage</text>
<text x="460" y="404">PrivateMessage</text> <text x="480" y="388">GroupInfo</text>
<text x="252" y="500">MLSMessage</text> <text x="260" y="468">MLSMessage</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-6-9.1.2">
Proposal Commit Application Data Proposal Commit Application Data
| | | | | |
+--------------+--------------+ +--------------+--------------+
| |
V V
FramedContent FramedContent
| | -. | | -.
| | | +--------+ | |
+--------+ | | | | |
| | | V | +-- Asymmetric
V | +-- Asymmetri FramedContentAuthData | | Sign / Verify
c | | |
FramedContentAuthData | | Sign / Ve +--------+ | |
rify | | |
| | | V V -'
+--------+ | | AuthenticatedContent
| | | | -.
V V -' +--------+--------+ |
AuthenticatedContent | | +-- Symmetric
| -. V V | Protect / Unprotect
| | PublicMessage PrivateMessage -'
| | | |
+--------+--------+ +-- Symmetric | | Welcome KeyPackage GroupInfo
| | | Protect / | | | | |
Unprotect +-----------------+-----+----------+----------+
V V | |
Welcome KeyPackage GroupInfo PublicMessage PrivateMessage -' V
| | | | | MLSMessage
| | | | | </artwork>
+----------+----------+----+--------+-----------------+
|
V
MLSMessage
]]></artwork>
</artset> </artset>
</figure> </figure>
<section anchor="content-authentication"> <section anchor="content-authentication" numbered="true" removeInRFC="fals
<name>Content Authentication</name> e" toc="include" pn="section-6.1">
<t>FramedContent is authenticated using the FramedContentAuthData struct <name slugifiedName="name-content-authentication">Content Authentication
ure.</t> </name>
<sourcecode type="tls"><![CDATA[ <t indent="0" pn="section-6.1-1">FramedContent is authenticated using th
e FramedContentAuthData structure.</t>
<sourcecode type="tls-presentation" markers="false" pn="section-6.1-2">
struct { struct {
ProtocolVersion version = mls10; ProtocolVersion version = mls10;
WireFormat wire_format; WireFormat wire_format;
FramedContent content; FramedContent content;
select (FramedContentTBS.content.sender.sender_type) { select (FramedContentTBS.content.sender.sender_type) {
case member: case member:
case new_member_commit: case new_member_commit:
GroupContext context; GroupContext context;
case external: case external:
case new_member_proposal: case new_member_proposal:
struct{}; struct{};
}; };
} FramedContentTBS; } FramedContentTBS;
opaque MAC<V&gt;; opaque MAC<V&gt;;
struct { struct {
/* SignWithLabel(., "FramedContentTBS", FramedContentTBS) */ /* SignWithLabel(., "FramedContentTBS", FramedContentTBS) */
opaque signature<V&gt;; opaque signature<V&gt;;
select (FramedContent.content_type) { select (FramedContent.content_type) {
case commit: case commit:
/* /*
MAC(confirmation_key, MAC(confirmation_key,
GroupContext.confirmed_transcript_hash) GroupContext.confirmed_transcript_hash)
*/ */
MAC confirmation_tag; MAC confirmation_tag;
case application: case application:
case proposal: case proposal:
struct{}; struct{};
}; };
} FramedContentAuthData; } FramedContentAuthData;
]]></sourcecode> </sourcecode>
<t>The signature is computed using <tt>SignWithLabel</tt> with label <t indent="0" pn="section-6.1-3">The signature is computed using <tt>Sig
nWithLabel</tt> with label
<tt>"FramedContentTBS"</tt> and with a content that covers the message content a nd <tt>"FramedContentTBS"</tt> and with a content that covers the message content a nd
the wire format that will be used for this message. If the sender's the wire format that will be used for this message. If the sender's
<tt>sender_type</tt> is <tt>member</tt>, the content also covers the GroupContex t for the <tt>sender_type</tt> is <tt>member</tt>, the content also covers the GroupContex t for the
current epoch so that signatures are specific to a given group and epoch.</t> current epoch so that signatures are specific to a given group and epoch.</t>
<t>The sender MUST use the private key corresponding to the following si gnature key <t indent="0" pn="section-6.1-4">The sender <bcp14>MUST</bcp14> use the private key corresponding to the following signature key
depending on the sender's <tt>sender_type</tt>:</t> depending on the sender's <tt>sender_type</tt>:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6
<li> .1-5">
<li pn="section-6.1-5.1">
<tt>member</tt>: The signature key contained in the LeafNode at the index <tt>member</tt>: The signature key contained in the LeafNode at the index
indicated by <tt>leaf_index</tt> in the ratchet tree.</li> indicated by <tt>leaf_index</tt> in the ratchet tree.</li>
<li> <li pn="section-6.1-5.2">
<tt>external</tt>: The signature key at the index <tt>external</tt>: The signature key at the index
indicated by <tt>sender_index</tt> in the <tt>external_senders</tt> group contex t indicated by <tt>sender_index</tt> in the <tt>external_senders</tt> group contex t
extension (see <xref target="external-senders-extension"/>). The extension (see <xref target="external-senders-extension" format="default" sectio
<tt>content_type</tt> of the message MUST be <tt>proposal</tt> and the <tt>propo nFormat="of" derivedContent="Section 12.1.8.1"/>). The
sal_type</tt> <tt>content_type</tt> of the message <bcp14>MUST</bcp14> be <tt>proposal</tt> an
MUST be a value that is allowed for external senders.</li> d the <tt>proposal_type</tt> <bcp14>MUST</bcp14> be a value that is allowed for
<li> external senders.</li>
<li pn="section-6.1-5.3">
<tt>new_member_commit</tt>: The signature key in the LeafNode in <tt>new_member_commit</tt>: The signature key in the LeafNode in
the Commit's path (see <xref target="joining-via-external-commits"/>). The the Commit's path (see <xref target="joining-via-external-commits" format="def
<tt>content_type</tt> of the message MUST be <tt>commit</tt>.</li> ault" sectionFormat="of" derivedContent="Section 12.4.3.2"/>). The
<li> <tt>content_type</tt> of the message <bcp14>MUST</bcp14> be <tt>commit</tt>.</
li>
<li pn="section-6.1-5.4">
<tt>new_member_proposal</tt>: The signature key in the LeafNode in <tt>new_member_proposal</tt>: The signature key in the LeafNode in
the KeyPackage embedded in an External Add Proposal. The the KeyPackage embedded in an external Add proposal. The
<tt>content_type</tt> of the message MUST be <tt>proposal</tt> and the <tt>content_type</tt> of the message <bcp14>MUST</bcp14> be <tt>proposal</tt>
<tt>proposal_type</tt> of the Proposal MUST be <tt>add</tt>.</li> and the
<tt>proposal_type</tt> of the Proposal <bcp14>MUST</bcp14> be <tt>add</tt>.</l
i>
</ul> </ul>
<t>Recipients of an MLSMessage MUST verify the signature with the key de pending on <t indent="0" pn="section-6.1-6">Recipients of an MLSMessage <bcp14>MUST </bcp14> verify the signature with the key depending on
the <tt>sender_type</tt> of the sender as described above.</t> the <tt>sender_type</tt> of the sender as described above.</t>
<t>The confirmation tag value confirms that the members of the group hav e arrived <t indent="0" pn="section-6.1-7">The confirmation tag value confirms tha t the members of the group have arrived
at the same state of the group. A FramedContentAuthData is said to be valid when both at the same state of the group. A FramedContentAuthData is said to be valid when both
the <tt>signature</tt> and <tt>confirmation_tag</tt> fields are valid.</t> the <tt>signature</tt> and <tt>confirmation_tag</tt> fields are valid.</t>
</section> </section>
<section anchor="encoding-and-decoding-a-public-message"> <section anchor="encoding-and-decoding-a-public-message" numbered="true" r
<name>Encoding and Decoding a Public Message</name> emoveInRFC="false" toc="include" pn="section-6.2">
<t>Messages that are authenticated but not encrypted are encoded using t <name slugifiedName="name-encoding-and-decoding-a-pub">Encoding and Deco
he PublicMessage structure.</t> ding a Public Message</name>
<sourcecode type="tls"><![CDATA[ <t indent="0" pn="section-6.2-1">Messages that are authenticated but not
encrypted are encoded using the PublicMessage structure.</t>
<sourcecode type="tls-presentation" markers="false" pn="section-6.2-2">
struct { struct {
FramedContent content; FramedContent content;
FramedContentAuthData auth; FramedContentAuthData auth;
select (PublicMessage.content.sender.sender_type) { select (PublicMessage.content.sender.sender_type) {
case member: case member:
MAC membership_tag; MAC membership_tag;
case external: case external:
case new_member_commit: case new_member_commit:
case new_member_proposal: case new_member_proposal:
struct{}; struct{};
}; };
} PublicMessage; } PublicMessage;
]]></sourcecode> </sourcecode>
<t>The <tt>membership_tag</tt> field in the PublicMessage object authent <t indent="0" pn="section-6.2-3">The <tt>membership_tag</tt> field in th
icates the sender's e PublicMessage object authenticates the sender's
membership in the group. For messages sent by members, it MUST be set to the membership in the group. For messages sent by members, it <bcp14>MUST</bcp14> be
set to the
following value:</t> following value:</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-6.2-4">
struct { struct {
FramedContentTBS content_tbs; FramedContentTBS content_tbs;
FramedContentAuthData auth; FramedContentAuthData auth;
} AuthenticatedContentTBM; } AuthenticatedContentTBM;
]]></sourcecode> </sourcecode>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-6.2-5">
membership_tag = MAC(membership_key, AuthenticatedContentTBM) membership_tag = MAC(membership_key, AuthenticatedContentTBM)
]]></sourcecode> </sourcecode>
<t>When decoding an PublicMessage into an AuthenticatedContent, <t indent="0" pn="section-6.2-6">When decoding a PublicMessage into an A
the application MUST check <tt>membership_tag</tt> and MUST check that the uthenticatedContent,
the application <bcp14>MUST</bcp14> check <tt>membership_tag</tt> and <bcp14>MUS
T</bcp14> check that the
FramedContentAuthData is valid.</t> FramedContentAuthData is valid.</t>
</section> </section>
<section anchor="encoding-and-decoding-a-private-message"> <section anchor="encoding-and-decoding-a-private-message" numbered="true"
<name>Encoding and Decoding a Private Message</name> removeInRFC="false" toc="include" pn="section-6.3">
<t>Authenticated and encrypted messages are encoded using the PrivateMes <name slugifiedName="name-encoding-and-decoding-a-pri">Encoding and Deco
sage structure.</t> ding a Private Message</name>
<sourcecode type="tls"><![CDATA[ <t indent="0" pn="section-6.3-1">Authenticated and encrypted messages ar
e encoded using the PrivateMessage structure.</t>
<sourcecode type="tls-presentation" markers="false" pn="section-6.3-2">
struct { struct {
opaque group_id<V&gt;; opaque group_id<V&gt;;
uint64 epoch; uint64 epoch;
ContentType content_type; ContentType content_type;
opaque authenticated_data<V>; opaque authenticated_data&lt;V&gt;;
opaque encrypted_sender_data<V>; opaque encrypted_sender_data&lt;V&gt;;
opaque ciphertext<V>; opaque ciphertext&lt;V&gt;;
} PrivateMessage; } PrivateMessage;
]]></sourcecode> </sourcecode>
<t><tt>encrypted_sender_data</tt> and <tt>ciphertext</tt> are encrypted <t indent="0" pn="section-6.3-3"><tt>encrypted_sender_data</tt> and <tt>
using the AEAD function ciphertext</tt> are encrypted using the AEAD function
specified by the ciphersuite in use, using as input the structures SenderData specified by the cipher suite in use, using the SenderData
and PrivateMessageContent.</t> and PrivateMessageContent structures as input.</t>
<section anchor="content-encryption"> <section anchor="content-encryption" numbered="true" removeInRFC="false"
<name>Content Encryption</name> toc="include" pn="section-6.3.1">
<t>Content to be encrypted is encoded in a PrivateMessageContent struc <name slugifiedName="name-content-encryption">Content Encryption</name
ture.</t> >
<sourcecode type="tls"><![CDATA[ <t indent="0" pn="section-6.3.1-1">Content to be encrypted is encoded
in a PrivateMessageContent structure.</t>
<sourcecode type="tls-presentation" markers="false" pn="section-6.3.1-
2">
struct { struct {
select (PrivateMessage.content_type) { select (PrivateMessage.content_type) {
case application: case application:
opaque application_data<V&gt;; opaque application_data<V&gt;;
case proposal: case proposal:
Proposal proposal; Proposal proposal;
case commit: case commit:
Commit commit; Commit commit;
}; };
FramedContentAuthData auth; FramedContentAuthData auth;
opaque padding[length_of_padding]; opaque padding[length_of_padding];
} PrivateMessageContent; } PrivateMessageContent;
]]></sourcecode> </sourcecode>
<t>The <tt>padding</tt> field is set by the sender, by first encoding <t indent="0" pn="section-6.3.1-3">The <tt>padding</tt> field is set b
the content (via the y the sender, by first encoding the content (via the
<tt>select</tt>) and the <tt>auth</tt> field, then appending the chosen number o <tt>select</tt>) and the <tt>auth</tt> field, and then appending the chosen numb
f zero bytes. er of zero bytes.
A receiver identifies the padding field in a plaintext decoded from A receiver identifies the padding field in a plaintext decoded from
<tt>PrivateMessage.ciphertext</tt> by first decoding the content and the <tt>aut h</tt> field; <tt>PrivateMessage.ciphertext</tt> by first decoding the content and the <tt>aut h</tt> field;
then the <tt>padding</tt> field comprises any remaining octets of plaintext. Th e then the <tt>padding</tt> field comprises any remaining octets of plaintext. Th e
<tt>padding</tt> field MUST be filled with all zero bytes. A receiver MUST veri fy that <tt>padding</tt> field <bcp14>MUST</bcp14> be filled with all zero bytes. A rec eiver <bcp14>MUST</bcp14> verify that
there are no non-zero bytes in the <tt>padding</tt> field, and if this check fai ls, the there are no non-zero bytes in the <tt>padding</tt> field, and if this check fai ls, the
enclosing PrivateMessage MUST be rejected as malformed. This check ensures that enclosing PrivateMessage <bcp14>MUST</bcp14> be rejected as malformed. This che ck ensures that
the padding process is deterministic, so that, for example, padding cannot be the padding process is deterministic, so that, for example, padding cannot be
used as a covert channel.</t> used as a covert channel.</t>
<t>In the MLS key schedule, the sender creates two distinct key ratche ts for <t indent="0" pn="section-6.3.1-4">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 handshake and application messages for each member of the group. When encrypting
a message, the sender looks at the ratchets it derived for its own member and a message, the sender looks at the ratchets it derived for its own member and
chooses an unused generation from either the handshake or application ratchet chooses an unused generation from either the handshake ratchet or the applicatio n ratchet,
depending on the content type of the message. This generation of the ratchet is depending on the content type of the message. This generation of the ratchet is
used to derive a provisional nonce and key.</t> used to derive a provisional nonce and key.</t>
<t>Before use in the encryption operation, the nonce is XORed with a f resh random <t indent="0" pn="section-6.3.1-5">Before use in the encryption operat ion, the nonce is XORed with a fresh random
value to guard against reuse. Because the key schedule generates nonces value to guard against reuse. Because the key schedule generates nonces
deterministically, a client MUST keep persistent state as to where in the key deterministically, a client <bcp14>MUST</bcp14> keep persistent state as to wher e in the key
schedule it is; if this persistent state is lost or corrupted, a client might schedule it is; if this persistent state is lost or corrupted, a client might
reuse a generation that has already been used, causing reuse of a key/nonce pair .</t> reuse a generation that has already been used, causing reuse of a key/nonce pair .</t>
<t>To avoid this situation, the sender of a message MUST generate a fr esh random <t indent="0" pn="section-6.3.1-6">To avoid this situation, the sender of a message <bcp14>MUST</bcp14> generate a fresh random
four-byte "reuse guard" value and XOR it with the first four bytes of the nonce four-byte "reuse guard" value and XOR it with the first four bytes of the nonce
from the key schedule before using the nonce for encryption. The sender MUST from the key schedule before using the nonce for encryption. The sender <bcp14> MUST</bcp14>
include the reuse guard in the <tt>reuse_guard</tt> field of the sender data obj ect, so include the reuse guard in the <tt>reuse_guard</tt> field of the sender data obj ect, so
that the recipient of the message can use it to compute the nonce to be used for that the recipient of the message can use it to compute the nonce to be used for
decryption.</t> decryption.</t>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-6.3.1-7">
+-+-+-+-+---------...---+ +-+-+-+-+---------...---+
| Key Schedule Nonce | | Key Schedule Nonce |
+-+-+-+-+---------...---+ +-+-+-+-+---------...---+
XOR XOR
+-+-+-+-+---------...---+ +-+-+-+-+---------...---+
| Guard | 0 | | Guard | 0 |
+-+-+-+-+---------...---+ +-+-+-+-+---------...---+
=== ===
+-+-+-+-+---------...---+ +-+-+-+-+---------...---+
| Encrypt/Decrypt Nonce | | Encrypt/Decrypt Nonce |
+-+-+-+-+---------...---+ +-+-+-+-+---------...---+
]]></artwork> </artwork>
<t>The Additional Authenticated Data (AAD) input to the encryption <t indent="0" pn="section-6.3.1-8">The Additional Authenticated Data (
AAD) input to the encryption
contains an object of the following form, with the values used to contains an object of the following form, with the values used to
identify the key and nonce:</t> identify the key and nonce:</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-6.3.1- 9">
struct { struct {
opaque group_id<V&gt;; opaque group_id<V&gt;;
uint64 epoch; uint64 epoch;
ContentType content_type; ContentType content_type;
opaque authenticated_data<V&gt;; opaque authenticated_data<V&gt;;
} PrivateContentAAD; } PrivateContentAAD;
]]></sourcecode> </sourcecode>
<t>When decoding a PrivateMessageContent, the application MUST check t <t indent="0" pn="section-6.3.1-10">When decoding a PrivateMessageCont
hat the ent, the application <bcp14>MUST</bcp14> check that the
FramedContentAuthData is valid.</t> FramedContentAuthData is valid.</t>
<t>It is up to the application to decide what <tt>authenticated_data</ tt> to provide and <t indent="0" pn="section-6.3.1-11">It is up to the application to dec ide what <tt>authenticated_data</tt> to provide and
how much padding to add to a given message (if any). The overall size of the how much padding to add to a given message (if any). The overall size of the
AAD and ciphertext MUST fit within the limits established for the group's AEAD AAD and ciphertext <bcp14>MUST</bcp14> fit within the limits established for the
algorithm in [!I-D.irtf-cfrg-aead-limits].</t> group's AEAD
algorithm in <xref target="I-D.irtf-cfrg-aead-limits" format="default" sectionFo
rmat="of" derivedContent="CFRG-AEAD-LIMITS"/>.</t>
</section> </section>
<section anchor="sender-data-encryption"> <section anchor="sender-data-encryption" numbered="true" removeInRFC="fa
<name>Sender Data Encryption</name> lse" toc="include" pn="section-6.3.2">
<t>The "sender data" used to look up the key for content encryption is <name slugifiedName="name-sender-data-encryption">Sender Data Encrypti
encrypted with the ciphersuite's AEAD with a key and nonce derived from both the on</name>
<t indent="0" pn="section-6.3.2-1">The "sender data" used to look up t
he key for content encryption is
encrypted with the cipher suite's AEAD with a key and nonce derived from both th
e
<tt>sender_data_secret</tt> and a sample of the encrypted content. Before being <tt>sender_data_secret</tt> and a sample of the encrypted content. Before being
encrypted, the sender data is encoded as an object of the following form:</t> encrypted, the sender data is encoded as an object of the following form:</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-6.3.2- 2">
struct { struct {
uint32 leaf_index; uint32 leaf_index;
uint32 generation; uint32 generation;
opaque reuse_guard[4]; opaque reuse_guard[4];
} SenderData; } SenderData;
]]></sourcecode> </sourcecode>
<t>When constructing a SenderData object from a Sender object, the sen <t indent="0" pn="section-6.3.2-3">When constructing a SenderData obje
der MUST verify ct from a Sender object, the sender <bcp14>MUST</bcp14> verify
Sender.sender_type is <tt>member</tt> and use Sender.leaf_index for Sender.sender_type is <tt>member</tt> and use Sender.leaf_index for
SenderData.leaf_index.</t> SenderData.leaf_index.</t>
<t>The <tt>reuse_guard</tt> field contains a fresh random value used t <t indent="0" pn="section-6.3.2-4">The <tt>reuse_guard</tt> field cont
o avoid nonce reuse ains a fresh random value used to avoid nonce reuse
in the case of state loss or corruption, as described in <xref target="content-e in the case of state loss or corruption, as described in <xref target="content-e
ncryption"/>.</t> ncryption" format="default" sectionFormat="of" derivedContent="Section 6.3.1"/>.
<t>The key and nonce provided to the AEAD are computed as the KDF of t </t>
he first <t indent="0" pn="section-6.3.2-5">The key and nonce provided to the A
EAD are computed as the KDF of the first
<tt>KDF.Nh</tt> bytes of the ciphertext generated in the previous section. If th e <tt>KDF.Nh</tt> bytes of the ciphertext generated in the previous section. If th e
length of the ciphertext is less than <tt>KDF.Nh</tt>, the whole ciphertext is u sed. length of the ciphertext is less than <tt>KDF.Nh</tt>, the whole ciphertext is u sed.
In pseudocode, the key and nonce are derived as:</t> In pseudocode, the key and nonce are derived as:</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-6.3.2-6">
ciphertext_sample = ciphertext[0..KDF.Nh-1] ciphertext_sample = ciphertext[0..KDF.Nh-1]
sender_data_key = ExpandWithLabel(sender_data_secret, "key", sender_data_key = ExpandWithLabel(sender_data_secret, "key",
ciphertext_sample, AEAD.Nk) ciphertext_sample, AEAD.Nk)
sender_data_nonce = ExpandWithLabel(sender_data_secret, "nonce", sender_data_nonce = ExpandWithLabel(sender_data_secret, "nonce",
ciphertext_sample, AEAD.Nn) ciphertext_sample, AEAD.Nn)
]]></sourcecode> </sourcecode>
<t>The Additional Authenticated Data (AAD) for the SenderData cipherte <t indent="0" pn="section-6.3.2-7">The AAD for the SenderData cipherte
xt is the xt is the
first three fields of PrivateMessage:</t> first three fields of PrivateMessage:</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-6.3.2- 8">
struct { struct {
opaque group_id<V&gt;; opaque group_id<V&gt;;
uint64 epoch; uint64 epoch;
ContentType content_type; ContentType content_type;
} SenderDataAAD; } SenderDataAAD;
]]></sourcecode> </sourcecode>
<t>When parsing a SenderData struct as part of message decryption, the <t indent="0" pn="section-6.3.2-9">When parsing a SenderData struct as
recipient part of message decryption, the recipient
MUST verify that the leaf index indicated in the <tt>leaf_index</tt> field ident <bcp14>MUST</bcp14> verify that the leaf index indicated in the <tt>leaf_index</
ifies a tt> field identifies a
non-blank node.</t> non-blank node.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="ratchet-tree-operations"> <section anchor="ratchet-tree-operations" numbered="true" removeInRFC="false
<name>Ratchet Tree Operations</name> " toc="include" pn="section-7">
<t>The ratchet tree for an epoch describes the membership of a group in th <name slugifiedName="name-ratchet-tree-operations">Ratchet Tree Operations
at epoch, </name>
providing public-key encryption (HPKE) keys that can be used to encrypt to subse <t indent="0" pn="section-7-1">The ratchet tree for an epoch describes the
ts of membership of a group in that epoch,
providing public key encryption (HPKE) keys that can be used to encrypt to subse
ts of
the group as well as information to authenticate the members. In order to the group as well as information to authenticate the members. In order to
reflect changes to the membership of the group from one epoch to the next, reflect changes to the membership of the group from one epoch to the next,
corresponding changes are made to the ratchet tree. In this section, we corresponding changes are made to the ratchet tree. In this section, we
describe the content of the tree and the required operations.</t> describe the content of the tree and the required operations.</t>
<section anchor="parent-node-contents"> <section anchor="parent-node-contents" numbered="true" removeInRFC="false"
<name>Parent Node Contents</name> toc="include" pn="section-7.1">
<t>As discussed in <xref target="ratchet-tree-nodes"/>, the nodes of a r <name slugifiedName="name-parent-node-contents">Parent Node Contents</na
atchet tree contain me>
<t indent="0" pn="section-7.1-1">As discussed in <xref target="ratchet-t
ree-nodes" format="default" sectionFormat="of" derivedContent="Section 4.1.1"/>,
the nodes of a ratchet tree contain
several types of data describing individual members (for leaf nodes) or several types of data describing individual members (for leaf nodes) or
subgroups of the group (for parent nodes). Parent nodes are simpler:</t> subgroups of the group (for parent nodes). Parent nodes are simpler:</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-7.1-2">
struct { struct {
HPKEPublicKey encryption_key; HPKEPublicKey encryption_key;
opaque parent_hash<V>; opaque parent_hash&lt;V&gt;;
uint32 unmerged_leaves<V>; uint32 unmerged_leaves&lt;V&gt;;
} ParentNode; } ParentNode;
]]></sourcecode> </sourcecode>
<t>The <tt>encryption_key</tt> field contains an HPKE public key whose p <t indent="0" pn="section-7.1-3">The <tt>encryption_key</tt> field conta
rivate key is held only ins an HPKE public key whose private key is held only
by the members at the leaves among its descendants. The <tt>parent_hash</tt> fi eld by the members at the leaves among its descendants. The <tt>parent_hash</tt> fi eld
contains a hash of this node's parent node, as described in <xref target="parent -hashes"/>. contains a hash of this node's parent node, as described in <xref target="parent -hashes" format="default" sectionFormat="of" derivedContent="Section 7.9"/>.
The <tt>unmerged_leaves</tt> field lists the leaves under this parent node that are The <tt>unmerged_leaves</tt> field lists the leaves under this parent node that are
unmerged, according to their indices among all the leaves in the tree. The unmerged, according to their indices among all the leaves in the tree. The
entries in the <tt>unmerged_leaves</tt> vector MUST be sorted in increasing orde r.</t> entries in the <tt>unmerged_leaves</tt> vector <bcp14>MUST</bcp14> be sorted in increasing order.</t>
</section> </section>
<section anchor="leaf-node-contents"> <section anchor="leaf-node-contents" numbered="true" removeInRFC="false" t
<name>Leaf Node Contents</name> oc="include" pn="section-7.2">
<t>A leaf node in the tree describes all the details of an individual cl <name slugifiedName="name-leaf-node-contents">Leaf Node Contents</name>
ient's <t indent="0" pn="section-7.2-1">A leaf node in the tree describes all t
he details of an individual client's
appearance in the group, signed by that client. It is also used in client appearance in the group, signed by that client. It is also used in client
KeyPackage objects to store the information that will be needed to add a KeyPackage objects to store the information that will be needed to add a
client to a group.</t> client to a group.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-7.2-2">
enum { enum {
reserved(0), reserved(0),
key_package(1), key_package(1),
update(2), update(2),
commit(3), commit(3),
(255) (255)
} LeafNodeSource; } LeafNodeSource;
struct { struct {
ProtocolVersion versions<V>; ProtocolVersion versions&lt;V&gt;;
CipherSuite ciphersuites<V>; CipherSuite cipher_suites&lt;V&gt;;
ExtensionType extensions<V>; ExtensionType extensions&lt;V&gt;;
ProposalType proposals<V>; ProposalType proposals&lt;V&gt;;
CredentialType credentials<V>; CredentialType credentials&lt;V&gt;;
} Capabilities; } Capabilities;
struct { struct {
uint64 not_before; uint64 not_before;
uint64 not_after; uint64 not_after;
} Lifetime; } Lifetime;
// See IANA registry for registered values // See the "MLS Extension Types" IANA registry for values
uint16 ExtensionType; uint16 ExtensionType;
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<V&gt;; opaque extension_data<V&gt;;
} Extension; } Extension;
struct { struct {
HPKEPublicKey encryption_key; HPKEPublicKey encryption_key;
SignaturePublicKey signature_key; SignaturePublicKey signature_key;
Credential credential; Credential credential;
Capabilities capabilities; Capabilities capabilities;
LeafNodeSource leaf_node_source; LeafNodeSource leaf_node_source;
select (LeafNode.leaf_node_source) { select (LeafNode.leaf_node_source) {
case key_package: case key_package:
Lifetime lifetime; Lifetime lifetime;
case update: case update:
struct{}; struct{};
case commit: case commit:
opaque parent_hash<V&gt;; opaque parent_hash<V&gt;;
}; };
Extension extensions<V&gt;; Extension extensions<V&gt;;
/* SignWithLabel(., "LeafNodeTBS", LeafNodeTBS) */ /* SignWithLabel(., "LeafNodeTBS", LeafNodeTBS) */
opaque signature<V&gt;; opaque signature<V&gt;;
} LeafNode; } LeafNode;
struct { struct {
HPKEPublicKey encryption_key; HPKEPublicKey encryption_key;
SignaturePublicKey signature_key; SignaturePublicKey signature_key;
Credential credential; Credential credential;
Capabilities capabilities; Capabilities capabilities;
LeafNodeSource leaf_node_source; LeafNodeSource leaf_node_source;
select (LeafNodeTBS.leaf_node_source) { select (LeafNodeTBS.leaf_node_source) {
case key_package: case key_package:
Lifetime lifetime; Lifetime lifetime;
case update: case update:
struct{}; struct{};
case commit: case commit:
opaque parent_hash<V&gt;; opaque parent_hash<V&gt;;
}; };
Extension extensions<V&gt;; Extension extensions<V&gt;;
select (LeafNodeTBS.leaf_node_source) { select (LeafNodeTBS.leaf_node_source) {
case key_package: case key_package:
struct{}; struct{};
case update: case update:
opaque group_id<V&gt;; opaque group_id<V&gt;;
uint32 leaf_index; uint32 leaf_index;
case commit: case commit:
opaque group_id<V&gt;; opaque group_id<V&gt;;
uint32 leaf_index; uint32 leaf_index;
}; };
} LeafNodeTBS; } LeafNodeTBS;
]]></sourcecode> </sourcecode>
<t>The <tt>encryption_key</tt> field contains an HPKE public key whose p <t indent="0" pn="section-7.2-3">The <tt>encryption_key</tt> field conta
rivate key is held only ins an HPKE public key whose private key is held only
by the member occupying this leaf (or in the case of a LeafNode in a KeyPackage by the member occupying this leaf (or in the case of a LeafNode in a KeyPackage
object, the issuer of the KeyPackage). The <tt>signature_key</tt> field contains the object, the issuer of the KeyPackage). The <tt>signature_key</tt> field contains the
member's public signing key. The <tt>credential</tt> field contains information member's public signing key. The <tt>credential</tt> field contains information
authenticating both the member's identity and the provided signing key, as authenticating both the member's identity and the provided signing key, as
described in <xref target="credentials"/>.</t> described in <xref target="credentials" format="default" sectionFormat="of" deri
<t>The <tt>capabilities</tt> field indicates what protocol versions, cip vedContent="Section 5.3"/>.</t>
hersuites, <t indent="0" pn="section-7.2-4">The <tt>capabilities</tt> field indicat
extensions, credential types, and non-default proposal types are supported by a es the protocol features that the client
client. supports, including protocol versions, cipher suites, credential types,
Proposal and extension types defined in this document are considered "default" a non-default proposal types, and non-default extension types. The following
nd thus need proposal and extension types are considered "default" and <bcp14>MUST NOT</bcp14
not be listed, while any credential types the application wishes to use MUST > be
be listed. Extensions that appear in the <tt>extensions</tt> field of a LeafNode listed:</t>
MUST be included in the <tt>extensions</tt> field of the <tt>capabilities</tt> f <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7
ield, and the .2-5">
credential type used in the LeafNode MUST be included in the <tt>credentials</tt <li pn="section-7.2-5.1">
> field <t indent="0" pn="section-7.2-5.1.1">Proposal types:
of the <tt>capabilities</tt> field. As discussed in <xref target="extensibility </t>
"/>, unknown values <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
in <tt>capabilities</tt> MUST be ignored, and the creator of a <tt>capabilities< on-7.2-5.1.2">
/tt> field <li pn="section-7.2-5.1.2.1">0x0001 - <tt>add</tt></li>
SHOULD include some random GREASE values to help ensure that other clients corre <li pn="section-7.2-5.1.2.2">0x0002 - <tt>update</tt></li>
ctly <li pn="section-7.2-5.1.2.3">0x0003 - <tt>remove</tt></li>
<li pn="section-7.2-5.1.2.4">0x0004 - <tt>psk</tt></li>
<li pn="section-7.2-5.1.2.5">0x0005 - <tt>reinit</tt></li>
<li pn="section-7.2-5.1.2.6">0x0006 - <tt>external_init</tt></li>
<li pn="section-7.2-5.1.2.7">0x0007 - <tt>group_context_extensions
</tt></li>
</ul>
</li>
<li pn="section-7.2-5.2">
<t indent="0" pn="section-7.2-5.2.1">Extension types:
</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
on-7.2-5.2.2">
<li pn="section-7.2-5.2.2.1">0x0001 - <tt>application_id</tt></li>
<li pn="section-7.2-5.2.2.2">0x0002 - <tt>ratchet_tree</tt></li>
<li pn="section-7.2-5.2.2.3">0x0003 - <tt>required_capabilities</t
t></li>
<li pn="section-7.2-5.2.2.4">0x0004 - <tt>external_pub</tt></li>
<li pn="section-7.2-5.2.2.5">0x0005 - <tt>external_senders</tt></l
i>
</ul>
</li>
</ul>
<t indent="0" pn="section-7.2-6">There are no default values for the oth
er fields of a capabilities object. The
client <bcp14>MUST</bcp14> list all values for the respective parameters that it
supports.</t>
<t indent="0" pn="section-7.2-7">The types of any non-default extensions
that appear in the <tt>extensions</tt> field of a LeafNode
<bcp14>MUST</bcp14> be included in the <tt>extensions</tt> field of the <tt>capa
bilities</tt> field, and the
credential type used in the LeafNode <bcp14>MUST</bcp14> be included in the <tt>
credentials</tt> field
of the <tt>capabilities</tt> field.</t>
<t indent="0" pn="section-7.2-8">As discussed in <xref target="extensibi
lity" format="default" sectionFormat="of" derivedContent="Section 13"/>, unknown
values
in <tt>capabilities</tt> <bcp14>MUST</bcp14> be ignored, and the creator of a <t
t>capabilities</tt> field
<bcp14>SHOULD</bcp14> include some random GREASE values to help ensure that othe
r clients correctly
ignore unknown values.</t> ignore unknown values.</t>
<t>The <tt>leaf_node_source</tt> field indicates how this LeafNode came to be added to the <t indent="0" pn="section-7.2-9">The <tt>leaf_node_source</tt> field ind icates how this LeafNode came to be added to the
tree. This signal tells other members of the group whether the leaf node is tree. This signal tells other members of the group whether the leaf node is
required to have a <tt>lifetime</tt> or <tt>parent_hash</tt>, and whether the <t t>group_id</tt> is required to have a <tt>lifetime</tt> or <tt>parent_hash</tt>, and whether the <t t>group_id</tt> is
added as context to the signature. Whether these fields can be computed by the added as context to the signature.
client represented by the LeafNode depends on when the LeafNode was created. These fields are included selectively because the client creating a LeafNode is
not always able to compute all of them.
For example, a KeyPackage is created before the client knows which group it will For example, a KeyPackage is created before the client knows which group it will
be used with, so its signature can't bind to a <tt>group_id</tt>.</t> be used with, so its signature can't bind to a <tt>group_id</tt>.</t>
<t>In the case where the leaf was added to the tree based on a pre-publi shed <t indent="0" pn="section-7.2-10">In the case where the leaf was added t o the tree based on a pre-published
KeyPackage, the <tt>lifetime</tt> field represents the times between which clien ts will KeyPackage, the <tt>lifetime</tt> field represents the times between which clien ts will
consider a LeafNode valid. These times are represented as absolute times, consider a LeafNode valid. These times are represented as absolute times,
measured in seconds since the Unix epoch (1970-01-01T00:00:00Z). Applications measured in seconds since the Unix epoch (1970-01-01T00:00:00Z). Applications
MUST define a maximum total lifetime that is acceptable for a LeafNode, and <bcp14>MUST</bcp14> define a maximum total lifetime that is acceptable for a Lea fNode, and
reject any LeafNode where the total lifetime is longer than this duration. In reject any LeafNode where the total lifetime is longer than this duration. In
order to avoid disagreements about whether a LeafNode has a valid lifetime, the order to avoid disagreements about whether a LeafNode has a valid lifetime, the
clients in a group SHOULD maintain time synchronization (e.g., using the Network clients in a group <bcp14>SHOULD</bcp14> maintain time synchronization (e.g., us
Time Protocol <xref target="RFC5905"/>).</t> ing the Network
<t>In the case where the leaf node was inserted into the tree via a Comm Time Protocol <xref target="RFC5905" format="default" sectionFormat="of" derived
it message, Content="RFC5905"/>).</t>
<t indent="0" pn="section-7.2-11">In the case where the leaf node was in
serted into the tree via a Commit message,
the <tt>parent_hash</tt> field contains the parent hash for this leaf node (see the <tt>parent_hash</tt> field contains the parent hash for this leaf node (see
<xref target="parent-hashes"/>).</t> <xref target="parent-hashes" format="default" sectionFormat="of" derivedContent=
<t>The LeafNodeTBS structure covers the fields above the signature in th "Section 7.9"/>).</t>
e LeafNode. <t indent="0" pn="section-7.2-12">The LeafNodeTBS structure covers the f
ields above the signature in the LeafNode.
In addition, when the leaf node was created in the context of a group (the In addition, when the leaf node was created in the context of a group (the
update and commit cases), the group ID of the group is added as context to the <tt>update</tt> and <tt>commit</tt> cases), the group ID of the group is added a s context to the
signature.</t> signature.</t>
<t>LeafNode objects stored in the group's ratchet tree <t indent="0" pn="section-7.2-13">LeafNode objects stored in the group's ratchet tree
are updated according to the evolution of the tree. Each modification of are updated according to the evolution of the tree. Each modification of
LeafNode content MUST be reflected by a change in its signature. This allows oth er LeafNode content <bcp14>MUST</bcp14> be reflected by a change in its signature. This allows other
members to verify the validity of the LeafNode at any time, particularly in the members to verify the validity of the LeafNode at any time, particularly in the
case of a newcomer joining the group.</t> case of a newcomer joining the group.</t>
</section> </section>
<section anchor="leaf-node-validation"> <section anchor="leaf-node-validation" numbered="true" removeInRFC="false"
<name>Leaf Node Validation</name> toc="include" pn="section-7.3">
<t>The validity of a LeafNode needs to be verified at a few stages:</t> <name slugifiedName="name-leaf-node-validation">Leaf Node Validation</na
<ul spacing="normal"> me>
<li>When a LeafNode is downloaded in a KeyPackage, before it is used <t indent="0" pn="section-7.3-1">The validity of a LeafNode needs to be
verified at the following stages:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7
.3-2">
<li pn="section-7.3-2.1">When a LeafNode is downloaded in a KeyPackage
, before it is used
to add the client to the group</li> to add the client to the group</li>
<li>When a LeafNode is received by a group member in an Add, Update, o r Commit <li pn="section-7.3-2.2">When a LeafNode is received by a group member in an Add, Update, or Commit
message</li> message</li>
<li>When a client validates a ratchet tree, e.g., when joining a group <li pn="section-7.3-2.3">When a client validates a ratchet tree, e.g.,
or after when joining a group or after
processing a commit</li> processing a Commit</li>
</ul> </ul>
<t>The client verifies the validity of a LeafNode using the following st <t indent="0" pn="section-7.3-3">The client verifies the validity of a L
eps:</t> eafNode using the following steps:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7
<li>Verify that the credential in the LeafNode is valid as described i .3-4">
n <li pn="section-7.3-4.1">Verify that the credential in the LeafNode is
<xref target="credential-validation"/>.</li> valid, as described in
<li>Verify that the signature on the LeafNode is valid using <tt>signa <xref target="credential-validation" format="default" sectionFormat="of" derived
ture_key</tt>.</li> Content="Section 5.3.1"/>.</li>
<li>Verify that the LeafNode is compatible with the group's parameters <li pn="section-7.3-4.2">Verify that the signature on the LeafNode is
. If the valid using <tt>signature_key</tt>.</li>
<li pn="section-7.3-4.3">Verify that the LeafNode is compatible with t
he group's parameters. If the
GroupContext has a <tt>required_capabilities</tt> extension, then the required GroupContext has a <tt>required_capabilities</tt> extension, then the required
extensions, proposals, and credential types MUST be listed in the LeafNode's extensions, proposals, and credential types <bcp14>MUST</bcp14> be listed in the LeafNode's
<tt>capabilities</tt> field.</li> <tt>capabilities</tt> field.</li>
<li>Verify that the credential type is supported by all members of the group, as <li pn="section-7.3-4.4">Verify that the credential type is supported by all members of the group, as
specified by the <tt>capabilities</tt> field of each member's LeafNode, and that the specified by the <tt>capabilities</tt> field of each member's LeafNode, and that the
<tt>capabilities</tt> field of this LeafNode indicates support for all the crede ntial <tt>capabilities</tt> field of this LeafNode indicates support for all the crede ntial
types currently in use by other members.</li> types currently in use by other members.</li>
<li> <li pn="section-7.3-4.5">
<t>Verify the <tt>lifetime</tt> field: <t indent="0" pn="section-7.3-4.5.1">Verify the <tt>lifetime</tt> fi
eld:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>If the LeafNode appears in a message being sent by the client, on-7.3-4.5.2">
e.g., a <li pn="section-7.3-4.5.2.1">If the LeafNode appears in a message
proposal or a commit, then the client MUST verify that the current time is withi being sent by the client, e.g., a
n Proposal or a Commit, then the client <bcp14>MUST</bcp14> verify that the curren
t time is within
the range of the <tt>lifetime</tt> field.</li> the range of the <tt>lifetime</tt> field.</li>
<li>If instead the LeafNode appears in a message being received by <li pn="section-7.3-4.5.2.2">If instead the LeafNode appears in a
the client, e.g., message being received by the client, e.g.,
a proposal, a commit, or a ratchet tree of the group the client is joining, it i a Proposal, a Commit, or a ratchet tree of the group the client is joining, it i
s s
RECOMMENDED that the client verifies that the current time is within the range <bcp14>RECOMMENDED</bcp14> that the client verifies that the current time is wit
hin the range
of the <tt>lifetime</tt> field. (This check is not mandatory because the LeafNo de of the <tt>lifetime</tt> field. (This check is not mandatory because the LeafNo de
might have expired in the time between when the message was sent and when it might have expired in the time between when the message was sent and when it
was received.)</li> was received.)</li>
</ul> </ul>
</li> </li>
<li>Verify that the extensions in the LeafNode are supported by checki ng that the <li pn="section-7.3-4.6">Verify that the extensions in the LeafNode ar e supported by checking that the
ID for each extension in the <tt>extensions</tt> field is listed in the ID for each extension in the <tt>extensions</tt> field is listed in the
<tt>capabilities.extensions</tt> field of the LeafNode.</li> <tt>capabilities.extensions</tt> field of the LeafNode.</li>
<li> <li pn="section-7.3-4.7">
<t>Verify the <tt>leaf_node_source</tt> field: <t indent="0" pn="section-7.3-4.7.1">Verify the <tt>leaf_node_source
</tt> field:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>If the LeafNode appears in a KeyPackage, verify that <tt>leaf_ on-7.3-4.7.2">
node_source</tt> is <li pn="section-7.3-4.7.2.1">If the LeafNode appears in a KeyPacka
ge, verify that <tt>leaf_node_source</tt> is
set to <tt>key_package</tt>.</li> set to <tt>key_package</tt>.</li>
<li>If the LeafNode appears in an Update proposal, verify that <tt >leaf_node_source</tt> <li pn="section-7.3-4.7.2.2">If the LeafNode appears in an Update proposal, verify that <tt>leaf_node_source</tt>
is set to <tt>update</tt> and that <tt>encryption_key</tt> represents a differen t public is set to <tt>update</tt> and that <tt>encryption_key</tt> represents a differen t public
key than the <tt>encryption_key</tt> in the leaf node being replaced by the Upda te key than the <tt>encryption_key</tt> in the leaf node being replaced by the Upda te
proposal.</li> proposal.</li>
<li>If the LeafNode appears in the <tt>leaf_node</tt> value of the UpdatePath in <li pn="section-7.3-4.7.2.3">If the LeafNode appears in the <tt>le af_node</tt> value of the UpdatePath in
a Commit, verify that <tt>leaf_node_source</tt> is set to <tt>commit</tt>.</li> a Commit, verify that <tt>leaf_node_source</tt> is set to <tt>commit</tt>.</li>
</ul> </ul>
</li> </li>
<li> <li pn="section-7.3-4.8">
<t>Verify that the following fields are unique among the members of <t indent="0" pn="section-7.3-4.8.1">Verify that the following field
the group: s are unique among the members of the group:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li> on-7.3-4.8.2">
<tt>signature_key</tt></li> <li pn="section-7.3-4.8.2.1">
<li> <tt>signature_key</tt>
<tt>encryption_key</tt></li> </li>
<li pn="section-7.3-4.8.2.2">
<tt>encryption_key</tt>
</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="ratchet-tree-evolution"> <section anchor="ratchet-tree-evolution" numbered="true" removeInRFC="fals
<name>Ratchet Tree Evolution</name> e" toc="include" pn="section-7.4">
<t>Whenever a member initiates an epoch change (i.e., commits; see <xref <name slugifiedName="name-ratchet-tree-evolution">Ratchet Tree Evolution
target="commit"/>), </name>
<t indent="0" pn="section-7.4-1">Whenever a member initiates an epoch ch
ange (i.e., commits; see <xref target="commit" format="default" sectionFormat="o
f" derivedContent="Section 12.4"/>),
they may need to refresh the key pairs of their leaf and of the nodes on their they may need to refresh the key pairs of their leaf and of the nodes on their
leaf's direct path in order to maintain forward secrecy and post-compromise leaf's direct path in order to maintain forward secrecy and post-compromise
security.</t> security.</t>
<t>The member initiating the epoch change generates the fresh key pairs using the <t indent="0" pn="section-7.4-2">The member initiating the epoch change generates the fresh key pairs using the
following procedure. The procedure is designed in a way that allows group member s to following procedure. The procedure is designed in a way that allows group member s to
efficiently communicate the fresh secret keys to other group members, as efficiently communicate the fresh secret keys to other group members, as
described in <xref target="update-paths"/>.</t> described in <xref target="update-paths" format="default" sectionFormat="of" der
<t>A member updates the nodes along its direct path as follows:</t> ivedContent="Section 7.6"/>.</t>
<ul spacing="normal"> <t indent="0" pn="section-7.4-3">A member updates the nodes along its di
<li>Blank all the nodes on the direct path from the leaf to the root.< rect path as follows:</t>
/li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7
<li>Generate a fresh HPKE key pair for the leaf.</li> .4-4">
<li>Generate a sequence of path secrets, one for each node on the leaf <li pn="section-7.4-4.1">Blank all the nodes on the direct path from t
's filtered direct he leaf to the root.</li>
<li pn="section-7.4-4.2">Generate a fresh HPKE key pair for the leaf.<
/li>
<li pn="section-7.4-4.3">Generate a sequence of path secrets, one for
each node on the leaf's filtered direct
path, as follows. In this setting, <tt>path_secret[0]</tt> refers to the first p arent node path, as follows. In this setting, <tt>path_secret[0]</tt> refers to the first p arent node
in the filtered direct path, <tt>path_secret[1]</tt> to the second parent node, and so on.</li> in the filtered direct path, <tt>path_secret[1]</tt> to the second parent node, and so on.</li>
</ul> </ul>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-7.4-5">
path_secret[0] is sampled at random path_secret[0] is sampled at random
path_secret[n] = DeriveSecret(path_secret[n-1], "path") path_secret[n] = DeriveSecret(path_secret[n-1], "path")
]]></sourcecode> </sourcecode>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7
<li>Compute the sequence of HPKE key pairs <tt>(node_priv,node_pub)</t .4-6">
t>, one for each <li pn="section-7.4-6.1">Compute the sequence of HPKE key pairs <tt>(n
ode_priv,node_pub)</tt>, one for each
node on the leaf's direct path, as follows.</li> node on the leaf's direct path, as follows.</li>
</ul> </ul>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-7.4-7">
node_secret[n] = DeriveSecret(path_secret[n], "node") node_secret[n] = DeriveSecret(path_secret[n], "node")
node_priv[n], node_pub[n] = KEM.DeriveKeyPair(node_secret[n]) node_priv[n], node_pub[n] = KEM.DeriveKeyPair(node_secret[n])
]]></sourcecode> </sourcecode>
<t>The node secret is derived as a temporary intermediate secret so that <t indent="0" pn="section-7.4-8">The node secret is derived as a tempora
each ry intermediate secret so that each
secret is only used with one algorithm: The path secret is used as an input to secret is only used with one algorithm: The path secret is used as an input to
DeriveSecret and the node secret is used as an input to DeriveKeyPair.</t> DeriveSecret, and the node secret is used as an input to DeriveKeyPair.</t>
<t>For example, suppose there is a group with four members, with C an un <t indent="0" pn="section-7.4-9">For example, suppose there is a group w
merged leaf ith four members, with C an unmerged leaf
at Z:</t> at Z:</t>
<figure anchor="evolution-tree"> <figure anchor="evolution-tree" align="left" suppress-title="false" pn="
<name>A full tree with one unmerged leaf</name> figure-13">
<artset> <name slugifiedName="name-a-full-tree-with-one-unmerg">A Full Tree wit
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= h One Unmerged Leaf</name>
"1.1" height="176" width="120" viewBox="0 0 120 176" class="diagram" text-anchor <artset pn="section-7.4-10.1">
="middle" font-family="monospace" font-size="13px"> <artwork type="svg" align="left" pn="section-7.4-10.1.1">
<svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-famil
y="monospace" font-size="13px" height="176" text-anchor="middle" version="1.1" v
iewBox="0 0 120 176" width="120">
<path d="M 56,48 L 56,64" fill="none" stroke="black"/> <path d="M 56,48 L 56,64" fill="none" stroke="black"/>
<path d="M 40,64 L 72,64" fill="none" stroke="black"/> <path d="M 40,64 L 72,64" fill="none" stroke="black"/>
<path d="M 72,64 L 80,80" fill="none" stroke="black"/> <path d="M 72,64 L 80,80" fill="none" stroke="black"/>
<path d="M 32,80 L 40,64" fill="none" stroke="black"/> <path d="M 32,80 L 40,64" fill="none" stroke="black"/>
<g class="text"> <g class="text">
<text x="56" y="36">Y</text> <text x="56" y="36">Y</text>
<text x="24" y="100">X</text> <text x="24" y="100">X</text>
<text x="100" y="100">Z[C]</text> <text x="100" y="100">Z[C]</text>
<text x="16" y="116">/</text> <text x="16" y="116">/</text>
<text x="32" y="116">\</text> <text x="32" y="116">\</text>
skipping to change at line 2657 skipping to change at line 2869
<text x="40" y="132">B</text> <text x="40" y="132">B</text>
<text x="72" y="132">C</text> <text x="72" y="132">C</text>
<text x="104" y="132">D</text> <text x="104" y="132">D</text>
<text x="8" y="164">0</text> <text x="8" y="164">0</text>
<text x="40" y="164">1</text> <text x="40" y="164">1</text>
<text x="72" y="164">2</text> <text x="72" y="164">2</text>
<text x="104" y="164">3</text> <text x="104" y="164">3</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-7.4-10.1.2">
Y Y
| |
.-+-. .-+-.
/ \ / \
X Z[C] X Z[C]
/ \ / \ / \ / \
A B C D A B C D
0 1 2 3 0 1 2 3
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>If member B subsequently generates an UpdatePath based on a secret <t indent="0" pn="section-7.4-11">If member B subsequently generates an UpdatePath based on a secret
"leaf_secret", then it would generate the following sequence "leaf_secret", then it would generate the following sequence
of path secrets:</t> of path secrets:</t>
<figure> <figure align="left" suppress-title="false" pn="figure-14">
<name>Derivation of ratchet tree keys along a direct path</name> <name slugifiedName="name-derivation-of-ratchet-tree-">Derivation of R
<artset> atchet Tree Keys along a Direct Path</name>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= <artset pn="section-7.4-12.1">
"1.1" height="272" width="560" viewBox="0 0 560 272" class="diagram" text-anchor <artwork type="svg" align="left" pn="section-7.4-12.1.1">
="middle" font-family="monospace" font-size="13px"> <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-famil
y="monospace" font-size="13px" height="272" text-anchor="middle" version="1.1" v
iewBox="0 0 560 272" width="560">
<path d="M 48,64 L 48,96" fill="none" stroke="black"/> <path d="M 48,64 L 48,96" fill="none" stroke="black"/>
<path d="M 48,144 L 48,176" fill="none" stroke="black"/> <path d="M 48,144 L 48,176" fill="none" stroke="black"/>
<path d="M 128,32 L 152,32" fill="none" stroke="black"/> <path d="M 128,32 L 152,32" fill="none" stroke="black"/>
<path d="M 288,32 L 344,32" fill="none" stroke="black"/> <path d="M 288,32 L 344,32" fill="none" stroke="black"/>
<path d="M 128,112 L 152,112" fill="none" stroke="black"/> <path d="M 128,112 L 152,112" fill="none" stroke="black"/>
<path d="M 288,112 L 344,112" fill="none" stroke="black"/> <path d="M 288,112 L 344,112" fill="none" stroke="black"/>
<path d="M 104,192 L 152,192" fill="none" stroke="black"/> <path d="M 104,192 L 152,192" fill="none" stroke="black"/>
<path d="M 304,192 L 344,192" fill="none" stroke="black"/> <path d="M 304,192 L 344,192" fill="none" stroke="black"/>
<path d="M 368,224 L 416,224" fill="none" stroke="black"/> <path d="M 368,224 L 416,224" fill="none" stroke="black"/>
<path d="M 448,224 L 496,224" fill="none" stroke="black"/> <path d="M 448,224 L 496,224" fill="none" stroke="black"/>
<path d="M 368,224 C 359.16936,224 352,216.83064 352,208" fill=" none" stroke="black"/> <path d="M 368,224 C 359.16936,224 352,216.83064 352,208" fill=" none" stroke="black"/>
<path d="M 416,224 C 424.83064,224 432,231.16936 432,240" fill=" none" stroke="black"/> <path d="M 416,224 C 424.83064,224 432,231.16936 432,240" fill=" none" stroke="black"/>
<path d="M 448,224 C 439.16936,224 432,231.16936 432,240" fill=" none" stroke="black"/> <path d="M 448,224 C 439.16936,224 432,231.16936 432,240" fill=" none" stroke="black"/>
<path d="M 496,224 C 504.83064,224 512,216.83064 512,208" fill=" none" stroke="black"/> <path d="M 496,224 C 504.83064,224 512,216.83064 512,208" fill=" none" stroke="black"/>
<polygon class="arrowhead" points="352,192 340,186.4 340,197.6" <polygon class="arrowhead" fill="black" points="352,192 340,186.
fill="black" transform="rotate(0,344,192)"/> 4 340,197.6" transform="rotate(0,344,192)"/>
<polygon class="arrowhead" points="352,112 340,106.4 340,117.6" <polygon class="arrowhead" fill="black" points="352,112 340,106.
fill="black" transform="rotate(0,344,112)"/> 4 340,117.6" transform="rotate(0,344,112)"/>
<polygon class="arrowhead" points="352,32 340,26.4 340,37.6" fil <polygon class="arrowhead" fill="black" points="352,32 340,26.4
l="black" transform="rotate(0,344,32)"/> 340,37.6" transform="rotate(0,344,32)"/>
<polygon class="arrowhead" points="160,192 148,186.4 148,197.6" <polygon class="arrowhead" fill="black" points="160,192 148,186.
fill="black" transform="rotate(0,152,192)"/> 4 148,197.6" transform="rotate(0,152,192)"/>
<polygon class="arrowhead" points="160,112 148,106.4 148,117.6" <polygon class="arrowhead" fill="black" points="160,112 148,106.
fill="black" transform="rotate(0,152,112)"/> 4 148,117.6" transform="rotate(0,152,112)"/>
<polygon class="arrowhead" points="160,32 148,26.4 148,37.6" fil <polygon class="arrowhead" fill="black" points="160,32 148,26.4
l="black" transform="rotate(0,152,32)"/> 148,37.6" transform="rotate(0,152,32)"/>
<polygon class="arrowhead" points="56,144 44,138.4 44,149.6" fil <polygon class="arrowhead" fill="black" points="56,144 44,138.4
l="black" transform="rotate(270,48,144)"/> 44,149.6" transform="rotate(270,48,144)"/>
<polygon class="arrowhead" points="56,64 44,58.4 44,69.6" fill=" <polygon class="arrowhead" fill="black" points="56,64 44,58.4 44
black" transform="rotate(270,48,64)"/> ,69.6" transform="rotate(270,48,64)"/>
<g class="text"> <g class="text">
<text x="60" y="36">path_secret[1]</text> <text x="60" y="36">path_secret[1]</text>
<text x="220" y="36">node_secret[1]</text> <text x="220" y="36">node_secret[1]</text>
<text x="408" y="36">node_priv[1],</text> <text x="408" y="36">node_priv[1],</text>
<text x="512" y="36">node_pub[1]</text> <text x="512" y="36">node_pub[1]</text>
<text x="60" y="116">path_secret[0]</text> <text x="60" y="116">path_secret[0]</text>
<text x="220" y="116">node_secret[0]</text> <text x="220" y="116">node_secret[0]</text>
<text x="408" y="116">node_priv[0],</text> <text x="408" y="116">node_priv[0],</text>
<text x="512" y="116">node_pub[0]</text> <text x="512" y="116">node_pub[0]</text>
<text x="48" y="196">leaf_secret</text> <text x="48" y="196">leaf_secret</text>
<text x="228" y="196">leaf_node_secret</text> <text x="228" y="196">leaf_node_secret</text>
<text x="396" y="196">leaf_priv,</text> <text x="396" y="196">leaf_priv,</text>
<text x="476" y="196">leaf_pub</text> <text x="476" y="196">leaf_pub</text>
<text x="432" y="260">leaf_node</text> <text x="432" y="260">leaf_node</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-7.4-12.1.2">
path_secret[1] ---> node_secret[1] -------> node_priv[1], node_pub[1] path_secret[1] ---&gt; node_secret[1] -------&gt; node_priv[1], node_pub[1]
^ ^
| |
| |
path_secret[0] ---> node_secret[0] -------&gt; node_priv[0], node_pub[0] path_secret[0] ---> node_secret[0] -------&gt; node_priv[0], node_pub[0]
^ ^
| |
| |
leaf_secret ------> leaf_node_secret --+--&gt; leaf_priv, leaf_pub leaf_secret ------> leaf_node_secret --+--&gt; leaf_priv, leaf_pub
| | | |
'-------. .-------' '-------. .-------'
| |
leaf_node leaf_node
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>After applying the UpdatePath, the tree will have the following struc <t indent="0" pn="section-7.4-13">After applying the UpdatePath, the tre
ture:</t> e will have the following structure:</t>
<figure> <figure align="left" suppress-title="false" pn="figure-15">
<name>Placement of keys in a ratchet tree</name> <name slugifiedName="name-placement-of-keys-in-a-ratc">Placement of Ke
<artset> ys in a Ratchet Tree</name>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= <artset pn="section-7.4-14.1">
"1.1" height="192" width="256" viewBox="0 0 256 192" class="diagram" text-anchor <artwork type="svg" align="left" pn="section-7.4-14.1.1">
="middle" font-family="monospace" font-size="13px"> <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-famil
y="monospace" font-size="13px" height="192" text-anchor="middle" version="1.1" v
iewBox="0 0 256 192" width="256">
<path d="M 176,144 L 176,160" fill="none" stroke="black"/> <path d="M 176,144 L 176,160" fill="none" stroke="black"/>
<path d="M 192,48 L 192,64" fill="none" stroke="black"/> <path d="M 192,48 L 192,64" fill="none" stroke="black"/>
<path d="M 112,32 L 176,32" fill="none" stroke="black"/> <path d="M 112,32 L 176,32" fill="none" stroke="black"/>
<path d="M 176,64 L 208,64" fill="none" stroke="black"/> <path d="M 176,64 L 208,64" fill="none" stroke="black"/>
<path d="M 112,96 L 144,96" fill="none" stroke="black"/> <path d="M 112,96 L 144,96" fill="none" stroke="black"/>
<path d="M 88,160 L 176,160" fill="none" stroke="black"/> <path d="M 88,160 L 176,160" fill="none" stroke="black"/>
<path d="M 208,64 L 216,80" fill="none" stroke="black"/> <path d="M 208,64 L 216,80" fill="none" stroke="black"/>
<path d="M 168,80 L 176,64" fill="none" stroke="black"/> <path d="M 168,80 L 176,64" fill="none" stroke="black"/>
<polygon class="arrowhead" points="184,144 172,138.4 172,149.6" <polygon class="arrowhead" fill="black" points="184,144 172,138.
fill="black" transform="rotate(270,176,144)"/> 4 172,149.6" transform="rotate(270,176,144)"/>
<polygon class="arrowhead" points="184,32 172,26.4 172,37.6" fil <polygon class="arrowhead" fill="black" points="184,32 172,26.4
l="black" transform="rotate(0,176,32)"/> 172,37.6" transform="rotate(0,176,32)"/>
<polygon class="arrowhead" points="152,96 140,90.4 140,101.6" fi <polygon class="arrowhead" fill="black" points="152,96 140,90.4
ll="black" transform="rotate(0,144,96)"/> 140,101.6" transform="rotate(0,144,96)"/>
<g class="text"> <g class="text">
<text x="52" y="36">node_priv[1]</text> <text x="52" y="36">node_priv[1]</text>
<text x="196" y="36">Y'</text> <text x="196" y="36">Y'</text>
<text x="52" y="100">node_priv[0]</text> <text x="52" y="100">node_priv[0]</text>
<text x="164" y="100">X'</text> <text x="164" y="100">X'</text>
<text x="236" y="100">Z[C]</text> <text x="236" y="100">Z[C]</text>
<text x="152" y="116">/</text> <text x="152" y="116">/</text>
<text x="168" y="116">\</text> <text x="168" y="116">\</text>
<text x="216" y="116">/</text> <text x="216" y="116">/</text>
<text x="232" y="116">\</text> <text x="232" y="116">\</text>
skipping to change at line 2773 skipping to change at line 2987
<text x="208" y="132">C</text> <text x="208" y="132">C</text>
<text x="240" y="132">D</text> <text x="240" y="132">D</text>
<text x="40" y="164">leaf_priv</text> <text x="40" y="164">leaf_priv</text>
<text x="144" y="180">0</text> <text x="144" y="180">0</text>
<text x="176" y="180">1</text> <text x="176" y="180">1</text>
<text x="208" y="180">2</text> <text x="208" y="180">2</text>
<text x="240" y="180">3</text> <text x="240" y="180">3</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-7.4-14.1.2">
node_priv[1] --------> Y' node_priv[1] --------&gt; Y'
| |
.-+-. .-+-.
/ \ / \
node_priv[0] ----> X' Z[C] node_priv[0] ----&gt; X' Z[C]
/ \ / \ / \ / \
A B C D A B C D
^ ^
leaf_priv -----------+ leaf_priv -----------+
0 1 2 3 0 1 2 3
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="synchronizing-views-of-the-tree"> <section anchor="synchronizing-views-of-the-tree" numbered="true" removeIn
<name>Synchronizing Views of the Tree</name> RFC="false" toc="include" pn="section-7.5">
<t>After generating fresh key material and applying it to ratchet forwar <name slugifiedName="name-synchronizing-views-of-the-">Synchronizing Vie
d their ws of the Tree</name>
local tree state as described in the <xref target="ratchet-tree-evolution"/>, th <t indent="0" pn="section-7.5-1">After generating fresh key material and
e applying it to update their
local tree state as described in <xref target="ratchet-tree-evolution" format="d
efault" sectionFormat="of" derivedContent="Section 7.4"/>, the
generator broadcasts generator broadcasts
this update to other members of the group in a Commit message, who this update to other members of the group in a Commit message, who
apply it to keep their local views of the tree in apply it to keep their local views of the tree in
sync with the sender's. More specifically, when a member commits a change to sync with the sender's. More specifically, when a member commits a change to
the tree (e.g., to add or remove a member), it transmits an UpdatePath the tree (e.g., to add or remove a member), it transmits an UpdatePath
containing a set of public keys and encrypted path secrets containing a set of public keys and encrypted path secrets
for intermediate nodes in the filtered direct path of its leaf. The for intermediate nodes in the filtered direct path of its leaf. The
other members of the group use these values to update other members of the group use these values to update
their view of the tree, aligning their copy of the tree to the their view of the tree, aligning their copy of the tree to the
sender's.</t> sender's.</t>
<t>An UpdatePath contains <t indent="0" pn="section-7.5-2">An UpdatePath contains
the following information for each node in the filtered direct path of the the following information for each node in the filtered direct path of the
sender's leaf, including the root:</t> sender's leaf, including the root:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7
<li>The public key for the node</li> .5-3">
<li>One or more encrypted copies of the path secret corresponding to <li pn="section-7.5-3.1">The public key for the node</li>
<li pn="section-7.5-3.2">One or more encrypted copies of the path secr
et corresponding to
the node</li> the node</li>
</ul> </ul>
<t>The path secret value for a given node is encrypted to the subtree <t indent="0" pn="section-7.5-4">The path secret value for a given node is encrypted to the subtree
rooted at the parent's non-updated child, i.e., the child rooted at the parent's non-updated child, i.e., the child
on the copath of the sender's leaf node. on the copath of the sender's leaf node.
There is one encryption of the path secret to each public key in the resolution There is one encryption of the path secret to each public key in the resolution
of the non-updated child.</t> of the non-updated child.</t>
<t>A member of the group <em>updates their direct path</em> by computing <t indent="0" pn="section-7.5-5">A member of the group <em>updates their
new values for direct path</em> by computing new values for
their leaf node and the nodes along their filtered direct path:</t> their leaf node and the nodes along their filtered direct path as follows:</t>
<ol spacing="normal" type="1"><li>Blank all nodes along the direct path <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7.
of the sender's leaf.</li> 5-6">
<li> <li pn="section-7.5-6.1" derivedCounter="1.">Blank all nodes along the
<t>Compute updated path secrets and public keys for the nodes on the direct path of the sender's leaf.</li>
sender's <li pn="section-7.5-6.2" derivedCounter="2.">
<t indent="0" pn="section-7.5-6.2.1">Compute updated path secrets an
d public keys for the nodes on the sender's
filtered direct path. filtered direct path.
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>Generate a sequence of path secrets of the same length as the on-7.5-6.2.2">
filtered <li pn="section-7.5-6.2.2.1">Generate a sequence of path secrets o
direct path, as defined in <xref target="ratchet-tree-evolution"/></li> f the same length as the filtered
<li>For each node in the filtered direct path, replace the node's direct path, as defined in <xref target="ratchet-tree-evolution" format="default
public key " sectionFormat="of" derivedContent="Section 7.4"/>.</li>
<li pn="section-7.5-6.2.2.2">For each node in the filtered direct
path, replace the node's public key
with the <tt>node_pub[n]</tt> value derived from the corresponding path secret with the <tt>node_pub[n]</tt> value derived from the corresponding path secret
<tt>path_secret[n]</tt>.</li> <tt>path_secret[n]</tt>.</li>
</ul> </ul>
</li> </li>
<li>Compute the new parent hashes for the nodes along the filtered dir ect path <li pn="section-7.5-6.3" derivedCounter="3.">Compute the new parent ha shes for the nodes along the filtered direct path
and the sender's leaf node.</li> and the sender's leaf node.</li>
<li> <li pn="section-7.5-6.4" derivedCounter="4.">
<t>Update the leaf node for the sender. <t indent="0" pn="section-7.5-6.4.1">Update the leaf node for the se
nder.
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>Set the <tt>leaf_node_source</tt> to <tt>commit</tt>.</li> on-7.5-6.4.2">
<li>Set the <tt>encryption_key</tt> to the public key of a freshly <li pn="section-7.5-6.4.2.1">Set the <tt>leaf_node_source</tt> to
sampled key pair</li> <tt>commit</tt>.</li>
<li>Set the parent hash to the parent hash for the leaf.</li> <li pn="section-7.5-6.4.2.2">Set the <tt>encryption_key</tt> to th
<li>Re-sign the leaf node with its new contents</li> e public key of a freshly sampled key pair.</li>
<li pn="section-7.5-6.4.2.3">Set the parent hash to the parent has
h for the leaf.</li>
<li pn="section-7.5-6.4.2.4">Re-sign the leaf node with its new co
ntents.</li>
</ul> </ul>
</li> </li>
</ol> </ol>
<t>Since the new leaf node effectively updates an existing leaf node in <t indent="0" pn="section-7.5-7">Since the new leaf node effectively upd
the group, ates an existing leaf node in the group,
it MUST adhere to the same restrictions as LeafNodes used in <tt>Update</tt> pro it <bcp14>MUST</bcp14> adhere to the same restrictions as LeafNodes used in Upda
posals te proposals
(aside from <tt>leaf_node_source</tt>). The application MAY specify other change (aside from <tt>leaf_node_source</tt>). The application <bcp14>MAY</bcp14> speci
s to fy other changes to
the leaf node, e.g., providing a new signature key, updated capabilities, or the leaf node, e.g., providing a new signature key, updated capabilities, or
different extensions.</t> different extensions.</t>
<t>The member then <em>encrypts path secrets to the group</em>. For eac h node in the <t indent="0" pn="section-7.5-8">The member then <em>encrypts path secre ts to the group</em>. For each node in the
member's filtered direct path, the member takes the following steps:</t> member's filtered direct path, the member takes the following steps:</t>
<ol spacing="normal" type="1"><li>Compute the resolution of the node's c <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7.
hild that is on the copath of the 5-9">
<li pn="section-7.5-9.1" derivedCounter="1.">Compute the resolution of
the node's child that is on the copath of the
sender (the child that is not in the direct path of the sender). Any new sender (the child that is not in the direct path of the sender). Any new
member (from an Add proposal) added in the same Commit MUST be excluded from member (from an Add proposal) added in the same Commit <bcp14>MUST</bcp14> be ex cluded from
this resolution.</li> this resolution.</li>
<li>For each node in the resolution, encrypt the path secret for the d irect <li pn="section-7.5-9.2" derivedCounter="2.">For each node in the reso lution, encrypt the path secret for the direct
path node using the public key of the resolution node, as defined in path node using the public key of the resolution node, as defined in
<xref target="update-paths"/></li> <xref target="update-paths" format="default" sectionFormat="of" derivedContent=" Section 7.6"/>.</li>
</ol> </ol>
<t>The recipient of an UpdatePath performs the corresponding steps. Fir st, the <t indent="0" pn="section-7.5-10">The recipient of an UpdatePath perform s the corresponding steps. First, the
recipient <em>merges UpdatePath into the tree</em>:</t> recipient <em>merges UpdatePath into the tree</em>:</t>
<ol spacing="normal" type="1"><li>Blank all nodes on the direct path of <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7.
the sender's leaf.</li> 5-11">
<li> <li pn="section-7.5-11.1" derivedCounter="1.">Blank all nodes on the d
<t>For all nodes on the filtered direct path of the sender's leaf, irect path of the sender's leaf.</li>
<li pn="section-7.5-11.2" derivedCounter="2.">
<t indent="0" pn="section-7.5-11.2.1">For all nodes on the filtered
direct path of the sender's leaf,
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>Set the public key to the public key in the UpdatePath.</li> on-7.5-11.2.2">
<li>Set the list of unmerged leaves to the empty list.</li> <li pn="section-7.5-11.2.2.1">Set the public key to the public key
in the UpdatePath.</li>
<li pn="section-7.5-11.2.2.2">Set the list of unmerged leaves to t
he empty list.</li>
</ul> </ul>
</li> </li>
<li> <li pn="section-7.5-11.3" derivedCounter="3.">
<t>Compute parent hashes for the nodes in the sender's filtered dire <t indent="0" pn="section-7.5-11.3.1">Compute parent hashes for the
ct path, nodes in the sender's filtered direct path,
and verify that the <tt>parent_hash</tt> field of the leaf node matches the pare nt and verify that the <tt>parent_hash</tt> field of the leaf node matches the pare nt
hash for the first node in its filtered direct path. hash for the first node in its filtered direct path.
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>Note that these hashes are computed from root to leaf, so that on-7.5-11.3.2">
<li pn="section-7.5-11.3.2.1">Note that these hashes are computed
from root to leaf, so that
each hash incorporates all the non-blank nodes above it. The root node each hash incorporates all the non-blank nodes above it. The root node
always has a zero-length hash for its parent hash.</li> always has a zero-length hash for its parent hash.</li>
</ul> </ul>
</li> </li>
</ol> </ol>
<t>Second, the recipient <em>decrypts the path secrets</em>:</t> <t indent="0" pn="section-7.5-12">Second, the recipient <em>decrypts the
<ol spacing="normal" type="1"><li>Identify a node in the filtered direct path secrets</em>:</t>
path for which the recipient <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7.
5-13">
<li pn="section-7.5-13.1" derivedCounter="1.">Identify a node in the f
iltered direct path for which the recipient
is in the subtree of the non-updated child.</li> is in the subtree of the non-updated child.</li>
<li>Identify a node in the resolution of the copath node for <li pn="section-7.5-13.2" derivedCounter="2.">Identify a node in the r esolution of the copath node for
which the recipient has a private key.</li> which the recipient has a private key.</li>
<li>Decrypt the path secret for the parent of the copath node using <li pn="section-7.5-13.3" derivedCounter="3.">Decrypt the path secret for the parent of the copath node using
the private key from the resolution node.</li> the private key from the resolution node.</li>
<li>Derive path secrets for ancestors of that node in the sender's fil tered <li pn="section-7.5-13.4" derivedCounter="4.">Derive path secrets for ancestors of that node in the sender's filtered
direct path using the algorithm described above.</li> direct path using the algorithm described above.</li>
<li>Derive the node secrets and node key pairs from the path secrets.< <li pn="section-7.5-13.5" derivedCounter="5.">Derive the node secrets
/li> and node key pairs from the path secrets.</li>
<li>Verify that the derived public keys are the same as the correspond <li pn="section-7.5-13.6" derivedCounter="6.">Verify that the derived
ing public public keys are the same as the corresponding public
keys sent in the UpdatePath.</li> keys sent in the UpdatePath.</li>
<li>Store the derived private keys in the corresponding ratchet tree n odes.</li> <li pn="section-7.5-13.7" derivedCounter="7.">Store the derived privat e keys in the corresponding ratchet tree nodes.</li>
</ol> </ol>
<t>For example, in order to communicate the example update described in <t indent="0" pn="section-7.5-14">For example, in order to communicate t
<xref target="ratchet-tree-evolution"/>, the member at node B would transmit the he example update described in
following <xref target="ratchet-tree-evolution" format="default" sectionFormat="of" derive
dContent="Section 7.4"/>, the member at node B would transmit the following
values:</t> values:</t>
<table> <table align="center" pn="table-3">
<thead> <thead>
<tr> <tr>
<th align="left">Public Key</th> <th align="left" colspan="1" rowspan="1">Public Key</th>
<th align="left">Ciphertext(s)</th> <th align="left" colspan="1" rowspan="1">Ciphertext(s)</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>node_pub[1]</tt></td> <tt>node_pub[1]</tt>
<td align="left"> </td>
<td align="left" colspan="1" rowspan="1">
<tt>E(pk(Z), path_secret[1])</tt>, <tt>E(pk(C), path_secret[1]</ tt>)</td> <tt>E(pk(Z), path_secret[1])</tt>, <tt>E(pk(C), path_secret[1]</ tt>)</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>node_pub[0]</tt></td> <tt>node_pub[0]</tt>
<td align="left"> </td>
<tt>E(pk(A), path_secret[0])</tt></td> <td align="left" colspan="1" rowspan="1">
<tt>E(pk(A), path_secret[0])</tt>
</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>In this table, the value node_pub[i] represents the public key <t indent="0" pn="section-7.5-16">In this table, the value node_pub[i] r epresents the public key
derived from node_secret[i], pk(X) represents the current public key derived from node_secret[i], pk(X) represents the current public key
of node X, and E(K, S) represents of node X, and E(K, S) represents
the public-key encryption of the path secret S to the the public key encryption of the path secret S to the
public key K (using HPKE).</t> public key K (using HPKE).</t>
<t>A recipient at node A would decrypt <tt>E(pk(A), path_secret\[0\])</t t> to obtain <t indent="0" pn="section-7.5-17">A recipient at node A would decrypt <t t>E(pk(A), path_secret\[0\])</tt> to obtain
<tt>path_secret\[0\]</tt>, then use it to derive <tt>path_secret[1]</tt> and the resulting <tt>path_secret\[0\]</tt>, then use it to derive <tt>path_secret[1]</tt> and the resulting
node secrets and key pairs. Thus, A would have the private keys to nodes X' node secrets and key pairs. Thus, A would have the private keys to nodes X'
and Y', in accordance with the tree invariant.</t> and Y', in accordance with the tree invariant.</t>
<t>Similarly, a recipient at node D would decrypt <tt>E(pk(Z), path_secr et[1])</tt> to <t indent="0" pn="section-7.5-18">Similarly, a recipient at node D would decrypt <tt>E(pk(Z), path_secret[1])</tt> to
obtain <tt>path_secret[1]</tt>, then use it to derive the node secret and key pa ir obtain <tt>path_secret[1]</tt>, then use it to derive the node secret and key pa ir
for the node Y'. As required to maintain the tree invariant, node D does not for the node Y'. As required to maintain the tree invariant, node D does not
receive the private key for the node X', since X' is not an ancestor of D.</t> receive the private key for the node X', since X' is not an ancestor of D.</t>
<t>After processing the update, each recipient MUST delete outdated key material, <t indent="0" pn="section-7.5-19">After processing the update, each reci pient <bcp14>MUST</bcp14> delete outdated key material,
specifically:</t> specifically:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7
<li>The path secrets and node secrets used to derive each updated node .5-20">
key pair.</li> <li pn="section-7.5-20.1">The path secrets and node secrets used to de
<li>Each outdated node key pair that was replaced by the update.</li> rive each updated node key pair.</li>
<li pn="section-7.5-20.2">Each outdated node key pair that was replace
d by the update.</li>
</ul> </ul>
</section> </section>
<section anchor="update-paths"> <section anchor="update-paths" numbered="true" removeInRFC="false" toc="in
<name>Update Paths</name> clude" pn="section-7.6">
<t>As described in <xref target="commit"/>, each Commit message may opti <name slugifiedName="name-update-paths">Update Paths</name>
onally contain an <t indent="0" pn="section-7.6-1">As described in <xref target="commit" f
ormat="default" sectionFormat="of" derivedContent="Section 12.4"/>, each Commit
message may optionally contain an
UpdatePath, with a new LeafNode and set of parent nodes for the sender's UpdatePath, with a new LeafNode and set of parent nodes for the sender's
filtered direct path. For each parent node, the UpdatePath contains a new filtered direct path. For each parent node, the UpdatePath contains a new
public key and encrypted path secret. The parent nodes are kept in the same public key and encrypted path secret. The parent nodes are kept in the same
order as the filtered direct path.</t> order as the filtered direct path.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-7.6-2">
struct { struct {
opaque kem_output<V>; opaque kem_output&lt;V&gt;;
opaque ciphertext<V>; opaque ciphertext&lt;V&gt;;
} HPKECiphertext; } HPKECiphertext;
struct { struct {
HPKEPublicKey encryption_key; HPKEPublicKey encryption_key;
HPKECiphertext encrypted_path_secret<V&gt;; HPKECiphertext encrypted_path_secret<V&gt;;
} UpdatePathNode; } UpdatePathNode;
struct { struct {
LeafNode leaf_node; LeafNode leaf_node;
UpdatePathNode nodes<V&gt;; UpdatePathNode nodes<V&gt;;
} UpdatePath; } UpdatePath;
]]></sourcecode> </sourcecode>
<t>For each <tt>UpdatePathNode</tt>, the resolution of the corresponding <t indent="0" pn="section-7.6-3">For each UpdatePathNode, the resolution
copath node MUST of the corresponding copath node <bcp14>MUST</bcp14>
exclude all new leaf nodes added as part of the current Commit. The length of exclude all new leaf nodes added as part of the current Commit. The length of
the <tt>encrypted_path_secret</tt> vector MUST be equal to the length of the res olution the <tt>encrypted_path_secret</tt> vector <bcp14>MUST</bcp14> be equal to the le ngth of the resolution
of the copath node (excluding new leaf nodes), with each ciphertext being the of the copath node (excluding new leaf nodes), with each ciphertext being the
encryption to the respective resolution node.</t> encryption to the respective resolution node.</t>
<t>The HPKECiphertext values are encrypted and decrypted as follows:</t> <t keepWithNext="true" indent="0" pn="section-7.6-4">The HPKECiphertext
<sourcecode type="pseudocode"><![CDATA[ values are encrypted and decrypted as follows:</t>
<sourcecode type="pseudocode" markers="false" pn="section-7.6-5">
(kem_output, ciphertext) = (kem_output, ciphertext) =
EncryptWithLabel(node_public_key, "UpdatePathNode", EncryptWithLabel(node_public_key, "UpdatePathNode",
group_context, path_secret) group_context, path_secret)
path_secret = path_secret =
DecryptWithLabel(node_private_key, "UpdatePathNode", DecryptWithLabel(node_private_key, "UpdatePathNode",
group_context, kem_output, ciphertext) group_context, kem_output, ciphertext)
]]></sourcecode> </sourcecode>
<t>Here <tt>node_public_key</tt> is the public key of the node for which <t indent="0" pn="section-7.6-6">Here <tt>node_public_key</tt> is the pu
the path secret is blic key of the node for which the path secret is
encrypted, <tt>group_context</tt> is the provisional GroupContext object for encrypted, <tt>group_context</tt> is the provisional GroupContext object for
the group, and the <tt>EncryptWithLabel</tt> function is as defined in the group, and the <tt>EncryptWithLabel</tt> function is as defined in
<xref target="public-key-encryption"/>.</t> <xref target="public-key-encryption" format="default" sectionFormat="of" derived Content="Section 5.1.3"/>.</t>
</section> </section>
<section anchor="adding-and-removing-leaves"> <section anchor="adding-and-removing-leaves" numbered="true" removeInRFC="
<name>Adding and Removing Leaves</name> false" toc="include" pn="section-7.7">
<t>In addition to the path-based updates to the tree described above, it <name slugifiedName="name-adding-and-removing-leaves">Adding and Removin
is also g Leaves</name>
<t indent="0" pn="section-7.7-1">In addition to the path-based updates t
o the tree described above, it is also
necessary to add and remove leaves of the tree in order to reflect changes to necessary to add and remove leaves of the tree in order to reflect changes to
the membership of the group (see <xref target="add"/> and <xref target="remove"/ >). Since the tree is the membership of the group (see Sections <xref format="counter" target="add" se ctionFormat="of" derivedContent="12.1.1"/> and <xref format="counter" target="re move" sectionFormat="of" derivedContent="12.1.3"/>). Since the tree is
always full, adding or removing leaves corresponds to increasing or decreasing always full, adding or removing leaves corresponds to increasing or decreasing
the depth of the tree, resulting in the number of leaves being doubled or the depth of the tree, resulting in the number of leaves being doubled or
halved. These operations are also known as <em>extending</em> and <em>truncating </em> the halved. These operations are also known as <em>extending</em> and <em>truncating </em> the
tree.</t> tree.</t>
<t>Leaves are always added and removed at the right edge of the tree. W hen the <t indent="0" pn="section-7.7-2">Leaves are always added and removed at the right edge of the tree. When the
size of the tree needs to be increased, a new blank root node is added, whose size of the tree needs to be increased, a new blank root node is added, whose
left subtree is the existing tree and right subtree is a new all-blank subtree. left subtree is the existing tree and right subtree is a new all-blank subtree.
This operation is typically done when adding a member to the group.</t> This operation is typically done when adding a member to the group.</t>
<figure> <figure align="left" suppress-title="false" pn="figure-16">
<name>Extending the tree to make room for a third member</name> <name slugifiedName="name-extending-the-tree-to-make-">Extending the T
<artwork type="ascii-art"><![CDATA[ ree to Make Room for a Third Member</name>
_ <-- new blank root _ <artwork type="ascii-art" align="left" pn="section-7.7-3.1">
_ &lt;-- new blank root _
__|__ __|__ __|__ __|__
/ \ / \ / \ / \
X ===> X _ <-- new blank subtree ===&gt; X _ X ===> X _ &lt;-- new blank subtree ===&gt; X _
/ \ / \ / \ / \ / \ / \ / \ / \ / \ / \
A B A B _ _ A B C _ A B A B _ _ A B C _
^ ^
| |
+-- new member new member --+
]]></artwork> </artwork>
</figure> </figure>
<t>When the right subtree of the tree no longer has any non-blank nodes, it can be <t indent="0" pn="section-7.7-4">When the right subtree of the tree no l onger has any non-blank nodes, it can be
safely removed. The root of the tree and the right subtree are discarded safely removed. The root of the tree and the right subtree are discarded
(whether or not the root node is blank). The left child of the root becomes the (whether or not the root node is blank). The left child of the root becomes the
new root node, and the left subtree becomes the new tree. This operation is new root node, and the left subtree becomes the new tree. This operation is
typically done after removing a member from the group.</t> typically done after removing a member from the group.</t>
<figure> <figure align="left" suppress-title="false" pn="figure-17">
<name>Cleaning up after removing member C</name> <name slugifiedName="name-cleaning-up-after-removing-">Cleaning Up aft
<artwork type="ascii-art"><![CDATA[ er Removing Member C</name>
<artwork type="ascii-art" align="left" pn="section-7.7-5.1">
Y Y Y Y
__|__ __|__ __|__ __|__
/ \ / \ / \ / \
X _ ===> X _ ==> X &lt;-- new root X _ ===> X _ ==&gt; X &lt;-- new root
/ \ / \ / \ / \ / \ / \ / \ / \ / \ / \
A B C _ A B _ _ A B A B C _ A B _ _ A B
^ ^
| |
removed member --+ removed member --+
]]></artwork> </artwork>
</figure> </figure>
<t>Concrete algorithms for these operations on array-based and link-base <t indent="0" pn="section-7.7-6">Concrete algorithms for these operation
d trees are s on array-based and link-based trees are
provided in <xref target="array-based-trees"/> and <xref target="link-based-tree provided in Appendices <xref format="counter" target="array-based-trees" section
s"/>. The concrete Format="of" derivedContent="C"/> and <xref format="counter" target="link-based-t
rees" sectionFormat="of" derivedContent="D"/>. The concrete
algorithms are non-normative. An implementation may use any algorithm that algorithms are non-normative. An implementation may use any algorithm that
produces the correct tree in its internal representation.</t> produces the correct tree in its internal representation.</t>
</section> </section>
<section anchor="tree-hashes"> <section anchor="tree-hashes" numbered="true" removeInRFC="false" toc="inc
<name>Tree Hashes</name> lude" pn="section-7.8">
<t>MLS hashes the contents of the tree in two ways to authenticate diffe <name slugifiedName="name-tree-hashes">Tree Hashes</name>
rent <t indent="0" pn="section-7.8-1">MLS hashes the contents of the tree in
two ways to authenticate different
properties of the tree. <em>Tree hashes</em> are defined in this section, and < em>parent properties of the tree. <em>Tree hashes</em> are defined in this section, and < em>parent
hashes</em> are defined in <xref target="parent-hashes"/>.</t> hashes</em> are defined in <xref target="parent-hashes" format="default" section
<t>Each node in a ratchet tree has a tree hash that summarizes the subtr Format="of" derivedContent="Section 7.9"/>.</t>
ee below <t indent="0" pn="section-7.8-2">Each node in a ratchet tree has a tree
hash that summarizes the subtree below
that node. The tree hash of the root is used in the GroupContext to confirm that node. The tree hash of the root is used in the GroupContext to confirm
that the group agrees on the whole tree. Tree hashes are computed recursively that the group agrees on the whole tree. Tree hashes are computed recursively
from the leaves up to the root.</t> from the leaves up to the root.</t>
<figure> <figure align="left" suppress-title="false" pn="figure-18">
<name>Composition of the tree hash</name> <name slugifiedName="name-composition-of-the-tree-has">Composition of
<artset> the Tree Hash</name>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= <artset pn="section-7.8-3.1">
"1.1" height="112" width="128" viewBox="0 0 128 112" class="diagram" text-anchor <artwork type="svg" align="left" pn="section-7.8-3.1.1">
="middle" font-family="monospace" font-size="13px"> <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-famil
y="monospace" font-size="13px" height="112" text-anchor="middle" version="1.1" v
iewBox="0 0 128 112" width="128">
<path d="M 24,32 L 40,32" fill="none" stroke="black"/> <path d="M 24,32 L 40,32" fill="none" stroke="black"/>
<path d="M 72,48 L 88,80" fill="none" stroke="black"/> <path d="M 72,48 L 88,80" fill="none" stroke="black"/>
<path d="M 40,80 L 56,48" fill="none" stroke="black"/> <path d="M 40,80 L 56,48" fill="none" stroke="black"/>
<polygon class="arrowhead" points="80,48 68,42.4 68,53.6" fill=" <polygon class="arrowhead" fill="black" points="80,48 68,42.4 68
black" transform="rotate(243.43494882292202,72,48)"/> ,53.6" transform="rotate(243.43494882292202,72,48)"/>
<polygon class="arrowhead" points="64,48 52,42.4 52,53.6" fill=" <polygon class="arrowhead" fill="black" points="64,48 52,42.4 52
black" transform="rotate(296.565051177078,56,48)"/> ,53.6" transform="rotate(296.565051177078,56,48)"/>
<polygon class="arrowhead" points="48,32 36,26.4 36,37.6" fill=" <polygon class="arrowhead" fill="black" points="48,32 36,26.4 36
black" transform="rotate(0,40,32)"/> ,37.6" transform="rotate(0,40,32)"/>
<g class="text"> <g class="text">
<text x="8" y="36">P</text> <text x="8" y="36">P</text>
<text x="72" y="36">th(P)</text> <text x="72" y="36">th(P)</text>
<text x="24" y="100">th(L)</text> <text x="24" y="100">th(L)</text>
<text x="104" y="100">th(R)</text> <text x="104" y="100">th(R)</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-7.8-3.1.2">
P --> th(P) P --&gt; th(P)
^ ^ ^ ^
/ \ / \
/ \ / \
th(L) th(R) th(L) th(R)
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>The tree hash of an individual node is the hash of the node's <tt>Tre <t indent="0" pn="section-7.8-4">The tree hash of an individual node is
eHashInput</tt> the hash of the node's TreeHashInput
object, which may contain either a <tt>LeafNodeHashInput</tt> or a object, which may contain either a LeafNodeHashInput or a
<tt>ParentNodeHashInput</tt> depending on the type of node. <tt>LeafNodeHashInpu ParentNodeHashInput depending on the type of node. LeafNodeHashInput objects
t</tt> objects contain the <tt>leaf_index</tt> and the LeafNode (if any). ParentNodeHashInput
contain the <tt>leaf_index</tt> and the <tt>LeafNode</tt> (if any). <tt>ParentNo objects contain the ParentNode (if any) and the tree hash of the node's left
deHashInput</tt>
objects contain the <tt>ParentNode</tt> (if any) and the tree hash of the node's
left
and right children. For both parent and leaf nodes, the optional node value and right children. For both parent and leaf nodes, the optional node value
MUST be absent if the node is blank and present if the node contains a value.</t <bcp14>MUST</bcp14> be absent if the node is blank and present if the node conta
> ins a value.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-7.8-5">
enum { enum {
reserved(0), reserved(0),
leaf(1), leaf(1),
parent(2), parent(2),
(255) (255)
} NodeType; } NodeType;
struct { struct {
NodeType node_type; NodeType node_type;
select (TreeHashInput.node_type) { select (TreeHashInput.node_type) {
case leaf: LeafNodeHashInput leaf_node; case leaf: LeafNodeHashInput leaf_node;
case parent: ParentNodeHashInput parent_node; case parent: ParentNodeHashInput parent_node;
}; };
} TreeHashInput; } TreeHashInput;
struct { struct {
uint32 leaf_index; uint32 leaf_index;
optional<LeafNode&gt; leaf_node; optional<LeafNode&gt; leaf_node;
} LeafNodeHashInput; } LeafNodeHashInput;
struct { struct {
optional<ParentNode> parent_node; optional&lt;ParentNode&gt; parent_node;
opaque left_hash<V>; opaque left_hash&lt;V&gt;;
opaque right_hash<V>; opaque right_hash&lt;V&gt;;
} ParentNodeHashInput; } ParentNodeHashInput;
]]></sourcecode> </sourcecode>
<t>The tree hash of an entire tree corresponds to the tree hash of the r <t indent="0" pn="section-7.8-6">The tree hash of an entire tree corresp
oot node, onds to the tree hash of the root node,
which is computed recursively by starting at the leaf nodes and building up.</t> which is computed recursively by starting at the leaf nodes and building up.</t>
</section> </section>
<section anchor="parent-hashes"> <section anchor="parent-hashes" numbered="true" removeInRFC="false" toc="i
<name>Parent Hashes</name> nclude" pn="section-7.9">
<t>While tree hashes summarize the state of a tree at point in time, par <name slugifiedName="name-parent-hashes">Parent Hashes</name>
ent hashes <t indent="0" pn="section-7.9-1">While tree hashes summarize the state o
f a tree at point in time, parent hashes
capture information about how keys in the tree were populated.</t> capture information about how keys in the tree were populated.</t>
<t>When a client sends a commit to change a group, it can include an Upd atePath to <t indent="0" pn="section-7.9-2">When a client sends a Commit to change a group, it can include an UpdatePath to
assign new keys to the nodes along its filtered direct path. When a client assign new keys to the nodes along its filtered direct path. When a client
computes an UpdatePath (as defined in <xref target="synchronizing-views-of-the-t ree"/>), it computes an UpdatePath (as defined in <xref target="synchronizing-views-of-the-t ree" format="default" sectionFormat="of" derivedContent="Section 7.5"/>), it
computes and signs a parent hash that summarizes the state of the tree after the computes and signs a parent hash that summarizes the state of the tree after the
UpdatePath has been applied. These summaries are constructed in a chain from UpdatePath has been applied. These summaries are constructed in a chain from
the root to the member's leaf so that the part of the chain closer to the root the root to the member's leaf so that the part of the chain closer to the root
can be overwritten as nodes set in one UpdatePath are reset by a later can be overwritten as nodes set in one UpdatePath are reset by a later
UpdatePath.</t> UpdatePath.</t>
<figure> <figure align="left" suppress-title="false" pn="figure-19">
<name>Inputs to a parent hash</name> <name slugifiedName="name-inputs-to-a-parent-hash">Inputs to a Parent
<artset> Hash</name>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= <artset pn="section-7.9-3.1">
"1.1" height="176" width="216" viewBox="0 0 216 176" class="diagram" text-anchor <artwork type="svg" align="left" pn="section-7.9-3.1.1">
="middle" font-family="monospace" font-size="13px"> <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-famil
y="monospace" font-size="13px" height="176" text-anchor="middle" version="1.1" v
iewBox="0 0 216 176" width="216">
<path d="M 112,96 L 128,96" fill="none" stroke="black"/> <path d="M 112,96 L 128,96" fill="none" stroke="black"/>
<path d="M 160,112 L 176,144" fill="none" stroke="black"/> <path d="M 160,112 L 176,144" fill="none" stroke="black"/>
<path d="M 128,144 L 144,112" fill="none" stroke="black"/> <path d="M 128,144 L 144,112" fill="none" stroke="black"/>
<path d="M 160,80 L 176,48" fill="none" stroke="black"/> <path d="M 160,80 L 176,48" fill="none" stroke="black"/>
<polygon class="arrowhead" points="168,112 156,106.4 156,117.6" <polygon class="arrowhead" fill="black" points="168,112 156,106.
fill="black" transform="rotate(243.43494882292202,160,112)"/> 4 156,117.6" transform="rotate(243.43494882292202,160,112)"/>
<polygon class="arrowhead" points="168,80 156,74.4 156,85.6" fil <polygon class="arrowhead" fill="black" points="168,80 156,74.4
l="black" transform="rotate(116.56505117707799,160,80)"/> 156,85.6" transform="rotate(116.56505117707799,160,80)"/>
<polygon class="arrowhead" points="136,144 124,138.4 124,149.6" <polygon class="arrowhead" fill="black" points="136,144 124,138.
fill="black" transform="rotate(116.56505117707799,128,144)"/> 4 124,149.6" transform="rotate(116.56505117707799,128,144)"/>
<polygon class="arrowhead" points="136,96 124,90.4 124,101.6" fi <polygon class="arrowhead" fill="black" points="136,96 124,90.4
ll="black" transform="rotate(0,128,96)"/> 124,101.6" transform="rotate(0,128,96)"/>
<g class="text"> <g class="text">
<text x="192" y="36">ph(Q)</text> <text x="192" y="36">ph(Q)</text>
<text x="52" y="100">P.public_key</text> <text x="52" y="100">P.public_key</text>
<text x="160" y="100">ph(P)</text> <text x="160" y="100">ph(P)</text>
<text x="80" y="164">N.parent_hash</text> <text x="80" y="164">N.parent_hash</text>
<text x="192" y="164">th(S)</text> <text x="192" y="164">th(S)</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-7.9-3.1.2">
ph(Q) ph(Q)
/ /
/ /
V V
P.public_key --> ph(P) P.public_key --&gt; ph(P)
/ ^ / ^
/ \ / \
V \ V \
N.parent_hash th(S) N.parent_hash th(S)
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>As a result, the signature over the parent hash in each member's leaf <t indent="0" pn="section-7.9-4">As a result, the signature over the par ent hash in each member's leaf
effectively signs the subtree of the tree that hasn't been changed since that effectively signs the subtree of the tree that hasn't been changed since that
leaf was last changed in an UpdatePath. A new member joining the group uses leaf was last changed in an UpdatePath. A new member joining the group uses
these parent hashes to verify that the parent nodes in the tree were set by these parent hashes to verify that the parent nodes in the tree were set by
members of the group, not chosen by an external attacker. For an example of how members of the group, not chosen by an external attacker. For an example of how
this works, see <xref target="ph-evolution"/>.</t> this works, see <xref target="ph-evolution" format="default" sectionFormat="of"
<t>Consider a ratchet tree with a non-blank parent node P and children D derivedContent="Appendix B"/>.</t>
and S (for <t indent="0" pn="section-7.9-5">Consider a ratchet tree with a non-blan
k parent node P and children D and S (for
"parent", "direct path", and "sibling"), with D and P in the direct path of a "parent", "direct path", and "sibling"), with D and P in the direct path of a
leaf node L (for "leaf"):</t> leaf node L (for "leaf"):</t>
<figure anchor="parent-hash-nodes"> <figure anchor="parent-hash-nodes" align="left" suppress-title="false" p
<name>Nodes involved in a parent hash computation</name> n="figure-20">
<artwork type="ascii-art"><![CDATA[ <name slugifiedName="name-nodes-involved-in-a-parent-">Nodes Involved
in a Parent Hash Computation</name>
<artwork type="ascii-art" align="left" pn="section-7.9-6.1">
... ...
/ /
P P
__|__ __|__
/ \ / \
D S D S
/ \ / \ / \ / \
... ... ... ... ... ... ... ...
/ /
L L
]]></artwork> </artwork>
</figure> </figure>
<t>The parent hash of P changes whenever an <tt>UpdatePath</tt> object i s applied to <t indent="0" pn="section-7.9-7">The parent hash of P changes whenever a n UpdatePath object is applied to
the ratchet tree along a path from a leaf L traversing node D (and hence also the ratchet tree along a path from a leaf L traversing node D (and hence also
P). The new "Parent hash of P (with copath child S)" is obtained by hashing P's P). The new "Parent hash of P (with copath child S)" is obtained by hashing P's
<tt>ParentHashInput</tt> struct.</t> ParentHashInput struct.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-7.9-8">
struct { struct {
HPKEPublicKey encryption_key; HPKEPublicKey encryption_key;
opaque parent_hash<V>; opaque parent_hash&lt;V&gt;;
opaque original_sibling_tree_hash<V>; opaque original_sibling_tree_hash&lt;V&gt;;
} ParentHashInput; } ParentHashInput;
]]></sourcecode> </sourcecode>
<t>The field <tt>encryption_key</tt> contains the HPKE public key of P. <t indent="0" pn="section-7.9-9">The field <tt>encryption_key</tt> conta
If P is the root, ins the HPKE public key of P. If P is the root,
then the <tt>parent_hash</tt> field is set to a zero-length octet string. Otherw ise, then the <tt>parent_hash</tt> field is set to a zero-length octet string. Otherw ise,
<tt>parent_hash</tt> is the Parent Hash of the next node after P on the filtered <tt>parent_hash</tt> is the parent hash of the next node after P on the filtered
direct path of the leaf L. This way, P's Parent Hash fixes direct path of the leaf L. This way, P's parent hash fixes
the new HPKE public key of each non-blank node on the path from P to the root. N ote the new HPKE public key of each non-blank node on the path from P to the root. N ote
that the path from P to the root may contain some blank nodes that are not that the path from P to the root may contain some blank nodes that are not
fixed by P's Parent Hash. However, for each node that has an HPKE key, this key fixed by P's parent hash. However, for each node that has an HPKE key, this key
is fixed by P's Parent Hash.</t> is fixed by P's parent hash.</t>
<t>Finally, <tt>original_sibling_tree_hash</tt> is the tree hash of S in <t indent="0" pn="section-7.9-10">Finally, <tt>original_sibling_tree_has
the ratchet tree h</tt> is the tree hash of S in the ratchet tree
modified as follows: For each leaf L in <tt>P.unmerged_leaves</tt>, blank L and remove modified as follows: For each leaf L in <tt>P.unmerged_leaves</tt>, blank L and remove
it from the <tt>unmerged_leaves</tt> sets of all parent nodes.</t> it from the <tt>unmerged_leaves</tt> sets of all parent nodes.</t>
<t>Observe that <tt>original_sibling_tree_hash</tt> does not change betw een updates of P. <t indent="0" pn="section-7.9-11">Observe that <tt>original_sibling_tree _hash</tt> does not change between updates of P.
This property is crucial for the correctness of the protocol.</t> This property is crucial for the correctness of the protocol.</t>
<t>Note that <tt>original_sibling_tree_hash</tt> is the tree hash of S, not the parent <t indent="0" pn="section-7.9-12">Note that <tt>original_sibling_tree_ha sh</tt> is the tree hash of S, not the parent
hash. The <tt>parent_hash</tt> field in ParentHashInput captures information ab out the hash. The <tt>parent_hash</tt> field in ParentHashInput captures information ab out the
nodes above P. the <tt>original_sibling_tree_hash</tt> captures information abou t the nodes above P. the <tt>original_sibling_tree_hash</tt> captures information abou t the
subtree under S that is not being updated (and thus the subtree to which a path subtree under S that is not being updated (and thus the subtree to which a path
secret for P would be encrypted according to <xref target="synchronizing-views-o secret for P would be encrypted according to <xref target="synchronizing-views-o
f-the-tree"/>).</t> f-the-tree" format="default" sectionFormat="of" derivedContent="Section 7.5"/>).
<t>For example, in the following tree:</t> </t>
<figure anchor="parent-hash-tree"> <t indent="0" pn="section-7.9-13">For example, in the following tree:</t
<name>A tree illustrating parent hash computations.</name> >
<artwork type="ascii-art"><![CDATA[ <figure anchor="parent-hash-tree" align="left" suppress-title="false" pn
="figure-21">
<name slugifiedName="name-a-tree-illustrating-parent-">A Tree Illustra
ting Parent Hash Computations</name>
<artwork type="ascii-art" align="left" pn="section-7.9-14.1">
W [F] W [F]
______|_____ ______|_____
/ \ / \
U Y [F] U Y [F]
__|__ __|__ __|__ __|__
/ \ / \ / \ / \
T _ _ _ T _ _ _
/ \ / \ / \ / \ / \ / \ / \ / \
A B C D E F G _ A B C D E F G _
]]></artwork> </artwork>
</figure> </figure>
<t>With P = W and S = Y, <tt>original_sibling_tree_hash</tt> is the tree hash of the <t indent="0" pn="section-7.9-15">With P = W and S = Y, <tt>original_sib ling_tree_hash</tt> is the tree hash of the
following tree:</t> following tree:</t>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-7.9-16">
Y Y
__|__ __|__
/ \ / \
_ _ _ _
/ \ / \ / \ / \
E _ G _ E _ G _
]]></artwork> </artwork>
<t>Because <tt>W.unmerged_leaves</tt> includes F, F is blanked and remov <t indent="0" pn="section-7.9-17">Because <tt>W.unmerged_leaves</tt> inc
ed from ludes F, F is blanked and removed from
<tt>Y.unmerged_leaves</tt>.</t> <tt>Y.unmerged_leaves</tt>.</t>
<t>Note that no recomputation is needed if the tree hash of S is unchang ed since <t indent="0" pn="section-7.9-18">Note that no recomputation is needed i f the tree hash of S is unchanged since
the last time P was updated. This is the case for computing or processing a the last time P was updated. This is the case for computing or processing a
Commit whose UpdatePath traverses P, since the Commit itself resets P. (In Commit whose UpdatePath traverses P, since the Commit itself resets P. (In
other words, it is only necessary to recompute the original sibling tree hash other words, it is only necessary to recompute the original sibling tree hash
when validating a group's tree on joining.) More generally, if none of the entri es when validating a group's tree on joining.) More generally, if none of the entri es
in <tt>P.unmerged_leaves</tt> is in the subtree under S (and thus no leaves were blanked), in <tt>P.unmerged_leaves</tt> are in the subtree under S (and thus no leaves wer e blanked),
then the original tree hash at S is the tree hash of S in the current tree.</t> then the original tree hash at S is the tree hash of S in the current tree.</t>
<t>If it is necessary to recompute the original tree hash of a node, the efficiency <t indent="0" pn="section-7.9-19">If it is necessary to recompute the or iginal tree hash of a node, the efficiency
of recomputation can be improved by caching intermediate tree hashes, to avoid of recomputation can be improved by caching intermediate tree hashes, to avoid
recomputing over the subtree when the subtree is included in multiple parent recomputing over the subtree when the subtree is included in multiple parent
hashes. A subtree hash can be reused as long as the intersection of the hashes. A subtree hash can be reused as long as the intersection of the
parent's unmerged leaves with the subtree is the same as in the earlier parent's unmerged leaves with the subtree is the same as in the earlier
computation.</t> computation.</t>
<section anchor="using-parent-hashes"> <section anchor="using-parent-hashes" numbered="true" removeInRFC="false
<name>Using Parent Hashes</name> " toc="include" pn="section-7.9.1">
<t>In ParentNode objects and LeafNode objects with <tt>leaf_node_sourc <name slugifiedName="name-using-parent-hashes">Using Parent Hashes</na
e</tt> set to me>
<t indent="0" pn="section-7.9.1-1">In ParentNode objects and LeafNode
objects with <tt>leaf_node_source</tt> set to
<tt>commit</tt>, the value of the <tt>parent_hash</tt> field is the parent hash of the next <tt>commit</tt>, the value of the <tt>parent_hash</tt> field is the parent hash of the next
non-blank parent node above the node in question (the next node in the filtered non-blank parent node above the node in question (the next node in the filtered
direct path). Using the node labels in <xref target="parent-hash-nodes"/>, the direct path). Using the node labels in <xref target="parent-hash-nodes" format= "default" sectionFormat="of" derivedContent="Figure 20"/>, the
<tt>parent_hash</tt> field of D is equal to the parent hash of P with copath chi ld S. <tt>parent_hash</tt> field of D is equal to the parent hash of P with copath chi ld S.
This is the case even when the node D is a leaf node.</t> This is the case even when the node D is a leaf node.</t>
<t>The <tt>parent_hash</tt> field of a LeafNode is signed by the membe <t indent="0" pn="section-7.9.1-2">The <tt>parent_hash</tt> field of a
r. The signature of LeafNode is signed by the member. The signature of
such a LeafNode thus also attests to which keys the group member introduced into such a LeafNode thus attests to which keys the group member introduced into
the ratchet tree and to whom the corresponding secret keys were sent. This the ratchet tree and to whom the corresponding secret keys were sent, in
addition to the other contents of the LeafNode. This
prevents malicious insiders from constructing artificial ratchet trees with a prevents malicious insiders from constructing artificial ratchet trees with a
node D whose HPKE secret key is known to the insider yet where the insider isn't node D whose HPKE secret key is known to the insider, yet where the insider isn' t
assigned a leaf in the subtree rooted at D. Indeed, such a ratchet tree would assigned a leaf in the subtree rooted at D. Indeed, such a ratchet tree would
violate the tree invariant.</t> violate the tree invariant.</t>
</section> </section>
<section anchor="verifying-parent-hashes"> <section anchor="verifying-parent-hashes" numbered="true" removeInRFC="f
<name>Verifying Parent Hashes</name> alse" toc="include" pn="section-7.9.2">
<t>Parent hashes are verified at two points in the protocol: When join <name slugifiedName="name-verifying-parent-hashes">Verifying Parent Ha
ing a group shes</name>
<t indent="0" pn="section-7.9.2-1">Parent hashes are verified at two p
oints in the protocol: When joining a group
and when processing a Commit.</t> and when processing a Commit.</t>
<t>The parent hash in a node D is valid with respect to a parent node P if the <t indent="0" pn="section-7.9.2-2">The parent hash in a node D is vali d with respect to a parent node P if the
following criteria hold. Here C and S are the children of P (for "child" and following criteria hold. Here C and S are the children of P (for "child" and
"sibling"), with C being the child that is on the direct path of D (possibly D "sibling"), with C being the child that is on the direct path of D (possibly D
itself) and S the other child:</t> itself) and S being the other child:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>D is a descendant of P in the tree.</li> -7.9.2-3">
<li>The <tt>parent_hash</tt> field of D is equal to the parent hash <li pn="section-7.9.2-3.1">D is a descendant of P in the tree.</li>
of P with copath <li pn="section-7.9.2-3.2">The <tt>parent_hash</tt> field of D is eq
ual to the parent hash of P with copath
child S.</li> child S.</li>
<li>D is in the resolution of C, and the intersection of P's <tt>unm erged_leaves</tt> <li pn="section-7.9.2-3.3">D is in the resolution of C, and the inte rsection of P's <tt>unmerged_leaves</tt>
with the subtree under C is equal to the resolution of C with D removed.</li> with the subtree under C is equal to the resolution of C with D removed.</li>
</ul> </ul>
<t>These checks verify that D and P were updated at the same time (in the same <t indent="0" pn="section-7.9.2-4">These checks verify that D and P we re updated at the same time (in the same
UpdatePath), and that they were neighbors in the UpdatePath because the nodes in UpdatePath), and that they were neighbors in the UpdatePath because the nodes in
between them would have omitted from the filtered direct path.</t> between them would have omitted from the filtered direct path.</t>
<t>A parent node P is "parent-hash valid" if it can be chained back to a leaf node <t indent="0" pn="section-7.9.2-5">A parent node P is "parent-hash val id" if it can be chained back to a leaf node
in this way. That is, if there is leaf node L and a sequence of parent nodes in this way. That is, if there is leaf node L and a sequence of parent nodes
P_1, ..., P_N such that P_N = P and each step in the chain is authenticated P_1, ..., P_N such that P_N = P and each step in the chain is authenticated
by a parent hash: L's parent hash is valid with respect to P_1, P_1's parent by a parent hash, then L's parent hash is valid with respect to P_1, P_1's paren t
hash is valid with respect to P_2, and so on.</t> hash is valid with respect to P_2, and so on.</t>
<t>When joining a group, the new member MUST authenticate that each no n-blank <t indent="0" pn="section-7.9.2-6">When joining a group, the new membe r <bcp14>MUST</bcp14> authenticate that each non-blank
parent node P is parent-hash valid. This can be done "bottom up" by building parent node P is parent-hash valid. This can be done "bottom up" by building
chains up from leaves and verifying that all non-blank parent nodes are covered chains up from leaves and verifying that all non-blank parent nodes are covered
by exactly one such chain, or "top down" by verifying that there is exactly one by exactly one such chain, or "top down" by verifying that there is exactly one
descendant of each non-blank parent node for which the parent node is descendant of each non-blank parent node for which the parent node is
parent-hash valid.</t> parent-hash valid.</t>
<t>When processing a Commit message that includes an UpdatePath, clien ts MUST <t indent="0" pn="section-7.9.2-7">When processing a Commit message th at includes an UpdatePath, clients <bcp14>MUST</bcp14>
recompute the expected value of <tt>parent_hash</tt> for the committer's new lea f and recompute the expected value of <tt>parent_hash</tt> for the committer's new lea f and
verify that it matches the <tt>parent_hash</tt> value in the supplied <tt>leaf_n ode</tt>. verify that it matches the <tt>parent_hash</tt> value in the supplied <tt>leaf_n ode</tt>.
After being merged into the tree, the nodes in the UpdatePath form a parent-hash After being merged into the tree, the nodes in the UpdatePath form a parent-hash
chain from the committer's leaf to the root.</t> chain from the committer's leaf to the root.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="key-schedule"> <section anchor="key-schedule" numbered="true" removeInRFC="false" toc="incl
<name>Key Schedule</name> ude" pn="section-8">
<t>Group keys are derived using the <tt>Extract</tt> and <tt>Expand</tt> f <name slugifiedName="name-key-schedule">Key Schedule</name>
unctions from the KDF <t indent="0" pn="section-8-1">Group keys are derived using the <tt>Extrac
for the group's ciphersuite, as well as the functions defined below:</t> t</tt> and <tt>Expand</tt> functions from the KDF
<sourcecode type="pseudocode"><![CDATA[ for the group's cipher suite, as well as the functions defined below:</t>
<sourcecode type="pseudocode" markers="false" pn="section-8-2">
ExpandWithLabel(Secret, Label, Context, Length) = ExpandWithLabel(Secret, Label, Context, Length) =
KDF.Expand(Secret, KDFLabel, Length) KDF.Expand(Secret, KDFLabel, Length)
DeriveSecret(Secret, Label) = DeriveSecret(Secret, Label) =
ExpandWithLabel(Secret, Label, "", KDF.Nh) ExpandWithLabel(Secret, Label, "", KDF.Nh)
]]></sourcecode> </sourcecode>
<t>Where KDFLabel is specified as:</t> <t indent="0" pn="section-8-3">Where KDFLabel is specified as:</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-8-4">
struct { struct {
uint16 length; uint16 length;
opaque label<V>; opaque label&lt;V&gt;;
opaque context<V>; opaque context&lt;V&gt;;
} KDFLabel; } KDFLabel;
]]></sourcecode> </sourcecode>
<t>And its fields set to:</t> <t indent="0" pn="section-8-5">And its fields are set to:</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-8-6">
length = Length; length = Length;
label = "MLS 1.0 " + Label; label = "MLS 1.0 " + Label;
context = Context; context = Context;
]]></sourcecode> </sourcecode>
<t>The value <tt>KDF.Nh</tt> is the size of an output from <tt>KDF.Extract <t indent="0" pn="section-8-7">The value <tt>KDF.Nh</tt> is the size of an
</tt>, in bytes. In output from <tt>KDF.Extract</tt>, in bytes. In
the below diagram:</t> the below diagram:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-8
<li>KDF.Extract takes its salt argument from the top and its Input ">
Key Material (IKM) argument from the left</li> <li pn="section-8-8.1">KDF.Extract takes its salt argument from the top
<li>DeriveSecret takes its Secret argument from the incoming arrow</li> and its Input
<li> Keying Material (IKM) argument from the left.</li>
<li pn="section-8-8.2">DeriveSecret takes its Secret argument from the i
ncoming arrow.</li>
<li pn="section-8-8.3">
<tt>0</tt> represents an all-zero byte string of length <tt>KDF.Nh</tt >.</li> <tt>0</tt> represents an all-zero byte string of length <tt>KDF.Nh</tt >.</li>
</ul> </ul>
<t>When processing a handshake message, a client combines the <t indent="0" pn="section-8-9">When processing a handshake message, a clie nt combines the
following information to derive new epoch secrets:</t> following information to derive new epoch secrets:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-1
<li>The init secret from the previous epoch</li> 0">
<li>The commit secret for the current epoch</li> <li pn="section-8-10.1">The init secret from the previous epoch</li>
<li>The GroupContext object for current epoch</li> <li pn="section-8-10.2">The commit secret for the current epoch</li>
<li pn="section-8-10.3">The GroupContext object for current epoch</li>
</ul> </ul>
<t>Given these inputs, the derivation of secrets for an epoch <t indent="0" pn="section-8-11">Given these inputs, the derivation of secr ets for an epoch
proceeds as shown in the following diagram:</t> proceeds as shown in the following diagram:</t>
<figure> <figure align="left" suppress-title="false" pn="figure-22">
<name>The MLS key schedule</name> <name slugifiedName="name-the-mls-key-schedule">The MLS Key Schedule</na
<artset> me>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 <artset pn="section-8-12.1">
.1" height="656" width="584" viewBox="0 0 584 656" class="diagram" text-anchor=" <artwork type="svg" align="left" pn="section-8-12.1.1">
middle" font-family="monospace" font-size="13px"> <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-family=
"monospace" font-size="13px" height="656" text-anchor="middle" version="1.1" vie
wBox="0 0 584 656" width="584">
<path d="M 216,48 L 216,80" fill="none" stroke="black"/> <path d="M 216,48 L 216,80" fill="none" stroke="black"/>
<path d="M 216,112 L 216,144" fill="none" stroke="black"/> <path d="M 216,112 L 216,144" fill="none" stroke="black"/>
<path d="M 216,176 L 216,208" fill="none" stroke="black"/> <path d="M 216,176 L 216,208" fill="none" stroke="black"/>
<path d="M 216,232 L 216,272" fill="none" stroke="black"/> <path d="M 216,232 L 216,272" fill="none" stroke="black"/>
<path d="M 216,304 L 216,384" fill="none" stroke="black"/> <path d="M 216,304 L 216,384" fill="none" stroke="black"/>
<path d="M 216,416 L 216,448" fill="none" stroke="black"/> <path d="M 216,416 L 216,448" fill="none" stroke="black"/>
<path d="M 216,472 L 216,560" fill="none" stroke="black"/> <path d="M 216,472 L 216,560" fill="none" stroke="black"/>
<path d="M 216,592 L 216,624" fill="none" stroke="black"/> <path d="M 216,592 L 216,624" fill="none" stroke="black"/>
<path d="M 152,96 L 168,96" fill="none" stroke="black"/> <path d="M 152,96 L 168,96" fill="none" stroke="black"/>
<path d="M 152,288 L 168,288" fill="none" stroke="black"/> <path d="M 152,288 L 168,288" fill="none" stroke="black"/>
<path d="M 216,336 L 240,336" fill="none" stroke="black"/> <path d="M 216,336 L 240,336" fill="none" stroke="black"/>
<path d="M 216,512 L 240,512" fill="none" stroke="black"/> <path d="M 216,512 L 240,512" fill="none" stroke="black"/>
<polygon class="arrowhead" points="248,512 236,506.4 236,517.6" fi <polygon class="arrowhead" fill="black" points="248,512 236,506.4
ll="black" transform="rotate(0,240,512)"/> 236,517.6" transform="rotate(0,240,512)"/>
<polygon class="arrowhead" points="248,336 236,330.4 236,341.6" fi <polygon class="arrowhead" fill="black" points="248,336 236,330.4
ll="black" transform="rotate(0,240,336)"/> 236,341.6" transform="rotate(0,240,336)"/>
<polygon class="arrowhead" points="224,624 212,618.4 212,629.6" fi <polygon class="arrowhead" fill="black" points="224,624 212,618.4
ll="black" transform="rotate(90,216,624)"/> 212,629.6" transform="rotate(90,216,624)"/>
<polygon class="arrowhead" points="224,560 212,554.4 212,565.6" fi <polygon class="arrowhead" fill="black" points="224,560 212,554.4
ll="black" transform="rotate(90,216,560)"/> 212,565.6" transform="rotate(90,216,560)"/>
<polygon class="arrowhead" points="224,448 212,442.4 212,453.6" fi <polygon class="arrowhead" fill="black" points="224,448 212,442.4
ll="black" transform="rotate(90,216,448)"/> 212,453.6" transform="rotate(90,216,448)"/>
<polygon class="arrowhead" points="224,384 212,378.4 212,389.6" fi <polygon class="arrowhead" fill="black" points="224,384 212,378.4
ll="black" transform="rotate(90,216,384)"/> 212,389.6" transform="rotate(90,216,384)"/>
<polygon class="arrowhead" points="224,272 212,266.4 212,277.6" fi <polygon class="arrowhead" fill="black" points="224,272 212,266.4
ll="black" transform="rotate(90,216,272)"/> 212,277.6" transform="rotate(90,216,272)"/>
<polygon class="arrowhead" points="224,208 212,202.4 212,213.6" fi <polygon class="arrowhead" fill="black" points="224,208 212,202.4
ll="black" transform="rotate(90,216,208)"/> 212,213.6" transform="rotate(90,216,208)"/>
<polygon class="arrowhead" points="224,144 212,138.4 212,149.6" fi <polygon class="arrowhead" fill="black" points="224,144 212,138.4
ll="black" transform="rotate(90,216,144)"/> 212,149.6" transform="rotate(90,216,144)"/>
<polygon class="arrowhead" points="224,80 212,74.4 212,85.6" fill= <polygon class="arrowhead" fill="black" points="224,80 212,74.4 21
"black" transform="rotate(90,216,80)"/> 2,85.6" transform="rotate(90,216,80)"/>
<polygon class="arrowhead" points="176,288 164,282.4 164,293.6" fi <polygon class="arrowhead" fill="black" points="176,288 164,282.4
ll="black" transform="rotate(0,168,288)"/> 164,293.6" transform="rotate(0,168,288)"/>
<polygon class="arrowhead" points="176,96 164,90.4 164,101.6" fill <polygon class="arrowhead" fill="black" points="176,96 164,90.4 16
="black" transform="rotate(0,168,96)"/> 4,101.6" transform="rotate(0,168,96)"/>
<g class="text"> <g class="text">
<text x="232" y="36">init_secret_[n-1]</text> <text x="232" y="36">init_secret_[n-1]</text>
<text x="88" y="100">commit_secret</text> <text x="88" y="100">commit_secret</text>
<text x="224" y="100">KDF.Extract</text> <text x="224" y="100">KDF.Extract</text>
<text x="220" y="164">ExpandWithLabel(.,</text> <text x="220" y="164">ExpandWithLabel(.,</text>
<text x="336" y="164">"joiner",</text> <text x="336" y="164">"joiner",</text>
<text x="448" y="164">GroupContext_[n],</text> <text x="448" y="164">GroupContext_[n],</text>
<text x="552" y="164">KDF.Nh)</text> <text x="552" y="164">KDF.Nh)</text>
<text x="224" y="228">joiner_secret</text> <text x="224" y="228">joiner_secret</text>
<text x="44" y="292">psk_secret</text> <text x="44" y="292">psk_secret</text>
skipping to change at line 3402 skipping to change at line 3627
<text x="312" y="516">DeriveSecret(.,</text> <text x="312" y="516">DeriveSecret(.,</text>
<text x="412" y="516">&lt;label&gt;)</text> <text x="412" y="516">&lt;label&gt;)</text>
<text x="256" y="532">=</text> <text x="256" y="532">=</text>
<text x="300" y="532">&lt;secret&gt;</text> <text x="300" y="532">&lt;secret&gt;</text>
<text x="224" y="580">DeriveSecret(.,</text> <text x="224" y="580">DeriveSecret(.,</text>
<text x="320" y="580">"init")</text> <text x="320" y="580">"init")</text>
<text x="224" y="644">init_secret_[n]</text> <text x="224" y="644">init_secret_[n]</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-8-12.1.2">
init_secret_[n-1] init_secret_[n-1]
| |
| |
V V
commit_secret --> KDF.Extract commit_secret --&gt; KDF.Extract
| |
| |
V V
ExpandWithLabel(., "joiner", GroupContext_[n], KDF.Nh) ExpandWithLabel(., "joiner", GroupContext_[n], KDF.Nh)
| |
| |
V V
joiner_secret joiner_secret
| |
| |
V V
psk_secret (or 0) --> KDF.Extract psk_secret (or 0) --&gt; KDF.Extract
| |
| |
+--> DeriveSecret(., "welcome") +--&gt; DeriveSecret(., "welcome")
| = welcome_secret | = welcome_secret
| |
V V
ExpandWithLabel(., "epoch", GroupContext_[n], KDF.Nh) ExpandWithLabel(., "epoch", GroupContext_[n], KDF.Nh)
| |
| |
V V
epoch_secret epoch_secret
| |
| |
+--> DeriveSecret(., <label>) +--&gt; DeriveSecret(., &lt;label&gt;)
| = <secret> | = &lt;secret&gt;
| |
V V
DeriveSecret(., "init") DeriveSecret(., "init")
| |
| |
V V
init_secret_[n] init_secret_[n]
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>A number of values are derived from the epoch secret for different purp <t indent="0" pn="section-8-13">A number of values are derived from the ep
oses:</t> och secret for different purposes:</t>
<table anchor="epoch-derived-secrets"> <table anchor="epoch-derived-secrets" align="center" pn="table-4">
<name>Epoch-derived secrets</name> <name slugifiedName="name-epoch-derived-secrets">Epoch-Derived Secrets</
name>
<thead> <thead>
<tr> <tr>
<th align="left">Label</th> <th align="left" colspan="1" rowspan="1">Label</th>
<th align="left">Secret</th> <th align="left" colspan="1" rowspan="1">Secret</th>
<th align="left">Purpose</th> <th align="left" colspan="1" rowspan="1">Purpose</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">"sender data"</td> <td align="left" colspan="1" rowspan="1">"sender data"</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>sender_data_secret</tt></td> <tt>sender_data_secret</tt>
<td align="left">Deriving keys to encrypt sender data</td> </td>
<td align="left" colspan="1" rowspan="1">Deriving keys to encrypt se
nder data</td>
</tr> </tr>
<tr> <tr>
<td align="left">"encryption"</td> <td align="left" colspan="1" rowspan="1">"encryption"</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>encryption_secret</tt></td> <tt>encryption_secret</tt>
<td align="left">Deriving message encryption keys (via the secret tr </td>
ee)</td> <td align="left" colspan="1" rowspan="1">Deriving message encryption
keys (via the secret tree)</td>
</tr> </tr>
<tr> <tr>
<td align="left">"exporter"</td> <td align="left" colspan="1" rowspan="1">"exporter"</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>exporter_secret</tt></td> <tt>exporter_secret</tt>
<td align="left">Deriving exported secrets</td> </td>
<td align="left" colspan="1" rowspan="1">Deriving exported secrets</
td>
</tr> </tr>
<tr> <tr>
<td align="left">"external"</td> <td align="left" colspan="1" rowspan="1">"external"</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>external_secret</tt></td> <tt>external_secret</tt>
<td align="left">Deriving the external init key</td> </td>
<td align="left" colspan="1" rowspan="1">Deriving the external init
key</td>
</tr> </tr>
<tr> <tr>
<td align="left">"confirm"</td> <td align="left" colspan="1" rowspan="1">"confirm"</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>confirmation_key</tt></td> <tt>confirmation_key</tt>
<td align="left">Computing the confirmation MAC for an epoch</td> </td>
<td align="left" colspan="1" rowspan="1">Computing the confirmation
MAC for an epoch</td>
</tr> </tr>
<tr> <tr>
<td align="left">"membership"</td> <td align="left" colspan="1" rowspan="1">"membership"</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>membership_key</tt></td> <tt>membership_key</tt>
<td align="left">Computing the membership MAC for an PublicMessage</ </td>
td> <td align="left" colspan="1" rowspan="1">Computing the membership MA
C for a PublicMessage</td>
</tr> </tr>
<tr> <tr>
<td align="left">"resumption"</td> <td align="left" colspan="1" rowspan="1">"resumption"</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>resumption_psk</tt></td> <tt>resumption_psk</tt>
<td align="left">Proving membership in this epoch (via a PSK injecte </td>
d later)</td> <td align="left" colspan="1" rowspan="1">Proving membership in this
epoch (via a PSK injected later)</td>
</tr> </tr>
<tr> <tr>
<td align="left">"authentication"</td> <td align="left" colspan="1" rowspan="1">"authentication"</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>epoch_authenticator</tt></td> <tt>epoch_authenticator</tt>
<td align="left">Confirming that two clients have the same view of t </td>
he group</td> <td align="left" colspan="1" rowspan="1">Confirming that two clients
have the same view of the group</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The <tt>external_secret</tt> is used to derive an HPKE key pair whose p rivate key is <t indent="0" pn="section-8-15">The <tt>external_secret</tt> is used to de rive an HPKE key pair whose private key is
held by the entire group:</t> held by the entire group:</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-8-16">
external_priv, external_pub = KEM.DeriveKeyPair(external_secret) external_priv, external_pub = KEM.DeriveKeyPair(external_secret)
]]></sourcecode> </sourcecode>
<t>The public key <tt>external_pub</tt> can be published as part of the Gr <t indent="0" pn="section-8-17">The public key <tt>external_pub</tt> can b
oupInfo struct e published as part of the GroupInfo struct
in order to allow non-members to join the group using an external commit.</t> in order to allow non-members to join the group using an external Commit.</t>
<section anchor="group-context"> <section anchor="group-context" numbered="true" removeInRFC="false" toc="i
<name>Group Context</name> nclude" pn="section-8.1">
<t>Each member of the group maintains a GroupContext object that <name slugifiedName="name-group-context">Group Context</name>
<t indent="0" pn="section-8.1-1">Each member of the group maintains a Gr
oupContext object that
summarizes the state of the group:</t> summarizes the state of the group:</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-8.1-2">
struct { struct {
ProtocolVersion version = mls10; ProtocolVersion version = mls10;
CipherSuite cipher_suite; CipherSuite cipher_suite;
opaque group_id<V&gt;; opaque group_id<V&gt;;
uint64 epoch; uint64 epoch;
opaque tree_hash<V>; opaque tree_hash&lt;V&gt;;
opaque confirmed_transcript_hash<V>; opaque confirmed_transcript_hash&lt;V&gt;;
Extension extensions<V>; Extension extensions&lt;V&gt;;
} GroupContext; } GroupContext;
]]></sourcecode> </sourcecode>
<t>The fields in this state have the following semantics:</t> <t indent="0" pn="section-8.1-3">The fields in this state have the follo
<ul spacing="normal"> wing semantics:</t>
<li>The <tt>cipher_suite</tt> is the cipher suite used by the group.</ <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8
li> .1-4">
<li>The <tt>group_id</tt> field is an application-defined identifier f <li pn="section-8.1-4.1">The <tt>cipher_suite</tt> is the cipher suite
or the used by the group.</li>
<li pn="section-8.1-4.2">The <tt>group_id</tt> field is an application
-defined identifier for the
group.</li> group.</li>
<li>The <tt>epoch</tt> field represents the current version of the gro <li pn="section-8.1-4.3">The <tt>epoch</tt> field represents the curre
up.</li> nt version of the group.</li>
<li>The <tt>tree_hash</tt> field contains a commitment to the contents <li pn="section-8.1-4.4">The <tt>tree_hash</tt> field contains a commi
of the tment to the contents of the
group's ratchet tree and the credentials for the members of the group's ratchet tree and the credentials for the members of the
group, as described in <xref target="tree-hashes"/>.</li> group, as described in <xref target="tree-hashes" format="default" sectionFormat
<li>The <tt>confirmed_transcript_hash</tt> field contains a running ha ="of" derivedContent="Section 7.8"/>.</li>
sh over <li pn="section-8.1-4.5">The <tt>confirmed_transcript_hash</tt> field
contains a running hash over
the messages that led to this state.</li> the messages that led to this state.</li>
<li>The <tt>extensions</tt> field contains the details of any protocol extensions that <li pn="section-8.1-4.6">The <tt>extensions</tt> field contains the de tails of any protocol extensions that
apply to the group.</li> apply to the group.</li>
</ul> </ul>
<t>When a new member is added to the group, an existing member of the <t indent="0" pn="section-8.1-5">When a new member is added to the group , an existing member of the
group provides the new member with a Welcome message. The Welcome group provides the new member with a Welcome message. The Welcome
message provides the information the new member needs to initialize message provides the information the new member needs to initialize
its GroupContext.</t> its GroupContext.</t>
<t>Different changes to the group will have different effects on the gro <t indent="0" pn="section-8.1-6">Different changes to the group will hav
up state. e different effects on the group state.
These effects are described in their respective subsections of <xref target="pro These effects are described in their respective subsections of <xref target="pro
posals"/>. posals" format="default" sectionFormat="of" derivedContent="Section 12.1"/>.
The following general rules apply:</t> The following general rules apply:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8
<li>The <tt>group_id</tt> field is constant.</li> .1-7">
<li>The <tt>epoch</tt> field increments by one for each Commit message <li pn="section-8.1-7.1">The <tt>group_id</tt> field is constant.</li>
that <li pn="section-8.1-7.2">The <tt>epoch</tt> field increments by one fo
r each Commit message that
is processed.</li> is processed.</li>
<li>The <tt>tree_hash</tt> is updated to represent the current tree an d <li pn="section-8.1-7.3">The <tt>tree_hash</tt> is updated to represen t the current tree and
credentials.</li> credentials.</li>
<li>The <tt>confirmed_transcript_hash</tt> field is updated with the d <li pn="section-8.1-7.4">The <tt>confirmed_transcript_hash</tt> field
ata for an is updated with the data for an
AuthenticatedContent encoding a Commit message as described below.</li> AuthenticatedContent encoding a Commit message, as described below.</li>
<li>The <tt>extensions</tt> field changes when a GroupContextExtension <li pn="section-8.1-7.5">The <tt>extensions</tt> field changes when a
s proposal is GroupContextExtensions proposal is
committed.</li> committed.</li>
</ul> </ul>
</section> </section>
<section anchor="transcript-hashes"> <section anchor="transcript-hashes" numbered="true" removeInRFC="false" to
<name>Transcript Hashes</name> c="include" pn="section-8.2">
<t>The transcript hashes computed in MLS represent a running hash over a <name slugifiedName="name-transcript-hashes">Transcript Hashes</name>
ll Proposal <t indent="0" pn="section-8.2-1">The transcript hashes computed in MLS r
epresent a running hash over all Proposal
and Commit messages that have ever been sent in a group. Commit messages are and Commit messages that have ever been sent in a group. Commit messages are
included directly. Proposal messages are indirectly included via the Commit that included directly. Proposal messages are indirectly included via the Commit that
applied them. Both types of message are included by hashing the AuthenticatedCon tent applied them. Messages of both types are included by hashing the AuthenticatedCo ntent
object in which they were sent.</t> object in which they were sent.</t>
<t>The transcript hash comprises two individual hashes:</t> <t indent="0" pn="section-8.2-2">The transcript hash comprises two indiv
<ul spacing="normal"> idual hashes:</t>
<li>A <tt>confirmed_transcript_hash</tt> that represents a transcript <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8
over the whole .2-3">
<li pn="section-8.2-3.1">A <tt>confirmed_transcript_hash</tt> that rep
resents a transcript over the whole
history of Commit messages, up to and including the signature of the most history of Commit messages, up to and including the signature of the most
recent Commit.</li> recent Commit.</li>
<li>An <tt>interim_transcript_hash</tt> that covers the confirmed tran script hash plus <li pn="section-8.2-3.2">An <tt>interim_transcript_hash</tt> that cove rs the confirmed transcript hash plus
the <tt>confirmation_tag</tt> of the most recent Commit.</li> the <tt>confirmation_tag</tt> of the most recent Commit.</li>
</ul> </ul>
<t>New members compute the interim transcript hash using the <tt>confirm ation_tag</tt> <t indent="0" pn="section-8.2-4">New members compute the interim transcr ipt hash using the <tt>confirmation_tag</tt>
field of the GroupInfo struct, while existing members can compute it directly.</ t> field of the GroupInfo struct, while existing members can compute it directly.</ t>
<t>Each Commit message updates these hashes by way of its enclosing <t indent="0" pn="section-8.2-5">Each Commit message updates these hashe s by way of its enclosing
AuthenticatedContent. The AuthenticatedContent struct is split into AuthenticatedContent. The AuthenticatedContent struct is split into
ConfirmedTranscriptHashInput and InterimTranscriptHashInput. The former is used to ConfirmedTranscriptHashInput and InterimTranscriptHashInput. The former is used to
update the confirmed transcript hash and the latter to update the interim update the confirmed transcript hash and the latter is used to update the interi m
transcript hash.</t> transcript hash.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-8.2-6">
struct { struct {
WireFormat wire_format; WireFormat wire_format;
FramedContent content; /* with content_type == commit */ FramedContent content; /* with content_type == commit */
opaque signature<V&gt;; opaque signature<V&gt;;
} ConfirmedTranscriptHashInput; } ConfirmedTranscriptHashInput;
struct { struct {
MAC confirmation_tag; MAC confirmation_tag;
} InterimTranscriptHashInput; } InterimTranscriptHashInput;
]]></sourcecode> </sourcecode>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-8.2-7">
confirmed_transcript_hash_[0] = ""; /* zero-length octet string */ confirmed_transcript_hash_[0] = ""; /* zero-length octet string */
interim_transcript_hash_[0] = ""; /* zero-length octet string */ interim_transcript_hash_[0] = ""; /* zero-length octet string */
confirmed_transcript_hash_[epoch] = confirmed_transcript_hash_[epoch] =
Hash(interim_transcript_hash_[epoch - 1] || Hash(interim_transcript_hash_[epoch - 1] ||
ConfirmedTranscriptHashInput_[epoch]); ConfirmedTranscriptHashInput_[epoch]);
interim_transcript_hash_[epoch] = interim_transcript_hash_[epoch] =
Hash(confirmed_transcript_hash_[epoch] || Hash(confirmed_transcript_hash_[epoch] ||
InterimTranscriptHashInput_[epoch]); InterimTranscriptHashInput_[epoch]);
]]></sourcecode> </sourcecode>
<t>In this notation, <tt>ConfirmedTranscriptHashInput_[epoch]</tt> and <t indent="0" pn="section-8.2-8">In this notation, <tt>ConfirmedTranscri
ptHashInput_[epoch]</tt> and
<tt>InterimTranscriptHashInput_[epoch]</tt> are based on the Commit that initiat ed the <tt>InterimTranscriptHashInput_[epoch]</tt> are based on the Commit that initiat ed the
epoch with epoch number <tt>epoch. (Note that the </tt>epoch<tt> field in this epoch with epoch number <tt>epoch. (Note that the </tt>epoch<tt> field in this
Commit will be set to </tt>epoch - 1`, since it is sent within the previous epoc h.)</t> Commit will be set to </tt>epoch - 1`, since it is sent within the previous epoc h.)</t>
<t>The transcript hash <tt>ConfirmedTranscriptHashInput_[epoch]</tt> is used as the <t indent="0" pn="section-8.2-9">The transcript hash <tt>ConfirmedTransc riptHashInput_[epoch]</tt> is used as the
<tt>confirmed_transcript_hash</tt> input to the <tt>confirmation_tag</tt> field for this <tt>confirmed_transcript_hash</tt> input to the <tt>confirmation_tag</tt> field for this
Commit. Each Commit thus confirms the whole transcript of Commits up to that Commit. Each Commit thus confirms the whole transcript of Commits up to that
point, except for the latest Commit's confirmation tag.</t> point, except for the latest Commit's confirmation tag.</t>
<figure> <figure align="left" suppress-title="false" pn="figure-23">
<name>Evolution of the transcript hashes through two epoch changes</na <name slugifiedName="name-evolution-of-the-transcript">Evolution of th
me> e Transcript Hashes through Two Epoch Changes</name>
<artset> <artset pn="section-8.2-10.1">
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= <artwork type="svg" align="left" pn="section-8.2-10.1.1">
"1.1" height="720" width="576" viewBox="0 0 576 720" class="diagram" text-anchor <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-famil
="middle" font-family="monospace" font-size="13px"> y="monospace" font-size="13px" height="720" text-anchor="middle" version="1.1" v
iewBox="0 0 576 720" width="576">
<path d="M 8,272 L 8,304" fill="none" stroke="black"/> <path d="M 8,272 L 8,304" fill="none" stroke="black"/>
<path d="M 8,512 L 8,544" fill="none" stroke="black"/> <path d="M 8,512 L 8,544" fill="none" stroke="black"/>
<path d="M 32,192 L 32,208" fill="none" stroke="black"/> <path d="M 32,192 L 32,208" fill="none" stroke="black"/>
<path d="M 32,432 L 32,448" fill="none" stroke="black"/> <path d="M 32,432 L 32,448" fill="none" stroke="black"/>
<path d="M 104,224 L 104,264" fill="none" stroke="black"/> <path d="M 104,224 L 104,264" fill="none" stroke="black"/>
<path d="M 104,464 L 104,504" fill="none" stroke="black"/> <path d="M 104,464 L 104,504" fill="none" stroke="black"/>
<path d="M 168,192 L 168,208" fill="none" stroke="black"/> <path d="M 168,192 L 168,208" fill="none" stroke="black"/>
<path d="M 168,432 L 168,448" fill="none" stroke="black"/> <path d="M 168,432 L 168,448" fill="none" stroke="black"/>
<path d="M 208,272 L 208,304" fill="none" stroke="black"/> <path d="M 208,272 L 208,304" fill="none" stroke="black"/>
<path d="M 208,512 L 208,544" fill="none" stroke="black"/> <path d="M 208,512 L 208,544" fill="none" stroke="black"/>
skipping to change at line 3692 skipping to change at line 3926
<path d="M 312,608 L 416,608" fill="none" stroke="black"/> <path d="M 312,608 L 416,608" fill="none" stroke="black"/>
<path d="M 424,624 L 568,624" fill="none" stroke="black"/> <path d="M 424,624 L 568,624" fill="none" stroke="black"/>
<path d="M 48,176 C 39.16936,176 32,183.16936 32,192" fill="none " stroke="black"/> <path d="M 48,176 C 39.16936,176 32,183.16936 32,192" fill="none " stroke="black"/>
<path d="M 152,176 C 160.83064,176 168,183.16936 168,192" fill=" none" stroke="black"/> <path d="M 152,176 C 160.83064,176 168,183.16936 168,192" fill=" none" stroke="black"/>
<path d="M 48,224 C 39.16936,224 32,216.83064 32,208" fill="none " stroke="black"/> <path d="M 48,224 C 39.16936,224 32,216.83064 32,208" fill="none " stroke="black"/>
<path d="M 152,224 C 160.83064,224 168,216.83064 168,208" fill=" none" stroke="black"/> <path d="M 152,224 C 160.83064,224 168,216.83064 168,208" fill=" none" stroke="black"/>
<path d="M 48,416 C 39.16936,416 32,423.16936 32,432" fill="none " stroke="black"/> <path d="M 48,416 C 39.16936,416 32,423.16936 32,432" fill="none " stroke="black"/>
<path d="M 152,416 C 160.83064,416 168,423.16936 168,432" fill=" none" stroke="black"/> <path d="M 152,416 C 160.83064,416 168,423.16936 168,432" fill=" none" stroke="black"/>
<path d="M 48,464 C 39.16936,464 32,456.83064 32,448" fill="none " stroke="black"/> <path d="M 48,464 C 39.16936,464 32,456.83064 32,448" fill="none " stroke="black"/>
<path d="M 152,464 C 160.83064,464 168,456.83064 168,448" fill=" none" stroke="black"/> <path d="M 152,464 C 160.83064,464 168,456.83064 168,448" fill=" none" stroke="black"/>
<polygon class="arrowhead" points="504,656 492,650.4 492,661.6" <polygon class="arrowhead" fill="black" points="504,656 492,650.
fill="black" transform="rotate(90,496,656)"/> 4 492,661.6" transform="rotate(90,496,656)"/>
<polygon class="arrowhead" points="504,584 492,578.4 492,589.6" <polygon class="arrowhead" fill="black" points="504,584 492,578.
fill="black" transform="rotate(90,496,584)"/> 4 492,589.6" transform="rotate(90,496,584)"/>
<polygon class="arrowhead" points="504,504 492,498.4 492,509.6" <polygon class="arrowhead" fill="black" points="504,504 492,498.
fill="black" transform="rotate(90,496,504)"/> 4 492,509.6" transform="rotate(90,496,504)"/>
<polygon class="arrowhead" points="504,344 492,338.4 492,349.6" <polygon class="arrowhead" fill="black" points="504,344 492,338.
fill="black" transform="rotate(90,496,344)"/> 4 492,349.6" transform="rotate(90,496,344)"/>
<polygon class="arrowhead" points="504,264 492,258.4 492,269.6" <polygon class="arrowhead" fill="black" points="504,264 492,258.
fill="black" transform="rotate(90,496,264)"/> 4 492,269.6" transform="rotate(90,496,264)"/>
<polygon class="arrowhead" points="504,104 492,98.4 492,109.6" f <polygon class="arrowhead" fill="black" points="504,104 492,98.4
ill="black" transform="rotate(90,496,104)"/> 492,109.6" transform="rotate(90,496,104)"/>
<polygon class="arrowhead" points="424,608 412,602.4 412,613.6" <polygon class="arrowhead" fill="black" points="424,608 412,602.
fill="black" transform="rotate(0,416,608)"/> 4 412,613.6" transform="rotate(0,416,608)"/>
<polygon class="arrowhead" points="424,368 412,362.4 412,373.6" <polygon class="arrowhead" fill="black" points="424,368 412,362.
fill="black" transform="rotate(0,416,368)"/> 4 412,373.6" transform="rotate(0,416,368)"/>
<polygon class="arrowhead" points="408,528 396,522.4 396,533.6" <polygon class="arrowhead" fill="black" points="408,528 396,522.
fill="black" transform="rotate(180,400,528)"/> 4 396,533.6" transform="rotate(180,400,528)"/>
<polygon class="arrowhead" points="408,288 396,282.4 396,293.6" <polygon class="arrowhead" fill="black" points="408,288 396,282.
fill="black" transform="rotate(180,400,288)"/> 4 396,293.6" transform="rotate(180,400,288)"/>
<polygon class="arrowhead" points="240,528 228,522.4 228,533.6" <polygon class="arrowhead" fill="black" points="240,528 228,522.
fill="black" transform="rotate(0,232,528)"/> 4 228,533.6" transform="rotate(0,232,528)"/>
<polygon class="arrowhead" points="240,288 228,282.4 228,293.6" <polygon class="arrowhead" fill="black" points="240,288 228,282.
fill="black" transform="rotate(0,232,288)"/> 4 228,293.6" transform="rotate(0,232,288)"/>
<polygon class="arrowhead" points="184,448 172,442.4 172,453.6" <polygon class="arrowhead" fill="black" points="184,448 172,442.
fill="black" transform="rotate(180,176,448)"/> 4 172,453.6" transform="rotate(180,176,448)"/>
<polygon class="arrowhead" points="184,208 172,202.4 172,213.6" <polygon class="arrowhead" fill="black" points="184,208 172,202.
fill="black" transform="rotate(180,176,208)"/> 4 172,213.6" transform="rotate(180,176,208)"/>
<polygon class="arrowhead" points="112,504 100,498.4 100,509.6" <polygon class="arrowhead" fill="black" points="112,504 100,498.
fill="black" transform="rotate(90,104,504)"/> 4 100,509.6" transform="rotate(90,104,504)"/>
<polygon class="arrowhead" points="112,264 100,258.4 100,269.6" <polygon class="arrowhead" fill="black" points="112,264 100,258.
fill="black" transform="rotate(90,104,264)"/> 4 100,269.6" transform="rotate(90,104,264)"/>
<g class="text"> <g class="text">
<text x="496" y="36">...</text> <text x="496" y="36">...</text>
<text x="496" y="132">interim_[N-1]</text> <text x="496" y="132">interim_[N-1]</text>
<text x="80" y="196">Ratchet</text> <text x="80" y="196">Ratchet</text>
<text x="132" y="196">Tree</text> <text x="132" y="196">Tree</text>
<text x="296" y="196">wire_format</text> <text x="296" y="196">wire_format</text>
<text x="64" y="212">Key</text> <text x="64" y="212">Key</text>
<text x="116" y="212">Schedule</text> <text x="116" y="212">Schedule</text>
<text x="280" y="212">content</text> <text x="280" y="212">content</text>
<text x="288" y="228">epoch</text> <text x="288" y="228">epoch</text>
skipping to change at line 3745 skipping to change at line 3979
<text x="292" y="484">commit</text> <text x="292" y="484">commit</text>
<text x="288" y="500">signature</text> <text x="288" y="500">signature</text>
<text x="108" y="532">confirmation_key_[N+1]</text> <text x="108" y="532">confirmation_key_[N+1]</text>
<text x="316" y="532">confirmation_tag</text> <text x="316" y="532">confirmation_tag</text>
<text x="496" y="532">confirmed_[N+1]</text> <text x="496" y="532">confirmed_[N+1]</text>
<text x="496" y="612">interim_[N+1]</text> <text x="496" y="612">interim_[N+1]</text>
<text x="496" y="692">...</text> <text x="496" y="692">...</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-8.2-10.1.2">
... ...
| |
| |
V V
+-----------------+ +-----------------+
| interim_[N-1] | | interim_[N-1] |
+--------+--------+ +--------+--------+
| |
.--------------. +------------------+ | .--------------. +------------------+ |
| Ratchet Tree | | wire_format | | | Ratchet Tree | | wire_format | |
| Key Schedule |<-------+ content | | | Key Schedule |&lt;-------+ content | |
'-------+------' | epoch = N-1 +------------+ '-------+------' | epoch = N-1 +------------+
| | commit | | | | commit | |
V | signature | V V | signature | V
+------------------------+ +------------------+ +-----------------+ +------------------------+ +------------------+ +-----------------+
| confirmation_key_[N] +-->| confirmation_tag |&lt;--+ confirmed_[N] | | confirmation_key_[N] +-->| confirmation_tag |&lt;--+ confirmed_[N] |
+------------------------+ +--------+---------+ +--------+--------+ +------------------------+ +--------+---------+ +--------+--------+
| | | |
| V | V
| +-----------------+ | +-----------------+
+------------>| interim_[N] | +------------&gt;| interim_[N] |
+--------+--------+ +--------+--------+
| |
.--------------. +------------------+ | .--------------. +------------------+ |
| Ratchet Tree | | wire_format | | | Ratchet Tree | | wire_format | |
| Key Schedule |<-------+ content | | | Key Schedule |&lt;-------+ content | |
'-------+------' | epoch = N +------------+ '-------+------' | epoch = N +------------+
| | commit | | | | commit | |
V | signature | V V | signature | V
+------------------------+ +------------------+ +-----------------+ +------------------------+ +------------------+ +-----------------+
| confirmation_key_[N+1] +-->| confirmation_tag |&lt;--+ confirmed_[N+1] | | confirmation_key_[N+1] +-->| confirmation_tag |&lt;--+ confirmed_[N+1] |
+------------------------+ +--------+---------+ +--------+--------+ +------------------------+ +--------+---------+ +--------+--------+
| | | |
| V | V
| +-----------------+ | +-----------------+
+------------>| interim_[N+1] | +------------&gt;| interim_[N+1] |
+--------+--------+ +--------+--------+
| |
V V
... ...
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="external-initialization"> <section anchor="external-initialization" numbered="true" removeInRFC="fal
<name>External Initialization</name> se" toc="include" pn="section-8.3">
<t>In addition to initializing a new epoch via KDF invocations as descri <name slugifiedName="name-external-initialization">External Initializati
bed above, on</name>
<t indent="0" pn="section-8.3-1">In addition to initializing a new epoch
via KDF invocations as described above,
an MLS group can also initialize a new epoch via an asymmetric interaction using an MLS group can also initialize a new epoch via an asymmetric interaction using
the external key pair for the previous epoch. This is done when a new member the external key pair for the previous epoch. This is done when a new member
is joining via an external commit.</t> is joining via an external commit.</t>
<t>In this process, the joiner sends a new <tt>init_secret</tt> value to the group using <t indent="0" pn="section-8.3-2">In this process, the joiner sends a new <tt>init_secret</tt> value to the group using
the HPKE export method. The joiner then uses that <tt>init_secret</tt> with the HPKE export method. The joiner then uses that <tt>init_secret</tt> with
information provided in the GroupInfo and an external Commit to initialize information provided in the GroupInfo and an external Commit to initialize
their copy of the key schedule for the new epoch.</t> their copy of the key schedule for the new epoch.</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-8.3-3">
kem_output, context = SetupBaseS(external_pub, "") kem_output, context = SetupBaseS(external_pub, "")
init_secret = context.export("MLS 1.0 external init secret", KDF.Nh) init_secret = context.export("MLS 1.0 external init secret", KDF.Nh)
]]></sourcecode> </sourcecode>
<t>Members of the group receive the <tt>kem_output</tt> in an ExternalIn <t indent="0" pn="section-8.3-4">Members of the group receive the <tt>ke
it proposal and m_output</tt> in an ExternalInit proposal and
perform the corresponding calculation to retrieve the <tt>init_secret</tt> value .</t> perform the corresponding calculation to retrieve the <tt>init_secret</tt> value .</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-8.3-5">
context = SetupBaseR(kem_output, external_priv, "") context = SetupBaseR(kem_output, external_priv, "")
init_secret = context.export("MLS 1.0 external init secret", KDF.Nh) init_secret = context.export("MLS 1.0 external init secret", KDF.Nh)
]]></sourcecode> </sourcecode>
<t>In both cases, the <tt>info</tt> input to HPKE is set to the GroupInf
o for the
previous epoch, encoded using the TLS serialization.</t>
</section> </section>
<section anchor="pre-shared-keys"> <section anchor="pre-shared-keys" numbered="true" removeInRFC="false" toc=
<name>Pre-Shared Keys</name> "include" pn="section-8.4">
<t>Groups that already have an out-of-band mechanism to generate <name slugifiedName="name-pre-shared-keys">Pre-Shared Keys</name>
shared group secrets can inject those into the MLS key schedule to seed <t indent="0" pn="section-8.4-1">Groups that already have an out-of-band
the MLS group secrets computations by this external entropy.</t> mechanism to generate
<t>Injecting an external PSK can improve security in the case shared group secrets can inject them into the MLS key schedule to
incorporate this external entropy in the computation of MLS group secrets.</t>
<t indent="0" pn="section-8.4-2">Injecting an external PSK can improve s
ecurity in the case
where having a full run of Updates across members is too expensive, or if where having a full run of Updates across members is too expensive, or if
the external group key establishment mechanism provides the external group key establishment mechanism provides
stronger security against classical or quantum adversaries.</t> stronger security against classical or quantum adversaries.</t>
<t>Note that, as a PSK may have a different lifetime than an Update, it <t indent="0" pn="section-8.4-3">Note that, as a PSK may have a differen
does not t lifetime than an Update, it does not
necessarily provide the same Forward Secrecy (FS) or Post-Compromise Security necessarily provide the same forward secrecy or post-compromise security
(PCS) guarantees as a Commit message. Unlike the key pairs populated in the guarantees as a Commit message. Unlike the key pairs populated in the
tree by an Update or Commit, which are always freshly generated, PSKs may be tree by an Update or Commit, which are always freshly generated, PSKs may be
pre-distributed and stored. This creates the risk that a PSK may be compromised pre-distributed and stored. This creates the risk that a PSK may be compromised
in the process of distribution and storage. The security that the group gets in the process of distribution and storage. The security that the group gets
from injecting a PSK thus depends on both the entropy of the PSK and the risk of from injecting a PSK thus depends on both the entropy of the PSK and the risk of
compromise. These factors are outside of the scope of this document, but should compromise. These factors are outside of the scope of this document, but they s hould
be considered by application designers relying on PSKs.</t> be considered by application designers relying on PSKs.</t>
<t>Each PSK in MLS has a type that designates how it was provisioned. <t indent="0" pn="section-8.4-4">Each PSK in MLS has a type that designa tes how it was provisioned.
External PSKs are provided by the application, while resumption PSKs External PSKs are provided by the application, while resumption PSKs
are derived from the MLS key schedule and used in cases where it is 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.</t> necessary to authenticate a member's participation in a prior epoch.</t>
<t>The injection of one or more PSKs into the key schedule is signaled i n two ways: <t indent="0" pn="section-8.4-5">The injection of one or more PSKs into the key schedule is signaled in two ways:
Existing members are informed via PreSharedKey proposals covered by a Commit, Existing members are informed via PreSharedKey proposals covered by a Commit,
and new members added in the Commit are informed by the GroupSecrets object in t he and new members added in the Commit are informed by the GroupSecrets object in t he
Welcome message corresponding to the Commit. To ensure that existing and new 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 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.</t> GroupSecrets objects <bcp14>MUST</bcp14> indicate the same set of PSKs, in the s
<sourcecode type="tls"><![CDATA[ ame order.</t>
<sourcecode type="tls-presentation" markers="false" pn="section-8.4-6">
enum { enum {
reserved(0), reserved(0),
external(1), external(1),
resumption(2), resumption(2),
(255) (255)
} PSKType; } PSKType;
enum { enum {
reserved(0), reserved(0),
application(1), application(1),
reinit(2), reinit(2),
branch(3), branch(3),
(255) (255)
} ResumptionPSKUsage; } ResumptionPSKUsage;
struct { struct {
PSKType psktype; PSKType psktype;
select (PreSharedKeyID.psktype) { select (PreSharedKeyID.psktype) {
case external: case external:
opaque psk_id<V&gt;; opaque psk_id<V&gt;;
case resumption: case resumption:
ResumptionPSKUsage usage; ResumptionPSKUsage usage;
opaque psk_group_id<V&gt;; opaque psk_group_id<V&gt;;
uint64 psk_epoch; uint64 psk_epoch;
}; };
opaque psk_nonce<V&gt;; opaque psk_nonce<V&gt;;
} PreSharedKeyID; } PreSharedKeyID;
]]></sourcecode> </sourcecode>
<t>Each time a client injects a PSK into a group, the <tt>psk_nonce</tt> <t indent="0" pn="section-8.4-7">Each time a client injects a PSK into a
of its group, the <tt>psk_nonce</tt> of its
PreSharedKeyID MUST be set to a fresh random value of length <tt>KDF.Nh</tt>, wh PreSharedKeyID <bcp14>MUST</bcp14> be set to a fresh random value of length <tt>
ere KDF.Nh</tt>, where
<tt>KDF</tt> is the KDF for the ciphersuite of the group into which the PSK is b <tt>KDF</tt> is the KDF for the cipher suite of the group into which the PSK is
eing being
injected. This ensures that even when a PSK is used multiple times, the value injected. This ensures that even when a PSK is used multiple times, the value
used as an input into the key schedule is different each time.</t> used as an input into the key schedule is different each time.</t>
<t>Upon receiving a Commit with a <tt>PreSharedKey</tt> proposal or a Gr <t indent="0" pn="section-8.4-8">Upon receiving a Commit with a PreShare
oupSecrets object dKey proposal or a GroupSecrets object
with the <tt>psks</tt> field set, the receiving Client includes them in the key with the <tt>psks</tt> field set, the receiving client includes them in the key
schedule in the order listed in the Commit, or in the <tt>psks</tt> field respec schedule in the order listed in the Commit, or in the <tt>psks</tt> field, respe
tively. ctively.
For resumption PSKs, the PSK is defined as the <tt>resumption_psk</tt> of the gr oup and For resumption PSKs, the PSK is defined as the <tt>resumption_psk</tt> of the gr oup and
epoch specified in the <tt>PreSharedKeyID</tt> object. Specifically, <tt>psk_sec ret</tt> is epoch specified in the PreSharedKeyID object. Specifically, <tt>psk_secret</tt> is
computed as follows:</t> computed as follows:</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-8.4-9">
struct { struct {
PreSharedKeyID id; PreSharedKeyID id;
uint16 index; uint16 index;
uint16 count; uint16 count;
} PSKLabel; } PSKLabel;
]]></sourcecode> </sourcecode>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-8.4-10">
psk_extracted_[i] = KDF.Extract(0, psk_[i]) psk_extracted_[i] = KDF.Extract(0, psk_[i])
psk_input_[i] = ExpandWithLabel(psk_extracted_[i], "derived psk", psk_input_[i] = ExpandWithLabel(psk_extracted_[i], "derived psk",
PSKLabel, KDF.Nh) PSKLabel, KDF.Nh)
psk_secret_[0] = 0 psk_secret_[0] = 0
psk_secret_[i] = KDF.Extract(psk_input_[i-1], psk_secret_[i-1]) psk_secret_[i] = KDF.Extract(psk_input_[i-1], psk_secret_[i-1])
psk_secret = psk_secret_[n] psk_secret = psk_secret_[n]
]]></sourcecode> </sourcecode>
<t>Here <tt>0</tt> represents the all-zero vector of length <tt>KDF.Nh</ <t indent="0" pn="section-8.4-11">Here <tt>0</tt> represents the all-zer
tt>. The <tt>index</tt> field in o vector of length <tt>KDF.Nh</tt>. The <tt>index</tt> field in
<tt>PSKLabel</tt> corresponds to the index of the PSK in the <tt>psk</tt> array, PSKLabel corresponds to the index of the PSK in the <tt>psk</tt> array, while th
while the e
<tt>count</tt> field contains the total number of PSKs. In other words, the PSK s are <tt>count</tt> field contains the total number of PSKs. In other words, the PSK s are
chained together with KDF.Extract invocations (labeled "Extract" for brevity chained together with KDF.Extract invocations (labeled "Extract" for brevity
in the diagram), as follows:</t> in the diagram), as follows:</t>
<figure> <figure align="left" suppress-title="false" pn="figure-24">
<name>Computatation of a PSK secret from a set of PSKs</name> <name slugifiedName="name-computation-of-a-psk-secret">Computation of
<artset> a PSK Secret from a Set of PSKs</name>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= <artset pn="section-8.4-12.1">
"1.1" height="256" width="568" viewBox="0 0 568 256" class="diagram" text-anchor <artwork type="svg" align="left" pn="section-8.4-12.1.1">
="middle" font-family="monospace" font-size="13px"> <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-famil
y="monospace" font-size="13px" height="256" text-anchor="middle" version="1.1" v
iewBox="0 0 568 256" width="568">
<path d="M 400,96 L 400,144" fill="none" stroke="black"/> <path d="M 400,96 L 400,144" fill="none" stroke="black"/>
<path d="M 400,192 L 400,224" fill="none" stroke="black"/> <path d="M 400,192 L 400,224" fill="none" stroke="black"/>
<path d="M 88,80 L 104,80" fill="none" stroke="black"/> <path d="M 88,80 L 104,80" fill="none" stroke="black"/>
<path d="M 184,80 L 200,80" fill="none" stroke="black"/> <path d="M 184,80 L 200,80" fill="none" stroke="black"/>
<path d="M 344,80 L 360,80" fill="none" stroke="black"/> <path d="M 344,80 L 360,80" fill="none" stroke="black"/>
<path d="M 88,160 L 104,160" fill="none" stroke="black"/> <path d="M 88,160 L 104,160" fill="none" stroke="black"/>
<path d="M 184,160 L 200,160" fill="none" stroke="black"/> <path d="M 184,160 L 200,160" fill="none" stroke="black"/>
<path d="M 344,160 L 360,160" fill="none" stroke="black"/> <path d="M 344,160 L 360,160" fill="none" stroke="black"/>
<path d="M 88,240 L 104,240" fill="none" stroke="black"/> <path d="M 88,240 L 104,240" fill="none" stroke="black"/>
<path d="M 184,240 L 200,240" fill="none" stroke="black"/> <path d="M 184,240 L 200,240" fill="none" stroke="black"/>
<path d="M 344,240 L 360,240" fill="none" stroke="black"/> <path d="M 344,240 L 360,240" fill="none" stroke="black"/>
<polygon class="arrowhead" points="408,224 396,218.4 396,229.6" <polygon class="arrowhead" fill="black" points="408,224 396,218.
fill="black" transform="rotate(90,400,224)"/> 4 396,229.6" transform="rotate(90,400,224)"/>
<polygon class="arrowhead" points="408,144 396,138.4 396,149.6" <polygon class="arrowhead" fill="black" points="408,144 396,138.
fill="black" transform="rotate(90,400,144)"/> 4 396,149.6" transform="rotate(90,400,144)"/>
<polygon class="arrowhead" points="368,240 356,234.4 356,245.6" <polygon class="arrowhead" fill="black" points="368,240 356,234.
fill="black" transform="rotate(0,360,240)"/> 4 356,245.6" transform="rotate(0,360,240)"/>
<polygon class="arrowhead" points="368,160 356,154.4 356,165.6" <polygon class="arrowhead" fill="black" points="368,160 356,154.
fill="black" transform="rotate(0,360,160)"/> 4 356,165.6" transform="rotate(0,360,160)"/>
<polygon class="arrowhead" points="368,80 356,74.4 356,85.6" fil <polygon class="arrowhead" fill="black" points="368,80 356,74.4
l="black" transform="rotate(0,360,80)"/> 356,85.6" transform="rotate(0,360,80)"/>
<polygon class="arrowhead" points="208,240 196,234.4 196,245.6" <polygon class="arrowhead" fill="black" points="208,240 196,234.
fill="black" transform="rotate(0,200,240)"/> 4 196,245.6" transform="rotate(0,200,240)"/>
<polygon class="arrowhead" points="208,160 196,154.4 196,165.6" <polygon class="arrowhead" fill="black" points="208,160 196,154.
fill="black" transform="rotate(0,200,160)"/> 4 196,165.6" transform="rotate(0,200,160)"/>
<polygon class="arrowhead" points="208,80 196,74.4 196,85.6" fil <polygon class="arrowhead" fill="black" points="208,80 196,74.4
l="black" transform="rotate(0,200,80)"/> 196,85.6" transform="rotate(0,200,80)"/>
<polygon class="arrowhead" points="112,240 100,234.4 100,245.6" <polygon class="arrowhead" fill="black" points="112,240 100,234.
fill="black" transform="rotate(0,104,240)"/> 4 100,245.6" transform="rotate(0,104,240)"/>
<polygon class="arrowhead" points="112,160 100,154.4 100,165.6" <polygon class="arrowhead" fill="black" points="112,160 100,154.
fill="black" transform="rotate(0,104,160)"/> 4 100,165.6" transform="rotate(0,104,160)"/>
<polygon class="arrowhead" points="112,80 100,74.4 100,85.6" fil <polygon class="arrowhead" fill="black" points="112,80 100,74.4
l="black" transform="rotate(0,104,80)"/> 100,85.6" transform="rotate(0,104,80)"/>
<g class="text"> <g class="text">
<text x="144" y="36">0</text> <text x="144" y="36">0</text>
<text x="400" y="36">0</text> <text x="400" y="36">0</text>
<text x="440" y="36">=</text> <text x="440" y="36">=</text>
<text x="508" y="36">psk_secret_[0]</text> <text x="508" y="36">psk_secret_[0]</text>
<text x="144" y="52">|</text> <text x="144" y="52">|</text>
<text x="400" y="52">|</text> <text x="400" y="52">|</text>
<text x="32" y="84">psk_[0]</text> <text x="32" y="84">psk_[0]</text>
<text x="144" y="84">Extract</text> <text x="144" y="84">Extract</text>
<text x="272" y="84">ExpandWithLabel</text> <text x="272" y="84">ExpandWithLabel</text>
skipping to change at line 3966 skipping to change at line 4199
<text x="144" y="212">|</text> <text x="144" y="212">|</text>
<text x="40" y="244">psk_[n-1]</text> <text x="40" y="244">psk_[n-1]</text>
<text x="144" y="244">Extract</text> <text x="144" y="244">Extract</text>
<text x="272" y="244">ExpandWithLabel</text> <text x="272" y="244">ExpandWithLabel</text>
<text x="400" y="244">Extract</text> <text x="400" y="244">Extract</text>
<text x="440" y="244">=</text> <text x="440" y="244">=</text>
<text x="508" y="244">psk_secret_[n]</text> <text x="508" y="244">psk_secret_[n]</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-8.4-12.1.2">
0 0 = psk_secret_[0] 0 0 = psk_secret_[0]
| | | |
V V V V
psk_[0] --> Extract --> ExpandWithLabel --&gt; Extract = psk_secret_[1] psk_[0] --> Extract --&gt; ExpandWithLabel --&gt; Extract = psk_secret_[1]
| |
0 | 0 |
| | | |
V V V V
psk_[1] --> Extract --> ExpandWithLabel --&gt; Extract = psk_secret_[2] psk_[1] --> Extract --&gt; ExpandWithLabel --&gt; Extract = psk_secret_[2]
| |
0 ... 0 ...
| | | |
V V V V
psk_[n-1] --> Extract --> ExpandWithLabel --> Extract = psk_secret_[n] psk_[n-1] --&gt; Extract --&gt; ExpandWithLabel --&gt; Extract = psk_secret_[n]
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>In particular, if there are no PreSharedKey proposals in a given Comm it, then <t indent="0" pn="section-8.4-13">In particular, if there are no PreShar edKey proposals in a given Commit, then
the resulting <tt>psk_secret</tt> is <tt>psk_secret_[0]</tt>, the all-zero vecto r.</t> the resulting <tt>psk_secret</tt> is <tt>psk_secret_[0]</tt>, the all-zero vecto r.</t>
</section> </section>
<section anchor="exporters"> <section anchor="exporters" numbered="true" removeInRFC="false" toc="inclu
<name>Exporters</name> de" pn="section-8.5">
<t>The main MLS key schedule provides an <tt>exporter_secret</tt> which <name slugifiedName="name-exporters">Exporters</name>
can <t indent="0" pn="section-8.5-1">The main MLS key schedule provides an <
tt>exporter_secret</tt> that can
be used by an application to derive new secrets for use outside of MLS.</t> be used by an application to derive new secrets for use outside of MLS.</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-8.5-2">
MLS-Exporter(Label, Context, Length) = MLS-Exporter(Label, Context, Length) =
ExpandWithLabel(DeriveSecret(exporter_secret, Label), ExpandWithLabel(DeriveSecret(exporter_secret, Label),
"exported", Hash(Context), Length) "exported", Hash(Context), Length)
]]></sourcecode> </sourcecode>
<t>Applications SHOULD provide a unique label to <tt>MLS-Exporter</tt> t <t indent="0" pn="section-8.5-3">Applications <bcp14>SHOULD</bcp14> prov
hat ide a unique label to <tt>MLS-Exporter</tt> that
identifies the secret's intended purpose. This is to help prevent the same identifies the secret's intended purpose. This is to help prevent the same
secret from being generated and used in two different places. To help avoid secret from being generated and used in two different places. To help avoid
the same label being used in different applications, an IANA registry for these the same label being used in different applications, an IANA registry for these
labels has been defined in <xref target="mls-exporter-labels"/>.</t> labels has been defined in <xref target="mls-exporter-labels" format="default" s
<t>The exported values are bound to the group epoch from which the ectionFormat="of" derivedContent="Section 17.8"/>.</t>
<t indent="0" pn="section-8.5-4">The exported values are bound to the gr
oup epoch from which the
<tt>exporter_secret</tt> is derived, and hence reflect a particular state of <tt>exporter_secret</tt> is derived, and hence reflect a particular state of
the group.</t> the group.</t>
<t>It is RECOMMENDED for the application generating exported values <t indent="0" pn="section-8.5-5">It is <bcp14>RECOMMENDED</bcp14> for th e application generating exported values
to refresh those values after a Commit is processed.</t> to refresh those values after a Commit is processed.</t>
</section> </section>
<section anchor="resumption-psk"> <section anchor="resumption-psk" numbered="true" removeInRFC="false" toc="
<name>Resumption PSK</name> include" pn="section-8.6">
<t>The main MLS key schedule provides a <tt>resumption_psk</tt> that is <name slugifiedName="name-resumption-psk">Resumption PSK</name>
used as a PSK <t indent="0" pn="section-8.6-1">The main MLS key schedule provides a <t
t>resumption_psk</tt> that is used as a PSK
to inject entropy from one epoch into another. This functionality is used in th e to inject entropy from one epoch into another. This functionality is used in th e
reinitialization and branching processes described in <xref target="reinitializa reinitialization and branching processes described in Sections <xref format="cou
tion"/> and nter" target="reinitialization" sectionFormat="of" derivedContent="11.2"/> and
<xref target="subgroup-branching"/>, but may be used by applications for other p <xref format="counter" target="subgroup-branching" sectionFormat="of" derivedCon
urposes.</t> tent="11.3"/>, but it may be used by applications for other purposes.</t>
<t>Some uses of resumption PSKs might call for the use of PSKs from hist <t indent="0" pn="section-8.6-2">Some uses of resumption PSKs might call
orical for the use of PSKs from historical
epochs. The application SHOULD specify an upper limit on the number of past epochs. The application <bcp14>SHOULD</bcp14> specify an upper limit on the numb
er of past
epochs for which the <tt>resumption_psk</tt> may be stored.</t> epochs for which the <tt>resumption_psk</tt> may be stored.</t>
</section> </section>
<section anchor="epoch-authenticators"> <section anchor="epoch-authenticators" numbered="true" removeInRFC="false"
<name>Epoch Authenticators</name> toc="include" pn="section-8.7">
<t>The main MLS key schedule provides a per-epoch <tt>epoch_authenticato <name slugifiedName="name-epoch-authenticators">Epoch Authenticators</na
r</tt>. If one me>
<t indent="0" pn="section-8.7-1">The main MLS key schedule provides a pe
r-epoch <tt>epoch_authenticator</tt>. If one
member of the group is being impersonated by an active attacker, the member of the group is being impersonated by an active attacker, the
<tt>epoch_authenticator</tt> computed by their client will differ from those com puted <tt>epoch_authenticator</tt> computed by their client will differ from those com puted
by the other group members.</t> by the other group members.</t>
<t>This property can be used to construct defenses against impersonation attacks <t indent="0" pn="section-8.7-2">This property can be used to construct defenses against impersonation attacks
that are effective even if members' signature keys are compromised. As a trivial that are effective even if members' signature keys are compromised. As a trivial
example, if the users of the clients in an MLS group were to meet in person and example, if the users of the clients in an MLS group were to meet in person and
reliably confirm that their epoch authenticator values were equal (using some reliably confirm that their epoch authenticator values were equal (using some
suitable user interface), then each user would be assured that the others were suitable user interface), then each user would be assured that the others were
not being impersonated in the current epoch. As soon as the epoch changed, not being impersonated in the current epoch. As soon as the epoch changed,
though, they would need to re-do this confirmation. The state of the group would though, they would need to redo this confirmation. The state of the group would
have changed, possibly introducing an attacker.</t> have changed, possibly introducing an attacker.</t>
<t>More generally, in order for the members of an MLS group to obtain co ncrete <t indent="0" pn="section-8.7-3">More generally, in order for the member s of an MLS group to obtain concrete
authentication protections using the <tt>epoch_authenticator</tt>, they will nee d to authentication protections using the <tt>epoch_authenticator</tt>, they will nee d to
use it in some secondary protocol (such as the face-to-face protocol above). use it in some secondary protocol (such as the face-to-face protocol above).
The details of that protocol will then determine the specific authentication The details of that protocol will then determine the specific authentication
protections provided to the MLS group.</t> protections provided to the MLS group.</t>
</section> </section>
</section> </section>
<section anchor="secret-tree"> <section anchor="secret-tree" numbered="true" removeInRFC="false" toc="inclu
<name>Secret Tree</name> de" pn="section-9">
<t>For the generation of encryption keys and nonces, the key schedule begi <name slugifiedName="name-secret-tree">Secret Tree</name>
ns with <t indent="0" pn="section-9-1">For the generation of encryption keys and n
onces, the key schedule begins with
the <tt>encryption_secret</tt> at the root and derives a tree of secrets with th e same the <tt>encryption_secret</tt> at the root and derives a tree of secrets with th e same
structure as the group's ratchet tree. Each leaf in the Secret Tree is structure as the group's ratchet tree. Each leaf in the secret tree is
associated with the same group member as the corresponding leaf in the ratchet associated with the same group member as the corresponding leaf in the ratchet
tree.</t> tree.</t>
<t>If N is a parent node in the Secret Tree then the secrets of the childr en of N <t indent="0" pn="section-9-2">If N is a parent node in the secret tree, t hen the secrets of the children of N
are defined as follows (where left(N) and right(N) denote the children of N):</t > are defined as follows (where left(N) and right(N) denote the children of N):</t >
<figure> <figure align="left" suppress-title="false" pn="figure-25">
<name>Derivation of secrets from parent to children within a secret tree <name slugifiedName="name-derivation-of-secrets-from-">Derivation of Sec
</name> rets from Parent to Children within a Secret Tree</name>
<artset> <artset pn="section-9-3.1">
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 <artwork type="svg" align="left" pn="section-9-3.1.1">
.1" height="160" width="456" viewBox="0 0 456 160" class="diagram" text-anchor=" <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-family=
middle" font-family="monospace" font-size="13px"> "monospace" font-size="13px" height="160" text-anchor="middle" version="1.1" vie
wBox="0 0 456 160" width="456">
<path d="M 72,40 L 72,128" fill="none" stroke="black"/> <path d="M 72,40 L 72,128" fill="none" stroke="black"/>
<path d="M 248,80 L 248,88" fill="none" stroke="black"/> <path d="M 248,80 L 248,88" fill="none" stroke="black"/>
<path d="M 72,80 L 96,80" fill="none" stroke="black"/> <path d="M 72,80 L 96,80" fill="none" stroke="black"/>
<path d="M 72,128 L 96,128" fill="none" stroke="black"/> <path d="M 72,128 L 96,128" fill="none" stroke="black"/>
<polygon class="arrowhead" points="104,128 92,122.4 92,133.6" fill <polygon class="arrowhead" fill="black" points="104,128 92,122.4 9
="black" transform="rotate(0,96,128)"/> 2,133.6" transform="rotate(0,96,128)"/>
<polygon class="arrowhead" points="104,80 92,74.4 92,85.6" fill="b <polygon class="arrowhead" fill="black" points="104,80 92,74.4 92,
lack" transform="rotate(0,96,80)"/> 85.6" transform="rotate(0,96,80)"/>
<g class="text"> <g class="text">
<text x="84" y="36">tree_node_[N]_secret</text> <text x="84" y="36">tree_node_[N]_secret</text>
<text x="176" y="84">ExpandWithLabel(.</text> <text x="176" y="84">ExpandWithLabel(.</text>
<text x="288" y="84">"tree",</text> <text x="288" y="84">"tree",</text>
<text x="352" y="84">"left",</text> <text x="352" y="84">"left",</text>
<text x="416" y="84">KDF.Nh)</text> <text x="416" y="84">KDF.Nh)</text>
<text x="112" y="100">=</text> <text x="112" y="100">=</text>
<text x="228" y="100">tree_node_[left(N)]_secret</text> <text x="228" y="100">tree_node_[left(N)]_secret</text>
<text x="180" y="132">ExpandWithLabel(.,</text> <text x="180" y="132">ExpandWithLabel(.,</text>
<text x="288" y="132">"tree",</text> <text x="288" y="132">"tree",</text>
<text x="356" y="132">"right",</text> <text x="356" y="132">"right",</text>
<text x="424" y="132">KDF.Nh)</text> <text x="424" y="132">KDF.Nh)</text>
<text x="112" y="148">=</text> <text x="112" y="148">=</text>
<text x="232" y="148">tree_node_[right(N)]_secret</text> <text x="232" y="148">tree_node_[right(N)]_secret</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-9-3.1.2">
tree_node_[N]_secret tree_node_[N]_secret
| |
| |
+--> ExpandWithLabel(., "tree", "left", KDF.Nh) +--&gt; ExpandWithLabel(., "tree", "left", KDF.Nh)
| = tree_node_[left(N)]_secret | = tree_node_[left(N)]_secret
| |
+--> ExpandWithLabel(., "tree", "right", KDF.Nh) +--&gt; ExpandWithLabel(., "tree", "right", KDF.Nh)
= tree_node_[right(N)]_secret = tree_node_[right(N)]_secret
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>The secret in the leaf of the Secret Tree is used to initiate two symme tric hash <t indent="0" pn="section-9-4">The secret in the leaf of the secret tree i s used to initiate two symmetric hash
ratchets, from which a sequence of single-use keys and nonces are derived, as ratchets, from which a sequence of single-use keys and nonces are derived, as
described in <xref target="encryption-keys"/>. The root of each ratchet is compu described in <xref target="encryption-keys" format="default" sectionFormat="of"
ted as:</t> derivedContent="Section 9.1"/>. The root of each ratchet is computed as:</t>
<figure> <figure align="left" suppress-title="false" pn="figure-26">
<name>Initialization of the hash ratchets from the leaves of a secret tr <name slugifiedName="name-initialization-of-the-hash-">Initialization of
ee</name> the Hash Ratchets from the Leaves of a Secret Tree</name>
<artset> <artset pn="section-9-5.1">
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 <artwork type="svg" align="left" pn="section-9-5.1.1">
.1" height="160" width="472" viewBox="0 0 472 160" class="diagram" text-anchor=" <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-family=
middle" font-family="monospace" font-size="13px"> "monospace" font-size="13px" height="160" text-anchor="middle" version="1.1" vie
wBox="0 0 472 160" width="472">
<path d="M 72,40 L 72,128" fill="none" stroke="black"/> <path d="M 72,40 L 72,128" fill="none" stroke="black"/>
<path d="M 72,80 L 96,80" fill="none" stroke="black"/> <path d="M 72,80 L 96,80" fill="none" stroke="black"/>
<path d="M 72,128 L 96,128" fill="none" stroke="black"/> <path d="M 72,128 L 96,128" fill="none" stroke="black"/>
<polygon class="arrowhead" points="104,128 92,122.4 92,133.6" fill <polygon class="arrowhead" fill="black" points="104,128 92,122.4 9
="black" transform="rotate(0,96,128)"/> 2,133.6" transform="rotate(0,96,128)"/>
<polygon class="arrowhead" points="104,80 92,74.4 92,85.6" fill="b <polygon class="arrowhead" fill="black" points="104,80 92,74.4 92,
lack" transform="rotate(0,96,80)"/> 85.6" transform="rotate(0,96,80)"/>
<g class="text"> <g class="text">
<text x="84" y="36">tree_node_[N]_secret</text> <text x="84" y="36">tree_node_[N]_secret</text>
<text x="180" y="84">ExpandWithLabel(.,</text> <text x="180" y="84">ExpandWithLabel(.,</text>
<text x="308" y="84">"handshake",</text> <text x="308" y="84">"handshake",</text>
<text x="376" y="84">"",</text> <text x="376" y="84">"",</text>
<text x="424" y="84">KDF.Nh)</text> <text x="424" y="84">KDF.Nh)</text>
<text x="112" y="100">=</text> <text x="112" y="100">=</text>
<text x="252" y="100">handshake_ratchet_secret_[N]_[0]</text> <text x="252" y="100">handshake_ratchet_secret_[N]_[0]</text>
<text x="180" y="132">ExpandWithLabel(.,</text> <text x="180" y="132">ExpandWithLabel(.,</text>
<text x="316" y="132">"application",</text> <text x="316" y="132">"application",</text>
<text x="392" y="132">"",</text> <text x="392" y="132">"",</text>
<text x="440" y="132">KDF.Nh)</text> <text x="440" y="132">KDF.Nh)</text>
<text x="112" y="148">=</text> <text x="112" y="148">=</text>
<text x="260" y="148">application_ratchet_secret_[N]_[0]</text> <text x="260" y="148">application_ratchet_secret_[N]_[0]</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-9-5.1.2">
tree_node_[N]_secret tree_node_[N]_secret
| |
| |
+--> ExpandWithLabel(., "handshake", "", KDF.Nh) +--&gt; ExpandWithLabel(., "handshake", "", KDF.Nh)
| = handshake_ratchet_secret_[N]_[0] | = handshake_ratchet_secret_[N]_[0]
| |
+--> ExpandWithLabel(., "application", "", KDF.Nh) +--&gt; ExpandWithLabel(., "application", "", KDF.Nh)
= application_ratchet_secret_[N]_[0] = application_ratchet_secret_[N]_[0]
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<section anchor="encryption-keys"> <section anchor="encryption-keys" numbered="true" removeInRFC="false" toc=
<name>Encryption Keys</name> "include" pn="section-9.1">
<t>As described in <xref target="message-framing"/>, MLS encrypts three <name slugifiedName="name-encryption-keys">Encryption Keys</name>
different <t indent="0" pn="section-9.1-1">As described in <xref target="message-f
raming" format="default" sectionFormat="of" derivedContent="Section 6"/>, MLS en
crypts three different
types of information:</t> types of information:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9
<li>Metadata (sender information)</li> .1-2">
<li>Handshake messages (Proposal and Commit)</li> <li pn="section-9.1-2.1">Metadata (sender information)</li>
<li>Application messages</li> <li pn="section-9.1-2.2">Handshake messages (Proposal and Commit)</li>
<li pn="section-9.1-2.3">Application messages</li>
</ul> </ul>
<t>The sender information used to look up the key for content encryption is <t indent="0" pn="section-9.1-3">The sender information used to look up the key for content encryption is
encrypted with an AEAD where the key and nonce are derived from both encrypted with an AEAD where the key and nonce are derived from both
<tt>sender_data_secret</tt> and a sample of the encrypted message content.</t> <tt>sender_data_secret</tt> and a sample of the encrypted message content.</t>
<t>For handshake and application messages, a sequence of keys is derived via a <t indent="0" pn="section-9.1-4">For handshake and application messages, a sequence of keys is derived via a
"sender ratchet". Each sender has their own sender ratchet, and each step along "sender ratchet". Each sender has their own sender ratchet, and each step along
the ratchet is called a "generation".</t> the ratchet is called a "generation".</t>
<t>The following figure shows a secret tree for a four-member group, wit h the <t indent="0" pn="section-9.1-5">The following figure shows a secret tre e for a four-member group, with the
handshake and application ratchets that member D will use for sending and the handshake and application ratchets that member D will use for sending and the
first two application keys and nonces.</t> first two application keys and nonces.</t>
<figure anchor="secret-tree-example"> <figure anchor="secret-tree-example" align="left" suppress-title="false"
<name>Secret tree for a four-member group</name> pn="figure-27">
<artset> <name slugifiedName="name-secret-tree-for-a-four-memb">Secret Tree for
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= a Four-Member Group</name>
"1.1" height="320" width="200" viewBox="0 0 200 320" class="diagram" text-anchor <artset pn="section-9.1-6.1">
="middle" font-family="monospace" font-size="13px"> <artwork type="svg" align="left" pn="section-9.1-6.1.1">
<svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-famil
y="monospace" font-size="13px" height="320" text-anchor="middle" version="1.1" v
iewBox="0 0 200 320" width="200">
<path d="M 56,48 L 56,64" fill="none" stroke="black"/> <path d="M 56,48 L 56,64" fill="none" stroke="black"/>
<path d="M 128,176 L 128,208" fill="none" stroke="black"/> <path d="M 128,176 L 128,208" fill="none" stroke="black"/>
<path d="M 128,240 L 128,272" fill="none" stroke="black"/> <path d="M 128,240 L 128,272" fill="none" stroke="black"/>
<path d="M 160,160 L 160,192" fill="none" stroke="black"/> <path d="M 160,160 L 160,192" fill="none" stroke="black"/>
<path d="M 160,224 L 160,256" fill="none" stroke="black"/> <path d="M 160,224 L 160,256" fill="none" stroke="black"/>
<path d="M 40,64 L 72,64" fill="none" stroke="black"/> <path d="M 40,64 L 72,64" fill="none" stroke="black"/>
<path d="M 144,160 L 176,160" fill="none" stroke="black"/> <path d="M 144,160 L 176,160" fill="none" stroke="black"/>
<path d="M 160,192 L 176,192" fill="none" stroke="black"/> <path d="M 160,192 L 176,192" fill="none" stroke="black"/>
<path d="M 144,224 L 176,224" fill="none" stroke="black"/> <path d="M 144,224 L 176,224" fill="none" stroke="black"/>
<path d="M 160,256 L 176,256" fill="none" stroke="black"/> <path d="M 160,256 L 176,256" fill="none" stroke="black"/>
skipping to change at line 4186 skipping to change at line 4422
<text x="128" y="164">AR0</text> <text x="128" y="164">AR0</text>
<text x="188" y="164">K0</text> <text x="188" y="164">K0</text>
<text x="188" y="196">N0</text> <text x="188" y="196">N0</text>
<text x="128" y="228">AR1</text> <text x="128" y="228">AR1</text>
<text x="188" y="228">K1</text> <text x="188" y="228">K1</text>
<text x="188" y="260">N1</text> <text x="188" y="260">N1</text>
<text x="128" y="292">AR2</text> <text x="128" y="292">AR2</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-9.1-6.1.2">
G G
| |
.-+-. .-+-.
/ \ / \
E F E F
/ \ / \ / \ / \
A B C D A B C D
/ \ / \
HR0 AR0--+--K0 HR0 AR0--+--K0
| | | |
| +--N0 | +--N0
| |
AR1--+--K1 AR1--+--K1
| | | |
| +--N1 | +--N1
| |
AR2 AR2
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>A sender ratchet starts from a per-sender base secret derived from a <t indent="0" pn="section-9.1-7">A sender ratchet starts from a per-send
Secret er base secret derived from a Secret
Tree, as described in <xref target="secret-tree"/>. The base secret initiates a Tree, as described in <xref target="secret-tree" format="default" sectionFormat=
symmetric "of" derivedContent="Section 9"/>. The base secret initiates a symmetric
hash ratchet which generates a sequence of keys and nonces. The sender uses the hash ratchet, which generates a sequence of keys and nonces. The sender uses the
j-th key/nonce pair in the sequence to encrypt (using the AEAD) the j-th message j-th key/nonce pair in the sequence to encrypt (using the AEAD) the j-th message
they send during that epoch. Each key/nonce pair MUST NOT be used to encrypt they send during that epoch. Each key/nonce pair <bcp14>MUST NOT</bcp14> be used to encrypt
more than one message.</t> more than one message.</t>
<t>Keys, nonces, and the secrets in ratchets are derived using <t indent="0" pn="section-9.1-8">Keys, nonces, and the secrets in ratche ts are derived using
DeriveTreeSecret. The context in a given call consists of the current position DeriveTreeSecret. The context in a given call consists of the current position
in the ratchet.</t> in the ratchet.</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-9.1-9">
DeriveTreeSecret(Secret, Label, Generation, Length) = DeriveTreeSecret(Secret, Label, Generation, Length) =
ExpandWithLabel(Secret, Label, Generation, Length) ExpandWithLabel(Secret, Label, Generation, Length)
]]></sourcecode> </sourcecode>
<t>Where <tt>Generation</tt> is encoded as a big endian uint32.</t> <t indent="0" pn="section-9.1-10">Where <tt>Generation</tt> is encoded a
<artset> s a big endian uint32.</t>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 <artset pn="section-9.1-11">
.1" height="208" width="416" viewBox="0 0 416 208" class="diagram" text-anchor=" <artwork type="svg" align="left" pn="section-9.1-11.1">
middle" font-family="monospace" font-size="13px"> <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-family=
"monospace" font-size="13px" height="208" text-anchor="middle" version="1.1" vie
wBox="0 0 416 208" width="416">
<path d="M 56,40 L 56,160" fill="none" stroke="black"/> <path d="M 56,40 L 56,160" fill="none" stroke="black"/>
<path d="M 56,64 L 80,64" fill="none" stroke="black"/> <path d="M 56,64 L 80,64" fill="none" stroke="black"/>
<path d="M 56,112 L 80,112" fill="none" stroke="black"/> <path d="M 56,112 L 80,112" fill="none" stroke="black"/>
<polygon class="arrowhead" points="88,112 76,106.4 76,117.6" fill= <polygon class="arrowhead" fill="black" points="88,112 76,106.4 76
"black" transform="rotate(0,80,112)"/> ,117.6" transform="rotate(0,80,112)"/>
<polygon class="arrowhead" points="88,64 76,58.4 76,69.6" fill="bl <polygon class="arrowhead" fill="black" points="88,64 76,58.4 76,6
ack" transform="rotate(0,80,64)"/> 9.6" transform="rotate(0,80,64)"/>
<polygon class="arrowhead" points="64,160 52,154.4 52,165.6" fill= <polygon class="arrowhead" fill="black" points="64,160 52,154.4 52
"black" transform="rotate(90,56,160)"/> ,165.6" transform="rotate(90,56,160)"/>
<g class="text"> <g class="text">
<text x="92" y="36">ratchet_secret_[N]_[j]</text> <text x="92" y="36">ratchet_secret_[N]_[j]</text>
<text x="168" y="68">DeriveTreeSecret(.,</text> <text x="168" y="68">DeriveTreeSecret(.,</text>
<text x="284" y="68">"nonce",</text> <text x="284" y="68">"nonce",</text>
<text x="332" y="68">j,</text> <text x="332" y="68">j,</text>
<text x="380" y="68">AEAD.Nn)</text> <text x="380" y="68">AEAD.Nn)</text>
<text x="96" y="84">=</text> <text x="96" y="84">=</text>
<text x="192" y="84">ratchet_nonce_[N]_[j]</text> <text x="192" y="84">ratchet_nonce_[N]_[j]</text>
<text x="168" y="116">DeriveTreeSecret(.,</text> <text x="168" y="116">DeriveTreeSecret(.,</text>
<text x="276" y="116">"key",</text> <text x="276" y="116">"key",</text>
skipping to change at line 4252 skipping to change at line 4489
<text x="184" y="132">ratchet_key_[N]_[j]</text> <text x="184" y="132">ratchet_key_[N]_[j]</text>
<text x="80" y="180">DeriveTreeSecret(.,</text> <text x="80" y="180">DeriveTreeSecret(.,</text>
<text x="200" y="180">"secret",</text> <text x="200" y="180">"secret",</text>
<text x="252" y="180">j,</text> <text x="252" y="180">j,</text>
<text x="296" y="180">KDF.Nh)</text> <text x="296" y="180">KDF.Nh)</text>
<text x="8" y="196">=</text> <text x="8" y="196">=</text>
<text x="116" y="196">ratchet_secret_[N]_[j+1]</text> <text x="116" y="196">ratchet_secret_[N]_[j+1]</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-9.1-11.2">
ratchet_secret_[N]_[j] ratchet_secret_[N]_[j]
| |
+--> DeriveTreeSecret(., "nonce", j, AEAD.Nn) +--&gt; DeriveTreeSecret(., "nonce", j, AEAD.Nn)
| = ratchet_nonce_[N]_[j] | = ratchet_nonce_[N]_[j]
| |
+--> DeriveTreeSecret(., "key", j, AEAD.Nk) +--&gt; DeriveTreeSecret(., "key", j, AEAD.Nk)
| = ratchet_key_[N]_[j] | = ratchet_key_[N]_[j]
| |
V V
DeriveTreeSecret(., "secret", j, KDF.Nh) DeriveTreeSecret(., "secret", j, KDF.Nh)
= ratchet_secret_[N]_[j+1] = ratchet_secret_[N]_[j+1]
]]></artwork> </artwork>
</artset> </artset>
<t>Here, <tt>AEAD.Nn</tt> and <tt>AEAD.Nk</tt> denote the lengths <t indent="0" pn="section-9.1-12">Here <tt>AEAD.Nn</tt> and <tt>AEAD.Nk< /tt> denote the lengths
in bytes of the nonce and key for the AEAD scheme defined by in bytes of the nonce and key for the AEAD scheme defined by
the ciphersuite.</t> the cipher suite.</t>
</section> </section>
<section anchor="deletion-schedule"> <section anchor="deletion-schedule" numbered="true" removeInRFC="false" to
<name>Deletion Schedule</name> c="include" pn="section-9.2">
<t>It is important to delete all security-sensitive values as soon as th <name slugifiedName="name-deletion-schedule">Deletion Schedule</name>
ey are <t indent="0" pn="section-9.2-1">It is important to delete all security-
<em>consumed</em>. A sensitive value S is said to be <em>consumed</em> if</t> sensitive values as soon as they are
<ul spacing="normal"> <em>consumed</em>. A sensitive value S is said to be <em>consumed</em> if:</t>
<li>S was used to encrypt or (successfully) decrypt a message, or if</ <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9
li> .2-2">
<li>a key, nonce, or secret derived from S has been consumed. (This go <li pn="section-9.2-2.1">S was used to encrypt or (successfully) decry
es for pt a message, or</li>
<li pn="section-9.2-2.2">a key, nonce, or secret derived from S has be
en consumed. (This goes for
values derived via DeriveSecret as well as ExpandWithLabel.)</li> values derived via DeriveSecret as well as ExpandWithLabel.)</li>
</ul> </ul>
<t>Here, S may be the <tt>init_secret</tt>, <tt>commit_secret</tt>, <tt> <t indent="0" pn="section-9.2-3">Here S may be the <tt>init_secret</tt>,
epoch_secret</tt>, <tt>commit_secret</tt>, <tt>epoch_secret</tt>, or
<tt>encryption_secret</tt> as well as any secret in a Secret Tree or one of the <tt>encryption_secret</tt> as well as any secret in a secret tree or one of the
ratchets.</t> ratchets.</t>
<t>As soon as a group member consumes a value they MUST immediately dele te <t indent="0" pn="section-9.2-4">As soon as a group member consumes a va lue, they <bcp14>MUST</bcp14> immediately delete
(all representations of) that value. This is crucial to ensuring (all representations of) that value. This is crucial to ensuring
forward secrecy for past messages. Members MAY keep unconsumed values around forward secrecy for past messages. Members <bcp14>MAY</bcp14> keep unconsumed va lues around
for some reasonable amount of time to handle out-of-order message delivery.</t> for some reasonable amount of time to handle out-of-order message delivery.</t>
<t>For example, suppose a group member encrypts or (successfully) decryp ts an <t indent="0" pn="section-9.2-5">For example, suppose a group member enc rypts or (successfully) decrypts an
application message using the j-th key and nonce in the ratchet of leaf node application message using the j-th key and nonce in the ratchet of leaf node
L in some epoch n. Then, for that member, at least the following L in some epoch n. Then, for that member, at least the following
values have been consumed and MUST be deleted:</t> values have been consumed and <bcp14>MUST</bcp14> be deleted:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9
<li>the <tt>commit_secret</tt>, <tt>joiner_secret</tt>, <tt>epoch_secr .2-6">
et</tt>, <tt>encryption_secret</tt> of <li pn="section-9.2-6.1">the <tt>commit_secret</tt>, <tt>joiner_secret
</tt>, <tt>epoch_secret</tt>, and <tt>encryption_secret</tt> of
that epoch n as well as the <tt>init_secret</tt> of the previous epoch n-1,</li> that epoch n as well as the <tt>init_secret</tt> of the previous epoch n-1,</li>
<li>all node secrets in the Secret Tree on the path from the root to t he leaf with <li pn="section-9.2-6.2">all node secrets in the secret tree on the pa th from the root to the leaf with
node L,</li> node L,</li>
<li>the first j secrets in the application data ratchet of node L and< <li pn="section-9.2-6.3">the first j secrets in the application data r
/li> atchet of node L, and</li>
<li> <li pn="section-9.2-6.4">
<tt>application_ratchet_nonce_[L]_[j]</tt> and <tt>application_ratch et_key_[L]_[j]</tt>.</li> <tt>application_ratchet_nonce_[L]_[j]</tt> and <tt>application_ratch et_key_[L]_[j]</tt>.</li>
</ul> </ul>
<t>Concretely, consider the Secret Tree shown in <xref target="secret-tr ee-example"/>. Client <t indent="0" pn="section-9.2-7">Concretely, consider the secret tree sh own in <xref target="secret-tree-example" format="default" sectionFormat="of" de rivedContent="Figure 27"/>. Client
A, B, or C would generate the illustrated values on receiving a message from D A, B, or C would generate the illustrated values on receiving a message from D
with generation equal to 1, having not received a message with generation 0 with generation equal to 1, having not received a message with generation 0
(e.g., due to out-of-order delivery). In such a case, the following values (e.g., due to out-of-order delivery). In such a case, the following values
would be consumed:</t> would be consumed:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9
<li>The key K1 and nonce N1 used to decrypt the message</li> .2-8">
<li>The application ratchet secrets AR1 and AR0</li> <li pn="section-9.2-8.1">The key K1 and nonce N1 used to decrypt the m
<li>The tree secrets D, F, G (recall that G is the <tt>encryption_secr essage</li>
et</tt> for the <li pn="section-9.2-8.2">The application ratchet secrets AR1 and AR0</
li>
<li pn="section-9.2-8.3">The tree secrets D, F, and G (recall that G i
s the <tt>encryption_secret</tt> for the
epoch)</li> epoch)</li>
<li>The <tt>epoch_secret</tt>, <tt>commit_secret</tt>, <tt>psk_secret< /tt>, and <tt>joiner_secret</tt> for the <li pn="section-9.2-8.4">The <tt>epoch_secret</tt>, <tt>commit_secret< /tt>, <tt>psk_secret</tt>, and <tt>joiner_secret</tt> for the
current epoch</li> current epoch</li>
</ul> </ul>
<t>Other values may be retained (not consumed):</t> <t indent="0" pn="section-9.2-9">Other values may be retained (not consu
<ul spacing="normal"> med):</t>
<li>K0 and N0 for decryption of an out-of-order message with generatio <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9
n 0</li> .2-10">
<li>AR2 for derivation of further message decryption keys and nonces</ <li pn="section-9.2-10.1">K0 and N0 for decryption of an out-of-order
li> message with generation 0</li>
<li>HR0 for protection of handshake messages from D</li> <li pn="section-9.2-10.2">AR2 for derivation of further message decryp
<li>E and C for deriving secrets used by senders A, B, and C</li> tion keys and nonces</li>
<li pn="section-9.2-10.3">HR0 for protection of handshake messages fro
m D</li>
<li pn="section-9.2-10.4">E and C for deriving secrets used by senders
A, B, and C</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="key-packages"> <section anchor="key-packages" numbered="true" removeInRFC="false" toc="incl
<name>Key Packages</name> ude" pn="section-10">
<t>In order to facilitate the asynchronous addition of clients to a <name slugifiedName="name-key-packages">Key Packages</name>
group, key packages are pre-published that <t indent="0" pn="section-10-1">In order to facilitate the asynchronous ad
dition of clients to a
group, clients can pre-publish KeyPackage objects that
provide some public information about a user. A KeyPackage object specifies:</t> provide some public information about a user. A KeyPackage object specifies:</t>
<ol spacing="normal" type="1"><li>A protocol version and ciphersuite that <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-10-2
the client supports,</li> ">
<li>a public key that others can use to encrypt a Welcome message to thi <li pn="section-10-2.1" derivedCounter="1.">a protocol version and ciphe
s client r suite that the client supports,</li>
<li pn="section-10-2.2" derivedCounter="2.">a public key that others can
use to encrypt a Welcome message to this client
(an "init key"), and</li> (an "init key"), and</li>
<li>the content of the leaf node that should be added to the tree to rep resent <li pn="section-10-2.3" derivedCounter="3.">the content of the leaf node that should be added to the tree to represent
this client.</li> this client.</li>
</ol> </ol>
<t>KeyPackages are intended to be used only once and SHOULD NOT <t indent="0" pn="section-10-3">KeyPackages are intended to be used only o
be reused except in the case of last resort (see <xref target="keypackage-reuse" nce and <bcp14>SHOULD NOT</bcp14>
/>). be reused except in the case of a "last resort" KeyPackage (see <xref target="ke
Clients MAY generate and publish multiple KeyPackages to ypackage-reuse" format="default" sectionFormat="of" derivedContent="Section 16.8
support multiple ciphersuites.</t> "/>).
<t>The value for <tt>init_key</tt> MUST be a public key for the asymmetric Clients <bcp14>MAY</bcp14> generate and publish multiple KeyPackages to
encryption support multiple cipher suites.</t>
scheme defined by <tt>cipher_suite</tt>, and it MUST be unique among the set of <t indent="0" pn="section-10-4">The value for <tt>init_key</tt> <bcp14>MUS
KeyPackages created by this client. Likewise, the <tt>leaf_node</tt> field MUST T</bcp14> be a public key for the asymmetric encryption
be scheme defined by <tt>cipher_suite</tt>, and it <bcp14>MUST</bcp14> be unique am
valid for the ciphersuite, including both the <tt>encryption_key</tt> and ong the set of
KeyPackages created by this client. Likewise, the <tt>leaf_node</tt> field <bcp
14>MUST</bcp14> be
valid for the cipher suite, including both the <tt>encryption_key</tt> and
<tt>signature_key</tt> fields. The whole structure is signed using the client's <tt>signature_key</tt> fields. The whole structure is signed using the client's
signature key. A KeyPackage object with an invalid signature field MUST be signature key. A KeyPackage object with an invalid signature field <bcp14>MUST</ bcp14> be
considered malformed.</t> considered malformed.</t>
<t>The signature is computed by the function <tt>SignWithLabel</tt> with a <t indent="0" pn="section-10-5">The signature is computed by the function
label <tt>SignWithLabel</tt> with a label
<tt>KeyPackageTBS</tt> and a <tt>Content</tt> input comprising all of the fields <tt>"KeyPackageTBS"</tt> and a <tt>Content</tt> input comprising all of the fiel
except for the ds except for the
signature field.</t> signature field.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-10-6">
struct { struct {
ProtocolVersion version; ProtocolVersion version;
CipherSuite cipher_suite; CipherSuite cipher_suite;
HPKEPublicKey init_key; HPKEPublicKey init_key;
LeafNode leaf_node; LeafNode leaf_node;
Extension extensions<V&gt;; Extension extensions<V&gt;;
/* SignWithLabel(., "KeyPackageTBS", KeyPackageTBS) */ /* SignWithLabel(., "KeyPackageTBS", KeyPackageTBS) */
opaque signature<V&gt;; opaque signature<V&gt;;
} KeyPackage; } KeyPackage;
struct { struct {
ProtocolVersion version; ProtocolVersion version;
CipherSuite cipher_suite; CipherSuite cipher_suite;
HPKEPublicKey init_key; HPKEPublicKey init_key;
LeafNode leaf_node; LeafNode leaf_node;
Extension extensions<V&gt;; Extension extensions<V&gt;;
} KeyPackageTBS; } KeyPackageTBS;
]]></sourcecode> </sourcecode>
<t>If a client receives a KeyPackage carried within an MLSMessage object, <t indent="0" pn="section-10-7">If a client receives a KeyPackage carried
then it within an MLSMessage object, then it
MUST verify that the <tt>version</tt> field of the KeyPackage has the same value <bcp14>MUST</bcp14> verify that the <tt>version</tt> field of the KeyPackage has
as the the same value as the
<tt>version</tt> field of the MLSMessage. The <tt>version</tt> field in the Key Package <tt>version</tt> field of the MLSMessage. The <tt>version</tt> field in the Key Package
provides an explicit signal of the intended version to the other members of provides an explicit signal of the intended version to the other members of
group when they receive the KeyPackage in an Add proposal.</t> group when they receive the KeyPackage in an Add proposal.</t>
<t>The field <tt>leaf_node.capabilities</tt> indicates what protocol versi <t indent="0" pn="section-10-8">The field <tt>leaf_node.capabilities</tt>
ons, indicates what protocol versions,
ciphersuites, credential types, and non-default proposal/extension types are sup cipher suites, credential types, and non-default proposal/extension types are su
ported pported
by the client. (Proposal and extension types defined in this document are consi by the client. (As discussed in <xref target="leaf-node-contents" format="defau
dered lt" sectionFormat="of" derivedContent="Section 7.2"/>, some proposal and extensi
"default" and not listed.) This information allows MLS session on types defined in this document are considered
"default" and thus are not listed.) This information allows MLS session
establishment to be safe from downgrade attacks on the parameters described (as establishment to be safe from downgrade attacks on the parameters described (as
discussed in <xref target="group-creation"/>), while still only advertising one discussed in <xref target="group-creation" format="default" sectionFormat="of" d
version / erivedContent="Section 11"/>), while still only advertising one version and
ciphersuite per KeyPackage.</t> one cipher suite per KeyPackage.</t>
<t>The field <tt>leaf_node.leaf_node_source</tt> of the LeafNode in a KeyP <t indent="0" pn="section-10-9">The field <tt>leaf_node.leaf_node_source</
ackage MUST be tt> of the LeafNode in a KeyPackage <bcp14>MUST</bcp14> be
set to <tt>key_package</tt>.</t> set to <tt>key_package</tt>.</t>
<t>Extensions included in the <tt>extensions</tt> or <tt>leaf_node.extensi ons</tt> fields MUST <t indent="0" pn="section-10-10">Extensions included in the <tt>extensions </tt> or <tt>leaf_node.extensions</tt> fields <bcp14>MUST</bcp14>
be included in the <tt>leaf_node.capabilities</tt> field. As discussed in be included in the <tt>leaf_node.capabilities</tt> field. As discussed in
<xref target="extensibility"/>, unknown extensions in <tt>KeyPackage.extensions< <xref target="extensibility" format="default" sectionFormat="of" derivedContent=
/tt> MUST be "Section 13"/>, unknown extensions in <tt>KeyPackage.extensions</tt> <bcp14>MUST
ignored, and the creator of a <tt>KeyPackage</tt> object SHOULD include some ran </bcp14> be
dom GREASE ignored, and the creator of a KeyPackage object <bcp14>SHOULD</bcp14> include so
me random GREASE
extensions to help ensure that other clients correctly ignore unknown extensions to help ensure that other clients correctly ignore unknown
extensions.</t> extensions.</t>
<section anchor="keypackage-validation"> <section anchor="keypackage-validation" numbered="true" removeInRFC="false
<name>KeyPackage Validation</name> " toc="include" pn="section-10.1">
<t>The validity of a KeyPackage needs to be verified at a few stages:</t <name slugifiedName="name-keypackage-validation">KeyPackage Validation</
> name>
<ul spacing="normal"> <t indent="0" pn="section-10.1-1">The validity of a KeyPackage needs to
<li>When a KeyPackage is downloaded by a group member, before it is us be verified at a few stages:</t>
ed <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
0.1-2">
<li pn="section-10.1-2.1">When a KeyPackage is downloaded by a group m
ember, before it is used
to add the client to the group</li> to add the client to the group</li>
<li>When a KeyPackage is received by a group member in an Add message< /li> <li pn="section-10.1-2.2">When a KeyPackage is received by a group mem ber in an Add message</li>
</ul> </ul>
<t>The client verifies the validity of a KeyPackage using the following <t indent="0" pn="section-10.1-3">The client verifies the validity of a
steps:</t> KeyPackage using the following steps:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>Verify that the ciphersuite and protocol version of the KeyPackage 0.1-4">
match <li pn="section-10.1-4.1">Verify that the cipher suite and protocol ve
those in the <tt>GroupContext</tt>.</li> rsion of the KeyPackage match
<li>Verify that the <tt>leaf_node</tt> of the KeyPackage is valid for those in the GroupContext.</li>
a KeyPackage <li pn="section-10.1-4.2">Verify that the <tt>leaf_node</tt> of the Ke
according to <xref target="leaf-node-validation"/>.</li> yPackage is valid for a KeyPackage
<li>Verify that the signature on the KeyPackage is valid using the pub according to <xref target="leaf-node-validation" format="default" sectionFormat=
lic key "of" derivedContent="Section 7.3"/>.</li>
<li pn="section-10.1-4.3">Verify that the signature on the KeyPackage
is valid using the public key
in <tt>leaf_node.credential</tt>.</li> in <tt>leaf_node.credential</tt>.</li>
<li>Verify that the value of <tt>leaf_node.encryption_key</tt> is diff erent from the value of <li pn="section-10.1-4.4">Verify that the value of <tt>leaf_node.encry ption_key</tt> is different from the value of
the <tt>init_key</tt> field.</li> the <tt>init_key</tt> field.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="group-creation"> <section anchor="group-creation" numbered="true" removeInRFC="false" toc="in
<name>Group Creation</name> clude" pn="section-11">
<t>A group is always created with a single member, the "creator". Other m <name slugifiedName="name-group-creation">Group Creation</name>
embers <t indent="0" pn="section-11-1">A group is always created with a single me
mber, the "creator". Other members
are then added to the group using the usual Add/Commit mechanism.</t> are then added to the group using the usual Add/Commit mechanism.</t>
<t>The creator of a group is responsible for setting the group ID, ciphers uite, and <t indent="0" pn="section-11-2">The creator of a group is responsible for setting the group ID, cipher suite, and
initial extensions for the group. If the creator intends to add other members initial extensions for the group. If the creator intends to add other members
at the time of creation, then it SHOULD Fetch KeyPackages for the members to be at the time of creation, then it <bcp14>SHOULD</bcp14> fetch KeyPackages for the
added, and select a ciphersuite and extensions according to the capabilities of members to be
the members. To protect against downgrade attacks, the creator MUST use the added, and select a cipher suite and extensions according to the capabilities of
the members. To protect against downgrade attacks, the creator <bcp14>MUST</bcp
14> use the
<tt>capabilities</tt> information in these KeyPackages to verify that the chosen <tt>capabilities</tt> information in these KeyPackages to verify that the chosen
version and ciphersuite is the best option supported by all members.</t> version and cipher suite is the best option supported by all members.</t>
<t>Group IDs SHOULD be constructed in such a way that there's an overwhelm <t indent="0" pn="section-11-3">Group IDs <bcp14>SHOULD</bcp14> be constru
ingly low cted in such a way that there is an overwhelmingly low
probability of honest group creators generating the same group ID, even without 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 assistance from the Delivery Service. This can be done, for example, by making t
freshly generated random value of size <tt>KDF.Nh</tt>. The Delivery Service MAY he group ID a
freshly generated random value of size <tt>KDF.Nh</tt>. The Delivery Service <bc
p14>MAY</bcp14>
attempt to ensure that group IDs are globally unique by rejecting the creation attempt to ensure that group IDs are globally unique by rejecting the creation
of new groups with a previously used ID.</t> of new groups with a previously used ID.</t>
<t>The creator of a group MUST take the following steps to initialize the <t indent="0" pn="section-11-4">To initialize a group, the creator of the
group:</t> group <bcp14>MUST</bcp14> take the
<ul spacing="normal"> following steps:</t>
<li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-11-
<t>Initialize a one-member group with the following initial values: 5">
<li pn="section-11-5.1">
<t indent="0" pn="section-11-5.1.1">Initialize a one-member group with
the following initial values:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>Ratchet tree: A tree with a single node, a leaf containing an HP -11-5.1.2">
KE public <li pn="section-11-5.1.2.1">Ratchet tree: A tree with a single node,
a leaf node containing an HPKE public
key and credential for the creator</li> key and credential for the creator</li>
<li>Group ID: A value set by the creator</li> <li pn="section-11-5.1.2.2">Group ID: A value set by the creator</li
<li>Epoch: 0</li> >
<li>Tree hash: The root hash of the above ratchet tree</li> <li pn="section-11-5.1.2.3">Epoch: 0</li>
<li>Confirmed transcript hash: The zero-length octet string</li> <li pn="section-11-5.1.2.4">Tree hash: The root hash of the above ra
<li>Epoch secret: A fresh random value of size <tt>KDF.Nh</tt></li> tchet tree</li>
<li>Extensions: Any values of the creator's choosing</li> <li pn="section-11-5.1.2.5">Confirmed transcript hash: The zero-leng
th octet string</li>
<li pn="section-11-5.1.2.6">Epoch secret: A fresh random value of si
ze <tt>KDF.Nh</tt></li>
<li pn="section-11-5.1.2.7">Extensions: Any values of the creator's
choosing</li>
</ul> </ul>
</li> </li>
<li> <li pn="section-11-5.2">
<t>Calculate the interim transcript hash: <t indent="0" pn="section-11-5.2.1">Calculate the interim transcript h
ash:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>Derive the <tt>confirmation_key</tt> for the epoch as described -11-5.2.2">
in <li pn="section-11-5.2.2.1">Derive the <tt>confirmation_key</tt> for
<xref target="key-schedule"/>.</li> the epoch as described in
<li>Compute a <tt>confirmation_tag</tt> over the empty <tt>confirmed <xref target="key-schedule" format="default" sectionFormat="of" derivedContent="
_transcript_hash</tt> Section 8"/>.</li>
using the <tt>confirmation_key</tt> as described in <xref target="content-authen <li pn="section-11-5.2.2.2">Compute a <tt>confirmation_tag</tt> over
tication"/>.</li> the empty <tt>confirmed_transcript_hash</tt>
<li>Compute the updated <tt>interim_transcript_hash</tt> from the using the <tt>confirmation_key</tt> as described in <xref target="content-authen
tication" format="default" sectionFormat="of" derivedContent="Section 6.1"/>.</l
i>
<li pn="section-11-5.2.2.3">Compute the updated <tt>interim_transcri
pt_hash</tt> from the
<tt>confirmed_transcript_hash</tt> and the <tt>confirmation_tag</tt> as describe d in <tt>confirmed_transcript_hash</tt> and the <tt>confirmation_tag</tt> as describe d in
<xref target="transcript-hashes"/></li> <xref target="transcript-hashes" format="default" sectionFormat="of" derivedCont ent="Section 8.2"/>.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>At this point, the creator's state represents a one-member group with a fully <t indent="0" pn="section-11-6">At this point, the creator's state represe nts a one-member group with a fully
initialized key schedule, transcript hashes, etc. Proposals and Commits can be initialized key schedule, transcript hashes, etc. Proposals and Commits can be
generated for this group state just like any other state of the group, such as generated for this group state just like any other state of the group, such as
Add proposals and Commits to add other members to the group. A GroupInfo object Add proposals and Commits to add other members to the group. A GroupInfo object
for this group state can also be published to facilitate external joins.</t> for this group state can also be published to facilitate external joins.</t>
<t>Members other than the creator join either by being sent a Welcome mess <t indent="0" pn="section-11-7">Members other than the creator join either
age (as by being sent a Welcome message (as
described in <xref target="joining-via-welcome-message"/>) or by sending an exte described in <xref target="joining-via-welcome-message" format="default" section
rnal Commit Format="of" derivedContent="Section 12.4.3.1"/>) or by sending an external Commi
(see <xref target="joining-via-external-commits"/>).</t> t
<t>In principle, the above process could be streamlined by having the (see <xref target="joining-via-external-commits" format="default" sectionFormat=
"of" derivedContent="Section 12.4.3.2"/>).</t>
<t indent="0" pn="section-11-8">In principle, the above process could be s
treamlined by having the
creator directly create a tree and choose a random value for first creator directly create a tree and choose a random value for first
epoch's epoch secret. We follow the steps above because it removes epoch's epoch secret. We follow the steps above because it removes
unnecessary choices, by which, for example, bad randomness could be unnecessary choices, by which, for example, bad randomness could be
introduced. The only choices the creator makes here are its own introduced. The only choices the creator makes here are its own
KeyPackage and the leaf secret from which the Commit is built.</t> KeyPackage and the leaf secret from which the Commit is built.</t>
<section anchor="required-capabilities"> <section anchor="required-capabilities" numbered="true" removeInRFC="false
<name>Required Capabilities</name> " toc="include" pn="section-11.1">
<t>The configuration of a group imposes certain requirements on clients <name slugifiedName="name-required-capabilities">Required Capabilities</
in the name>
group. At a minimum, all members of the group need to support the ciphersuite <t indent="0" pn="section-11.1-1">The configuration of a group imposes c
ertain requirements on clients in the
group. At a minimum, all members of the group need to support the cipher suite
and protocol version in use. Additional requirements can be imposed by and protocol version in use. Additional requirements can be imposed by
including a <tt>required_capabilities</tt> extension in the GroupContext.</t> including a <tt>required_capabilities</tt> extension in the GroupContext.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-11.1-2">
struct { struct {
ExtensionType extension_types<V>; ExtensionType extension_types&lt;V&gt;;
ProposalType proposal_types<V>; ProposalType proposal_types&lt;V&gt;;
CredentialType credential_types<V>; CredentialType credential_types&lt;V&gt;;
} RequiredCapabilities; } RequiredCapabilities;
]]></sourcecode> </sourcecode>
<t>This extension lists the extensions, proposals, and credential types <t indent="0" pn="section-11.1-3">This extension lists the extensions, p
that must be supported by roposals, and credential types that must be supported by
all members of the group. The "default" proposal and extension types defined in this 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 document are assumed to be implemented by all clients, and need not be listed in
RequiredCapabilities in order to be safely used. Note that this is not true for RequiredCapabilities in order to be safely used. Note that this is not true for
credential types.</t> credential types.</t>
<t>For new members, support for required capabilities is enforced by exi sting <t indent="0" pn="section-11.1-4">For new members, support for required capabilities is enforced by existing
members during the application of Add commits. Existing members should of 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 course be in compliance already. In order to ensure this continues to be the
case even as the group's extensions are updated, a GroupContextExtensions case even as the group's extensions are updated, a GroupContextExtensions
proposal is deemed invalid if it contains a <tt>required_capabilities</tt> exten sion that proposal is deemed invalid if it contains a <tt>required_capabilities</tt> exten sion that
requires non-default capabilities not supported by all current members.</t> requires non-default capabilities not supported by all current members.</t>
</section> </section>
<section anchor="reinitialization"> <section anchor="reinitialization" numbered="true" removeInRFC="false" toc
<name>Reinitialization</name> ="include" pn="section-11.2">
<t>A group may be reinitialized by creating a new group with the same me <name slugifiedName="name-reinitialization">Reinitialization</name>
mbership <t indent="0" pn="section-11.2-1">A group may be reinitialized by creati
ng a new group with the same membership
and different parameters, and linking it to the old group via a resumption PSK. 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:</t> The members of a group reinitialize it using the following steps:</t>
<ol spacing="normal" type="1"><li>A member of the old group sends a ReIn <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-11
it proposal (see <xref target="reinit"/>)</li> .2-2">
<li>A member of the old group sends a Commit covering the ReInit propo <li pn="section-11.2-2.1" derivedCounter="1.">A member of the old grou
sal</li> p sends a ReInit proposal (see <xref target="reinit" format="default" sectionFor
<li> mat="of" derivedContent="Section 12.1.5"/>).</li>
<t>A member of the old group creates an initial Commit setting up a <li pn="section-11.2-2.2" derivedCounter="2.">A member of the old grou
new group p sends a Commit covering the ReInit proposal.</li>
that matches the ReInit and sends a Welcome message <li pn="section-11.2-2.3" derivedCounter="3.">
<t indent="0" pn="section-11.2-2.3.1">A member of the old group crea
tes an initial Commit that sets up a new group
that matches the ReInit and sends a Welcome message:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>The <tt>version</tt>, <tt>cipher_suite</tt>, <tt>group_id</tt> on-11.2-2.3.2">
, and <tt>extensions</tt> fields of the GroupContext object in the Welcome <li pn="section-11.2-2.3.2.1">The <tt>version</tt>, <tt>cipher_sui
message MUST be the same as the corresponding fields in the ReInit te</tt>, <tt>group_id</tt>, and <tt>extensions</tt> fields of the GroupContext o
proposal. The <tt>epoch</tt> in the Welcome message MUST be 1.</li> bject in the Welcome
<li>The Welcome MUST specify a PreSharedKeyID of type <tt>resumpti message <bcp14>MUST</bcp14> be the same as the corresponding fields in the ReIni
on</tt> with usage t
proposal. The <tt>epoch</tt> in the Welcome message <bcp14>MUST</bcp14> be 1.</l
i>
<li pn="section-11.2-2.3.2.2">The Welcome message <bcp14>MUST</bcp
14> specify a PreSharedKeyID of type <tt>resumption</tt> with usage
<tt>reinit</tt>, where the <tt>group_id</tt> field matches the old group and the <tt>epoch</tt> <tt>reinit</tt>, where the <tt>group_id</tt> field matches the old group and the <tt>epoch</tt>
field indicates the epoch after the Commit covering the ReInit.</li> field indicates the epoch after the Commit covering the ReInit.</li>
</ul> </ul>
</li> </li>
</ol> </ol>
<t>Note that these three steps may be done by the same group member or d ifferent <t indent="0" pn="section-11.2-3">Note that these three steps may be don e by the same group member or different
members. For example, if a group member sends a Commit with an inline ReInit 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 proposal (steps 1 and 2) but then goes offline, another group member may
recreate the group instead. This flexibility avoids situations where a group recreate the group instead. This flexibility avoids situations where a group
gets stuck between steps 2 and 3.</t> gets stuck between steps 2 and 3.</t>
<t>Resumption PSKs with usage <tt>reinit</tt> MUST NOT be used in other <t indent="0" pn="section-11.2-4">Resumption PSKs with usage <tt>reinit<
contexts. A /tt> <bcp14>MUST NOT</bcp14> be used in other contexts. A
PreSharedKey proposal with type <tt>resumption</tt> and usage <tt>reinit</tt> MU PreSharedKey proposal with type <tt>resumption</tt> and usage <tt>reinit</tt> <b
ST be cp14>MUST</bcp14> be
considered invalid.</t> considered invalid.</t>
</section> </section>
<section anchor="subgroup-branching"> <section anchor="subgroup-branching" numbered="true" removeInRFC="false" t
<name>Subgroup Branching</name> oc="include" pn="section-11.3">
<t>A new group can be formed from a subset of an existing group's member <name slugifiedName="name-subgroup-branching">Subgroup Branching</name>
s, using <t indent="0" pn="section-11.3-1">A new group can be formed from a subse
t of an existing group's members, using
the same parameters as the old group.</t> the same parameters as the old group.</t>
<t>A member can create a subgroup by performing the following steps:</t> <t indent="0" pn="section-11.3-2">A member can create a subgroup by perf
<ol spacing="normal" type="1"><li>Fetch a new KeyPackage for each group orming the following steps:</t>
member that should be included in the <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-11
.3-3">
<li pn="section-11.3-3.1" derivedCounter="1.">Fetch a new KeyPackage f
or each group member that should be included in the
subgroup.</li> subgroup.</li>
<li>Create an initial Commit message that sets up the new group and co ntains a <li pn="section-11.3-3.2" derivedCounter="2.">Create an initial Commit message that sets up the new group and contains a
PreSharedKey proposal of type <tt>resumption</tt> with usage <tt>branch</tt>. To avoid key PreSharedKey proposal of type <tt>resumption</tt> with usage <tt>branch</tt>. To avoid key
re-use, the <tt>psk_nonce</tt> included in the <tt>PreSharedKeyID</tt> object MU ST be a reuse, the <tt>psk_nonce</tt> included in the PreSharedKeyID object <bcp14>MUST< /bcp14> be a
randomly sampled nonce of length <tt>KDF.Nh</tt>.</li> randomly sampled nonce of length <tt>KDF.Nh</tt>.</li>
<li>Send the corresponding Welcome message to the subgroup members.</l i> <li pn="section-11.3-3.3" derivedCounter="3.">Send the corresponding W elcome message to the subgroup members.</li>
</ol> </ol>
<t>A client receiving a Welcome including a PreSharedKey of type <tt>res <t indent="0" pn="section-11.3-4">A client receiving a Welcome message i
umption</tt> with ncluding a PreSharedKey of type <tt>resumption</tt> with
usage <tt>branch</tt> MUST verify that the new group reflects a subgroup branche usage <tt>branch</tt> <bcp14>MUST</bcp14> verify that the new group reflects a s
d from ubgroup branched from
the referenced group by checking:</t> the referenced group by checking that:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>The <tt>version</tt> and <tt>ciphersuite</tt> values in the Welcom 1.3-5">
e are the same as <li pn="section-11.3-5.1">The <tt>version</tt> and <tt>cipher_suite</t
t> values in the Welcome message are the same as
those used by the old group.</li> those used by the old group.</li>
<li>The <tt>epoch</tt> in the Welcome message MUST be 1.</li> <li pn="section-11.3-5.2">The <tt>epoch</tt> in the Welcome message <b
<li>Each LeafNode in a new subgroup MUST match some LeafNode in the or cp14>MUST</bcp14> be 1.</li>
iginal <li pn="section-11.3-5.3">Each LeafNode in a new subgroup <bcp14>MUST<
/bcp14> match some LeafNode in the original
group. In this context, a pair of LeafNodes is said to "match" if the group. In this context, a pair of LeafNodes is said to "match" if the
identifiers presented by their respective credentials are considered identifiers presented by their respective credentials are considered
equivalent by the application.</li> equivalent by the application.</li>
</ul> </ul>
<t>Resumption PSKs with usage <tt>branch</tt> MUST NOT be used in other <t indent="0" pn="section-11.3-6">Resumption PSKs with usage <tt>branch<
contexts. A /tt> <bcp14>MUST NOT</bcp14> be used in other contexts. A
PreSharedKey proposal with type <tt>resumption</tt> and usage <tt>branch</tt> MU PreSharedKey proposal with type <tt>resumption</tt> and usage <tt>branch</tt> <b
ST be cp14>MUST</bcp14> be
considered invalid.</t> considered invalid.</t>
</section> </section>
</section> </section>
<section anchor="group-evolution"> <section anchor="group-evolution" numbered="true" removeInRFC="false" toc="i
<name>Group Evolution</name> nclude" pn="section-12">
<t>Over the lifetime of a group, its membership can change, and existing m <name slugifiedName="name-group-evolution">Group Evolution</name>
embers <t indent="0" pn="section-12-1">Over the lifetime of a group, its membersh
ip can change, and existing members
might want to change their keys in order to achieve post-compromise security. might want to change their keys in order to achieve post-compromise security.
In MLS, each such change is accomplished by a two-step process:</t> In MLS, each such change is accomplished by a two-step process:</t>
<ol spacing="normal" type="1"><li>A proposal to make the change is broadca <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-12-2
st to the group in a Proposal message</li> ">
<li>A member of the group or a new member broadcasts a Commit message th <li pn="section-12-2.1" derivedCounter="1.">A proposal to make the chang
at causes e is broadcast to the group in a Proposal
one or more proposed changes to enter into effect</li> message.</li>
<li pn="section-12-2.2" derivedCounter="2.">A member of the group or a n
ew member broadcasts a Commit message that causes
one or more proposed changes to enter into effect.</li>
</ol> </ol>
<t>In cases where the Proposal and Commit are sent by the same member, the se two steps <t indent="0" pn="section-12-3">In cases where the Proposal and Commit are sent by the same member, these two steps
can be combined by sending the proposals in the commit.</t> can be combined by sending the proposals in the commit.</t>
<t>The group thus evolves from one cryptographic state to another each tim e a <t indent="0" pn="section-12-4">The group thus evolves from one cryptograp hic state to another each time a
Commit message is sent and processed. These states are referred to as "epochs" Commit message is sent and processed. These states are referred to as "epochs"
and are uniquely identified among states of the group by eight-octet epoch value s. and are uniquely identified among states of the group by eight-octet epoch value s.
When a new group is initialized, its initial state epoch is 0x0000000000000000. Each time When a new group is initialized, its initial state epoch is 0x0000000000000000. Each time
a state transition occurs, the epoch number is incremented by one.</t> a state transition occurs, the epoch number is incremented by one.</t>
<section anchor="proposals"> <section anchor="proposals" numbered="true" removeInRFC="false" toc="inclu
<name>Proposals</name> de" pn="section-12.1">
<t>Proposals are included in a FramedContent by way of a Proposal struct <name slugifiedName="name-proposals">Proposals</name>
ure <t indent="0" pn="section-12.1-1">Proposals are included in a FramedCont
ent by way of a Proposal structure
that indicates their type:</t> that indicates their type:</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-12.1-2">
// See IANA registry for registered values // See the "MLS Proposal Types" IANA registry for values
uint16 ProposalType; uint16 ProposalType;
struct { struct {
ProposalType proposal_type; ProposalType proposal_type;
select (Proposal.proposal_type) { select (Proposal.proposal_type) {
case add: Add; case add: Add;
case update: Update; case update: Update;
case remove: Remove; case remove: Remove;
case psk: PreSharedKey; case psk: PreSharedKey;
case reinit: ReInit; case reinit: ReInit;
case external_init: ExternalInit; case external_init: ExternalInit;
case group_context_extensions: GroupContextExtensions; case group_context_extensions: GroupContextExtensions;
}; };
} Proposal; } Proposal;
]]></sourcecode> </sourcecode>
<t>On receiving a FramedContent containing a Proposal, a client MUST ver <t indent="0" pn="section-12.1-3">On receiving a FramedContent containin
ify the g a Proposal, a client <bcp14>MUST</bcp14> verify the
signature inside FramedContentAuthData and that the <tt>epoch</tt> field of the enclosing signature inside FramedContentAuthData and that the <tt>epoch</tt> field of the enclosing
FramedContent is equal to the <tt>epoch</tt> field of the current GroupContext o bject. FramedContent is equal to the <tt>epoch</tt> field of the current GroupContext o bject.
If the verification is successful, then the Proposal should be cached in such a way If the verification is successful, then the Proposal should be cached in such a way
that it can be retrieved by hash (as a ProposalOrRef object) in a later Commit m essage.</t> that it can be retrieved by hash (as a ProposalOrRef object) in a later Commit m essage.</t>
<section anchor="add"> <section anchor="add" numbered="true" removeInRFC="false" toc="include"
<name>Add</name> pn="section-12.1.1">
<t>An Add proposal requests that a client with a specified KeyPackage <name slugifiedName="name-add">Add</name>
be added <t indent="0" pn="section-12.1.1-1">An Add proposal requests that a cl
ient with a specified KeyPackage be added
to the group.</t> to the group.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-12.1.1 -2">
struct { struct {
KeyPackage key_package; KeyPackage key_package;
} Add; } Add;
]]></sourcecode> </sourcecode>
<t>An Add proposal is invalid if the KeyPackage is invalid according t <t indent="0" pn="section-12.1.1-3">An Add proposal is invalid if the
o KeyPackage is invalid according to
<xref target="keypackage-validation"/>.</t> <xref target="keypackage-validation" format="default" sectionFormat="of" derived
<t>An Add is applied after being included in a Commit message. The po Content="Section 10.1"/>.</t>
sition of the <t indent="0" pn="section-12.1.1-4">An Add is applied after being incl
uded in a Commit message. The position of the
Add in the list of proposals determines the leaf node where the new member will Add in the list of proposals determines the leaf node where the new member will
be added. For the first Add in the Commit, the corresponding new member will be be added. For the first Add in the Commit, the corresponding new member will be
placed in the leftmost empty leaf in the tree, for the second Add, the next placed in the leftmost empty leaf in the tree, for the second Add, the next
empty leaf to the right, etc. If no empty leaf exists, the tree is extended to empty leaf to the right, etc. If no empty leaf exists, the tree is extended to
the right.</t> the right.</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>Identify the leaf L for the new member: if there are empty leave -12.1.1-5">
s in the tree, <li pn="section-12.1.1-5.1">Identify the leaf L for the new member:
if there are empty leaves in the tree,
L is the leftmost empty leaf. Otherwise, the tree is extended to the right as L is the leftmost empty leaf. Otherwise, the tree is extended to the right as
described in <xref target="adding-and-removing-leaves"/> and L is assigned the l eftmost new described in <xref target="adding-and-removing-leaves" format="default" sectionF ormat="of" derivedContent="Section 7.7"/>, and L is assigned the leftmost new
blank leaf.</li> blank leaf.</li>
<li>For each non-blank intermediate node along the path from the lea f L <li pn="section-12.1.1-5.2">For each non-blank intermediate node alo ng the path from the leaf L
to the root, add L's leaf index to the <tt>unmerged_leaves</tt> list for the nod e.</li> to the root, add L's leaf index to the <tt>unmerged_leaves</tt> list for the nod e.</li>
<li>Set the leaf node L to a new node containing the LeafNode object carried in <li pn="section-12.1.1-5.3">Set the leaf node L to a new node contai ning the LeafNode object carried in
the <tt>leaf_node</tt> field of the KeyPackage in the Add.</li> the <tt>leaf_node</tt> field of the KeyPackage in the Add.</li>
</ul> </ul>
</section> </section>
<section anchor="update"> <section anchor="update" numbered="true" removeInRFC="false" toc="includ
<name>Update</name> e" pn="section-12.1.2">
<t>An Update proposal is a similar mechanism to Add with the distincti <name slugifiedName="name-update">Update</name>
on <t indent="0" pn="section-12.1.2-1">An Update proposal is a similar me
chanism to Add with the distinction
that it replaces the sender's LeafNode in the tree instead of adding a new leaf that it replaces the sender's LeafNode in the tree instead of adding a new leaf
to the tree.</t> to the tree.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-12.1.2 -2">
struct { struct {
LeafNode leaf_node; LeafNode leaf_node;
} Update; } Update;
]]></sourcecode> </sourcecode>
<t>An Update proposal is invalid if the LeafNode is invalid for an Upd <t indent="0" pn="section-12.1.2-3">An Update proposal is invalid if t
ate he LeafNode is invalid for an Update
proposal according to <xref target="leaf-node-validation"/>.</t> proposal according to <xref target="leaf-node-validation" format="default" secti
<t>A member of the group applies an Update message by taking the follo onFormat="of" derivedContent="Section 7.3"/>.</t>
wing steps:</t> <t indent="0" pn="section-12.1.2-4">A member of the group applies an U
<ul spacing="normal"> pdate message by taking the following steps:</t>
<li>Replace the sender's LeafNode with the one contained in the Upda <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
te proposal</li> -12.1.2-5">
<li>Blank the intermediate nodes along the path from the sender's le <li pn="section-12.1.2-5.1">Replace the sender's LeafNode with the o
af to the root</li> ne contained in the Update proposal.</li>
<li pn="section-12.1.2-5.2">Blank the intermediate nodes along the p
ath from the sender's leaf to the
root.</li>
</ul> </ul>
</section> </section>
<section anchor="remove"> <section anchor="remove" numbered="true" removeInRFC="false" toc="includ
<name>Remove</name> e" pn="section-12.1.3">
<t>A Remove proposal requests that the member with the leaf index <tt> <name slugifiedName="name-remove">Remove</name>
removed</tt> be removed <t indent="0" pn="section-12.1.3-1">A Remove proposal requests that th
e member with the leaf index <tt>removed</tt> be removed
from the group.</t> from the group.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-12.1.3 -2">
struct { struct {
uint32 removed; uint32 removed;
} Remove; } Remove;
]]></sourcecode> </sourcecode>
<t>A Remove proposal is invalid if the <tt>removed</tt> field does not <t indent="0" pn="section-12.1.3-3">A Remove proposal is invalid if th
identify a non-blank e <tt>removed</tt> field does not identify a non-blank
leaf node.</t> leaf node.</t>
<t>A member of the group applies a Remove message by taking the follow <t indent="0" pn="section-12.1.3-4">A member of the group applies a Re
ing steps:</t> move message by taking the following steps:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>Identify the leaf node matching <tt>removed</tt>. Let L be this -12.1.3-5">
leaf node.</li> <li pn="section-12.1.3-5.1">Identify the leaf node matching <tt>remo
<li>Replace the leaf node L with a blank node</li> ved</tt>. Let L be this leaf node.</li>
<li>Blank the intermediate nodes along the path from L to the root</ <li pn="section-12.1.3-5.2">Replace the leaf node L with a blank nod
li> e.</li>
<li>Truncate the tree by removing the right subtree until there is a <li pn="section-12.1.3-5.3">Blank the intermediate nodes along the p
t least one ath from L to the root.</li>
<li pn="section-12.1.3-5.4">Truncate the tree by removing the right
subtree until there is at least one
non-blank leaf node in the right subtree. If the rightmost non-blank leaf has non-blank leaf node in the right subtree. If the rightmost non-blank leaf has
index L, then this will result in the tree having <tt>2^d</tt> leaves, where <tt index L, then this will result in the tree having 2<sup>d</sup> leaves, where <t
>d</tt> is t>d</tt> is
the smallest value such that <tt>2^d &gt; L</tt>.</li> the smallest value such that 2<sup>d</sup> &gt; <tt>L</tt>.</li>
</ul> </ul>
</section> </section>
<section anchor="presharedkey"> <section anchor="presharedkey" numbered="true" removeInRFC="false" toc="
<name>PreSharedKey</name> include" pn="section-12.1.4">
<t>A PreSharedKey proposal can be used to request that a pre-shared ke <name slugifiedName="name-presharedkey">PreSharedKey</name>
y be <t indent="0" pn="section-12.1.4-1">A PreSharedKey proposal can be use
d to request that a pre-shared key be
injected into the key schedule in the process of advancing the epoch.</t> injected into the key schedule in the process of advancing the epoch.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-12.1.4 -2">
struct { struct {
PreSharedKeyID psk; PreSharedKeyID psk;
} PreSharedKey; } PreSharedKey;
]]></sourcecode> </sourcecode>
<t>A PreSharedKey proposal is invalid if any of the following is true: <t indent="0" pn="section-12.1.4-3">A PreSharedKey proposal is invalid
</t> if any of the following is true:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>The PreSharedKey proposal is not being processed as part of a re -12.1.4-4">
initialization <li pn="section-12.1.4-4.1">The PreSharedKey proposal is not being p
of the group (see <xref target="reinitialization"/>), and the PreSharedKeyID has rocessed as part of a reinitialization
<tt>psktype</tt> of the group (see <xref target="reinitialization" format="default" sectionFormat
="of" derivedContent="Section 11.2"/>), and the PreSharedKeyID has <tt>psktype</
tt>
set to <tt>resumption</tt> and <tt>usage</tt> set to <tt>reinit</tt>.</li> set to <tt>resumption</tt> and <tt>usage</tt> set to <tt>reinit</tt>.</li>
<li>The PreSharedKey proposal is not being processed as part of a su <li pn="section-12.1.4-4.2">The PreSharedKey proposal is not being p
bgroup rocessed as part of a subgroup
branching operation (see <xref target="subgroup-branching"/>), and the PreShared branching operation (see <xref target="subgroup-branching" format="default" sect
KeyID has ionFormat="of" derivedContent="Section 11.3"/>), and the PreSharedKeyID has
<tt>psktype</tt> set to <tt>resumption</tt> and <tt>usage</tt> set to <tt>branch </tt>.</li> <tt>psktype</tt> set to <tt>resumption</tt> and <tt>usage</tt> set to <tt>branch </tt>.</li>
<li>The <tt>psk_nonce</tt> is not of length <tt>KDF.Nh</tt>.</li> <li pn="section-12.1.4-4.3">The <tt>psk_nonce</tt> is not of length <tt>KDF.Nh</tt>.</li>
</ul> </ul>
<t>The <tt>psk_nonce</tt> MUST be randomly sampled. When processing <t indent="0" pn="section-12.1.4-5">The <tt>psk_nonce</tt> <bcp14>MUST </bcp14> be randomly sampled. When processing
a Commit message that includes one or more PreSharedKey proposals, group a Commit message that includes one or more PreSharedKey proposals, group
members derive <tt>psk_secret</tt> as described in <xref target="pre-shared-keys members derive <tt>psk_secret</tt> as described in <xref target="pre-shared-keys
"/>, where the " format="default" sectionFormat="of" derivedContent="Section 8.4"/>, where the
order of the PSKs corresponds to the order of the <tt>PreSharedKey</tt> proposal order of the PSKs corresponds to the order of the PreSharedKey proposals
s
in the Commit.</t> in the Commit.</t>
</section> </section>
<section anchor="reinit"> <section anchor="reinit" numbered="true" removeInRFC="false" toc="includ
<name>ReInit</name> e" pn="section-12.1.5">
<t>A ReInit proposal represents a request to reinitialize the group wi <name slugifiedName="name-reinit">ReInit</name>
th different <t indent="0" pn="section-12.1.5-1">A ReInit proposal represents a req
uest to reinitialize the group with different
parameters, for example, to increase the version number or to change the parameters, for example, to increase the version number or to change the
ciphersuite. The reinitialization is done by creating a completely new group cipher suite. The reinitialization is done by creating a completely new group
and shutting down the old one.</t> and shutting down the old one.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-12.1.5 -2">
struct { struct {
opaque group_id<V&gt;; opaque group_id<V&gt;;
ProtocolVersion version; ProtocolVersion version;
CipherSuite cipher_suite; CipherSuite cipher_suite;
Extension extensions<V&gt;; Extension extensions<V&gt;;
} ReInit; } ReInit;
]]></sourcecode> </sourcecode>
<t>A ReInit proposal is invalid if the <tt>version</tt> field is less <t indent="0" pn="section-12.1.5-3">A ReInit proposal is invalid if th
than the version e <tt>version</tt> field is less than the version
for the current group.</t> for the current group.</t>
<t>A member of the group applies a ReInit proposal by waiting for the committer to <t indent="0" pn="section-12.1.5-4">A member of the group applies a Re Init proposal by waiting for the committer to
send the Welcome message that matches the ReInit, according to the criteria in send the Welcome message that matches the ReInit, according to the criteria in
<xref target="reinitialization"/>.</t> <xref target="reinitialization" format="default" sectionFormat="of" derivedConte nt="Section 11.2"/>.</t>
</section> </section>
<section anchor="externalinit"> <section anchor="externalinit" numbered="true" removeInRFC="false" toc="
<name>ExternalInit</name> include" pn="section-12.1.6">
<t>An ExternalInit proposal is used by new members that want to join a <name slugifiedName="name-externalinit">ExternalInit</name>
group by <t indent="0" pn="section-12.1.6-1">An ExternalInit proposal is used b
y new members that want to join a group by
using an external commit. This proposal can only be used in that context.</t> using an external commit. This proposal can only be used in that context.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-12.1.6 -2">
struct { struct {
opaque kem_output<V&gt;; opaque kem_output<V&gt;;
} ExternalInit; } ExternalInit;
]]></sourcecode> </sourcecode>
<t>A member of the group applies an ExternalInit message by initializi <t indent="0" pn="section-12.1.6-3">A member of the group applies an E
ng the next xternalInit message by initializing the next
epoch using an init secret computed as described in <xref target="external-initi epoch using an init secret computed as described in <xref target="external-initi
alization"/>. alization" format="default" sectionFormat="of" derivedContent="Section 8.3"/>.
The <tt>kem_output</tt> field contains the required KEM output.</t> The <tt>kem_output</tt> field contains the required KEM output.</t>
</section> </section>
<section anchor="groupcontextextensions"> <section anchor="groupcontextextensions" numbered="true" removeInRFC="fa
<name>GroupContextExtensions</name> lse" toc="include" pn="section-12.1.7">
<t>A GroupContextExtensions proposal is used to update the list of ext <name slugifiedName="name-groupcontextextensions">GroupContextExtensio
ensions in ns</name>
<t indent="0" pn="section-12.1.7-1">A GroupContextExtensions proposal
is used to update the list of extensions in
the GroupContext for the group.</t> the GroupContext for the group.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-12.1.7 -2">
struct { struct {
Extension extensions<V&gt;; Extension extensions<V&gt;;
} GroupContextExtensions; } GroupContextExtensions;
]]></sourcecode> </sourcecode>
<t>A GroupContextExtensions proposal is invalid if it includes a <t indent="0" pn="section-12.1.7-3">A GroupContextExtensions proposal
is invalid if it includes a
<tt>required_capabilities</tt> extension and some members of the group do not su pport <tt>required_capabilities</tt> extension and some members of the group do not su pport
some of the required capabilities (including those added in the same commit, some of the required capabilities (including those added in the same Commit,
and excluding those removed).</t> and excluding those removed).</t>
<t>A member of the group applies a GroupContextExtensions proposal wit h the <t indent="0" pn="section-12.1.7-4">A member of the group applies a Gr oupContextExtensions proposal with the
following steps:</t> following steps:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>Remove all of the existing extensions from the GroupContext obje -12.1.7-5">
ct for the <li pn="section-12.1.7-5.1">Remove all of the existing extensions fr
group and replacing them with the list of extensions in the proposal. (This om the GroupContext object for the
group and replace them with the list of extensions in the proposal. (This
is a wholesale replacement, not a merge. An extension is only carried over if 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.)</li> the sender of the proposal includes it in the new list.)</li>
</ul> </ul>
<t>Note that once the GroupContext is updated, its inclusion in the <t indent="0" pn="section-12.1.7-6">Note that once the GroupContext is updated, its inclusion in the
<tt>confirmation_tag</tt> by way of the key schedule will confirm that all membe rs of the <tt>confirmation_tag</tt> by way of the key schedule will confirm that all membe rs of the
group agree on the extensions in use.</t> group agree on the extensions in use.</t>
</section> </section>
<section anchor="external-proposals"> <section anchor="external-proposals" numbered="true" removeInRFC="false"
<name>External Proposals</name> toc="include" pn="section-12.1.8">
<t>Proposals can be constructed and sent to the group by a party <name slugifiedName="name-external-proposals">External Proposals</name
that is outside the group in two cases. One case, indicated by an <tt>external</ >
tt> SenderType <t indent="0" pn="section-12.1.8-1">Proposals can be constructed and s
is useful in cases where, for example, an automated service might propose to ent to the group by a party
remove a member of a group who has been inactive for a long time, or propose add that is outside the group in two cases. One case, indicated by the <tt>external<
ing /tt> SenderType,
a newly-hired staff member to a group representing a real-world team. allows an entity outside the group to submit proposals to the group.
An <tt>external</tt> sender might send a ReInit proposal, to enforce a changed p For example, an automated service might propose
olicy removing a member of a group who has been inactive for a long time, or propose a
regarding MLS version or ciphersuite.</t> dding
<t>The <tt>external</tt> SenderType requires that signers are pre-prov a newly hired staff member to a group representing a real-world team.
isioned An <tt>external</tt> sender might send a ReInit proposal to enforce a changed po
licy
regarding MLS versions or cipher suites.</t>
<t indent="0" pn="section-12.1.8-2">The <tt>external</tt> SenderType r
equires that signers are pre-provisioned
to the clients within a group and can only be used if the to the clients within a group and can only be used if the
<tt>external_senders</tt> extension is present in the group's GroupContext.</t> <tt>external_senders</tt> extension is present in the group's GroupContext.</t>
<t>The other case, indicated by a <tt>new_member_proposal</tt> SenderT <t indent="0" pn="section-12.1.8-3">The other case, indicated by the <
ype is useful when tt>new_member_proposal</tt> SenderType, is useful
existing members of the group can independently authorize the addition of an when existing members of the group can independently verify that an Add proposal
MLS client proposing it be added to the group. External proposals which are not sent by the new joiner itself (not an existing member) is authorized. External
authorized are considered invalid.</t> proposals that are not authorized are considered invalid.</t>
<t>An external proposal MUST be sent as a PublicMessage object, since <t indent="0" pn="section-12.1.8-4">An external proposal <bcp14>MUST</
the sender bcp14> be sent as a PublicMessage object, since the sender
will not have the keys necessary to construct a PrivateMessage object.</t> will not have the keys necessary to construct a PrivateMessage object.</t>
<t>Some types of proposal cannot be sent by an <tt>external</tt> sende r. Among the <t indent="0" pn="section-12.1.8-5">Proposals of some types cannot be sent by an <tt>external</tt> sender. Among the
proposal types defined in this document, only the following types may be sent by proposal types defined in this document, only the following types may be sent by
an <tt>external</tt> sender:</t> an <tt>external</tt> sender:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li> -12.1.8-6">
<tt>add</tt></li> <li pn="section-12.1.8-6.1">
<li> <tt>add</tt>
<tt>remove</tt></li> </li>
<li> <li pn="section-12.1.8-6.2">
<tt>psk</tt></li> <tt>remove</tt>
<li> </li>
<tt>reinit</tt></li> <li pn="section-12.1.8-6.3">
<li> <tt>psk</tt>
<tt>group_context_extensions</tt></li> </li>
<li pn="section-12.1.8-6.4">
<tt>reinit</tt>
</li>
<li pn="section-12.1.8-6.5">
<tt>group_context_extensions</tt>
</li>
</ul> </ul>
<t>Messages from <tt>external</tt> senders containing proposal types o <t indent="0" pn="section-12.1.8-7">Messages from <tt>external</tt> se
ther than the above nders containing proposal types other than the above
MUST be rejected as malformed. New proposal types defined in the future MUST <bcp14>MUST</bcp14> be rejected as malformed. New proposal types defined in the
define whether they may be sent by <tt>external</tt> senders. A column is defin future <bcp14>MUST</bcp14>
ed in define whether they may be sent by <tt>external</tt> senders. The "Ext" column
the relevant IANA registry (<xref target="mls-proposal-types"/>) to reflect this in
property.</t> the "MLS Proposal Types" registry (<xref target="mls-proposal-types" format="def
<section anchor="external-senders-extension"> ault" sectionFormat="of" derivedContent="Section 17.4"/>) reflects this property
<name>External Senders Extension</name> .</t>
<t>The <tt>external_senders</tt> extension is a group context extens <section anchor="external-senders-extension" numbered="true" removeInR
ion that contains FC="false" toc="exclude" pn="section-12.1.8.1">
<name slugifiedName="name-external-senders-extension">External Sende
rs Extension</name>
<t indent="0" pn="section-12.1.8.1-1">The <tt>external_senders</tt>
extension is a group context extension that contains
the credentials and signature keys of senders that are permitted to send the credentials and signature keys of senders that are permitted to send
external proposals to the group.</t> external proposals to the group.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-12.1 .8.1-2">
struct { struct {
SignaturePublicKey signature_key; SignaturePublicKey signature_key;
Credential credential; Credential credential;
} ExternalSender; } ExternalSender;
ExternalSender external_senders<V>; ExternalSender external_senders&lt;V&gt;;
]]></sourcecode> </sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="proposal-list-validation"> <section anchor="proposal-list-validation" numbered="true" removeInRFC="fa
<name>Proposal List Validation</name> lse" toc="include" pn="section-12.2">
<t>A group member creating a commit and a group member processing a Comm <name slugifiedName="name-proposal-list-validation">Proposal List Valida
it tion</name>
MUST verify that the list of committed proposals is valid using one of the follo <t indent="0" pn="section-12.2-1">A group member creating a Commit and a
wing group member processing a Commit
procedures, depending on whether the commit is external or not. If the list of <bcp14>MUST</bcp14> verify that the list of committed proposals is valid using o
proposals is invalid, then the Commit message MUST be rejected as invalid.</t> ne of the following
<t>For a regular, i.e. not external, commit the list is invalid if any o procedures, depending on whether the Commit is external or not. If the list of
f the following proposals is invalid, then the Commit message <bcp14>MUST</bcp14> be rejected as
occurs:</t> invalid.</t>
<ul spacing="normal"> <t indent="0" pn="section-12.2-2">For a regular, i.e., not external, Com
<li>It contains an individual proposal that is invalid as specified in mit, the list is invalid if any of the
<xref target="proposals"/>.</li> following occurs:</t>
<li>It contains an Update proposal generated by the committer.</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>It contains a Remove proposal that removes the committer.</li> 2.2-3">
<li>It contains multiple Update and/or Remove proposals that apply to <li pn="section-12.2-3.1">It contains an individual proposal that is i
the same leaf. nvalid as specified in <xref target="proposals" format="default" sectionFormat="
If the committer has received multiple such proposals they SHOULD prefer any Rem of" derivedContent="Section 12.1"/>.</li>
ove <li pn="section-12.2-3.2">It contains an Update proposal generated by
the committer.</li>
<li pn="section-12.2-3.3">It contains a Remove proposal that removes t
he committer.</li>
<li pn="section-12.2-3.4">It contains multiple Update and/or Remove pr
oposals that apply to the same leaf.
If the committer has received multiple such proposals they <bcp14>SHOULD</bcp14>
prefer any Remove
received, or the most recent Update if there are no Removes.</li> received, or the most recent Update if there are no Removes.</li>
<li>It contains multiple Add proposals that contain KeyPackages that r epresent the same <li pn="section-12.2-3.5">It contains multiple Add proposals that cont ain KeyPackages that represent the same
client according to the application (for example, identical signature keys).</li > client according to the application (for example, identical signature keys).</li >
<li>It contains an Add proposal with a KeyPackage that represents a cl ient already <li pn="section-12.2-3.6">It contains an Add proposal with a KeyPackag e that represents a client already
in the group according to the application, unless there is a Remove proposal in the group according to the application, unless there is a Remove proposal
in the list removing the matching client from the group.</li> in the list removing the matching client from the group.</li>
<li>It contains multiple PreSharedKey proposals that reference the sam <li pn="section-12.2-3.7">It contains multiple PreSharedKey proposals
e PreSharedKeyID.</li> that reference the same PreSharedKeyID.</li>
<li>It contains multiple GroupContextExtensions proposals.</li> <li pn="section-12.2-3.8">It contains multiple GroupContextExtensions
<li>It contains a ReInit proposal together with any other proposal. If proposals.</li>
the committer has <li pn="section-12.2-3.9">It contains a ReInit proposal together with
received other proposals during the epoch, they SHOULD prefer them over the any other proposal. If the committer has
received other proposals during the epoch, they <bcp14>SHOULD</bcp14> prefer the
m over the
ReInit proposal, allowing the ReInit to be resent and applied in a subsequent ReInit proposal, allowing the ReInit to be resent and applied in a subsequent
epoch.</li> epoch.</li>
<li>It contains an ExternalInit proposal.</li> <li pn="section-12.2-3.10">It contains an ExternalInit proposal.</li>
<li>It contains a proposal with a non-default proposal type that is no <li pn="section-12.2-3.11">It contains a Proposal with a non-default p
t supported by some roposal type that is not supported by some
members of the group that will process the Commit (i.e., members being added members of the group that will process the Commit (i.e., members being added
or removed by the Commit do not need to support the proposal type).</li> or removed by the Commit do not need to support the proposal type).</li>
<li>After processing the commit the ratchet tree is invalid, in partic <li pn="section-12.2-3.12">After processing the Commit the ratchet tre
ular, if it e is invalid, in particular, if it
contains any leaf node that is invalid according to <xref target="leaf-node-vali contains any leaf node that is invalid according to <xref target="leaf-node-vali
dation"/>.</li> dation" format="default" sectionFormat="of" derivedContent="Section 7.3"/>.</li>
</ul> </ul>
<t>An application may extend the above procedure by additional rules, fo r example, <t indent="0" pn="section-12.2-4">An application may extend the above pr ocedure by additional rules, for example,
requiring application-level permissions to add members, or rules concerning requiring application-level permissions to add members, or rules concerning
non-default proposal types.</t> non-default proposal types.</t>
<t>For an external commit, the list is valid if it contains only the fol lowing proposals <t indent="0" pn="section-12.2-5">For an external Commit, the list is va lid if it contains only the following proposals
(not necessarily in this order):</t> (not necessarily in this order):</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>Exactly one ExternalInit</li> 2.2-6">
<li>At most one Remove proposal, with which the joiner removes an <li pn="section-12.2-6.1">Exactly one ExternalInit</li>
<li pn="section-12.2-6.2">At most one Remove proposal, with which the
joiner removes an
old version of themselves. If a Remove proposal is present, then the LeafNode in the old version of themselves. If a Remove proposal is present, then the LeafNode in the
<tt>path</tt> field of the external commit MUST meet the same criteria as would <tt>path</tt> field of the external Commit <bcp14>MUST</bcp14> meet the same cri
the LeafNode teria as would the LeafNode
in an Update for the removed leaf (see <xref target="update"/>). In particular, in an Update for the removed leaf (see <xref target="update" format="default" se
the <tt>credential</tt> ctionFormat="of" derivedContent="Section 12.1.2"/>). In particular, the <tt>cred
in the LeafNode MUST present a set of identifiers that is acceptable to the ential</tt>
in the LeafNode <bcp14>MUST</bcp14> present a set of identifiers that is accepta
ble to the
application for the removed participant.</li> application for the removed participant.</li>
<li>Zero or more PreSharedKey proposals.</li> <li pn="section-12.2-6.3">Zero or more PreSharedKey proposals</li>
<li>No other proposals.</li> <li pn="section-12.2-6.4">No other proposals</li>
</ul> </ul>
<t>Proposal types defined in the future may make updates to the above va lidation <t indent="0" pn="section-12.2-7">Proposal types defined in the future m ay make updates to the above validation
logic to incorporate considerations related to proposals of the new type.</t> logic to incorporate considerations related to proposals of the new type.</t>
</section> </section>
<section anchor="applying-a-proposal-list"> <section anchor="applying-a-proposal-list" numbered="true" removeInRFC="fa
<name>Applying a Proposal List</name> lse" toc="include" pn="section-12.3">
<t>The sections above defining each proposal type describe how each indi <name slugifiedName="name-applying-a-proposal-list">Applying a Proposal
vidual List</name>
<t indent="0" pn="section-12.3-1">The sections above defining each propo
sal type describe how each individual
proposal is applied. When creating or processing a Commit, a client applies a proposal is applied. When creating or processing a Commit, a client applies a
list of proposals to the ratchet tree and GroupContext. The client MUST apply list of proposals to the ratchet tree and GroupContext. The client <bcp14>MUST</ bcp14> apply
the proposals in the list in the following order:</t> the proposals in the list in the following order:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>If there is a GroupContextExtensions proposal, replace the <tt>ext 2.3-2">
ensions</tt> field <li pn="section-12.3-2.1">If there is a GroupContextExtensions proposa
l, replace the <tt>extensions</tt> field
of the GroupContext for the group with the contents of the proposal. The of the GroupContext for the group with the contents of the proposal. The
new <tt>extensions</tt> MUST be used for evaluating other proposals in this list . For new <tt>extensions</tt> <bcp14>MUST</bcp14> be used when evaluating other propos als in this list. For
example, if a GroupContextExtensions proposal adds a <tt>required_capabilities</ tt> example, if a GroupContextExtensions proposal adds a <tt>required_capabilities</ tt>
extension, then any Add proposals need to indicate support for those extension, then any Add proposals need to indicate support for those
capabilities.</li> capabilities.</li>
<li>Apply any Update proposals to the ratchet tree, in any order.</li> <li pn="section-12.3-2.2">Apply any Update proposals to the ratchet tr
<li>Apply any Remove proposals to the ratchet tree, in any order.</li> ee, in any order.</li>
<li>Apply any Add proposals to the ratchet tree, in the order they app <li pn="section-12.3-2.3">Apply any Remove proposals to the ratchet tr
ear in the list.</li> ee, in any order.</li>
<li>Look up the PSK secrets for any PreSharedKey proposals, in the ord <li pn="section-12.3-2.4">Apply any Add proposals to the ratchet tree,
er they in the order they appear in the list.</li>
<li pn="section-12.3-2.5">Look up the PSK secrets for any PreSharedKey
proposals, in the order they
appear in the list. These secrets are then used to advance the key schedule appear in the list. These secrets are then used to advance the key schedule
later in Commit processing.</li> later in Commit processing.</li>
<li>If there is an ExternalInit proposal, use it to derive the <tt>ini t_secret</tt> for <li pn="section-12.3-2.6">If there is an ExternalInit proposal, use it to derive the <tt>init_secret</tt> for
use later in Commit processing.</li> use later in Commit processing.</li>
<li>If there is a ReInit proposal, note its parameters for application later in <li pn="section-12.3-2.7">If there is a ReInit proposal, note its para meters for application later in
Commit processing.</li> Commit processing.</li>
</ul> </ul>
<t>Proposal types defined in the future MUST specify how the above steps are to be <t indent="0" pn="section-12.3-3">Proposal types defined in the future < bcp14>MUST</bcp14> specify how the above steps are to be
adjusted to accommodate the application of proposals of the new type.</t> adjusted to accommodate the application of proposals of the new type.</t>
</section> </section>
<section anchor="commit"> <section anchor="commit" numbered="true" removeInRFC="false" toc="include"
<name>Commit</name> pn="section-12.4">
<t>A Commit message initiates a new epoch for the group, based on a coll <name slugifiedName="name-commit">Commit</name>
ection of <t indent="0" pn="section-12.4-1">A Commit message initiates a new epoch
for the group, based on a collection of
Proposals. It instructs group members to update their representation of the Proposals. It instructs group members to update their representation of the
state of the group by applying the proposals and advancing the key schedule.</t> state of the group by applying the proposals and advancing the key schedule.</t>
<t>Each proposal covered by the Commit is included by a ProposalOrRef va lue, which <t indent="0" pn="section-12.4-2">Each proposal covered by the Commit is included by a ProposalOrRef value, which
identifies the proposal to be applied by value or by reference. Commits that identifies the proposal to be applied by value or by reference. Commits that
refer to new Proposals from the committer can be included by value. Commits refer to new Proposals from the committer can be included by value. Commits
for previously sent proposals from anyone (including the committer) can be sent for previously sent proposals from anyone (including the committer) can be sent
by reference. Proposals sent by reference are specified by including the hash o f by reference. Proposals sent by reference are specified by including the hash o f
the AuthenticatedContent object in which the proposal was sent (see <xref target the AuthenticatedContent object in which the proposal was sent (see <xref target
="hash-based-identifiers"/>).</t> ="hash-based-identifiers" format="default" sectionFormat="of" derivedContent="Se
<sourcecode type="tls"><![CDATA[ ction 5.2"/>).</t>
<sourcecode type="tls-presentation" markers="false" pn="section-12.4-3">
enum { enum {
reserved(0), reserved(0),
proposal(1), proposal(1),
reference(2), reference(2),
(255) (255)
} ProposalOrRefType; } ProposalOrRefType;
struct { struct {
ProposalOrRefType type; ProposalOrRefType type;
select (ProposalOrRef.type) { select (ProposalOrRef.type) {
case proposal: Proposal proposal; case proposal: Proposal proposal;
case reference: ProposalRef reference; case reference: ProposalRef reference;
}; };
} ProposalOrRef; } ProposalOrRef;
struct { struct {
ProposalOrRef proposals<V>; ProposalOrRef proposals&lt;V&gt;;
optional<UpdatePath> path; optional&lt;UpdatePath&gt; path;
} Commit; } Commit;
]]></sourcecode> </sourcecode>
<t>A group member that has observed one or more valid proposals within a <t indent="0" pn="section-12.4-4">A group member that has observed one o
n epoch MUST send r more valid proposals within an epoch <bcp14>MUST</bcp14> send
a Commit message before sending application data. This ensures, for example, a Commit message before sending application data. This ensures, for example,
that any members whose removal was proposed during the epoch are actually that any members whose removal was proposed during the epoch are actually
removed before any application data is transmitted.</t> removed before any application data is transmitted.</t>
<t>A sender and a receiver of a Commit MUST verify that the committed li <t indent="0" pn="section-12.4-5">A sender and a receiver of a Commit <b
st of cp14>MUST</bcp14> verify that the committed list of
proposals is valid as specified in <xref target="proposal-list-validation"/>. A proposals is valid as specified in <xref target="proposal-list-validation" forma
list is invalid if, for example, t="default" sectionFormat="of" derivedContent="Section 12.2"/>. A list is invali
d if, for example,
it includes an Update and a Remove for the same member, or an Add when the sende r does not have it includes an Update and a Remove for the same member, or an Add when the sende r does not have
the application-level permission to add new users.</t> the application-level permission to add new users.</t>
<t>The sender of a Commit SHOULD include all proposals that it has recei <t indent="0" pn="section-12.4-6">The sender of a Commit <bcp14>SHOULD</
ved bcp14> include all proposals that it has received
during the current epoch, that are valid according to the rules for their during the current epoch that are valid according to the rules for their
proposal types and according to application policy, as long as this results in proposal types and according to application policy, as long as this results in
a valid proposal list.</t> a valid proposal list.</t>
<t>Due to the asynchronous nature of proposals, receivers of a Commit SH OULD NOT enforce <t indent="0" pn="section-12.4-7">Due to the asynchronous nature of prop osals, receivers of a Commit <bcp14>SHOULD NOT</bcp14> enforce
that all valid proposals sent within the current epoch are referenced by the nex t that all valid proposals sent within the current epoch are referenced by the nex t
Commit. In the event that a valid proposal is omitted from the next Commit, and Commit. In the event that a valid proposal is omitted from the next Commit, and
that proposal is still valid in the current epoch, the sender of the proposal that proposal is still valid in the current epoch, the sender of the proposal
MAY resend it after updating it to reflect the current epoch.</t> <bcp14>MAY</bcp14> resend it after updating it to reflect the current epoch.</t>
<t>A member of the group MAY send a Commit that references no proposals <t indent="0" pn="section-12.4-8">A member of the group <bcp14>MAY</bcp1
at all, 4> send a Commit that references no proposals at all,
which would thus have an empty <tt>proposals</tt> vector. Such which would thus have an empty <tt>proposals</tt> vector. Such
a Commit resets the sender's leaf and the nodes along its direct path, and a Commit resets the sender's leaf and the nodes along its direct path, and
provides forward secrecy and post-compromise security with regard to the sender provides forward secrecy and post-compromise security with regard to the sender
of the Commit. An Update proposal can be regarded as a "lazy" version of this of the Commit. An Update proposal can be regarded as a "lazy" version of this
operation, where only the leaf changes and intermediate nodes are blanked out.</ t> operation, where only the leaf changes and intermediate nodes are blanked out.</ t>
<t>By default, the <tt>path</tt> field of a Commit MUST be populated. T <t indent="0" pn="section-12.4-9">By default, the <tt>path</tt> field of
he <tt>path</tt> field a Commit <bcp14>MUST</bcp14> be populated. The <tt>path</tt> field
MAY be omitted if (a) it covers at least one proposal and (b) none of the propos <bcp14>MAY</bcp14> be omitted if (a) it covers at least one proposal and (b) non
als e of the proposals
covered by the Commit are of "path required" types. A proposal type requires a covered by the Commit are of "path required" types. A proposal type requires a
path if it cannot change the group membership in a way that requires the forward path if it cannot change the group membership in a way that requires the forward
secrecy and post-compromise security guarantees that an UpdatePath provides. secrecy and post-compromise security guarantees that an UpdatePath provides.
The only proposal types defined in this document that do not require a path are: </t> The only proposal types defined in this document that do not require a path are: </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li> 2.4-10">
<tt>add</tt></li> <li pn="section-12.4-10.1">
<li> <tt>add</tt>
<tt>psk</tt></li> </li>
<li> <li pn="section-12.4-10.2">
<tt>reinit</tt></li> <tt>psk</tt>
</li>
<li pn="section-12.4-10.3">
<tt>reinit</tt>
</li>
</ul> </ul>
<t>New proposal types MUST state whether they require a path. If any ins tance of a <t indent="0" pn="section-12.4-11">New proposal types <bcp14>MUST</bcp14 > state whether they require a path. If any instance of a
proposal type requires a path, then the proposal type requires a path. This proposal type requires a path, then the proposal type requires a path. This
attribute of a proposal type is reflected in the "Path Required" field of the attribute of a proposal type is reflected in the "Path Required" field of the
proposal type registry defined in <xref target="mls-proposal-types"/>.</t> "MLS Proposal Types" registry defined in <xref target="mls-proposal-types" forma
<t>Update and Remove proposals are the clearest examples of proposals th t="default" sectionFormat="of" derivedContent="Section 17.4"/>.</t>
at require <t indent="0" pn="section-12.4-12">Update and Remove proposals are the c
learest examples of proposals that require
a path. An UpdatePath is required to evict the removed member or the old a path. An UpdatePath is required to evict the removed member or the old
appearance of the updated member.</t> appearance of the updated member.</t>
<t>In pseudocode, the logic for validating the <tt>path</tt> field of a Commit is as <t indent="0" pn="section-12.4-13">In pseudocode, the logic for validati ng the <tt>path</tt> field of a Commit is as
follows:</t> follows:</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-12.4-14">
pathRequiredTypes = [ pathRequiredTypes = [
update, update,
remove, remove,
external_init, external_init,
group_context_extensions group_context_extensions
] ]
pathRequired = false pathRequired = false
for proposal in commit.proposals: for proposal in commit.proposals:
pathRequired = pathRequired || pathRequired = pathRequired ||
(proposal.msg_type in pathRequiredTypes) (proposal.msg_type in pathRequiredTypes)
if len(commit.proposals) == 0 || pathRequired: if len(commit.proposals) == 0 || pathRequired:
assert(commit.path != null) assert(commit.path != null)
]]></sourcecode> </sourcecode>
<t>To summarize, a Commit can have three different configurations, with <t indent="0" pn="section-12.4-15">To summarize, a Commit can have three
different different configurations, with different
uses:</t> uses:</t>
<ol spacing="normal" type="1"><li>An "empty" Commit that references no p <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-12
roposals, which updates the committer's .4-16">
<li pn="section-12.4-16.1" derivedCounter="1.">An "empty" Commit that
references no proposals, which updates the committer's
contribution to the group and provides PCS with regard to the committer.</li> contribution to the group and provides PCS with regard to the committer.</li>
<li>A "partial" Commit that references proposals that do not require a <li pn="section-12.4-16.2" derivedCounter="2.">A "partial" Commit that
path, and references proposals that do not require a path, and
where the path is empty. Such a commit doesn't provide PCS with regard to the where the path is empty. Such a Commit doesn't provide PCS with regard to the
committer.</li> committer.</li>
<li>A "full" Commit that references proposals of any type, which provi des FS with <li pn="section-12.4-16.3" derivedCounter="3.">A "full" Commit that re ferences proposals of any type, which provides FS with
regard to any removed members and PCS for the committer and any updated regard to any removed members and PCS for the committer and any updated
members.</li> members.</li>
</ol> </ol>
<section anchor="creating-a-commit"> <section anchor="creating-a-commit" numbered="true" removeInRFC="false"
<name>Creating a Commit</name> toc="include" pn="section-12.4.1">
<t>When creating or processing a Commit, a client updates the ratchet <name slugifiedName="name-creating-a-commit">Creating a Commit</name>
tree and <t indent="0" pn="section-12.4.1-1">When creating or processing a Comm
it, a client updates the ratchet tree and
GroupContext for the group. These values advance from an "old" state reflecting GroupContext for the group. These values advance from an "old" state reflecting
the current epoch to a "new" state reflecting the new epoch initiated by the the current epoch to a "new" state reflecting the new epoch initiated by the
Commit. When the Commit includes an UpdatePath, a "provisional" group context Commit. When the Commit includes an UpdatePath, a "provisional" group context
is constructed that reflects changes due to the proposals and UpdatePath, but is constructed that reflects changes due to the proposals and UpdatePath, but
with the old confirmed transcript hash.</t> with the old confirmed transcript hash.</t>
<t>A member of the group creates a Commit message and the correspondin g Welcome <t indent="0" pn="section-12.4.1-2">A member of the group creates a Co mmit message and the corresponding Welcome
message at the same time, by taking the following steps:</t> message at the same time, by taking the following steps:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>Verify that the list of proposals to be committed is valid as sp -12.4.1-3">
ecified in <li pn="section-12.4.1-3.1">Verify that the list of proposals to be
<xref target="proposal-list-validation"/>.</li> committed is valid as specified in
<li>Construct an initial Commit object with the <tt>proposals</tt> <xref target="proposal-list-validation" format="default" sectionFormat="of" deri
field populated from Proposals received during the current epoch, and an empty vedContent="Section 12.2"/>.</li>
<tt>path</tt> field.</li> <li pn="section-12.4.1-3.2">Construct an initial Commit object with
<li>Create the new ratchet tree and GroupContext by applying the lis the <tt>proposals</tt> field populated from
t of proposals Proposals received during the current epoch, and with the <tt>path</tt> field em
pty.</li>
<li pn="section-12.4.1-3.3">Create the new ratchet tree and GroupCon
text by applying the list of proposals
to the old ratchet tree and GroupContext, as defined in to the old ratchet tree and GroupContext, as defined in
<xref target="applying-a-proposal-list"/></li> <xref target="applying-a-proposal-list" format="default" sectionFormat="of" deri
<li>Decide whether to populate the <tt>path</tt> field: If the <tt>p vedContent="Section 12.3"/>.</li>
ath</tt> field is required <li pn="section-12.4.1-3.4">Decide whether to populate the <tt>path<
based on the proposals that are in the commit (see above), then it MUST be /tt> field: If the <tt>path</tt> field is required
populated. Otherwise, the sender MAY omit the <tt>path</tt> field at its discre based on the proposals that are in the Commit (see above), then it <bcp14>MUST</
tion.</li> bcp14> be
<li> populated. Otherwise, the sender <bcp14>MAY</bcp14> omit the <tt>path</tt> fiel
<t>If populating the <tt>path</tt> field: </t> d at its discretion.</li>
<ul spacing="normal"> <li pn="section-12.4.1-3.5">
<li>If this is an external commit, assign the sender the leftmos <t indent="0" pn="section-12.4.1-3.5.1">If populating the <tt>path
t blank leaf </tt> field: </t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="sec
tion-12.4.1-3.5.2">
<li pn="section-12.4.1-3.5.2.1">If this is an external Commit, a
ssign the sender the leftmost blank leaf
node in the new ratchet tree. If there are no blank leaf nodes in the new node in the new ratchet tree. If there are no blank leaf nodes in the new
ratchet tree, expand the tree to the right as defined in ratchet tree, expand the tree to the right as defined in
<xref target="adding-and-removing-leaves"/> and assign the leftmost new blank le af to the <xref target="adding-and-removing-leaves" format="default" sectionFormat="of" de rivedContent="Section 7.7"/> and assign the leftmost new blank leaf to the
sender.</li> sender.</li>
<li>Update the sender's direct path in the ratchet tree as descr <li pn="section-12.4.1-3.5.2.2">Update the sender's direct path
ibed in in the ratchet tree as described in
<xref target="synchronizing-views-of-the-tree"/>. Define <xref target="synchronizing-views-of-the-tree" format="default" sectionFormat="o
f" derivedContent="Section 7.5"/>. Define
<tt>commit_secret</tt> as the value <tt>path_secret[n+1]</tt> derived from the <tt>commit_secret</tt> as the value <tt>path_secret[n+1]</tt> derived from the
last path secret value (<tt>path_secret[n]</tt>) derived for the UpdatePath.</li > last path secret value (<tt>path_secret[n]</tt>) derived for the UpdatePath.</li >
<li> <li pn="section-12.4.1-3.5.2.3">
<t>Construct a provisional GroupContext object containing the <t indent="0" pn="section-12.4.1-3.5.2.3.1">Construct a provis
following values: ional GroupContext object containing the following values:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn=
<li> "section-12.4.1-3.5.2.3.2">
<li pn="section-12.4.1-3.5.2.3.2.1">
<tt>group_id</tt>: Same as the old GroupContext</li> <tt>group_id</tt>: Same as the old GroupContext</li>
<li> <li pn="section-12.4.1-3.5.2.3.2.2">
<tt>epoch</tt>: The epoch number for the new epoch</li> <tt>epoch</tt>: The epoch number for the new epoch</li>
<li> <li pn="section-12.4.1-3.5.2.3.2.3">
<tt>tree_hash</tt>: The tree hash of the new ratchet tree< /li> <tt>tree_hash</tt>: The tree hash of the new ratchet tree< /li>
<li> <li pn="section-12.4.1-3.5.2.3.2.4">
<tt>confirmed_transcript_hash</tt>: Same as the old GroupC ontext</li> <tt>confirmed_transcript_hash</tt>: Same as the old GroupC ontext</li>
<li> <li pn="section-12.4.1-3.5.2.3.2.5">
<tt>extensions</tt>: The new GroupContext extensions (poss ibly updated by a <tt>extensions</tt>: The new GroupContext extensions (poss ibly updated by a
GroupContextExtensions proposal)</li> GroupContextExtensions proposal)</li>
</ul> </ul>
</li> </li>
<li>Encrypt the path secrets resulting from the tree update to t <li pn="section-12.4.1-3.5.2.4">Encrypt the path secrets resulti
he group as ng from the tree update to the group as
described in <xref target="synchronizing-views-of-the-tree"/>, using the provisi described in <xref target="synchronizing-views-of-the-tree" format="default" sec
onal tionFormat="of" derivedContent="Section 7.5"/>, using the provisional
group context as the context for HPKE encryption.</li> group context as the context for HPKE encryption.</li>
<li>Create an UpdatePath containing the sender's new leaf node a nd the new <li pn="section-12.4.1-3.5.2.5">Create an UpdatePath containing the sender's new leaf node and the new
public keys and encrypted path secrets along the sender's filtered direct public keys and encrypted path secrets along the sender's filtered direct
path. Assign this UpdatePath to the <tt>path</tt> field in the Commit.</li> path. Assign this UpdatePath to the <tt>path</tt> field in the Commit.</li>
</ul> </ul>
</li> </li>
<li>If not populating the <tt>path</tt> field: Set the <tt>path</tt> field in the Commit to the <li pn="section-12.4.1-3.6">If not populating the <tt>path</tt> fiel d: Set the <tt>path</tt> field in the Commit to the
null optional. Define <tt>commit_secret</tt> as the all-zero vector of length null optional. Define <tt>commit_secret</tt> as the all-zero vector of length
<tt>KDF.Nh</tt> (the same length as a <tt>path_secret</tt> value would be).</li> <tt>KDF.Nh</tt> (the same length as a <tt>path_secret</tt> value would be).</li>
<li>Derive the <tt>psk_secret</tt> as specified in <xref target="pre -shared-keys"/>, where the order <li pn="section-12.4.1-3.7">Derive the <tt>psk_secret</tt> as specif ied in <xref target="pre-shared-keys" format="default" sectionFormat="of" derive dContent="Section 8.4"/>, where the order
of PSKs in the derivation corresponds to the order of PreSharedKey proposals of PSKs in the derivation corresponds to the order of PreSharedKey proposals
in the <tt>proposals</tt> vector.</li> in the <tt>proposals</tt> vector.</li>
<li> <li pn="section-12.4.1-3.8">
<t>Construct a FramedContent object containing the Commit object. <t indent="0" pn="section-12.4.1-3.8.1">Construct a FramedContent
Sign the object containing the Commit object. Sign the
FramedContent using the old GroupContext as context. FramedContent using the old GroupContext as context.
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="sec
<li>Use the FramedContent to update the confirmed transcript has tion-12.4.1-3.8.2">
h and update <li pn="section-12.4.1-3.8.2.1">Use the FramedContent to update
the confirmed transcript hash and update
the new GroupContext.</li> the new GroupContext.</li>
<li>Use the <tt>init_secret</tt> from the previous epoch, the <t <li pn="section-12.4.1-3.8.2.2">Use the <tt>init_secret</tt> fro
t>commit_secret</tt> and the m the previous epoch, the <tt>commit_secret</tt> and
<tt>psk_secret</tt> as defined in the previous steps, and the new GroupContext t <tt>psk_secret</tt> defined in the previous steps, and the new GroupContext to
o
compute the new <tt>joiner_secret</tt>, <tt>welcome_secret</tt>, <tt>epoch_secre t</tt>, and compute the new <tt>joiner_secret</tt>, <tt>welcome_secret</tt>, <tt>epoch_secre t</tt>, and
derived secrets for the new epoch.</li> derived secrets for the new epoch.</li>
<li>Use the <tt>confirmation_key</tt> for the new epoch to compu te the <li pn="section-12.4.1-3.8.2.3">Use the <tt>confirmation_key</tt > for the new epoch to compute the
<tt>confirmation_tag</tt> value.</li> <tt>confirmation_tag</tt> value.</li>
<li>Calculate the interim transcript hash using the new confirme d transcript <li pn="section-12.4.1-3.8.2.4">Calculate the interim transcript hash using the new confirmed transcript
hash and the <tt>confirmation_tag</tt> from the FramedContentAuthData.</li> hash and the <tt>confirmation_tag</tt> from the FramedContentAuthData.</li>
</ul> </ul>
</li> </li>
<li> <li pn="section-12.4.1-3.9">
<t>Protect the AuthenticatedContent object using keys from the old <t indent="0" pn="section-12.4.1-3.9.1">Protect the AuthenticatedC
epoch: ontent object using keys from the old epoch:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="sec
<li>If encoding as PublicMessage, compute the <tt>membership_tag tion-12.4.1-3.9.2">
</tt> value using the <li pn="section-12.4.1-3.9.2.1">If encoding as PublicMessage, co
mpute the <tt>membership_tag</tt> value using the
<tt>membership_key</tt>.</li> <tt>membership_key</tt>.</li>
<li>If encoding as a PrivateMessage, encrypt the message using t he <li pn="section-12.4.1-3.9.2.2">If encoding as a PrivateMessage, encrypt the message using the
<tt>sender_data_secret</tt> and the next (key, nonce) pair from the sender's <tt>sender_data_secret</tt> and the next (key, nonce) pair from the sender's
handshake ratchet.</li> handshake ratchet.</li>
</ul> </ul>
</li> </li>
<li> <li pn="section-12.4.1-3.10">
<t>Construct a GroupInfo reflecting the new state: <t indent="0" pn="section-12.4.1-3.10.1">Construct a GroupInfo ref
lecting the new state:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="sec
<li>Group ID, epoch, tree, confirmed transcript hash, interim tr tion-12.4.1-3.10.2">
anscript <li pn="section-12.4.1-3.10.2.1">Set the <tt>group_id</tt>, <tt>
hash, and group context extensions from the new state</li> epoch</tt>, <tt>tree</tt>, <tt>confirmed_transcript_hash</tt>,
<li>The confirmation_tag from the FramedContentAuthData object</ <tt>interim_transcript_hash</tt>, and <tt>group_context_extensions</tt> fields t
li> o reflect
<li>Other extensions as defined by the application</li> the new state.</li>
<li>Optionally derive an external keypair as described in <xref <li pn="section-12.4.1-3.10.2.2">Set the <tt>confirmation_tag</t
target="key-schedule"/> t> field to the value of the corresponding field in
(required for External Commits, see <xref target="joining-via-external-commits"/ the FramedContentAuthData object.</li>
>)</li> <li pn="section-12.4.1-3.10.2.3">Add any other extensions as def
<li>Sign the GroupInfo using the member's private signing key</l ined by the application.</li>
i> <li pn="section-12.4.1-3.10.2.4">Optionally derive an external k
<li>Encrypt the GroupInfo using the key and nonce derived from t ey pair as described in <xref target="key-schedule" format="default" sectionForm
he <tt>joiner_secret</tt> at="of" derivedContent="Section 8"/>.
for the new epoch (see <xref target="joining-via-welcome-message"/>)</li> (required for external Commits, see <xref target="joining-via-external-commits"
format="default" sectionFormat="of" derivedContent="Section 12.4.3.2"/>).</li>
<li pn="section-12.4.1-3.10.2.5">Sign the GroupInfo using the me
mber's private signing key.</li>
<li pn="section-12.4.1-3.10.2.6">Encrypt the GroupInfo using the
key and nonce derived from the <tt>joiner_secret</tt>.
for the new epoch (see <xref target="joining-via-welcome-message" format="defaul
t" sectionFormat="of" derivedContent="Section 12.4.3.1"/>).</li>
</ul> </ul>
</li> </li>
<li> <li pn="section-12.4.1-3.11">
<t>For each new member in the group: <t indent="0" pn="section-12.4.1-3.11.1">For each new member in th
e group:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="sec
<li>Identify the lowest common ancestor in the tree of the new m tion-12.4.1-3.11.2">
ember's <li pn="section-12.4.1-3.11.2.1">Identify the lowest common ance
leaf node and the member sending the Commit</li> stor in the tree of the new member's
<li>If the <tt>path</tt> field was populated above: Compute the leaf node and the member sending the Commit.</li>
path secret <li pn="section-12.4.1-3.11.2.2">If the <tt>path</tt> field was
corresponding to the common ancestor node</li> populated above: Compute the path secret
<li>Compute an EncryptedGroupSecrets object that encapsulates th corresponding to the common ancestor node.</li>
e <tt>init_secret</tt> <li pn="section-12.4.1-3.11.2.3">Compute an EncryptedGroupSecret
s object that encapsulates the <tt>init_secret</tt>
for the current epoch and the path secret (if present).</li> for the current epoch and the path secret (if present).</li>
</ul> </ul>
</li> </li>
<li>Construct one or more Welcome messages from the encrypted GroupI nfo object, <li pn="section-12.4.1-3.12">Construct one or more Welcome messages from the encrypted GroupInfo object,
the encrypted key packages, and any PSKs for which a proposal was included in the encrypted key packages, and any PSKs for which a proposal was included in
the Commit. The order of the <tt>psks</tt> MUST be the same as the order of the Commit. The order of the <tt>psks</tt> <bcp14>MUST</bcp14> be the same as th
PreSharedKey proposals in the <tt>proposals</tt> vector. As discussed on e order of
<xref target="joining-via-welcome-message"/>, the committer is free to choose ho PreSharedKey proposals in the <tt>proposals</tt> vector. As discussed in
w many <xref target="joining-via-welcome-message" format="default" sectionFormat="of" d
erivedContent="Section 12.4.3.1"/>, the committer is free to choose how many
Welcome messages to construct. However, the set of Welcome messages produced Welcome messages to construct. However, the set of Welcome messages produced
in this step MUST cover every new member added in the Commit.</li> in this step <bcp14>MUST</bcp14> cover every new member added in the Commit.</li
<li> >
<t>If a ReInit proposal was part of the Commit, the committer MUST <li pn="section-12.4.1-3.13">
create a new <t indent="0" pn="section-12.4.1-3.13.1">If a ReInit proposal was
part of the Commit, the committer <bcp14>MUST</bcp14> create a new
group with the parameters specified in the ReInit proposal, group with the parameters specified in the ReInit proposal,
and with the same members as the original group. and with the same members as the original group.
The Welcome message MUST include a <tt>PreSharedKeyID</tt> with the following The Welcome message <bcp14>MUST</bcp14> include a PreSharedKeyID with the follow ing
parameters: parameters:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="sec
<li> tion-12.4.1-3.13.2">
<li pn="section-12.4.1-3.13.2.1">
<tt>psktype</tt>: <tt>resumption</tt></li> <tt>psktype</tt>: <tt>resumption</tt></li>
<li> <li pn="section-12.4.1-3.13.2.2">
<tt>usage</tt>: <tt>reinit</tt></li> <tt>usage</tt>: <tt>reinit</tt></li>
<li> <li pn="section-12.4.1-3.13.2.3">
<tt>group_id</tt>: The group ID for the current group</li> <tt>group_id</tt>: The group ID for the current group</li>
<li> <li pn="section-12.4.1-3.13.2.4">
<tt>epoch</tt>: The epoch that the group will be in after this Commit</li> <tt>epoch</tt>: The epoch that the group will be in after this Commit</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="processing-a-commit"> <section anchor="processing-a-commit" numbered="true" removeInRFC="false
<name>Processing a Commit</name> " toc="include" pn="section-12.4.2">
<t>A member of the group applies a Commit message by taking the follow <name slugifiedName="name-processing-a-commit">Processing a Commit</na
ing steps:</t> me>
<ul spacing="normal"> <t indent="0" pn="section-12.4.2-1">A member of the group applies a Co
<li>Verify that the <tt>epoch</tt> field of the enclosing FramedCont mmit message by taking the following steps:</t>
ent is equal <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
to the <tt>epoch</tt> field of the current GroupContext object</li> -12.4.2-2">
<li> <li pn="section-12.4.2-2.1">Verify that the <tt>epoch</tt> field of
<t>Unprotect the Commit using the keys from the current epoch: the enclosing FramedContent is equal
to the <tt>epoch</tt> field of the current GroupContext object.</li>
<li pn="section-12.4.2-2.2">
<t indent="0" pn="section-12.4.2-2.2.1">Unprotect the Commit using
the keys from the current epoch:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="sec
<li>If the message is encoded as PublicMessage, verify the membe tion-12.4.2-2.2.2">
rship MAC using <li pn="section-12.4.2-2.2.2.1">If the message is encoded as Pub
the <tt>membership_key</tt></li> licMessage, verify the membership MAC using
<li>If the message is encoded as PrivateMessage, decrypt the mes the <tt>membership_key</tt>.</li>
sage using the <li pn="section-12.4.2-2.2.2.2">If the message is encoded as Pri
vateMessage, decrypt the message using the
<tt>sender_data_secret</tt> and the (key, nonce) pair from the step on the sende r's <tt>sender_data_secret</tt> and the (key, nonce) pair from the step on the sende r's
hash ratchet indicated by the <tt>generation</tt> field.</li> hash ratchet indicated by the <tt>generation</tt> field.</li>
</ul> </ul>
</li> </li>
<li>Verify that the signature on the FramedContent message as descri <li pn="section-12.4.2-2.3">Verify the signature on the FramedConten
bed in t message as described in
<xref target="content-authentication"/>.</li> <xref target="content-authentication" format="default" sectionFormat="of" derive
<li>Verify that the <tt>proposals</tt> vector is valid as specified dContent="Section 6.1"/>.</li>
in <xref target="proposal-list-validation"/>.</li> <li pn="section-12.4.2-2.4">Verify that the <tt>proposals</tt> vecto
<li>Verify that all PreSharedKey proposals in the <tt>proposals</tt> r is valid according to the rules in
vector are available.</li> <xref target="proposal-list-validation" format="default" sectionFormat="of" deri
<li>Create the new ratchet tree and GroupContext by applying the lis vedContent="Section 12.2"/>.</li>
t of proposals <li pn="section-12.4.2-2.5">Verify that all PreSharedKey proposals i
n the <tt>proposals</tt> vector are available.</li>
<li pn="section-12.4.2-2.6">Create the new ratchet tree and GroupCon
text by applying the list of proposals
to the old ratchet tree and GroupContext, as defined in to the old ratchet tree and GroupContext, as defined in
<xref target="applying-a-proposal-list"/></li> <xref target="applying-a-proposal-list" format="default" sectionFormat="of" deri
<li>Verify that the <tt>path</tt> value is populated if the <tt>prop vedContent="Section 12.3"/>.</li>
osals</tt> vector contains <li pn="section-12.4.2-2.7">Verify that the <tt>path</tt> value is p
opulated if the <tt>proposals</tt> vector contains
any Update or Remove proposals, or if it's empty. Otherwise, the <tt>path</tt> v alue any Update or Remove proposals, or if it's empty. Otherwise, the <tt>path</tt> v alue
MAY be omitted.</li> <bcp14>MAY</bcp14> be omitted.</li>
<li> <li pn="section-12.4.2-2.8">
<t>If the <tt>path</tt> value is populated, validate it and apply <t indent="0" pn="section-12.4.2-2.8.1">If the <tt>path</tt> value
it to the tree: </t> is populated, validate it and apply it to the tree: </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="sec
<li>If this is an external commit, assign the sender the leftmos tion-12.4.2-2.8.2">
t blank leaf <li pn="section-12.4.2-2.8.2.1">If this is an external Commit, a
ssign the sender the leftmost blank leaf
node in the new ratchet tree. If there are no blank leaf nodes in the new node in the new ratchet tree. If there are no blank leaf nodes in the new
ratchet tree, add a blank leaf to the right side of the new ratchet tree and ratchet tree, add a blank leaf to the right side of the new ratchet tree and
assign it to the sender.</li> assign it to the sender.</li>
<li>Validate the LeafNode as specified in <xref target="leaf-nod <li pn="section-12.4.2-2.8.2.2">Validate the LeafNode as specifi
e-validation"/>. The ed in <xref target="leaf-node-validation" format="default" sectionFormat="of" de
<tt>leaf_node_source</tt> field MUST be set to <tt>commit</tt>.</li> rivedContent="Section 7.3"/>. The
<li>Verify that the <tt>encryption_key</tt> value in the LeafNod <tt>leaf_node_source</tt> field <bcp14>MUST</bcp14> be set to <tt>commit</tt>.</
e is different from the li>
<li pn="section-12.4.2-2.8.2.3">Verify that the <tt>encryption_k
ey</tt> value in the LeafNode is different from the
committer's current leaf node.</li> committer's current leaf node.</li>
<li>Verify that none of the public keys in the UpdatePath appear in any node of <li pn="section-12.4.2-2.8.2.4">Verify that none of the public k eys in the UpdatePath appear in any node of
the new ratchet tree.</li> the new ratchet tree.</li>
<li>Merge the UpdatePath into the new ratchet tree as described <li pn="section-12.4.2-2.8.2.5">Merge the UpdatePath into the ne
in w ratchet tree, as described in
<xref target="synchronizing-views-of-the-tree"/>.</li> <xref target="synchronizing-views-of-the-tree" format="default" sectionFormat="o
<li> f" derivedContent="Section 7.5"/>.</li>
<t>Construct a provisional GroupContext object containing the <li pn="section-12.4.2-2.8.2.6">
following values: <t indent="0" pn="section-12.4.2-2.8.2.6.1">Construct a provis
ional GroupContext object containing the following values:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn=
<li> "section-12.4.2-2.8.2.6.2">
<li pn="section-12.4.2-2.8.2.6.2.1">
<tt>group_id</tt>: Same as the old GroupContext</li> <tt>group_id</tt>: Same as the old GroupContext</li>
<li> <li pn="section-12.4.2-2.8.2.6.2.2">
<tt>epoch</tt>: The epoch number for the new epoch</li> <tt>epoch</tt>: The epoch number for the new epoch</li>
<li> <li pn="section-12.4.2-2.8.2.6.2.3">
<tt>tree_hash</tt>: The tree hash of the new ratchet tree< /li> <tt>tree_hash</tt>: The tree hash of the new ratchet tree< /li>
<li> <li pn="section-12.4.2-2.8.2.6.2.4">
<tt>confirmed_transcript_hash</tt>: Same as the old GroupC ontext</li> <tt>confirmed_transcript_hash</tt>: Same as the old GroupC ontext</li>
<li> <li pn="section-12.4.2-2.8.2.6.2.5">
<tt>extensions</tt>: The new GroupContext extensions (poss ibly updated by a <tt>extensions</tt>: The new GroupContext extensions (poss ibly updated by a
GroupContextExtensions proposal)</li> GroupContextExtensions proposal)</li>
</ul> </ul>
</li> </li>
<li>Decrypt the path secrets for UpdatePath as described in <li pn="section-12.4.2-2.8.2.7">Decrypt the path secrets for Upd
<xref target="synchronizing-views-of-the-tree"/>, using the provisional GroupCon atePath as described in
text as <xref target="synchronizing-views-of-the-tree" format="default" sectionFormat="o
f" derivedContent="Section 7.5"/>, using the provisional GroupContext as
the context for HPKE decryption.</li> the context for HPKE decryption.</li>
<li>Define <tt>commit_secret</tt> as the value <tt>path_secret[n +1]</tt> derived from the <li pn="section-12.4.2-2.8.2.8">Define <tt>commit_secret</tt> as the value <tt>path_secret[n+1]</tt> derived from the
last path secret value (<tt>path_secret[n]</tt>) derived for the UpdatePath.</li > last path secret value (<tt>path_secret[n]</tt>) derived for the UpdatePath.</li >
</ul> </ul>
</li> </li>
<li>If the <tt>path</tt> value is not populated: Define <tt>commit_s ecret</tt> as the all-zero <li pn="section-12.4.2-2.9">If the <tt>path</tt> value is not popula ted, define <tt>commit_secret</tt> as the all-zero
vector of length <tt>KDF.Nh</tt> (the same length as a <tt>path_secret</tt> valu e would be).</li> vector of length <tt>KDF.Nh</tt> (the same length as a <tt>path_secret</tt> valu e would be).</li>
<li>Update the confirmed and interim transcript hashes using the new Commit, and <li pn="section-12.4.2-2.10">Update the confirmed and interim transc ript hashes using the new Commit, and
generate the new GroupContext.</li> generate the new GroupContext.</li>
<li>Derive the <tt>psk_secret</tt> as specified in <xref target="pre -shared-keys"/>, where the order <li pn="section-12.4.2-2.11">Derive the <tt>psk_secret</tt> as speci fied in <xref target="pre-shared-keys" format="default" sectionFormat="of" deriv edContent="Section 8.4"/>, where the order
of PSKs in the derivation corresponds to the order of PreSharedKey proposals of PSKs in the derivation corresponds to the order of PreSharedKey proposals
in the <tt>proposals</tt> vector.</li> in the <tt>proposals</tt> vector.</li>
<li>Use the <tt>init_secret</tt> from the previous epoch, the <tt>co <li pn="section-12.4.2-2.12">Use the <tt>init_secret</tt> from the p
mmit_secret</tt> and the revious epoch, the <tt>commit_secret</tt> and
<tt>psk_secret</tt> as defined in the previous steps, and the new GroupContext t <tt>psk_secret</tt> defined in the previous steps, and the new GroupContext to
o
compute the new <tt>joiner_secret</tt>, <tt>welcome_secret</tt>, <tt>epoch_secre t</tt>, and compute the new <tt>joiner_secret</tt>, <tt>welcome_secret</tt>, <tt>epoch_secre t</tt>, and
derived secrets for the new epoch.</li> derived secrets for the new epoch.</li>
<li>Use the <tt>confirmation_key</tt> for the new epoch to compute t he confirmation tag <li pn="section-12.4.2-2.13">Use the <tt>confirmation_key</tt> for t he new epoch to compute the confirmation tag
for this message, as described below, and verify that it is the same as the for this message, as described below, and verify that it is the same as the
<tt>confirmation_tag</tt> field in the FramedContentAuthData object.</li> <tt>confirmation_tag</tt> field in the FramedContentAuthData object.</li>
<li>If the above checks are successful, consider the new GroupContex t object <li pn="section-12.4.2-2.14">If the above checks are successful, con sider the new GroupContext object
as the current state of the group.</li> as the current state of the group.</li>
<li>If the Commit included a ReInit proposal, the client MUST NOT us <li pn="section-12.4.2-2.15">If the Commit included a ReInit proposa
e the group to l, the client <bcp14>MUST NOT</bcp14> use the group to
send messages anymore. Instead, it MUST wait for a Welcome message from the comm send messages anymore. Instead, it <bcp14>MUST</bcp14> wait for a Welcome messag
itter e from the committer
meeting the requirements of <xref target="reinitialization"/>.</li> meeting the requirements of <xref target="reinitialization" format="default" sec
tionFormat="of" derivedContent="Section 11.2"/>.</li>
</ul> </ul>
<t>Note that clients need to be prepared to receive a valid Commit mes sage which removes <t indent="0" pn="section-12.4.2-3">Note that clients need to be prepa red to receive a valid Commit message that removes
them from the group. In this case, the client cannot send any more messages in t he them from the group. In this case, the client cannot send any more messages in t he
group and SHOULD promptly delete its group state and secret tree. (A client migh t keep group and <bcp14>SHOULD</bcp14> promptly delete its group state and secret tree. (A client might keep
the secret tree for a short time to decrypt late messages in the previous epoch. )</t> the secret tree for a short time to decrypt late messages in the previous epoch. )</t>
</section> </section>
<section anchor="adding-members-to-the-group"> <section anchor="adding-members-to-the-group" numbered="true" removeInRF
<name>Adding Members to the Group</name> C="false" toc="include" pn="section-12.4.3">
<t>New members can join the group in two ways. Either by being added b <name slugifiedName="name-adding-members-to-the-group">Adding Members
y a group to the Group</name>
member, or by adding themselves through an external Commit. In both cases, the <t indent="0" pn="section-12.4.3-1">New members can join the group in
two ways: by being added by a group
member or by adding themselves through an external Commit. In both cases, the
new members need information to bootstrap their local group state.</t> new members need information to bootstrap their local group state.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-12.4.3 -2">
struct { struct {
GroupContext group_context; GroupContext group_context;
Extension extensions<V&gt;; Extension extensions<V&gt;;
MAC confirmation_tag; MAC confirmation_tag;
uint32 signer; uint32 signer;
/* SignWithLabel(., "GroupInfoTBS", GroupInfoTBS) */ /* SignWithLabel(., "GroupInfoTBS", GroupInfoTBS) */
opaque signature<V&gt;; opaque signature<V&gt;;
} GroupInfo; } GroupInfo;
]]></sourcecode> </sourcecode>
<t>The <tt>group_context</tt> field represents the current state of th <t indent="0" pn="section-12.4.3-3">The <tt>group_context</tt> field r
e group. The epresents the current state of the group. The
<tt>extensions</tt> field allows the sender to provide additional data that migh t be <tt>extensions</tt> field allows the sender to provide additional data that migh t be
useful to new joiners. The <tt>confirmation_tag</tt> represents the confirmati on tag useful to new joiners. The <tt>confirmation_tag</tt> represents the confirmati on tag
from the Commit that initiated the current epoch, or for epoch 0, the from the Commit that initiated the current epoch, or for epoch 0, the
confirmation tag computed in the creation of the group (see <xref target="group- creation"/>). confirmation tag computed in the creation of the group (see <xref target="group- creation" format="default" sectionFormat="of" derivedContent="Section 11"/>).
(In either case, the creator of a GroupInfo may recompute the confirmation tag (In either case, the creator of a GroupInfo may recompute the confirmation tag
as <tt>MAC(confirmation_key, confirmed_transcript_hash)</tt>.)</t> as <tt>MAC(confirmation_key, confirmed_transcript_hash)</tt>.)</t>
<t>As discussed in <xref target="extensibility"/>, unknown extensions <t indent="0" pn="section-12.4.3-4">As discussed in <xref target="exte
in <tt>GroupInfo.extensions</tt> nsibility" format="default" sectionFormat="of" derivedContent="Section 13"/>, un
MUST be ignored, and the creator of a <tt>GroupInfo</tt> object SHOULD include s known extensions in <tt>GroupInfo.extensions</tt> <bcp14>MUST</bcp14> be ignored
ome , and the creator of a GroupInfo object <bcp14>SHOULD</bcp14> include some
random GREASE extensions to help ensure that other clients correctly ignore unkn own random GREASE extensions to help ensure that other clients correctly ignore unkn own
extensions. Extensions in <tt>GroupInfo.group_context.extensions</tt>, however, MUST extensions. Extensions in <tt>GroupInfo.group_context.extensions</tt>, however, <bcp14>MUST</bcp14>
be supported by the new joiner.</t> be supported by the new joiner.</t>
<t>New members MUST verify that <tt>group_id</tt> is unique among the groups they're <t indent="0" pn="section-12.4.3-5">New members <bcp14>MUST</bcp14> ve rify that <tt>group_id</tt> is unique among the groups they are
currently participating in.</t> currently participating in.</t>
<t>New members also MUST verify the <tt>signature</tt> using the publi c key taken from the <t indent="0" pn="section-12.4.3-6">New members also <bcp14>MUST</bcp1 4> verify the <tt>signature</tt> using the public key taken from the
leaf node of the ratchet tree with leaf index <tt>signer</tt>. The leaf node of the ratchet tree with leaf index <tt>signer</tt>. The
signature covers the following structure, comprising all the fields in the signature covers the following structure, comprising all the fields in the
GroupInfo above <tt>signature</tt>:</t> GroupInfo above <tt>signature</tt>:</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-12.4.3 -7">
struct { struct {
GroupContext group_context; GroupContext group_context;
Extension extensions<V&gt;; Extension extensions<V&gt;;
MAC confirmation_tag; MAC confirmation_tag;
uint32 signer; uint32 signer;
} GroupInfoTBS; } GroupInfoTBS;
]]></sourcecode> </sourcecode>
<section anchor="joining-via-welcome-message"> <section anchor="joining-via-welcome-message" numbered="true" removeIn
<name>Joining via Welcome Message</name> RFC="false" toc="exclude" pn="section-12.4.3.1">
<t>The sender of a Commit message is responsible for sending a Welco <name slugifiedName="name-joining-via-welcome-message">Joining via W
me message to elcome Message</name>
<t indent="0" pn="section-12.4.3.1-1">The sender of a Commit message
is responsible for sending a Welcome message to
each new member added via Add proposals. The format of the Welcome message each new member added via Add proposals. The format of the Welcome message
allows a single Welcome message to be encrypted for multiple new members. It is allows a single Welcome message to be encrypted for multiple new members. It is
up to the committer to decide how many Welcome messages to create for a given up to the committer to decide how many Welcome messages to create for a given
Commit. The committer could create one Welcome that is encrypted for all new Commit. The committer could create one Welcome that is encrypted for all new
members, a different Welcome for each new member, or Welcome messages for members, a different Welcome for each new member, or Welcome messages for
batches of new members (according to some batching scheme that works well for batches of new members (according to some batching scheme that works well for
the application). The processes for creating and processing the Welcome are the the application). The processes for creating and processing the Welcome are the
same in all cases, aside from the set of new members for whom a given Welcome is same in all cases, aside from the set of new members for whom a given Welcome is
encrypted.</t> encrypted.</t>
<t>The Welcome message provides the new <t indent="0" pn="section-12.4.3.1-2">The Welcome message provides t he new
members with the current state of the group after the application of the Commit members with the current state of the group after the application of the Commit
message. The new members will not be able to decrypt or verify the Commit message. The new members will not be able to decrypt or verify the Commit
message, but will have the secrets they need to participate in the epoch message, but they will have the secrets they need to participate in the epoch
initiated by the Commit message.</t> initiated by the Commit message.</t>
<t>In order to allow the same Welcome message to be sent to multiple new members, <t indent="0" pn="section-12.4.3.1-3">In order to allow the same Wel come message to be sent to multiple new members,
information describing the group is encrypted with a symmetric key and nonce information describing the group is encrypted with a symmetric key and nonce
derived from the <tt>joiner_secret</tt> for the new epoch. The <tt>joiner_secre t</tt> is derived from the <tt>joiner_secret</tt> for the new epoch. The <tt>joiner_secre t</tt> is
then encrypted to each new member using HPKE. In the same encrypted package, then encrypted to each new member using HPKE. In the same encrypted package,
the committer transmits the path secret for the lowest (closest to the leaf) nod e the committer transmits the path secret for the lowest (closest to the leaf) nod e
which is contained in the direct paths of both the committer and the new member. that is contained in the direct paths of both the committer and the new member.
This allows the new This allows the new
member to compute private keys for nodes in its direct path that are being member to compute private keys for nodes in its direct path that are being
reset by the corresponding Commit.</t> reset by the corresponding Commit.</t>
<t>If the sender of the Welcome message wants the receiving member t o include a PSK <t indent="0" pn="section-12.4.3.1-4">If the sender of the Welcome m essage wants the receiving member to include a PSK
in the derivation of the <tt>epoch_secret</tt>, they can populate the <tt>psks</ tt> field in the derivation of the <tt>epoch_secret</tt>, they can populate the <tt>psks</ tt> field
indicating which PSK to use.</t> indicating which PSK to use.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-12.4 .3.1-5">
struct { struct {
opaque path_secret<V&gt;; opaque path_secret<V&gt;;
} PathSecret; } PathSecret;
struct { struct {
opaque joiner_secret<V>; opaque joiner_secret&lt;V&gt;;
optional<PathSecret> path_secret; optional&lt;PathSecret&gt; path_secret;
PreSharedKeyID psks<V>; PreSharedKeyID psks&lt;V&gt;;
} GroupSecrets; } GroupSecrets;
struct { struct {
KeyPackageRef new_member; KeyPackageRef new_member;
HPKECiphertext encrypted_group_secrets; HPKECiphertext encrypted_group_secrets;
} EncryptedGroupSecrets; } EncryptedGroupSecrets;
struct { struct {
CipherSuite cipher_suite; CipherSuite cipher_suite;
EncryptedGroupSecrets secrets<V>; EncryptedGroupSecrets secrets&lt;V&gt;;
opaque encrypted_group_info<V>; opaque encrypted_group_info&lt;V&gt;;
} Welcome; } Welcome;
]]></sourcecode> </sourcecode>
<t>The client processing a Welcome message will need to have a copy <t indent="0" pn="section-12.4.3.1-6">The client processing a Welcom
of the group's e message will need to have a copy of the group's
ratchet tree. The tree can be provided in the Welcome message, in an extension ratchet tree. The tree can be provided in the Welcome message, in an extension
of type <tt>ratchet_tree</tt>. If it is sent otherwise (e.g., provided by a cac hing of type <tt>ratchet_tree</tt>. If it is sent otherwise (e.g., provided by a cac hing
service on the Delivery Service), then the client MUST download the tree before service on the Delivery Service), then the client <bcp14>MUST</bcp14> download t he tree before
processing the Welcome.</t> processing the Welcome.</t>
<t>On receiving a Welcome message, a client processes it using the f <t indent="0" pn="section-12.4.3.1-7">On receiving a Welcome message
ollowing steps:</t> , a client processes it using the following steps:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>Identify an entry in the <tt>secrets</tt> array where the <tt> on-12.4.3.1-8">
new_member</tt> <li pn="section-12.4.3.1-8.1">Identify an entry in the <tt>secrets
</tt> array where the <tt>new_member</tt>
value corresponds to one of this client's KeyPackages, using the hash value corresponds to one of this client's KeyPackages, using the hash
indicated by the <tt>cipher_suite</tt> field. If no such field exists, or if the indicated by the <tt>cipher_suite</tt> field. If no such field exists, or if the
ciphersuite indicated in the KeyPackage does not match the one in the cipher suite indicated in the KeyPackage does not match the one in the
Welcome message, return an error.</li> Welcome message, return an error.</li>
<li>Decrypt the <tt>encrypted_group_secrets</tt> value with the al <li pn="section-12.4.3.1-8.2">Decrypt the <tt>encrypted_group_secr
gorithms indicated by ets</tt> value with the algorithms indicated by
the ciphersuite and the private key <tt>init_key_priv</tt> corresponding to the cipher suite and the private key <tt>init_key_priv</tt> corresponding to
<tt>init_key</tt> in the referenced KeyPackage.</li> <tt>init_key</tt> in the referenced KeyPackage.</li>
</ul> </ul>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-12.4.3.1-9
encrypted_group_secrets = EncryptWithLabel(init_key, "Welcome", ">
encrypted_group_info, group_secrets) encrypted_group_secrets =
EncryptWithLabel(init_key, "Welcome",
encrypted_group_info, group_secrets)
group_secrets = DecryptWithLabel(init_key_priv, "Welcome", group_secrets =
encrypted_group_info, kem_output, ciphertext) DecryptWithLabel(init_key_priv, "Welcome",
]]></sourcecode> encrypted_group_info, kem_output, ciphertext)
<ul spacing="normal"> </sourcecode>
<li>If a <tt>PreSharedKeyID</tt> is part of the GroupSecrets and t <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
he client is not in on-12.4.3.1-10">
<li pn="section-12.4.3.1-10.1">If a PreSharedKeyID is part of the
GroupSecrets and the client is not in
possession of the corresponding PSK, return an error. Additionally, if a possession of the corresponding PSK, return an error. Additionally, if a
<tt>PreSharedKeyID</tt> has type <tt>resumption</tt> with usage <tt>reinit</tt> or <tt>branch</tt>, verify PreSharedKeyID has type <tt>resumption</tt> with usage <tt>reinit</tt> or <tt>br anch</tt>, verify
that it is the only such PSK.</li> that it is the only such PSK.</li>
<li>From the <tt>joiner_secret</tt> in the decrypted GroupSecrets <li pn="section-12.4.3.1-10.2">From the <tt>joiner_secret</tt> in
object and the PSKs the decrypted GroupSecrets object and the PSKs
specified in the <tt>GroupSecrets</tt>, derive the <tt>welcome_secret</tt> and u specified in the GroupSecrets, derive the <tt>welcome_secret</tt> and then
sing that
the <tt>welcome_key</tt> and <tt>welcome_nonce</tt>. Use the key and nonce to de crypt the the <tt>welcome_key</tt> and <tt>welcome_nonce</tt>. Use the key and nonce to de crypt the
<tt>encrypted_group_info</tt> field.</li> <tt>encrypted_group_info</tt> field.</li>
</ul> </ul>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-12.4.3.1-1 1">
welcome_nonce = ExpandWithLabel(welcome_secret, "nonce", "", AEAD.Nn) welcome_nonce = ExpandWithLabel(welcome_secret, "nonce", "", AEAD.Nn)
welcome_key = ExpandWithLabel(welcome_secret, "key", "", AEAD.Nk) welcome_key = ExpandWithLabel(welcome_secret, "key", "", AEAD.Nk)
]]></sourcecode> </sourcecode>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>Verify the signature on the GroupInfo object. The signature in on-12.4.3.1-12">
put comprises <li pn="section-12.4.3.1-12.1">Verify the signature on the GroupIn
fo object. The signature input comprises
all of the fields in the GroupInfo object except the signature field. The all of the fields in the GroupInfo object except the signature field. The
public key is taken from the LeafNode of the public key is taken from the LeafNode of the
ratchet tree with leaf index <tt>signer</tt>. If the node is blank or if ratchet tree with leaf index <tt>signer</tt>. If the node is blank or if
signature verification fails, return an error.</li> signature verification fails, return an error.</li>
<li>Verify that the <tt>group_id</tt> is unique among the groups t hat the client is <li pn="section-12.4.3.1-12.2">Verify that the <tt>group_id</tt> i s unique among the groups that the client is
currently participating in.</li> currently participating in.</li>
<li>Verify that the <tt>cipher_suite</tt> in the GroupInfo matches the <tt>cipher_suite</tt> in <li pn="section-12.4.3.1-12.3">Verify that the <tt>cipher_suite</t t> in the GroupInfo matches the <tt>cipher_suite</tt> in
the KeyPackage.</li> the KeyPackage.</li>
<li> <li pn="section-12.4.3.1-12.4">
<t>Verify the integrity of the ratchet tree. </t> <t indent="0" pn="section-12.4.3.1-12.4.1">Verify the integrity
<ul spacing="normal"> of the ratchet tree. </t>
<li>Verify that the tree hash of the ratchet tree matches the <ul spacing="normal" bare="false" empty="false" indent="3" pn="s
<tt>tree_hash</tt> field ection-12.4.3.1-12.4.2">
<li pn="section-12.4.3.1-12.4.2.1">Verify that the tree hash o
f the ratchet tree matches the <tt>tree_hash</tt> field
in GroupInfo.</li> in GroupInfo.</li>
<li>For each non-empty parent node, verify that it is "parent- <li pn="section-12.4.3.1-12.4.2.2">For each non-empty parent n
hash valid", ode, verify that it is "parent-hash valid",
as described in <xref target="verifying-parent-hashes"/>.</li> as described in <xref target="verifying-parent-hashes" format="default" sectionF
<li>For each non-empty leaf node, validate the LeafNode as des ormat="of" derivedContent="Section 7.9.2"/>.</li>
cribed in <li pn="section-12.4.3.1-12.4.2.3">For each non-empty leaf nod
<xref target="leaf-node-validation"/>.</li> e, validate the LeafNode as described in
<li> <xref target="leaf-node-validation" format="default" sectionFormat="of" derivedC
<t>For each non-empty parent node and each entry in the node ontent="Section 7.3"/>.</li>
's <li pn="section-12.4.3.1-12.4.2.4">
<t indent="0" pn="section-12.4.3.1-12.4.2.4.1">For each non-
empty parent node and each entry in the node's
<tt>unmerged_leaves</tt> field: </t> <tt>unmerged_leaves</tt> field: </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" p
<li>Verify that the entry represents a non-blank leaf node n="section-12.4.3.1-12.4.2.4.2">
that is a <li pn="section-12.4.3.1-12.4.2.4.2.1">Verify that the ent
ry represents a non-blank leaf node that is a
descendant of the parent node.</li> descendant of the parent node.</li>
<li>Verify that every non-blank intermediate node beween t he leaf node and the <li pn="section-12.4.3.1-12.4.2.4.2.2">Verify that every n on-blank intermediate node between the leaf node and the
parent node also has an entry for the leaf node in its <tt>unmerged_leaves</tt>. </li> parent node also has an entry for the leaf node in its <tt>unmerged_leaves</tt>. </li>
<li>Verify that the encryption key in the parent node does not appear in any <li pn="section-12.4.3.1-12.4.2.4.2.3">Verify that the enc ryption key in the parent node does not appear in any
other node of the tree.</li> other node of the tree.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</li> </li>
<li>Identify a leaf whose LeafNode is <li pn="section-12.4.3.1-12.5">Identify a leaf whose LeafNode is
identical to the one in the KeyPackage. If no such field exists, return an identical to the one in the KeyPackage. If no such field exists, return an
error. Let <tt>my_leaf</tt> represent this leaf in the tree.</li> error. Let <tt>my_leaf</tt> represent this leaf in the tree.</li>
<li> <li pn="section-12.4.3.1-12.6">
<t>Construct a new group state using the information in the Grou <t indent="0" pn="section-12.4.3.1-12.6.1">Construct a new group
pInfo object. state using the information in the GroupInfo object. </t>
</t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="s
<ul spacing="normal"> ection-12.4.3.1-12.6.2">
<li>The GroupContext is the <tt>group_context</tt> field from <li pn="section-12.4.3.1-12.6.2.1">Initialize the GroupContext
the GroupInfo object.</li> for the group from the <tt>group_context</tt> field
<li>The new member's position in the tree is at the leaf <tt>m from the GroupInfo object.</li>
y_leaf</tt>, as defined <li pn="section-12.4.3.1-12.6.2.2">Update the leaf <tt>my_leaf
above.</li> </tt> with the private key corresponding to the
<li>Update the leaf <tt>my_leaf</tt> with the private key corr public key in the node, where <tt>my_leaf</tt> is the new member's leaf node in
esponding to the the ratchet tree, as defined above.</li>
public key in the node.</li> <li pn="section-12.4.3.1-12.6.2.3">If the <tt>path_secret</tt>
<li>If the <tt>path_secret</tt> value is set in the GroupSecre value is set in the GroupSecrets object: Identify the
ts object: Identify the
lowest common ancestor of the leaf node <tt>my_leaf</tt> and of the node of lowest common ancestor of the leaf node <tt>my_leaf</tt> and of the node of
the member with leaf index <tt>GroupInfo.signer</tt>. Set the private key for the member with leaf index <tt>GroupInfo.signer</tt>. Set the private key for
this node to the private key derived from the <tt>path_secret</tt>.</li> this node to the private key derived from the <tt>path_secret</tt>.</li>
<li>For each parent of the common ancestor, up to the root of <li pn="section-12.4.3.1-12.6.2.4">For each parent of the comm
the tree, derive on 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 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 derived from the path secret. The private key <bcp14>MUST</bcp14> be the privat
e key
that corresponds to the public key in the node.</li> that corresponds to the public key in the node.</li>
</ul> </ul>
</li> </li>
<li>Use the <tt>joiner_secret</tt> from the GroupSecrets object to generate the epoch secret <li pn="section-12.4.3.1-12.7">Use the <tt>joiner_secret</tt> from the GroupSecrets object to generate the epoch secret
and other derived secrets for the current epoch.</li> and other derived secrets for the current epoch.</li>
<li>Set the confirmed transcript hash in the new state to the valu e of the <li pn="section-12.4.3.1-12.8">Set the confirmed transcript hash i n the new state to the value of the
<tt>confirmed_transcript_hash</tt> in the GroupInfo.</li> <tt>confirmed_transcript_hash</tt> in the GroupInfo.</li>
<li>Verify the confirmation tag in the GroupInfo using the derived confirmation <li pn="section-12.4.3.1-12.9">Verify the confirmation tag in the GroupInfo using the derived confirmation
key and the <tt>confirmed_transcript_hash</tt> from the GroupInfo.</li> key and the <tt>confirmed_transcript_hash</tt> from the GroupInfo.</li>
<li>Use the confirmed transcript hash and confirmation tag to comp ute the interim <li pn="section-12.4.3.1-12.10">Use the confirmed transcript hash and confirmation tag to compute the interim
transcript hash in the new state.</li> transcript hash in the new state.</li>
<li> <li pn="section-12.4.3.1-12.11">
<t>If a <tt>PreSharedKeyID</tt> was used that has type <tt>resum <t indent="0" pn="section-12.4.3.1-12.11.1">If a PreSharedKeyID
ption</tt> with usage <tt>reinit</tt> was used that has type <tt>resumption</tt> with usage <tt>reinit</tt>
or <tt>branch</tt>, verify that the <tt>epoch</tt> field in the GroupInfo is equ al to 1. </t> or <tt>branch</tt>, verify that the <tt>epoch</tt> field in the GroupInfo is equ al to 1. </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="s
<li>For usage <tt>reinit</tt>, verify that the last Commit to ection-12.4.3.1-12.11.2">
the referenced group <li pn="section-12.4.3.1-12.11.2.1">For usage <tt>reinit</tt>,
verify that the last Commit to the referenced group
contains a ReInit proposal and that the <tt>group_id</tt>, <tt>version</tt>, contains a ReInit proposal and that the <tt>group_id</tt>, <tt>version</tt>,
<tt>cipher_suite</tt>, and <tt>group_context.extensions</tt> fields of the Group Info match <tt>cipher_suite</tt>, and <tt>group_context.extensions</tt> fields of the Group Info match
the ReInit proposal. Additionally, verify that all the members of the old the ReInit proposal. Additionally, verify that all the members of the old
group are also members of the new group, according to the application.</li> group are also members of the new group, according to the application.</li>
<li>For usage <tt>branch</tt>, verify that the <tt>version</tt > and <tt>cipher_suite</tt> of the new <li pn="section-12.4.3.1-12.11.2.2">For usage <tt>branch</tt>, verify that the <tt>version</tt> and <tt>cipher_suite</tt> of the new
group match those of the old group, and that the members of the new group group match those of the old group, and that the members of the new group
compose a subset of the members of the old group, according to the compose a subset of the members of the old group, according to the
application.</li> application.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="joining-via-external-commits"> <section anchor="joining-via-external-commits" numbered="true" removeI
<name>Joining via External Commits</name> nRFC="false" toc="exclude" pn="section-12.4.3.2">
<t>External Commits are a mechanism for new members (external partie <name slugifiedName="name-joining-via-external-commit">Joining via E
s that want to xternal Commits</name>
<t indent="0" pn="section-12.4.3.2-1">External Commits are a mechani
sm for new members (external parties that want to
become members of the group) to add themselves to a group, without requiring become members of the group) to add themselves to a group, without requiring
that an existing member has to come online to issue a Commit that references an that an existing member has to come online to issue a Commit that references an
Add Proposal.</t> Add proposal.</t>
<t>Whether existing members of the group will accept or reject an Ex <t indent="0" pn="section-12.4.3.2-2">Whether existing members of th
ternal Commit e group will accept or reject an external Commit
follows the same rules that are applied to other handshake messages.</t> follows the same rules that are applied to other handshake messages.</t>
<t>New members can create and issue an External Commit if they have access to the <t indent="0" pn="section-12.4.3.2-3">New members can create and iss ue an external Commit if they have access to the
following information for the group's current epoch:</t> following information for the group's current epoch:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>group ID</li> on-12.4.3.2-4">
<li>epoch ID</li> <li pn="section-12.4.3.2-4.1">group ID</li>
<li>ciphersuite</li> <li pn="section-12.4.3.2-4.2">epoch ID</li>
<li>public tree hash</li> <li pn="section-12.4.3.2-4.3">cipher suite</li>
<li>confirmed transcript hash</li> <li pn="section-12.4.3.2-4.4">public tree hash</li>
<li>confirmation tag of the most recent Commit</li> <li pn="section-12.4.3.2-4.5">confirmed transcript hash</li>
<li>group extensions</li> <li pn="section-12.4.3.2-4.6">confirmation tag of the most recent
<li>external public key</li> Commit</li>
<li pn="section-12.4.3.2-4.7">group extensions</li>
<li pn="section-12.4.3.2-4.8">external public key</li>
</ul> </ul>
<t>In other words, to join a group via an External Commit, a new mem ber needs a <t indent="0" pn="section-12.4.3.2-5">In other words, to join a grou p via an external Commit, a new member needs a
GroupInfo with an <tt>external_pub</tt> extension present in its <tt>extensions< /tt> field.</t> GroupInfo with an <tt>external_pub</tt> extension present in its <tt>extensions< /tt> field.</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-12.4 .3.2-6">
struct { struct {
HPKEPublicKey external_pub; HPKEPublicKey external_pub;
} ExternalPub; } ExternalPub;
]]></sourcecode> </sourcecode>
<t>Thus, a member of the group can enable new clients to join by mak <t indent="0" pn="section-12.4.3.2-7">Thus, a member of the group ca
ing a GroupInfo n enable new clients to join by making a GroupInfo
object available to them. Note that because a GroupInfo object is specific to an object available to them. Note that because a GroupInfo object is specific to an
epoch, it will need to be updated as the group advances. In particular, each epoch, it will need to be updated as the group advances. In particular, each
GroupInfo object can be used for one external join, since that external join GroupInfo object can be used for one external join, since that external join
will cause the epoch to change.</t> will cause the epoch to change.</t>
<t>Note that the <tt>tree_hash</tt> field is used the same way as in the Welcome message. <t indent="0" pn="section-12.4.3.2-8">Note that the <tt>tree_hash</t t> field is used the same way as in the Welcome message.
The full tree can be included via the <tt>ratchet_tree</tt> extension The full tree can be included via the <tt>ratchet_tree</tt> extension
<xref target="ratchet-tree-extension"/>.</t> (see <xref target="ratchet-tree-extension" format="default" sectionFormat="of" d
<t>The information in a GroupInfo is not generally public informatio erivedContent="Section 12.4.3.3"/>).</t>
n, but applications <t indent="0" pn="section-12.4.3.2-9">The information in a GroupInfo
is not generally public information, but applications
can choose to make it available to new members in order to allow External can choose to make it available to new members in order to allow External
Commits.</t> Commits.</t>
<t>In principle, External Commits work like regular Commits. However , their content <t indent="0" pn="section-12.4.3.2-10">In principle, external Commit s work like regular Commits. However, their content
has to meet a specific set of requirements:</t> has to meet a specific set of requirements:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>External Commits MUST contain a <tt>path</tt> field (and is th on-12.4.3.2-11">
erefore a "full" <li pn="section-12.4.3.2-11.1">External Commits <bcp14>MUST</bcp14
> contain a <tt>path</tt> field (and is therefore a "full"
Commit). The joiner is added at the leftmost free leaf node (just as if they Commit). The joiner is added at the leftmost free leaf node (just as if they
were added with an Add proposal), and the path is calculated relative to that were added with an Add proposal), and the path is calculated relative to that
leaf node.</li> leaf node.</li>
<li>The Commit MUST NOT include any proposals by reference, since <li pn="section-12.4.3.2-11.2">The Commit <bcp14>MUST NOT</bcp14>
an external include any proposals by reference, since an external
joiner cannot determine the validity of proposals sent within the group</li> joiner cannot determine the validity of proposals sent within the group.</li>
<li>External Commits MUST be signed by the new member. In particu <li pn="section-12.4.3.2-11.3">External Commits <bcp14>MUST</bcp14
lar, the > be signed by the new member. In particular, the
signature on the enclosing AuthenticatedContent MUST verify using the public key signature on the enclosing AuthenticatedContent <bcp14>MUST</bcp14> verify using
for the public key for
the credential in the <tt>leaf_node</tt> of the <tt>path</tt> field.</li> the credential in the <tt>leaf_node</tt> of the <tt>path</tt> field.</li>
<li>When processing a Commit, both existing and new members MUST u <li pn="section-12.4.3.2-11.4">When processing a Commit, both exis
se the external ting and new members <bcp14>MUST</bcp14> use the external
init secret as described in <xref target="external-initialization"/>.</li> init secret as described in <xref target="external-initialization" format="defau
<li>The sender type for the AuthenticatedContent encapsulating the lt" sectionFormat="of" derivedContent="Section 8.3"/>.</li>
External Commit MUST be <li pn="section-12.4.3.2-11.5">The sender type for the Authenticat
edContent encapsulating the external Commit <bcp14>MUST</bcp14> be
<tt>new_member_commit</tt>.</li> <tt>new_member_commit</tt>.</li>
</ul> </ul>
<t>External Commits come in two "flavors" -- a "join" commit that <t indent="0" pn="section-12.4.3.2-12">External Commits come in two
adds the sender to the group or a "resync" commit that replaces a member's prior "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.</t> appearance with a new one.</t>
<t>Note that the "resync" operation allows an attacker that has comp romised a <t indent="0" pn="section-12.4.3.2-13">Note that the "resync" operat ion allows an attacker that has compromised a
member's signature private key to introduce themselves into the group and remove the member's signature private key to introduce themselves into the group and remove the
prior, legitimate member in a single Commit. Without resync, this prior, legitimate member in a single Commit. Without resync, this
can still be done, but requires two operations, the external Commit to join and can still be done, but it requires two operations: the external Commit to join a nd
a second Commit to remove the old appearance. Applications for whom this a second Commit to remove the old appearance. Applications for whom this
distinction is salient can choose to disallow external commits that contain a 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 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 proposal that demonstrates the joining member's presence in a prior epoch of the
group. With the latter approach, the attacker would need to compromise the PSK group. With the latter approach, the attacker would need to compromise the PSK
as well as the signing key, but the application will need to ensure that as well as the signing key, but the application will need to ensure that
continuing, non-resynchronizing members have the required PSK.</t> continuing, non-resynchronizing members have the required PSK.</t>
</section> </section>
<section anchor="ratchet-tree-extension"> <section anchor="ratchet-tree-extension" numbered="true" removeInRFC="
<name>Ratchet Tree Extension</name> false" toc="exclude" pn="section-12.4.3.3">
<t>By default, a GroupInfo message only provides the joiner with a h <name slugifiedName="name-ratchet-tree-extension">Ratchet Tree Exten
ash of sion</name>
<t indent="0" pn="section-12.4.3.3-1">By default, a GroupInfo messag
e only provides the joiner with a hash of
the group's ratchet tree. In order to process or generate handshake the group's ratchet tree. In order to process or generate handshake
messages, the joiner will need to get a copy of the ratchet tree from some other messages, the joiner will need to get a copy of the ratchet tree from some other
source. (For example, the DS might provide a cached copy.) The inclusion of source. (For example, the DS might provide a cached copy.) The inclusion of
the tree hash in the GroupInfo message means that the source of the ratchet the tree hash in the GroupInfo message means that the source of the ratchet
tree need not be trusted to maintain the integrity of tree.</t> tree need not be trusted to maintain the integrity of the tree.</t>
<t>In cases where the application does not wish to provide such an e <t indent="0" pn="section-12.4.3.3-2">In cases where the application
xternal source, does not wish to provide such an external source,
the whole public state of the ratchet tree can be provided in an extension of the whole public state of the ratchet tree can be provided in an extension of
type <tt>ratchet_tree</tt>, containing a <tt>ratchet_tree</tt> object of the fol lowing form:</t> type <tt>ratchet_tree</tt>, containing a <tt>ratchet_tree</tt> object of the fol lowing form:</t>
<sourcecode type="tls"><![CDATA[ <sourcecode type="tls-presentation" markers="false" pn="section-12.4 .3.3-3">
struct { struct {
NodeType node_type; NodeType node_type;
select (Node.node_type) { select (Node.node_type) {
case leaf: LeafNode leaf_node; case leaf: LeafNode leaf_node;
case parent: ParentNode parent_node; case parent: ParentNode parent_node;
}; };
} Node; } Node;
optional<Node> ratchet_tree<V>; optional&lt;Node&gt; ratchet_tree&lt;V&gt;;
]]></sourcecode> </sourcecode>
<t>Each entry in the <tt>ratchet_tree</tt> vector provides the value <t indent="0" pn="section-12.4.3.3-4">Each entry in the <tt>ratchet_
for a node in the tree</tt> vector provides the value for a node in the
tree, or the null optional for a blank node.</t> tree, or the null optional for a blank node.</t>
<t>The nodes are listed in the order specified by a left-to-right in -order <t indent="0" pn="section-12.4.3.3-5">The nodes are listed in the or der specified by a left-to-right in-order
traversal of the ratchet tree. Each node is listed between its left subtree and traversal of the ratchet tree. Each node is listed between its left subtree and
its right subtree. (This is the same ordering as specified for the array-based its right subtree. (This is the same ordering as specified for the array-based
trees outlined in <xref target="array-based-trees"/>.)</t> trees outlined in <xref target="array-based-trees" format="default" sectionForma
<t>If the tree has <tt>2^d</tt> leaves, then it has <tt>2^(d+1) - 1< t="of" derivedContent="Appendix C"/>.)</t>
/tt> nodes. The <t indent="0" pn="section-12.4.3.3-6">If the tree has 2<sup>d</sup>
leaves, then it has 2<sup>d+1</sup> - 1 nodes. The
<tt>ratchet_tree</tt> vector logically has this number of entries, but the sende r <tt>ratchet_tree</tt> vector logically has this number of entries, but the sende r
MUST NOT include blank nodes after the last non-blank node. The receiver MUST <bcp14>MUST NOT</bcp14> include blank nodes after the last non-blank node. The
check that the last node in <tt>ratchet_tree</tt> is non-blank, and extend it to receiver <bcp14>MUST</bcp14>
the check that the last node in <tt>ratchet_tree</tt> is non-blank, and then extend
right until it has a length of the form <tt>2^(d+1) - 1</tt>, adding the minimum the tree to the
number right until it has a length of the form 2<sup>d+1</sup> - 1, adding the minimum
number
of blank values possible. (Obviously, this may be done "virtually", by of blank values possible. (Obviously, this may be done "virtually", by
synthesizing blank nodes when required, as opposed to actually changing the synthesizing blank nodes when required, as opposed to actually changing the
structure in memory.)</t> structure in memory.)</t>
<t>The leaves of the tree are stored in even-numbered entries in the array (the <t indent="0" pn="section-12.4.3.3-7">The leaves of the tree are sto red in even-numbered entries in the array (the
leaf with index <tt>L</tt> in array position <tt>2*L</tt>). The root node of the tree is at leaf with index <tt>L</tt> in array position <tt>2*L</tt>). The root node of the tree is at
position <tt>2^d - 1</tt> of the array. Intermediate parent nodes can be identif ied by position 2<sup>d</sup> - 1 of the array. Intermediate parent nodes can be identi fied by
performing the same calculation to the subarrays to the left and right of the performing the same calculation to the subarrays to the left and right of the
root, following something like the following algorithm:</t> root, following something like the following algorithm:</t>
<sourcecode type="python"><![CDATA[ <sourcecode type="python" markers="false" pn="section-12.4.3.3-8">
# Assuming a class Node that has left and right members # Assuming a class Node that has left and right members
def subtree_root(nodes): def subtree_root(nodes):
# If there is only one node in the array return it # If there is only one node in the array, return it
if len(nodes) == 1: if len(nodes) == 1:
return Node(nodes[0]) return Node(nodes[0])
# Otherwise, the length of the array MUST be odd # Otherwise, the length of the array MUST be odd
if len(nodes) % 2 == 0: if len(nodes) % 2 == 0:
raise Exception("Malformed node array {}", len(nodes)) raise Exception("Malformed node array {}", len(nodes))
# Identify the root of the subtree # Identify the root of the subtree
d = 0 d = 0
while (2**(d+1)) < len(nodes): while (2**(d+1)) &lt; len(nodes):
d += 1 d += 1
R = 2**d - 1 R = 2**d - 1
root = Node(nodes[R]) root = Node(nodes[R])
root.left = subtree_root(nodes[:R]) root.left = subtree_root(nodes[:R])
root.right = subtree_root(nodes[(R+1):]) root.right = subtree_root(nodes[(R+1):])
return root return root
]]></sourcecode> </sourcecode>
<t>(Note that this is the same ordering of nodes as in the array-bas <t indent="0" pn="section-12.4.3.3-9">(Note that this is the same or
ed tree representation dering of nodes as in the array-based tree representation
described in <xref target="array-based-trees"/>. The algorithms in that section described in <xref target="array-based-trees" format="default" sectionFormat="of
may be used to " derivedContent="Appendix C"/>. The algorithms in that section may be used to
simplify decoding this extension into other representations.)</t> simplify decoding this extension into other representations.)</t>
<t>For example, the following tree with six non-blank leaves would b e represented <t indent="0" pn="section-12.4.3.3-10">For example, the following tr ee with six non-blank leaves would be represented
as an array of eleven elements, <tt>[A, W, B, X, C, _, D, Y, E, Z, F]</tt>. The above as an array of eleven elements, <tt>[A, W, B, X, C, _, D, Y, E, Z, F]</tt>. The above
decoding procedure would identify the subtree roots as follows (using R to decoding procedure would identify the subtree roots as follows (using R to
represent a subtree root):</t> represent a subtree root):</t>
<figure> <figure align="left" suppress-title="false" pn="figure-28">
<name>Left-to-right in-order traversal of a six-member tree</name> <name slugifiedName="name-left-to-right-in-order-trav">Left-to-Rig
<artset> ht In-Order Traversal of a Six-Member Tree</name>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" vers <artset pn="section-12.4.3.3-11.1">
ion="1.1" height="304" width="240" viewBox="0 0 240 304" class="diagram" text-an <artwork type="svg" align="left" pn="section-12.4.3.3-11.1.1">
chor="middle" font-family="monospace" font-size="13px"> <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-f
amily="monospace" font-size="13px" height="304" text-anchor="middle" version="1.
1" viewBox="0 0 240 304" width="240">
<path d="M 56,112 L 56,128" fill="none" stroke="black"/> <path d="M 56,112 L 56,128" fill="none" stroke="black"/>
<path d="M 120,48 L 120,64" fill="none" stroke="black"/> <path d="M 120,48 L 120,64" fill="none" stroke="black"/>
<path d="M 184,104 L 184,128" fill="none" stroke="black"/> <path d="M 184,104 L 184,128" fill="none" stroke="black"/>
<path d="M 72,64 L 168,64" fill="none" stroke="black"/> <path d="M 72,64 L 168,64" fill="none" stroke="black"/>
<path d="M 40,128 L 72,128" fill="none" stroke="black"/> <path d="M 40,128 L 72,128" fill="none" stroke="black"/>
<path d="M 168,128 L 200,128" fill="none" stroke="black"/> <path d="M 168,128 L 200,128" fill="none" stroke="black"/>
<path d="M 8,256 L 104,256" fill="none" stroke="black"/> <path d="M 8,256 L 104,256" fill="none" stroke="black"/>
<path d="M 136,256 L 232,256" fill="none" stroke="black"/> <path d="M 136,256 L 232,256" fill="none" stroke="black"/>
<path d="M 8,272 L 40,272" fill="none" stroke="black"/> <path d="M 8,272 L 40,272" fill="none" stroke="black"/>
<path d="M 72,272 L 104,272" fill="none" stroke="black"/> <path d="M 72,272 L 104,272" fill="none" stroke="black"/>
skipping to change at line 5595 skipping to change at line 5852
<path d="M 72,128 L 80,144" fill="none" stroke="black"/> <path d="M 72,128 L 80,144" fill="none" stroke="black"/>
<path d="M 92,168 L 96,176" fill="none" stroke="black"/> <path d="M 92,168 L 96,176" fill="none" stroke="black"/>
<path d="M 168,64 L 176,80" fill="none" stroke="black"/> <path d="M 168,64 L 176,80" fill="none" stroke="black"/>
<path d="M 200,128 L 208,144" fill="none" stroke="black"/> <path d="M 200,128 L 208,144" fill="none" stroke="black"/>
<path d="M 220,168 L 224,176" fill="none" stroke="black"/> <path d="M 220,168 L 224,176" fill="none" stroke="black"/>
<path d="M 32,144 L 40,128" fill="none" stroke="black"/> <path d="M 32,144 L 40,128" fill="none" stroke="black"/>
<path d="M 64,80 L 72,64" fill="none" stroke="black"/> <path d="M 64,80 L 72,64" fill="none" stroke="black"/>
<path d="M 80,176 L 84,168" fill="none" stroke="black"/> <path d="M 80,176 L 84,168" fill="none" stroke="black"/>
<path d="M 160,144 L 168,128" fill="none" stroke="black"/> <path d="M 160,144 L 168,128" fill="none" stroke="black"/>
<path d="M 208,176 L 212,168" fill="none" stroke="black"/> <path d="M 208,176 L 212,168" fill="none" stroke="black"/>
<polygon class="arrowhead" points="240,272 228,266.4 228,277 <polygon class="arrowhead" fill="black" points="240,272 228,
.6" fill="black" transform="rotate(0,232,272)"/> 266.4 228,277.6" transform="rotate(0,232,272)"/>
<polygon class="arrowhead" points="240,256 228,250.4 228,261 <polygon class="arrowhead" fill="black" points="240,256 228,
.6" fill="black" transform="rotate(0,232,256)"/> 250.4 228,261.6" transform="rotate(0,232,256)"/>
<polygon class="arrowhead" points="208,272 196,266.4 196,277 <polygon class="arrowhead" fill="black" points="208,272 196,
.6" fill="black" transform="rotate(180,200,272)"/> 266.4 196,277.6" transform="rotate(180,200,272)"/>
<polygon class="arrowhead" points="176,272 164,266.4 164,277 <polygon class="arrowhead" fill="black" points="176,272 164,
.6" fill="black" transform="rotate(0,168,272)"/> 266.4 164,277.6" transform="rotate(0,168,272)"/>
<polygon class="arrowhead" points="144,272 132,266.4 132,277 <polygon class="arrowhead" fill="black" points="144,272 132,
.6" fill="black" transform="rotate(180,136,272)"/> 266.4 132,277.6" transform="rotate(180,136,272)"/>
<polygon class="arrowhead" points="144,256 132,250.4 132,261 <polygon class="arrowhead" fill="black" points="144,256 132,
.6" fill="black" transform="rotate(180,136,256)"/> 250.4 132,261.6" transform="rotate(180,136,256)"/>
<polygon class="arrowhead" points="112,272 100,266.4 100,277 <polygon class="arrowhead" fill="black" points="112,272 100,
.6" fill="black" transform="rotate(0,104,272)"/> 266.4 100,277.6" transform="rotate(0,104,272)"/>
<polygon class="arrowhead" points="112,256 100,250.4 100,261 <polygon class="arrowhead" fill="black" points="112,256 100,
.6" fill="black" transform="rotate(0,104,256)"/> 250.4 100,261.6" transform="rotate(0,104,256)"/>
<polygon class="arrowhead" points="80,272 68,266.4 68,277.6" <polygon class="arrowhead" fill="black" points="80,272 68,26
fill="black" transform="rotate(180,72,272)"/> 6.4 68,277.6" transform="rotate(180,72,272)"/>
<polygon class="arrowhead" points="48,272 36,266.4 36,277.6" <polygon class="arrowhead" fill="black" points="48,272 36,26
fill="black" transform="rotate(0,40,272)"/> 6.4 36,277.6" transform="rotate(0,40,272)"/>
<polygon class="arrowhead" points="16,272 4,266.4 4,277.6" f <polygon class="arrowhead" fill="black" points="16,272 4,266
ill="black" transform="rotate(180,8,272)"/> .4 4,277.6" transform="rotate(180,8,272)"/>
<polygon class="arrowhead" points="16,256 4,250.4 4,261.6" f <polygon class="arrowhead" fill="black" points="16,256 4,250
ill="black" transform="rotate(180,8,256)"/> .4 4,261.6" transform="rotate(180,8,256)"/>
<g class="text"> <g class="text">
<text x="120" y="36">Y</text> <text x="120" y="36">Y</text>
<text x="56" y="100">X</text> <text x="56" y="100">X</text>
<text x="184" y="100">_</text> <text x="184" y="100">_</text>
<text x="24" y="164">W</text> <text x="24" y="164">W</text>
<text x="88" y="164">_</text> <text x="88" y="164">_</text>
<text x="152" y="164">Z</text> <text x="152" y="164">Z</text>
<text x="216" y="164">_</text> <text x="216" y="164">_</text>
<text x="16" y="180">/</text> <text x="16" y="180">/</text>
<text x="32" y="180">\</text> <text x="32" y="180">\</text>
skipping to change at line 5657 skipping to change at line 5914
<text x="104" y="292">-</text> <text x="104" y="292">-</text>
<text x="136" y="292">-</text> <text x="136" y="292">-</text>
<text x="152" y="292">R</text> <text x="152" y="292">R</text>
<text x="168" y="292">-</text> <text x="168" y="292">-</text>
<text x="200" y="292">-</text> <text x="200" y="292">-</text>
<text x="216" y="292">R</text> <text x="216" y="292">R</text>
<text x="232" y="292">-</text> <text x="232" y="292">-</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-12.4.3.3-11.1 .2">
Y Y
| |
.-----+-----. .-----+-----.
/ \ / \
X _ X _
| | | |
.-+-. .-+-. .-+-. .-+-.
/ \ / \ / \ / \
W _ Z _ W _ Z _
/ \ / \ / \ / \ / \ / \ / \ / \
A B C D E F _ _ A B C D E F _ _
1 1
0 1 2 3 4 5 6 7 8 9 0 0 1 2 3 4 5 6 7 8 9 0
<-----------> R <-----------> &lt;-----------&gt; R &lt;-----------&gt;
<---> R <---> <---> R <---> &lt;---&gt; R &lt;---&gt; &lt;---&gt; R &lt;---&gt;
- R - - R - - R - - R - - R - - R - - R - - R -
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>The presence of a <tt>ratchet_tree</tt> extension in a GroupInfo message does not <t indent="0" pn="section-12.4.3.3-12">The presence of a <tt>ratchet _tree</tt> extension in a GroupInfo message does not
result in any changes to the GroupContext extensions for the group. The ratchet result in any changes to the GroupContext extensions for the group. The ratchet
tree provided is simply stored by the client and used for MLS operations.</t> tree provided is simply stored by the client and used for MLS operations.</t>
<t>If this extension is not provided in a Welcome message, then the client will <t indent="0" pn="section-12.4.3.3-13">If this extension is not prov ided in a Welcome message, then the client will
need to fetch the ratchet tree over some other channel before it can generate or need to fetch the ratchet tree over some other channel before it can generate or
process Commit messages. Applications should ensure that this out-of-band process Commit messages. Applications should ensure that this out-of-band
channel is provided with security protections equivalent to the protections that channel is provided with security protections equivalent to the protections that
are afforded to Proposal and Commit messages. For example, an application that are afforded to Proposal and Commit messages. For example, an application that
encrypts Proposal and Commit messages might distribute ratchet trees encrypted encrypts Proposal and Commit messages might distribute ratchet trees encrypted
using a key exchanged over the MLS channel.</t> using a key exchanged over the MLS channel.</t>
<t>Regardless of how the client obtains the tree, the client MUST ve rify that the <t indent="0" pn="section-12.4.3.3-14">Regardless of how the client obtains the tree, the client <bcp14>MUST</bcp14> verify that the
root hash of the ratchet tree matches the <tt>tree_hash</tt> of the GroupContext before root hash of the ratchet tree matches the <tt>tree_hash</tt> of the GroupContext before
using the tree for MLS operations.</t> using the tree for MLS operations.</t>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section anchor="extensibility"> <section anchor="extensibility" numbered="true" removeInRFC="false" toc="inc
<name>Extensibility</name> lude" pn="section-13">
<t>The base MLS protocol can be extended in a few ways. New ciphersuites <name slugifiedName="name-extensibility">Extensibility</name>
can be <t indent="0" pn="section-13-1">The base MLS protocol can be extended in a
few ways. New cipher suites can be
added to enable the use of new cryptographic algorithms. New types of proposals added to enable the use of new cryptographic algorithms. New types of proposals
can be used to perform new actions within an epoch. Extension fields can be can be used to perform new actions within an epoch. Extension fields can be
used to add additional information to the protocol. In this section, we discuss used to add additional information to the protocol. In this section, we discuss
some constraints on these extensibility mechanisms that are necessary to ensure some constraints on these extensibility mechanisms that are necessary to ensure
broad interoperability.</t> broad interoperability.</t>
<section anchor="additional-ciphersuites"> <section anchor="additional-cipher-suites" numbered="true" removeInRFC="fa
<name>Additional Ciphersuites</name> lse" toc="include" pn="section-13.1">
<t>As discussed in <xref target="ciphersuites"/>, MLS allows the partici <name slugifiedName="name-additional-cipher-suites">Additional Cipher Su
pants in a group to ites</name>
<t indent="0" pn="section-13.1-1">As discussed in <xref target="cipher-s
uites" format="default" sectionFormat="of" derivedContent="Section 5.1"/>, MLS a
llows the participants in a group to
negotiate the cryptographic algorithms used within the group. This negotiate the cryptographic algorithms used within the group. This
extensibility is important for maintaining the security of the protocol over extensibility is important for maintaining the security of the protocol over
time <xref target="RFC7696"/>. It also creates a risk of interoperability failu time <xref target="RFC7696" format="default" sectionFormat="of" derivedContent="
re due to RFC7696"/>. It also creates a risk of interoperability failure due to
clients not supporting a common ciphersuite.</t> clients not supporting a common cipher suite.</t>
<t>The ciphersuite registry defined in <xref target="mls-ciphersuites"/> <t indent="0" pn="section-13.1-2">The cipher suite registry defined in <
attempts to strike a xref target="mls-cipher-suites" format="default" sectionFormat="of" derivedConte
nt="Section 17.1"/> attempts to strike a
balance on this point. On the one hand, the base policy for the registry is balance on this point. On the one hand, the base policy for the registry is
Specification Required, a fairly low bar designed to avoid the need for Specification Required, a fairly low bar designed to avoid the need for
standards work in cases where different ciphers are needed for niche standards work in cases where different ciphers are needed for niche
applications. There is a higher bar (Standards Action) for ciphers to set the applications. On the other hand, there is a higher bar (Standards Action) for c iphers to set the
Recommended field in the registry. This higher bar is there in part to ensure Recommended field in the registry. This higher bar is there in part to ensure
that the interoperability implications of new ciphersuites are considered.</t> that the interoperability implications of new cipher suites are considered.</t>
<t>MLS ciphersuites are defined independent of MLS versions, so that in <t indent="0" pn="section-13.1-3">MLS cipher suites are defined independ
principle ent of MLS versions, so that in principle,
the same ciphersuite can be used across versions. Standards work defining new the same cipher suite can be used across versions. Standards work defining new
versions of MLS should consider whether it is desirable for the new version to versions of MLS should consider whether it is desirable for the new version to
be compatible with existing ciphersuites, or whether the new version should rule be compatible with existing cipher suites, or whether the new version should rul
out some ciphersuites. For example, a new version could follow the example of e
HTTP/2, which restricted the set of allowed TLS ciphers (see Section 9.2.2 of out some cipher suites. For example, a new version could follow the example of
<xref target="RFC9113"/>.</t> HTTP/2, which restricted the set of allowed TLS ciphers (see <xref section="9.2.
2" sectionFormat="of" target="RFC9113" format="default" derivedLink="https://rfc
-editor.org/rfc/rfc9113#section-9.2.2" derivedContent="RFC9113"/>).</t>
</section> </section>
<section anchor="proposals-1"> <section anchor="proposals-1" numbered="true" removeInRFC="false" toc="inc
<name>Proposals</name> lude" pn="section-13.2">
<t>Commit messages do not have an extension field because the set of pro <name slugifiedName="name-proposals-2">Proposals</name>
posals is <t indent="0" pn="section-13.2-1">Commit messages do not have an extensi
extensible. As discussed in <xref target="commit"/>, Proposals with a non-defau on field because the set of proposals is
lt proposal extensible. As discussed in <xref target="commit" format="default" sectionForma
type MUST NOT be included in a commit unless the proposal type is supported by t="of" derivedContent="Section 12.4"/>, Proposals with a non-default proposal
type <bcp14>MUST NOT</bcp14> be included in a commit unless the proposal type is
supported by
all the members of the group that will process the Commit.</t> all the members of the group that will process the Commit.</t>
</section> </section>
<section anchor="credential-extensibility"> <section anchor="credential-extensibility" numbered="true" removeInRFC="fa
<name>Credential Extensibility</name> lse" toc="include" pn="section-13.3">
<t>In order to ensure that MLS provides meaningful authentication it is <name slugifiedName="name-credential-extensibility">Credential Extensibi
important lity</name>
<t indent="0" pn="section-13.3-1">In order to ensure that MLS provides m
eaningful authentication, it is important
that each member is able to authenticate some identity information for each that each member is able to authenticate some identity information for each
other member. Identity information is encoded in Credentials, so this property other member. Identity information is encoded in Credentials, so this property
is provided by ensuring that members use compatible credential types.</t> is provided by ensuring that members use compatible credential types.</t>
<t>The types of credential that may be used in a group is restricted to what all <t indent="0" pn="section-13.3-2">The only types of credential that may be used in a group are those that all
members of the group support, as specified by the <tt>capabilities</tt> field of each members of the group support, as specified by the <tt>capabilities</tt> field of each
LeafNode in the ratchet tree. An application can introduce new credential types LeafNode in the ratchet tree. An application can introduce new credential types
by choosing an unallocated identifier from the registry in by choosing an unallocated identifier from the registry in
<xref target="mls-credential-types"/> and indicating support for the credential type in <xref target="mls-credential-types" format="default" sectionFormat="of" derivedC ontent="Section 17.5"/> and indicating support for the credential type in
published LeafNodes, whether in Update proposals to existing groups or published LeafNodes, whether in Update proposals to existing groups or
KeyPackages that are added to new groups. Once all members in a group indicate KeyPackages that are added to new groups. Once all members in a group indicate
support for the credential type, members can start using LeafNodes with the new support for the credential type, members can start using LeafNodes with the new
credential. Application may enforce that certain credential types always remain credential. Application may enforce that certain credential types always remain
supported by adding a <tt>required_capabilities</tt> extension to the group's supported by adding a <tt>required_capabilities</tt> extension to the group's
GroupContext, which would prevent any member from being added to the group that GroupContext, which would prevent any member from being added to the group that
doesn't support them.</t> doesn't support them.</t>
<t>In future extensions to MLS, it may be useful to allow a member to pr esent more <t indent="0" pn="section-13.3-3">In future extensions to MLS, it may be useful to allow a member to present more
than one credential. For example, such credentials might present different than one credential. For example, such credentials might present different
attributes attested by different authorities. To be consistent with the general attributes attested by different authorities. To be consistent with the general
principle stated at the beginning of this section, such an extension would need principle stated at the beginning of this section, such an extension would need
to ensure that each member can authenticate some identity for each other member. to ensure that each member can authenticate some identity for each other member.
For each pair of members (Alice, Bob), Alice would need to present at least one For each pair of members (Alice, Bob), Alice would need to present at least one
credential of a type that Bob supports.</t> credential of a type that Bob supports.</t>
</section> </section>
<section anchor="extensions"> <section anchor="extensions" numbered="true" removeInRFC="false" toc="incl
<name>Extensions</name> ude" pn="section-13.4">
<t>This protocol includes a mechanism for negotiating extension paramete <name slugifiedName="name-extensions">Extensions</name>
rs similar <t indent="0" pn="section-13.4-1">This protocol includes a mechanism for
to the one in TLS <xref target="RFC8446"/>. In TLS, extension negotiation is on negotiating extension parameters similar
e-to-one: The to the one in TLS <xref target="RFC8446" format="default" sectionFormat="of" der
ivedContent="RFC8446"/>. In TLS, extension negotiation is one-to-one: The
client offers extensions in its ClientHello message, and the server expresses client offers extensions in its ClientHello message, and the server expresses
its choices for the session with extensions in its ServerHello and its choices for the session with extensions in its ServerHello and
EncryptedExtensions messages. In MLS, extensions appear in the following EncryptedExtensions messages. In MLS, extensions appear in the following
places:</t> places:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>In KeyPackages, to describe additional information related to the 3.4-2">
client</li> <li pn="section-13.4-2.1">In KeyPackages, to describe additional infor
<li>In LeafNodes, to describe additional information about the client mation related to the client</li>
or its <li pn="section-13.4-2.2">In LeafNodes, to describe additional informa
tion about the client or its
participation in the group (once in the ratchet tree)</li> participation in the group (once in the ratchet tree)</li>
<li>In the GroupInfo, to tell new members of a group what parameters a re <li pn="section-13.4-2.3">In the GroupInfo, to tell new members of a g roup what parameters are
being used by the group, and to provide any additional details required to being used by the group, and to provide any additional details required to
join the group</li> join the group</li>
<li>In the GroupContext object, to ensure that all members of the grou p have the <li pn="section-13.4-2.4">In the GroupContext object, to ensure that a ll members of the group have the
same view of the parameters in use</li> same view of the parameters in use</li>
</ul> </ul>
<t>In other words, an application can use GroupContext extensions to ens ure that <t indent="0" pn="section-13.4-3">In other words, an application can use GroupContext extensions to ensure that
all members of the group agree on a set of parameters. Clients indicate their all members of the group agree on a set of parameters. Clients indicate their
support for parameters in the <tt>capabilities</tt> field of their LeafNode. New support for parameters in the <tt>capabilities</tt> field of their LeafNode. New
members of a group are informed of the group's GroupContext extensions via the members of a group are informed of the group's GroupContext extensions via the
<tt>extensions</tt> field in the <tt>group_context</tt> field of the GroupInfo o bject. The <tt>extensions</tt> field in the <tt>group_context</tt> field of the GroupInfo o bject. The
<tt>extensions</tt> field in a GroupInfo object (outside of the <tt>group_contex t</tt> field) <tt>extensions</tt> field in a GroupInfo object (outside of the <tt>group_contex t</tt> field)
can be used to provide additional parameters to new joiners that are used to can be used to provide additional parameters to new joiners that are used to
join the group.</t> join the group.</t>
<t>This extension mechanism is designed to allow for the secure and forw <t indent="0" pn="section-13.4-4">This extension mechanism is designed t
ard-compatible o allow for the secure and forward-compatible
negotiation of extensions. For this to work, implementations MUST correctly negotiation of extensions. For this to work, implementations <bcp14>MUST</bcp14
> correctly
handle extensible fields:</t> handle extensible fields:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>A client that posts a KeyPackage MUST support all parameters adver 3.4-5">
tised in <li pn="section-13.4-5.1">A client that posts a KeyPackage <bcp14>MUST
it. Otherwise, another client might fail to interoperate by selecting one of </bcp14> support all parameters advertised in
it. Otherwise, another client might fail to interoperate by selecting one of
those parameters.</li> those parameters.</li>
<li>A client processing a KeyPackage object MUST ignore all unrecogniz <li pn="section-13.4-5.2">A client processing a KeyPackage object <bcp
ed values 14>MUST</bcp14> ignore all unrecognized values
in the <tt>capabilities</tt> field of the <tt>LeafNode</tt>, and all unknown ext in the <tt>capabilities</tt> field of the LeafNode and all unknown extensions in
ensions in
the <tt>extensions</tt> and <tt>leaf_node.extensions</tt> fields. Otherwise, it could fail the <tt>extensions</tt> and <tt>leaf_node.extensions</tt> fields. Otherwise, it could fail
to interoperate with newer clients.</li> to interoperate with newer clients.</li>
<li>A client processing a GroupInfo object MUST ignore all unrecognize d <li pn="section-13.4-5.3">A client processing a GroupInfo object <bcp1 4>MUST</bcp14> ignore all unrecognized
extensions in the <tt>extensions</tt> field.</li> extensions in the <tt>extensions</tt> field.</li>
<li>Any field containing a list of extensions MUST NOT have more than one <li pn="section-13.4-5.4">Any field containing a list of extensions <b cp14>MUST NOT</bcp14> have more than one
extension of any given type.</li> extension of any given type.</li>
<li>A client adding a new member to a group MUST verify that the LeafN ode for the <li pn="section-13.4-5.5">A client adding a new member to a group <bcp 14>MUST</bcp14> verify that the LeafNode for the
new member is compatible with the group's extensions. The <tt>capabilities</tt> new member is compatible with the group's extensions. The <tt>capabilities</tt>
field MUST indicate support for each extension in the GroupContext.</li> field <bcp14>MUST</bcp14> indicate support for each extension in the GroupContex
<li>A client joining a group MUST verify that it supports every extens t.</li>
ion in the <li pn="section-13.4-5.6">A client joining a group <bcp14>MUST</bcp14>
GroupContext for the group. Otherwise, it MUST treat the enclosing verify that it supports every extension in the
GroupContext for the group. Otherwise, it <bcp14>MUST</bcp14> treat the enclosi
ng
GroupInfo message as invalid and not join the group.</li> GroupInfo message as invalid and not join the group.</li>
</ul> </ul>
<t>Note that the latter two requirements mean that all MLS GroupContext <t indent="0" pn="section-13.4-6">Note that the latter two requirements
extensions mean that all MLS GroupContext extensions
are mandatory, in the sense that an extension in use by the group MUST be are mandatory, in the sense that an extension in use by the group <bcp14>MUST</b
cp14> be
supported by all members of the group.</t> supported by all members of the group.</t>
<t>The parameters of a group may be changed by sending a GroupContextExt <t indent="0" pn="section-13.4-7">The parameters of a group may be chang
ensions ed by sending a GroupContextExtensions
proposal to enable additional extensions (<xref target="groupcontextextensions"/ proposal to enable additional extensions (<xref target="groupcontextextensions"
>), or format="default" sectionFormat="of" derivedContent="Section 12.1.7"/>), or
by reinitializing the group (<xref target="reinitialization"/>).</t> by reinitializing the group (<xref target="reinitialization" format="default" se
ctionFormat="of" derivedContent="Section 11.2"/>).</t>
</section> </section>
<section anchor="grease"> <section anchor="grease" numbered="true" removeInRFC="false" toc="include"
<name>GREASE</name> pn="section-13.5">
<t>As described in <xref target="extensions"/>, clients are required to <name slugifiedName="name-grease">GREASE</name>
ignore unknown values <t indent="0" pn="section-13.5-1">As described in <xref target="extensio
ns" format="default" sectionFormat="of" derivedContent="Section 13.4"/>, clients
are required to ignore unknown values
for certain parameters. To help ensure that other clients implement this for certain parameters. To help ensure that other clients implement this
behavior, a client can follow the “Generate Random Extensions And Sustain behavior, a client can follow the "Generate Random Extensions And Sustain
Extensibility” or GREASE approach described in <xref target="RFC8701"/>. In the Extensibility" or GREASE approach described in <xref target="RFC8701" format="de
context of fault" sectionFormat="of" derivedContent="RFC8701"/>. In the context of
MLS, this means that a client generating a KeyPackage, LeafNode, or GroupInfo ob ject includes MLS, this means that a client generating a KeyPackage, LeafNode, or GroupInfo ob ject includes
random values in certain fields which would be ignored by a random values in certain fields which would be ignored by a
correctly-implemented client processing the message. A client that incorrectly correctly implemented client processing the message. A client that incorrectly
rejects unknown code points will fail to process such a message, providing a rejects unknown code points will fail to process such a message, providing a
signal to its implementer that the client needs to be fixed.</t> signal to its implementer that the client needs to be fixed.</t>
<t>When generating the following fields, an MLS client SHOULD include a random <t indent="0" pn="section-13.5-2">When generating the following fields, an MLS client <bcp14>SHOULD</bcp14> include a random
selection of values chosen from these GREASE values:</t> selection of values chosen from these GREASE values:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li> 3.5-3">
<tt>LeafNode.capabilities.ciphersuites</tt></li> <li pn="section-13.5-3.1">
<li> <tt>LeafNode.capabilities.cipher_suites</tt>
<tt>LeafNode.capabilities.extensions</tt></li> </li>
<li> <li pn="section-13.5-3.2">
<tt>LeafNode.capabilities.proposals</tt></li> <tt>LeafNode.capabilities.extensions</tt>
<li> </li>
<tt>LeafNode.capabilities.credentials</tt></li> <li pn="section-13.5-3.3">
<li> <tt>LeafNode.capabilities.proposals</tt>
<tt>LeafNode.extensions</tt></li> </li>
<li> <li pn="section-13.5-3.4">
<tt>KeyPackage.extensions</tt></li> <tt>LeafNode.capabilities.credentials</tt>
<li> </li>
<tt>GroupInfo.extensions</tt></li> <li pn="section-13.5-3.5">
<tt>LeafNode.extensions</tt>
</li>
<li pn="section-13.5-3.6">
<tt>KeyPackage.extensions</tt>
</li>
<li pn="section-13.5-3.7">
<tt>GroupInfo.extensions</tt>
</li>
</ul> </ul>
<t>For the KeyPackage and GroupInfo extensions, the <tt>extension_data</ <t indent="0" pn="section-13.5-4">For the KeyPackage and GroupInfo exten
tt> for GREASE sions, the <tt>extension_data</tt> for GREASE
extensions MAY have any contents selected by the sender, since they will be extensions <bcp14>MAY</bcp14> have any contents selected by the sender, since th
ignored by a correctly-implemented receiver. For example, a sender might ey will be
populate these extensions with a randomly-sized amount of random data.</t> ignored by a correctly implemented receiver. For example, a sender might
<t>GREASE values MUST NOT be sent in the following fields, because an un populate these extensions with a randomly sized amount of random data.</t>
supported <t indent="0" pn="section-13.5-5">Note that any GREASE values added to <
value in one these fields (including a GREASE value), will cause the enclosing tt>LeafNode.extensions</tt> need to be reflected
in <tt>LeafNode.capabilities.extensions</tt>, since the LeafNode validation proc
ess
described in <xref target="leaf-node-validation" format="default" sectionFormat=
"of" derivedContent="Section 7.3"/> requires that these two fields be
consistent.</t>
<t indent="0" pn="section-13.5-6">GREASE values <bcp14>MUST NOT</bcp14>
be sent in the following fields, because an unsupported
value in one these fields (including a GREASE value) will cause the enclosing
message to be rejected:</t> message to be rejected:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li> 3.5-7">
<tt>Proposal.proposal_type</tt></li> <li pn="section-13.5-7.1">
<li> <tt>Proposal.proposal_type</tt>
<tt>Credential.credential_type</tt></li> </li>
<li> <li pn="section-13.5-7.2">
<tt>GroupContext.extensions</tt></li> <tt>Credential.credential_type</tt>
<li> </li>
<tt>GroupContextExtensions.extensions</tt></li> <li pn="section-13.5-7.3">
<tt>GroupContext.extensions</tt>
</li>
<li pn="section-13.5-7.4">
<tt>GroupContextExtensions.extensions</tt>
</li>
</ul> </ul>
<t>A set of values reserved for GREASE have been registered in the vario <t indent="0" pn="section-13.5-8">Values reserved for GREASE have been r
us egistered in the various
registries in <xref target="iana-considerations"/>. This prevents conflict betw registries in <xref target="iana-considerations" format="default" sectionFormat=
een GREASE "of" derivedContent="Section 17"/>. This prevents conflict between GREASE
and real future values. The following values are reserved in each registry: and real future values. The following values are reserved in each registry:
<tt>0x0A0A</tt>, <tt>0x1A1A</tt>, <tt>0x2A2A</tt>, <tt>0x3A3A</tt>, <tt>0x4A4A</ tt>, <tt>0x5A5A</tt>, <tt>0x6A6A</tt>, <tt>0x7A7A</tt>, <tt>0x0A0A</tt>, <tt>0x1A1A</tt>, <tt>0x2A2A</tt>, <tt>0x3A3A</tt>, <tt>0x4A4A</ tt>, <tt>0x5A5A</tt>, <tt>0x6A6A</tt>, <tt>0x7A7A</tt>,
<tt>0x8A8A</tt>, <tt>0x9A9A</tt>, <tt>0xAAAA</tt>, <tt>0xBABA</tt>, <tt>0xCACA</ tt>, <tt>0xDADA</tt>, and <tt>0xEAEA</tt>. (The <tt>0x8A8A</tt>, <tt>0x9A9A</tt>, <tt>0xAAAA</tt>, <tt>0xBABA</tt>, <tt>0xCACA</ tt>, <tt>0xDADA</tt>, and <tt>0xEAEA</tt>. (The
value <tt>0xFAFA</tt> falls within the private use range.) These values MUST onl y value <tt>0xFAFA</tt> falls within the private use range.) These values <bcp14>M UST</bcp14> only
appear in the fields listed above, and not, for example, in the <tt>proposal_typ e</tt> appear in the fields listed above, and not, for example, in the <tt>proposal_typ e</tt>
field of a Proposal. Clients MUST NOT implement any special processing rules field of a Proposal. Clients <bcp14>MUST NOT</bcp14> implement any special proc essing rules
for how to handle these values when receiving them, since this negates their for how to handle these values when receiving them, since this negates their
utility for detecting extensibility failures.</t> utility for detecting extensibility failures.</t>
<t>GREASE values MUST be handled using normal logic for processing unsup <t indent="0" pn="section-13.5-9">GREASE values <bcp14>MUST</bcp14> be h
ported andled using normal logic for processing unsupported
values. When comparing lists of capabilities to identify mutually-supported values. When comparing lists of capabilities to identify mutually supported
capabilities, clients MUST represent their own capabilities with a list capabilities, clients <bcp14>MUST</bcp14> represent their own capabilities with
a list
containing only the capabilities actually supported, without any GREASE values. containing only the capabilities actually supported, without any GREASE values.
In other words, lists including GREASE values are only sent to other clients; In other words, lists including GREASE values are only sent to other clients;
representations of a client's own capabilities MUST NOT contain GREASE values.</ t> representations of a client's own capabilities <bcp14>MUST NOT</bcp14> contain G REASE values.</t>
</section> </section>
</section> </section>
<section anchor="sequencing"> <section anchor="sequencing" numbered="true" removeInRFC="false" toc="includ
<name>Sequencing of State Changes</name> e" pn="section-14">
<t>Each Commit message is premised on a given starting state, <name slugifiedName="name-sequencing-of-state-changes">Sequencing of State
Changes</name>
<t indent="0" pn="section-14-1">Each Commit message is premised on a given
starting state,
indicated by the <tt>epoch</tt> field of the enclosing FramedContent. indicated by the <tt>epoch</tt> field of the enclosing FramedContent.
If the changes implied by a Commit message are made If the changes implied by a Commit message are made
starting from a different state, the results will be incorrect.</t> starting from a different state, the results will be incorrect.</t>
<t>This need for sequencing is not a problem as long as each time a <t indent="0" pn="section-14-2">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 group member sends a Commit message, it is based on the most
current state of the group. In practice, however, there is a risk current state of the group. In practice, however, there is a risk
that two members will generate Commit messages simultaneously that two members will generate Commit messages simultaneously
based on the same state.</t> based on the same state.</t>
<t>Applications MUST have an established way to resolve conflicting Commit messages <t indent="0" pn="section-14-3">Applications <bcp14>MUST</bcp14> have an e stablished way to resolve conflicting Commit messages
for the same epoch. They can do this either by preventing conflicting messages for the same epoch. They can do this either by preventing conflicting messages
from occurring in the first place, or by developing rules for deciding which from occurring in the first place, or by developing rules for deciding which
Commit out of several sent in an epoch will be canonical. The approach chosen Commit out of several sent in an epoch will be canonical. The approach chosen
MUST minimize the amount of time that forked or previous group states are kept <bcp14>MUST</bcp14> minimize the amount of time that forked or previous group st ates are kept
in memory, and promptly delete them once they're no longer necessary to ensure in memory, and promptly delete them once they're no longer necessary to ensure
forward secrecy.</t> forward secrecy.</t>
<t>The generation of Commit messages MUST NOT modify a client's state, sin ce the <t indent="0" pn="section-14-4">The generation of Commit messages <bcp14>M UST NOT</bcp14> modify a client's state, since the
client doesn't know at that time whether the changes implied by the Commit client doesn't know at that time whether the changes implied by the Commit
message will conflict with another Commit or not. Similarly, the Welcome message will conflict with another Commit or not. Similarly, the Welcome
message corresponding to a Commit MUST NOT be delivered to a new message corresponding to a Commit <bcp14>MUST NOT</bcp14> be delivered to a new
joiner until it's clear that the Commit has been accepted.</t> joiner until it's clear that the Commit has been accepted.</t>
<t>Regardless of how messages are kept in sequence, there is a risk that <t indent="0" pn="section-14-5">Regardless of how messages are kept in seq uence, there is a risk that
in a sufficiently busy group, a given member may never in a sufficiently busy group, a given member may never
be able to send a Commit message because they always lose to other be able to send a Commit message because they always lose to other
members. The degree to which this is a practical problem will depend members. The degree to which this is a practical problem will depend
on the dynamics of the application.</t> on the dynamics of the application.</t>
</section> </section>
<section anchor="application-messages"> <section anchor="application-messages" numbered="true" removeInRFC="false" t
<name>Application Messages</name> oc="include" pn="section-15">
<t>The primary purpose of handshake messages are to provide an authenticat <name slugifiedName="name-application-messages">Application Messages</name
ed group >
<t indent="0" pn="section-15-1">The primary purpose of handshake messages
is to provide an authenticated group
key exchange to clients. In order to protect application messages sent among the key exchange to clients. In order to protect application messages sent among the
members of a group, the <tt>encryption_secret</tt> provided by the key schedule is used members of a group, the <tt>encryption_secret</tt> provided by the key schedule is used
to derive a sequence of nonces and keys for message encryption. Every epoch to derive a sequence of nonces and keys for message encryption. Every epoch
moves the key schedule forward which triggers the creation of a new secret moves the key schedule forward, which triggers the creation of a new secret
tree, as described in <xref target="secret-tree"/>, along with a new set of symm tree, as described in <xref target="secret-tree" format="default" sectionFormat=
etric "of" derivedContent="Section 9"/>, along with a new set of symmetric
ratchets of nonces and keys for each member.</t> ratchets of nonces and keys for each member.</t>
<t>Each client maintains their own local copy of the key <t indent="0" pn="section-15-2">Each client maintains their own local copy of the key
schedule for each epoch during which they are a group member. They schedule for each epoch during which they are a group member. They
derive new keys, nonces, and secrets as needed while deleting old derive new keys, nonces, and secrets as needed while deleting old
ones as soon as they have been used.</t> ones as soon as they have been used.</t>
<t>The group identifier and epoch allow a recipient to know which group se crets <t indent="0" pn="section-15-3">The group identifier and epoch allow a rec ipient to know which group secrets
should be used and from which <tt>epoch_secret</tt> to start computing other sec rets. should be used and from which <tt>epoch_secret</tt> to start computing other sec rets.
The sender identifier and content type is used to identify which The sender identifier and content type are used to identify which
symmetric ratchet to use from the secret tree. The symmetric ratchet to use from the secret tree. The
<tt>generation</tt> counter determines how far into the ratchet to iterate in <tt>generation</tt> counter determines how far into the ratchet to iterate in
order to produce the required nonce and key for encryption or decryption.</t> order to produce the required nonce and key for encryption or decryption.</t>
<section anchor="padding"> <section anchor="padding" numbered="true" removeInRFC="false" toc="include
<name>Padding</name> " pn="section-15.1">
<t>Application messages MAY be padded to provide some resistance <name slugifiedName="name-padding">Padding</name>
<t indent="0" pn="section-15.1-1">Application messages <bcp14>MAY</bcp14
> be padded to provide some resistance
against traffic analysis techniques over encrypted traffic against traffic analysis techniques over encrypted traffic
<xref target="CLINIC"/> <xref target="CLINIC" format="default" sectionFormat="of" derivedContent="CLINIC
<xref target="HCJ16"/>. "/> <xref target="HCJ16" format="default" sectionFormat="of" derivedContent="HCJ
16"/>.
While MLS might deliver the same payload less frequently across While MLS might deliver the same payload less frequently across
a lot of ciphertexts than traditional web servers, it might still provide a lot of ciphertexts than traditional web servers, it might still provide
the attacker enough information to mount an attack. If Alice asks Bob the attacker enough information to mount an attack. If Alice asks Bob
"When are we going to the movie?", then the answer "Wednesday" could be leaked "When are we going to the movie?", then the answer "Wednesday" could be leaked
to an adversary solely by the ciphertext length.</t> to an adversary solely by the ciphertext length.</t>
<t>The length of the <tt>padding</tt> field in <tt>PrivateMessageContent </tt> can be <t indent="0" pn="section-15.1-2">The length of the <tt>padding</tt> fie ld in PrivateMessageContent can be
chosen by the sender at the time of message encryption. Senders may use padding chosen by the sender at the time of message encryption. Senders may use padding
to reduce the ability of attackers outside the group to infer the size of the to reduce the ability of attackers outside the group to infer the size of the
encrypted content. Note, however, that the transports used to carry MLS encrypted content. Note, however, that the transports used to carry MLS
messages may have maximum message sizes, so padding schemes SHOULD avoid messages may have maximum message sizes, so padding schemes <bcp14>SHOULD</bcp14 > avoid
increasing message size beyond any such limits that exist in a given increasing message size beyond any such limits that exist in a given
deployment scenario.</t> deployment scenario.</t>
</section> </section>
<section anchor="restrictions"> <section anchor="restrictions" numbered="true" removeInRFC="false" toc="in
<name>Restrictions</name> clude" pn="section-15.2">
<t>During each epoch, senders MUST NOT encrypt more data than permitted <name slugifiedName="name-restrictions">Restrictions</name>
by the <t indent="0" pn="section-15.2-1">During each epoch, senders <bcp14>MUST
security bounds of the AEAD scheme used <xref target="I-D.irtf-cfrg-aead-limits" NOT</bcp14> encrypt more data than permitted by the
/>.</t> security bounds of the AEAD scheme used <xref target="I-D.irtf-cfrg-aead-limits"
<t>Note that each change to the group through a handshake message will a format="default" sectionFormat="of" derivedContent="CFRG-AEAD-LIMITS"/>.</t>
lso set a <t indent="0" pn="section-15.2-2">Note that each change to the group thr
new <tt>encryption_secret</tt>. Hence this change MUST be applied before encrypt ough a handshake message will also set a
ing new <tt>encryption_secret</tt>. Hence this change <bcp14>MUST</bcp14> be applied
before encrypting
any new application message. This is required both to ensure that any users any new application message. This is required both to ensure that any users
removed from the group can no longer receive messages and to (potentially) removed from the group can no longer receive messages and to (potentially)
recover confidentiality and authenticity for future messages despite a past recover confidentiality and authenticity for future messages despite a past
state compromise.</t> state compromise.</t>
</section> </section>
<section anchor="delayed-and-reordered-application-messages"> <section anchor="delayed-and-reordered-application-messages" numbered="tru
<name>Delayed and Reordered Application messages</name> e" removeInRFC="false" toc="include" pn="section-15.3">
<t>Since each application message contains the group identifier, the epo <name slugifiedName="name-delayed-and-reordered-appli">Delayed and Reord
ch, and a ered Application Messages</name>
<t indent="0" pn="section-15.3-1">Since each application message contain
s the group identifier, the epoch, and a
generation counter, a client can receive messages out of order. When messages generation counter, a client can receive messages out of order. When messages
are received out of order, the client moves the sender ratchet forward to match are received out of order, the client moves the sender ratchet forward to match
the received generation counter. Any unused nonce and key pairs from the ratchet the received generation counter. Any unused nonce and key pairs from the ratchet
are potentially stored so that they can be used to decrypt the messages which are potentially stored so that they can be used to decrypt the messages that
were delayed or reordered.</t> were delayed or reordered.</t>
<t>Applications SHOULD define a policy on how long to keep unused nonce and key <t indent="0" pn="section-15.3-2">Applications <bcp14>SHOULD</bcp14> def ine a policy on how long to keep unused nonce and key
pairs for a sender, and the maximum number to keep. This is in addition to pairs for a sender, and the maximum number to keep. This is in addition to
ensuring that these secrets are deleted according to the deletion schedule ensuring that these secrets are deleted according to the deletion schedule
defined in <xref target="deletion-schedule"/>. Applications SHOULD also define a policy defined in <xref target="deletion-schedule" format="default" sectionFormat="of" derivedContent="Section 9.2"/>. Applications <bcp14>SHOULD</bcp14> also define a policy
limiting the maximum number of steps that clients will move the ratchet forward limiting the maximum number of steps that clients will move the ratchet forward
in response to a new message. Messages received with a generation counter in response to a new message. Messages received with a generation counter
that's too much higher than the last message received would then be rejected. that is too much higher than the last message received would then be rejected.
This avoids causing a denial-of-service attack by requiring the recipient to This avoids causing a denial-of-service attack by requiring the recipient to
perform an excessive number of key derivations. For example, a malicious group perform an excessive number of key derivations. For example, a malicious group
member could send a message with <tt>generation = 0xffffffff</tt> at the beginni ng of a member could send a message with <tt>generation = 0xffffffff</tt> at the beginni ng of a
new epoch, forcing recipients to perform billions of key derivations unless they new epoch, forcing recipients to perform billions of key derivations unless they
apply limits of the type discussed above.</t> apply limits of the type discussed above.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations" numbered="true" removeInRFC="false
<name>Security Considerations</name> " toc="include" pn="section-16">
<t>The security goals of MLS are described in <xref target="I-D.ietf-mls-a <name slugifiedName="name-security-considerations">Security Considerations
rchitecture"/>. </name>
<t indent="0" pn="section-16-1">The security goals of MLS are described in
<xref target="I-D.ietf-mls-architecture" format="default" sectionFormat="of" de
rivedContent="MLS-ARCH"/>.
We describe here how the protocol achieves its goals at a high level, We describe here how the protocol achieves its goals at a high level,
though a complete security analysis is outside of the scope of this though a complete security analysis is outside of the scope of this
document. The Security Considerations section of <xref target="I-D.ietf-mls-arc hitecture"/> document. The Security Considerations section of <xref target="I-D.ietf-mls-arc hitecture" format="default" sectionFormat="of" derivedContent="MLS-ARCH"/>
provides some citations to detailed security analyses.</t> provides some citations to detailed security analyses.</t>
<section anchor="transport-security"> <section anchor="transport-security" numbered="true" removeInRFC="false" t
<name>Transport Security</name> oc="include" pn="section-16.1">
<t>Because MLS messages are protected at the message level, the <name slugifiedName="name-transport-security">Transport Security</name>
<t indent="0" pn="section-16.1-1">Because MLS messages are protected at
the message level, the
confidentiality and integrity of the group state do not depend on confidentiality and integrity of the group state do not depend on
those messages being protected in transit. However, an attacker who those messages being protected in transit. However, an attacker who
can observe those messages in transit will be able to learn about the can observe those messages in transit will be able to learn about the
group state, including potentially the group membership (see group state, including potentially the group membership (see
<xref target="group-membership"/> below). Such an attacker might also be able to <xref target="group-membership" format="default" sectionFormat="of" derivedConte nt="Section 16.4.3"/> below). Such an attacker might also be able to
mount denial-of-service attacks on the group or exclude new members by mount denial-of-service attacks on the group or exclude new members by
selectively removing messages in transit. In order to prevent this selectively removing messages in transit. In order to prevent this
form of attack, it is RECOMMENDED that all MLS messages be carried form of attack, it is <bcp14>RECOMMENDED</bcp14> that all MLS messages be carrie
over a secure transport such as TLS <xref target="RFC8446"/> or QUIC <xref targe d
t="RFC9000"/>.</t> over a secure transport such as TLS <xref target="RFC8446" format="default" sect
ionFormat="of" derivedContent="RFC8446"/> or QUIC <xref target="RFC9000" format=
"default" sectionFormat="of" derivedContent="RFC9000"/>.</t>
</section> </section>
<section anchor="confidentiality-of-the-group-secrets"> <section anchor="confidentiality-of-group-secrets" numbered="true" removeI
<name>Confidentiality of the Group Secrets</name> nRFC="false" toc="include" pn="section-16.2">
<t>Group secrets are partly derived from the output of a ratchet tree. R <name slugifiedName="name-confidentiality-of-group-se">Confidentiality o
atchet f Group Secrets</name>
<t indent="0" pn="section-16.2-1">Group secrets are partly derived from
the output of a ratchet tree. Ratchet
trees work by assigning each member of the group to a leaf in the tree and trees work by assigning each member of the group to a leaf in the tree and
maintaining the following property: the private key of a node in the tree is maintaining the following property: the private key of a node in the tree is
known only to members of the group that are assigned a leaf in the node's known only to members of the group that are assigned a leaf in the node's
subtree. This is called the <em>ratchet tree invariant</em> and it makes it poss ible to subtree. This is called the <em>tree invariant</em>, and it makes it possible to
encrypt to all group members except one, with a number of ciphertexts that is encrypt to all group members except one, with a number of ciphertexts that is
logarithmic in the number of group members.</t> logarithmic in the number of group members.</t>
<t>The ability to efficiently encrypt to all members except one allows m embers to <t indent="0" pn="section-16.2-2">The ability to efficiently encrypt to all members except one allows members to
be securely removed from a group. It also allows a member to rotate their be securely removed from a group. It also allows a member to rotate their
keypair such that the old private key can no longer be used to decrypt new key pair such that the old private key can no longer be used to decrypt new
messages.</t> messages.</t>
</section> </section>
<section anchor="confidentiality-of-sender-data"> <section anchor="confidentiality-of-sender-data" numbered="true" removeInR
<name>Confidentiality of Sender Data</name> FC="false" toc="include" pn="section-16.3">
<t>The PrivateMessage framing encrypts "sender data" that identifies whi <name slugifiedName="name-confidentiality-of-sender-d">Confidentiality o
ch group f Sender Data</name>
member sent an encrypted message, as described in <xref target="sender-data-encr <t indent="0" pn="section-16.3-1">The PrivateMessage framing encrypts "s
yption"/>. ender data" that identifies which group
As with the QUIC header protection scheme <xref section="5.4" sectionFormat="com member sent an encrypted message, as described in <xref target="sender-data-encr
ma" target="RFC9001"/>, this scheme yption" format="default" sectionFormat="of" derivedContent="Section 6.3.2"/>.
is a variant of the HN1 construction analyzed in <xref target="NAN"/>. A sample As with the QUIC header protection scheme <xref section="5.4" sectionFormat="com
of the ma" target="RFC9001" format="default" derivedLink="https://rfc-editor.org/rfc/rf
c9001#section-5.4" derivedContent="RFC9001"/>, this scheme
is a variant of the HN1 construction analyzed in <xref target="NAN" format="defa
ult" sectionFormat="of" derivedContent="NAN"/>. A sample of the
ciphertext is combined with a <tt>sender_data_secret</tt> to derive a key and no nce ciphertext is combined with a <tt>sender_data_secret</tt> to derive a key and no nce
that are used for AEAD encryption of the sender data.</t> that are used for AEAD encryption of the sender data.</t>
<t><tt>pseudocode <sourcecode type="pseudocode" markers="false" pn="section-16.3-2">
(key, nonce) = PRF(sender_data_secret, sample) (key, nonce) = PRF(sender_data_secret, sample)
encrypted_sender_data = encrypted_sender_data =
AEAD.Seal(key, nonce, sender_data_aad, sender_data) AEAD.Seal(key, nonce, sender_data_aad, sender_data)
</tt></t> </sourcecode>
<t>The only differences between this construction and HN1 as described i <t indent="0" pn="section-16.3-3">The only differences between this cons
n <xref target="NAN"/> are truction and HN1 as described in <xref target="NAN" format="default" sectionForm
(1) that it uses authenticated encryption instead of unauthenticated encryption at="of" derivedContent="NAN"/>
and (2) that it protects information used to derive a nonce instead of the nonce are that it (1) uses authenticated encryption instead of unauthenticated
itself.</t> encryption and (2) protects information used to derive a nonce instead of the
<t>Since the <tt>sender_data_secret</tt> is distinct from the content en nonce itself.</t>
cryption key, it <t indent="0" pn="section-16.3-4">Since the <tt>sender_data_secret</tt>
is distinct from the content encryption key, it
follows that the sender data encryption scheme achieves AE2 security as defined follows that the sender data encryption scheme achieves AE2 security as defined
in <xref target="NAN"/>, and therefore guarantees the confidentiality of the sen in <xref target="NAN" format="default" sectionFormat="of" derivedContent="NAN"/>
der data.</t> , and therefore guarantees the confidentiality of the sender data.</t>
<t>Use of the same <tt>sender_data_secret</tt> and ciphertext sample mor <t indent="0" pn="section-16.3-5">Use of the same <tt>sender_data_secret
e than once risks </tt> and ciphertext sample more than once risks
compromising sender data protection by reusing an AEAD (key, nonce) pair. For compromising sender data protection by reusing an AEAD (key, nonce) pair. For
example, in many AEAD schemes, reusing a key and nonce reveals the exclusive OR example, in many AEAD schemes, reusing a key and nonce reveals the exclusive OR
of the two plaintexts. Assuming the ciphertext output of the AEAD algorithm is of the two plaintexts. Assuming the ciphertext output of the AEAD algorithm is
indistinguishable from random data (i.e., the AEAD is AE1-secure in the phrasing indistinguishable from random data (i.e., the AEAD is AE1-secure in the phrasing
of <xref target="NAN"/>), the odds of two ciphertext samples being identical is roughly of <xref target="NAN" format="default" sectionFormat="of" derivedContent="NAN"/> ), the odds of two ciphertext samples being identical is roughly
2<sup>-L/2</sup>, i.e., the birthday bound.</t> 2<sup>-L/2</sup>, i.e., the birthday bound.</t>
<t>The AEAD algorithms for ciphersuites defined in this document all pro <t indent="0" pn="section-16.3-6">The AEAD algorithms for cipher suites
vide this defined in this document all provide this
property. The size of the sample depends on the ciphersuite's hash function, but property. The size of the sample depends on the cipher suite's hash function, bu
t
in all cases, the probability of collision is no more than 2<sup>-128</sup>. in all cases, the probability of collision is no more than 2<sup>-128</sup>.
Any future ciphersuite MUST use an AE1-secure AEAD algorithm.</t> Any future cipher suite <bcp14>MUST</bcp14> use an AE1-secure AEAD algorithm.</t >
</section> </section>
<section anchor="confidentiality-of-group-metadata"> <section anchor="confidentiality-of-group-metadata" numbered="true" remove
<name>Confidentiality of Group Metadata</name> InRFC="false" toc="include" pn="section-16.4">
<t>MLS does not provide confidentiality protection to some messages and <name slugifiedName="name-confidentiality-of-group-me">Confidentiality o
fields f Group Metadata</name>
<t indent="0" pn="section-16.4-1">MLS does not provide confidentiality p
rotection to some messages and fields
within messages:</t> within messages:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>KeyPackage messages</li> 6.4-2">
<li>GroupInfo messages</li> <li pn="section-16.4-2.1">KeyPackage messages</li>
<li>The unencrypted portion of a Welcome message</li> <li pn="section-16.4-2.2">GroupInfo messages</li>
<li>Any Proposal or Commit messages sent as PublicMessage messages</li <li pn="section-16.4-2.3">The unencrypted portion of a Welcome message
> </li>
<li>The unencrypted header fields in PrivateMessage messages</li> <li pn="section-16.4-2.4">Any Proposal or Commit messages sent as Publ
<li>The lengths of encrypted Welcome and PrivateMessage messages</li> icMessage messages</li>
<li pn="section-16.4-2.5">The unencrypted header fields in PrivateMess
age messages</li>
<li pn="section-16.4-2.6">The lengths of encrypted Welcome and Private
Message messages</li>
</ul> </ul>
<t>The only mechanism MLS provides for confidentially distributing a gro up's <t indent="0" pn="section-16.4-3">The only mechanism MLS provides for co nfidentially distributing a group's
ratchet tree to new members is to send it in a Welcome message as a ratchet tree to new members is to send it in a Welcome message as a
<tt>ratchet_tree</tt> extension. If an application distributes the tree in some other <tt>ratchet_tree</tt> extension. If an application distributes the tree in some other
way, its security will depend on that application mechanism.</t> way, its security will depend on that application mechanism.</t>
<t>A party observing these fields might be able to infer certain propert ies of the <t indent="0" pn="section-16.4-4">A party observing these fields might b e able to infer certain properties of the
group:</t> group:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>Group ID</li> 6.4-5">
<li>Current epoch and frequency of epoch changes</li> <li pn="section-16.4-5.1">Group ID</li>
<li>Frequency of messages within an epoch</li> <li pn="section-16.4-5.2">Current epoch and frequency of epoch changes
<li>Group extensions</li> </li>
<li>Group membership</li> <li pn="section-16.4-5.3">Frequency of messages within an epoch</li>
<li pn="section-16.4-5.4">Group extensions</li>
<li pn="section-16.4-5.5">Group membership</li>
</ul> </ul>
<t>The amount of metadata exposed to parties outside the group, and thus the <t indent="0" pn="section-16.4-6">The amount of metadata exposed to part ies outside the group, and thus the
ability of these parties to infer the group's properties, depends on several ability of these parties to infer the group's properties, depends on several
aspects of the DS design, such as:</t> aspects of the DS design, such as:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>How KeyPackages are distributed</li> 6.4-7">
<li>How the ratchet tree is distributed</li> <li pn="section-16.4-7.1">How KeyPackages are distributed</li>
<li>How prospective external joiners get a GroupInfo object for the gr <li pn="section-16.4-7.2">How the ratchet tree is distributed</li>
oup</li> <li pn="section-16.4-7.3">How prospective external joiners get a Group
<li>Whether Proposal and Commit messages are sent as PublicMessage or Info object for the group</li>
PrivateMessage</li> <li pn="section-16.4-7.4">Whether Proposal and Commit messages are sen
t as PublicMessage or PrivateMessage</li>
</ul> </ul>
<t>In the remainder of this section, we note the ways that the above pro perties of <t indent="0" pn="section-16.4-8">In the remainder of this section, we n ote the ways that the above properties of
the group are reflected in unprotected group messages, as a guide to the group are reflected in unprotected group messages, as a guide to
understanding how they might be exposed or protected in a given application.</t> understanding how they might be exposed or protected in a given application.</t>
<section anchor="groupid-epoch-and-message-frequency"> <section anchor="groupid-epoch-and-message-frequency" numbered="true" re
<name>GroupID, Epoch, and Message Frequency</name> moveInRFC="false" toc="include" pn="section-16.4.1">
<t>MLS provides no mechanism to protect the group ID and epoch of a me <name slugifiedName="name-groupid-epoch-and-message-f">GroupID, Epoch,
ssage from and Message Frequency</name>
<t indent="0" pn="section-16.4.1-1">MLS provides no mechanism to prote
ct the group ID and epoch of a message from
the DS, so the group ID and the frequency of messages and epoch changes are not the DS, so the group ID and the frequency of messages and epoch changes are not
protected against inspection by the DS. However, any modifications to these protected against inspection by the DS. However, any modifications to these
will cause decryption failure.</t> will cause decryption failure.</t>
</section> </section>
<section anchor="group-extensions"> <section anchor="group-extensions" numbered="true" removeInRFC="false" t
<name>Group Extensions</name> oc="include" pn="section-16.4.2">
<t>A group's extensions are first set by the group's creator and then <name slugifiedName="name-group-extensions">Group Extensions</name>
updated by <t indent="0" pn="section-16.4.2-1">A group's extensions are first set
GroupContextExtensions proposals. A GroupContextExtension proposal sent as by the group's creator and then updated by
GroupContextExtensions proposals. A GroupContextExtensions proposal sent as
a PublicMessage leaks the group's extensions.</t> a PublicMessage leaks the group's extensions.</t>
<t>A new member learns the group's extensions via a GroupInfo object. When the new <t indent="0" pn="section-16.4.2-2">A new member learns the group's ex tensions via a GroupInfo object. When the new
member joins via a Welcome message, the Welcome message's encryption protects member joins via a Welcome message, the Welcome message's encryption protects
the GroupInfo message. When the new member joins via an external join, they the GroupInfo message. When the new member joins via an external join, they
must be provided with a GroupInfo object. Protection of this GroupInfo object must be provided with a GroupInfo object. Protection of this GroupInfo object
is up to the application -- if it is transmitted over a channel that is not is up to the application -- if it is transmitted over a channel that is not
confidential to the group and the new joiner, then it will leak the group's confidential to the group and the new joiner, then it will leak the group's
extensions.</t> extensions.</t>
</section> </section>
<section anchor="group-membership"> <section anchor="group-membership" numbered="true" removeInRFC="false" t
<name>Group Membership</name> oc="include" pn="section-16.4.3">
<t>The group's membership is represented directly by its ratchet tree, <name slugifiedName="name-group-membership">Group Membership</name>
since each <t indent="0" pn="section-16.4.3-1">The group's membership is represen
ted directly by its ratchet tree, since each
member's LeafNode contains members' cryptographic keys, a credential that member's LeafNode contains members' cryptographic keys, a credential that
contains information about the member's identity, and possibly other contains information about the member's identity, and possibly other
identifiers. Applications that expose the group's ratchet tree outside the identifiers. Applications that expose the group's ratchet tree outside the
group also leak the group's membership.</t> group also leak the group's membership.</t>
<t>Changes to the group's membership are made by means of Add and Remo ve proposals. <t indent="0" pn="section-16.4.3-2">Changes to the group's membership are made by means of Add and Remove proposals.
If these proposals are sent as PublicMessage, then information will be leaked If these proposals are sent as PublicMessage, then information will be leaked
about the corresponding changes to the group's membership. A party that sees about the corresponding changes to the group's membership. A party that sees
all of these changes can reconstruct the group membership.</t> all of these changes can reconstruct the group membership.</t>
<t>Welcome messages contain a hash of each KeyPackage for which the We lcome message <t indent="0" pn="section-16.4.3-3">Welcome messages contain a hash of each KeyPackage for which the Welcome message
is encrypted. If a party has access to a pool of KeyPackages and observes a is encrypted. If a party has access to a pool of KeyPackages and observes a
Welcome message, then they can identify the KeyPackage representing the new Welcome message, then they can identify the KeyPackage representing the new
member. If the party can also associate the Welcome with a group, then the member. If the party can also associate the Welcome with a group, then the
party can infer that the identified new member was added to that group.</t> party can infer that the identified new member was added to that group.</t>
<t>Note that these information leaks reveal the group's membership onl <t indent="0" pn="section-16.4.3-4">Note that these information leaks
y to the degree reveal the group's membership only to the degree
that that membership is revealed by the contents of a member's LeafNode in the that membership is revealed by the contents of a member's LeafNode in the
ratchet tree. In some cases, this may be quite direct, e.g., due to credentials ratchet tree. In some cases, this may be quite direct, e.g., due to credentials
attesting to identifiers such as email addresses. An application could attesting to identifiers such as email addresses. An application could
construct a member's leaf node to be less identifying, e.g., by using a construct a member's leaf node to be less identifying, e.g., by using a
pseudonymous credential and frequently rotating encryption and signature keys.</ t> pseudonymous credential and frequently rotating encryption and signature keys.</ t>
</section> </section>
</section> </section>
<section anchor="authentication"> <section anchor="authentication" numbered="true" removeInRFC="false" toc="
<name>Authentication</name> include" pn="section-16.5">
<t>The first form of authentication we provide is that group members can <name slugifiedName="name-authentication">Authentication</name>
verify a <t indent="0" pn="section-16.5-1">The first form of authentication we pr
ovide is that group members can verify a
message originated from one of the members of the group. For encrypted messages, message originated from one of the members of the group. For encrypted messages,
this is guaranteed because messages are encrypted with an AEAD under a key this is guaranteed because messages are encrypted with an AEAD under a key
derived from the group secrets. For plaintext messages, this is guaranteed by derived from the group secrets. For plaintext messages, this is guaranteed by
the use of a <tt>membership_tag</tt> which constitutes a MAC over the message, u nder a the use of a <tt>membership_tag</tt>, which constitutes a MAC over the message, under a
key derived from the group secrets.</t> key derived from the group secrets.</t>
<t>The second form of authentication is that group members can verify a message <t indent="0" pn="section-16.5-2">The second form of authentication is t hat group members can verify a message
originated from a particular member of the group. This is guaranteed by a originated from a particular member of the group. This is guaranteed by a
digital signature on each message from the sender's signature key.</t> digital signature on each message from the sender's signature key.</t>
<t>The signature keys held by group members are critical to the security of MLS <t indent="0" pn="section-16.5-3">The signature keys held by group membe rs are critical to the security of MLS
against active attacks. If a member's signature key is compromised, then an against active attacks. If a member's signature key is compromised, then an
attacker can create LeafNodes and KeyPackages impersonating the member; dependin g on the attacker can create LeafNodes and KeyPackages impersonating the member; dependin g on the
application, this can then allow the attacker to join the group with 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 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 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 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 the group -- even using a "resync"-style external Commit to replace the
compromised member in the group.</t> compromised member in the group.</t>
<t>Applications can mitigate the risks of signature key compromise using pre-shared <t indent="0" pn="section-16.5-4">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 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 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. 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 The cost of this mitigation is that the application needs some external
arrangement that ensures that the legitimate members of the group have the arrangement that ensures that the legitimate members of the group have the
required PSKs.</t> required PSKs.</t>
</section> </section>
<section anchor="forward-secrecy-and-post-compromise-security"> <section anchor="forward-secrecy-and-post-compromise-security" numbered="t
<name>Forward Secrecy and Post-Compromise Security</name> rue" removeInRFC="false" toc="include" pn="section-16.6">
<t>Forward secrecy and post-compromise security are important security n <name slugifiedName="name-forward-secrecy-and-post-co">Forward Secrecy a
otions for nd Post-Compromise Security</name>
<t indent="0" pn="section-16.6-1">Forward secrecy and post-compromise se
curity are important security notions for
long-lived MLS groups. Forward secrecy means that messages sent at a certain long-lived MLS groups. Forward secrecy means that messages sent at a certain
point in time are secure in the face of later compromise of a group member. point in time are secure in the face of later compromise of a group member.
Post-compromise security means that messages are secure even if a group member Post-compromise security means that messages are secure even if a group member
was compromised at some point in the past.</t> was compromised at some point in the past.</t>
<figure> <figure align="left" suppress-title="false" pn="figure-29">
<name>Forward secrecy and post-compromise security</name> <name slugifiedName="name-forward-secrecy-and-post-com">Forward Secrec
<artset> y and Post-Compromise Security</name>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= <artset pn="section-16.6-2.1">
"1.1" height="176" width="448" viewBox="0 0 448 176" class="diagram" text-anchor <artwork type="svg" align="left" pn="section-16.6-2.1.1">
="middle" font-family="monospace" font-size="13px"> <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-famil
y="monospace" font-size="13px" height="176" text-anchor="middle" version="1.1" v
iewBox="0 0 448 176" width="448">
<path d="M 152,80 L 152,160" fill="none" stroke="black"/> <path d="M 152,80 L 152,160" fill="none" stroke="black"/>
<path d="M 192,48 L 192,88" fill="none" stroke="black"/> <path d="M 192,48 L 192,88" fill="none" stroke="black"/>
<path d="M 232,80 L 232,160" fill="none" stroke="black"/> <path d="M 232,80 L 232,160" fill="none" stroke="black"/>
<path d="M 8,96 L 144,96" fill="none" stroke="black"/> <path d="M 8,96 L 144,96" fill="none" stroke="black"/>
<path d="M 160,96 L 224,96" fill="none" stroke="black"/> <path d="M 160,96 L 224,96" fill="none" stroke="black"/>
<path d="M 240,96 L 440,96" fill="none" stroke="black"/> <path d="M 240,96 L 440,96" fill="none" stroke="black"/>
<path d="M 8,128 L 144,128" fill="none" stroke="black"/> <path d="M 8,128 L 144,128" fill="none" stroke="black"/>
<path d="M 240,128 L 368,128" fill="none" stroke="black"/> <path d="M 240,128 L 368,128" fill="none" stroke="black"/>
<polygon class="arrowhead" points="448,96 436,90.4 436,101.6" fi <polygon class="arrowhead" fill="black" points="448,96 436,90.4
ll="black" transform="rotate(0,440,96)"/> 436,101.6" transform="rotate(0,440,96)"/>
<polygon class="arrowhead" points="376,128 364,122.4 364,133.6" <polygon class="arrowhead" fill="black" points="376,128 364,122.
fill="black" transform="rotate(0,368,128)"/> 4 364,133.6" transform="rotate(0,368,128)"/>
<polygon class="arrowhead" points="200,88 188,82.4 188,93.6" fil <polygon class="arrowhead" fill="black" points="200,88 188,82.4
l="black" transform="rotate(90,192,88)"/> 188,93.6" transform="rotate(90,192,88)"/>
<polygon class="arrowhead" points="16,128 4,122.4 4,133.6" fill= <polygon class="arrowhead" fill="black" points="16,128 4,122.4 4
"black" transform="rotate(180,8,128)"/> ,133.6" transform="rotate(180,8,128)"/>
<g class="text"> <g class="text">
<text x="196" y="36">Compromise</text> <text x="196" y="36">Compromise</text>
<text x="420" y="116">Time</text> <text x="420" y="116">Time</text>
<text x="48" y="148">Forward</text> <text x="48" y="148">Forward</text>
<text x="112" y="148">Secrecy</text> <text x="112" y="148">Secrecy</text>
<text x="304" y="148">Post-Compromise</text> <text x="304" y="148">Post-Compromise</text>
<text x="292" y="164">Security</text> <text x="292" y="164">Security</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-16.6-2.1.2">
Compromise Compromise
| |
| |
| V | | V |
------------------|---------|-------------------------&gt;
| | Time | | Time
<-----------------| |----------------&gt; <-----------------| |----------------&gt;
Forward Secrecy | | Post-Compromise Forward Secrecy | | Post-Compromise
| | Security | | Security
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>Post-compromise security is provided between epochs by members <t indent="0" pn="section-16.6-3">Post-compromise security is provided b etween epochs by members
regularly updating their leaf key in the ratchet tree. Updating their regularly updating their leaf key in the ratchet tree. Updating their
leaf key prevents group secrets from continuing to be encrypted to leaf key prevents group secrets from continuing to be encrypted to
public keys whose private keys had previously been compromised. Note public keys whose private keys had previously been compromised. Note
that sending an Update proposal does not achieve PCS until another that sending an Update proposal does not achieve PCS until another
member includes it in a Commit. Members can achieve immediate PCS by member includes it in a Commit. Members can achieve immediate PCS by
sending their own Commit and populating the <tt>path</tt> field, as described sending their own Commit and populating the <tt>path</tt> field, as described
in <xref target="commit"/>. To be clear, in all these cases, the PCS guarantees in <xref target="commit" format="default" sectionFormat="of" derivedContent="Sec tion 12.4"/>. To be clear, in all these cases, the PCS guarantees
come into effect when the members of the group process the relevant come into effect when the members of the group process the relevant
Commit, not when the sender creates it.</t> Commit, not when the sender creates it.</t>
<t>Forward secrecy between epochs is provided by deleting private keys f rom past <t indent="0" pn="section-16.6-4">Forward secrecy between epochs is prov ided by deleting private keys from past
versions of the ratchet tree, as this prevents old group secrets from being versions of the ratchet tree, as this prevents old group secrets from being
re-derived. Forward secrecy <em>within</em> an epoch is provided by deleting mes sage re-derived. Forward secrecy <em>within</em> an epoch is provided by deleting mes sage
encryption keys once they've been used to encrypt or decrypt a message. encryption keys once they've been used to encrypt or decrypt a message.
Note that group secrets and message encryption keys are shared by the Note that group secrets and message encryption keys are shared by the
group, and thus there is a risk to forward secrecy as long as any group. There is thus a risk to forward secrecy as long as any
member has not deleted these keys. This is a particular risk if a member member has not deleted these keys. This is a particular risk if a member
is offline for a long period of time. Applications SHOULD have mechanisms is offline for a long period of time. Applications <bcp14>SHOULD</bcp14> have me
for evicting group members which are offline for too long (i.e., have chanisms
for evicting group members that are offline for too long (i.e., have
not changed their key within some period).</t> not changed their key within some period).</t>
<t>New groups are also at risk of using previously compromised keys (as <t indent="0" pn="section-16.6-5">New groups are also at risk of using p
with reviously compromised keys (as with
post-compromise security), if a member is added to a new group via an old post-compromise security) if a member is added to a new group via an old
KeyPackage whose corresponding private key has been compromised. This risk can KeyPackage whose corresponding private key has been compromised. This risk can
be mitigated by having clients regularly generate new KeyPackages and upload be mitigated by having clients regularly generate new KeyPackages and upload
them to the Delivery Service. This way, the key material used to add a member them to the Delivery Service. This way, the key material used to add a member
to a new group is more likely to be fresh and less likely to be compromised.</t> to a new group is more likely to be fresh and less likely to be compromised.</t>
</section> </section>
<section anchor="uniqueness-of-ratchet-tree-key-pairs"> <section anchor="uniqueness-of-ratchet-tree-key-pairs" numbered="true" rem
<name>Uniqueness of Ratchet Tree Key Pairs</name> oveInRFC="false" toc="include" pn="section-16.7">
<t>The encryption and signature keys stored in the <tt>encryption_key</t <name slugifiedName="name-uniqueness-of-ratchet-tree-">Uniqueness of Rat
t> and chet Tree Key Pairs</name>
<tt>signature_key</tt> fields of ratchet tree nodes MUST be distinct from one an <t indent="0" pn="section-16.7-1">The encryption and signature keys stor
other. ed in the <tt>encryption_key</tt> and
<tt>signature_key</tt> fields of ratchet tree nodes <bcp14>MUST</bcp14> be disti
nct from one another.
If two members' leaf nodes have the same signature key, for example, then the If two members' leaf nodes have the same signature key, for example, then the
data origin authentication properties afforded by signatures within the group data origin authentication properties afforded by signatures within the group
are degraded.</t> are degraded.</t>
<t>Uniqueness of keys in leaf nodes is assured by explicit checks on lea <t indent="0" pn="section-16.7-2">Uniqueness of keys in leaf nodes is as
f nodes sured by explicitly checking each leaf node
being added to the tree by Add or Update proposals, or in the <tt>path</tt> fiel as it is added to the tree, whether in an Add proposal, in an Update proposal, o
d of a r in the <tt>path</tt> field of a
Commit. Details can be found in <xref target="leaf-node-validation"/>, Commit. Details can be found in Sections <xref format="counter" target="leaf-no
<xref target="proposal-list-validation"/>, and <xref target="processing-a-commit de-validation" sectionFormat="of" derivedContent="7.3"/>,
"/>. Uniqueness of <xref format="counter" target="proposal-list-validation" sectionFormat="of" deri
vedContent="12.2"/>, and <xref format="counter" target="processing-a-commit" sec
tionFormat="of" derivedContent="12.4.2"/>. Uniqueness of
encryption keys in parent nodes is assured by checking that the keys in an encryption keys in parent nodes is assured by checking that the keys in an
UpdatePath are not found elsewhere in the tree (see <xref target="processing-a-c ommit"/>.</t> UpdatePath are not found elsewhere in the tree (see <xref target="processing-a-c ommit" format="default" sectionFormat="of" derivedContent="Section 12.4.2"/>).</ t>
</section> </section>
<section anchor="keypackage-reuse"> <section anchor="keypackage-reuse" numbered="true" removeInRFC="false" toc
<name>KeyPackage Reuse</name> ="include" pn="section-16.8">
<t>KeyPackages are intended to be used only once. That is, once a KeyPa <name slugifiedName="name-keypackage-reuse">KeyPackage Reuse</name>
ckage <t indent="0" pn="section-16.8-1">KeyPackages are intended to be used on
has been used to introduce the corresponding client to a group, it SHOULD be ly once. That is, once a KeyPackage
has been used to introduce the corresponding client to a group, it <bcp14>SHOULD
</bcp14> be
deleted from the KeyPackage publication system. Reuse of KeyPackages can lead deleted from the KeyPackage publication system. Reuse of KeyPackages can lead
to replay attacks.</t> to replay attacks.</t>
<t>An application MAY allow for reuse of a "last resort" KeyPackage in o rder to <t indent="0" pn="section-16.8-2">An application <bcp14>MAY</bcp14> allo w for reuse of a "last resort" KeyPackage in order to
prevent denial-of-service attacks. Since a KeyPackage is needed to add a prevent denial-of-service attacks. Since a KeyPackage is needed to add a
client to a new group, an attacker could prevent a client being added to new client to a new group, an attacker could prevent a client from being added to ne w
groups by exhausting all available KeyPackages. To prevent such a denial-of-serv ice groups by exhausting all available KeyPackages. To prevent such a denial-of-serv ice
attack, the KeyPackage publication system SHOULD rate-limit KeyPackage attack, the KeyPackage publication system <bcp14>SHOULD</bcp14> rate-limit KeyPa ckage
requests, especially if not authenticated.</t> requests, especially if not authenticated.</t>
</section> </section>
<section anchor="delivery-service-compromise"> <section anchor="delivery-service-compromise" numbered="true" removeInRFC=
<name>Delivery Service Compromise</name> "false" toc="include" pn="section-16.9">
<t>MLS is designed to protect the confidentiality and integrity of <name slugifiedName="name-delivery-service-compromise">Delivery Service
Compromise</name>
<t indent="0" pn="section-16.9-1">MLS is designed to protect the confide
ntiality and integrity of
the group data even in the face of a compromised DS. However, a compromised the group data even in the face of a compromised DS. However, a compromised
DS can still mount some attacks. While it cannot forge messages, DS can still mount some attacks. While it cannot forge messages,
it can selectively delay or remove them. This can in some cases be it can selectively delay or remove them. In some cases, this can be
observed by detecting gaps in the per-sender generation counter, observed by detecting gaps in the per-sender generation counter,
though it may not always be possible to distinguish an attack from message though it may not always be possible to distinguish an attack from message
loss. In addition, the DS can permanently block messages to and from loss. In addition, the DS can permanently block messages to and from
a group member. This will not always be detectable by other members. a group member. This will not always be detectable by other members.
If an application uses the DS to resolve conflicts between If an application uses the DS to resolve conflicts between
simultaneous Commits (see <xref target="sequencing"/>), it is also possible for the simultaneous Commits (see <xref target="sequencing" format="default" sectionForm at="of" derivedContent="Section 14"/>), it is also possible for the
DS to influence which Commit is applied, even to the point of DS to influence which Commit is applied, even to the point of
preventing a member from ever having its Commits applied.</t> preventing a member from ever having its Commits applied.</t>
<t>When put together, these abilities potentially allow a DS to collude <t indent="0" pn="section-16.9-2">When put together, these abilities pot entially allow a DS to collude
with an attacker who has compromised a member's state to defeat PCS by with an attacker who has compromised a member's state to defeat PCS by
suppressing the valid Update and Commit messages from the member that suppressing the valid Update and Commit messages from the member that
would lock out the attacker and update the member's leaf to a new, would lock out the attacker and update the member's leaf to a new,
uncompromised state. Aside from the SenderData.generation value, MLS uncompromised state. Aside from the SenderData.generation value, MLS
leaves loss detection up to the application.</t> leaves loss detection up to the application.</t>
</section> </section>
<section anchor="authentication-service-compromise"> <section anchor="authentication-service-compromise" numbered="true" remove
<name>Authentication Service Compromise</name> InRFC="false" toc="include" pn="section-16.10">
<t>Authentication Service compromise is much more serious than compromis <name slugifiedName="name-authentication-service-comp">Authentication Se
e rvice Compromise</name>
<t indent="0" pn="section-16.10-1">Authentication Service compromise is
much more serious than compromise
of the Delivery Service. A compromised AS can assert a binding for a of the Delivery Service. A compromised AS can assert a binding for a
signature key and identity pair of its choice, thus allowing signature key and identity pair of its choice, thus allowing
impersonation of a given user. This ability is sufficient to allow the impersonation of a given user. This ability is sufficient to allow the
AS to join new groups as if it were that user. Depending on the AS to join new groups as if it were that user. Depending on the
application architecture, it may also be sufficient to allow the application architecture, it may also be sufficient to allow the
compromised AS to join the group as an existing user, for instance as compromised AS to join the group as an existing user, for instance, as
if it were a new device associated with the same user. If if it were a new device associated with the same user. If
the application uses a transparency mechanism such as CONIKS the application uses a transparency mechanism such as CONIKS
<xref target="CONIKS"/> or Key Transparency <xref target="KT"/>, then it may be possible for end <xref target="CONIKS" format="default" sectionFormat="of" derivedContent="CONIKS "/> or Key Transparency <xref target="KT" format="default" sectionFormat="of" de rivedContent="KT"/>, then it may be possible for end
users to detect this kind of misbehavior by the AS. It is also possible to users to detect this kind of misbehavior by the AS. It is also possible to
construct schemes in which the various clients owned by a user vouch construct schemes in which the various clients owned by a user vouch
for each other, e.g., by signing each others' keys.</t> for each other, e.g., by signing each others' keys.</t>
</section> </section>
<section anchor="additional-policy-enforcement"> <section anchor="additional-policy-enforcement" numbered="true" removeInRF
<name>Additional Policy Enforcement</name> C="false" toc="include" pn="section-16.11">
<t>The DS and AS may also apply additional policies to MLS operations to <name slugifiedName="name-additional-policy-enforceme">Additional Policy
obtain Enforcement</name>
<t indent="0" pn="section-16.11-1">The DS and AS may also apply addition
al policies to MLS operations to obtain
additional security properties. For example, MLS enables any participant to add additional security properties. For example, MLS enables any participant to add
or remove members of a group; a DS could enforce a policy that only certain or remove members of a group; a DS could enforce a policy that only certain
members are allowed to perform these operations. MLS authenticates all members members are allowed to perform these operations. MLS authenticates all members
of a group; a DS could help ensure that only clients with certain types of of a group; a DS could help ensure that only clients with certain types of
credentials are admitted. MLS provides no inherent protection against denial of credentials are admitted. MLS provides no inherent protection against denial of
service; a DS could also enforce rate limits in order to mitigate service; a DS could also enforce rate limits in order to mitigate
these risks.</t> these risks.</t>
</section> </section>
<section anchor="group-fragmentation-by-malicious-insiders"> <section anchor="group-fragmentation-by-malicious-insiders" numbered="true
<name>Group Fragmentation by Malicious Insiders</name> " removeInRFC="false" toc="include" pn="section-16.12">
<t>It is possible for a malicious member of a group to "fragment" the gr <name slugifiedName="name-group-fragmentation-by-mali">Group Fragmentati
oup by on by Malicious Insiders</name>
<t indent="0" pn="section-16.12-1">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 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 of path secrets to different subtrees of the group's ratchet trees. These path
secrets should be derived in a sequence as described in secrets should be derived in a sequence as described in
<xref target="ratchet-tree-evolution"/>, but the UpdatePath syntax allows the se nder to <xref target="ratchet-tree-evolution" format="default" sectionFormat="of" derive dContent="Section 7.4"/>, but the UpdatePath syntax allows the sender to
encrypt arbitrary, unrelated secrets. The syntax also does not guarantee that encrypt arbitrary, unrelated secrets. The syntax also does not guarantee that
the encrypted path secret for a given node corresponds to the public the encrypted path secret for a given node corresponds to the public
key provided for that node.</t> key provided for that node.</t>
<t>Both of these types of corruption will cause processing of a Commit t o fail for <t indent="0" pn="section-16.12-2">Both of these types of corruption wil l 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 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 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, 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 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 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 causes the Commit to fail. Applications <bcp14>SHOULD</bcp14> provide mechanism s for failed
commits to be reported, so that group members who were not able to recognize the commits to be reported, so that group members who were not able to recognize the
error themselves can reinitialize the group if necessary.</t> error themselves can reinitialize the group if necessary.</t>
<t>Even with such an error reporting mechanism in place, however, it is <t indent="0" pn="section-16.12-3">Even with such an error reporting mec
still hanism in place, however, it is still
possible for members to get locked out of the group by a malformed commit. 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, 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 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 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 accepted by the group, and the resulting state will possibly be used as the basi s for
further Commits. When the affected members come back online, they will reject 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. These members the first Commit, and thus be unable to catch up with the group. These members
will either need to add themselves back with an external Commit, or reinitialize will need to either add themselves back with an external Commit or reinitialize
the group from scratch.</t> the group from scratch.</t>
<t>Applications can address this risk by requiring certain members of th e group to <t indent="0" pn="section-16.12-4">Applications can address this risk by requiring certain members of the group to
acknowledge successful processing of a Commit before the group regards the acknowledge successful processing of a Commit before the group regards the
Commit as accepted. The minimum set of acknowledgements necessary to verify Commit as accepted. The minimum set of acknowledgements necessary to verify
that a Commit is well-formed comprises an acknowledgement from one member per 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 node in the UpdatePath, that is, one member from each subtree rooted in the
copath node corresponding to the node in the UpdatePath. MLS does not copath node corresponding to the node in the UpdatePath. MLS does not
provide a built-in mechanism for such acknowledgements, but they can provide a built-in mechanism for such acknowledgements, but they can
be added at the application layer.</t> be added at the application layer.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations" numbered="true" removeInRFC="false" to
<name>IANA Considerations</name> c="include" pn="section-17">
<t>This document requests the creation of the following new IANA registrie <name slugifiedName="name-iana-considerations">IANA Considerations</name>
s:</t> <t indent="0" pn="section-17-1">IANA has created the following registries:
<ul spacing="normal"> </t>
<li>MLS Ciphersuites (<xref target="mls-ciphersuites"/>)</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-17-
<li>MLS Wire Formats (<xref target="mls-wire-formats"/>)</li> 2">
<li>MLS Extension Types (<xref target="mls-extension-types"/>)</li> <li pn="section-17-2.1">MLS Cipher Suites (<xref target="mls-cipher-suit
<li>MLS Proposal Types (<xref target="mls-proposal-types"/>)</li> es" format="default" sectionFormat="of" derivedContent="Section 17.1"/>)</li>
<li>MLS Credential Types (<xref target="mls-credential-types"/>)</li> <li pn="section-17-2.2">MLS Wire Formats (<xref target="mls-wire-formats
<li>MLS Signature Labels (<xref target="mls-signature-labels"/>)</li> " format="default" sectionFormat="of" derivedContent="Section 17.2"/>)</li>
<li>MLS Public Key Encryption Labels (<xref target="mls-public-key-encry <li pn="section-17-2.3">MLS Extension Types (<xref target="mls-extension
ption-labels"/>)</li> -types" format="default" sectionFormat="of" derivedContent="Section 17.3"/>)</li
<li>MLS Exporter Labels (<xref target="mls-exporter-labels"/>)</li> >
<li pn="section-17-2.4">MLS Proposal Types (<xref target="mls-proposal-t
ypes" format="default" sectionFormat="of" derivedContent="Section 17.4"/>)</li>
<li pn="section-17-2.5">MLS Credential Types (<xref target="mls-credenti
al-types" format="default" sectionFormat="of" derivedContent="Section 17.5"/>)</
li>
<li pn="section-17-2.6">MLS Signature Labels (<xref target="mls-signatur
e-labels" format="default" sectionFormat="of" derivedContent="Section 17.6"/>)</
li>
<li pn="section-17-2.7">MLS Public Key Encryption Labels (<xref target="
mls-public-key-encryption-labels" format="default" sectionFormat="of" derivedCon
tent="Section 17.7"/>)</li>
<li pn="section-17-2.8">MLS Exporter Labels (<xref target="mls-exporter-
labels" format="default" sectionFormat="of" derivedContent="Section 17.8"/>)</li
>
</ul> </ul>
<t>All of these registries should be under a heading of "Messaging Layer S <t indent="0" pn="section-17-3">All of these registries are under the "Mes
ecurity", saging Layer Security" group registry heading,
and assignments are made via the Specification Required policy <xref target="RFC and assignments are made via the Specification Required policy <xref target="RFC
8126"/>. See 8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. See
<xref target="de"/> for additional information about the MLS Designated Experts <xref target="de" format="default" sectionFormat="of" derivedContent="Section 17
(DEs).</t> .9"/> for additional information about the MLS Designated Experts (DEs).</t>
<t>RFC EDITOR: Please replace XXXX throughout with the RFC number assigned <section anchor="mls-cipher-suites" numbered="true" removeInRFC="false" to
to c="include" pn="section-17.1">
this document</t> <name slugifiedName="name-mls-cipher-suites">MLS Cipher Suites</name>
<section anchor="mls-ciphersuites"> <t indent="0" pn="section-17.1-1">A cipher suite is a combination of a p
<name>MLS Ciphersuites</name> rotocol version and the set of
<t>A ciphersuite is a combination of a protocol version and the set of
cryptographic algorithms that should be used.</t> cryptographic algorithms that should be used.</t>
<t>Ciphersuite names follow the naming convention:</t> <t indent="0" pn="section-17.1-2">Cipher suite names follow the naming c
<sourcecode type="pseudocode"><![CDATA[ onvention:</t>
<sourcecode type="pseudocode" markers="false" pn="section-17.1-3">
CipherSuite MLS_LVL_KEM_AEAD_HASH_SIG = VALUE; CipherSuite MLS_LVL_KEM_AEAD_HASH_SIG = VALUE;
]]></sourcecode> </sourcecode>
<t>Where VALUE is represented as a sixteen-bit integer:</t> <t indent="0" pn="section-17.1-4">Where VALUE is represented as a 16-bit
<sourcecode type="tls"><![CDATA[ integer:</t>
<sourcecode type="tls-presentation" markers="false" pn="section-17.1-5">
uint16 CipherSuite; uint16 CipherSuite;
]]></sourcecode> </sourcecode>
<table> <table align="center" pn="table-5">
<thead> <thead>
<tr> <tr>
<th align="left">Component</th> <th align="left" colspan="1" rowspan="1">Component</th>
<th align="left">Contents</th> <th align="left" colspan="1" rowspan="1">Contents</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">LVL</td> <td align="left" colspan="1" rowspan="1">LVL</td>
<td align="left">The security level (in bits)</td> <td align="left" colspan="1" rowspan="1">The security level (in bi
ts)</td>
</tr> </tr>
<tr> <tr>
<td align="left">KEM</td> <td align="left" colspan="1" rowspan="1">KEM</td>
<td align="left">The KEM algorithm used for HPKE in ratchet tree o <td align="left" colspan="1" rowspan="1">The KEM algorithm used fo
perations</td> r HPKE in ratchet tree operations</td>
</tr> </tr>
<tr> <tr>
<td align="left">AEAD</td> <td align="left" colspan="1" rowspan="1">AEAD</td>
<td align="left">The AEAD algorithm used for HPKE and message prot <td align="left" colspan="1" rowspan="1">The AEAD algorithm used f
ection</td> or HPKE and message protection</td>
</tr> </tr>
<tr> <tr>
<td align="left">HASH</td> <td align="left" colspan="1" rowspan="1">HASH</td>
<td align="left">The hash algorithm used for HPKE and the MLS tran <td align="left" colspan="1" rowspan="1">The hash algorithm used f
script hash</td> or HPKE and the MLS transcript hash</td>
</tr> </tr>
<tr> <tr>
<td align="left">SIG</td> <td align="left" colspan="1" rowspan="1">SIG</td>
<td align="left">The Signature algorithm used for message authenti <td align="left" colspan="1" rowspan="1">The signature algorithm u
cation</td> sed for message authentication</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The columns in the registry are as follows:</t> <t indent="0" pn="section-17.1-7">The columns in the registry are as fol
<ul spacing="normal"> lows:</t>
<li>Value: The numeric value of the ciphersuite</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>Name: The name of the ciphersuite</li> 7.1-8">
</ul> <li pn="section-17.1-8.1">Value: The numeric value of the cipher suite
<t>[[ RFC EDITOR: This section should be the same as the corresponding t </li>
ext in <li pn="section-17.1-8.2">Name: The name of the cipher suite</li>
draft-ietf-tls-rfc8447bis. Please align the two documents if they have diverged <li pn="section-17.1-8.3">
in the approval process. ]]</t> <t indent="0" pn="section-17.1-8.3.1">Recommended: Whether support f
<ul spacing="normal"> or this cipher suite is recommended by the IETF.
<li>
<t>Recommended: Whether support for this ciphersuite is recommended
by the IETF.
Valid values are "Y", "N", and "D", as described below. The default Valid values are "Y", "N", and "D", as described below. The default
value of the "Recommended" column is "N". Setting the Recommended item to "Y" value of the "Recommended" column is "N". Setting the Recommended item to "Y"
or "D", or changing an item whose current value is "Y" or "D", requires or "D", or changing an item whose current value is "Y" or "D", requires
Standards Action <xref target="RFC8126"/>. </t> Standards Action <xref target="RFC8126" format="default" sectionFormat="of" deri
<ul spacing="normal"> vedContent="RFC8126"/>. </t>
<li>Y: Indicates that the IETF has consensus that the item is RECO <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
MMENDED. This on-17.1-8.3.2">
<li pn="section-17.1-8.3.2.1">Y: Indicates that the IETF has conse
nsus that the item is <bcp14>RECOMMENDED</bcp14>. This
only means that the associated mechanism is fit for the purpose for which it only means that the associated mechanism is fit for the purpose for which it
was defined. Careful reading of the documentation for the mechanism is was defined. Careful reading of the documentation for the mechanism is
necessary to understand the applicability of that mechanism. The IETF could necessary to understand the applicability of that mechanism. The IETF could
recommend mechanisms that have limited applicability, but will provide recommend mechanisms that have limited applicability, but it will provide
applicability statements that describe any limitations of the mechanism or applicability statements that describe any limitations of the mechanism or
necessary constraints on its use.</li> necessary constraints on its use.</li>
<li>N: Indicates that the item has not been evaluated by the IETF and that the <li pn="section-17.1-8.3.2.2">N: Indicates that the item has not b een evaluated by the IETF and that the
IETF has made no statement about the suitability of the associated IETF has made no statement about the suitability of the associated
mechanism. This does not necessarily mean that the mechanism is flawed, only mechanism. This does not necessarily mean that the mechanism is flawed, only
that no consensus exists. The IETF might have consensus to leave an item that no consensus exists. The IETF might have consensus to leave an item
marked as "N" on the basis of it having limited applicability or usage marked as "N" on the basis of it having limited applicability or usage
constraints.</li> constraints.</li>
<li>D: Indicates that the item is discouraged and SHOULD NOT or MU ST NOT be <li pn="section-17.1-8.3.2.3">D: Indicates that the item is discou raged and <bcp14>SHOULD NOT</bcp14> or <bcp14>MUST NOT</bcp14> be
used. This marking could be used to identify mechanisms that might result in used. This marking could be used to identify mechanisms that might result in
problems if they are used, such as a weak cryptographic algorithm or a problems if they are used, such as a weak cryptographic algorithm or a
mechanism that might cause interoperability problems in deployment.</li> mechanism that might cause interoperability problems in deployment.</li>
</ul> </ul>
</li> </li>
<li>Reference: The document where this ciphersuite is defined</li> <li pn="section-17.1-8.4">Reference: The document where this cipher su ite is defined</li>
</ul> </ul>
<t>Initial contents:</t> <t indent="0" pn="section-17.1-9">Initial contents:</t>
<table> <table align="center" pn="table-6">
<name slugifiedName="name-mls-extension-types-registr">MLS Extension T
ypes Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left" colspan="1" rowspan="1">Value</th>
<th align="left">Name</th> <th align="left" colspan="1" rowspan="1">Name</th>
<th align="left">R</th> <th align="left" colspan="1" rowspan="1">R</th>
<th align="left">Ref</th> <th align="left" colspan="1" rowspan="1">Ref</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0x0000</td> <td align="left" colspan="1" rowspan="1">0x0000</td>
<td align="left">RESERVED</td> <td align="left" colspan="1" rowspan="1">RESERVED</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0001</td> <td align="left" colspan="1" rowspan="1">0x0001</td>
<td align="left">MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519</td> <td align="left" colspan="1" rowspan="1">MLS_128_DHKEMX25519_AES12
<td align="left">Y</td> 8GCM_SHA256_Ed25519</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0002</td> <td align="left" colspan="1" rowspan="1">0x0002</td>
<td align="left">MLS_128_DHKEMP256_AES128GCM_SHA256_P256</td> <td align="left" colspan="1" rowspan="1">MLS_128_DHKEMP256_AES128G
<td align="left">Y</td> CM_SHA256_P256</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0003</td> <td align="left" colspan="1" rowspan="1">0x0003</td>
<td align="left">MLS_128_DHKEMX25519_CHACHA20POLY1305_SHA256_Ed255 <td align="left" colspan="1" rowspan="1">MLS_128_DHKEMX25519_CHACH
19</td> A20POLY1305_SHA256_Ed25519</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0004</td> <td align="left" colspan="1" rowspan="1">0x0004</td>
<td align="left">MLS_256_DHKEMX448_AES256GCM_SHA512_Ed448</td> <td align="left" colspan="1" rowspan="1">MLS_256_DHKEMX448_AES256G
<td align="left">Y</td> CM_SHA512_Ed448</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0005</td> <td align="left" colspan="1" rowspan="1">0x0005</td>
<td align="left">MLS_256_DHKEMP521_AES256GCM_SHA512_P521</td> <td align="left" colspan="1" rowspan="1">MLS_256_DHKEMP521_AES256G
<td align="left">Y</td> CM_SHA512_P521</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0006</td> <td align="left" colspan="1" rowspan="1">0x0006</td>
<td align="left">MLS_256_DHKEMX448_CHACHA20POLY1305_SHA512_Ed448</ <td align="left" colspan="1" rowspan="1">MLS_256_DHKEMX448_CHACHA2
td> 0POLY1305_SHA512_Ed448</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0007</td> <td align="left" colspan="1" rowspan="1">0x0007</td>
<td align="left">MLS_256_DHKEMP384_AES256GCM_SHA384_P384.</td> <td align="left" colspan="1" rowspan="1">MLS_256_DHKEMP384_AES256G
<td align="left">Y</td> CM_SHA384_P384</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0A0A</td> <td align="left" colspan="1" rowspan="1">0x0A0A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x1A1A</td> <td align="left" colspan="1" rowspan="1">0x1A1A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x2A2A</td> <td align="left" colspan="1" rowspan="1">0x2A2A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x3A3A</td> <td align="left" colspan="1" rowspan="1">0x3A3A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x4A4A</td> <td align="left" colspan="1" rowspan="1">0x4A4A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x5A5A</td> <td align="left" colspan="1" rowspan="1">0x5A5A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x6A6A</td> <td align="left" colspan="1" rowspan="1">0x6A6A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x7A7A</td> <td align="left" colspan="1" rowspan="1">0x7A7A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8A8A</td> <td align="left" colspan="1" rowspan="1">0x8A8A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x9A9A</td> <td align="left" colspan="1" rowspan="1">0x9A9A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xAAAA</td> <td align="left" colspan="1" rowspan="1">0xAAAA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xBABA</td> <td align="left" colspan="1" rowspan="1">0xBABA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xCACA</td> <td align="left" colspan="1" rowspan="1">0xCACA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xDADA</td> <td align="left" colspan="1" rowspan="1">0xDADA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xEAEA</td> <td align="left" colspan="1" rowspan="1">0xEAEA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xF000 - 0xFFFF</td> <td align="left" colspan="1" rowspan="1">0xF000 - 0xFFFF</td>
<td align="left">Reserved for Private Use</td> <td align="left" colspan="1" rowspan="1">Reserved for Private Use<
<td align="left">-</td> /td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>All of these ciphersuites use HMAC <xref target="RFC2104"/> as their <t indent="0" pn="section-17.1-11">All of the non-GREASE cipher suites u
MAC function, with se HMAC <xref target="RFC2104" format="default" sectionFormat="of" derivedConten
different hashes per ciphersuite. The mapping of ciphersuites to HPKE t="RFC2104"/> as their MAC function, with
primitives, HMAC hash functions, and TLS signature schemes is as follows different hashes per cipher suite. The mapping of cipher suites to HPKE
<xref target="RFC9180"/> <xref target="RFC8446"/>:</t> primitives <xref target="RFC9180" format="default" sectionFormat="of" derivedCon
<table> tent="RFC9180"/>, HMAC hash functions, and TLS signature schemes
<xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC84
46"/> is as follows:</t>
<table align="center" pn="table-7">
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left" colspan="1" rowspan="1">Value</th>
<th align="left">KEM</th> <th align="left" colspan="1" rowspan="1">KEM</th>
<th align="left">KDF</th> <th align="left" colspan="1" rowspan="1">KDF</th>
<th align="left">AEAD</th> <th align="left" colspan="1" rowspan="1">AEAD</th>
<th align="left">Hash</th> <th align="left" colspan="1" rowspan="1">Hash</th>
<th align="left">Signature</th> <th align="left" colspan="1" rowspan="1">Signature</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0x0001</td> <td align="left" colspan="1" rowspan="1">0x0001</td>
<td align="left">0x0020</td> <td align="left" colspan="1" rowspan="1">0x0020</td>
<td align="left">0x0001</td> <td align="left" colspan="1" rowspan="1">0x0001</td>
<td align="left">0x0001</td> <td align="left" colspan="1" rowspan="1">0x0001</td>
<td align="left">SHA256</td> <td align="left" colspan="1" rowspan="1">SHA256</td>
<td align="left">ed25519</td> <td align="left" colspan="1" rowspan="1">ed25519</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0002</td> <td align="left" colspan="1" rowspan="1">0x0002</td>
<td align="left">0x0010</td> <td align="left" colspan="1" rowspan="1">0x0010</td>
<td align="left">0x0001</td> <td align="left" colspan="1" rowspan="1">0x0001</td>
<td align="left">0x0001</td> <td align="left" colspan="1" rowspan="1">0x0001</td>
<td align="left">SHA256</td> <td align="left" colspan="1" rowspan="1">SHA256</td>
<td align="left">ecdsa_secp256r1_sha256</td> <td align="left" colspan="1" rowspan="1">ecdsa_secp256r1_sha256</t
d>
</tr> </tr>
<tr> <tr>
<td align="left">0x0003</td> <td align="left" colspan="1" rowspan="1">0x0003</td>
<td align="left">0x0020</td> <td align="left" colspan="1" rowspan="1">0x0020</td>
<td align="left">0x0001</td> <td align="left" colspan="1" rowspan="1">0x0001</td>
<td align="left">0x0003</td> <td align="left" colspan="1" rowspan="1">0x0003</td>
<td align="left">SHA256</td> <td align="left" colspan="1" rowspan="1">SHA256</td>
<td align="left">ed25519</td> <td align="left" colspan="1" rowspan="1">ed25519</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0004</td> <td align="left" colspan="1" rowspan="1">0x0004</td>
<td align="left">0x0021</td> <td align="left" colspan="1" rowspan="1">0x0021</td>
<td align="left">0x0003</td> <td align="left" colspan="1" rowspan="1">0x0003</td>
<td align="left">0x0002</td> <td align="left" colspan="1" rowspan="1">0x0002</td>
<td align="left">SHA512</td> <td align="left" colspan="1" rowspan="1">SHA512</td>
<td align="left">ed448</td> <td align="left" colspan="1" rowspan="1">ed448</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0005</td> <td align="left" colspan="1" rowspan="1">0x0005</td>
<td align="left">0x0012</td> <td align="left" colspan="1" rowspan="1">0x0012</td>
<td align="left">0x0003</td> <td align="left" colspan="1" rowspan="1">0x0003</td>
<td align="left">0x0002</td> <td align="left" colspan="1" rowspan="1">0x0002</td>
<td align="left">SHA512</td> <td align="left" colspan="1" rowspan="1">SHA512</td>
<td align="left">ecdsa_secp521r1_sha512</td> <td align="left" colspan="1" rowspan="1">ecdsa_secp521r1_sha512</t
d>
</tr> </tr>
<tr> <tr>
<td align="left">0x0006</td> <td align="left" colspan="1" rowspan="1">0x0006</td>
<td align="left">0x0021</td> <td align="left" colspan="1" rowspan="1">0x0021</td>
<td align="left">0x0003</td> <td align="left" colspan="1" rowspan="1">0x0003</td>
<td align="left">0x0003</td> <td align="left" colspan="1" rowspan="1">0x0003</td>
<td align="left">SHA512</td> <td align="left" colspan="1" rowspan="1">SHA512</td>
<td align="left">ed448</td> <td align="left" colspan="1" rowspan="1">ed448</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0007</td> <td align="left" colspan="1" rowspan="1">0x0007</td>
<td align="left">0x0011</td> <td align="left" colspan="1" rowspan="1">0x0011</td>
<td align="left">0x0002</td> <td align="left" colspan="1" rowspan="1">0x0002</td>
<td align="left">0x0002</td> <td align="left" colspan="1" rowspan="1">0x0002</td>
<td align="left">SHA384</td> <td align="left" colspan="1" rowspan="1">SHA384</td>
<td align="left">ecdsa_secp384r1_sha384</td> <td align="left" colspan="1" rowspan="1">ecdsa_secp384r1_sha384</t
d>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The hash used for the MLS transcript hash is the one referenced in th <t indent="0" pn="section-17.1-13">The hash used for the MLS transcript
e hash is the one referenced in the
ciphersuite name. In the ciphersuites defined above, "SHA256", "SHA384", and "S cipher suite name. In the cipher suites defined above, "SHA256", "SHA384", and
HA512" "SHA512" refer, respectively, to the SHA-256, SHA-384, and SHA-512 functions
refer to the SHA-256, SHA-384, and SHA-512 functions defined in <xref target="SH defined in <xref target="SHS" format="default" sectionFormat="of" derivedContent
S"/>.</t> ="SHS"/>.</t>
<t>In addition to the general requirements of <xref target="additional-c <t indent="0" pn="section-17.1-14">In addition to the general requiremen
iphersuites"/>, future ts of <xref target="additional-cipher-suites" format="default" sectionFormat="of
ciphersuites MUST meet the requirements of <xref target="confidentiality-of-send " derivedContent="Section 13.1"/>, future
er-data"/>.</t> cipher suites <bcp14>MUST</bcp14> meet the requirements of <xref target="confide
<t>It is advisable to keep the number of ciphersuites low to increase th ntiality-of-sender-data" format="default" sectionFormat="of" derivedContent="Sec
e chances tion 16.3"/>.</t>
clients can interoperate in a federated environment, therefore the ciphersuites <t indent="0" pn="section-17.1-15">It is advisable to keep the number of
only include modern, yet well-established algorithms. Depending on their cipher suites low to increase the likelihood
that clients can interoperate in a federated environment. The cipher suites ther
efore
include only modern, yet well-established algorithms. Depending on their
requirements, clients can choose between two security levels (roughly 128-bit requirements, clients can choose between two security levels (roughly 128-bit
and 256-bit). Within the security levels clients can choose between faster 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 X25519/X448 curves and curves compliant with FIPS 140-2 for Diffie-Hellman key
negotiations. Clients may also choose ChaCha20Poly1305 or AES-GCM, e.g., for negotiations. Clients may also choose ChaCha20Poly1305 or AES-GCM, e.g., for
performance reasons. Since ChaCha20Poly1305 is not listed by FIPS 140-2 it is 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 not paired with curves compliant with FIPS 140-2. The security level of symmetri
c
encryption algorithms and hash functions is paired with the security level of encryption algorithms and hash functions is paired with the security level of
the curves.</t> the curves.</t>
<t>The mandatory-to-implement ciphersuite for MLS 1.0 is <t indent="0" pn="section-17.1-16">The mandatory-to-implement cipher sui
<tt>MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519</tt> which uses te for MLS 1.0 is
<tt>MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519</tt>, which uses
Curve25519 for key exchange, AES-128-GCM for HPKE, HKDF over SHA2-256, and Curve25519 for key exchange, AES-128-GCM for HPKE, HKDF over SHA2-256, and
Ed25519 for signatures. MLS clients MUST implement this ciphersuite.</t> Ed25519 for signatures. MLS clients <bcp14>MUST</bcp14> implement this cipher s
<t>New ciphersuite values are assigned by IANA as described in uite.</t>
<xref target="iana-considerations"/>.</t>
</section> </section>
<section anchor="mls-wire-formats"> <section anchor="mls-wire-formats" numbered="true" removeInRFC="false" toc
<name>MLS Wire Formats</name> ="include" pn="section-17.2">
<t>This registry lists identifiers for the types of messages that can be <name slugifiedName="name-mls-wire-formats">MLS Wire Formats</name>
sent in <t indent="0" pn="section-17.2-1">The "MLS Wire Formats" registry lists
identifiers for the types of messages that can be sent in
MLS. The wire format field is two bytes wide, so the valid wire format values MLS. The wire format field is two bytes wide, so the valid wire format values
are in the range 0x0000 to 0xFFFF.</t> are in the range 0x0000 to 0xFFFF.</t>
<t>Template:</t> <t indent="0" pn="section-17.2-2">Template:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>Value: The numeric value of the wire format</li> 7.2-3">
<li>Name: The name of the wire format</li> <li pn="section-17.2-3.1">Value: The numeric value of the wire format<
<li>Recommended: Same as in <xref target="mls-ciphersuites"/></li> /li>
<li>Reference: The document where this wire format is defined</li> <li pn="section-17.2-3.2">Name: The name of the wire format</li>
<li pn="section-17.2-3.3">Recommended: Same as in <xref target="mls-ci
pher-suites" format="default" sectionFormat="of" derivedContent="Section 17.1"/>
</li>
<li pn="section-17.2-3.4">Reference: The document where this wire form
at is defined</li>
</ul> </ul>
<t>Initial contents:</t> <t indent="0" pn="section-17.2-4">Initial contents:</t>
<table> <table align="center" pn="table-8">
<name slugifiedName="name-mls-wire-formats-registry">MLS Wire Formats
Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left" colspan="1" rowspan="1">Value</th>
<th align="left">Name</th> <th align="left" colspan="1" rowspan="1">Name</th>
<th align="left">R</th> <th align="left" colspan="1" rowspan="1">R</th>
<th align="left">Ref</th> <th align="left" colspan="1" rowspan="1">Ref</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0x0000</td> <td align="left" colspan="1" rowspan="1">0x0000</td>
<td align="left">RESERVED</td> <td align="left" colspan="1" rowspan="1">RESERVED</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0001</td> <td align="left" colspan="1" rowspan="1">0x0001</td>
<td align="left">mls_public_message</td> <td align="left" colspan="1" rowspan="1">mls_public_message</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0002</td> <td align="left" colspan="1" rowspan="1">0x0002</td>
<td align="left">mls_private_message</td> <td align="left" colspan="1" rowspan="1">mls_private_message</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0003</td> <td align="left" colspan="1" rowspan="1">0x0003</td>
<td align="left">mls_welcome</td> <td align="left" colspan="1" rowspan="1">mls_welcome</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0004</td> <td align="left" colspan="1" rowspan="1">0x0004</td>
<td align="left">mls_group_info</td> <td align="left" colspan="1" rowspan="1">mls_group_info</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0005</td> <td align="left" colspan="1" rowspan="1">0x0005</td>
<td align="left">mls_key_package</td> <td align="left" colspan="1" rowspan="1">mls_key_package</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xF000 - 0xFFFF</td> <td align="left" colspan="1" rowspan="1">0xF000 - 0xFFFF</td>
<td align="left">Reserved for Private Use</td> <td align="left" colspan="1" rowspan="1">Reserved for Private Use<
<td align="left">-</td> /td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="mls-extension-types"> <section anchor="mls-extension-types" numbered="true" removeInRFC="false"
<name>MLS Extension Types</name> toc="include" pn="section-17.3">
<t>This registry lists identifiers for extensions to the MLS protocol. <name slugifiedName="name-mls-extension-types">MLS Extension Types</name
The >
<t indent="0" pn="section-17.3-1">The "MLS Extension Types" registry lis
ts identifiers for extensions to the MLS protocol. The
extension type field is two bytes wide, so valid extension type values are in extension type field is two bytes wide, so valid extension type values are in
the range 0x0000 to 0xFFFF.</t> the range 0x0000 to 0xFFFF.</t>
<t>Template:</t> <t indent="0" pn="section-17.3-2">Template:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>Value: The numeric value of the extension type</li> 7.3-3">
<li>Name: The name of the extension type</li> <li pn="section-17.3-3.1">Value: The numeric value of the extension ty
<li> pe</li>
<t>Message(s): The messages in which the extension may appear, drawn <li pn="section-17.3-3.2">Name: The name of the extension type</li>
from the following <li pn="section-17.3-3.3">
<t indent="0" pn="section-17.3-3.3.1">Message(s): The messages in wh
ich the extension may appear, drawn from the following
list: </t> list: </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>KP: KeyPackage objects</li> on-17.3-3.3.2">
<li>LN: LeafNode objects</li> <li pn="section-17.3-3.3.2.1">KP: KeyPackage objects</li>
<li>GC: GroupContext objects</li> <li pn="section-17.3-3.3.2.2">LN: LeafNode objects</li>
<li>GI: GroupInfo objects</li> <li pn="section-17.3-3.3.2.3">GC: GroupContext objects</li>
<li pn="section-17.3-3.3.2.4">GI: GroupInfo objects</li>
</ul> </ul>
</li> </li>
<li>Recommended: Same as in <xref target="mls-ciphersuites"/></li> <li pn="section-17.3-3.4">Recommended: Same as in <xref target="mls-ci
<li>Reference: The document where this extension is defined</li> pher-suites" format="default" sectionFormat="of" derivedContent="Section 17.1"/>
</li>
<li pn="section-17.3-3.5">Reference: The document where this extension
is defined</li>
</ul> </ul>
<t>Initial contents:</t> <t indent="0" pn="section-17.3-4">Initial contents:</t>
<table> <table align="center" pn="table-9">
<name slugifiedName="name-mls-extension-types-registry">MLS Extension
Types Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left" colspan="1" rowspan="1">Value</th>
<th align="left">Name</th> <th align="left" colspan="1" rowspan="1">Name</th>
<th align="left">Message(s)</th> <th align="left" colspan="1" rowspan="1">Message(s)</th>
<th align="left">R</th> <th align="left" colspan="1" rowspan="1">R</th>
<th align="left">Ref</th> <th align="left" colspan="1" rowspan="1">Ref</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0x0000</td> <td align="left" colspan="1" rowspan="1">0x0000</td>
<td align="left">RESERVED</td> <td align="left" colspan="1" rowspan="1">RESERVED</td>
<td align="left">N/A</td> <td align="left" colspan="1" rowspan="1">N/A</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0001</td> <td align="left" colspan="1" rowspan="1">0x0001</td>
<td align="left">application_id</td> <td align="left" colspan="1" rowspan="1">application_id</td>
<td align="left">LN</td> <td align="left" colspan="1" rowspan="1">LN</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0002</td> <td align="left" colspan="1" rowspan="1">0x0002</td>
<td align="left">ratchet_tree</td> <td align="left" colspan="1" rowspan="1">ratchet_tree</td>
<td align="left">GI</td> <td align="left" colspan="1" rowspan="1">GI</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0003</td> <td align="left" colspan="1" rowspan="1">0x0003</td>
<td align="left">required_capabilities</td> <td align="left" colspan="1" rowspan="1">required_capabilities</td
<td align="left">GC</td> >
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">GC</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0004</td> <td align="left" colspan="1" rowspan="1">0x0004</td>
<td align="left">external_pub</td> <td align="left" colspan="1" rowspan="1">external_pub</td>
<td align="left">GI</td> <td align="left" colspan="1" rowspan="1">GI</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0005</td> <td align="left" colspan="1" rowspan="1">0x0005</td>
<td align="left">external_senders</td> <td align="left" colspan="1" rowspan="1">external_senders</td>
<td align="left">GC</td> <td align="left" colspan="1" rowspan="1">GC</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0A0A</td> <td align="left" colspan="1" rowspan="1">0x0A0A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">KP, GI</td> <td align="left" colspan="1" rowspan="1">KP, GI, LN</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x1A1A</td> <td align="left" colspan="1" rowspan="1">0x1A1A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">KP, GI</td> <td align="left" colspan="1" rowspan="1">KP, GI, LN</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x2A2A</td> <td align="left" colspan="1" rowspan="1">0x2A2A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">KP, GI</td> <td align="left" colspan="1" rowspan="1">KP, GI, LN</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x3A3A</td> <td align="left" colspan="1" rowspan="1">0x3A3A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">KP, GI</td> <td align="left" colspan="1" rowspan="1">KP, GI, LN</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x4A4A</td> <td align="left" colspan="1" rowspan="1">0x4A4A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">KP, GI</td> <td align="left" colspan="1" rowspan="1">KP, GI, LN</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x5A5A</td> <td align="left" colspan="1" rowspan="1">0x5A5A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">KP, GI</td> <td align="left" colspan="1" rowspan="1">KP, GI, LN</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x6A6A</td> <td align="left" colspan="1" rowspan="1">0x6A6A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">KP, GI</td> <td align="left" colspan="1" rowspan="1">KP, GI, LN</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x7A7A</td> <td align="left" colspan="1" rowspan="1">0x7A7A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">KP, GI</td> <td align="left" colspan="1" rowspan="1">KP, GI, LN</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8A8A</td> <td align="left" colspan="1" rowspan="1">0x8A8A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">KP, GI</td> <td align="left" colspan="1" rowspan="1">KP, GI, LN</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x9A9A</td> <td align="left" colspan="1" rowspan="1">0x9A9A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">KP, GI</td> <td align="left" colspan="1" rowspan="1">KP, GI, LN</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xAAAA</td> <td align="left" colspan="1" rowspan="1">0xAAAA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">KP, GI</td> <td align="left" colspan="1" rowspan="1">KP, GI, LN</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xBABA</td> <td align="left" colspan="1" rowspan="1">0xBABA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">KP, GI</td> <td align="left" colspan="1" rowspan="1">KP, GI, LN</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xCACA</td> <td align="left" colspan="1" rowspan="1">0xCACA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">KP, GI</td> <td align="left" colspan="1" rowspan="1">KP, GI, LN</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xDADA</td> <td align="left" colspan="1" rowspan="1">0xDADA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">KP, GI</td> <td align="left" colspan="1" rowspan="1">KP, GI, LN</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xEAEA</td> <td align="left" colspan="1" rowspan="1">0xEAEA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">KP, GI</td> <td align="left" colspan="1" rowspan="1">KP, GI, LN</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xF000 - 0xFFFF</td> <td align="left" colspan="1" rowspan="1">0xF000 - 0xFFFF</td>
<td align="left">Reserved for Private Use</td> <td align="left" colspan="1" rowspan="1">Reserved for Private Use<
<td align="left">N/A</td> /td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">N/A</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="mls-proposal-types"> <section anchor="mls-proposal-types" numbered="true" removeInRFC="false" t
<name>MLS Proposal Types</name> oc="include" pn="section-17.4">
<t>This registry lists identifiers for types of proposals that can be ma <name slugifiedName="name-mls-proposal-types">MLS Proposal Types</name>
de for <t indent="0" pn="section-17.4-1">The "MLS Proposal Types" registry list
s identifiers for types of proposals that can be made for
changes to an MLS group. The extension type field is two bytes wide, so valid changes to an MLS group. The extension type field is two bytes wide, so valid
extension type values are in the range 0x0000 to 0xFFFF.</t> extension type values are in the range 0x0000 to 0xFFFF.</t>
<t>Template:</t> <t indent="0" pn="section-17.4-2">Template:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>Value: The numeric value of the proposal type</li> 7.4-3">
<li>Name: The name of the proposal type</li> <li pn="section-17.4-3.1">Value: The numeric value of the proposal typ
<li>Recommended: Same as in <xref target="mls-ciphersuites"/></li> e</li>
<li>External: Whether a proposal of this type may be sent by an <tt>ex <li pn="section-17.4-3.2">Name: The name of the proposal type</li>
ternal</tt> sender <li pn="section-17.4-3.3">Recommended: Same as in <xref target="mls-ci
(see <xref target="external-proposals"/>).</li> pher-suites" format="default" sectionFormat="of" derivedContent="Section 17.1"/>
<li>Path Required: Whether a Commit covering a proposal of this type i </li>
s required <li pn="section-17.4-3.4">External: Whether a proposal of this type ma
to have its <tt>path</tt> field populated (see <xref target="commit"/>).</li> y be sent by an <tt>external</tt> sender
<li>Reference: The document where this extension is defined</li> (see <xref target="external-proposals" format="default" sectionFormat="of" deriv
edContent="Section 12.1.8"/>)</li>
<li pn="section-17.4-3.5">Path Required: Whether a Commit covering a p
roposal of this type is required
to have its <tt>path</tt> field populated (see <xref target="commit" format="def
ault" sectionFormat="of" derivedContent="Section 12.4"/>)</li>
<li pn="section-17.4-3.6">Reference: The document where this extension
is defined</li>
</ul> </ul>
<t>Initial contents:</t> <t indent="0" pn="section-17.4-4">Initial contents:</t>
<table> <table align="center" pn="table-10">
<name slugifiedName="name-mls-proposal-types-registry">MLS Proposal Ty
pes Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left" colspan="1" rowspan="1">Value</th>
<th align="left">Name</th> <th align="left" colspan="1" rowspan="1">Name</th>
<th align="left">R</th> <th align="left" colspan="1" rowspan="1">R</th>
<th align="left">Ext</th> <th align="left" colspan="1" rowspan="1">Ext</th>
<th align="left">Path</th> <th align="left" colspan="1" rowspan="1">Path</th>
<th align="left">Ref</th> <th align="left" colspan="1" rowspan="1">Ref</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0x0000</td> <td align="left" colspan="1" rowspan="1">0x0000</td>
<td align="left">RESERVED</td> <td align="left" colspan="1" rowspan="1">RESERVED</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0001</td> <td align="left" colspan="1" rowspan="1">0x0001</td>
<td align="left">add</td> <td align="left" colspan="1" rowspan="1">add</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">N</td> <td align="left" colspan="1" rowspan="1">N</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0002</td> <td align="left" colspan="1" rowspan="1">0x0002</td>
<td align="left">update</td> <td align="left" colspan="1" rowspan="1">update</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">N</td> <td align="left" colspan="1" rowspan="1">N</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0003</td> <td align="left" colspan="1" rowspan="1">0x0003</td>
<td align="left">remove</td> <td align="left" colspan="1" rowspan="1">remove</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0004</td> <td align="left" colspan="1" rowspan="1">0x0004</td>
<td align="left">psk</td> <td align="left" colspan="1" rowspan="1">psk</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">N</td> <td align="left" colspan="1" rowspan="1">N</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0005</td> <td align="left" colspan="1" rowspan="1">0x0005</td>
<td align="left">reinit</td> <td align="left" colspan="1" rowspan="1">reinit</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">N</td> <td align="left" colspan="1" rowspan="1">N</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0006</td> <td align="left" colspan="1" rowspan="1">0x0006</td>
<td align="left">external_init</td> <td align="left" colspan="1" rowspan="1">external_init</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">N</td> <td align="left" colspan="1" rowspan="1">N</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0007</td> <td align="left" colspan="1" rowspan="1">0x0007</td>
<td align="left">group_context_extensions</td> <td align="left" colspan="1" rowspan="1">group_context_extensions<
<td align="left">Y</td> /td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0A0A</td> <td align="left" colspan="1" rowspan="1">0x0A0A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x1A1A</td> <td align="left" colspan="1" rowspan="1">0x1A1A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x2A2A</td> <td align="left" colspan="1" rowspan="1">0x2A2A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x3A3A</td> <td align="left" colspan="1" rowspan="1">0x3A3A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x4A4A</td> <td align="left" colspan="1" rowspan="1">0x4A4A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x5A5A</td> <td align="left" colspan="1" rowspan="1">0x5A5A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x6A6A</td> <td align="left" colspan="1" rowspan="1">0x6A6A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x7A7A</td> <td align="left" colspan="1" rowspan="1">0x7A7A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8A8A</td> <td align="left" colspan="1" rowspan="1">0x8A8A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x9A9A</td> <td align="left" colspan="1" rowspan="1">0x9A9A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xAAAA</td> <td align="left" colspan="1" rowspan="1">0xAAAA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xBABA</td> <td align="left" colspan="1" rowspan="1">0xBABA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xCACA</td> <td align="left" colspan="1" rowspan="1">0xCACA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xDADA</td> <td align="left" colspan="1" rowspan="1">0xDADA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xEAEA</td> <td align="left" colspan="1" rowspan="1">0xEAEA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xF000 - 0xFFFF</td> <td align="left" colspan="1" rowspan="1">0xF000 - 0xFFFF</td>
<td align="left">Reserved for Private Use</td> <td align="left" colspan="1" rowspan="1">Reserved for Private Use<
<td align="left">-</td> /td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="mls-credential-types"> <section anchor="mls-credential-types" numbered="true" removeInRFC="false"
<name>MLS Credential Types</name> toc="include" pn="section-17.5">
<t>This registry lists identifiers for types of credentials that can be <name slugifiedName="name-mls-credential-types">MLS Credential Types</na
used for me>
<t indent="0" pn="section-17.5-1">The "MLS Credential Types" registry li
sts identifiers for types of credentials that can be used for
authentication in the MLS protocol. The credential type field is two bytes wide , authentication in the MLS protocol. The credential type field is two bytes wide ,
so valid credential type values are in the range 0x0000 to 0xFFFF.</t> so valid credential type values are in the range 0x0000 to 0xFFFF.</t>
<t>Template:</t> <t indent="0" pn="section-17.5-2">Template:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>Value: The numeric value of the credential type</li> 7.5-3">
<li>Name: The name of the credential type</li> <li pn="section-17.5-3.1">Value: The numeric value of the credential t
<li>Recommended: Same as in <xref target="mls-ciphersuites"/></li> ype</li>
<li>Reference: The document where this credential is defined</li> <li pn="section-17.5-3.2">Name: The name of the credential type</li>
<li pn="section-17.5-3.3">Recommended: Same as in <xref target="mls-ci
pher-suites" format="default" sectionFormat="of" derivedContent="Section 17.1"/>
</li>
<li pn="section-17.5-3.4">Reference: The document where this credentia
l is defined</li>
</ul> </ul>
<t>Initial contents:</t> <t indent="0" pn="section-17.5-4">Initial contents:</t>
<table> <table align="center" pn="table-11">
<name slugifiedName="name-mls-credential-types-regist">MLS Credential
Types Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left" colspan="1" rowspan="1">Value</th>
<th align="left">Name</th> <th align="left" colspan="1" rowspan="1">Name</th>
<th align="left">R</th> <th align="left" colspan="1" rowspan="1">R</th>
<th align="left">Ref</th> <th align="left" colspan="1" rowspan="1">Ref</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0x0000</td> <td align="left" colspan="1" rowspan="1">0x0000</td>
<td align="left">RESERVED</td> <td align="left" colspan="1" rowspan="1">RESERVED</td>
<td align="left">-</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0001</td> <td align="left" colspan="1" rowspan="1">0x0001</td>
<td align="left">basic</td> <td align="left" colspan="1" rowspan="1">basic</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0002</td> <td align="left" colspan="1" rowspan="1">0x0002</td>
<td align="left">x509</td> <td align="left" colspan="1" rowspan="1">x509</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0A0A</td> <td align="left" colspan="1" rowspan="1">0x0A0A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x1A1A</td> <td align="left" colspan="1" rowspan="1">0x1A1A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x2A2A</td> <td align="left" colspan="1" rowspan="1">0x2A2A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x3A3A</td> <td align="left" colspan="1" rowspan="1">0x3A3A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x4A4A</td> <td align="left" colspan="1" rowspan="1">0x4A4A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x5A5A</td> <td align="left" colspan="1" rowspan="1">0x5A5A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x6A6A</td> <td align="left" colspan="1" rowspan="1">0x6A6A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x7A7A</td> <td align="left" colspan="1" rowspan="1">0x7A7A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8A8A</td> <td align="left" colspan="1" rowspan="1">0x8A8A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x9A9A</td> <td align="left" colspan="1" rowspan="1">0x9A9A</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xAAAA</td> <td align="left" colspan="1" rowspan="1">0xAAAA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xBABA</td> <td align="left" colspan="1" rowspan="1">0xBABA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xCACA</td> <td align="left" colspan="1" rowspan="1">0xCACA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xDADA</td> <td align="left" colspan="1" rowspan="1">0xDADA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xEAEA</td> <td align="left" colspan="1" rowspan="1">0xEAEA</td>
<td align="left">GREASE</td> <td align="left" colspan="1" rowspan="1">GREASE</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xF000 - 0xFFFF</td> <td align="left" colspan="1" rowspan="1">0xF000 - 0xFFFF</td>
<td align="left">Reserved for Private Use</td> <td align="left" colspan="1" rowspan="1">Reserved for Private Use<
<td align="left">-</td> /td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="mls-signature-labels"> <section anchor="mls-signature-labels" numbered="true" removeInRFC="false"
<name>MLS Signature Labels</name> toc="include" pn="section-17.6">
<t>The <tt>SignWithLabel</tt> function defined in <xref target="signing" <name slugifiedName="name-mls-signature-labels">MLS Signature Labels</na
/> avoids the risk of me>
<t indent="0" pn="section-17.6-1">The <tt>SignWithLabel</tt> function de
fined in <xref target="signing" format="default" sectionFormat="of" derivedConte
nt="Section 5.1.2"/> avoids the risk of
confusion between signatures in different contexts. Each context is assigned a confusion between signatures in different contexts. Each context is assigned a
distinct label that is incorporated into the signature. This registry records distinct label that is incorporated into the signature. The "MLS Signature Labe
the labels defined in this document, and allows additional labels to be ls" registry records
registered in case extensions add other types of signature using the same the labels defined in this document and allows additional labels to be
registered in case extensions add other types of signatures using the same
signature keys used elsewhere in MLS.</t> signature keys used elsewhere in MLS.</t>
<t>Template:</t> <t indent="0" pn="section-17.6-2">Template:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>Label: The string to be used as the <tt>Label</tt> parameter to <t 7.6-3">
t>SignWithLabel</tt></li> <li pn="section-17.6-3.1">Label: The string to be used as the <tt>Labe
<li>Recommended: Same as in <xref target="mls-ciphersuites"/></li> l</tt> parameter to <tt>SignWithLabel</tt></li>
<li>Reference: The document where this credential is defined</li> <li pn="section-17.6-3.2">Recommended: Same as in <xref target="mls-ci
pher-suites" format="default" sectionFormat="of" derivedContent="Section 17.1"/>
</li>
<li pn="section-17.6-3.3">Reference: The document where this label is
defined</li>
</ul> </ul>
<t>Initial contents:</t> <t indent="0" pn="section-17.6-4">Initial contents:</t>
<table> <table align="center" pn="table-12">
<name slugifiedName="name-mls-signature-labels-regist">MLS Signature L
abels Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Label</th> <th align="left" colspan="1" rowspan="1">Label</th>
<th align="left">R</th> <th align="left" colspan="1" rowspan="1">R</th>
<th align="left">Ref</th> <th align="left" colspan="1" rowspan="1">Ref</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">"FramedContentTBS"</td> <td align="left" colspan="1" rowspan="1">"FramedContentTBS"</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">"LeafNodeTBS"</td> <td align="left" colspan="1" rowspan="1">"LeafNodeTBS"</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">"KeyPackageTBS"</td> <td align="left" colspan="1" rowspan="1">"KeyPackageTBS"</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">"GroupInfoTBS"</td> <td align="left" colspan="1" rowspan="1">"GroupInfoTBS"</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="mls-public-key-encryption-labels"> <section anchor="mls-public-key-encryption-labels" numbered="true" removeI
<name>MLS Public Key Encryption Labels</name> nRFC="false" toc="include" pn="section-17.7">
<t>The <tt>EncryptWithLabel</tt> function defined in <xref target="publi <name slugifiedName="name-mls-public-key-encryption-l">MLS Public Key En
c-key-encryption"/> avoids the cryption Labels</name>
<t indent="0" pn="section-17.7-1">The <tt>EncryptWithLabel</tt> function
defined in <xref target="public-key-encryption" format="default" sectionFormat=
"of" derivedContent="Section 5.1.3"/> avoids the
risk of confusion between ciphertexts produced for different purposes in risk of confusion between ciphertexts produced for different purposes in
different contexts. Each context is assigned a distinct label that is different contexts. Each context is assigned a distinct label that is
incorporated into the signature. This registry records the labels defined in incorporated into the signature. The "MLS Public Key Encryption Labels" registr
this document, and allows additional labels to be registered in case extensions y records the labels defined in
add other types of public-key encryption using the same HPKE keys used elsewhere 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.</t> in MLS.</t>
<t>Template:</t> <t indent="0" pn="section-17.7-2">Template:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>Label: The string to be used as the <tt>Label</tt> parameter to <t 7.7-3">
t>EncryptWithLabel</tt></li> <li pn="section-17.7-3.1">Label: The string to be used as the <tt>Labe
<li>Recommended: Same as in <xref target="mls-ciphersuites"/></li> l</tt> parameter to <tt>EncryptWithLabel</tt></li>
<li>Reference: The document where this credential is defined</li> <li pn="section-17.7-3.2">Recommended: Same as in <xref target="mls-ci
pher-suites" format="default" sectionFormat="of" derivedContent="Section 17.1"/>
</li>
<li pn="section-17.7-3.3">Reference: The document where this label is
defined</li>
</ul> </ul>
<t>Initial contents:</t> <t indent="0" pn="section-17.7-4">Initial contents:</t>
<table> <table align="center" pn="table-13">
<name slugifiedName="name-mls-public-key-encryption-la">MLS Public Key
Encryption Labels Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Label</th> <th align="left" colspan="1" rowspan="1">Label</th>
<th align="left">R</th> <th align="left" colspan="1" rowspan="1">R</th>
<th align="left">Ref</th> <th align="left" colspan="1" rowspan="1">Ref</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">"UpdatePathNode"</td> <td align="left" colspan="1" rowspan="1">"UpdatePathNode"</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
<tr> <tr>
<td align="left">"Welcome"</td> <td align="left" colspan="1" rowspan="1">"Welcome"</td>
<td align="left">Y</td> <td align="left" colspan="1" rowspan="1">Y</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9420</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="mls-exporter-labels"> <section anchor="mls-exporter-labels" numbered="true" removeInRFC="false"
<name>MLS Exporter Labels</name> toc="include" pn="section-17.8">
<t>The exporter function defined in <xref target="exporters"/> allows ap <name slugifiedName="name-mls-exporter-labels">MLS Exporter Labels</name
plications to derive key >
material from the MLS key schedule. Like the TLS exporter <xref target="RFC8446 <t indent="0" pn="section-17.8-1">The exporter function defined in <xref
"/>, the MLS target="exporters" format="default" sectionFormat="of" derivedContent="Section
8.5"/> allows applications to derive key
material from the MLS key schedule. Like the TLS exporter <xref target="RFC8446
" format="default" sectionFormat="of" derivedContent="RFC8446"/>, the MLS
exporter uses a label to distinguish between different applications' use of the exporter uses a label to distinguish between different applications' use of the
exporter. This registry allows applications to register their usage to avoid exporter. The "MLS Exporter Labels" registry allows applications to register th eir usage to avoid
collisions.</t> collisions.</t>
<t>Template:</t> <t indent="0" pn="section-17.8-2">Template:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>Label: The string to be used as the <tt>Label</tt> parameter to <t 7.8-3">
t>MLS-Exporter</tt></li> <li pn="section-17.8-3.1">Label: The string to be used as the <tt>Labe
<li>Recommended: Same as in <xref target="mls-ciphersuites"/></li> l</tt> parameter to <tt>MLS-Exporter</tt></li>
<li>Reference: The document where this credential is defined</li> <li pn="section-17.8-3.2">Recommended: Same as in <xref target="mls-ci
pher-suites" format="default" sectionFormat="of" derivedContent="Section 17.1"/>
</li>
<li pn="section-17.8-3.3">Reference: The document where this label is
defined</li>
</ul> </ul>
<t>The registry has no initial contents, since it is intended to be used by <t indent="0" pn="section-17.8-4">The registry has no initial contents, since it is intended to be used by
applications, not the core protocol. The table below is intended only to show applications, not the core protocol. The table below is intended only to show
the column layout of the registry.</t> the column layout of the registry.</t>
<table> <table align="center" pn="table-14">
<name slugifiedName="name-mls-exporter-labels-registr">MLS Exporter La
bels Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Label</th> <th align="left" colspan="1" rowspan="1">Label</th>
<th align="left">Recommended</th> <th align="left" colspan="1" rowspan="1">Recommended</th>
<th align="left">Reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">(N/A)</td> <td align="left" colspan="1" rowspan="1">(N/A)</td>
<td align="left">(N/A)</td> <td align="left" colspan="1" rowspan="1">(N/A)</td>
<td align="left">(N/A)</td> <td align="left" colspan="1" rowspan="1">(N/A)</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="de"> <section anchor="de" numbered="true" removeInRFC="false" toc="include" pn=
<name>MLS Designated Expert Pool</name> "section-17.9">
<t>Specification Required <xref target="RFC8126"/> registry requests are <name slugifiedName="name-mls-designated-expert-pool">MLS Designated Exp
registered ert Pool</name>
after a three-week review period on the MLS DEs' mailing list: <t indent="0" pn="section-17.9-1">Specification Required <xref target="R
<eref target="mailto:mls-reg-review@ietf.org">mls-reg-review@ietf.org</eref>, on FC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/> registry
the advice of one or more of the MLS DEs. However, requests are registered
after a three-week review period on the MLS Designated Expert (DE) mailing list
<eref brackets="angle" target="mailto:mls-reg-review@ietf.org"/> on the advice o
f one or more of the MLS DEs. However,
to allow for the allocation of values prior to publication, the MLS to allow for the allocation of values prior to publication, the MLS
DEs may approve registration once they are satisfied that such a DEs may approve registration once they are satisfied that such a
specification will be published.</t> specification will be published.</t>
<t>Registration requests sent to the MLS DEs mailing list for review <t indent="0" pn="section-17.9-2">Registration requests sent to the MLS
SHOULD use an appropriate subject (e.g., "Request to register value DEs' mailing list for review
<bcp14>SHOULD</bcp14> use an appropriate subject (e.g., "Request to register val
ue
in MLS Bar registry").</t> in MLS Bar registry").</t>
<t>Within the review period, the MLS DEs will either approve or deny <t indent="0" pn="section-17.9-3">Within the review period, the MLS DEs
the registration request, communicating this decision to the MLS DEs will either approve or deny
mailing list and IANA. Denials SHOULD include an explanation and, if the registration request, communicating this decision to the MLS DEs'
mailing list and IANA. Denials <bcp14>SHOULD</bcp14> include an explanation and,
if
applicable, suggestions as to how to make the request successful. applicable, suggestions as to how to make the request successful.
Registration requests that are undetermined for a period longer than Registration requests that are undetermined for a period longer than
21 days can be brought to the IESG's attention for resolution using 21 days can be brought to the IESG's attention for resolution using
the <eref target="mailto:iesg@ietf.org">iesg@ietf.org</eref> mailing list.</t> the <eref brackets="angle" target="mailto:iesg@ietf.org"/> mailing list.</t>
<t>Criteria that SHOULD be applied by the MLS DEs includes determining <t indent="0" pn="section-17.9-4">Criteria that <bcp14>SHOULD</bcp14> be
applied by the MLS DEs includes determining
whether the proposed registration duplicates existing functionality, whether the proposed registration duplicates existing functionality,
whether it is likely to be of general applicability or useful only whether it is likely to be of general applicability or useful only
for a single application, and whether the registration description for a single application, and whether the registration description
is clear. For example, the MLS DEs will apply the ciphersuite-related is clear. For example, for cipher suite registrations, the MLS DEs will apply th
advisory found in <xref target="mls-ciphersuites"/>.</t> e
<t>IANA MUST only accept registry updates from the MLS DEs and SHOULD advisory found in <xref target="mls-cipher-suites" format="default" sectionForma
t="of" derivedContent="Section 17.1"/>.</t>
<t indent="0" pn="section-17.9-5">IANA <bcp14>MUST</bcp14> only accept r
egistry updates from the MLS DEs and <bcp14>SHOULD</bcp14>
direct all requests for registration to the MLS DEs' mailing list.</t> direct all requests for registration to the MLS DEs' mailing list.</t>
<t>It is suggested that multiple MLS DEs be appointed who are able to <t indent="0" pn="section-17.9-6">It is suggested that multiple MLS DEs who are able to
represent the perspectives of different applications using this represent the perspectives of different applications using this
specification, in order to enable broadly informed review of specification be appointed, in order to enable a broadly informed review of
registration decisions. In cases where a registration decision could registration decisions. In cases where a registration decision could
be perceived as creating a conflict of interest for a particular 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.</t> MLS DE, that MLS DE <bcp14>SHOULD</bcp14> defer to the judgment of the other MLS DEs.</t>
</section> </section>
<section anchor="the-messagemls-mime-type"> <section anchor="the-messagemls-media-type" numbered="true" removeInRFC="f
<name>The "message/mls" MIME Type</name> alse" toc="include" pn="section-17.10">
<t>This document registers the "message/mls" MIME media type in order to <name slugifiedName="name-the-message-mls-media-type">The "message/mls"
allow other Media Type</name>
protocols (e.g., HTTP <xref target="RFC9113"/>) to convey MLS messages.</t> <t indent="0" pn="section-17.10-1">This document registers the "message/
<dl> mls" media type in the "message" registry in order to allow other
<dt>Type name:</dt> protocols (e.g., HTTP <xref target="RFC9113" format="default" sectionFormat="of"
<dd> derivedContent="RFC9113"/>) to convey MLS messages.</t>
<t>message</t> <dl indent="3" newline="false" spacing="normal" pn="section-17.10-2">
</dd> <dt pn="section-17.10-2.1">Type name:</dt>
<dt>Subtype name:</dt> <dd pn="section-17.10-2.2">message</dd>
<dd> <dt pn="section-17.10-2.3">Subtype name:</dt>
<t>mls</t> <dd pn="section-17.10-2.4">mls</dd>
</dd> <dt pn="section-17.10-2.5">Required parameters:</dt>
<dt>Required parameters:</dt> <dd pn="section-17.10-2.6">none</dd>
<dd> <dt pn="section-17.10-2.7">Optional parameters:</dt>
<t>none</t> <dd pn="section-17.10-2.8">
</dd> <dl indent="3" newline="false" spacing="normal" pn="section-17.10-2.
<dt>Optional parameters:</dt> 8.1">
<dd> <dt pn="section-17.10-2.8.1.1">version</dt>
<dl> <dd pn="section-17.10-2.8.1.2"/>
<dt>version</dt> <dt pn="section-17.10-2.8.1.3"> version:</dt>
<dd> <dd pn="section-17.10-2.8.1.4">The MLS protocol version expressed
<t/> as a string
</dd> <tt>&lt;major&gt;.&lt;minor&gt;</tt>. If omitted, the version is "1.0", which
<dt> version:</dt>
<dd>
<t>The MLS protocol version expressed as a string
<tt>&lt;major&gt;.&lt;minor&gt;</tt>. If omitted the version is "1.0", which
corresponds to MLS ProtocolVersion mls10. If for some reason corresponds to MLS ProtocolVersion mls10. If for some reason
the version number in the MIME type parameter differs from the the version number in the media type parameter differs from the
ProtocolVersion embedded in the protocol, the protocol takes ProtocolVersion embedded in the protocol, the protocol takes
precedence.</t> precedence.</dd>
</dd>
</dl> </dl>
</dd> </dd>
<dt>Encoding considerations:</dt> <dt pn="section-17.10-2.9">Encoding considerations:</dt>
<dd> <dd pn="section-17.10-2.10">MLS messages are represented using the TLS
<t>MLS messages are represented using the TLS presentation language <xref target="RFC8446" format="default" sectionFormat="of"
presentation language <xref target="RFC8446"/>. Therefore MLS messages need to b derivedContent="RFC8446"/>. Therefore, MLS messages need to be
e treated as binary data.</dd>
treated as binary data.</t> <dt pn="section-17.10-2.11">Security considerations:</dt>
</dd> <dd pn="section-17.10-2.12">MLS is an encrypted messaging layer design
<dt>Security considerations:</dt> ed
<dd> to be transmitted over arbitrary lower-layer protocols. The
<t>MLS is an encrypted messaging layer designed security considerations in this document (RFC 9420) also apply.</dd>
to be transmitted over arbitrary lower layer protocols. The <dt pn="section-17.10-2.13">Interoperability considerations:</dt>
security considerations in this document (RFC XXXX) also apply.</t> <dd pn="section-17.10-2.14">N/A</dd>
</dd> <dt pn="section-17.10-2.15">Published specification:</dt>
<dt>Interoperability considerations:</dt> <dd pn="section-17.10-2.16">RFC 9420</dd>
<dd> <dt pn="section-17.10-2.17">Applications that use this media type:</dt
<t>N/A</t> >
</dd> <dd pn="section-17.10-2.18">MLS-based messaging applications</dd>
<dt>Published specification:</dt> <dt pn="section-17.10-2.19">Fragment identifier considerations:</dt>
<dd> <dd pn="section-17.10-2.20">N/A</dd>
<t>RFC XXXX</t> <dt pn="section-17.10-2.21">Additional information:</dt>
</dd> <dd pn="section-17.10-2.22">
<dt>Applications that use this media type:</dt> <t indent="0" pn="section-17.10-2.22.1">
<dd> <br/>
<t>MLS-based messaging applications</t> </t>
</dd> <dl indent="3" newline="false" spacing="compact" pn="section-17.10-2
<dt>Fragment identifier considerations:</dt> .22.2">
<dd> <dt pn="section-17.10-2.22.2.1">Deprecated alias names for this ty
<t>N/A</t> pe:</dt>
<dd pn="section-17.10-2.22.2.2">N/A</dd>
<dt pn="section-17.10-2.22.2.3">Magic number(s):</dt>
<dd pn="section-17.10-2.22.2.4">N/A</dd>
<dt pn="section-17.10-2.22.2.5">File extension(s):</dt>
<dd pn="section-17.10-2.22.2.6">N/A</dd>
<dt pn="section-17.10-2.22.2.7">Macintosh file type code(s):</dt>
<dd pn="section-17.10-2.22.2.8">N/A</dd>
</dl>
</dd> </dd>
</dl> </dl>
<t>Additional information:</t> <dl indent="3" newline="false" spacing="normal" pn="section-17.10-3">
<ul spacing="normal"> <dt pn="section-17.10-3.1">Person &amp; email address to contact for f
<li>Deprecated alias names for this type: N/A</li> urther information:</dt>
<li>Magic number(s): N/A</li> <dd pn="section-17.10-3.2">
<li>File extension(s): N/A</li> <t indent="0" pn="section-17.10-3.2.1">IETF MLS Working Group <eref
<li>Macintosh file type code(s): N/A</li> brackets="angle" target="mailto:mls@ietf.org"/></t>
</ul>
<dl>
<dt>Person &amp; email address to contact for further information:</dt
>
<dd>
<t>IETF MLS Working Group <eref target="mailto:mls@ietf.org">mls@iet
f.org</eref></t>
</dd>
<dt>Intended usage:</dt>
<dd>
<t>COMMON</t>
</dd> </dd>
<dt>Restrictions on usage:</dt> <dt pn="section-17.10-3.3">Intended usage:</dt>
<dd> <dd pn="section-17.10-3.4">
<t>N/A</t> <t indent="0" pn="section-17.10-3.4.1">COMMON</t>
</dd> </dd>
<dt>Author:</dt> <dt pn="section-17.10-3.5">Restrictions on usage:</dt>
<dd> <dd pn="section-17.10-3.6">
<t>IETF MLS Working Group</t> <t indent="0" pn="section-17.10-3.6.1">N/A</t>
</dd> </dd>
<dt>Change controller:</dt> <dt pn="section-17.10-3.7">Author:</dt>
<dd> <dd pn="section-17.10-3.8">
<t>IESG</t> <t indent="0" pn="section-17.10-3.8.1">IETF MLS Working Group</t>
</dd> </dd>
<dt>Provisional registration? (standards tree only):</dt> <dt pn="section-17.10-3.9">Change controller:</dt>
<dd> <dd pn="section-17.10-3.10">
<t>No</t> <t indent="0" pn="section-17.10-3.10.1">IETF</t>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references> <displayreference target="I-D.ietf-mls-architecture" to="MLS-ARCH"/>
<name>References</name> <displayreference target="I-D.irtf-cfrg-aead-limits" to="CFRG-AEAD-LIMITS"/>
<references> <references pn="section-18">
<name>Normative References</name> <name slugifiedName="name-references">References</name>
<reference anchor="RFC2119"> <references pn="section-18.1">
<name slugifiedName="name-normative-references">Normative References</na
me>
<reference anchor="RFC2104" target="https://www.rfc-editor.org/info/rfc2
104" quoteTitle="true" derivedAnchor="RFC2104">
<front>
<title>HMAC: Keyed-Hashing for Message Authentication</title>
<author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
<author fullname="M. Bellare" initials="M." surname="Bellare"/>
<author fullname="R. Canetti" initials="R." surname="Canetti"/>
<date month="February" year="1997"/>
<abstract>
<t indent="0">This document describes HMAC, a mechanism for messag
e authentication using cryptographic hash functions. HMAC can be used with any i
terative cryptographic hash function, e.g., MD5, SHA-1, in combination with a se
cret shared key. The cryptographic strength of HMAC depends on the properties of
the underlying hash function. This memo provides information for the Internet c
ommunity. This memo does not specify an Internet standard of any kind</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2104"/>
<seriesInfo name="DOI" value="10.17487/RFC2104"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<front> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit le> <title>Key words for use in RFCs to Indicate Requirement Levels</tit le>
<author fullname="S. Bradner" initials="S." surname="Bradner"> <author fullname="S. Bradner" initials="S." surname="Bradner"/>
<organization/>
</author>
<date month="March" year="1997"/> <date month="March" year="1997"/>
<abstract> <abstract>
<t>In many standards track documents several words are used to sig nify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF document s. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often cap italized. This document defines these words as they should be interpreted in IET F documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t >
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/> <seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference> </reference>
<reference anchor="RFC8174"> <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
126" quoteTitle="true" derivedAnchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t indent="0">Many protocols make use of points of extensibility t
hat use constants to identify various protocol parameters. To ensure that the va
lues in these fields do not have conflicting uses and to promote interoperabilit
y, their allocations are often coordinated by a central record keeper. For IETF
protocols, that role is filled by the Internet Assigned Numbers Authority (IANA)
.</t>
<t indent="0">To make assignments in a given registry prudently, g
uidance describing the conditions under which new values should be assigned, as
well as when and how modifications to existing values can be made, is needed. Th
is document defines a framework for the documentation of these guidelines by spe
cification authors, in order to assure that the provided guidance for the IANA C
onsiderations is clear and addresses the various issues that are likely in the o
peration of a registry.</t>
<t indent="0">This is the third edition of this document; it obsol
etes RFC 5226.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti tle> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"> <author fullname="B. Leiba" initials="B." surname="Leiba"/>
<organization/>
</author>
<date month="May" year="2017"/> <date month="May" year="2017"/>
<abstract> <abstract>
<t>RFC 2119 specifies common key words that may be used in protoco l specifications. This document aims to reduce the ambiguity by clarifying tha t only UPPERCASE usage of the key words have the defined special meanings.</t> <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clari fying that only UPPERCASE usage of the key words have the defined special meanin gs.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/> <seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference> </reference>
<reference anchor="RFC9180"> <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
446" quoteTitle="true" derivedAnchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t indent="0">This document specifies version 1.3 of the Transport
Layer Security (TLS) protocol. TLS allows client/server applications to communi
cate over the Internet in a way that is designed to prevent eavesdropping, tampe
ring, and message forgery.</t>
<t indent="0">This document updates RFCs 5705 and 6066, and obsole
tes RFCs 5077, 5246, and 6961. This document also specifies new requirements for
TLS 1.2 implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC9180" target="https://www.rfc-editor.org/info/rfc9
180" quoteTitle="true" derivedAnchor="RFC9180">
<front> <front>
<title>Hybrid Public Key Encryption</title> <title>Hybrid Public Key Encryption</title>
<author fullname="R. Barnes" initials="R." surname="Barnes"> <author fullname="R. Barnes" initials="R." surname="Barnes"/>
<organization/> <author fullname="K. Bhargavan" initials="K." surname="Bhargavan"/>
</author> <author fullname="B. Lipp" initials="B." surname="Lipp"/>
<author fullname="K. Bhargavan" initials="K." surname="Bhargavan"> <author fullname="C. Wood" initials="C." surname="Wood"/>
<organization/>
</author>
<author fullname="B. Lipp" initials="B." surname="Lipp">
<organization/>
</author>
<author fullname="C. Wood" initials="C." surname="Wood">
<organization/>
</author>
<date month="February" year="2022"/> <date month="February" year="2022"/>
<abstract> <abstract>
<t>This document describes a scheme for hybrid public key encrypti <t indent="0">This document describes a scheme for hybrid public k
on (HPKE). This scheme provides a variant of public key encryption of arbitrary- ey encryption (HPKE). This scheme provides a variant of public key encryption of
sized plaintexts for a recipient public key. It also includes three authenticate arbitrary-sized plaintexts for a recipient public key. It also includes three a
d variants, including one that authenticates possession of a pre-shared key and uthenticated variants, including one that authenticates possession of a pre-shar
two optional ones that authenticate possession of a key encapsulation mechanism ed key and two optional ones that authenticate possession of a key encapsulation
(KEM) private key. HPKE works for any combination of an asymmetric KEM, key deri mechanism (KEM) private key. HPKE works for any combination of an asymmetric KE
vation function (KDF), and authenticated encryption with additional data (AEAD) M, key derivation function (KDF), and authenticated encryption with additional d
encryption function. Some authenticated variants may not be supported by all KEM ata (AEAD) encryption function. Some authenticated variants may not be supported
s. We provide instantiations of the scheme using widely used and efficient primi by all KEMs. We provide instantiations of the scheme using widely used and effi
tives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based ke cient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HM
y derivation function (HKDF), and SHA2.</t> AC-based key derivation function (HKDF), and SHA2.</t>
<t>This document is a product of the Crypto Forum Research Group ( <t indent="0">This document is a product of the Crypto Forum Resea
CFRG) in the IRTF.</t> rch Group (CFRG) in the IRTF.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="9180"/> <seriesInfo name="RFC" value="9180"/>
<seriesInfo name="DOI" value="10.17487/RFC9180"/> <seriesInfo name="DOI" value="10.17487/RFC9180"/>
</reference> </reference>
<reference anchor="RFC8446"> </references>
<references pn="section-18.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="ART" target="https://eprint.iacr.org/2017/666.pdf" qu
oteTitle="true" derivedAnchor="ART">
<front> <front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl <title>On Ends-to-Ends Encryption: Asynchronous Group Messaging with
e> Strong Security Guarantees</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"> <author fullname="Katriel Cohn-Gordon" initials="K." surname="Cohn-G
<organization/> ordon">
<organization showOnFrontPage="true"/>
</author> </author>
<date month="August" year="2018"/> <author fullname="Cas Cremers" initials="C." surname="Cremers">
<abstract> <organization showOnFrontPage="true"/>
<t>This document specifies version 1.3 of the Transport Layer Secu </author>
rity (TLS) protocol. TLS allows client/server applications to communicate over <author fullname="Luke Garratt" initials="L." surname="Garratt">
the Internet in a way that is designed to prevent eavesdropping, tampering, and <organization showOnFrontPage="true"/>
message forgery.</t> </author>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50 <author fullname="Jon Millican" initials="J." surname="Millican">
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 i <organization showOnFrontPage="true"/>
mplementations.</t> </author>
</abstract> <author fullname="Kevin Milner" initials="K." surname="Milner">
<organization showOnFrontPage="true"/>
</author>
<date month="March" year="2020"/>
</front> </front>
<seriesInfo name="RFC" value="8446"/> <refcontent>Version 2.3</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC8446"/> <seriesInfo name="DOI" value="10.1145/3243734.3243747"/>
</reference> </reference>
<reference anchor="RFC8126"> <reference anchor="I-D.irtf-cfrg-aead-limits" target="https://datatracke r.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-07" quoteTitle="true" derivedAnc hor="CFRG-AEAD-LIMITS">
<front> <front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs <title>Usage Limits on AEAD Algorithms</title>
</title> <author fullname="Felix Günther" initials="F." surname="Günther">
<author fullname="M. Cotton" initials="M." surname="Cotton"> <organization showOnFrontPage="true">ETH Zurich</organization>
<organization/>
</author> </author>
<author fullname="B. Leiba" initials="B." surname="Leiba"> <author fullname="Martin Thomson" initials="M." surname="Thomson">
<organization/> <organization showOnFrontPage="true">Mozilla</organization>
</author> </author>
<author fullname="T. Narten" initials="T." surname="Narten"> <author fullname="Christopher A. Wood" initials="C. A." surname="Woo
<organization/> d">
<organization showOnFrontPage="true">Cloudflare</organization>
</author> </author>
<date month="June" year="2017"/> <date day="31" month="May" year="2023"/>
<abstract> <abstract>
<t>Many protocols make use of points of extensibility that use con <t indent="0">An Authenticated Encryption with Associated Data (AE
stants to identify various protocol parameters. To ensure that the values in th AD) algorithm provides confidentiality and integrity. Excessive use of the same
ese fields do not have conflicting uses and to promote interoperability, their a key can give an attacker advantages in breaking these properties. This document
llocations are often coordinated by a central record keeper. For IETF protocols provides simple guidance for users of common AEAD functions about how to limit t
, that role is filled by the Internet Assigned Numbers Authority (IANA).</t> he use of keys in order to bound the advantage given to an attacker. It consider
<t>To make assignments in a given registry prudently, guidance des s limits in both single- and multi-key settings.</t>
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This documen
t defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Considerati
ons is clear and addresses the various issues that are likely in the operation o
f a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="26"/> <seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-aead-limits-0
<seriesInfo name="RFC" value="8126"/> 7"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/> <refcontent>Work in Progress</refcontent>
</reference> </reference>
<reference anchor="RFC2104"> <reference anchor="CLINIC" quoteTitle="true" target="https://doi.org/10. 1007/978-3-319-08506-7_8" derivedAnchor="CLINIC">
<front> <front>
<title>HMAC: Keyed-Hashing for Message Authentication</title> <title>I Know Why You Went to the Clinic: Risks and Realization of H
<author fullname="H. Krawczyk" initials="H." surname="Krawczyk"> TTPS Traffic Analysis</title>
<organization/> <author fullname="Brad Miller" initials="B." surname="Miller">
<organization showOnFrontPage="true"/>
</author> </author>
<author fullname="M. Bellare" initials="M." surname="Bellare"> <author fullname="Ling Huang" initials="L." surname="Huang">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author fullname="R. Canetti" initials="R." surname="Canetti"> <author fullname="A. D. Joseph" initials="A." surname="Joseph">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date month="February" year="1997"/> <author fullname="J. D. Tygar" initials="J." surname="Tygar">
<abstract> <organization showOnFrontPage="true"/>
<t>This document describes HMAC, a mechanism for message authentic </author>
ation using cryptographic hash functions. HMAC can be used with any iterative cr <date year="2014"/>
yptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared
key. The cryptographic strength of HMAC depends on the properties of the under
lying hash function. This memo provides information for the Internet community.
This memo does not specify an Internet standard of any kind</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="2104"/> <refcontent>Privacy Enhancing Technologies, pp. 143-163</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC2104"/> <seriesInfo name="DOI" value="10.1007/978-3-319-08506-7_8"/>
</reference> </reference>
</references> <reference anchor="CONIKS" target="https://www.usenix.org/system/files/c
<references> onference/usenixsecurity15/sec15-paper-melara.pdf" quoteTitle="true" derivedAnch
<name>Informative References</name> or="CONIKS">
<reference anchor="ART" target="https://eprint.iacr.org/2017/666.pdf">
<front> <front>
<title>On Ends-to-Ends Encryption: Asynchronous Group Messaging with <title>CONIKS: Bringing Key Transparency to End Users</title>
Strong Security Guarantees</title> <author fullname="Marcela S. Melara" initials="M. S." surname="Melar
<author initials="K." surname="Cohn-Gordon" fullname="Katriel Cohn-G a">
ordon"> <organization showOnFrontPage="true"/>
<organization/>
</author> </author>
<author initials="C." surname="Cremers" fullname="Cas Cremers"> <author fullname="Aaron Blankstein" initials="A." surname="Blankstei
<organization/> n">
<organization showOnFrontPage="true"/>
</author> </author>
<author initials="L." surname="Garratt" fullname="Luke Garratt"> <author fullname="Joseph Bonneau" initials="J." surname="Bonneau">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="J." surname="Millican" fullname="Jon Millican"> <author fullname="Edward W. Felten" initials="E. W." surname="Felten
<organization/> ">
<organization showOnFrontPage="true"/>
</author> </author>
<author initials="K." surname="Milner" fullname="Kevin Milner"> <author fullname="Michael J. Freedman" initials="M. J." surname="Fre
<organization/> edman">
<organization showOnFrontPage="true"/>
</author> </author>
<date year="2018" month="January" day="18"/> <date month="August" year="2015"/>
</front> </front>
<refcontent>Proceedings of the 24th USENIX Security Symposium</refcont
ent>
<refcontent>ISBN 978-1-939133-11-3</refcontent>
</reference> </reference>
<reference anchor="DoubleRatchet"> <reference anchor="DoubleRatchet" quoteTitle="true" target="https://doi. org/10.1109/eurosp.2017.27" derivedAnchor="DoubleRatchet">
<front> <front>
<title>A Formal Security Analysis of the Signal Messaging Protocol</ title> <title>A Formal Security Analysis of the Signal Messaging Protocol</ title>
<author fullname="Katriel Cohn-Gordon" initials="K." surname="Cohn-G ordon"> <author fullname="Katriel Cohn-Gordon" initials="K." surname="Cohn-G ordon">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author fullname="Cas Cremers" initials="C." surname="Cremers"> <author fullname="Cas Cremers" initials="C." surname="Cremers">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author fullname="Benjamin Dowling" initials="B." surname="Dowling"> <author fullname="Benjamin Dowling" initials="B." surname="Dowling">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author fullname="Luke Garratt" initials="L." surname="Garratt"> <author fullname="Luke Garratt" initials="L." surname="Garratt">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author fullname="Douglas Stebila" initials="D." surname="Stebila"> <author fullname="Douglas Stebila" initials="D." surname="Stebila">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date month="April" year="2017"/> <date month="April" year="2017"/>
</front> </front>
<seriesInfo name="2017 IEEE European Symposium on Security and Privacy " value="(EuroS&amp;P)"/> <refcontent>2017 IEEE European Symposium on Security and Privacy (Euro S&amp;P)</refcontent>
<seriesInfo name="DOI" value="10.1109/eurosp.2017.27"/> <seriesInfo name="DOI" value="10.1109/eurosp.2017.27"/>
</reference> </reference>
<reference anchor="Signal" target="https://www.signal.org/docs/specifica <reference anchor="HCJ16" quoteTitle="true" target="https://doi.org/10.1
tions/doubleratchet/"> 186/s13635-016-0030-7" derivedAnchor="HCJ16">
<front>
<title>The Double Ratchet Algorithm</title>
<author initials="T." surname="Perrin(ed)" fullname="Trevor Perrin(e
d)">
<organization/>
</author>
<author initials="M." surname="Marlinspike" fullname="Moxie Marlinsp
ike">
<organization/>
</author>
<date year="2016" month="November" day="20"/>
</front>
</reference>
<reference anchor="SHS">
<front>
<title>Secure Hash Standard</title>
<author fullname="Quynh H. Dang" initials="Q." surname="Dang">
<organization/>
</author>
<date month="July" year="2015"/>
</front>
<seriesInfo name="National Institute of Standards and Technology" valu
e="report"/>
<seriesInfo name="DOI" value="10.6028/nist.fips.180-4"/>
</reference>
<reference anchor="NAN">
<front>
<title>Nonces Are Noticed: AEAD Revisited</title>
<author fullname="Mihir Bellare" initials="M." surname="Bellare">
<organization/>
</author>
<author fullname="Ruth Ng" initials="R." surname="Ng">
<organization/>
</author>
<author fullname="Björn Tackmann" initials="B." surname="Tackmann">
<organization/>
</author>
<date year="2019"/>
</front>
<seriesInfo name="Advances in Cryptology - CRYPTO 2019" value="pp. 235
-265"/>
<seriesInfo name="DOI" value="10.1007/978-3-030-26948-7_9"/>
</reference>
<reference anchor="CONIKS" target="https://www.usenix.org/system/files/c
onference/usenixsecurity15/sec15-paper-melara.pdf">
<front> <front>
<title>CONIKS: Bringing Key Transparency to End Users</title> <title>HTTPS traffic analysis and client identification using passiv
<author initials="M. S." surname="Melara" fullname="Marcela S. Melar e SSL/TLS fingerprinting</title>
a"> <author fullname="Martin Husák" initials="M." surname="Husák">
<organization/> <organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Blankstein" fullname="Aaron Blankstei
n">
<organization/>
</author> </author>
<author initials="J." surname="Bonneau" fullname="Joseph Bonneau"> <author fullname="Milan Čermák" initials="M." surname="Čermák">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="E. W." surname="Felten" fullname="Edward W. Felten <author fullname="Tomáš Jirsík" initials="T." surname="Jirsík">
"> <organization showOnFrontPage="true"/>
<organization/>
</author> </author>
<author initials="M. J." surname="Freedman" fullname="Michael J. Fre <author fullname="Pavel Čeleda" initials="P." surname="Čeleda">
edman"> <organization showOnFrontPage="true"/>
<organization/>
</author> </author>
<date year="2015"/> <date month="February" year="2016"/>
</front> </front>
<refcontent>EURASIP Journal on Information Security, Vol. 2016, Issue
1</refcontent>
<seriesInfo name="DOI" value="10.1186/s13635-016-0030-7"/>
</reference> </reference>
<reference anchor="KT" target="https://github.com/google/keytransparency /blob/master/docs/design.md"> <reference anchor="KT" target="https://github.com/google/keytransparency /blob/master/docs/design.md" quoteTitle="true" derivedAnchor="KT">
<front> <front>
<title>Key Transparency Design Doc</title> <title>Key Transparency Design Doc</title>
<author> <author>
<organization/> <organization showOnFrontPage="true"/>
</author>
<date year="2020" month="June" day="26"/>
</front>
</reference>
<reference anchor="RFC9000">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar">
<organization/>
</author>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson">
<organization/>
</author> </author>
<date month="May" year="2021"/> <date month="June" year="2020"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communic
ation, low-latency connection establishment, and network path migration. QUIC in
cludes security measures that ensure confidentiality, integrity, and availabilit
y in a range of deployment circumstances. Accompanying documents describe the i
ntegration of TLS for key negotiation, loss detection, and an exemplary congesti
on control algorithm.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="9000"/> <refcontent>commit fb0f87f</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference> </reference>
<reference anchor="I-D.ietf-mls-architecture"> <reference anchor="I-D.ietf-mls-architecture" target="https://datatracke r.ietf.org/doc/html/draft-ietf-mls-architecture-10" quoteTitle="true" derivedAnc hor="MLS-ARCH">
<front> <front>
<title>The Messaging Layer Security (MLS) Architecture</title> <title>The Messaging Layer Security (MLS) Architecture</title>
<author fullname="Benjamin Beurdouche" initials="B." surname="Beurdo uche"> <author fullname="Benjamin Beurdouche" initials="B." surname="Beurdo uche">
<organization>Inria &amp; Mozilla</organization> <organization showOnFrontPage="true">Inria &amp; Mozilla</organiza tion>
</author> </author>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla"> <author fullname="Eric Rescorla" initials="E." surname="Rescorla">
<organization>Mozilla</organization> <organization showOnFrontPage="true">Mozilla</organization>
</author> </author>
<author fullname="Emad Omara" initials="E." surname="Omara"> <author fullname="Emad Omara" initials="E." surname="Omara">
<organization>Google</organization> <organization showOnFrontPage="true">Google</organization>
</author> </author>
<author fullname="Srinivas Inguva" initials="S." surname="Inguva"> <author fullname="Srinivas Inguva" initials="S." surname="Inguva">
<organization>Twitter</organization> <organization showOnFrontPage="true">Twitter</organization>
</author> </author>
<author fullname="Alan Duric" initials="A." surname="Duric"> <author fullname="Alan Duric" initials="A." surname="Duric">
<organization>Wire</organization> <organization showOnFrontPage="true">Wire</organization>
</author> </author>
<date day="16" month="December" year="2022"/> <date day="16" month="December" year="2022"/>
<abstract> <abstract>
<t> The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-pr <t indent="0">The Messaging Layer Security (MLS) protocol (I-D.iet
otocol) f-mls-protocol) specification has the role of defining a Group Key Agreement pro
specification has the role of defining a Group Key Agreement tocol, including all the cryptographic operations and serialization/deserializat
protocol, including all the cryptographic operations and ion functions necessary for scalable and secure group messaging. The MLS protoco
serialization/deserialization functions necessary for scalable and l is meant to protect against eavesdropping, tampering, message forgery, and pro
secure group messaging. The MLS protocol is meant to protect against vide further properties such as Forward Secrecy (FS) and Post-Compromise Securit
eavesdropping, tampering, message forgery, and provide further y (PCS) in the case of past or future device compromises. This document describe
properties such as Forward Secrecy (FS) and Post-Compromise Security s a general secure group messaging infrastructure and its security goals. It pro
(PCS) in the case of past or future device compromises. vides guidance on building a group messaging system and discusses security and p
rivacy tradeoffs offered by multiple security mechanisms that are part of the ML
This document describes a general secure group messaging S protocol (e.g., frequency of public encryption key rotation). The document als
infrastructure and its security goals. It provides guidance on o provides guidance for parts of the infrastructure that are not standardized by
building a group messaging system and discusses security and privacy the MLS Protocol document and left to the application or the infrastructure arc
tradeoffs offered by multiple security mechanisms that are part of hitects to design. While the recommendations of this document are not mandatory
the MLS protocol (e.g., frequency of public encryption key rotation). to follow in order to interoperate at the protocol level, they affect the overal
l security guarantees that are achieved by a messaging application. This is espe
The document also provides guidance for parts of the infrastructure cially true in case of active adversaries that are able to compromise clients, t
that are not standardized by the MLS Protocol document and left to he delivery service, or the authentication service.</t>
the application or the infrastructure architects to design.
While the recommendations of this document are not mandatory to
follow in order to interoperate at the protocol level, they affect
the overall security guarantees that are achieved by a messaging
application. This is especially true in case of active adversaries
that are able to compromise clients, the delivery service, or the
authentication service.
</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-mls-architecture-1 0"/> <seriesInfo name="Internet-Draft" value="draft-ietf-mls-architecture-1 0"/>
<refcontent>Work in Progress</refcontent>
</reference> </reference>
<reference anchor="RFC5116"> <reference anchor="NAN" quoteTitle="true" target="https://doi.org/10.100 7/978-3-030-26948-7_9" derivedAnchor="NAN">
<front> <front>
<title>An Interface and Algorithms for Authenticated Encryption</tit <title>Nonces Are Noticed: AEAD Revisited</title>
le> <author fullname="Mihir Bellare" initials="M." surname="Bellare">
<author fullname="D. McGrew" initials="D." surname="McGrew"> <organization showOnFrontPage="true"/>
<organization/>
</author> </author>
<author fullname="Ruth Ng" initials="R." surname="Ng">
<organization showOnFrontPage="true"/>
</author>
<author fullname="Björn Tackmann" initials="B." surname="Tackmann">
<organization showOnFrontPage="true"/>
</author>
<date month="August" year="2019"/>
</front>
<refcontent>Advances in Cryptology - CRYPTO 2019, pp. 235-265</refcont
ent>
<seriesInfo name="DOI" value="10.1007/978-3-030-26948-7_9"/>
</reference>
<reference anchor="RFC5116" target="https://www.rfc-editor.org/info/rfc5
116" quoteTitle="true" derivedAnchor="RFC5116">
<front>
<title>An Interface and Algorithms for Authenticated Encryption</tit
le>
<author fullname="D. McGrew" initials="D." surname="McGrew"/>
<date month="January" year="2008"/> <date month="January" year="2008"/>
<abstract> <abstract>
<t>This document defines algorithms for Authenticated Encryption w ith Associated Data (AEAD), and defines a uniform interface and a registry for s uch algorithms. The interface and registry can be used as an application-indepe ndent set of cryptoalgorithm suites. This approach provides advantages in effic iency and security, and promotes the reuse of crypto implementations. [STANDARD S-TRACK]</t> <t indent="0">This document defines algorithms for Authenticated E ncryption with Associated Data (AEAD), and defines a uniform interface and a reg istry for such algorithms. The interface and registry can be used as an applicat ion-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [ STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="5116"/> <seriesInfo name="RFC" value="5116"/>
<seriesInfo name="DOI" value="10.17487/RFC5116"/> <seriesInfo name="DOI" value="10.17487/RFC5116"/>
</reference> </reference>
<reference anchor="RFC8032"> <reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc5 905" quoteTitle="true" derivedAnchor="RFC5905">
<front> <front>
<title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title> <title>Network Time Protocol Version 4: Protocol and Algorithms Spec
<author fullname="S. Josefsson" initials="S." surname="Josefsson"> ification</title>
<organization/> <author fullname="D. Mills" initials="D." surname="Mills"/>
</author> <author fullname="J. Martin" initials="J." role="editor" surname="Ma
<author fullname="I. Liusvaara" initials="I." surname="Liusvaara"> rtin"/>
<organization/> <author fullname="J. Burbank" initials="J." surname="Burbank"/>
</author> <author fullname="W. Kasch" initials="W." surname="Kasch"/>
<date month="January" year="2017"/> <date month="June" year="2010"/>
<abstract> <abstract>
<t>This document describes elliptic curve signature scheme Edwards -curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example i mplementation and test vectors are provided.</t> <t indent="0">The Network Time Protocol (NTP) is widely used to sy nchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modifi ed protocol header to accommodate the Internet Protocol version 6 address family . NTPv4 includes fundamental improvements in the mitigation and discipline algor ithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so t hat in many cases, specific server configuration is not required. It corrects ce rtain errors in the NTPv3 design and implementation and includes an optional ext ension mechanism. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8032"/> <seriesInfo name="RFC" value="5905"/>
<seriesInfo name="DOI" value="10.17487/RFC8032"/> <seriesInfo name="DOI" value="10.17487/RFC5905"/>
</reference> </reference>
<reference anchor="RFC6125"> <reference anchor="RFC6125" target="https://www.rfc-editor.org/info/rfc6 125" quoteTitle="true" derivedAnchor="RFC6125">
<front> <front>
<title>Representation and Verification of Domain-Based Application S ervice Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Cer tificates in the Context of Transport Layer Security (TLS)</title> <title>Representation and Verification of Domain-Based Application S ervice Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Cer tificates in the Context of Transport Layer Security (TLS)</title>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"> "/>
<organization/> <author fullname="J. Hodges" initials="J." surname="Hodges"/>
</author>
<author fullname="J. Hodges" initials="J." surname="Hodges">
<organization/>
</author>
<date month="March" year="2011"/> <date month="March" year="2011"/>
<abstract> <abstract>
<t>Many application technologies enable secure communication betwe en two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX ) certificates in the context of Transport Layer Security (TLS). This document s pecifies procedures for representing and verifying the identity of application s ervices in such interactions. [STANDARDS-TRACK]</t> <t indent="0">Many application technologies enable secure communic ation between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of ap plication services in such interactions. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6125"/> <seriesInfo name="RFC" value="6125"/>
<seriesInfo name="DOI" value="10.17487/RFC6125"/> <seriesInfo name="DOI" value="10.17487/RFC6125"/>
</reference> </reference>
<reference anchor="RFC5905"> <reference anchor="RFC7696" target="https://www.rfc-editor.org/info/rfc7
<front> 696" quoteTitle="true" derivedAnchor="RFC7696">
<title>Network Time Protocol Version 4: Protocol and Algorithms Spec
ification</title>
<author fullname="D. Mills" initials="D." surname="Mills">
<organization/>
</author>
<author fullname="J. Martin" initials="J." role="editor" surname="Ma
rtin">
<organization/>
</author>
<author fullname="J. Burbank" initials="J." surname="Burbank">
<organization/>
</author>
<author fullname="W. Kasch" initials="W." surname="Kasch">
<organization/>
</author>
<date month="June" year="2010"/>
<abstract>
<t>The Network Time Protocol (NTP) is widely used to synchronize c
omputer clocks in the Internet. This document describes NTP version 4 (NTPv4),
which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305,
as well as previous versions of the protocol. NTPv4 includes a modified protoco
l header to accommodate the Internet Protocol version 6 address family. NTPv4 i
ncludes fundamental improvements in the mitigation and discipline algorithms tha
t extend the potential accuracy to the tens of microseconds with modern workstat
ions and fast LANs. It includes a dynamic server discovery scheme, so that in m
any cases, specific server configuration is not required. It corrects certain e
rrors in the NTPv3 design and implementation and includes an optional extension
mechanism. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5905"/>
<seriesInfo name="DOI" value="10.17487/RFC5905"/>
</reference>
<reference anchor="RFC7696">
<front> <front>
<title>Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms</title> <title>Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms</title>
<author fullname="R. Housley" initials="R." surname="Housley"> <author fullname="R. Housley" initials="R." surname="Housley"/>
<organization/>
</author>
<date month="November" year="2015"/> <date month="November" year="2015"/>
<abstract> <abstract>
<t>Many IETF protocols use cryptographic algorithms to provide con fidentiality, integrity, authentication, or digital signature. Communicating pe ers must support a common set of cryptographic algorithms for these mechanisms t o work properly. This memo provides guidelines to ensure that protocols have th e ability to migrate from one mandatory-to-implement algorithm suite to another over time.</t> <t indent="0">Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Commun icating peers must support a common set of cryptographic algorithms for these me chanisms to work properly. This memo provides guidelines to ensure that protocol s have the ability to migrate from one mandatory-to-implement algorithm suite to another over time.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="201"/> <seriesInfo name="BCP" value="201"/>
<seriesInfo name="RFC" value="7696"/> <seriesInfo name="RFC" value="7696"/>
<seriesInfo name="DOI" value="10.17487/RFC7696"/> <seriesInfo name="DOI" value="10.17487/RFC7696"/>
</reference> </reference>
<reference anchor="RFC9113"> <reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8 032" quoteTitle="true" derivedAnchor="RFC8032">
<front> <front>
<title>HTTP/2</title> <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
<author fullname="M. Thomson" initials="M." role="editor" surname="T <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
homson"> <author fullname="I. Liusvaara" initials="I." surname="Liusvaara"/>
<organization/> <date month="January" year="2017"/>
</author>
<author fullname="C. Benfield" initials="C." role="editor" surname="
Benfield">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract> <abstract>
<t>This specification describes an optimized expression of the sem <t indent="0">This document describes elliptic curve signature sch
antics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 eme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instanti
(HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced ated with recommended parameters for the edwards25519 and edwards448 curves. An
latency by introducing field compression and allowing multiple concurrent excha example implementation and test vectors are provided.</t>
nges on the same connection.</t>
<t>This document obsoletes RFCs 7540 and 8740.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="9113"/> <seriesInfo name="RFC" value="8032"/>
<seriesInfo name="DOI" value="10.17487/RFC9113"/> <seriesInfo name="DOI" value="10.17487/RFC8032"/>
</reference> </reference>
<reference anchor="RFC8701"> <reference anchor="RFC8701" target="https://www.rfc-editor.org/info/rfc8 701" quoteTitle="true" derivedAnchor="RFC8701">
<front> <front>
<title>Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility</title> <title>Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility</title>
<author fullname="D. Benjamin" initials="D." surname="Benjamin"> <author fullname="D. Benjamin" initials="D." surname="Benjamin"/>
<organization/>
</author>
<date month="January" year="2020"/> <date month="January" year="2020"/>
<abstract> <abstract>
<t>This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to e nsure peers correctly handle unknown values.</t> <t indent="0">This document describes GREASE (Generate Random Exte nsions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be adve rtised to ensure peers correctly handle unknown values.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8701"/> <seriesInfo name="RFC" value="8701"/>
<seriesInfo name="DOI" value="10.17487/RFC8701"/> <seriesInfo name="DOI" value="10.17487/RFC8701"/>
</reference> </reference>
<reference anchor="CLINIC"> <reference anchor="RFC9000" target="https://www.rfc-editor.org/info/rfc9 000" quoteTitle="true" derivedAnchor="RFC9000">
<front> <front>
<title>I Know Why You Went to the Clinic: Risks and Realization of H <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
TTPS Traffic Analysis</title> <author fullname="J. Iyengar" initials="J." role="editor" surname="I
<author fullname="Brad Miller" initials="B." surname="Miller"> yengar"/>
<organization/> <author fullname="M. Thomson" initials="M." role="editor" surname="T
</author> homson"/>
<author fullname="Ling Huang" initials="L." surname="Huang"> <date month="May" year="2021"/>
<organization/> <abstract>
</author> <t indent="0">This document defines the core of the QUIC transport
<author fullname="A. D. Joseph" initials="A." surname="Joseph"> protocol. QUIC provides applications with flow-controlled streams for structure
<organization/> d communication, low-latency connection establishment, and network path migratio
</author> n. QUIC includes security measures that ensure confidentiality, integrity, and a
<author fullname="J. D. Tygar" initials="J." surname="Tygar"> vailability in a range of deployment circumstances. Accompanying documents descr
<organization/> ibe the integration of TLS for key negotiation, loss detection, and an exemplary
</author> congestion control algorithm.</t>
<date year="2014"/> </abstract>
</front> </front>
<seriesInfo name="Privacy Enhancing Technologies" value="pp. 143-163"/ <seriesInfo name="RFC" value="9000"/>
> <seriesInfo name="DOI" value="10.17487/RFC9000"/>
<seriesInfo name="DOI" value="10.1007/978-3-319-08506-7_8"/>
</reference> </reference>
<reference anchor="HCJ16"> <reference anchor="RFC9001" target="https://www.rfc-editor.org/info/rfc9 001" quoteTitle="true" derivedAnchor="RFC9001">
<front> <front>
<title>HTTPS traffic analysis and client identification using passiv <title>Using TLS to Secure QUIC</title>
e SSL/TLS fingerprinting</title> <author fullname="M. Thomson" initials="M." role="editor" surname="T
<author fullname="Martin Husák" initials="M." surname="Husák"> homson"/>
<organization/> <author fullname="S. Turner" initials="S." role="editor" surname="Tu
</author> rner"/>
<author fullname="Milan Čermák" initials="M." surname="Čermák"> <date month="May" year="2021"/>
<organization/> <abstract>
</author> <t indent="0">This document describes how Transport Layer Security
<author fullname="Tomáš Jirsík" initials="T." surname="Jirsík"> (TLS) is used to secure QUIC.</t>
<organization/> </abstract>
</author>
<author fullname="Pavel Čeleda" initials="P." surname="Čeleda">
<organization/>
</author>
<date month="February" year="2016"/>
</front> </front>
<seriesInfo name="EURASIP Journal on Information Security" value="vol. <seriesInfo name="RFC" value="9001"/>
2016, no. 1"/> <seriesInfo name="DOI" value="10.17487/RFC9001"/>
<seriesInfo name="DOI" value="10.1186/s13635-016-0030-7"/>
</reference> </reference>
<reference anchor="I-D.irtf-cfrg-aead-limits"> <reference anchor="RFC9113" target="https://www.rfc-editor.org/info/rfc9 113" quoteTitle="true" derivedAnchor="RFC9113">
<front> <front>
<title>Usage Limits on AEAD Algorithms</title> <title>HTTP/2</title>
<author fullname="Felix Günther" initials="F." surname="Günther"> <author fullname="M. Thomson" initials="M." role="editor" surname="T
<organization>ETH Zurich</organization> homson"/>
</author> <author fullname="C. Benfield" initials="C." role="editor" surname="
<author fullname="Martin Thomson" initials="M." surname="Thomson"> Benfield"/>
<organization>Mozilla</organization> <date month="June" year="2022"/>
</author>
<author fullname="Christopher A. Wood" initials="C. A." surname="Woo
d">
<organization>Cloudflare</organization>
</author>
<date day="30" month="January" year="2023"/>
<abstract> <abstract>
<t> An Authenticated Encryption with Associated Data (AEAD) algo <t indent="0">This specification describes an optimized expression
rithm of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP
provides confidentiality and integrity. Excessive use of the same version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources an
key can give an attacker advantages in breaking these properties. d a reduced latency by introducing field compression and allowing multiple concu
This document provides simple guidance for users of common AEAD rrent exchanges on the same connection.</t>
functions about how to limit the use of keys in order to bound the <t indent="0">This document obsoletes RFCs 7540 and 8740.</t>
advantage given to an attacker. It considers limits in both single-
and multi-key settings.
</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-aead-limits-0 <seriesInfo name="RFC" value="9113"/>
6"/> <seriesInfo name="DOI" value="10.17487/RFC9113"/>
</reference> </reference>
<reference anchor="RFC9001"> <reference anchor="SHS" target="https://doi.org/10.6028/NIST.FIPS.180-4" quoteTitle="true" derivedAnchor="SHS">
<front> <front>
<title>Using TLS to Secure QUIC</title> <title>Secure Hash Standard (SHS)</title>
<author fullname="M. Thomson" initials="M." role="editor" surname="T <author>
homson"> <organization showOnFrontPage="true">National Institute of Standar
<organization/> ds and Technology (NIST)</organization>
</author> </author>
<author fullname="S. Turner" initials="S." role="editor" surname="Tu <date month="August" year="2015"/>
rner"> </front>
<organization/> <seriesInfo name="FIPS PUB" value="180-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
</reference>
<reference anchor="Signal" target="https://www.signal.org/docs/specifica
tions/doubleratchet/" quoteTitle="true" derivedAnchor="Signal">
<front>
<title>The Double Ratchet Algorithm</title>
<author fullname="Trevor Perrin(ed)" initials="T." surname="Perrin(e
d)">
<organization showOnFrontPage="true"/>
</author> </author>
<date month="May" year="2021"/> <author fullname="Moxie Marlinspike" initials="M." surname="Marlinsp
<abstract> ike">
<t>This document describes how Transport Layer Security (TLS) is u <organization showOnFrontPage="true"/>
sed to secure QUIC.</t> </author>
</abstract> <date month="November" year="2016"/>
</front> </front>
<seriesInfo name="RFC" value="9001"/> <refcontent>Revision 1</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC9001"/>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="protocol-origins-of-example-trees"> <section anchor="protocol-origins-of-example-trees" numbered="true" removeIn
<name>Protocol Origins of Example Trees</name> RFC="false" toc="include" pn="section-appendix.a">
<t>Protocol operations in MLS give rise to specific forms of ratchet tree, <name slugifiedName="name-protocol-origins-of-example">Protocol Origins of
Example Trees</name>
<t indent="0" pn="section-appendix.a-1">Protocol operations in MLS give ri
se to specific forms of ratchet tree,
typically affecting a whole direct path at once. In this section, we describe typically affecting a whole direct path at once. In this section, we describe
the protocol operations that could have given rise to the various example trees the protocol operations that could have given rise to the various example trees
in this document.</t> in this document.</t>
<t>To construct the tree in <xref target="full-tree"/>:</t> <t indent="0" pn="section-appendix.a-2">To construct the tree in <xref tar
<ul spacing="normal"> get="full-tree" format="default" sectionFormat="of" derivedContent="Figure 11"/>
<li>A creates a group with B, ..., G</li> :</t>
<li>F sends an empty Commit, setting X, Y, W</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-app
<li>G removes C and D, blanking V, U, and setting Y, W</li> endix.a-3">
<li>B sends an empty Commit, setting T and W</li> <li pn="section-appendix.a-3.1">A creates a group with B, ..., G</li>
<li pn="section-appendix.a-3.2">F sends an empty Commit, setting X, Y, a
nd W</li>
<li pn="section-appendix.a-3.3">G removes C and D, blanking V, U, and se
tting Y and W</li>
<li pn="section-appendix.a-3.4">B sends an empty Commit, setting T and W
</li>
</ul> </ul>
<t>To construct the tree in <xref target="resolution-tree"/>:</t> <t indent="0" pn="section-appendix.a-4">To construct the tree in <xref tar
<ul spacing="normal"> get="resolution-tree" format="default" sectionFormat="of" derivedContent="Figure
<li>A creates a group with B, ..., H, as well as some members outside th 10"/>:</t>
is subtree</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-app
<li>F sends an empty Commit, setting Y and its ancestors</li> endix.a-5">
<li> <li pn="section-appendix.a-5.1">A creates a group with B, ..., H, as wel
<t>D removes B and C, with the following effects: l as some members outside this subtree</li>
<li pn="section-appendix.a-5.2">F sends an empty Commit, setting Y and i
ts ancestors</li>
<li pn="section-appendix.a-5.3">
<t indent="0" pn="section-appendix.a-5.3.1">D removes B and C, with th
e following effects:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>Blank the direct paths of B and C</li> -appendix.a-5.3.2">
<li>Set X, the top node, and any further nodes in the direct path of <li pn="section-appendix.a-5.3.2.1">Blank the direct paths of B and
D</li> C</li>
<li pn="section-appendix.a-5.3.2.2">Set X, the top node, and any fur
ther nodes in the direct path of D</li>
</ul> </ul>
</li> </li>
<li>Someone outside this subtree removes G, blanking the direct path of <li pn="section-appendix.a-5.4">Someone outside this subtree removes G,
G</li> blanking the direct path of G</li>
<li>A adds a new member at B with a partial Commit, adding B as unmerged <li pn="section-appendix.a-5.5">A adds a new member at B with a partial
at X</li> Commit, adding B as unmerged at X</li>
</ul> </ul>
<t>To construct the tree in <xref target="evolution-tree"/>:</t> <t indent="0" pn="section-appendix.a-6">To construct the tree in <xref tar
<ul spacing="normal"> get="evolution-tree" format="default" sectionFormat="of" derivedContent="Figure
<li>A creates a group with B, C, D</li> 13"/>:</t>
<li>B sends a full Commit, setting X and Y</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-app
<li>D removes C, setting Z and Y</li> endix.a-7">
<li> <li pn="section-appendix.a-7.1">A creates a group with B, C, and D</li>
<t>B adds a new member at C with a full Commit <li pn="section-appendix.a-7.2">B sends a full Commit, setting X and Y</
li>
<li pn="section-appendix.a-7.3">D removes C, setting Z and Y</li>
<li pn="section-appendix.a-7.4">
<t indent="0" pn="section-appendix.a-7.4.1">B adds a new member at C w
ith a full Commit
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>The Add proposal adds C as unmerged at Z and Y</li> -appendix.a-7.4.2">
<li>The path in the Commit resets X and Y, clearing Y's unmerged lea <li pn="section-appendix.a-7.4.2.1">The Add proposal adds C as unmer
ves</li> ged at Z and Y</li>
<li pn="section-appendix.a-7.4.2.2">The path in the Commit resets X
and Y, clearing Y's unmerged leaves</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>To construct the tree in <xref target="parent-hash-tree"/>:</t> <t indent="0" pn="section-appendix.a-8">To construct the tree in <xref tar
<ul spacing="normal"> get="parent-hash-tree" format="default" sectionFormat="of" derivedContent="Figur
<li>A creates a group with B, ..., G</li> e 21"/>:</t>
<li>A removes F in a full Commit, setting T, U, and W</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-app
<li>E sends an empty Commit, setting Y and W</li> endix.a-9">
<li>A adds a new member at F in a partial Commit, adding F as unmerged a <li pn="section-appendix.a-9.1">A creates a group with B, ..., G</li>
t Y and W</li> <li pn="section-appendix.a-9.2">A removes F in a full Commit, setting T,
U, and W</li>
<li pn="section-appendix.a-9.3">E sends an empty Commit, setting Y and W
</li>
<li pn="section-appendix.a-9.4">A adds a new member at F in a partial Co
mmit, adding F as unmerged at Y and W</li>
</ul> </ul>
</section> </section>
<section anchor="ph-evolution"> <section anchor="ph-evolution" numbered="true" removeInRFC="false" toc="incl
<name>Evolution of Parent Hashes</name> ude" pn="section-appendix.b">
<t>To better understand how parent hashes are maintained, let's look in de <name slugifiedName="name-evolution-of-parent-hashes">Evolution of Parent
tail at Hashes</name>
<t indent="0" pn="section-appendix.b-1">To better understand how parent ha
shes are maintained, let's look in detail at
how they evolve in a small group. Consider the following sequence of how they evolve in a small group. Consider the following sequence of
operations:</t> operations:</t>
<ol spacing="normal" type="1"><li>A initializes a new group</li> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-appe
<li>A adds B to the group with a full Commit</li> ndix.b-2">
<li>B adds C and D to the group with a full Commit</li> <li pn="section-appendix.b-2.1" derivedCounter="1.">A initializes a new
<li>C sends an empty Commit.</li> group</li>
<li pn="section-appendix.b-2.2" derivedCounter="2.">A adds B to the grou
p with a full Commit</li>
<li pn="section-appendix.b-2.3" derivedCounter="3.">B adds C and D to th
e group with a full Commit</li>
<li pn="section-appendix.b-2.4" derivedCounter="4.">C sends an empty Com
mit</li>
</ol> </ol>
<figure> <figure align="left" suppress-title="false" pn="figure-30">
<name>Building a four-member tree to illustrate parent hashes</name> <name slugifiedName="name-building-a-four-member-tree">Building a Four-M
<artset> ember Tree to Illustrate Parent Hashes</name>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 <artset pn="section-appendix.b-3.1">
.1" height="144" width="432" viewBox="0 0 432 144" class="diagram" text-anchor=" <artwork type="svg" align="left" pn="section-appendix.b-3.1.1">
middle" font-family="monospace" font-size="13px"> <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-family=
"monospace" font-size="13px" height="144" text-anchor="middle" version="1.1" vie
wBox="0 0 432 144" width="432">
<path d="M 216,48 L 216,64" fill="none" stroke="black"/> <path d="M 216,48 L 216,64" fill="none" stroke="black"/>
<path d="M 376,48 L 376,64" fill="none" stroke="black"/> <path d="M 376,48 L 376,64" fill="none" stroke="black"/>
<path d="M 200,64 L 232,64" fill="none" stroke="black"/> <path d="M 200,64 L 232,64" fill="none" stroke="black"/>
<path d="M 360,64 L 392,64" fill="none" stroke="black"/> <path d="M 360,64 L 392,64" fill="none" stroke="black"/>
<path d="M 32,78 L 48,78" fill="none" stroke="black"/> <path d="M 32,78 L 48,78" fill="none" stroke="black"/>
<path d="M 32,82 L 48,82" fill="none" stroke="black"/> <path d="M 32,82 L 48,82" fill="none" stroke="black"/>
<path d="M 128,78 L 144,78" fill="none" stroke="black"/> <path d="M 128,78 L 144,78" fill="none" stroke="black"/>
<path d="M 128,82 L 144,82" fill="none" stroke="black"/> <path d="M 128,82 L 144,82" fill="none" stroke="black"/>
<path d="M 288,78 L 304,78" fill="none" stroke="black"/> <path d="M 288,78 L 304,78" fill="none" stroke="black"/>
<path d="M 288,82 L 304,82" fill="none" stroke="black"/> <path d="M 288,82 L 304,82" fill="none" stroke="black"/>
<path d="M 232,64 L 240,80" fill="none" stroke="black"/> <path d="M 232,64 L 240,80" fill="none" stroke="black"/>
<path d="M 252,104 L 256,112" fill="none" stroke="black"/> <path d="M 252,104 L 256,112" fill="none" stroke="black"/>
<path d="M 392,64 L 400,80" fill="none" stroke="black"/> <path d="M 392,64 L 400,80" fill="none" stroke="black"/>
<path d="M 192,80 L 200,64" fill="none" stroke="black"/> <path d="M 192,80 L 200,64" fill="none" stroke="black"/>
<path d="M 240,112 L 244,104" fill="none" stroke="black"/> <path d="M 240,112 L 244,104" fill="none" stroke="black"/>
<path d="M 352,80 L 360,64" fill="none" stroke="black"/> <path d="M 352,80 L 360,64" fill="none" stroke="black"/>
<polygon class="arrowhead" points="312,80 300,74.4 300,85.6" fill= <polygon class="arrowhead" fill="black" points="312,80 300,74.4 30
"black" transform="rotate(0,304,80)"/> 0,85.6" transform="rotate(0,304,80)"/>
<polygon class="arrowhead" points="152,80 140,74.4 140,85.6" fill= <polygon class="arrowhead" fill="black" points="152,80 140,74.4 14
"black" transform="rotate(0,144,80)"/> 0,85.6" transform="rotate(0,144,80)"/>
<polygon class="arrowhead" points="56,80 44,74.4 44,85.6" fill="bl <polygon class="arrowhead" fill="black" points="56,80 44,74.4 44,8
ack" transform="rotate(0,48,80)"/> 5.6" transform="rotate(0,48,80)"/>
<g class="text"> <g class="text">
<text x="216" y="36">Y</text> <text x="216" y="36">Y</text>
<text x="380" y="36">Y'</text> <text x="380" y="36">Y'</text>
<text x="88" y="100">X</text> <text x="88" y="100">X</text>
<text x="188" y="100">X'</text> <text x="188" y="100">X'</text>
<text x="256" y="100">_=Z</text> <text x="256" y="100">_=Z</text>
<text x="348" y="100">X'</text> <text x="348" y="100">X'</text>
<text x="412" y="100">Z'</text> <text x="412" y="100">Z'</text>
<text x="80" y="116">/</text> <text x="80" y="116">/</text>
<text x="96" y="116">\</text> <text x="96" y="116">\</text>
skipping to change at line 8183 skipping to change at line 8355
<text x="200" y="132">B</text> <text x="200" y="132">B</text>
<text x="232" y="132">C</text> <text x="232" y="132">C</text>
<text x="264" y="132">D</text> <text x="264" y="132">D</text>
<text x="328" y="132">A</text> <text x="328" y="132">A</text>
<text x="360" y="132">B</text> <text x="360" y="132">B</text>
<text x="392" y="132">C</text> <text x="392" y="132">C</text>
<text x="424" y="132">D</text> <text x="424" y="132">D</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-appendix.b-3.1.2">
Y Y' Y Y'
| | | |
.-+-. .-+-. .-+-. .-+-.
==> ==> / \ ==&gt; / \ ==> ==&gt; / \ ==&gt; / \
X X' _=Z X' Z' X X' _=Z X' Z'
/ \ / \ / \ / \ / \ / \ / \ / \ / \ / \
A A B A B C D A B C D A A B A B C D A B C D
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>Then the parent hashes associated to the nodes will be updated as follo ws (where <t indent="0" pn="section-appendix.b-4">Then the parent hashes associated to the nodes will be updated as follows (where
we use the shorthand <tt>ph</tt> for parent hash, <tt>th</tt> for tree hash, and <tt>osth</tt> for we use the shorthand <tt>ph</tt> for parent hash, <tt>th</tt> for tree hash, and <tt>osth</tt> for
original sibling tree hash):</t> original sibling tree hash):</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-appe
<t>A adds B: set X </t> ndix.b-5">
<ul spacing="normal"> <li pn="section-appendix.b-5.1" derivedCounter="1.">
<li> <t indent="0" pn="section-appendix.b-5.1.1">A adds B: set X </t>
<tt>A.parent_hash = ph(X) = H(X, ph="", osth=th(B))</tt></li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
-appendix.b-5.1.2">
<li pn="section-appendix.b-5.1.2.1">
<tt>A.parent_hash = ph(X) = H(X, ph="", osth=th(B))</tt>
</li>
</ul> </ul>
</li> </li>
<li> <li pn="section-appendix.b-5.2" derivedCounter="2.">
<t>B adds C, D: set B', X', Y </t> <t indent="0" pn="section-appendix.b-5.2.1">B adds C, D: set B', X', a
<ul spacing="normal"> nd Y </t>
<li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
-appendix.b-5.2.2">
<li pn="section-appendix.b-5.2.2.1">
<tt>X'.parent_hash = ph(Y) = H(Y, ph="", osth=th(Z))</tt>, <tt>X'.parent_hash = ph(Y) = H(Y, ph="", osth=th(Z))</tt>,
where <tt>th(Z)</tt> covers <tt>(C, _, D)</tt></li> where <tt>th(Z)</tt> covers <tt>(C, _, D)</tt></li>
<li> <li pn="section-appendix.b-5.2.2.2">
<tt>B'.parent_hash = ph(X') = H(X', ph=X'.parent_hash, osth=th(A)) <tt>B'.parent_hash = ph(X') = H(X', ph=X'.parent_hash, osth=th(A))
</tt></li> </tt>
</li>
</ul> </ul>
</li> </li>
<li> <li pn="section-appendix.b-5.3" derivedCounter="3.">
<t>C sends empty Commit: set C', Z', Y' </t> <t indent="0" pn="section-appendix.b-5.3.1">C sends empty Commit: set
<ul spacing="normal"> C', Z', Y' </t>
<li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
-appendix.b-5.3.2">
<li pn="section-appendix.b-5.3.2.1">
<tt>Z'.parent_hash = ph(Y') = H(Y', ph="", osth=th(X'))</tt>, wher e <tt>Z'.parent_hash = ph(Y') = H(Y', ph="", osth=th(X'))</tt>, wher e
<tt>th(X')</tt> covers <tt>(A, X', B')</tt></li> <tt>th(X')</tt> covers <tt>(A, X', B')</tt></li>
<li> <li pn="section-appendix.b-5.3.2.2">
<tt>C'.parent_hash = ph(Z') = H(Z', ph=Z'.parent_hash, osth=th(D)) <tt>C'.parent_hash = ph(Z') = H(Z', ph=Z'.parent_hash, osth=th(D))
</tt></li> </tt>
</li>
</ul> </ul>
</li> </li>
</ol> </ol>
<t>When a new member joins, they will receive a tree that has the followin <t indent="0" pn="section-appendix.b-6">When a new member joins, they will
g parent receive a tree that has the following parent
hash values, and compute the indicated parent-hash validity relationships:</t> hash values and compute the indicated parent hash validity relationships:</t>
<table> <table align="center" pn="table-15">
<thead> <thead>
<tr> <tr>
<th align="left">Node</th> <th align="left" colspan="1" rowspan="1">Node</th>
<th align="left">Parent hash value</th> <th align="left" colspan="1" rowspan="1">Parent Hash Value</th>
<th align="left">Valid?</th> <th align="left" colspan="1" rowspan="1">Valid?</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">A</td> <td align="left" colspan="1" rowspan="1">A</td>
<td align="left">H(X, ph="", osth=th(B))</td> <td align="left" colspan="1" rowspan="1">H(X, ph="", osth=th(B))</td
<td align="left">No, B changed</td> >
<td align="left" colspan="1" rowspan="1">No, B changed</td>
</tr> </tr>
<tr> <tr>
<td align="left">B'</td> <td align="left" colspan="1" rowspan="1">B'</td>
<td align="left">H(X', ph=X'.parent_hash, osth=th(A))</td> <td align="left" colspan="1" rowspan="1">H(X', ph=X'.parent_hash, os
<td align="left">Yes</td> th=th(A))</td>
<td align="left" colspan="1" rowspan="1">Yes</td>
</tr> </tr>
<tr> <tr>
<td align="left">C'</td> <td align="left" colspan="1" rowspan="1">C'</td>
<td align="left">H(Z', ph=Z'.parent_hash, osth=th(D))</td> <td align="left" colspan="1" rowspan="1">H(Z', ph=Z'.parent_hash, os
<td align="left">Yes</td> th=th(D))</td>
<td align="left" colspan="1" rowspan="1">Yes</td>
</tr> </tr>
<tr> <tr>
<td align="left">D</td> <td align="left" colspan="1" rowspan="1">D</td>
<td align="left">(none, never sent an UpdatePath)</td> <td align="left" colspan="1" rowspan="1">(none, never sent an Update
<td align="left">N/A</td> Path)</td>
<td align="left" colspan="1" rowspan="1">N/A</td>
</tr> </tr>
<tr> <tr>
<td align="left">X'</td> <td align="left" colspan="1" rowspan="1">X'</td>
<td align="left">H(Y, ph="", osth=th(Z))</td> <td align="left" colspan="1" rowspan="1">H(Y, ph="", osth=th(Z))</td
<td align="left">No, Y and Z changed</td> >
<td align="left" colspan="1" rowspan="1">No, Y and Z changed</td>
</tr> </tr>
<tr> <tr>
<td align="left">Z'</td> <td align="left" colspan="1" rowspan="1">Z'</td>
<td align="left">H(Y', ph="", osth=th(X'))</td> <td align="left" colspan="1" rowspan="1">H(Y', ph="", osth=th(X'))</
<td align="left">Yes</td> td>
<td align="left" colspan="1" rowspan="1">Yes</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>In other words, the joiner will find the following path-hash links in t <t indent="0" pn="section-appendix.b-8">In other words, the joiner will fi
he tree:</t> nd the following path-hash links in the tree:</t>
<figure> <figure align="left" suppress-title="false" pn="figure-31">
<name>Parent-hash links connect all non-empty parent nodes to leaves</na <name slugifiedName="name-parent-hash-links-connect-a">Parent-hash links
me> connect all non-empty parent nodes to leaves</name>
<artset> <artset pn="section-appendix.b-9.1">
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 <artwork type="svg" align="left" pn="section-appendix.b-9.1.1">
.1" height="160" width="112" viewBox="0 0 112 160" class="diagram" text-anchor=" <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-family=
middle" font-family="monospace" font-size="13px"> "monospace" font-size="13px" height="160" text-anchor="middle" version="1.1" vie
wBox="0 0 112 160" width="112">
<path d="M 56,48 L 56,64" fill="none" stroke="black"/> <path d="M 56,48 L 56,64" fill="none" stroke="black"/>
<path d="M 56,64 L 72,64" fill="none" stroke="black"/> <path d="M 56,64 L 72,64" fill="none" stroke="black"/>
<path d="M 72,64 L 80,80" fill="none" stroke="black"/> <path d="M 72,64 L 80,80" fill="none" stroke="black"/>
<g class="text"> <g class="text">
<text x="60" y="36">Y'</text> <text x="60" y="36">Y'</text>
<text x="28" y="100">X'</text> <text x="28" y="100">X'</text>
<text x="92" y="100">Z'</text> <text x="92" y="100">Z'</text>
<text x="32" y="116">\</text> <text x="32" y="116">\</text>
<text x="80" y="116">/</text> <text x="80" y="116">/</text>
<text x="8" y="132">A</text> <text x="8" y="132">A</text>
<text x="44" y="132">B'</text> <text x="44" y="132">B'</text>
<text x="76" y="132">C'</text> <text x="76" y="132">C'</text>
<text x="104" y="132">D</text> <text x="104" y="132">D</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-appendix.b-9.1.2">
Y' Y'
| |
+-. +-.
\ \
X' Z' X' Z'
\ / \ /
A B' C' D A B' C' D
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>Since these chains collectively cover all non-blank parent nodes in the tree, <t indent="0" pn="section-appendix.b-10">Since these chains collectively c over all non-blank parent nodes in the tree,
the tree is parent-hash valid.</t> the tree is parent-hash valid.</t>
<t>Note that this tree, though valid, contains invalid parent-hash links. If a <t indent="0" pn="section-appendix.b-11">Note that this tree, though valid , contains invalid parent-hash links. If a
client were checking parent hashes top-down from Y', for example, they would client were checking parent hashes top-down from Y', for example, they would
find that X' has an invalid parent hash relative to Y', but that Z' has valid find that X' has an invalid parent hash relative to Y', but that Z' has a valid
parent hash. Likewise, if the client were checking bottom-up, they would find parent hash. Likewise, if the client were checking bottom-up, they would find
that the chain from B' ends in an invalid link from X' to Y'. These invalid that the chain from B' ends in an invalid link from X' to Y'. These invalid
links are the natural result of multiple clients having committed.</t> links are the natural result of multiple clients having committed.</t>
<t>Note also the way the tree hash and the parent hash interact. The pare nt hash <t indent="0" pn="section-appendix.b-12">Note also the way the tree hash a nd the parent hash interact. The parent hash
of node C' includes the tree hash of node D. The parent hash of node Z' of node C' includes the tree hash of node D. The parent hash of node Z'
includes the tree hash of X', which covers nodes A and B' (including the parent includes the tree hash of X', which covers nodes A and B' (including the parent
hash of B'). Although the tree hash and the parent hash depend on each other, hash of B'). Although the tree hash and the parent hash depend on each other,
the dependency relationships are structured so that there's never a circular the dependency relationships are structured so that there is never a circular
dependency.</t> dependency.</t>
<t>In the particular case where a new member first receives the tree for a <t indent="0" pn="section-appendix.b-13">In the particular case where a ne
group w member first receives the tree for a group
(e.g., in a ratchet tree GroupInfo extension <xref target="ratchet-tree-extensio (e.g., in a ratchet tree GroupInfo extension <xref target="ratchet-tree-extensio
n"/>), the n" format="default" sectionFormat="of" derivedContent="Section 12.4.3.3"/>), the
parent hashes will be expressed in the tree representation, but the tree hash parent hashes will be expressed in the tree representation, but the tree hash
need not be. Instead, the new member will recompute the tree hashes for all the need not be. Instead, the new member will recompute the tree hashes for all the
nodes in the tree, verifying that this matches the tree hash in the GroupInfo nodes in the tree, verifying that this matches the tree hash in the GroupInfo
object. Then, if the tree is valid, then the subtree hashes computed in this object. If the tree is valid, then the subtree hashes computed in this
way will align with the inputs needed for parent hash validation (except where way will align with the inputs needed for parent hash validation (except where
recomputation is needed to account for unmerged leaves).</t> recomputation is needed to account for unmerged leaves).</t>
</section> </section>
<section anchor="array-based-trees"> <section anchor="array-based-trees" numbered="true" removeInRFC="false" toc=
<name>Array-Based Trees</name> "include" pn="section-appendix.c">
<t>One benefit of using complete balanced trees is that they admit a simpl <name slugifiedName="name-array-based-trees">Array-Based Trees</name>
e <t indent="0" pn="section-appendix.c-1">One benefit of using complete bala
nced trees is that they admit a simple
flat array representation. In this representation, leaf nodes are flat array representation. In this representation, leaf nodes are
even-numbered nodes, with the <tt>n</tt>-th leaf at <tt>2*n</tt>. Intermediate nodes even-numbered nodes, with the <tt>n</tt>-th leaf at <tt>2*n</tt>. Intermediate nodes
are held in odd-numbered nodes. For example, the tree with 8 leaves has are held in odd-numbered nodes. For example, the tree with 8 leaves has
the following structure:</t> the following structure:</t>
<figure> <figure align="left" suppress-title="false" pn="figure-32">
<name>An 8-member tree represented as an array</name> <name slugifiedName="name-an-eight-member-tree-repres">An Eight-Member T
<artset> ree Represented as an Array</name>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 <artset pn="section-appendix.c-2.1">
.1" height="288" width="400" viewBox="0 0 400 288" class="diagram" text-anchor=" <artwork type="svg" align="left" pn="section-appendix.c-2.1.1">
middle" font-family="monospace" font-size="13px"> <svg xmlns="http://www.w3.org/2000/svg" class="diagram" font-family=
"monospace" font-size="13px" height="288" text-anchor="middle" version="1.1" vie
wBox="0 0 400 288" width="400">
<path d="M 128,112 L 128,128" fill="none" stroke="black"/> <path d="M 128,112 L 128,128" fill="none" stroke="black"/>
<path d="M 224,48 L 224,64" fill="none" stroke="black"/> <path d="M 224,48 L 224,64" fill="none" stroke="black"/>
<path d="M 320,112 L 320,128" fill="none" stroke="black"/> <path d="M 320,112 L 320,128" fill="none" stroke="black"/>
<path d="M 144,64 L 304,64" fill="none" stroke="black"/> <path d="M 144,64 L 304,64" fill="none" stroke="black"/>
<path d="M 96,128 L 160,128" fill="none" stroke="black"/> <path d="M 96,128 L 160,128" fill="none" stroke="black"/>
<path d="M 288,128 L 352,128" fill="none" stroke="black"/> <path d="M 288,128 L 352,128" fill="none" stroke="black"/>
<path d="M 88,176 L 96,192" fill="none" stroke="black"/> <path d="M 88,176 L 96,192" fill="none" stroke="black"/>
<path d="M 160,128 L 168,144" fill="none" stroke="black"/> <path d="M 160,128 L 168,144" fill="none" stroke="black"/>
<path d="M 184,176 L 192,192" fill="none" stroke="black"/> <path d="M 184,176 L 192,192" fill="none" stroke="black"/>
<path d="M 280,176 L 288,192" fill="none" stroke="black"/> <path d="M 280,176 L 288,192" fill="none" stroke="black"/>
skipping to change at line 8398 skipping to change at line 8576
<text x="104" y="276">1</text> <text x="104" y="276">1</text>
<text x="152" y="276">2</text> <text x="152" y="276">2</text>
<text x="200" y="276">3</text> <text x="200" y="276">3</text>
<text x="248" y="276">4</text> <text x="248" y="276">4</text>
<text x="296" y="276">5</text> <text x="296" y="276">5</text>
<text x="344" y="276">6</text> <text x="344" y="276">6</text>
<text x="392" y="276">7</text> <text x="392" y="276">7</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" align="left" pn="section-appendix.c-2.1.2">
X X
| |
.---------+---------. .---------+---------.
/ \ / \
X X X X
| | | |
.---+---. .---+---. .---+---. .---+---.
/ \ / \ / \ / \
X X X X X X X X
/ \ / \ / \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \ / \ / \
X X X X X X X X X X X X X X X X
Node: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Node: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Leaf: 0 1 2 3 4 5 6 7 Leaf: 0 1 2 3 4 5 6 7
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>This allows us to compute relationships between tree nodes simply by <t indent="0" pn="section-appendix.c-3">This allows us to compute relation ships between tree nodes simply by
manipulating indices, rather than having to maintain complicated structures in manipulating indices, rather than having to maintain complicated structures in
memory. The basic rule is that the high-order bits of parent and child nodes memory. The basic rule is that the high-order bits of parent and child nodes
indices have the following relation (where <tt>x</tt> is an arbitrary bit string ):</t> indices have the following relation (where <tt>x</tt> is an arbitrary bit string ):</t>
<sourcecode type="pseudocode"><![CDATA[ <sourcecode type="pseudocode" markers="false" pn="section-appendix.c-4">
parent=01x => left=00x, right=10x parent=01x =&gt; left=00x, right=10x
]]></sourcecode> </sourcecode>
<t>Since node relationships are implicit, the algorithms for adding and re <t indent="0" pn="section-appendix.c-5">Since node relationships are impli
moving cit, the algorithms for adding and removing
nodes at the right edge of the tree are quite simple. If there are <tt>N</tt> n odes in nodes at the right edge of the tree are quite simple. If there are <tt>N</tt> n odes in
the array:</t> the array:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-app
<li>Add: Append <tt>N + 1</tt> blank values to the end of the array.</li endix.c-6">
> <li pn="section-appendix.c-6.1">Add: Append <tt>N + 1</tt> blank values
<li>Remove: Truncate the array to its first <tt>(N-1) / 2</tt> entries.< to the end of the array.</li>
/li> <li pn="section-appendix.c-6.2">Remove: Truncate the array to its first
<tt>(N-1) / 2</tt> entries.</li>
</ul> </ul>
<t>The following python code demonstrates the tree computations necessary to use an <t indent="0" pn="section-appendix.c-7">The following python code demonstr ates the tree computations necessary to use an
array-based tree for MLS.</t> array-based tree for MLS.</t>
<sourcecode type="python"><![CDATA[ <sourcecode type="python" markers="false" pn="section-appendix.c-8">
# The exponent of the largest power of 2 less than x. Equivalent to: # The exponent of the largest power of 2 less than x. Equivalent to:
# int(math.floor(math.log(x, 2))) # int(math.floor(math.log(x, 2)))
def log2(x): def log2(x):
if x == 0: if x == 0:
return 0 return 0
k = 0 k = 0
while (x >> k) &gt; 0: while (x >&gt; k) &gt; 0:
k += 1 k += 1
return k-1 return k-1
# The level of a node in the tree. Leaves are level 0, their parents # The level of a node in the tree. Leaves are level 0, their parents
# are level 1, etc. If a node's children are at different levels, # are level 1, etc. If a node's children are at different levels,
# then its level is the max level of its children plus one. # then its level is the max level of its children plus one.
def level(x): def level(x):
if x & 0x01 == 0: if x &amp; 0x01 == 0:
return 0 return 0
k = 0 k = 0
while ((x >> k) &amp; 0x01) == 1: while ((x >&gt; k) &amp; 0x01) == 1:
k += 1 k += 1
return k return k
# The number of nodes needed to represent a tree with n leaves. # The number of nodes needed to represent a tree with n leaves.
def node_width(n): def node_width(n):
if n == 0: if n == 0:
return 0 return 0
else: else:
return 2*(n - 1) + 1 return 2*(n - 1) + 1
# The index of the root node of a tree with n leaves. # The index of the root node of a tree with n leaves.
def root(n): def root(n):
w = node_width(n) w = node_width(n)
return (1 <&lt; log2(w)) - 1 return (1 <&lt; log2(w)) - 1
# The left child of an intermediate node. # The left child of an intermediate node.
def left(x): def left(x):
k = level(x) k = level(x)
if k == 0: if k == 0:
raise Exception('leaf node has no children') raise Exception('leaf node has no children')
return x ^ (0x01 <&lt; (k - 1)) return x ^ (0x01 <&lt; (k - 1))
# The right child of an intermediate node. # The right child of an intermediate node.
def right(x): def right(x):
k = level(x) k = level(x)
if k == 0: if k == 0:
raise Exception('leaf node has no children') raise Exception('leaf node has no children')
return x ^ (0x03 <&lt; (k - 1)) return x ^ (0x03 <&lt; (k - 1))
# The parent of a node. # The parent of a node.
def parent(x, n): def parent(x, n):
if x == root(n): if x == root(n):
raise Exception('root node has no parent') raise Exception('root node has no parent')
k = level(x) k = level(x)
b = (x >> (k + 1)) & 0x01 b = (x &gt;&gt; (k + 1)) &amp; 0x01
return (x | (1 << k)) ^ (b << (k + 1)) return (x | (1 &lt;&lt; k)) ^ (b &lt;&lt; (k + 1))
# The other child of the node's parent. # The other child of the node's parent.
def sibling(x, n): def sibling(x, n):
p = parent(x, n) p = parent(x, n)
if x < p: if x &lt; p:
return right(p) return right(p)
else: else:
return left(p) return left(p)
# The direct path of a node, ordered from leaf to root. # The direct path of a node, ordered from leaf to root.
def direct_path(x, n): def direct_path(x, n):
r = root(n) r = root(n)
if x == r: if x == r:
return [] return []
skipping to change at line 8530 skipping to change at line 8708
d = direct_path(x, n) d = direct_path(x, n)
d.insert(0, x) d.insert(0, x)
d.pop() d.pop()
return [sibling(y, n) for y in d] return [sibling(y, n) for y in d]
# The common ancestor of two nodes is the lowest node that is in the # The common ancestor of two nodes is the lowest node that is in the
# direct paths of both leaves. # direct paths of both leaves.
def common_ancestor_semantic(x, y, n): def common_ancestor_semantic(x, y, n):
dx = set([x]) | set(direct_path(x, n)) dx = set([x]) | set(direct_path(x, n))
dy = set([y]) | set(direct_path(y, n)) dy = set([y]) | set(direct_path(y, n))
dxy = dx & dy dxy = dx &amp; dy
if len(dxy) == 0: if len(dxy) == 0:
raise Exception('failed to find common ancestor') raise Exception('failed to find common ancestor')
return min(dxy, key=level) return min(dxy, key=level)
# The common ancestor of two nodes is the lowest node that is in the # The common ancestor of two nodes is the lowest node that is in the
# direct paths of both leaves. # direct paths of both leaves.
def common_ancestor_direct(x, y, _): def common_ancestor_direct(x, y, _):
# Handle cases where one is an ancestor of the other # Handle cases where one is an ancestor of the other
lx, ly = level(x)+1, level(y)+1 lx, ly = level(x)+1, level(y)+1
if (lx <= ly) and (x>>ly == y>&gt;ly): if (lx <= ly) and (x&gt;&gt;ly == y&gt;&gt;ly):
return y return y
elif (ly <= lx) and (x>>lx == y>&gt;lx): elif (ly <= lx) and (x&gt;&gt;lx == y&gt;&gt;lx):
return x return x
# Handle other cases # Handle other cases
xn, yn = x, y xn, yn = x, y
k = 0 k = 0
while xn != yn: while xn != yn:
xn, yn = xn >> 1, yn >&gt; 1 xn, yn = xn >&gt; 1, yn &gt;&gt; 1
k += 1 k += 1
return (xn << k) + (1 << (k-1)) - 1 return (xn &lt;&lt; k) + (1 &lt;&lt; (k-1)) - 1
]]></sourcecode> </sourcecode>
</section> </section>
<section anchor="link-based-trees"> <section anchor="link-based-trees" numbered="true" removeInRFC="false" toc="
<name>Link-Based Trees</name> include" pn="section-appendix.d">
<t>An implementation may choose to store ratchet trees in a "link-based" <name slugifiedName="name-link-based-trees">Link-Based Trees</name>
<t indent="0" pn="section-appendix.d-1">An implementation may choose to st
ore ratchet trees in a "link-based"
representation, where each node stores references to its parents and/or representation, where each node stores references to its parents and/or
children. (As opposed to the array-based representation suggested above, where children (as opposed to the array-based representation suggested above, where
these relationships are computed from relationships between nodes' indices in these relationships are computed from relationships between nodes' indices in
the array.) Such an implementation needs to update these links to maintain the the array). Such an implementation needs to update these links to maintain the
balanced structure of the tree as the tree is extended to add new members, balanced structure of the tree as the tree is extended to add new members
or truncated when members are removed.</t> or truncated when members are removed.</t>
<t>The following code snippet shows how these algorithms could be implemen ted in <t indent="0" pn="section-appendix.d-2">The following code snippet shows h ow these algorithms could be implemented in
Python.</t> Python.</t>
<sourcecode type="python"><![CDATA[ <sourcecode type="python" markers="false" pn="section-appendix.d-3">
class Node: class Node:
def __init__(self, value, left=None, right=None): def __init__(self, value, left=None, right=None):
self.value = value # Value of the node self.value = value # Value of the node
self.left = left # Left child node self.left = left # Left child node
self.right = right # Right child node self.right = right # Right child node
@staticmethod @staticmethod
def blank_subtree(depth): def blank_subtree(depth):
if depth == 1: if depth == 1:
return Node(None) return Node(None)
L = Node.blank_subtree(depth-1) L = Node.blank_subtree(depth-1)
R = Node.blank_subtree(depth-1) R = Node.blank_subtree(depth-1)
return Node(None, left=L, right=R) return Node(None, left=L, right=R)
def empty(self): def empty(self):
L_empty = (self.left == None) or self.left.empty() L_empty = (self.left == None) or self.left.empty()
R_empty = (self.left == None) or self.left.empty() R_empty = (self.right == None) or self.right.empty()
return (self.value == None) and L_empty and R_empty return (self.value == None) and L_empty and R_empty
class Tree: class Tree:
def __init__(self): def __init__(self):
self.depth = 0 # Depth of the tree self.depth = 0 # Depth of the tree
self.root = None # Root node of the tree, initially empty self.root = None # Root node of the tree, initially empty
# Add a blank subtree to the right # Add a blank subtree to the right
def extend(self): def extend(self):
if self.depth == 0: if self.depth == 0:
self.depth = 1 self.depth = 1
self.root = Node(None) self.root = Node(None)
L = self.root L = self.root
R = Node.blank_subtree(self.depth) R = Node.blank_subtree(self.depth)
self.root = Node(None, left=L, right=R) self.root = Node(None, left=L, right=R)
self.depth += 1 self.depth += 1
# Truncate the right subtree # Truncate the right subtree
def truncate(self): def truncate(self):
if self.root == None or self.root.right == None: if self.root == None:
raise Exception("Cannot truncate a tree with 0 or 1 nodes") return
if not self.root.right.empty(): if not self.root.right.empty():
raise Exception("Cannot truncate non-blank subtree") raise Exception("Cannot truncate non-blank subtree")
self.depth -= 1 self.depth -= 1
self.root = self.root.left self.root = self.root.left
]]></sourcecode> </sourcecode>
</section> </section>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f <section anchor="contributors" numbered="false" removeInRFC="false" toc="inc
alse"> lude" pn="section-appendix.e">
<name>Contributors</name> <name slugifiedName="name-contributors">Contributors</name>
<contact initials="J." surname="Alwen" fullname="Joel Alwen"> <contact fullname="Joel Alwen">
<organization>Amazon</organization> <organization showOnFrontPage="true">Amazon</organization>
<address> <address>
<email>alwenjo@amazon.com</email> <email>alwenjo@amazon.com</email>
</address> </address>
</contact> </contact>
<contact initials="K." surname="Bhargavan" fullname="Karthikeyan Bhargavan <contact fullname="Karthikeyan Bhargavan">
"> <organization showOnFrontPage="true">Inria</organization>
<organization>Inria</organization>
<address> <address>
<email>karthikeyan.bhargavan@inria.fr</email> <email>karthikeyan.bhargavan@inria.fr</email>
</address> </address>
</contact> </contact>
<contact initials="C." surname="Cremers" fullname="Cas Cremers"> <contact fullname="Cas Cremers">
<organization>CISPA</organization> <organization showOnFrontPage="true">CISPA</organization>
<address> <address>
<email>cremers@cispa.de</email> <email>cremers@cispa.de</email>
</address> </address>
</contact> </contact>
<contact initials="A." surname="Duric" fullname="Alan Duric"> <contact fullname="Alan Duric">
<organization>Wire</organization> <organization showOnFrontPage="true">Wire</organization>
<address> <address>
<email>alan@wire.com</email> <email>alan@wire.com</email>
</address> </address>
</contact> </contact>
<contact initials="B." surname="Hale" fullname="Britta Hale"> <contact fullname="Britta Hale">
<organization>Naval Postgraduate School</organization> <organization showOnFrontPage="true">Naval Postgraduate School</organiza
tion>
<address> <address>
<email>britta.hale@nps.edu</email> <email>britta.hale@nps.edu</email>
</address> </address>
</contact> </contact>
<contact initials="S." surname="Inguva" fullname="Srinivas Inguva"> <contact fullname="Srinivas Inguva">
<organization/> <organization showOnFrontPage="true"/>
<address> <address>
<email>singuva@yahoo.com</email> <email>singuva@yahoo.com</email>
</address> </address>
</contact> </contact>
<contact initials="K." surname="Kohbrok" fullname="Konrad Kohbrok"> <contact fullname="Konrad Kohbrok">
<organization>Phoenix R&amp;D</organization> <organization showOnFrontPage="true">Phoenix R&amp;D</organization>
<address> <address>
<email>konrad.kohbrok@datashrine.de</email> <email>konrad.kohbrok@datashrine.de</email>
</address> </address>
</contact> </contact>
<contact initials="A." surname="Kwon" fullname="Albert Kwon"> <contact fullname="Albert Kwon">
<organization>MIT</organization> <organization showOnFrontPage="true">MIT</organization>
<address> <address>
<email>kwonal@mit.edu</email> <email>kwonal@mit.edu</email>
</address> </address>
</contact> </contact>
<contact initials="T." surname="Leavy" fullname="Tom Leavy"> <contact fullname="Tom Leavy">
<organization>Amazon</organization> <organization showOnFrontPage="true">Amazon</organization>
<address> <address>
<email>tomleavy@amazon.com</email> <email>tomleavy@amazon.com</email>
</address> </address>
</contact> </contact>
<contact initials="B." surname="McMillion" fullname="Brendan McMillion"> <contact fullname="Brendan McMillion">
<organization/> <organization showOnFrontPage="true"/>
<address> <address>
<email>brendanmcmillion@gmail.com</email> <email>brendanmcmillion@gmail.com</email>
</address> </address>
</contact> </contact>
<contact initials="M." surname="Mularczyk" fullname="Marta Mularczyk"> <contact fullname="Marta Mularczyk">
<organization>Amazon</organization> <organization showOnFrontPage="true">Amazon</organization>
<address> <address>
<email>mulmarta@amazon.com</email> <email>mulmarta@amazon.com</email>
</address> </address>
</contact> </contact>
<contact initials="E." surname="Rescorla" fullname="Eric Rescorla"> <contact fullname="Eric Rescorla">
<organization>Mozilla</organization> <organization showOnFrontPage="true">Mozilla</organization>
<address> <address>
<email>ekr@rtfm.com</email> <email>ekr@rtfm.com</email>
</address> </address>
</contact> </contact>
<contact initials="M." surname="Rosenberg" fullname="Michael Rosenberg"> <contact fullname="Michael Rosenberg">
<organization>Trail of Bits</organization> <organization showOnFrontPage="true">Trail of Bits</organization>
<address> <address>
<email>michael.rosenberg@trailofbits.com</email> <email>michael.rosenberg@trailofbits.com</email>
</address> </address>
</contact> </contact>
<contact initials="T." surname="Wallez" fullname="Théophile Wallez"> <contact fullname="Théophile Wallez">
<organization>Inria</organization> <organization showOnFrontPage="true">Inria</organization>
<address> <address>
<email>theophile.wallez@inria.fr</email> <email>theophile.wallez@inria.fr</email>
</address> </address>
</contact> </contact>
<contact initials="T. van der" surname="Merwe" fullname="Thyla van der Mer <contact fullname="Thyla van der Merwe">
we"> <organization showOnFrontPage="true">Royal Holloway, University of Londo
<organization>Royal Holloway, University of London</organization> n</organization>
<address> <address>
<email>tjvdmerwe@gmail.com</email> <email>tjvdmerwe@gmail.com</email>
</address> </address>
</contact> </contact>
</section> </section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.f">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author fullname="Richard Barnes" initials="R." surname="Barnes">
<organization showOnFrontPage="true">Cisco</organization>
<address>
<email>rlb@ipv.sx</email>
</address>
</author>
<author fullname="Benjamin Beurdouche" initials="B." surname="Beurdouche">
<organization showOnFrontPage="true">Inria &amp; Mozilla</organization>
<address>
<email>ietf@beurdouche.com</email>
</address>
</author>
<author fullname="Raphael Robert" initials="R." surname="Robert">
<organization showOnFrontPage="true">Phoenix R&amp;D</organization>
<address>
<email>ietf@raphaelrobert.com</email>
</address>
</author>
<author fullname="Jon Millican" initials="J." surname="Millican">
<organization showOnFrontPage="true">Meta Platforms</organization>
<address>
<email>jmillican@meta.com</email>
</address>
</author>
<author fullname="Emad Omara" initials="E." surname="Omara">
<organization showOnFrontPage="true"/>
<address>
<email>emad.omara@gmail.com</email>
</address>
</author>
<author fullname="Katriel Cohn-Gordon" initials="K." surname="Cohn-Gordon"
>
<organization showOnFrontPage="true">University of Oxford</organization>
<address>
<email>me@katriel.co.uk</email>
</address>
</author>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+S96XbbxpYw+r+eAq2sdSwlJC15iuOc5ESTE3U8XUtxcjK0
BJKQhGMSYAOgZMVJv899jvtid49VuwBQsp2kv15fq0/aEgnUsGvXnofhcOia
vJllj5Kj8yx5mtV1epYXZ8mT9CqrksNssqzy5ipZf/rkcCN5UZVNOSlnLh2P
q+ziUQKfumk5KdI5DDCt0tNmmGfN6XA+q4cLeXh4Z9NN0iY7K6urR0ndTJ3L
F9WjpKmWdXNnc/OzzTsurbL0kZ/Nvc6uLstq+ig5KJqsKrJmuIdjO1c3aTE9
TmdlAfNdZbVb5I+Sn2CaQVKXVVNlpzX8djXHX35xLl0252X1yCXDJMmL+lHy
cpTspDBg7RL44WW/zCfnaTW1X5TVWVrkv6ZNXhaPkt28npT0eTZP89mjpJqN
v8oXF6P6DYxMX9DgOzB4tqym5XJynpkJdrLiX+k8L9rfxrMcFFWeJn9Lnpa/
5rNZaudDkH419i+PJuU8mhh29bIcZ1Vjd5UuztNsZr+I53txXmZF/iZ5+be9
zlwVv1zRu53p/n2UPIUl5pO0MBP+e1nEH8fTPc2aNHkxS5vTsprXdsZ/zeWt
r+bwTGe2/VHyfJ5WqZlqf55OzYfxRF+X5dkssxPAP9MSn/7qjL7rTPHtKNkt
z4vh14Bzpd3Tt2lT5QDE9rfxjN8V+UVW1XhNytPk+RvY4dTOP8++es0Dwcyj
5WvnJmUBf4+XjSCnQhCm2p5dZjQJzPEoSbbn6a88qQyWpPjAv8qvUvpG9uLX
WzXnOdyeFJANkPosvUjNYIRidqzX4fnRWJ//KsfHRqdVGHc3rZPdKpvDLsNo
uweHL7btaBN+4qtJXi/S0TQL72/PYEF7cLcn4fXv8yqL9wVTX8KH8ZZ2gCAA
5nyT8pnyu89gnbPkRVk3Z1U6XQJxSQ4n5yUQJjPgmN4cncObXxWLepRNl2HY
wyqHU4NtHRRny4sIKHVOH311lcKILfiWBcwH/5yPq/J1WE/rLnnw0uOj1/z4
V9O0SetzmDhrAQdvWfLtZWmO6unBUTQSfJnOvprnTbyNo3KePMnSi6vrMKYp
5zN8phdldqqsmMLpPJ3Q5Y3eHPN388mcv/rqDD+P338KKJQmT5eztJr8evX6
unXMl7M5Pt27jn1AjuRlBpS2YuIncAjUUIfJXldfVc3pvLUOpOJE7+qsAICe
hTGOKngRr+ZO3tTRgvidUaXvfNXgo+XpGB6Mhz86///+33Jxns+y5Pt0Nst+
veZWNecZPzq6pEd7LtTR+dUsTeCyJVPgsk+z6tJg98vyCrD7m3I2Ky/Tq0GL
vjwpi2nrfP91MZ3jEOZ8XF4goQUKdZEBiUm2Xx49IprUwC3PmkfJedMs6ke3
b2cLQMhmlKeTagTT376zufXp7QcPHowW01N+gaWDtedFsl9M62FTDvFf+GNS
XS2YAm7XV8XkvCqLclknX1flcmEkicu8OU8OG/j2LMgTXy+BHgNzz+o1msVz
avoZ3kB/k1WUyXzzZPk6S75OqyptmtZXHVZlZswucvqyyCr6Ci4tfAxQeTjc
3BpuPXTw6V65HM+yl2kDzBhAuff8YLS1Odra2vzs9v6yKg9fjBCKozuf4sOH
+Rlc3X7gX15ejmr6nmAPklR9u15kk/wUloagreEznKviuW5HJ4ICGy8lkbUA
LQEpC+A9X4sX/2C4tYVyWBfUASVBoCur5EVWAUKsZ9ON9gNPyzd5hvd9Bkxz
AVyDdvfNoQfAg807D28/Ozg8Gj0+eHE42nq4ObyHzzzbfhaAtLn56e3PPn04
vDvcvLs5vPPgs3sPh58ef4bP7T5/dvDt4WpILWsksgSp+qpusvntU7hk9W3g
pqcZkKpJdpsfqQXLtu7fhl+37g8X6SKrhvMMiFTaQWyZFjlNQQj7bXaFNAM2
meKoV0BAEfWT72rAshZg71+DvQCqCUyZHIK8RFO3vt9O4U4kO8D3XsNu8jYq
/jtQpcV5slMWRZYuW1/uTy9RZv1+lDzOZk3WflepIYhqj6ssm84B0eGRb1cQ
gTNAmeUYCcdtFpFug0zQGBDcHs/K8e15CuusGE2nGSLuaD61sOxAbo+eAiyd
RGC7szncfACH7+BnOBwm6biG2SYg4AeykS4WM70FCQwHohoIGCly59lVMk9f
40Nw3kgTgU0hXYJ/nJ49SF0AgiKv5zWeX1bUSxijOU8b+AbnyHjUsoDR0skE
PsvxJjWlA/qdACjmy4Lmh2lg4EUJZBKUC9A/kqJscMy0uEoAJZA2w+IuytlF
NoVfgKTPkGDDi06nGiXJPugu41len+OAAF5aFuhIF/k0S2qQ6/GPJpvwhvPa
wfKBezBKAi1PzoiuTnAHddbgumA5MN3lORx2Mi95e0XSXJZuMsszWG5SwNnT
Us8AC2CvSYpTJyB5AgSvaCNjggEIJQkMjFuvAYNAJ5xnI+Rt8FFeJ3DkyzmM
OEgu4QGiUFcyVqb7wu+dKn0MadlenWSnQNFwSUlqWQVvqTsKsQzYM+E4nGiV
AS4h5Bcg8g3hbGDgeQ5n70/bA6gGzgci3K9ZAnjIsINnESgIB7imyxoGqkeC
efN8OgXJ0rmPUNesyumSDsC5l493k/29g6PnL0FVerK/fbifvNx/+vzVfnL0
zX7y+PmTJ8+/P3j2dfJi++X21y+3X3xD+nNdLuHO42ocww3VVjhMgDagD/zH
GPJ13nwD9y05XJ4BcjTwIeIqomQNC5xN4VBcvRyDuIffAYtbLGezpMr+cwlP
13hQPTcXdO7Ls9tW8x65gwIu1nISLlFZyMkAVuLAl9lsNgJqkoMqkoPUoesA
zoiLALoBD5o1Dwh3CPOXY9TGUcCQt8LikymozMu6hjcBlohUT58cIgxmeCBw
zA3Af1uOH+7vEikrIHKZXMKIeFBAx6dJlgJil/B6BTeQpA0Y0N9exO3apfAK
UWgQpHApNagx8FR9NQdtEmXKzMspdOuAIAKqIDoAjWryrB7wSQHM4PrPk3MA
yjjLAIea5TTH2wOUvVyenc9AEiO8bDps16H8wUQLoEy0A2ary9mSpn37NhIY
fv8dPmGp4PffR24XYFdkM7jy8wUsANAfB+pOkqDWB4gOODQErYdQqXVFnBwo
YcyKmyIHCKhQlEUG0wAHNffTZQVulu7TOSoNTGKBnCUgjQ7HcHcu8ylAAd69
LKvXeJEQoGk4TLp8QG+A1leeIg0MXIDUN9nZFV4LoLaAKqwLZ+bQ1vD84XU8
sTWePnsDDyJoth5tMZVnvEPYMVmGzRS0cMKbeTYf4wIElzzaEBXIHC83oJUe
bV4l5WWRhPlHyfOCjgPABdhRTAcAElyHWaLLEc4XhtABvaqA59PtQDqf5tUl
HgMxVTiQGhEDgJUX0xxI5BKunq6QNuNyQz3blHDd42E6hZsrQ6WIu+eJiIob
I6frpgvEK8+JGE1zXOVyxlxscp5nsMqVpBUnc2azAyJEeUX4nhRLAjPMj2R8
uUAWb4BN3GoCKniNSEns5T9B9M8cvIB/8TEgyozcNrCnKXLTtLoiYgBaa4V0
y4CaCFN5ChIPgi6D25A32YyYg1ukANYL/AsQN6unVbnw9I6x4VadGI78dVag
YE37gNc9IsrGsks7rz+MFI9jjhtuQcxFEAMgneGZEboRy8ahYNZvyksAd0Vn
wYDMgNfDKMuGhB1CZSN+IOWGR4ixWIAmyLNBGJcDItDizbOAhcvZy8FhHxPY
KuBP4hn2OGVyDSgKogKzjSWujabMihRpUT/39lpeD8t2q/AKQLGjU+I+cgA0
UhT8e83O4wSjiSxWqDEC/QR99vffB7RTv4MFrBZ2CEMCwmdIuOC0ChetGVYL
YuIkXdTLGYPby4lEOlqbH7kjBF54JkWlnBGZUaqOAG4YER4jXwcnPImEPoLT
pEQ2bs5S7sasPEt6Lob76CPQjpjHPinPrHCissne/pP9I5RNDg6Tw/3do4Pn
z+A9tsij0joEbeR1RiMrJiRkTIfjqpEqTV7bZwTkDA5gFMM5yqKEAus/f7wB
j4IylOy/WcAI38OOnqRj0DbC5oELwZFndHPkBVk/CAJDeK+skDvM6DUS0NYy
+XANh9G/pmv6+pMSjTRI8UEWkXszJxlXxwcNC6VSorCA3YuG6SFSCJBsxFoL
D379kiCGp41SCdxTuviA6QCAEilhnS0BSCXI5SXwSjiQb/ce8w6F4sBAI3j6
ZYbaVvICtgzHvFsC7hXN0c4+7kA+ZH1Gv4N3HudvQCsirhMAB+oYH0lZIb3B
pX3PEKRZ6gUQAWZdB/uHX8OSL/LsEte7pxf5IkUzToL6AuLXeTZ5zSrBZEZE
wuPCpy4sHLa/my/gsjTZm4YQFj55MUNRFT/o7IIeeQFCST7BT+gjuCQLVFqI
7spRbE+ncrRMy/xwC3p3SAJ/EMvkrYNiMlsCzGHBxBezNyh2PoG/nsFRHO0c
ElzGoPoAiEjBbIZ0wmfelqRDER6rs+oV2s5KkkKS8VWTdTBGFCuUWMxyXgHO
EDNTHpsihSkXGUmNJLUWKPbBxZ4Rv+kg4rkoVNuHLKsiBC4yUbJQ/kMSg1eE
TmSOqLcGB7CGhOwU0IRlJaBEeNK7QEFQNkxnRkkA6C9m6STD30/xtOHaEGOW
Q0DOScK/CuQqWnpWJdRGGB1aqI0aipDMCwA6rCZDHVdJLANqBhd6CTiAV2Eb
6SJaeJscpFi9/yCGwqjIzPImbBJ2x+YaBAjwgHwSNjciALKmeEkKC+ACXHKU
ySp8HU4B1kFHxlDBIzrYfrZtLjIhSoAwIiHTE8ZKAmeJ0ra+Os+meZo0V4tM
R1FiQZhEF+kCQFTiZqYoK6ExIEkvQKNBooj0kCWflxnuFqGJiD9bzgtDM3C/
c6SsycN79z4d53X7djM/B94G/5Nb3v/I8xeHewcvr33k6PDV0Ayj9/+BEyJE
ZtqD4rTEm2XvTXQ853cSY0n2o9x35sJOiIbUS5DE/Nn4W08jCzqiSAX/HeM1
Kut0diwy+iFh3xGC3z8+A7WuJuUDBC7UfokV6dfCTL7Nrl4A50I6lBMCneak
KQCtrQXecEmUhNhndCBkY7gsGv2UzpfXjcieAiklUabpkCt5VWTu02XB14zU
JuI6fqo6AkEKCFC9hgUgJSLhECcWRgUioN54/5JHKKYnDNx8ytr8GUuwgGtA
AKflXElwwEeERYWki294HQPnHOgWG6jxojBlRxse3phwJ81aiNp4gL7MTlme
MSQ7PEt3fXux2AZWpCfuvyZMWyBpRWG7Gudw5aqrIUmwODuIG8Nfs6o04xHL
Zygo5T0Wyos2LOSc2dQRUyQZRM14eaOHyJYg+BjBKZSP4fQCjnrAdj2Ufsqy
wYEOxdDFUib8Xvurnxex7HlJIuckwOyC2QdJmMuazGxT0CD93l8cfss6RU0S
PpEYkPjxqg2SbHQ2GqCnF+/AmVFTYAsZ6Xh42iiYTWjEA1Y/hSsmba5IZ4Sk
cYKsk4SD2kv6k7KCrTUFMHTaM3yYzskeWKMEJ/ioazotZ3RkRD12/V0BXPL0
BEd5IXZNkj5gzmo5E7KscGGli6y8pD/wSdESgiSnV4NMf2FvA5EraOGA0SnS
cnk1A/0QBWdaNlnDa3raUzUikSDXTeneKIPFd5F+be9v74FmhUth450neffw
mX1jRk4Ni2HBhsRdUBfk4FCMms3ys9yLzXaFcBRzYK4g8hMXZsFZVKemvk1m
BSHV9lh1HMVN1KwAnON8hux8nMGVztEeA6dRMMUNSFkrFUJ01xs1ZTlP7icR
4SYDgKLigvMsx0MmOmNApwlZr1VtFWwk9ZjJcN22vyihPEnT+uLshO00MMeU
Gel4VgIu2vuNrJJGxCeJruAfTMjRboGH2DCKZej4yc+WZO/rkDc+dJYYyCpl
BC4yu1Qi5OgB38VRj0AjAH2xSd+I8gaUOCc+hxtHKRv5/fA8S2G6oYjbFzBS
WdUb4XCacmHvLaxwiZ70Jnnx7b7AK6/qUSCHeHsNyUCphw4NzlSMq2y3AmFS
D1EsGWjxTZ4ePN3vkV8ITwAxAgskEmjYZotcq6PjOJ+aryTcJWP55XXmpcpZ
eoUaEhGvOmXq9rgEaj71FB+I85URKYBuepYkV95PtFeilRwGB3xPPTs1iyX1
QzHVXOgwwGWBASGg2Xx3eISrPfzm+XdP9oSxCytgRAmHCqyGQW9pEPurvaJB
d0+wG519eDQTIiByTLlZBh0mRrIcs+BEVjbdFgAxPQPWNQRi7wV8REuQ/EXN
wjHYNjUjoCMZJLye3oaniwkpJero9Xc6fEKrBAr+esg2HTKamKOps9npUOUD
WHyVGbkBaHpdiuYDt3s5Z6EH2dUkrc0u7z68l+wayW9b1CSLTW/QhQdAvxAV
bAHHC/98g7eghXnEd4NaT3vAbXURJhLAajJMVANSUaYsP+BZydb7xLAdszAi
5Fa1QvNiChpmTafm9ZnOKQvNuKPrwOVHPDHYQvCrf8GlyqpjkUMiIQjo2CHZ
h75F81CBl38h6iZ6XXDMQ+YJbdmOdHgyWpEDA90ZE4zDCVYXJGiKMWzZIgth
UKUsKOlUeF+bDw2/YmYcmVyEu3gShSETQDjZAReoIPk4aP/ICkknwmuRyLVQ
C4y3FuuLB8W/kLFH8ExrXiBqIxi11wAFRjK5Dfy6vdbABNDqPVNZg0hX+I7o
e2p5s4pR8ozwVJjkhSdm9ppgsFARRFv4fV8xdTfGVIPjIGN6e/2tIDffirQE
AuSxqCLHfsl1mOxgL3pBefluukhp2YipYav2mOEWT1I8im/3HltAwmyIJ0Wq
murEUAK4/nU0iuH5LJc0pSgA6nrOCz3Yjk6zVxa3vPFbDEqM6A1ORiKEQpLk
gejCRLZJ5UQiaI7wqW/w0MVsyQqmmDeYgDGyejMXqL8R7hQgmCDGWJlBRGiM
bUkmy+oiq82pPn+x/yw5ODz8bp8lzaPne8/p+2eI5kzCz9XmvtDTx49IwWHh
wVOULatZ18sx7ZIsx6SRdgXBF7kQVKQ4fHs/jVkREx9VgkSOMCrQKYgiLHPV
ANgpiOpJtign5xGGAV1s6XL+QGILKxvEYyMsOpThGxBMSHiTrW46bzhCOVXt
6bBAXHFykac4a7biTu2zRyLIGSwjonkKVkQKTI7xDp2rOBRfBq4IHdhDjHWg
PbasC2RM4+sQac2z/DSjd7oXzBvQ6dhESRRTbqDr/uiAqeZE6+BzdKsNEZQD
PPaOzN3Vgz3g6d/jcLzk1xEVEYj8sivlKfuzZj9SJs0VJW1YzB56Jiw4GZ3Z
C7kWBjhFZEgOsveS5mPNHGR3MishUNOwwX1ZHDr1jKQllg9BkvN8wVcS53mi
87T5wA/3Nz8zZowga7XgsSzQPkthDoBr+bzjQyCp2Su4gV+g7ZAQeypAqI39
ASWJsAES9uiIlIQCs8CYp9vsReE56CIDYY7UYFI2QzRU4Jck5Y6z4MXWq7X5
mdndGAPMhKIVJbowYYw+dKc7z/5cuk1LAMeDexEVYIxdLJvYqhXTDvXuWDmA
zpw1qmnCuhfb12AtfEPVrb4WSdxrRFLRcJJYdRt9R8g7I1FQj5c1zDrmIyr3
h6PnCDZ/O4mBiUHT4ib58erMK+hEi1sIBOOUOO+iIydsqymAR0718jD2dqgT
ApNDFZlzZhiTtCD9F+05QIbPUuTZclurDFdmgaABXFEsAJM6MoiQC6XEqQ1C
4RZRUqrPkXxFGyRFk/xIQdSvvcSIIkQQdL1ea8hhIVZIT0kBCdm+fwBE69v2
VEbUUZOSFwDxjszQ3oAqJ7GwSEyrgYtemYMh6TiaCocM2qS/Kw/NHWgtrS69
F+eKIwVJ6yQLUhEbvj3hRHstIIESLHQYCV8kM1kQJcnI2lKBhakxw50qegW0
IiIB+0eKY9zEbQMtbiCQCUI1UmWGaMRckHdF0V4xbfUptGDCt8qfJy5z6vVu
EJVyZKoTa8mPPEPx/lPKtoCP5R6QftjiHlbh2vyUxSPme6pWihxzhDyX9b5t
g9148odKnIKKwUMY54yMYmFn4y4j96AY5vK6XmYhKsywjWXN4Vko2SCczaVg
uu5jOwJBh9PFNDFWVogTiAYQK52bD9Qqg7zUU/cQb6Byh2CPx8D25fA6K4vd
gT22r17rPYyDNlcqwg9+rMZYWGbzecU66TRbIAWmcGq8UrKX+3grKOySowwb
yo2LCPDT7V2Q3GcTDdgIKtiFyBJsxIixRmDQ5uQRIO/zMBSVprBnD47SQjVR
d1ivLuIb/2gg2R1PEcDxAlN86PYCsULLDkZfsAcoFbsGmT1Q6MV1r3nj91p0
NY0xVyV5etJbOxnsa1VZUywFanXZolcTVadIns1E+pBoj2nGYmPtAXXPWx3U
gay+X5W683mOp6xGygqEVnQiIzZpvAnRt92D/UM0kRdAEypCJzr20xRzD+AG
Rqah72p2erQ0VcwGI38Z3fhv95/Gp3pXYIU2ZsO0CERBhEBxZZ5ZTj4UFxJD
hAXdGNPn7LSqaFkYim6EnMdof0I+r3rOJCfHVHOJwaRKbXEN5sqZk4WXDeYI
Leon0rLPO+E8p+gzjiluNmWLUMqeU8IWAHKO1BrDSocoz9ftFahiQJF29hJG
M2/FFLSj12q4yAsfSRAiqEYdEhwlvAQLBxu2spWkHMjE0sczoMzEBrB8gWZ2
ChMSmbc9CFvTEklgeJ/loDYazigEhXEgP24VM63MVE+VXPBKUYdG/xLj3vtO
3VIm/PQwJ9rBVk8bzBjvN6X3z0Y75VBXjDFJTKjIyiWowAqEGINOYSPp7Apu
iF1Ki49zAhnxYRWEes+PYpNI6UqU3AdyHHF9JlJwY7OAGfAG2oMooQE4+OQc
RmnjxMvgPyJfMZADIsJenCaaQh4WeITWzTZrmBB+gRHxgdYtrjuHEIPdHDMs
87zNYMihgsvkIyAmKMGCRFNwxuDcsN8IjCJlLb7/iGUL5NMg25BUI75Vdtb5
+EigCedBaKbAa6HsAVNIABpfeRKtonTecGAmKTB4ciGGwbvnNYZf1GWhOpsW
ZOm09CSHvx9T+n5ceWBziyPyv/8a5s3mI8rzOAqOV+eOBCBYbqBO1lCjXhvw
v8mz5/T7y/3/57uDl/t7+PvhN9tPnvhf+Am3xl4m/pj8Tf7N3edPn+4/2+OX
4dOk9dHT7X+ucbz32vMXGLS5/WSNz8mE7FKoB6MwGSgWABVOC9E4Xjxxt7P7
Itm6l7x9+28vH+/e2dr6jBIN8I+HW5/egz8uAa8Gok9j2DD9SaoNHjpwb7SX
zWZuki7yJqWoeoo1uywooBagx6LeI/cowVjtM1wbx2NQ5JGkUUj+TxlyevRA
iXSWZ1hdgDLBGS0J0ThIXWzHI6Ci8juFq6OMztgk4qEdR4yjIN+VM8rroWtI
axTsrzIJW0NUgGOHq4W+pNkskC41WnNILq7W5yvgOpnisC0t5fSXM9B44Zwk
TQpelTtWh+n4jFIJ1KZx/nNJXlBMWUNrSx3yt8hnziYYFpVJM0DdcIEiH+an
lWje3sdHeHc8IwlEEhakg6WermOqGD0SOS11uwgyXFfP8fDoI8zIQ4MQzyhn
whfZWzVUcPf3trWuAaAPBqoklFzDuXYqKdIDt2oNe4D5kHCLii7bBFqHYeJj
cgoJyrNgyOuB170nigJDjBNkENNDpMjJ+dW4Qg91fzAqSaB8bz7berj5++8b
NroDt44YSOlRTOQou9CbSQk2vC6em08kwm96HS03TUmsSxQgVpgExKWkIGgc
PzNF0cjkBgpIGGmX8znolb9mtTmKgS7dH0lIDaB8NY6jTELUW422M7wgQCBC
Zs6UTelyEsEQKixpIJvk+4+BP4hVsIWWWf88my1wBXM28Kd+cz4EDdl2OHXJ
lCSjkod1ZBQ2sauEb7IgGFLtDDyaCtCalYgGGkrVimIrBFsl+oplH+B5pFcR
wjneDFJCUtl6BvdZXHwOmk9nZ9AFKFTphvoF4x0IMdZ6C9jB6qlrPGWtJwMU
EimGQISU1+jep5Rp4pMiU02SinIOaFHGm0xEidPGjEsgmxKQbXj4uyyUbI99
qx38iUulgF+f2VWXTiWPvGatRj0Cciq9mRy5ZA7RmLDXIFra7SbRUSG2tELm
J2lVXYnwj5Dx8SvwKCOR42tM3LZcMGIgnhuRFx00mDHZFbBlEavm7I5hpJ/A
JDQO1aQh1cx5jXzx9q2Yk4f47NDEr2EaIyYasSg3G5hEPjYkkARDplOJN4Ot
rkluX4XJfkT81xyJN3xlQHLAFKH9nAgnTgarAfyja8ucmI5HfSCv0crROlyX
inEKBvoekwMp/JuFf592xyuktKhA+pA4y7IoH4XW7ogom7nzmqmS2L9PlxUt
1ooLwoBws2EggoDrGYidAkWI5eHEcIx9QCsY64GkQvonRizDxmjIgVIRTnDM
BZ+EClQ55qbKDR2KAQzP0lfp4GCF2q/iHVKyQxZcZyb9Zhi7zAh7thHZmjSf
6cOYQFpnmOOFt0YETDgUSdrDtFhycO4HW/U2rOZwWWOatdu3voG1ZJ2Tfjbw
RlQlilpkzuGcbLLm2OcHEs4bYsVqNN+xS9UJSpOSF0xFzAEBKhkVaxGMDxGW
7CJKlsXrAgVqHgRArVdwTdKS+Is1E9ezrMidwANicB8ZqUTkov0sqlyzIFzI
guC8sRc2Y+OJWO2c+z5jAQTN5kSve/I6VHu4d+8BaA/k55FsI2K73lwMzKtN
72uuHeDTU4XQonFewivpwsH3lJYTUmzcacamCs7tS8W5c0pJKARrVoS8L10S
f6MnJR4TKQBFuPuwTQp/kqBNDuFkKH2UPNfxXiH8Heai+in4osJRUGyIv6YC
tAkOi4FOJC1MmqyhKGk2wYnKIiM0GHmX5KcKbiVLIN5TzMnADMpD6VQ8AAmR
jlKqN5EYbHnqV2XIQljhmKczvOzEoP/rv/4raWa1E3PFW6rCgX7dh7qGz+kj
WBhKkuvy4YY8iT9kJNl8JOf99vfP42+2HiVHvDz+Ar7/3YPu70dffo5rYBi/
io7hFR1S8oRP4xs+DclXvQYpB/508ULoiaScJWzUK/7CZSqMcU5VODzGAjgB
pJ6CEmwKJyWF4wk5Xg4FtPGVk7IXanIEYpnPl3OJLHtDv/M4XpDQ1UULkwUx
xwTaRohe8f2uMTOYHFu8xctzvPk1SfUXmBVN1h4SjdFmVxBN4tt2WDpjIhd7
o42KtHuky8e5Nb13g1535kv5HPnzGVdj4CCpkDQsCfI52efoxLYeIGV4+/Yf
qEltboImRTrHlYRxsxFCpSyfYJ8FuonHIFCm1TmddpQchK0KlpCdMi/0ODz3
xYEZnNZS7WqU069Ug8WZTl6dcG0IsXk9uub23L3DkP375mh05/79Lxn1y0UK
5+yB9vdXX+JdOKSXMdeTMb6WG3FIPFXXhhqhNxyo1CS5NXxuKAVvSgIj0MA7
/3FX/hqRAHDjUeHQGLnGPiMgunNg3BEuYdUzF8WEaZISI3Ig4XfQjJKyhCIv
dObjdWA1Fl4l3zR9rENTBYcqLGpGHBlXM7AeeFfS5TD0GMaWMhS8UnLgMDh0
WH6WyKTyOw4ZxhgKX7oA57Lc2oWjIPzBQbrEWk6J7xoFSdA4RJ8LstjglcW5
3ZjcdGkPhZb88rQQ45MAKCZveJsGyZ0BEv17ggNs6Sj0bB4MB27r3pAeubs5
HOcei2yGLkz4G4oEmF76m9Je+O27muIOsEAe/PUUACs/8AdcpvbPb+63R0P+
8b+Y3zp/xV/5T2Etm5syzZaf8IGdKNm0fzy421lKQqNsyQN3/KNb96IX75k/
th7cfdgeCEfZ0rXc84/ejabHF+/5PzY/vfvpva2Hd+62RtG15AVnFfyG1WfN
KMMVf5hR3j5KPhJEGLJh54pLbH2xdih/AtYeyF3alytXr/3u3CuVfcgo1IBu
zGRkbWvLJxZzNS1eHWV9t6QIqekSCOHHdHdPy6XkLWreC12uzTefTT89vZt9
OuW7wfTp3mf3Hn768O7duyN5W9Ov2y9/Oh5HL27dv/OZf0miQ/reu3PfvnX3
U1GEWPQiuwGlBoFsmS7EGGMS+9VOxcqG51CkmaHPyXEKPUqTyoJkfiVwwh/C
mO4lcKRXlIe/jsr2BtZau33bChhwaCvodG1poY+DgLeZEBPwKA+6TZ5H8NhF
8gWr9wWGi+On6xvknaPT/gK+//LL5AGaGk/9h18kd7kWXJXmFIyIYQLAGddv
KWboSpMWR+ERbm1gQTn56gu4vn//u3zjeOHPC7Fo6ut1QqrPwMQp1EIyOXoh
RWy84rcNH2Aex7u8SP4GR38XC/gBiQaCKqMPt8gUX/OW8Mn1C1zRw43kky5o
eIpdOuH8NJD45JLy6k85EOkcqLQmeTKuiMwYAfJL3Pvf/gZz/j1ZJyisP/x4
nZ+8fWcDLvidjY0VkFYR0vPMy7QmGxsaAxjAVQbaEKiLLDMgKknJu1hu81gU
1B8vjErJkqAUoYHr0gEzvQKpukKRmguXGJEiwVwIllTFGiQ1Bxo0gE24fBRb
qXF0ZwZHLn2KIV8+O55C89AqCyIAqMzpBDU1VFin2Xh5diZu+kXZsOGGrUAU
tSQ6ndTmwnJ3rVWJv03L6KWcB5BkVQUAQAeXY9NFEZY1KQutmTSZLFkB9LUi
kufwGOfLo9mBTWBsrcStLdj0ILq3Gs1bVrJ/HAz3Rr4KempCYVACPiiMwZKV
4BpIfBbEYE/BHAps+UTMZ4qFRI5BPd2OwwEO+dlkfftwIzEle+o4cLrPgk4e
tRBWFLxXoL2y3yIaYkQLSPa4yuFVmHlPZ4anUUKJcnvSeamxGiFOow6kLtSs
I8gzUFAupzLxGOFyyJXLGGfRRlfoV3uHIyDicXzEUIBnTFO//+70qJgfADal
k4aTX3x9orJy8K9PpEW3AgAba3h2EULiH0JAuwBRPVF0LaXOhgumZYq3zy6o
hhUfeToRh1lYCG7rcxSfvVUVn9yjNfwLM8qzNwvW+cmsOENqcKW1J4MdBhBS
PrvqBUnyYSBBmDM9mqDgqwUQUs2YEmDhFcmLZagWFRv5yff2hg2+bn372/0N
dP3W1iW8+gWPMnWyrgbKoyeHGwQo14NlwSthymFqUTpjsxUHQjo5d1FMEeAB
lvWUggDe5SgsmZdrp0V1N9XiAw5fx61Yv6Hij78lpHJwkG8R3RS9KL7KVP+U
JiQKT0CDGmfYzMGJmjn2IfocoYoMxQDcQ3WknhyqeyYzb1MKnvrd6kC2MESc
B48qkfbedp1C8/hbOLJyDnVmt8Z00dniKgRBOEAUXfQGVSWZGcGCpa8nGJVc
K8oioT3mNMZjWtwx++mPKSSBvaV/LJygHUzgOsEEuFJQCimc3Tr3sW6fyqzk
ieC4AmtdcrxaNr6GiIKB9zK2rpMUYMG9+htRyJ4dL/TYeyjYcE1Wm3f3m/F2
YHI0LOjztlhueNEcnL8BHBAh06EIN9AyVY4r+gqMeVVmScqilxUlk/A4ZAyO
4w/sVmGxj32FEHqBPx/4UduOHhunRLKX60YBD7qZSzGn4i3VmFKgeIqmAs97
fGYtfy6EWgMnWBPg5S6LHMs2oJFEipW6ogw3g+SqlIvB8sHAeKcN+l5XnmY6
vUhFkM8rtzpQpOfI0oIJytiTbLxzVigQSeI4JGUct8I82EmvUR42sIN9T1qU
kesp98ZmkI+hFVghcQc0uTpkj72vujc+AAkbZjgIYiEu6uUS5oOxJT0xA1oI
gyZjj2+YijP42KmJwRIMPHSMa+FeCr/sHgzHV3hxmMiLpUA+ZYTnlRDEaI9a
zjIEacRRCj6twReAIkcORaxIwqfghaKAROzyJrxPrEGb7yWZuCnIsKzi72BA
rforZzWvs9lFK2iCAoNsIYhOVGVahUNXuIa6tJWJs4EdSySHWhgzdleqaDH1
gdux8EzsSktrg/5zlcWMeRRipCjwhjJfU1vCQuP798juv6xZSiekIeeO5xwM
jLwRfQ0Y0ojtj2m0JgKdf9wepguY7oMuGXP1CbhRZmXmqkQYYeRW4dYa+9oJ
TyeM8Qdrh8FGCwZrUOeflRPNgjDhOiYrKj7ZWDIKwSC6RSsSAWGxokvgvZE8
xFXiMNiV7phJlgqxSY8cUgjrWz8Ow2qYTayIkUhVhPCTnp3ZsvBEgayn3kxg
wtJasTwykaNwGp3hdgduoRw0Shk90SAffZTsRsT80McQ719I/WrlSV2an6rm
w3X6VEGyUkpzTtkp6MzHRyquUyd+djGhUWkg12MIlZ8RGUlHoxH+MxytfvK3
jiH1xkf9v+/xaDsN4Yb3Xr3TFEQ0NYn7Nzd699Vc9zNyv/3sC4h/yEASbH8b
Lds/c4bdB66I3r1NJnIYqe/nPbZ2m23tK0bqQP66cWSg5JPh8EvJxNJjwE+i
c6EP/KU0n36S+IFu/7Gt/awD9Y7zPjD6mQfqH+e98OhnHGjFOO+HkD//5m6t
+u7dTw1/br3Pbbru0fjfP/XRd7v58d/X0MFbER28RSbht4/UMaSWS6XEUuBe
qTj6hkgUtOVTRLkzGq1RBFBTsSLnQBiTTyuBpXrBSLswRLZF07+BLCraZGDm
I65tWX4MRF+O66yJJV0MAgyx8RycMaVWAJMmqgUzSg7Q2EKFdsmkeGwzXY5F
3I8+4+3HFjCuMC317E2SkTXagLJcczK2S4LCI0VT0HFBIYRqiTk29TmsVUE/
2hhYTo1vhGlRqU8kTCNjYxMDVJXOddhx8vYtDTiUGgVD+fL33zcGkq8tnrwk
IdvxsZEs2mp+LEL78jVaXkTrpDbSxFLCY/3AWvwhGlZcEC0DE9VSoYgXrgtO
cgoNSiZPTBaLrBWmW4zI6TIvIHWoVBZNrPgZAu4TLvHEeovBdG+ITuIwcHQi
SPI3aXOAol6jwL8mnJkRqZQGVse+boTPboryr9r3LzYpUI6jDyPr19DpfOU4
tahmnEIW1O3rrpJZNKaZmBYa0XQaNFlr5DWGKwnZYY8e1T8oaDf2zVsYR4PC
ftJyDHTUNsW5OqORWe16nWWSO4AlAq+KCWrcYVmU553zRVXdTYxhspmgXlPk
COuH01YdDs0fYLOVL0qgVUJ9D5JVtf8lAZ+xixcvj0RVq8ZXvvCp86Y5nwAw
0JojTAy0ako0AkZjhsYpVIfTmWIhlnpShAlX6tQnTKKGN+i1LGeoIzO4TMcr
fQabc5AxjTrlsD93OvLVLEixVURRyzsWTpf8mbaB7aa4/D5jnsYo4NHKOTGp
mVLmFIXikyXaOL4MK2t8zJ19lkrKooZCuUJtC4Nyorba6/U1m+7SZz1xZGjQ
nlwdK0qELxGVIP+4Of6BT2qIrskM69n4ifnDcwxp9I68XlOS5hsqXEEp3Je8
T+8X3X+TTYI2KKBj5W6e/gttlbbOCfv989NscjWZ2VQwdl5K1WdZzcDcRrwY
/pz568/hjaj0gLf1mYA5nx7iyz5kGb74sm2GU2rgqZVdd52saWrOGmXZinHA
5xUp3GI8obqr65j4e1ur+9yWxPwNNYB38q+4CEIjFsbpIDmXvjBuCXdg1iFJ
lOUjBkx1d7dsddEdD83bXK0Fxi6pRdclXxqfdDzOQv1lSvWaUzl8bKvDWT9Y
ya8k8x3Zgqdumi1m5RXZHbmkHucNhyoZ+dl5k5ylIqhwTKspCEu9CpzMKMdK
rVUSMuVPfOc52PVsttRytvgmyBFhH/iAUk3XZzjiQlNkDKfWrdQ6hH2UbJXU
PgoE2dAXhl35N6X2sKkaGcwOd1/g626L4UVZkGrbE9OgMb6xAU+WW1ZXzlNn
4fx7hyroAcbL+0MMZwARb/RuVpRVP20//gcMoT/XKS/9PyONBbwF2o38XGPg
WTHtn7SY1g+lObrt9sc77Q927R97eoT6JXcoc501vvcHqMsHjNn+wDE+6QvE
vPbny551/Bl76TwRNrfzgWPcuLn/tr10Pgib2/3AMdqb+2v2IjaFj1pkRo0M
u0LCtgfJDoupu6vIGemxehvQ+vD2LfsvhW4RCccU9EvhxGFKLE5rBrMaAg8R
XHjiEhGny3Zwh4TiA6nlkTu8aOq+xq7TIIah9mnrZWBggpaRoVwFzt/Rimez
Mp3W0UJRFZMJKJXAmUL4A4wfkNw1Ypha2qTF5sWFaLRXrg8xrmA64LZso5m3
hPwD1LHr0s7QEVPJy0yFBUgqUN4YvOveW7NO0vEtFFC8tEpNFPMmmncDeyNi
nU50IgOlRI1SMuCm5ONp7W2cYkit6sGdALJpmVEhB61i1ojGKHmTM420ijxY
mjoGXJAiTnkVqjPlWphh0N4jPgVcFrV3qWAi8GK0xkDUntg31nri97R8JUsU
OUox8B89aIreelnVFMn14pss0dSk1y9EKe+EYLiWimRw4SjeKK0IS8Jyd2ON
s2VcEFdo1BpTxRVqEhwFJo29mBM5dCM3LU0nfYVDW+U/KKNEP718ucWVDU9u
c2T+vp8tv9ef/JkZwjCwQZvgXz/E39+DH39ywyr+hI280xBAv9a3h19u72x8
8BB8c1Bz0jE+REBps8U/CRZCDtZxfx8yxCetZX3YKt79nf/Jh/peCN7388n/
AVj8CUMQOHcQnrsbHzjE/+g70npIr8zujVfmXTZyw5VZuYo/YSPX/vkXHepf
cEfee8Q/5ZqpCmGk/Vh9wCApiWSMZHO1j4gIjTrDIToEMby18YIeiU6xUEby
mClDhUVqL1M0gW2DGNfnxUB/kMrwcYAWVz6kvlm0HLIreeF7hdRehxBlNV7q
vkAaEseTNAM2EXMianYkdT9YWIYtGdUKpApl/6iqUpAEnTvC1F3YkWRivUP5
jqgzaOhITsHwAshFVuXlVAulSJOsVYbZHl2FKiZRhBoJ/GR6joytWhMdlobC
o/TT5khWNiFuUJqrfalw30Wtx73IHOyaaFsurBlcTWq8h2BO85lrbZu58Td1
9YA6M/AyXi/vqVVBXEuAYH0aajYEmEeFjFOsUTyNUkCC57WOjc4KU45Bg1mk
lYy3fsPpf9dqxi7JUmrupHM6o7pJFBl8gbZZvCXY2iLFAD0ErFEtHLa2o0Ri
Rtyge6ATnXq6iOomM2GKS7MkPKHsUi5Vqwqg87orLf/U65bWlExVR7jUUCZm
Zl/vJJ2Xy6LRJTt1+/G261FymOtBag0V7OniMUZt9XktNvVUkqTdxDf3sQk5
cIDFFM3P5M4jE/dpxbH3V+w4561qNYSKq5K583KJ2INtNq5qbjI5B1SAETEV
rY6KDgz6TemkqgUcJ7MCH5OiMiv27ZdV80f9XDRzrajlIuQe8PpytHJgl4j+
otcahylh6pwwYSo9V9qrVHACHxiriwVdjZiPkTKJkdLcGC3g5B5q4YhPR1uU
3rw6jQ7dKlQ/wY8RogpYAw2lnNRZoilKoZrRBDu81dw+qESvyUzMLmnBFCRz
IR2KA/GHUljDQAf/xyEu4UP24/tmy8CPnBQqGEUFgnvSKkO/gSm3YKGzjz3m
cHcdt5LDh2m/k3RJJjROlPRb1PIIYatAy6mQCcGGk18p9tnhXCF5mu7hmLs1
y6FKIWgOi9BrhAvzliQ63+/2Xmix7j/qmtCfazR+iYZKkh/DNx2N/8/Q9ntk
PL6N66wrvefb7yPCv7+4Hq/sD4mWf0yqvFGgvHawPyaOItRE0AZ4vK8W/4e0
rPc/sXih/2tPTHUHI5K1dIedkJ4T4m1QDAbpc2ASNFDJ8OEolHJIoiPnl6bU
2nLGRluWW31jHNY+ttWErAkiXu6r3UqRmeRUKbdCOUNlo5EG8xGqM081XLLq
ikO2pKW2UwAlxhRhplIV/JoIqyMHCk5vmBaqCyw1tJvIRMXJUndd4FNvgIuJ
MkI7dxxRIv6TjGocsKAk25TwCwlHsgPldWxHtpFBTnOKQvSWKSQuIRQqTvfN
556VjWeqVFM745e0QA+JPFQLisOHPDxF2mWZLhWQoWPpIkeJwEpPn2vnS0xz
UYVL8gxVsliU2FmBm29hd2ANQHHjtM4noXB6/T+DZ/5FLLP1J6PmCg5649tC
M2GQHuJ+w9s3WJ7+4n23/ozB8IGsQ8Dwv551GALZYh0/CnGolUXstIgvkmhL
L0BpoLhlDZDTZqOcKshd5z+P5X7qH1xRVT6fC+wHYaKBDeEw1bhVYamTz8ga
taVT6otVDd66cJFASotGDKDxuu+VFhKTdLT4UfFaTjQOypb8xpgvGIlsXxhC
VaeqMLT0H1gA2i1CYnVqDGYTJiQmZlyNUx+H1LjOnv0+TTCaD39DthNXJEm4
sKC8h4vOTPkZ4QxqCarUj2katGsPJpYgsNRLZPqRiLVELT6qIfFLIy2QZSuR
CwtFftM+RrIdwRyXKfvTxWVOUgxwMphGXiZ/uSyWg++odrHa/MjtT+AvOOuh
JFao7FHd75hfK6anRjOXMeiVDjGEmInXF0/ZV3XEcqQs43ARblwbMDfgWxKS
l1BNwUqDRqXX4r9jayGqb9kuACtILt256Y6SwVUjQlfkImO4BvFjjHEQs6A1
1YZXyAQ6vpKKeqy3r7VayK6NtOqeNiuxKeMU8E9ySDvYm5GTiwi0TMYuji6I
si4GPn45ZRMULqlcZMWaxo1TywBeAt3LqRtfdYKJsethWlOrtwXaw2pqmUPn
0l7pCINtaGwMPo7jbVI1jSSJpU++v5GCChcySsiAjJfI9QI6EluJRLLE2iuS
rmPQ0IazidGhk4BtZeCLcuK7USM6lQYlHbl2Pr213aNhVYeGtN0GWUDnYjnW
26q/V2wwu/8RzoM2IGAYqL1G/AlI5jo70zaifOUxJDwQCSIYYpXhr0Io+49x
CvZ62i6UjSuADQwv8nSopzcU1YctZUc37VPJmoSBtxoutzUS6U1Bza2dBr8E
8uQ7V7TKAPyobd96sYOl3r9G3vU//x02onDw7//2+xmFunNfP9m1K3s/0a0V
g/JXi8si4QJ/+XHj/7CgHy/lf72wHTOZjpv3WlpPblSVzDHbyeVNl7OgTI7C
xcuM239isl6d7Iivh7ohgaixHcwzoadstz6SpoTxYjixTBoxpV4gBH3f5YX2
KyXqTOIS+w5HyTeSqIGknMwsINBQ8UnhN6dLSmCC2V/L4C4qnsDVeTJubBGX
m6CkwkkFAo6v+UEGdkohxPBUk+e4qLKhZAsi01t/cfjthogDIcdPCzR6Y0vG
TcfF7uSigj3UX0zqyEuJqdMlOXa0ltN2JHer+0F4oeOX4S3qEo6tcfEwXlTZ
IS0TqyZ4I9Q6ZTLw+mH52GXJdHZCDoqDxIsK7Jjz13gk6+MddLNzaDEo/zoa
Cb5blFXqt9hNtYq7nnDGhQAae0Vxu4onOTfdDV28VPpx2Kc7BXFFgwKU4WbU
W14Uh8AfTSk6XEd+Ghq05acuhFr28u3p0o/Io9H5hwosBl1gcIflRT0CSKHF
erlA/1lNxdqoVzlCJc9s+ymu5hTETJXJNTdHK18u6tfDKsPwBBA3cRv80Rjg
MTnH4pcvszg9xk1mZMlFNDQlZnxwSFgBmVvz2rrUIunYcVF5qrwD8J+jzxhu
zw5NTU0wsRRyPKakfnLSuS/jV+VnOTaiUPd9VGxuXUMRMpgNzYBF9JIPi8b0
JbL+Un7UwKsHPvULqUMweZYzzW7G+kCpPTdA38giyJnj28c/FcOtX5yQ4+gf
IPwAaGyUGH3+yrz6iyHm/OnO8U+bMlx/6ZHf/JewovUlKg5f8FlvhC/7fr68
NhHn2i9frfjSLxkg4BMWPO4pFzLIZkKq1xJkKH3wvBYofaFOAeQWKIztASi/
XQeUa4d91fulPcdPtsKiVwGF16NACRfCwiNySc/TK1a0J+dlKaFLddbCybrF
4rx5y3XNW4MkkAak5EYX5Q6snFDamsExLyOydlKccNa25U761SevT9StMM3m
HLrR2JAsoRMuIp1aoZAHkHB23LUvaREeOAFaV4Uy+qzDX7m4t1vtJ7rFHqXp
kmAn4Sih31e94j63brPFKWNv27gGq0bXINXN33m3QPTVHxy0H4lHFodfD7d+
6b73ofP99vdrANOlhJ+87pIQtkQEIoJ/E7MXGUpsYSBnVTNsAU6j0T36yNda
ompHu9x8veZwGV+HkTL712w+t/R7IjmPmFVcWJJrJ3sZ8dTZPqlRWYCcY4DY
AD0X6dUPU0x9O0VTkNmaBEwnUSnpYsp3cL00HoslM1vRRVNuqHsGJ+voBWlF
Jb60Oxf51JRxs4NKqfjglaNqkqHaBVUpMA7JFjMPEYcRlNIaSzj7Yhsct1g6
Le3hhSxtOKKmUfY8tox7ZjVim8bEGZBoegNPfWsbkvBOZuXZ+rONE1NUikAL
KyHgDGzbexzk5Nlw68RFT5MMrvZ7NAR3WpJyundUS1i734Gqs87k9xnFwaGY
4ruitMoviGwjLUvkZHz6vCIJypStQ4Tpc9CYVvrNpVeYD8hbmBaJqILMZi2H
NEXJoczkQ0SdCZrcSOJcK+0MyvUB6h786jjhMeEOBpmlk1AhhLLr4ZXQrxrP
BhPi2fod3fy4xzThueSC4WqOC2xbcYzVIvE3urXuGCM4j1EBwF7G1AgALlA+
m1batTlNjuEUYeHHzGpB88o+R2d25q+p4weYHS8ruWISrJpN4AVMHbuMRk6O
MfjymD/SiSi+UT6z60QYHVdl2Rw7AitTHbtmWQEv+ZgiS8WFYzeHwrHTRXAg
Mr/H+WvHqINhzBl8cswHSCvwEXL4163axQDCxZkX8T10g8QPYfEAlHBo6e5Y
kjyxBLJs8jTMQCdjhvTFXAAA+jvV48Da2uIb4/ek1Vvd+/goeUZ9S6jaNOIv
Nm859tF4XDDaqzkMGOyRCA8zYRCQKMnXcaWONAU6X/FC1unAsNfdsYZoyBgb
XKG+qS3IBPrYU8LOgYSf35LpXKASFHhMCE0GEQGnSICpLIn3QI8NaE7COee3
I5vQSejKUZFQDAsWxKypZV+ybvsZOUZUffEYydM+JZXSOMtaswJsa3I6VKBb
pMGNQW+TxwcaND6QuN8ZaJFunM6o6oV9khd4cuc/pie4/wtmY1oPk05tCowf
HpmqbOpCv0SMFS5ybBV2akAUXrAlVubLWYMVykU15xCVVhsMCRK21VBioaBA
VlRWV9xXvSxgOq5Rq1V56BhPm2HfXkHpDXmpePQKGfmWYIzr3eBT1PBVccC0
u6GzdEJTEtIMnKjUU3zW2vi4GS0uxjaZo5duEQubBNGCxsTtOa4+X6XaULLN
DPxgooHTxFLJI6g+4jnC7gk0NDssqfFt7W0bOELrCw02Rpug+Gko4oey3EsX
6jX7K2vqz/gGZIgWVEy1EMWilTzMJbQc8SeiufImdzos2/hB4BKfTk8asuCK
oz1QzkwHv1LuiItUhRbdginxjLouJ1TEx/netPWglUdABkAqwUw2ukkI27Y1
wT9qc1OillK4x5MbllHb0i/fJSxijybcN8fJOsDyWJIj8IONAZuCqPRWk5xs
ngTmr0kIeLGTYbJ1ojeaicw6X9d+ArCBXJJYSpc2IMODD9ann2xt8LiM+ibh
2xDIULFs5S7FeHw8huv6GvZoKhUANlBrgQ0qeQ3MFuSkGhNNqK+98ZLSMglP
w9FRWWCu0WQfXVe/K42BptI5LQxwAiPBMXYfJEssvLzMG7wHGzRCaCoDp4Di
7il1JVJ24V8NvWfkzYKTJ7DjkkhMa8tinlVnWJdJYCo5A1TkSicEOFO85QSI
GmZv2MLl6Rgd6EpB2K4Hs3LXbWbNM4xXobQKDlQh+KPNVIuCawkeenOIs9Fm
tX1xZDWWhQ2SYJhUeZqCNMLHraKX0ithwbWGWDnpTf0JB8SdEJkFmwwg8vw6
M1B3nNQiXrfJg7GF4Lk5noO5UCWylhe1vNQkLucbJvYDXtdbgi+gTK+Db1si
AKKE4saxYwbC0TVU140FQORp2E9DYXTamSEzQ2qIqJNgmht2QuzHTuBFEJZ2
quwsraYzdK/DckDZoqsbJEWQhfEW43VdlAuuPjWgOOO0NdkxYpwUtuSugFS0
hF0eRWMrLoo85KhgVudkquVMqpUwjxXODhSecdofLuGzI3ymnu+K8pIAhGU3
pbysFdLZCNG+wkVZDHmndApcvk6bFqAsB39QfhDVj9BnW+K8go2bfIbpI8Fc
ZVC9TlLMtRbHSEqF/sy8oVcnsGirN/tTjC0YSTy3i3bOjgEeOGWhbkiFZgYs
Ykm/DpCfVXHWbWWwsLpxLTgleoS8cd+MMd572gKv+ku05n/QSQZA2GwEOEnZ
ckR6kYTGDtgbdbViRp4tuorkiJovQKLEIa99zyqG0fscmc91b+EksfRrEYr/
xYO1VARf+tAcTqLPMQ+nBwe+SQ0hadTtcpBod3oOAPUZUXKltDc8WWOOT5A3
kD+tivsCmaOgyJ8YstKBcyqFbbGi6X8uMQlrXGEyaFNrZfx6kudDkFbajhBv
0gw/t1sfHPu/j+nnN/5HP43Lef8sH//w0461xcog9LL9FP92fpCfwxr8YPq4
/vvPMOBteaHnX4rf2ZHX9uC/ffjvsfz9jXPYjRXbq2KbV2y7is1Y78N/2DL2
UxMBrKc/5FqpbMrdNpIbHU/ddzRkx5XKiaIVXmaSTpERcZL7KtlxRErhAEEY
v1pxOQkLflD8psv2808/DJKdn3/pfZ6u1J1EhaUH3ZsF7694F1ML7G0ysw2S
fw6Sb+A9ErBfpNgbsjkHinaG5i0rcAt15/BikBCacyHvRF47q2G7CjtFJHAW
l+Byz5v0Eiu18wYcFT9SUhL8/eVPb2kBR1qC8pxJaRZktyojij3FTJsZyiCk
zqnVhYbBfFFVLfEsySgSZh5gPktQgAkKuprTfNYQm+sCK1DGJ60lRmOzeRGo
rKjAbJDkzu9M1kptN4kv4NhPOM6lkDMwGLCOZZIpSBh0/pxMYpLU0qZAvpIp
DcoTTSifuimpSAC3xNaRN5Tj8vIYVJKhymHXVNYApbjgYhhnnJYam8jJfMSA
0EeDARsVWdBfJNI7fjGnrjvF0K559G7Em26+WLotc43pMAUSAFHn2ldkCGBX
AdouQD0YSxx7lZHoPsk2rulg8n3yBWFK6+Pg8ObalxyfNrqeLB9/8V30+T/l
87YjjAcfwaDWlUd/X0+ujxKdiP11P/i/f3x3go3/KcH+ml5+Z5KNRv4WsY7M
TFLgFkV7n7FOH9GhSPYenquzinQPLScTcbh+9UBugNir+65z7cOOjQ5ELf1q
wTBk17+RlQJOZC+8SfGC9Ase1WMdW554QU9oJ/WV3dP7e6dT83QpAno0SL4b
AL7xX0DnXw2Q39IX3yftH3xxp+/F7Xd4cZ8f/YF4ib74eJD8CCO1v4hefNz3
4v47vPg1P/pj9OI3A3yBXuy+RS+iR+aV1tOOuVvy9iNWzp373sT8RX14Oy4z
W/beYya6iZaLYVMOyW9lyuCrct6t+wxUL6rk7SLjaqTUk7mJtKGp9Lsjih3M
Jc5YbgKH8waWEWYztZuIRg0FUcOtOypua1TX1YOk3Qb7Jrk6jHGweZrp9fzY
V8JqmC/r4U3/2t3TWj5yTu9kx4QzFiVUt5EsW/tAzpFk7eLJvvJ3q/cyFVXw
52oiRW7FpdjFiE5FFRy7xVNy00Yl7o/lMWrMXTTHjxwR47YlRJJWWsAMNhCC
mfcc0xDBLylhgZG4Iy4To/T6oEMpC8M7l+Qz0HhEsfPCE1VrROJJ5LHwVsMo
q2KkHVSNQcLua6XtCLtsL6jTgUgebZuEE8kCsKymBsQ+tUzW1lTL7JGvGkTW
aE377eAugAz9Ix3lkqX1BhOxpXSIh7LIUsGMxMjEdiHXGQq7AMQu/775vJ8/
EmGctT960Hbav1giYOTTlggnxp28CSYx8izJQ5KMjsYnDUxomcNqznWiRGrH
dglKxB54wY2hy7khuJCpp1M0nU+mPuP0tZAC6FrnEoiZMeLUcip50zJbPglK
8pqYfZ06EDRZrncCsSu3Ynjd27dCcknEGPqeSGTI6hcfUxhvWQ0FRUwC0wCL
B+9tGCtAjF+O7QzoY/fxE2Lig52tU+wERgpLCjsLvrOyfA2qyWvyPmt1tKkv
R8yVi2lm5AJ7ow2iK8VKTsNRLsIwLC1zEcjs09onosP5vGgexB21gYCovMrq
MUhO/nFiG9tg+TIpfGXWwBs6Wbxe/2EjGiu+BisM4Oben/xwstpmwoX8WbX9
4pqfSFSHNW3v7O5tmA+NcM6SOT2zYd8S+8rtVmM6FJXx4Q1+aUf+3ZV/YRbg
FtJeIPkq0TSm8MlO55Pdzid78ebo2/f+hNePO49Fqnf9xCmg2gB4x08cDiOw
NAO3P/lHsvKTrsLSVV1u+ITUmn+Y//j/73Q+wf92O5/gf3uk23A6ufaqiCUE
ScCtHyW22RKLZNrPWlRqpLaDNk1FqHS47jZdqJ0QDxO/AOcTSRqzGdG5kEhN
9Ik03xDdX/u6ecCcy6qBtbtFCTzvkRThiDJyGyaM5ENfAzkC1TCxYJAqxNGT
sYSi1azZvmSaA8dQwQ9wHxRZzxSXqjMiH3QaR8HUBxV4rmhVBVGDOINNxiXC
uocu51Yb1OccEMANUo1rUzyzlDiRcQbukjtFS86R8YOKowbTOk9zlnJdsEjA
uczzJpc2x+MQqxK6nLFzhh31ZFpkF65Pb5B2btSOdN/3LsE1PfWZzevf7j/d
MM/thc5yj6UgGjyz93hDO7htRy3X9kOfOILVdlAN9tImBZa4vw3M0DaqVed/
8MjGHz3d3m19gtpCSpEx4XPKTSHQ0qbxGJkdDKn/W5jv7dt/e/l497Oth5uY
YEJawgltMqMM7bw68ZXfrGIjCAfQ8dq9Pbp5ilGgkyZrMG6HDIXwBi3Fm7e4
lFDOnvWBNLBDFTLE6SB0zKYk+KGDLpTbXC4bOG2+HvSe2eQ6tXbKxUQK8sw/
YM/3t7YeUIc/9GAvqGuRxMBmiCNNNDqRg/QMUN2isxQiChE6Xovkpw4Zj68W
GTu9Jq133TQ7xXx1dnljnb44DkCCOYT/woHABWrFIfAaykWK8VAUuVBzzAO7
7hOdQXS5JVZY4MZpPnSE3PJaPPAeSjVv33qcoOOloCATDaCF6RrQoWVqXBav
E5b591dffs70+9DjZnvJKK5hBGY7wmnlVlxrKwZUZLbWiTi+ortCv5SeZaIQ
Gx0O1yncn965f3/rM3Ql7E/v3XvYmUVKlRpJi9IsHFtP6QCUgMkhI+Y93Lx7
h27bqml39w63PS65ZweHR1gXl8I2Xgzv3H8wSF4M7z68R1UnXwzv39na6FtH
J3QMnbMlKvbfFeTfpNqrL5ATvYwDkjjWThQBg6G49nv3HnjEPORbxRpoDxmK
N596C44lFWLan6dYIRETysN9N4SdYuflDrd7jRvPcnLQuKffAbjGJgBUtMIb
19eyDmlLy9jgz5bw2OhkY6pCxAy8bpubSCUFh03iTW2KjVELenUcdTktJ0uK
eJMyNHR+WNIsRqt/M0fTMtMwNpnxcaS9/ZdDPxp2K5/2PCRnL7pj1xF1AsyB
9I/6pGdJBtOpkvI0h9MY52dLJK0mfKe7cWAFYhQTQxgRA+66CEt6wwU+1KPg
67uRHCNazKLOlgA6dKMhkn4Pp/0En173VOBb1J7os0Gyy+EfGwmL7/6ZEf7W
egX/0uedewWs8vQqDE9/i/2lZ4ZBGPsVR5m1Z+QBu+OYaTuDMA37ngRH8xy1
vPNnkqpTHEkiX/DkLU0u9JGgSSTRfCiBMfTx73ZwIZzbEgMNU6DFq6bKIN0z
4JP6IllDLr812kzWkk8YNJ87mQK+jYf+BrbDZC2Unj2Jj0bQrw29E4u9wi5c
z/VHesHNnrFmR1HbKFKLlzBCVC9pwHnFUnu2yoZq64lQLeEyyEtpHiiVb0PD
WIIJilxAEy7KfEpBNXltWkDWcijkXEkOtp9to0EKS0wRfQ+k2bHw4Jc85Nda
AsRQBF2RiijqjqMYmbAOJGhWqsf4+4UpxVJABtZlxCoTe9uETRSnSxLstZ50
kKJqDV9lem5Sjrm+dG1sg7A+ahSV+dkszcUM4M7i6NCp1IB1LLUwUcYPN9ZL
A/FdfQPX7MUMDdTwK1/Twyyd7YDaY1+R4fwra2v2Nef2svZ0rE/2zgfS9HOS
YgciP4a5ny+yguY2z9ih+tZhxrAUIn703YhED4mwBOKNEoh47JtpxM2E4Y0n
DG+uJwxyOEISFF4xKTBy7SA0GGeROkRdG3jY2l6x3NJHO5zSDhqw96JIraMu
6WjjpXtn6pG8C/Vw11APUT2CfjgMS48pSfIN6KPDHUoBOCA5CaBUgVJyiHHQ
UZFt8vGHSnD4nWYJjK9Ir20nOUttM9cdot0jzriapPvqJb87HZjmEjIASpG+
NTRDnwIlWdlFj0nYiMQ2St5Eh4xYdQc28FLDGAj5XfSRWTN89nnrS10PfUU4
3aJST9PXWTTCugSlf5HAHzjYur8xppKanwFuP79AI5npdJykbyRfT7BnHKdP
z5ho+fXQh/LlQQGQi4iN/cJi3fsTGppQyIwd9cMEkRmTGBYsv+DBjS6YxufH
1OaEnjqBGyOboTAuEaLD89526Kya09E0zLG1XLnf7j3m7BnJAXPm/K5ZSWR5
UhFwklbVldI5U8RZ2gPPUiroSBmNVGnDL4DOSpbVpoN2Y0wXdo1T3VlzrMmJ
Nn4O44cmU48vkGyaiTu+l03eufSDOGFGGjp604u3jKq+6L2vZkRq4Be+p4t/
QTJ32K0BKBJxbbPIiRtOcs8kJ/uAjoETsPHdTg+OCaY1sV02EBzKMTHkR0pF
SIt3O8YsuyBybykmBrgDf2c9IZPghB/ub34WToMzsuCM64abUHIv6WmJrvek
SOdcWCGDP2eomZJJwMfw1Uui2Nuz5hnq0Z7RcZJT1OICppE9giTo8+i8v5LL
YKS4u4qsFpzJymbpNFmDs8fMrTW7ss7CfMWoyXk2eZ34+hTysoVrHvLzSwIo
QgDz0b7zJXCakGLMRkPWWB9s3bmP0kFqcDrg55q3qDhzbmsDyQW9FgewUhAF
ta/5+Dez5DVfqjuNLMhcqkBDyY1V6/ZtwMispRVwdB3+QZFSbERzSxBHtx6Y
DR1dLYDa9WqBiFHHmMYkpHY3YFj7jXg8c6mPGxofn6kzqmSwHp4dtZ7bkNHw
h5wKVND7UeRLlLXJ/WW7XfzSG0D7+B2zcHtNaq/h/k7b84tRPpKs0QLWLJGi
jNcxx6zVOJbE4hd+SYNQY7S48mVb05kzFiHJHhG7oNiTlH/oQJZJCh0yeCT+
drznI9ixWaMYTLCYw5WymBO77xNmjZFPWc3oxhrkZODwppiuzykjrPZ5KdQi
JRR6lrQMnH3dTvvT5i+Y2Op4r9Oh7LIzvjFdepCw/e1EyJDXurAI3kmAX9+Y
iRoBGaxYrlUiZ0+8knwMc50oqJ5k6ekzTvzwqYCkZgYIY4IiQ+Hp9j+TEusp
cNgxCMloALS7Ft8V1waDrSwylS6N7xA7yV6R8w+Im2jqhui8Smc5N41hC6El
J6wOkLpOUcYLjLtQDyKLGsT12wwHA8IcIBcGJ02wtkqqL0UxaN5Wy5JCFPoU
9bhxc4CZMHFLP338CPPuIzTotUmiDQnUsPJe0ijVXazUH8SK4Km1plsh2C7Q
62g800QtqtpSt4gvXEBCbJQT6Sy0s3QkZxhCMQPa2+RzrrdtbhrlifbyDr9+
tKzUWo9O82b7oNECBvmROstmvte7ezE4L6iem+a7XQHHkLK5mNnPNXSRbQcV
u5P3RauDvaOGlXZkUCsyrW8fbiB+XNOSipPPe0CK9ok013rmx3IS1te2fXgc
qk5vH6ocJylyMWrcqvuBIrurpCB8T2Boh3IwORX64VeuhITPVZeiRwqHYg8f
7kDjSw3efNQj0qqKjNuAUXPDCE45VvJh+5p1i5DcpAQxhp9jkPE1t04DJev+
slMvOu/9V98hV97nHvKCjhJgVsc1vrXliG/oyNIqtoP05WoQjaZT4M0r65iP
rpttRTFsM6cWR1XSAVNJJjiXDdQWAqV8UISS7FIKfvX0rb34iuzvuYtuER/O
ZPH8iSu0xmdPKYkxolwDJ6kFJHkzMh8F06+aCjMJA6J5f7/2AwizFcmJVr8+
5mL+IHZ4taHTqUawUyunS4Xt5MZBpFQWx+WS3upr4K2gIGwl0pJEA9/fTYCN
gegCFh6OgmMGSlDo7lBQD93nq0Cgfch1D2XXu9K9p3QHuew6LARDPkuPITyi
6ydSMiKWbrKSH7By4M02nzqw2VvYbwn+uOoKGPtvFnnFXUxfZhflRGSNAy7J
a9fsnd2prN18N+EOATAUWoswjySjS4RxWvCo4+aJqS8qQJFPtJN8nrWaN5IQ
0hFAGRHdSVE22ziYkF5MKyMfNl807udIk4Xwp0g/5lhbWhXmmNOSp5HYQMol
Re56iy1rf9wVMMeqJxidKlzzIkhocQWR06gswzA8x3yu0/CEFEMEuovnxY6a
E7FWpNN00XhvyypO69skgRqOspm0Ocw4MhzGq/nWSNrGgIgu2Y97dxz6IPqW
J3CLfEE/BqFrOc2DZGY3SncGQUtj2lfEGE7iT6bBz3ThG4WBGopMBHRrUuUp
WoGsyvSaNY4CwLHCNO7dFDNjQdi3+zBIfU6VfhlBsAIKsZC6LIsNYqa8Ykc1
mg3N9iUqE+3iyxVmPLXt3B6x6KCmASiU1mjqVxlXmsCynN5mC3Vk6KaFTLlv
B9fqpPmyLooPNP3BUiSmKp1NKKUaYRgPtS/AwtuXzFekBVBe254u3nRP5h+i
InQtVWpIQZTWBphX3O4g1BGWgzvlDjP4XXl6ijXIJbhFZozA4oyXlow4tqZx
//5r39XWgGCeXjmq8jZGj6UiDtuJpKCJb/eBFU2ki+sKZIrbJN9ahVniC0Lb
mWCSk15zgj7cbMkkpLRdJq1+tRNxKrETKvUNpysMaNMkUJ7JI2rprWkS28LF
Gbu0EXmk+IbbLfFUTi1DDVc1IfI0LF/WebMUYkDs2rTl6OTw4Fd7ojTuHcrO
uL5sWeSNiCC6YLdiwbJb35Gjve6ReK66rE6yV6m2ph2UtZAK2OVrMtAHxolG
Du3ygam3xFxDpQRsBZRd5OWyBlLfYaLMM2tlmiN0zSOdBGpQ1p7faHaFAFEi
eGmhxEGoFxKtzK555HzF/bRdp/gy5UThBjMm+l4OTnoquo9X1xFi2sY+kirT
fRkY8SxjKHae72MefNe0LaVILN9RrTfYnngcybDBjQ9qjnNtletiar2gcsjp
2LQwjrYvVEcaslAjaqBOPijSxDa0MoH4bksJWe3n62Ein2uHZRf0Z1qVtuby
vk2S56IR2bZDxDPIflKyTJ+RJkqnwJbRhsqlGq1RgdYcAixazB2r1uXMDqWw
WSgcpBAYxDEvxFGXehR+LjVS5lxsgRo/vDE9HlJtrA4fc36hR3+fCa6kyZAO
CUZ30jjhSEP5zGCIvrZkX7tOFMmiRemtJCQGDKQbDyZLYlcLqVEtJhHjxTJW
Ag03FdBbIcNYXZxBriF5a3oV+VB52IOo6XihJUPPtcF9ZV6P+AClI6JvhdiL
r3k4xV6bpuAUCUIKsVYuq+QuMhGXF2/5TSv9Da+jRQRnBO4W7Ty9yqqWtQm4
JNfV7SFAGA1p3xc36aTtFiMDTIi0UOsLGe+8wip6vzcMnZiRj/Op0SK70cHx
oyEyuJ92kkb47PkRllz0HevRayJgXT0zBlOy84tLpncNd6usaGxREvHnDORi
7JQyQ7mlmM6ySA9uzi1CWYsX60CMWJS38VSkmsdVOqdQ3m9guPoc+6mT1tHX
x558lKT/Uwc1ejHx9TmlO5x+7n1nJh6GSlOQtI/hYrlcOm0BLHZ/VSJCbqc6
bFFnMXATvRktBazcWJ4ZyFno/16hSolA83YyMniC2t3rQ5e4FR8w4ndaq7dA
uTM/zpmCKi5KKVuzDRskvHorFJbvQI/kYYdphBShM1nwNdFes0mrGCZx97So
0XzVSJl9AQTXC8PEQthRTd5G6Ta5HtH+8zyideT9qlwryWKDazpMJXGcnDjq
a+0FK4eks1dHsRDj2TmqTT/xJatZqUd1mQiV9vDk5GMgY/LCyD2RxAKlrBYq
HERNDYZBsUMjn9nihYm5xZXgBl0IQNxg1Qc+4I3BtDctnrsAFdehFWBs66WW
g46rp2CjJd+DNMAETbh2f74Ldxchvf6CY1GhPxC+5lmTItkaJa29RIvQN6W8
LzNxXtmAojSRpvjltS0cRCuRZLT2GerTuF4qY6jdyrcxpOfcEyx9ldPX0Eun
mJ90H1I3IxLk1jlKnFoeGxelYbYvdqcdWfeyWU4VHtQGQ9I/Ej+xdZjSrMp0
sH6d+L0RzNVFNl3f3BjQB/NZvbW5viV/rT+4f//u/Q33O0ZnESV7BegKgPrc
XTuKAakfS/We9TvyAZtw1+/qXHfu00yCoRIlcO1a6fb4CVTR8hMU2eUxP3Ps
J7/b/U7Wca+1jkMihH3BCuEboZY9IQf8zMh83wk14OnjuAEMlrh7hyRNroH7
efyO7rH3LZms773Odh+t/F5BFU/BAHj7u4le4C0CcN4/GOR7YA6PiQ2tCAQh
DqCikG7xwT0WmD83pyCbjtIGIrEmhJNw2EjALiVRPaeH8oinlSP7XOcUDapb
iPUIdn4h0ft94PahkPpl6532Efqew/yFOaNoI21Yt+40siD69wumAjxMOCog
+FV2fCrHZsFlGKB5povws/qYIy2OhSrFOBYTwvjJz3uGYpq8YqyYYLee7RlN
gnjjUdQnJ1/2vCaIClw9fjP4A8MTPa+/zq6OF+yljN833kvzjDnZAHPRFZ4q
ayFTpPiuvPaFzY+jnr8ojKgMEwF+hJcZRD/fjtYbrHzt9Ou71oakTamhLgqu
qcYZVdOX1FfSJ3zoRtBplItKo7qF5jdQ7KBJ7xitSDC6DoGj66H0oOcrFKEo
ZRpJC0K/T6aSc4i3epqf0T5NPr4WFMBKAuWythJ9VIaa7PLatZ5lJt8Qhow2
IfrkPD87F73fmI4Uslq2HY2oaMXjQlnZ/Jr6d+0fT5HkR+gN/hhxi9LKbxgp
ubk/6Y0DtNrCtv+8eYD2gt77jVXN7Xp+IkR6v4l+6+mWNezUjn3/Md51xx6w
n/yBQX5b8ft7DWIbkfUMAgtNtuurOWgUVT65ZsT+W923rITzIpPbCaf1/fft
9U+Bul3GHx/kVU8ruOGtdx2jj1i+/x3tzP+eF6FvjA+5+n9kkE86JOsT+11y
+A4ofMNifot+e8HqOWDxd4Wo6u86dLf3X/jkN6eSkRVUoiblsTCXdCQyRh+z
/v5f+/f4B181DKP9a/eE3pmv3IQF1/GMIM1pVVXfwtB21eG0ApPOxo0LP1K1
pmW8dS4WcDohpj4LcQVhNGbVfuHqD6sQ10hgvcrY0c6h6mOiXL+Xjn2TMow/
hMWaoDrR5M9ohK4a/sFadHt3oKSJ7vh0e5f11gjitz+OE73XR4NkrT3I2qAz
7kby8W2rJPvYBa+SfoDy2we+2x+38Bz2sU6WdjE7o9Iz6LkLFu4jeQH0d5L/
QSpeNNRCYyN68+O4cD6WJ4qmatKz1tH16usrNfGbj0zvipH+Q7J/bhph8V07
iQ7vxNRBdifdY+R8YnEWq0VVem9csHoXTKv6PYr5+DneNc33kGbv2N/S1DSh
HIO5qn0Hp8YBcKt2J+ZiUQffE8btk0Fk4OVuw2E50fVRM+VkWVXe4am9ONsV
P7z7jbK1uCBYaCxufaXipPDGXfa13NDnxeif/oCwsfo0W2T8oLjSFAJJBAGK
NlYQPErig+ZJyR0T/DreNSjBPGSYAzQKNcvH2EXU2/p8PoitMYzxrT4ktXfe
a0e3NkE/fk+IqzZqp2NziQl5lb5JXs+XV4b+CfIGHVHTpRNLLU7atn+NAj/R
m3biFVj/Eb8JQ+nDqdRfUfN/Kt1POFJIQmtkTQSrDnXvBVr7iPKC7jd+xrot
tTeAeyfbv97k4QHwziCQpbVX7CHznms2UhgONJUMJhtEjhHiL3wO7nsut3Ni
/HJ8avq2Nxb419MpdUZ8Cfd7kWuUauQ542d9hLPduveoIwzsZSUqF1Op0tKw
uJQsBSwJ/bA8AiurCY7Jx93u43EbYI5/qbBM3dTZtpHdguGYttUvWsWZJRyU
Qi4+aq7KO1MQSFmJNmc70XxzH2/K+dD7hXcSTpM97zHUSm4qaAaLoe8J1goI
kDKMwfdny0AF2TEW9W+UGT/Q6GZFlNhg+QfkQRUagiO2R2S4Wdr703wq0caM
SHESL7CV/9PnQYzOso74mjNu57iCGcb1xGG0Iao3SuThCgdECAJbpUvUX1mh
LdkE38u4/rz9/TtZW492nvZXr4ghBZoIyp/mQypcvGLEUD3iOle7ONZ7Bxl0
kucJZBzm2jlFvKDmeyU7biXJeJdbLnKQv+ZxUdBeZ3696mbHOvuNV/vdvXfX
++Gud+SZJ/xORJLpfSg4CSStPN6WoNFJ71hKev0QJwoqgWAAFoWkaMSl65Tx
icoOSvtNKaxTSy0NuqTBG8AeTrKp4yLiVat+Jok1Qk1tgS39jDlMWHFe2yTn
tH/cm8/a0+Lo9T/dWfpB3tIPc5e+EwuStS44x+6nWVacNefH5emxfPJLF8G6
/qETedjTca4ZI5jC6DfwCcBxOJPqXRRARJGJfBInG0GaxuX6RCWKWALYitxE
Y2CgZZGEPuC/ZhVgyVWDcSLbmq9nQimlprskFnrmkybeHcf0EgXzqpy7kzZW
mPvjt+UpbKRO9uzhc9dohm0bcqFVIpY+qLBkB0XpUflfktv8CrXAcGsEZWmn
oB1rxi3GmhqQYMK2h0ksqHK1FOn3XZTU4iq86RWueE6p2HHKCjjT/lP0lNJh
YaHUWUmUoUV/damcBMVFoubpDHV8inw6CsNxhGPtV+jPTjtCmBI7mPo4GahW
PhDVSqJ79b1JWlCrEQq8lfxB0vobjdsbSbsmrsWFwjqmM0yXM8llFKGc+yPU
VPbHFxTDp0XrpTgyE1e1MhC0XTgglru/56R27d/h0hC4ZhaDvRtq3yhaF5Aj
bpJ4T5NgKglmhmgwN7pRz8uSkS5ZFgQQzmmjFZIDXnJ7yTvr94LJpmYr2ry7
Y4Hwph5kj7FOJlXezXTaPVWMBnnt1PHLm6Dsj/KCyrOl1J6VfcFcmsjtZKfo
q5cUNhypr3YcQ43fhel/eP7S3xXYb1afw/zFFG6+aOtlcrbElIX0DIssYHYH
TAAoumOak1gU0Q1RTxJsceIi7MQcgUFI/KKLgN3ysF5AjTFGxLEom5YitiVo
rtB5nJ+HAuk+95ev8z4Wd6QI3oqsSMsFdfT1M88xBdPRbtBGFU6BZDfKFZXS
GpTMhScxoKxOTgGm7E4MG4c13WZoYjlyrlHLqZC0LJ+tFGFreWriIQkGCrX2
KVD/EyRBWO8HJ6XTWBM9Fw8fTtCnBpJ1jEgy9RNg0uV7vcAine+yHp3ZWFFH
iTjviC6mxyGJFDYmO5/JRWgbluepJX12TJ+ZWHsDCAoMYT0H6ZYzNSvEwtC2
ZGDoLqE4Z52xUdasOa72bAJvR+3GJJ8M9f/0ZzQakXsIvU1Y5fRQ4fOMhk5+
u+Ydow7CiVw7+NcEI3Vpbcq/7zg4Nge5bnARHG9LyVBZ+nWDe2FmO8SAx6qG
NBnAHgMi35Yt+uJ84yvsOc16qxycCaEB9jYIiCq12bWitc9OUezkkGBY/Q0V
h/9iJcULgSpKbu993qtd9guL3Yo1H6QnvmtlOBjvpLuRE4ke4vw1YHsYujRf
Uo+hqW8GP51ag71euHWuGaaJAiXVfpsBYftVOZrbxv4KWEI3dDqgTZ4KXRJy
MMspzTirsV5QXp9750UojUrB8qGwOrz4079RuZeqOR1OTquzYQo0ecgj/aL1
45mWEMis3oTLXTOEZs0HUlGnJwTmeWgHp6zaMM28dkHb8ngbdwwgZVH4Z4S1
QfJAkqvh9N4ZgwsC/RSEqIZV0xRNj5hvFUp6ycxqFkuEw1Nac1jZoENQjWKY
3ngjV92uFRHM8nFgmNEdMgT/p3u/hOBi41ijWxPK0tLNCQ/pUqU/jRytcogm
5j8ivbtujLb1cnF/6TqTwUZhR8QhwtzmGzEv9zGwQOkiTi0cWTGMRQBGBBrE
2Y43cBAspICEUhsJheSEVt+0JCTvBNTkavhtQhl6LgqV4M4nrWq05GbYe+yx
gUpTncAno2fnJ7HMYC60CiieuWsiciKRjep3dKxJ9wyBEhk1pjvH3DaZkA/1
ElsUtZ6l4qXUhsDbBAdd5iCVmfmqpT2lusOgx3LBvjAT/bQ5GvFKhlu/OGcv
J07zBZY3gbmCl757fQfJGjy61ucJJ8tFe/4BHcvo2euNaDrezTtOSA+//5TF
xvtxeyXP5n7GZ0R2YxI4m3PKomc/Bpx9zAz/ShZuaUyLOS/Squ5QGFlASm3P
iSgqqwvC4iAWQl3bVsD8zOQke1+tir7WGyxmlmCDSaneX+jTRzmUUXfc5z76
VxpzGk8yd3EsxAcfauQZPxd6BGxJOlFr6I2BYzJBRoTebk7rWHl8g5vscJBC
WnipOiRccTlSbBiLJ27qMLxHlqJveUYVAivqGV6CWnZKNkk0SJxlmrrb2lyY
j5gFFv1liMjTBZawd3EEgQ6IRGOeUp3ZrqNe6hrnnrSB0IpNlkxAeyspLur0
6HMmQwQ3G/pfcFNscvkKOtfUPmGa15NlXSu5j9pkUjNNLCXLKs40k7KFEUII
T3Jamddn85M4ICvnhvTTHI5+icVKxCO6jtgU2hVvYFImnCpBtuUvpUdta28U
Cl+Yvzn6gwopVKuufNTiyWAd0tuWZRYHplihiC6A9OGbxHJXHZXT6QUEr7XQ
xjN0uXiRtHphSQGzVltd6syJKYsu6mfsbU7S34cD+1DMRagD0UkLzflF46Hf
kazD6E3cpa0Uc4a2pw3A7RMM+OshvsmNvmiaFnR0y1gds7ZrpS5eYj0J83gn
stNxuqXB8oopnt+wNseVkeNGskdkCm2q3NhRO2u8gKtWVsEvyRVPc2rYgTWN
yKhWcXI23CWMnejcpKiFUriYgULqMiWfRavvhkvBxqFbNeaSZmmVFpMs8qwO
NJV2LHyAXwDZR2Ja6tL3H+KvnIno0JRQpJvYOJvGjSikje7iageqmaVStUNU
NCkY/i6ZoCbtyKdYcmmUmzI4NUDlsFxWk0725IqQ0VAa2Xavs/3J/AP7GnlE
XD3UZfAPqEeIvvfpS2GCVaWjlSLspot0nM+oWHt7+SJiFGVzzOavz9sfUxEp
HOZJfpphUZkPSpGMNtlexAoIdI0T4StjmPBvt4e9mcZ229glUWHSNoANcOUr
A1qQDyI44/cx7rAaiTfzuBZkwofU9agPj9qPdRyPK/Ps9IyAzPnDit5klF8V
uHFzOOw1XEnf9+fRh8u98b66cQ71NX9dH+Ubrub/LSeP4eD/lx7+X7DfVUvv
2+YqFUt/euw87wyP9xlUYPW7xfL/PjktKSeT5eIq9P1CSQFrMrbMMqmNyoyK
DztrhKKKcN5TGR7i+NGkv8iz30tznoUi1do53rQZ4THCvesMYGQGW7Qb3/d1
O/wEvidAaEYtViIzJ0qXrm12CvzU25tO7IUP0WtTiU67lD4sXP1MJYJBxP4H
LlyQQdTEBbWWgZp2htPsNF3OGlPZmbQaUjF8SXzq4ChCmO9ww7FR/j7ye6ZT
VbclptbEg+/XZN41gdeyJknMsdOcpGgUiaUoXXHV2UHHPn+Jtm7floUcZ36g
UaAbGr5JkmcU4X1NtSrfp1RccdPrX2xWHKHpNhTvxrQRNQHLKyc1KKMazjWz
cu/mlvYr66ZHr6jDWsH1HEWsgodaY/nVnBVllU2jWv7YDJYh1rcAJ5Vh1I9J
5fLEnvv1y/3tw331UsHhAWVZ+PKyeFJxwT1f9t3xOlrr1vvTJvrdO8Rp5Xlt
ukmkc3Vs2srXzutXuXQuhjPLZqjXNKFwaEuHvzzPfDyDUZd81zkaXAoDnig7
PUEbdaS+MpDtYCfKDDDFxPE609q3VdTC1L7JZoKRHfp27U2HYmryBmvpuynK
j21GLPTdQ4mDL7CuUKjj77/EcqscsDIdubj6qY25z/1T6hMnPOLJuc8QV5AS
uxpra05tY+gHovgb6nvkA99hT7eAeOSFONgCqEKoDTGgUHeNjgYXHZU6J3V2
TI3zyoKLgXLDPXSmGU1T+nuF4+s0baHRsJixb7AplbEEm2lbShUtV2SHpBYx
4yHa/ctx2eO6nJFnHp8YALtL8eLQHa8zGBi7q/kaut8V+Rsx3q1vffbp5nBz
C/53tLn5iP7340arGhRTPaboGEmRvsnnoAA3ZYPdM1QY9JkmcY+SNO6u4DgI
i0h5QBd/EK0xKaqkOCOsTZWTLCvpzHNQOLVhigcI2xWfwalxSe90jL199Nak
7SL5nDygcw0M4kcFI4VoaecTrneKlZDPq7LIf2WmIxVFQ0jHMzjnsnrtjvBp
1d2l3cr9zzbvY/LLtdhY6D0CCSQT64zFS+5+IBGZGqPFCRBdw1ckDKn5iSxg
Pp8tTCo17FrWLu15beRJU5DEJLJpcsWYiyJHeX0xmSB3k5bCGwQyEu9fKYSt
2Pemsfb2dTy5pe8KICI01wGTOtT84MFeTJ19b4MO5Qw1qmHbrVqVNZuT4n4d
IPlZG7Gjyqvc8qBb6j+7wNtqgtCYtXAPvnJqCtqdhsnVCB6iGclq76UysrX7
LnCB8BO/ovQv4VQa6o+rMZlDdB1QcJU12TQ8vK18SUK/kZlmVrkgzRfZJaa3
V4nkfQX4tO2I7UZJdnZzU1EW1ALOvtUfVWbGMrp1gxGNtp9JUCdQ5LwsZmXq
A7YtwRZ2k3vXJyhMGpQRWJBtedE/h4S3yhnYAoyhWcpAqrQPQpl2l+iVDcPK
nNrrpW55HaSQM98SBa9OiXQWzWcusZXdU7kJkrwl44fuNiuhHsiYLT6ULRjU
r1qOuW5Vegsh3zfDqjuwztXNFvrmCDSkXDWFJArHumDvYPZdlHxgYuRWPuRE
LzTgOoiCjTjM2N3eynNnTnKi0txxLPV6pcAX6g3+KpssCmqYN7eyqNfRcvTW
sx7TBvStmrJIe2T+Gw5MozdiFW8265VmSWtNup2We7VUeNFEGXeaLPlYrP51
e8+MsQ+oxC5rZelCXAxRXx2GmOROM5lCVRBWG0nqMWy6AhzaYD7W9O5ADUlh
FAlBXdnc+kAzvwIF0UvL1Z28ak1iEd9Ngxk2SLft/NZEcJWKOM7L57FWRPtV
92vtY6T7wIjiLJ2+834scevsieZO/Z4GZke0vchjGnFds1fYiZCyAdNiGvXl
/u7zp0/3n+3t7xkIdMjXtaAJYGG77grQJMm6if6XSstzQFDUZDEYOYRdexsA
jkfxzKy4aRsD9YHhMoKUn2mrsbgPhepzyK1pQPxC4T3a6Lu1gVp0E+XbRhra
ju1KB3OA8OND/01nppX2C5QJLbFp39TRSpNHkO/aF6xfG3+Hi2Z5t70bPUMK
Ekmq5Ymx6p6Mbpyo08rrpulorrz207HMdxJoXMfSGlXpDQXw2TCpLkTVd3os
tXlbSI77ZOll5X1EdOfG7ceHdCJBdnKqpueYUB5VP97hSDx8fAJ/D4bb8n8+
QZvLnvvOwP255Wwu/7jN/fXTFghJFI3if/ZVII+a9XlBDvCdJTKNAhJhez0f
ZUDdpZ7B5wnXPOA/QWMidYx7xZgWEhTFiCvHY8YsBt2KtGMg1PFZBNxgm792
+PUtNOGh6YvrLOQhjieoqHDPLzHonQLYJmyKBgxohpT2Vc7zOsMKicsKRD9R
6+K9qvgX7TakmtBh0T7CHrzMaDKbSRadihaShT85i0p8+3S/qaOHNItCRSVu
Y9GULjs9xR5ZxM8RwIAWPqqJl8LRehJGpR0/onH6rO58X4cISza7+x6j/E1t
ziGd+WgTcwJpLYjL0vEOhZmpXGIPMHrLZ4bQkWtcVFk2WNri63Z6CvliFNY+
ThBfbT3OHTImdGlpHoYKbB0Dtjz9J7pRBkICSHWaz9ifzqtETSJF81rY3sgE
ajUN8ewTfEbiJH/a/OWEe4P4CDKOVTTRLi7xxfvj6WSyaLytX05Cgz20YbXi
c7AbPJyzppqYINR4VVwzAs2PpDpKqo99pvgl+SLZo6jWQ/pkPfp2uPXLIFnD
j9YkovNjpHw+FcYCPTqpOjlZJ0KIXrMB/7Ycb5zEpwFA6TmPCC7mEDqbZUr7
Thv5hWJZpxlswy+LPtWl8QDf7j8d8SDEdvNqPZ7DhLXSwuXm0aXWyGBs7pfN
QSJJqbU15qRlU6Si+rQWMyIIhBGoTL237hKcfIICF3cxaO3r4HLcvWbLOAsB
755oLbXnvSTatLTt9pZrErBYFmQKpso3LZQywDydoY92Oc2RI6+40w7s98ee
8rH/lH+5FN5o+AkXabxNH/4Mv/4gjt4ff9r9xcHnP9Nf8C+QqyTZgf924b89
5zC9aQv+uwP/3dWaeB95exMFOWqNvG2qHcwCugd2tF4qk3dwqhRxx/TggVMK
/CDuSGos5gxut0YiAf+xJhoPGvOpQY3PxWvZG+RSuRYli8AXk4tkOBx+mVhc
5c+G4XPC+C2L8RiHTtD8D2fOAP5pEZHO2Ju9Y2/asTdXjW3gkegYRmzSLz7x
nxMBkV+X4xWB6L0/PXU337N65y3NYEtG8ts7lzD9I9PSjwdKq74j3VSfxxvp
miQAMKtOLRUlZN7mxqbYeU1lnIC5g2Bdp6hAUu/aVjCxeEdoaFFLkQJO7p8r
4bQCEv7md36UFFhES3iWH27xI0wbet4MxKLzZUw9etf0H84joN9af1XPXtoj
5/UCdZO5xHDTCZHYZw9Oa3IeetcKAvxVnl16WR9ldT1DTYlCbcGLotjEvcol
JMGfMiev6lwqHItIXVKfUjzz/5+9d12O40jSBf/HU+RCtkZAKpRI9W2G3dQa
xEu3jiiJS7BbrenWoBJVCSKbhSqcygIpHEpm50F2X+48yYZ/fgmPiCwAavXM
mVkbmEkEqjLj6uHh188tEbqAE+/KIHFjpxIoHmQsVMdls24X83bYUiFzq3qc
5NFRJzGWovDkULhN4AqBPHykbYuWgDG/9SvDtRhXgfxSyZCpyEVUiG7tkAI5
LfxdVmxalJjkSZCarmhZ3FtiIUf8JYoy6ttcYVUh54sLQaOu2SSt1ZctsGgo
sHU8sw/AEfDSAwvUNwiRqKq3ZX8W47XdsPJi2xk6F3jAWxZ4qWmR/RpHUWyp
Ba3wwHx9eZ1tgvqPdOkjvWa3o3riQs5YfFxyLqbfMlffGSY9kfgK5W+kVEAz
gfCU4rlUiwB3/bD5egWcBRQg8MmQl31KUPOiV4kVGZrUWijlNDYksDuY810l
DsJ1paL+1SkcaDTszgq6suR/DygHh+pXm5/3FEvDSjhMgfRBMDAIt0RNtkSS
BfRKJTkkszj0hnq2WkDArZ/aGLtBbQcp9T8fotcqM/I7cTpmpCW3syew4kHH
oOWlUs5CoZRE6YwFWEcv4urdx8+MUU0khgdTp6cWb40QWL560/DJ1PQfnag/
tWxvcAfck9pQwoXSRTI2zKlYb+6g3dowudwkEiLbITs2cl2VWpULU9vN5GUg
z+56LCdqjLNJp8BDAtXgoaSKh077Uptbls3M1OyPm5u8tDbLFb3ZNPximimp
RELO8d+Vu5L2f2xK1ItS2dhR+uVUDae5bVL70Ep/vJLH3XaXQTizERZPl5ZQ
LX6aziTcmBAHqNiZ6PyqjRfN+SgIbakKjFAjC7/6sjsko1UxR2wkXTm0xHPL
jzm2eBv6PD3enZ1RnttbKkKp558Mi98D1Od1nVXDvregMILtggNF1onk44QJ
/V7K5SWn2WDxhLM/il3a/Ixhv6VoI6aweiMktDZDUjj6ViQIdaSlhMGQLYm6
vVLmI0IDclzWifEO71Ug71FIVvHkY8jtlFAhT4QghpwZeK/9iVZdLc5tCgge
P8Bb11X7Rk2elTP8QX7G0l3gDbhUS5yugSaV4qsvKKIwrSFpV5m9QV6pvjYi
ZtwZUVsrMjW/o8Zk9Puc2o9ABNv8Awl7kSZBQyJ/qp+5+15iTYFL1jRs+EsT
xCUwyhHTM5OUulpcp3q4zNbI367y4IP8YBcL7JL0lIVTO6VFV/J5Pb5Nbq24
7DYkeQ0jXBa7TAREZkyW9FNDJ7CTDLlbxAVonYxfsyOm4J137DNxcGdv3iAH
5k3AQ+vYXVrMmm/K1qW5TPOXyRFInXjr0NuUKdxdXG6v8VB27dx03fS5EDB+
DPXWKb3hYxFusgSJe17gNvcRb9RcxtvZPq3ESyx8pyDyYfPVetvZEIZOp5Xh
PeCwkeQK2BMI42Ln5GsahwVDiJfDekPm0a1LlMzT1DWGrt8yL0a7K/VAx5fe
tdeDRKAQdt6hSD42xX47+D2IHPQYdvQi3b45kUz8oTyngxCxFnEnNn6bSkId
c3Br1gmNuU/bzkJ+s1ti/mRnrzWTFUaqAgd1NTICWSmXwAJiVeSmXSxKFnCk
KzAqZo15XowJbQW7gpjENub8xmKEgXlHcYUizLbbbNLVOQm5MOu4ZsLzqUC8
f2Xd60HMRHZ8kHwXNg0/1mn49bRy3Kq0min1EsyKy6UdY6/J440XtMB5yYh+
M22OLX3XekrLbUSVt57ZBHGcSoO+d52WLkV5SO03WezaLdagVLyeF/QzsXNb
WdtMlGDgP5IlflCgccoRbMhw+9jAP/aHg1Hj3PjPD+GHh3kNnvLvu//EtpyC
Qi65+PfT/cs3+/9yMGly+zs5tvi7x9V3swOMy7V137V1VDx/P7Z12xyDeiMR
a85Lz8qTdvHXv/R//a4Mw3d6WKZkOcs73osDerP/54PydY02cs2s5cL5M/sk
n+5/MWmO/Ysh9Vtif4yYGo7VhOTu5y+afT7ggAqBPSHxNSW0IyE04ebjS/vX
v9z/Ky0uWSRPgWIxK7+diYcm4f4JIGblnU0YHMPVEnChFU8xdoIkhqso3+sw
zbqeneXtWu6+P98DevO393BQOYQaAAGmN4vNk+pBtkB0Pu4vegQmUzBavT5P
RtdnjIxJoeHVqea8a20KhprNPXjRJ86IE7F8BlBKLqjmNdHBL9YA+SQUTYSJ
1deO7+XP9yaS8fHne6pBtCu7ZYjwnkzVlu5ihqmBKwlXhrSS1lGyQJYdFWu4
2vJ17a3uk+ANzMnmWJqGMiIpQFfRp8oC2YVEkQ6IkLe+s6/5NuIwujwSilvj
AHQxUtDNImAwJfYXx+7I5HOjPCJ51pcM47S0yjVULN47kQSejhTeFGRFwQpi
+fYILrl95N4QRgXQpGhlERD5Temh0kgHdOxjp4Fd4nJKTJk33eXWK4eSZlOY
1HIZ+UbEqTfdxUnctigk3woyTxwuXXw/PeE+f98h3buDLF2ltaM9KruyvTPb
CHeQv8WrVjUoqda2b7P8rZmK4LUom+EnOWkTiayilbNW6K1KLpFFYbb8bcV0
zLttgHHBG9XyBaoAYiKvIjfZWnQsDzlXG8D9sPd5yGrEdshHclCwPA7mjKMZ
t4znrdekxkd1xGDIdlaL1tDzi80Xk3leeYAOg1wBvGApequIrNlPZDtxQzxo
HkVCEOjLBDChUgdV34Z5ay/f83H8OLZSSfJRdhMdBB+CgD5FVyn7lCLdf3en
O6bJJPwHMjbOisnNBI1uxERjZt+kguUROx5Kc5aNJLXqcLezdAuFq2QfiGUl
KPZ9uSczqyuBeJ3MVvT+fZLISqjHeFEcLaxIyEvyddIfz2H0CD5rLVmOt+eH
HPhiPh2XrFdoYhLsDgCjsOro7qUwKcUeWi3UvypmltzJm7SWGrgtJAWkBm6T
mlyxDytJzv2gEleTDNbc0RDExEBhQpNGoGvV+SumahpeYlqYdQYhhaPGfwVW
4C4T62CPqkmPeuWk+grSAfOExTpuGEUWEcz9kuLkJS3W1e5GNSaCheJk8Ljl
JzAh09BPMOeTyONXjN5wAjbD1eLCc0EUQwOYtnBU2w1zRm4Q/N8tUsqFpIZ/
I+H+wcH1igLq8thkfRgfnZgim3zMvGNpiRPG3AjL7mxrJhM5IuYuMDA8HpV7
jBuPV4XYlOQr8nuSEVoXDS1eX7LQFhd51UlkgJwAs4M7s3qF7l3zmJPmd4eH
5fRGfk6qd09Ofjg5uVn7S8+Vb0ugzK0vF7F1jx49+rRJcXbl4HVV5bH0XArG
40b/mv27u/M6gI9+9PcT+W/Xjw/bqdfvp/z86896++8I6HI/H8kSM30VAUNP
9dSmMwQ96Q3soBcSSxD1/81CGtj7UWBI0xEtzIxiCtKUctgDyWGSW13BnBkX
IQztGbnp5PwLsCAoeRSKMusUSLn9MG8jt16EfU1Dj+MmXWzrDbp0BDGCAxXR
zrbiAVIhaw08FEquZUAbWjh7P12BGatwz2OhPYCFP/6hOP5IJU1c3jiAGQTv
xAO+rXf82/yZkYNen+mRA53Orv2kgztylukj/kRPNa2ce33k3NYfZQF02QnM
P0qHF5/UR2TkzP0Q9IqRpdZKAelAPI53IeKOCPE13yB55zGdgCgpkZzlzMCm
ZOY3JcXnbjbttUgtREDLfvVG/iRSwWUYDL4I+rF7BdbPwSSJ9LJ+IcdlLiMK
bkRc9Wd1uOKYp7cdfJcNoEwpSlBK1rQIBcchTVZteFPiqBZX886Zledbk496
ADhI/U4zw7VSliIKd8j5+QP8NyFQ1R3x5XBj7MAvhS6quwOxoMTVNWc1DSqu
77bPJbY4tRN0yJ2cCIR2Do9k0LcQUcRdteOFESDS8NR7YYvkS/Z76K/nbCgZ
ri4u2k0UU4bMIROF5vW7YO4H2cL0rmdH/ZDBFWWCOkzqKLuZiowIWvFrkJZ4
MxmJXBlTWqXcrbahXKUBIRPBJ84AVtWKNHD2jAvLfdFQfOz2fP+FVr/+Vz18
HxsDUWYSH3vORvb428uD8vTFoayHvsRswGgRuFotU450qlyeXvQLKfEBM5o6
EeTnlIowM/Az1qHoHKitSeojtc1M7RPpNSTehlkC5nVfVbWStEYSb/Noa4x2
oeGbrGJ5oG3Tu/TlmStfMTqMoAgaWZvpydSANV7RniwZ3XQhyb24LWMzEu8B
XDaxa4G1md2BLS9qxeONgZ3AsL3aU3ZFOX1W72eObGN+kj3gbG9o7I5gsTQs
Q4nl4RpKrMLC0rrUYKb6KfstFMBUcQ8zcpraIwp5CMAO6vthk+xc9nxp8OIK
ghjcw2ZkVxWnUd8A7GA2gjEw2BG8Qt2U3+mQPvVD+bEeadmuNZBG+Wk5OrM8
EgHl2JJaVYMIKn3z49icHZRieerpYth0ihSeacaj9JykuMDHXVApSs5H5uxh
S/ArJJM5THyx/62o8nA8BCwjZBjoetV9AxS9rWOzdg3wLaCFmOW6IHTBdS9u
WYV/SSEdYd5eCq5PCl5m0CVCVfO+WU6qIFPS5fryasnAYCFHPhmAJ6YwArhC
OBK9VUOPCOaKH5cH8mzXoR0QnkcSnjqT9IT67M1xG3uOwxJkC8rkpv0yaHTw
6QqHCMo/XJ8dxn4hB1EaMOX4u+YYCRKxCD4EcexW9oWxeUcg+ZEC4MZEFzzK
piFar0t4YdKcXadSBUaTbuPy9lx2LxghZtj/GuOpuXps6XLmZTRAVReTfQCi
tcDKESjUuyi1bTuYYngfyA1CRqxV5rxgUDOp5tk2RCGb4MMAqqS54ufyfP//
Phj/6uPxlJqxT/8UXkyTmRPyw6WTH/zrI3J8kip8k/g/Pv5q6gKX8HGUNY5L
WQMMhuVMTyGcvwRYIBjMpD5PAsZ522URKxJmVKCwIA3Rh6AyLXoZMMtmkPJ8
QNQjEuMjuTA0uSiLG3jesh229oBHU3jBB+zIqfs1QhQJk3CVD2XkmMepyvIB
8liyxGOYjMI4hg1p31LIlUhtZXXKI7vbtvM33UZkCHxlRaLOIRcTvsh68yZK
EWxLvTz38R9T6F8K4pcJ4eoUNFuDrwHwgjF/RIRpuLzXMQpAhD1+cG/S7Plk
NtYU9oY+0urq9Z56U/jVFzuCRduQwuOec30JpGbuHTzcqcxPpy4jLZ2ZF/Kb
U9i9Wv5EHjvmPFaXghbb8/+F2OZzS1R1ig2X4tAz8ZVsdFzrt8q+PJ0ze8UN
ZOK4/55K5JiZ/J1BPKy8Y04lXthOmZOqRT3bSs0tTHn8LbPJ5xTjAxRe8nax
136f9uMcSQuw9r8QEw+dhL0X5Qj3sYniP2MD0PHBHmKGEY7ATm16HmVu7w0q
7TuxnXn8Lofsz6oHIl9FRfx1Hw/MiVDfCeJdK4FpTFjiWM0qkj+DJyyBp2ll
UO7qhWpQdMdMsuLGVThoghzJgyNR4JjWKI572nxNytS7foiyV96IdOTkJ1M/
SL3lrBvcxS/KwNwwEpjL5CFYfO/a6wntXdb6Wf89cz9QxsgSSJy1N1Vqz4kQ
X2S6MEJWg+OZo49l6iUgeX0IqpYnQeQJDRIUWIx+2vxh/Y5O1KTIXUvVXVeG
jDBhiwdFTvVDs7PJEJ71K05UnO0mONupTKw+tlhRD8nIyIq5zzdFVsgJppCf
F9OyXspE1uS5cwdRQoYZI+oKK1KnCa56f1vFiX19CjWQV+fGyWnMj0rCiiul
PkYcDfbniPHpmkF1r+aUBavRJWIgW1E5OI04E0jSOJwU2PzTF3pixmxns9pd
gIeWt2AOjSgRw4gWAUO3i4SObACLfdMwb2lOhRyuxnPc+AwLdjNq8NG+AZJ7
4QhFkklLY/4fXLTwC4kvO82iDTz25120hZEoVXAXyz2h53Zf1/j5pvnLs5QL
foKfH/B//fDj7HmVWf9YiK7fWjulqd6u/dI8n4SAV/po+W+ojOs7AS3if0/j
f8/if7/Hq2OCQo5pwfba5fIq8nhOD98hJwxTSAoULBC37lFcNJa6HjXf/h0s
Z5sBH92wR9+m9cwxPsbXJzyVpUvzD1oMfPZNxahUNx6aZ5O4bGq3KvzYUPlm
31ZvZ8xgRfEFbr1wSrhIUn82ynOpxlWmH3BWGGkFQMV7AS1BzpdchrKWsDFx
XVjNeV1ncYltkFg8LkPh9X6WueKUX0wcyLU8HvX9bnnGquVADGSfUKNhQ42C
/GLQUAzgzmShGDp5bk7poRF6SJMP8JYrgmkCZY33GatTBtc6PeA0fIYLwNXW
kzS+clVoUbcrjN9CIwkUysYSs1qt1TIOVUi2/8CJSzaVtH/tlvdv901qKIsc
LUFoksw377BkuYXMBS8qqNccQdQ5tYkJoSfAMsGgnMd7msNEHCCAs2ZNDAg8
aFsgJFWMddEMldEFS/jaChcUjkJqX+aHgQKrbzAz4SGi4CykClYMeBkxSHHr
KIOwLPYyjyohNuRRHpo8IZvQtZuolWyCWycpyvxHHJLC3Pf5ypkuDbyaKKVC
tMYARtJxWYYOmpLro+wVUnNc+C4NEU56DuNKcAIMVz9W1DUGRlfPBe9+t8BN
cUx/tEBmPL2kSLChcpxlpR7D2CwoRBoQBT72sVIqRzQ2kcg8a+veejRQ0Q0R
o+OSqMMuqamolDNkZfHUWCdSlzMInUVpB5KKvQoOgfiodhvlR7YysTwj5Ue7
EsR6y55Whp8fUYa5ykLkymN56h6TTywzqy1z/kAVjeFovYisc47axj3bTiT1
KK9avaFirpBqff9CuW3QCH/cDlA1Ut+0YhwPJpso/TTX3dbB7uunPVm7xJZM
51orz2YHNMFTPCFcvEVH4Vqy3Lnhh2TC8LZfLzW3qMpboAPMKVUjh9jZCMSO
63HQySsNE73xCBXsH7I9u0AKD4Y7m+GES3xwbTeBoSWRKyNtY8klFjczU4ox
qy/FofmmR4ZAc74G5i5iSh+LvKWJYmb+YksIjFP4DKWBQmXqepxChcfzqws9
/Emzf7keqJXr5klgueBAxoDrassp7T0B0oYP9XymwqI8MF9sUzMc/iHcI4qA
xj+0+9GUx8cp3Ke8ZEiJrlTR0NT3C8sNj6sBFj2pUVEDoEAgVKSM8IWHzCqr
lkccc6t8sE3XGETAfZ9VkIS4gxwU/JpbWXX96/PTdcKm9SBzDplZrcBB1eP4
4YXPMlpfkA/CoWnsSGE4Kgl5aPbclcHkv0f0bSFi7AMhXtzO3/BhMI4eNLrj
XXsN7gzynMj5YOgZb5AFaFUBcpIMB+HFX08eTMhmOmnir18xt8GS4c9HYkaG
NYNS1010g5eGiNkXHg/wsziCfNg8vzfkh3/XgeeR0P/tjXDrG5/kkJ1j3EnK
LicnAQNe5FWsBTMy2cJCtWnVnmnUm+wZotz2TtfbbaSHq8s9ukjVdxqwXIgr
AbmIhJbS0A1Wm1PzR0QZdbe9hXQS247KPJWqgs8Lu4Y+AJS+t11folIFBlH0
YFTiGgg5QyrMgn4pyiD89A3dvtUSaRH3+l6w/CdmsKphZu6didUyQqJKrgl0
319ypRKTHAuOaXaqC5xUclRZtggxf89oaDwutT9viTuwu1qs+A7Teiopb3x3
iBSeATdMMp5S8h2yKdm5wfKF5EatJlGD+4YPkN97HMe/uFp2ISBsKqVMa05q
yueePf0+qrjzLcfbxL8u478ps8HlaX/x5JmlGqoK6koBTnyleHBBa0I92gj/
qhNhuM+UdsLIqpMGf02ax5pI8hw2ds6PaWg4U37TXogfyTvyaMiwWvOGtZ1b
et/bQ7vTr84lY+UbnBrtCuKyVaxoh12F0qV+MLsJ8kARaqbKW+M5i8NDOxNP
x1HcKA40AIw5K1H1sopL4pEsxm8Deop/71FM4oPp/Wav+aiRhrU+0SNdbudV
Yaqf8SqYfUqTEOI55ewewfrhfWGagn3x9HoL9fbzFeR7EEG8GdvXm/YCopB7
Q+BwUGOoXZJr4DXXdTQqJIbWygLAwhuXjUj+S8Vm3P/8iy8PRl5ERNeHGXyx
603RfKvXCEnjglWEzfpdbGB2PwfZXyEHgpxAmKk4fzi9BBugCzfKAs/jXIZz
ijs3aEaLWIkdn8ZzMxTiblZj3DJbiaExnnpCsmXxkUDXDXbCQBeiegSlCO/I
kxIaU0BUqG3GP7kjbap4NvweYHxbCHWAQZb4uEWGr5rjVMi7WCXKaqGSFuek
XVWm6kRDNwdv0AJIntsJ4LZvyCu4Kefgpu/+xLFsWMCEsPupp+1/s17zn5Kf
UWVqEoS6TeRkft9OgM2tvO3fZ3Dxh8dyksHL/WO7vRze6BZQUeD7B/8OOwEs
5eyyoXWP1yHlSOzduLz0v0eNPPrz1uWu9IAj9h+DHDCUfztqGN2X3+Em/PQO
u/I7Htin/9A5V2RCDOpmGvmH9p/zw++K+DBi7yQgkGVrEDmSg8Nc5qRLfa6w
JP0tBJ7uq9BsCOSe8WhYfvIz0Vu4nGHzgt/bPdEbfmq4mhsQa/5+JBtFs9kT
mL0o0rd7PPoZf3RCH1kGfPwcdCAlu2EqVTw718QNs4rH2OJc9mShfOiL9eS7
Ul3LZb+j930q+AmxTiSjqKoc+K6+R/mnzZ7tyUw/ch1lXcn3C7vf77RX1BUH
zGVd8Ue7umItUOLsIO+8YZSjW7qSJJI9+5DQQfFRm6KH8Plj8/ewEpYear48
epyJLuNdpaxp26v0kXVUd+WyrV1HHGP1pWxm2RdFcF7kdJE+OonXo/X1YuNz
vNCLWpWkgi8Xgn1x/EX84m+sZiN69oC78gXrqTvaLHB098V6M8O0sGbJ+vBu
bUq9gfXAlOdRsdld8INP3aTmD5XrCG3tNR90/vND+Vxi9WoC6itoGBdDxIgv
bOz3EDj9EM7J+CqOEQnFlxJRpfplXXJxhfTn1eloEZRiiK4KiovUmvlmZmpw
sqrRJUAH7vfPo74gYXvBp/ejFhKMO65iK0lnbuHZTuCjWOdqy//gA25eFUbJ
EhsDolb8ITJ4j2kOiPO9KTjdL3GlWmv54z9RaGQ8j2/l30fNxXJ4cJ/1aobt
OCZDhRgtTmC1yLRureRt2jhp7b/+JR+F7Mk8JNF9IZyhW5wAkG2+6S+LKMen
Vhwvoc+Knu/XpoxqHFIyH1ZmrHpEd9HSiUuq38xP1TR3/rDBh3wKhKAl8Vbe
TSXgze3arjxk76FlKjCUYt9Z8ajQFI1hCXeULlelUTfOb7o14AJkiprTmtIB
vV2sYUWapQ6nKKNsjo5U3zNhJuXh3drCpKrg8P49cPpStqQu/S5KGJnA5moF
QzV7bt6i0i6PAQxe4iSXCmOvRJBWt6qVmIW8Lrr4+5LjBVfX5sPzNR8FRJRL
QhRYDJK54gznVtnaPznJcKYzPhCYD0iyb0oZl4ckev0bVoF01uJxlk+DSi5Z
I5ktJG/UMDG46NwychZyy2WHLE7uiQmnCebEsa5UqcWhRiO/wRyB/KBsCDuw
9AmWj/NyH/3GAw2h5JGYSeNavX9vCNpESq+y8y2BPZFalh3HkCcUtLHTCg83
fMBjhxA4IVzJ/vQ6r982YpcPwFcV0xW56upjafVIpBShJjL6I66njryR6czd
/cy4PszpCDGZ5aLY7JH3Qj2WouZR2l0vRn0O2WmGafKmQ+Ui/Iur7Gk6SlaH
F6VC1V6/0NxwnZe54F/BM2AfiyvecvQi1ZA6ltZzhF3AWfRC+oUTPp+mMBAu
KPsW/ok4A4VEFfdYPG/lW5Shb6FL7MxcXk+tp+xB5CPzEyncSbUKaRiUZMkP
593FtPmMUmm5pPL6LG0L2pNGXE4CtTW2w0FzK1bJJ3XtYkJGVxlrvOkpto+E
UZdPzXuAw3V0I1ViWbOSq64PiwxDGnqkhci4UfeXfN/5Sk8k0RyW7ay+ig+4
4TthPdBpJJjGBL1GA101Mzjs+4sd44TL0GAIeErVmlwurwa5fXJdaNu+nvkx
lCMIXxnvNepNUQT9RdWT80FVHYUMdbsUY5G5vuzKy4YdsNp1XF2jWJFNi7Pv
yqMkwO1IbFQtVMr8RMaxXANdaozq5IYaZTkiosI9tKRgRopveqzLnthAilSn
vf+c12rka87roduO71/RXoKWgLpxUw2/heKyNqkMkd+fULy0K8Xnm7ioz3Dp
Rha86U74AmbZ9hlVtLclECHst83HH2okCj5Asnjz6JH6Gz782EvQRvAiFN+0
ZmWGNmnIJS1RG7uXVcTsQnfbeeJPqDDao2ZvD5PalflDM9pxFO/ewE2DwEX+
nTgwaS77O7tjNf6wefBd80MyFd60qNr8QVzdm5vNRnD7cF3/uzfE9Y6dURjm
1ZojUifN7C6Dhzs7zG7vZ4a7xopKFpdVo9WZcX4CLyYDS+JXsYiyZEXl3jMY
/0riwlQs1JxEy9POalfbTs000JxjoHFNu7LzueuOqrmP3W13XCVXqpQmeNNd
Z3VMd9wNPElWn2yW08ZzXgSIyptDuhqzS1PvxoS9QoA8FIRIRpQ5Ycda8Rxi
33oD3Rtys1wc0+1p3Xf9oVTSn9fCz0Qz+/nv7/C/3PbzUWXlHqnNeJefHxq9
aU7+8tVhZEd/74xsRB/9zBGlofH703ye07pHtwj1+3GCWdX3VBv1B39T6kdj
7/vYnfjB76wzuTndKyPj10qqMtx72cPMXR41cemrKRXrV9V0pQ/krr6pf/35
U/1+kmLH3o+kObLEaaF3rP8oaf7Q5BLAm+460tt37An8oZIOsMgfNc5uh4d/
uOuIPrrl4zuT5lgh3Xppf/L7dz71+fs/49Rnr35KzaZj/13zX6e+fv/f49SP
TOn/X6d+5NB/FC+ZG0+9P/T08H+d+pGlvdtPderTof/oP+Jd/3f//OlnyoEk
SRZYtG8LlP7aGLg936yvXp/DTMVHWkyRe1zU+ql65z5XWzdIvcISN1N4KprI
zZGd7osnzwCBMlew66ECFg8tGyPZ5D1H7OPgLexVo/TIcH1x0VEFSSaKlvNJ
rgy023yL5nq16li5qtNYUq/DkfYgv/EbjfmXzmu/pSqUYsvmgEQOSjOMMGpy
5sJkNPI7cw2kCcBvzOEOcSTb87Vi+UqzW6npImbYvGXS7IL3Y3hI1Nz6hQwO
N6fHBmXmfBzbqnC0j+RJZVx0m6aV9SMD7Le44ONue3X5WdSTj/e9E5oipA+C
m1HzSF+a8pLsW7xxHqLBj5fh1V+OFdL2NWlmaXgzgYFS8ifqT+Z3MgBI+UUx
j2XFL9rlnJDi5GRsiEA77aLe+nqVRlbmZVbSoQgA+McuU6RigFBS+qfQ8IyI
yKnpoMoEVJOTkvpp8xM2YU9JliDwKo5qQGi1cBXB/tt0h8fnLWU5RfllkEwD
RXRZbrp2cc0OBw4QJxyKUyLgi454Vz9c0KCktH0XBm5KfGkSMMRofBIisEYM
sUykDFCjtoauWwT9smjI4TKwsxtZL7LMlBYfjwt4A3VWhjxQ8AuGwsni1OrV
pt9aXUvag8CJnnHCzFqpqAH5aYiO/6hleOeb9TCYsZq88es1sldWhMGIhJ3+
LGeJrzV/o+kGqkTWD+fwc6dVVH8oWUIZedzG174mF/C2mS8p3TRSPPXw36/a
1fbqIt4L5A0Afp8HZoCDmwN+CLmHd9A5P5f9WYdcu/iww2AD0IHVkNK0/X55
reNL4T3P1pt37WbBwX7z62b/2fEBDezFetgeUvDTZn3Rx80+lmmE/ReP4xOv
r9p4L24BHD1UjjxKzF4t+zedcTyuMmh4kLJZgXGIr9PIqWtuSwFxXZEGLfas
dLqY0MoMWJpTnJ7DRU8229MrLf5CLh7Dn6BSDOJiaDb98EaOhy3vKcMQ84wX
ISXZzgVMx1oHzow0j/m+OneUWKAgv45Ez1DGfaJodAoLHKP1woENJiLBTBt3
Z9CzCXg+Dnx9FtJIDQLyrJ2jqCQtWTzkKPms1WLjFSR/4MKeI7Fi0sS5UEA/
pS2fMmokpUWzm8/Xg44kTRnSG6q4tbwWaGFafPXmcExaIwDb5HojtwJWgt/F
yhNUaM+Vu6zuCzljn7rTzeO3e1eiYdxg1OGUoujwWhiNf614E62jQlmDX0tW
OMy7RYEWn4yoyPicBRk/7C8FKmXFlUbJXy9X+Cs4cv6WcnUB+7FpLggRBFM0
3pmNTbL926WcEIEhfxjXp/CttYbEKn7deAPwBUD6q4UtaGIiA23KwYJLeuX8
g1mBaDnJWQeyB7hUjoWLJx8vHeQiWqS43mWuaoRuXlF07XC10RRPnZ0MLIw5
LsGtmMqc5dsv3yQbf5Q3RsbLKYvwLlv9T7QsBdtocwyHCV8gQm8M4rkAeNZL
QiCeE3EKyLNCPMceBOF5V0uO1K0xEj6kodPIeOfn+7/IWn1p3cX2/0hbkHvj
pNcoMr0p8aM95Xz+ZCpPZPDROreHom0pbODwRuPz0rNp4vp0PbZ4ADHCqrUq
5s+i/uhbi/z7kf7nXlutV3P1UObTEb8VWBQuSsvn4vM5WDgt0rldZvLMGp6J
/znkTVu9NMMexP3UxO1ZROZj6a9F4tmE+U2gvy0IkLQ9y/BKWZy53I0xpiRf
DFvqJQUNB5abjk+XyH8Jj6TVl8AADfqGFmZwcC9BnVCQ+Oi07WRXLg5Llzie
lT/Ggy9qQhbnI6FlM7+Qs6QjoMzLyKENFl1Em2IBQEO3terW0tNj3VtJW6ao
Fj3NBEKYhq7wSBR+S8XMSwbI8t+q7jWFi1EowzOUyMruoYnfHQ3KlCzcKvI7
22DiWZKvYUmshpuf0Z7Cl06bY1eFc8JEm6KqFYl6pPTdSOBuRtz9IgXdPvh1
45Db5ZP5+mq1/S0zNJ8PWyhmOLec6EWWvZ787S75a//+BCc4fnGAZ3v2iOK5
MlmqaotwcrVI9PBmtP6dji5pbC4jTfz/97OPqiH6YR0++I4HbE/HTw58khv9
PMoekaQeqa6XJ6xCtNGMVanDOJKsyjFwUopB/ddhppObjYHP42kvQTpqnnE9
GJWkxNkcN3Q0YnW73lL1BMs3gtxHYQNNBq4m/XCgmkJlbNevuRYSzrBPLvbW
rX3kgMXH9+TbPbDDU9KHo85hCMdIMT2Y1OS8w6t8/xb73/16t+6PJKTuMOym
7+tXKgN8+T1ohuivQUKkrgr/ntF99n0+2BuzZ+8+2NuWaeSVf7slefDzluST
f5clyZCyrZmf3s0d14TypH/GmlRphY/FBGNZ3ywZ+Lz01ovESDmM5501n6jD
bxyyDSMG79JAOKQVqed6s5JWxehiVg2yuLj833RIBIyu4JRTMbdz5psE71J6
S631WZw6wYBXuXIsVM1bQhWyHIw8vaJI7vdZ8gRN5NTt2Hdtn4wfHupA92+G
0mjqLOEsR7UYvQJojBZ/5R/NF1zsTTg6THo+SNAcDGWRpjs0x3/4+o/Pn5jB
qG2uVr0hZCBEys+Jg1qD5Z5I2hBGeI8rdK1IyZScUwcIum7Ou+VlIwhxpncF
T4sM4GJmn0yHJyXZ5bRSNfB4Ob2SZhkh0pQ5Hrxg/0oD6WW33QPyJz4/+uoo
EulrMvtYzXUq0skwg1aLIysScrEcDnWPDvlJVAt4BUuiZGG6lN3TeO/muRvi
scHUTd4PNdlCvoT4w3BLDD2vhWJbd1otgSuV0iUDKyLaXj59/PWXXz796snT
J6aDeMKXZc+SSHn4gcvSQuthk7BOC7A7JvbnuQp0Zl9mIvPdDm4tPCsGnKkr
aAwOGNgm1IqGhSQTDK8r63oryC7qxVJ4nHbZM6y2q3YWWP1ONneuvwM1HJjD
MrcqFal8j+vnhffvh6tT7MGhNULYlGSLEzOk8SB/ImlzWODSzO24mMdkdYE3
C6iqmSbSXHC5LMpH0J0Fs2KmzuvCYfCkQLDuMbCw6SlAWAErJWCMV5eX0Jto
dzXZx8TDy3bYSlsFLlW1gzJdsdIyO8ceHfmE1Tty9iaO6ZC3eDTtFXUFCFVr
LCtSNWnyK8S7ZL0Co5FrgLODtGSIoIiOZtaawsUmM/L9sUqK+FJmNWqcpAOj
zwcxsfH+eljOAazDg75LnqlmzBp0JrGhqPjTUoirIc0FVIvxD8Fg/q00DJsI
+jPt8p4LFjG0KmcanzZHnF0RtW6iG8MvP1MaSz5DzSpm52DyBiEdhMq8dlwj
iEeKA7Lpln1L0I0SEmIG9V5MrE226sp10CIjHO6zx4wqHASypMTWeFjs9D6L
l8QByyFst8BXhujeDmQ9SRCFvCvcQUjg8RmlFNDJ4iKPyzSs1ytV/320wIJQ
mimOAOO4lt4pT449oIcLSS704TLiaKiycQV5FP4hbb4xBEwFdhVXmpW+CaGC
qNaM5JG8y2z34hC5Sokr+ZklnyOvUXPpXHLJ2KnRFaAjIgtAJiiY5KVMRbzy
om5LdnnLl9xnBFaBN4s7erhdH9K/6RHESRxw5p5Lu8S+2kPoFqQQH+koJ17M
wmJZafKJBT8x81I4T6jerh8ogAYi0d5/wLc2Q/8z7j+2T25XFsNLIAgYxMkG
Kep1xvlOo2CyYlDcwGtbw01oFXOq/UGNsbxgNUId3lOCDYX0BY5C5791SMFF
xq6Ek3vIXD9lKio/DOt5n2cIQhDLgIdbV9rVfAa+Vek0JEDyrxiwNQM6rEew
NfBvtSdqLbMEP/tV8CVXk2Gh2We/ECGV7X91kMqu0x9RzF1rno9v6yAzRyAd
ExDbf/nquxJV54eR3z4aUeuASUMtUVUoGsxejQsk+DiuPxn1Db3e2hcmO9JZ
U3Wmy2K95crmk3F8MboEZf9Q/k+WUXIrWo99YmWe5DPZapCIbGlOeHY5asYI
1IQU+gQsR6GqeLScpJ1jshLfWnaHxIyK8+jRdsgeFQrZL53FQ3qTKiS/Ok/1
xHHr6FnyRSDb4d+IhAzbbi+HUSxoyB47kdGZFh7798axO3TpZMgdnQotuQd3
dVuWzcvkcaEBpNrorjZl8WBYOUqiIoEz8VyOnTmqBHnxah6ebdoLEdaJ08se
IyKw88WhLYPWRZIhf/XLeAkhQ3pfUIXcAwfx+z+UAIQD+edSCJVoVPSoU9bt
YT0kZdN2HJbr9Rtk8shdwlU4LC1b16EnN6dWtWGnzao5enr0xCGo0+t2HGrs
KQplCKNYS4J8bMX2ON5Be0sOZE7q5JsyATPi7ZGpT4qTywVJTUHmCMSgeFBC
JHtR/cMVJh+f800UxUyCOMyfnRSAy6gMl2HkA3N4uQSM/F661/dE90/QAWf9
a7pZCUhxyGmSM+fj/682ggOjLkm9PsPupTDKh3wjrz9h+eZKSq4MUhhaoklC
lCwHRv/xLRW8bixz6/ch5wPTw48O2STqSgM+lWeehaIwYFb4J+MGH2dFNf/w
8n7THL28j5DjL+5XJq4fmjGr6g/MlL4aeb785OjlA277wU9se+T5uu1PCrZ1
fPtO7zVeUDwU1QqAbzk9cn3gQY21pPvKA5Q+qUSVnclWbsnwCtDHNXaKF1Hl
wvKN6WUKotW7NHiuK5eoWuqGsUPp6Kpx7Eoicrvwt8MtKlR8zJwFIcgakKFt
OXi2/aRcEIc6wG9oQ1hDgHJBvTSLq40hXomGhuNf9AbH/ldfv/JatnQXEMKD
aDsyKGm8Wwh0dUxMVtdgLRV2enc6K+RngUWmTeH9mQr+K4e0OgM6LDkI0hqc
MCsqp9asD7nQXNuiy+5KkOXfG+sqTdO3oDOPvOhRmmfpe9guNboVlrvT/nVD
vImMS6gYnjGdMaHgbyqL6MFz6JJuciSIYFui+PG3CWhk+tVKRRCRerR9PPiT
m4/kw41L6292tC7ZbyNt/6neFGrYoo3/lkSn1Fy2GB89cF7mSTOTeQqQuIxr
5hUX9jGj/hRAoa1sD1/o8TWVEPRsQfW8SMrS6XUoAlbYhPekW3ZsODTkczY1
9xdkP25Z4l/QU/DpWOQkcTAi4rfJkpwZUK7hWj6hE3BFiULTBlzRv8K1rYa2
x6mNBzg9TeG8UXA65spk+bmmaA8yKJAhl6KFr0nH42/aBAbNIcEfxo9Q2xIr
hU/HuO1x8g/oEKbNPkx5ryk0lwr+NjpPL6ZkoNgOxr04fZRrzpt9rHbUbRku
P2lmGQoyfeAxXmeTMGo1SJ0SRFXSutpMzyJ7tNUzM3VqCglad63NVX1ZCfpc
kjhoVzkm70LKfC2vhTbCPhGHRUu0Csx0wBycUwHMk6SFMLcSXEic9UyimweJ
biZqJvO0iY3TRlMcvjz6Nu5qFOyuVrpdyUtDLhrA7cMYtelaMvuRTbG9oKgJ
LAHCsNcQVZedBtmzNU2F2jituLOb67LuIxUvIGtwsVimX+wkTtqfMCIOO4ub
XqdOWC8KpiLeRMuYPDeTm2Aq4DJaTYQRmGA5aYCBhnp/XrgNsmYwRWbEjwFo
zBxvMBffAdVWZJohU9d0O2rtWp8BLEdv92ZVVkHIc0msPKrPumhWhw8mdMZR
8WOR3eGloaGqyWu2NrEHcrn0HgV/uPDLRCbMgvffytazmGtSFN0mpcoxBHw/
pjPL9fUcV4yw/rHncBHJU1zHHCZcsgBrCHg1V4N9z8REE1B/JMAqmPrD0aT5
DFzxsRi1VRzksCQt15nOVxEsqDSMFX3CwX/OTGo1jB5MNMODbPKSlbRwDZRv
3g/73fR1vFgXnD2WnVE9mwcc2STlvSikdZJTuDo/zV2gBG7wb3TavnjgDtxX
Dxy+Kd8qbFxnAfXDyuNmMr5QR1RT0FxUheRp6BD69ZMJlQD9fbMfF6GFNTse
gd9rcOnYSUnIkCD6gwyU7qbbw8VpsJhbHFTXclF+APW3dcvlwtp0Uul8H4WP
ZSEPuBDFfbT/1X2Gre7MOmFlLmoGW+/4h6SGSQveDHl2tcF4EmveZXkns8xL
HkQy/VMTVbWIQUn2w6j5wlqTOk4V8gbz7rLmE3cXBwYvaM2YF+38DVt0Pncg
sWftvF/2Wz1KrVYYJuZlmaVxZOpzIz93EAMCZ+Fwq5Jh0R0mrFoGdpFgD/B/
AbqtSyu3cJeR7AW0XDSp6QAauEpWzAf0iLlZFE+UpulDnM3JJo5S3IVRsZ2E
T6ak1ya4XTwprjjygaIkWJLgKshKg+fklknU3o+v7Skk9R5XIgu/mIr7ge1g
vox7KmzOSTLwDnqsTa0TbUIK9eI6Zc3whV93i4Vh+fSKsY5Q8EnkbvG3Rw00
pJKjgrbjstxwcbfAfhso2XV/ID/T+zgz2edDvIo604+1YFOUcowdU19CASkY
3A93uw6yHel7t3fD1JekIVLn+xX42XrTZ1to8SXJFJ+YU6jUiwIydyK1Zqxt
CUmKQpji8+GmzJack74Wlmgo+9I0z/s33bte2bsrGyUhsNJJ4CJnI9H5EwcO
aJlbntliHYB8Ze50/owxhCUtmUGXksMtlfxMQhwP+t4QMr/8+BFUey1VnaSR
p1fyeblkr4t2yZk+sqHpFe+akBAFDZVpZsfxMVNHZhrdj5CnMEsDe/XZsVp9
Z4JGp4mxgvmIez/eW3L0BGI5x5cKxTx2IeLtAKC+C/A05egyljuxYCVl/s7K
qhqd3AIgTV9+HLVNv0ZQ6rOFIZ+I//vgFvy99HCJtvcfZd4/5hNS4LizlHkj
khrpgI565+1m04u7wWJFFFOfSVsiNvptAA37QnE4ejJlV5WTPnZ9iH1fgO3B
tRRqbfzdNAQ5rOVzwo5TH8FHmnbfk0hHaePI6tNW7QbQO1Euk7VIJBpyIUDN
Wkr4Osu8d9Pi5TpaLCzsduqwyh1rm87by/aURIie68dzFhylQPqICBlWvII9
s584kGDGiJ2olETY4228IKz/j40oBE2WLj65SlKwk7Hi3MdVvuuiK7PsVYlK
Ui4W9mQUezKsrST2TA8UqsKLMuzk/xL59AP1FvKcbr6dh/ZMFBGq2/h60y40
DmxI2h/hbFIAsjOn75NHuB/mV8OgxnWO+MN1hFjAA82+GLbkoYEIgDTwLTNE
Mq0ogXzsd4Js/W77d+11XeBbyC8Vl17lR1BvBsVAJDVRRAlSEx2qsq+gzree
g2cmOSANowJulqqRp13dyi5CZYbfUDiVX9Tw/r20jkevyS97teLqz50fbONu
o2xAOuN4PCkCMRnusU2ci9P6tzXxSmU0mYLYhTjz7/cvnx4dPw0ez12ikX3S
q5QgFrkMsS+M1oyh6DxcK2xbddv1J7reBVpGxLB+QeGrGLR70MDXT/OC0m1z
RqHsW5KToHIJtrxnLQMIf7luF5pF7E1Uk9jk2VqzpyHLkgVmTUKyF+p9dPOu
fkyBr3pxDE5VZkxYGpcpMWvfuQhJmHI1GrbdJc/8T8Vd4o8bxORSjakvFxQq
hf2JwTGYpD0s+Ww61pWXPOtWrcou+wvdRdM07TySjSZYv39P7aDS/eFbowxE
ntd9Ohzr8gJLPaYVSxJ8aHCc3EG1O2F8dqkKrGMJhYic5ZGaHU3fDI0z3SXx
GRF2UvNEeCo5SS2aVzAjVPwX4ZQDeox6qeE9OesUDPC1v4GDVCtfjZRXcItz
NZA9KhLnxwaCIWggwpkzXmLj41A3CtBUz/zWygzxQ58/mRQlXVeLIBHlnr9l
ZWDJenWWsTCWNgY9let8irxLMF6T4UBW0iQt5XPPukjcmW5YRoiCvQSslBR/
7iQNoTxLbugZBbNem/i+pitoHDRwA8QEYyHO1bU8ySYPBi+1w8OsFH+SONBr
Ycxc/a1kzDkd7lXYZcwQi9spAeGu2ZpkUg/42nLpwrp/L9tsyTZiTIRYz9ei
mCEJBD1Vib4H4ZKQHaJouKSIpHhvRJZGsucpTxD87zyKEHEggg/GKzL4fA6T
hRPBcbJ4T6HJWwrf7KloxbxLx/KJ2Emb427ztp9HwThzZcRJXrRvSkJu2lCB
t1SJ8qhhm6e8lp2R/SIQbPrF5dYcPXKhvrbVpHP7ehmXYhn7ExvBKUnPir5i
FEJMgyzr8Rp8zYhJwifUJ0ANkLDx+ZPdhxk0RsVrx26XHA8sLQpunc89VFvc
rCwSJEXM+mqzfPrZikoACx8a4CWZoh42R2ySytkdcd2JVquX1F4JBgcuFfN3
6HXqKXKyvpk+eOroVEmXOuQNJKFR5Xr3INI5Hjb38QccCVx//pV6SrhsBrMs
xGtnIcZ47fEuKH1uZhdue+pfLK802HGMhoz0+D1jUvGt1bW5KjLeSijX52su
SRC387GgmN1YaYE3jX286voqi9zpikuyQx6ng22Cme9QQ8HplueFYryUdrRa
hBbAoMNzfVMhDU7z31EQgo1aVeiQWE8P82D5cmC4L6VkzGxnfQzlNRjHTSDo
Kq2PzHZ80VILViIqCg1b1isF1jzfX861yIqKjB9URhm7DumwL0p0mhJJMnLb
7XzaWAWXwYV4DpLmExK/VDB3X+Oo+dvVQHouwgGv5XKv80MmcpEMwVsJ8v7G
5IO8+FRUwBxonWBzjI7KwCizeni5B8NQ1ciBRNehgQ1iBIix8lc5iuF1Pb48
vZYcHKnBU1r+9+uAbIGiPHzbt4dS3vdQHo+6OCmt4pEpAed4fYJY130z+sgh
e8kGWNqRJh3Zz7y/VEgiZmuKIzZXR0LkUl17sVRbt/gyie51ylbCh6VYzdoA
fya+Q59krIw2A55lzr+7pz7tQeLK4kLJbcJ3P24oHt5pN28l6WbTXcRPhnC1
SnBYsb8eoW1UkoWC/DgiIN37rV7oKz/JoLlHnaJwws4hrWX7e4Hy75ZRTiRJ
CrDTTKxwCl1jPj84ZRimjNPTq3651WzT/37Vk537sZP/5DonxvH6KmXgmIR+
gQzLZt5tkOa04Ta4RFd81KW1bbWkGh0QxAtFErm4uph4cS9P19I0L/WuFCpn
GFU5e7i8qBNx9VH1MT8sSQzkoSM8KzkokD7Ly3CSi8HJ3OYhTlNNtlEru12P
QJWyJlBMJtm/lbEx9JT8UTzz2AQNPJXkDvfcj7aFfgetKKPAR/IkloiNxD1n
V/gksbxJKd2wjZEjW4iXnnaZyB527SELqMnmePkTTJghM2FSuuGF+QN7Ok/0
XdIYhNbE3Eqkw0mICbgojK1PyuZLtkyRZ6eNL43C8VPUZtxiMJFQLpBELDnU
uIkR7xkwkOSIZQocgjzj13Oei+K8Gb6bxePm0Q9xmemaEq5KMfol/J14YwGD
eLUZOiwcV5ta9tBXBPRUYGp0FUxf4LzK2OZVp5YxMF6gnZEKVKS9eZ11YzLM
ZGfdueDqzsXd7y6wTWxX6QlNzBecvP1kwjsvTw2ZxT1bb9rCSt/UMIykd4Il
9gU4tZpOLDLDCzKncgUlpOpCRYEWmeoWg4E5VAYzkTMNxzsPKmJvlsH1UuFm
ucRxnsnOGZw+F9WgiJ1uFVu7yciHcIQ89Tv1qljTL7sctlhufe4n3u8UlHB7
K3ILAXxRB1S0TFEHuxtSpFK4cVnlkzbVTERwYWkjOOqAWBh0p8H3yLYYHlgh
J4EBf5g7tiaV0z1Vs5SInxGTvq8NV9QTlltFK4dywLMKaurJNxoazQX1NXd1
XtKQebyyopp5n1VvD6Zu5voQvjSMgxIPjSZI95ODMBCP95WtZEPf0n4pyB8r
J2UxUL9HactNl+EpSIPqZVRHndMKgbHhZJ4RavNQwmLf4lQ1FvzkqAO+XVT3
OjkXYqgmtiVTXGb06c9Ki31xElJMAom7uoPulGE8HOP2yQGQMGCARKD0+uyM
3pooZkfeU5xE5IwiICcJi4yD8QIwfI9lvHzEMgZMGAqy2F5JSDFvlkwhEF5v
XKGr+Zu4Ott3KM6J8X2C8f0irurLAmgjEYKRQJ1F0itemmR20DIehVHYJGGs
FcEx8E3dTR7OIRcNc/pjwRppPlOsEeL1iYWL0ChIrwr9RIVwtxJpZ/Csehma
BJBA90E3zhPaFuRNQeEWA051IVWhUSgUIkDBh7+RhbMhmlmfUw2sWm5GG0Xk
VuFvpCOm3U+JsT+WQVVM19feJQ48aA5lWkZIlXalh6YZx8O6jY80M4aEmQHC
CJQqbheChLiyaCUHTlp5UcehIlNAFhqDqhalQc7D1EDVEehBuqiOO3WLZmx5
NN6uS1uaJI6jPPaDxQh93Ssp2aLtXKuQr1UzGg6S9kYQkYaM3PCqULyAkYHJ
zQ34noSe825Okkqq7GzxH7gJnc42UxNhcfeIE0lvN3MQ+lLv7ph8+BPvsQ85
gy336QOhTGeKh3HnsJfaP4rON/3rPuqSQavEN1qUY64AZS3nxcX90JcHn2Wz
h9b3BP6FXIRWgp4gMmA485A4ruJ20jOGMpyjoUjvPi4q0U2NAn4LF85I49+O
C2fd7OTCYi632jIhfK3GWEPwT1LtBLaPJEwzwwSqiyQhF+pQYJynd61CKdCj
stacB+1UoEgtKK1xSQD/CdPHcrCmZMD68vnxRHKdrwyxBl7VOetYsOfBUb99
tz5EQrTYt1zgLy8iYfyocyQ1dLpZt4s50kfW2bUNJpBXtB4Tuvlx+MRdmXlr
ta5JwIwBNi46hBkkO4+1W/iq80SzG8YKY5wkWPY8YjwNYyQ5n2OdHNE63Wii
UhihUdClFuT6jat6qoZANULSuxmOInNgqZzzyhYBVQS6SFtvNQKd5gYX+/r1
pr087+dilk24ZwmuOd4HxUJplVMxQglumxYZQEt8WMExN2y5iBf+HmN+7UH5
g5YM1xvFtCg/WEisrjSS7SUZCIiOD9mHI1WLwFOn4ZtUXcg86E5B5SOjtzZP
VsDehub+9/eLH037p/mHVheHzPMSQj+PZ0E8yVlpWfQ63zj7TFxqLcEiOxWC
s+dvcqmjLYoyp/rWjuotFDhI0Vsn/McTTfzIgTh//HG8nrsRqEL+A6xIMlYE
udlb5UaiSHdY7Nhal0DjRe3KnlHQePqBKaVdLB42oz9Hi8Vv82fZpjL2OJcG
KR5nI/XY4y/xTfF4FJh2jMSz/qoPIqnxPkiDKR63GkPVW74mUvESa4dyGZ10
zu04blni139kqHteezGEfp2nUdXlv9Xray9OUlBuLkL5aOseN1reHMHzPaH0
NNZaRwssJ2gPKdqeD4hsg5rJtfNltV2N2BWmQeJcOPxLTIfEuyxRUqJYMj6d
tIF5C/kvC7KQE7dVrUgLUYmDZjgnz5JbwK83L7szGdABH3Dy/27KejjEIT4g
mo+icB6pC8tpNyhqR5vwAtmBb0DwTtnRJJSQeed2WOrdey6ek8gHR5CBX4sx
gc2ZsXJbxYfplz58J2SZJ0UEmnRAAgRJcHQPwHwhQHoZh6xKCdFNp+AGmmyM
1gQFqh+gqaar0nDchuQuQiZPuredzED4KEGXVCwbUD+Roek6cvDFhSJUtIZi
RAREm8bYnW0vosAlvnePbbYFFod6/BnnjnqdyDi/3wb3kuw4ELfEffw5Tc43
DPFQbq+t4GGBr3AQW7AGELD3Od/N12mpnmdl6XheD3O4Z+vtbVJ4MJFIcs81
Cmpk0lOOsEtpNyPjSxNkdanw41Ke2+r1YWQ8h7gC6A8eCMOrcv8UuYQcmmwg
VFumaU6X7eoND4cW4JmaDsiszt8hMkGy0ZlygPbDElmW7MsLxjGvWwlpmcCP
/vzeoPtMOPzK5a5WF93mdbc44THPmHxtwSk8EiAF3bag3edcY4S2BH87hk4P
mlYn2r6mUyD0AT1XCU4jwaa8k5H6hGPxzYvzK/W5PI+g+KKLnuCFszJydGTM
MbCAqoKEIWOum45hmoXiKQkyLlaplzJpsBkPEtJikdwPNBllf4IKOMr9xtJX
fjSBQpnfyNwK/pcGl75CRK6+nIyZd43KDeMqDTPIwZVEU7mc1IkUWjcWxfyS
F3bHutqeQD1g8kksqlgDau4zHAb6sjoQw84TYf1m/CoeC6YoFs5o8vzbrotw
aw6fNG53nGYs/i1mfEvj92BjuPFCZHgZfYmdyywwMjlUA6upIfXOJ0lL7ami
Q3qxcZNgZ3h6655r33ff8pp9gzvAIgNgfR0qZTxGpvKcvS390Phh5aTjmY7I
IcwXgRDx9xDG85wQKBLwamUFuLQKoPJzdwMMV6f49ipOcikXEHEexZ4gOOfG
ce40dAW58M2k4Gh8zHdC/u457hwmsucmQPYDX+xcsCDjUBK2M/vkXyM5MFNX
789sgSI8zH+HC8KGG7YaLnmFiBUqQBvfbD5tns+E53p9hAhm3DRVgEDL4VEh
knK7pYgnxaAhDocLRDU7SjlVtQ7bxdt2Ndfd8MVpbysdFFWtshCXna3xyeQn
DIFsZwXFk0yxuerMELuzoYTPbLYLMk4QFj7r2SUqe5xCdhgzl68Hbz9I6UHF
jCmvcCaF08hzpwlUpdFwBqvhzH0PH870509Krb2hccD0hBfOapHMaQx3/sZZ
xeZsXneelXowzGbunRU8lzE/QyifVSt36auYcv6QrARpluO2PqsCllVfHK1S
MhHXnwWmcHhuVpWkjnlNp0wwXp3bN7DBNZVfGsZqNGUP7SiLNoRM/5jqPQoX
Kq6rPGQhi1U1vrDOYyUSuYPBJw+vD9XIAvwQx05uO06msKg0xf3f5KZnn7Ao
0LdlFQWtHJ4Hl8C+DDAaF96AGIbzKw59oJQPc5uw/W2ULUkKdVVT8GdkSt+Q
9awWIRMi8l0ZESLKVGK6kgeIPyu/wsHi78UYUjlUd8oS+RBgbOyxhNYkSAqB
BOswqJev8uuNR5ZMRtJ3Nj3FdLecnFmzUBJ7P0DNnmQPgwQ+XjS8T1gpvl4p
xqPeDoQFt2ZDDhwCNFJsvrEqCnaBIhbVOYbYRXBT5KPQVKosLrufG/iEBm4R
77M5O4nPFk0vXzYCwA5ts3PVyD14dMmiLES53gmwW1++faTym4X1ffH0y4af
E/6zI+wtHO34pt7UuHds8s2sOFneLkwVme0vz3Ub3aIbzugui6rs1x1Gnsfw
2Q3Thttj+MDD1hdZHFuii8XaR+8FPCgPjMdW7ie3OTuUsyq+8DnNXb3f7vv8
aVELDu7AR25bFoMmHldJodA4dA/zXvoURtXcxgLIEqJUCrVgE4IckAunIo6R
kYq2EijGIIwk5dPsAL8SP+/ULMGFsWkzCElsQybIo5WPkh4khl0sLMir6TVN
VdBsDVpOSUcppTftAWaMOFzCcUxRWgjDqFaCzoyGnLKnKzbnYrbDSAZM8i1V
0j50may4Sh3lLOAT7WsHdJevKgWj5+x83AlmLs6U2SgxiYXzF/5kkmnVDj9Y
XbX0kJT8giN22ny96gSjTd1kWrRnpqxvhvCVbkMurcDM5+xq2eTlvwthh9JX
rrbrC7Q3SO4he9nFV0wX5kZo250fvYgiVSX4z34lFYQ4h5v14/6CoUO1PTZv
BZi3lteH5zjxw7Y906o8TapQnGQ8lpmi9LQ8fLfeRPa97dqLKd2obv5Ckzx+
3PKVcDBhlzditUkI4xoyzeV62c8pvu51y/c84WVYCvymgH7FjTK27I2FLnME
lZSSNxSyVApebXqaXmHVIFyUVXVxM71azyeCqzbLD62smB4/DWYrsh1oDhIf
MkJWzSzuzgnvx4muXTbTRGAE2xLKUI2cx85xkS+6S3p/RYk+lD633qiE7jHd
2hUVEVT3EPctMdQlKJmE8dipTJ4RqXGBgo3bYJ0titgbF7ty5AQp42ap8vVq
K4XXkEFawvXEAWbWyMAlfpD1+dbKCESV0NKMsnpW5GcjyL4ub1ernlmVBS/T
SWaExl+0IweBAn4UMSyZbW/GmpkwyeU2CX5Fa5hxj2GsR9yEs7hHM/qX2QZ+
pSJo/BEMAfTrLn/wjBLkPMxg1cvgfQLFvIqcOqR8BVOwO7ENtYODAmuar+IN
ddP6EBYYXMQAdOGviOylr+66WJuRISOnMOpiVxcrXy671/qgy+4tyfl5dMM+
F1nUoR1iaJTEx/UIEaGw9SXT+Jpy99SxLJiJMwXz2sFClA0pNHueoGGiM6Ni
+8i21aKsqIZKODwIq8d2SV7L7VZSwzqqBl4f4dt9vsfaU8L0yvDnSJVNWVdu
oF6R4RX6LaP+pA+acoUgWUN+djEwzXMSwzw+jWWXSAhwpu9fSJZCEUOeDDzm
FR4H/lKhT7VZn+FaoJkkvGoHWYyOFnF1hknDzJgf9bSs4xRfJTaFEqLW22RU
lnGErHdhpS4WobBVjZ3CxH+fQWSIpC9Fd6dRHCUep4OY6MBsALcbUwPHN7H/
wGci4Tbq3/aLK8/tVRYzr/+Q16cnQ5hMWOBmikZL91pKaVbAADVD1G9X3hiM
RjJUb3nZMCtlAJHGPo7LWbSoBzDqO9cWwoxisfAQK5qKWUpIrDOsIusC9nzf
ZDx1VkKX4uSwE+L90tchAMLTtR44NjryOhlsWV6ZXx12TzLP7PYMKQc14fVT
aUhnG0SwqEw6PjFvPxOS2dk1p6CajLcdjNFAFl8iTiXnec5HNaQ4GMnjC15q
u3GQBAEmdjR1FpU7HnzkSOZ0MreZ9F55FHes/Y7a1zIriStPlJUb2nc3e4vm
XRNDbfTbrl8zD5MUHMUISOrwGIEbhRZPZymbsEhNxkgdOrniTYRK1WhNgDJb
ouRgClFaZSONCUI+CtV+ETvYGIWNmhBHVqikwjH8Qg76VsZXpVWiruioRM+m
SZJy1ZXmOP4+ce+JqQLs0OFILsRrwiKjPFHeEbvQWMJ4Nlg+dEeIqnIXp7u5
IFA5aJXscuqr2u7xsnWre13iIe+IArsp4OEoL6hOsiGH/SSRtLGrGMK7y3O/
WnaFR0LyYbGGqdnDKDF2SxalBkPfawEdJ1lLtNbUHEqXRpKhG3EnEWjmc21Q
nmRX7mhq74jOkLw6+7yvrPn0KNPKUiucQoyB/vT7FvgPJLbkNvMPCWoA18Ya
CXUZg5NyYQkWgTHa7dqMuiT5TnIsu4uhowhyMIT62k0KtJNkipCdMCOPfxn/
ma+apKN0Xbp6kteAqjUgPNM3Hhj9T65FNQDraQFZinuTTWSEwkEpLJ6e4W9x
UHV6A9gEMCq9E1vBkc7yWJTqI7V3l1xQmC+frP5GOTweRH/Zrjja7l+6zfoW
XySe+2pdct5pMqndqIvRsUK+Ba+GKQx8vtKRDMv1634ubr31JnIVALeIDUAS
I6MC1oo+kq4ArRMUtUMaCIe/UznC6zy6GFqA1e3kBnkUGDlMwK2TmpjpqgOj
OV+/4++TTJpl1csFQaAmRI+mUqxHNQcX6myW7VCHjmqYiueTdBtlViIuz+Xi
piE7Bs+TzezM/GFVcAEccZa/Vczr72Bqn6iNmgm6ysNOoQy7nSbJVi6QTUNp
rOaQWwqriTucdWK464PAEXUUzCLLXggKys1g4qYgS0royhKGb/MrRKZ9AzoC
mpOXhCXRNZVLwXptqhUvw6yAI4TqVLhm+RaFKkCtFZrLKH3g8oRgRZtaNFDr
Gj+xgUKq3/H21mIJII1FeuzajSdBtPrcVf98cfxFKsW7Zu1kV2xE1QFhj9Zd
WIaQNGvwmeru45CiVD5U/RGxOY6aj62J2JNO8LQ6JTtEvUkj8EWospLg1bKS
P1x0ix78KT3W1nJUUSNPjMt5xjK6u0B7IHPLSB934uYZKMG5wDYxExXwpk1n
0JuEBSYrTWl6F2vzrhboKrfwcrG1hKPSVOELQNIr7JPO2MsEFSMpLgO2neXS
6qUkj9CUJPJerLxDZvQZcrcwkkV9+S91TtUQZxAY9RLKWTHUiSyczVMfIVtn
1xCAFCpBvHeo16fXVQ4IovomLHIFkxuGQlCHkqOazem1AhBuOPpR9MRpkzDZ
GPfljL0/tOTJrWa6adLcFADKjVOKpEmDgavYGLblkHwJ1mTkBCRSZv5l18mB
9oJqJ8W40+jU5Ju0X6RFmt0IcQ6+A8GBxC16lEAEU8JQghNJcm3S5VrpUkRB
au0QlHjohDgGaFOTabe6uoDBlOhrE6W1/fsHlMCgje4/wJ82g/1P8Pf+J7/6
1YHLvsL+17l01deNZtGVOXR4Yurz5zhjTb5+mNqyz36bHrPhPbTHiB7tY3o0
yxZDd7vy/piYjSIsZorBbNvl7/hGfBHl/E8R30stM3FZGEUNwUAms/UpL3IW
jcdak/NPWfEHZi3M/sgSXoX4CfC4IfYVhdMk3IcBn0rNkQ1+8cZTpvMuxUQI
MV1qSnBp8GDIrvn2itBlgyntPBpqsyrhhtDVdjWwbXrqSvmy0VtsLeI/fuzU
pAp92Azco6bm28yzh/RWrpU3RyNG42K1skCXlTOmJjXR0pd8qjNrzcgGUYVR
5m3x8uQGDMUFVWnwqsAT+6PKU1p2KIVa2KoVqPztMvOcSPqJN+AGt71ZvbJJ
csuMWDkghMGGIDPvN6UnEevj3/F0wX51lGBGNADgUhgU/GqJ+I7QFodDxbgn
Vwa0kdX/Ujz3My+5KWkNY6tEqAji8g8WBFKeyEGTETX/3C9SygJn3Ay5MRGv
JtGqDCbBoGoWnl7MjGweQtd2qVEbSXWLDGArJUrsFS6bITQ7MriJp7hCxQlU
BwtiBepJcTIixI4ES5Y8iUXDO0OmqFEJr3isNjdvACaa92IJVnwS+DpTw8eV
1M4kHshAvfbGLDKE+XZNDuzjqyhmWDc0k22RTgXDiEZ2+8wMkisYWBQMnFf3
UqvWlBVTAQKwAyqCVUkODjHPCTv6ZV2UCJqRJCtLsaXXOykDvbds/8f1Xm6Z
6odgkewaYW2WNYa0FtgGlAcbyUghcyKleNDtgwjGz6jELKx9iqeTG65yNkwg
tutLIDsriql/AcQUn1EajsrtfnvQKCRXnq3i1Ns42P3TA7I/dyV9DmFcCG35
hO8hs0b14j0xVDYZ6kYWdtMGvCHmSY6SSLHauQROiCMwuhvovIve6ZRAwp0I
5PVVVI/ihqjfya4PEiAaJTqORcWW3jEcg1sT27gMD7FjW/CkPN6iDLIII3EN
LGhAqcgCGPK22Ta6uoby0gpgUht2LbqcLzOX3vgcCywEbr/pT6+2AgiTv4Ib
AlwpKYp7WMqXRgve+FqNTAIo3LKOh1LEI+Ku+cqIoZhG80jWG0ovEFlhKIxp
jniCzjKxAgwcU5L4VgpBe9sLy1XJKsHQwQYRjxubHnT56VOFFOdnBYPZCt6L
oR7mTrquVQBSePNdZx9pxBLUOgjiRmoVJ0qX/RWI6FHzF84wxHAm+J2nwb9n
+BD80a5on/BdyDqIbZ/FJe2CaHAWVqrR7bbqD9Fu8W725w9adT772Tfz38Xw
+oTJbdVUkzwIoUfyzn7Z8UHz6FFzP7aevcTDaYcot23tFdr4/+NRs7paLg8E
xJdcWxcXLUWjTRyCZmQYEipGltiEKJrhNg+TMouFQH4EiGjV7OEe3bvLnSwK
fLKde833HnCDaK9wQvtUuC0FJ9o9+uLx8dj16IMVgGq0Bw9Bu9w5vOI4jfI8
vsPj4BLAwaUcLsx9CnkhBduQ/L26t9XR7hgszzaNF4ile4Ryf4fBrplREh3p
otraPDvWmtiuQ3o6P/N8n9PY6nQVSNfxDTn51JTHt/1AagL50KHwE90EngZK
f0C4ISlBzaBaPF6MnmJbafYiC9uzsgJg5gqimMvWCPfdi0pP/bTZ7ATjSMxy
Ki2Y7M2eEW/EqvS4F0w+kQ41CJdoMQtzCwwFZ8HbuumMqaey1yLpJbnlzfcT
j01IaeicbTJe2mOnkG3QuKVBwEq3jWEUBnvK+R05Bvv2HOuyptWo2+jUq+e7
lPHQ3KyOo4pIin+tgCh9iVe+u0w3CAoWa6Iqk1wyyVlMx26dl48VMw3kfqar
kceWYFaJ/G50k1UG2WrZEmwGkcKNjU04t8miQ2kdtfHD9jBbUqrpQRVW5v3C
SXNrW5jq1n+oMTCZKOAkE8qqVat2TuBmJMjg2dgKCTP9QSqlpRiBTaZNFIAo
oq+SSrHWqI1sWLBhcB3ETSdAiHBXSKNjYk2kYkI7/py1KXGiVOEMjJniR8EK
loCnpCR5XOk+yb6kBQuJTOFrRXr+4F5lOSlzaXXfX+px1grbYMOCCpNTQnMX
VBg3OQ8H48eVbj0NFOdl+2PKUjPt2inQhjSQ0e9o+Rm11yC17/Bt370bqIZ9
fPuQ3iJ7XKRbmpqWvqGd8RnI1BE7DbC/8tVfVh89+G4mXq9FXj8HFcIxTskW
5Nf38/e/mx2k1+U6S4xbFsJxpsZdF6NJWwU8TWKrqXQVNZnAsR82xw7/mxiC
b1YfZ5AwrvuUIfN5yCJ8oW/QwnK5IH5rqzWovO+rKDmFF3fXHbrjUJPjnHum
jrKlculU+5GfUC1Ak2jAPUVOv8VRfsC785SrKibpT/2wbFRE2q9a1xhTQ+g6
k2Eh45ZZpLfS7cQXi0yUkVQcC5k3fPckOqEEWaoJqcRmYMxOWyyoyo6jQgIJ
WJNavYS3pPKVLJFIXwjPceuUgEus3bN+yQiKfN5NtUItWmEokZu6ESrOU3aT
FPn7HzJm1/ZGlm0QULubShyLNCnz0RgT2cVA2uXykIqmiTkxoTHQlS94DM2+
iUmC1AD7nOcagngslstTCUH0lc0K+ITKLbEbPoGDDTieBeAJMnHwKLah3wSn
MB7JAGCXUm5Sm2ohehXwieNcLZPKpki8kA3J306Ho2QWtCyWcI7LRuAV8gby
XOmdQjMjEzMeFZHqdoTr5N0U0RHKH9RF7C3pFTHxKeObqgLKyIIZrDnI1BN/
QPPV2K7ZsenKxSEIieMXtYdJM5MKXu4TjDT9LQqxXWo+1iW7J4r12F2ML+lb
SFKzEepVXebfsuededldCgM6KqGuxjYZXdlG1+NFv7aJo4idoPMXUkR1e4uv
nUcEvmmtEgVjGR6qTBnZ6Zp9sEOeBzjJNnKW7MtugdKseR3dQ7T607FOyrzA
iXJ09KOaXtEw8/QT8siWJMzOpv3Y34Rx8A8Y77zCNJP1jxznnCIsRWqoWEeq
kTeiskOX57VjVHBUXZVjBuF35/GejJCOkQSfqh35aYN3rMkYghZAKUnoFgrS
wn/0OtdL9sWR0tmvIdv5FbmlltcapeV1EUCIxqWvkSzyepeY9r5ZjumMWnKf
xLpMmjtV7MOglHO7rUunkUnyHglcoDqku8jBqCSvsQa0pirXWCil9JK7YWo1
0xmpP1iXMczxLBMqqc+ekXOb4cat35EVHzFjFH0xj3+t7S0Ii05Y1vVg9aKS
ulwFmPyeTDpoIdQg3sKsFlCbH2YlQ52YJveDN/E406ofPcDqsqqoK92pboFt
OpY7QbgddPnISdrLAUMZ6hsy25vCFS7T96rWfn+mQeUHBZfwUTAF3o47rElS
TXQlydWCN5GeICoT+N1hYgZSCE80Ykn9zkOmHPKutKemw1denFJhzoUAm3So
WpA8G3YUPhluEL1ImIZB42pgIwvMOzdS+sS2nO3BVOJHDAVSGZOCJS/iCoSm
Xl+fZR57/0Mk/7daDl5C/6t3LqWMpQqRPUszvCDw1lKMw8YjFeWQLLn4X2dq
vXOAbun5cqLcnVbPYQ2niOt2IamZxE3flYGsFMm7cnCtvo5b2louEKJJcE1W
NitLY7XAm7oKTV3NmgxhNlTmSgY29zCDmePvGGbuYXLklgaEV6bGfv6kOqUK
jzdqRDDTri4lQJzhBpcyW3G71Y/AII11bvKtQDplBNtPNjzfDLDejAOsJyvr
T4VYpyH8cXXphEWZQXa1+UhUzxEfen7vaktAkuN4j0JaTPDzPhbhy6PHUmhK
VZpSSLxDR4W8uOh+lrx4k6hIPGHtragmNqLuONuZMlQRTElyohMe3HSMAFKi
rXSRb7k5OSrr400FuscIrWLSf2d8Ydk4hZj91PuBIy7ftv2Ssq7+s/kh6qWF
5MPKT+8FH8UFrBfAgCUan5UyksqOoEtE+dwz12/hYPD9x/by2CWX+rB7oBON
oEC2hebqXrtqnrR0/+l8DhRi2tb+AEUQJmfSDouxGRtkNmkhMj/Cn3TV6BvL
PKyP044EWs3KahyU+8mwvtrMDdE94fIwEiuv8kz7r24Ts7mypUO2usztHFzc
ReZacJERxvo9qnTZaRbp5myyGQI5rKgpu4joHdu+PstMWtnWc1dfElhb2ZLB
Hdeb9ne6aP7LF/If3xfypNvhC6Gl8XT299HADndHadk1gq28HSJ/JG/HzQb7
/y0ev50XgfNcdIuHd/Q1xJGV3oaf72v445hN3IKAaxNrNxRGVh9g3hgujX1d
YMP953Zu/ENN/v9Qg/8/zNx/B2N/+Fm2/sxWGrU30kn4nX5Q6XuSc5XTLjJ7
XgGfzsPxpYUVJYw6EjLP300mWX9oOUcU9Us5XteXxdIs//E9Mfuu+mrlaq9z
Ln2HeYTZOMTkeZ42TwkoV4MPQQc5IIXC7C5RACAjGSWSoBTMxEJpCMxaIDVL
Y0SdGxkagE5YdQm2HF9o/vsOsOqEy6qAlJpRfgoiv2wlblliqyy3pVD12fgm
8BsU63dRQguloqutSuqyVBKuz4kllLNGJkNbHkHeSBGohsQTqXYLIzuhqSNm
iB/ibWQEVlwPLD3vW41exgl903WXXNo5PSWrPZwDgoaKRyLXmu/apatVM1SM
gI/fgRVCA5hoSvmlZ0GEHJ2vFiiK/wXAdyIRwX99114P0+ZpTwI/yQcOTIfT
cz2g/0RSbKWE0NbATuKv8bHX55lu4jKXTtcUdEAwsdiS4FHIQQk95U8pO4hU
sV5vo1jYIse+3zTL9VztZrzuu7DqswOYBYXfAjxPX5KFpGQb/I3UumHAVf7o
Y/Z2fBNX7nkbmdP+dNLsmXX51WfHe5PG/3nQfPgxXhToczNBeExtelbyP1+d
dwWIpXIwB+91C1thVafGt2DkKJ/oJMgkiGJ2cEHIu2TYehDzaRcElVXSqPmG
GTSbp2a6xWBrxm/n14dCp0jcyhwGGkReJe6V+0xQZbMJy10DChGvbInveY0S
LuahjyC7eT9SbcenwnESemItqZLJk0BQMZFx3XS9UWGTSF775VXpvJSlSnAw
o2OeWfQNij7uJpA2riFDr96sqJRDjio9s/FNPfipqraR+iL/WySRIptbetnK
nhcpoYDu4ooize9fPj06fur7j9Rx3i0vJW2Y91TQgIX/QzADJhOPRGcRUitT
d1zLKWUHw09wQg4L9kIATfW0yyHH9KZmwp3mbLJKFk6qJACJUYdXSu8aETFI
4b1NJEKmU0q/UrgizoNcFf1EkXJdVgptZsYRZl4tMv2ejNzdKqkoyWOo+PZe
K4ebwBf6Yt41g0fKVSWV1Lpcn7bKuRx5sOnZQL9c8nPEQuzGTMeARSU3jYf/
W5n0jxn7NXDVeG3+N/aINW/7JPGISXtnRrSzh7NCQZo1X+SWOl8X/FiH0oPM
Nyv1nCHSCAPlS1A3tGguCNemcoGr18uR+iIQp5InkwZnGIjuyiUTH4nNAZJi
Lt+JJEL3gHr+xv1+bDlmQeZ1FNlWli3xKmtvDk1THifDlbamQGD5eInIyK5o
KHOts5rpq2e1ax7XQu0AXm/CqRRciYvqxY79LKkcdSJOFbWS4iN0hO/Wmyj5
R8VpidagE6RQjAOtqyrlpFhXSrC8qfS3Hmgdo+T+BagtZKCjUgIsIbUwkrqo
mW05eHZEUyIMr7212hMch6ynpPeXVGLpQ2rCNfAGA7TaKVGYG6+Cwkk3uKaI
yMr4YRtsOaG3CPKbir2UUJiYYd4UEl74bQM8V92UmK9pE4nvmv2VDXdlak9d
WPjzlQIzrVk8Skrl+DnTugtjJ2wSvEArSmzvb42c8rVK8fXFBVVKnuehLuG2
UJcRBV0EsuK5HkrTyvVMuaIFi+LLh+xrxChcHRQf74v4iEkoeIfAcwylwdAG
KBEy++RqlXpa+DheVAccacIqXm8g7EmEc7kCOM1QKvIBePuIJrECv8QJvInk
vVFCY5LYESthL7jkijz/xlJVoCoFYAYkAGYfUGORCqLa5xgKJVVRISatFqTV
x9M4U0TAi+MvQm3o0uiSwp6D00HaX5G0gxgUzroXHyp1x2tPkGYUKDvs0LJE
gXFWRVFhyODJsUA5LI68kNGi3OeGh5Pe/dS3/NswVhYxq0Mk0Ud5lwkSmXB4
UrEJao8om8uTscVcqfqERZFB2/txPMwp7+imOmfjUVLSvi0A1qYcBLEPmaTQ
iVMLU+2KFDtRURNYrbBFBsKI1Hl5nbHze0MoXH+v1JshqBJyWdgZLLoRyL0k
pwGwgnKeZ9LwCbU2Y6ci2+rAN6EMkDO12e+mr6PqbB3B6EA15elwackY8dI/
6ZY9YoOO+fMDBwrgDWJU2W65bl3iE+MKhfG7OJL51yt36qrVdNms6aLP4jdu
LClLC7QivAA1LAsJzCIb2UTdMRm0XVkUisZgW31hwzbnH/FIDOre4JHJvVOF
9EgYtMswCU+qGighFdCBwM5mAq2Azs5wNqy6UjWuXZmZQyI3bCJggbPlfWUI
t1UwGWHsRKWBqWmzEVu79z/NdhxUc2mo+NIuX6838Y+LIZu4BOb58VusYWL+
YtaPv53Qp7MqRpJsy/rIzHLWEnZPWoJpBXWwYwbNI2UVyZqkXUyaPVmpvYm4
7u70M8ZQpDqndnsQQjkMWe96GFiMnzaW8RGkQnkT2QpiwoJeIBF9Vcxbn0f0
ZezU7Bd8PsWvBh8k+T+7wUEzF5sZL7qa7GBU1dBqRlilLS+HROBXwuhcGVfQ
IOLrLLqODo+WctXQLJBi5rwAaAtOXhwUSP/ZLlnP7v4spLWIwbVStMdfkEer
il+c+Zdmkwzos3AScTKMsJR2K8fInsIxQPla/YTLzk7NP5SHbTuRnxlBda57
mJ00eKs4QlkndHCQ4ZoINh98pFg8uBd/if8dPT16Mv1qdRDc4O/SRnwsa+GN
0eufkspSxZSVocasGafH+lU8BWpg6RCUlKr7ZUaWqikqQ9hdlrFswsZfYVmd
4YhoLLMdpaCUtbL1OxqPRJJdSUALR/mspW5fGgnI3LC8254x1Gr+XoXS3NHe
pjh+eubpXrrJ+DbSU34DVuvsy7RWz8oZyFh9RgvkN38N5KYR29yOMKIqiCTb
kmw8Kf7E8KrhtU72Ue4ipTCsV4eMgkaettUWGzgZcaTu8feHGAdccMLq60QS
fpkiO9w7Anq0o3MzWbrQt4wcx+NIdlZCuH2OnKdKX2cSGH0l8aSzqxWqUy5O
OM/dp/qPbRO3k5VYoZ6LGDmzbmm8DU0rqn9UhEsjt9Iop2OdSRS8tV0BskWh
9l3XaS5+kT4i3WZLQVZnurdMHjWt3N4WfbdalNER8nJoBA6zmlU5tyQIZsFo
Mj52CngrtpwQLz7z+Bhb1IXTkWBrpXM0uMNETH86m92irXGl2JoIALGPbTO7
uKa5nzkPFovcwhbzsfooNqu2LfazJI17m9AOxj6VZX51XlcudQyy8AjmZV+z
5lx7PueIZKPeD0QrmSg0C83S1sBH68rGwdhvzbsAovxNl03hZOyxvCMlWHdt
pbNqHflQqiKkCarlNlvYXCh6mCVrSX87UraEGNPBSDOiA7Z216AEVPKVIAab
6gJNnNmuUs1L9wvDsOrcGCTZhQMDSo/V9kC/HrZYxhrlOJoQnM110iQ3wGa9
3vqDqIKhbjpoyNv1OPxhdCJpheoZGFMs5uGaNsN6atTnTNWNSaWuKt5rJ0W5
CKbSnJqdpzK9bZ0HuLEf2rLqQB7garuiqEoQ1A+NFHYnpLtgbeYqMjkBPlcp
7oYA04rjlDJL5UKvWFTiZDo1/07sXiV9Fpp2D6XmV9l23JyXX42zCC2TmEWS
0W5ZxOlujZOSyLjcguJu30nZI4Nere41OxKPqgXWVCOa0gMn3+Sd1M0iUjXD
svAWCc3Yam6qb8bbVonhk2YmGLIzlgNzWZjDB/JLaVqFmwyZ4p7Ea4vrLQZT
6uB+uuqELqqGrUUIFi/VRqSd4im7mic3lr6rV373hurq8ELkikLq1Y1NzWEk
zKTB27D8NuwavSYNXKLeNRd1M7ZdL8yuKbNcn027co+XyeCpjqnVVsBix24J
wK4fLth54h2tqfgqKWYKYUvuDjKnnXZiBqyrwB0oYvnWBZpZ8W4Gq1xfKYgj
o/8xOG5RLpoPMNgETC0UZ00+lWEg9XIXCGOUCclHr8BvUyAfbjlR/6Zq1DC9
c3kr1EjrxCJTLqZCorIWTw42hkI3B5MWuNhqEasEmaAe7mkd56dJrRS+zROs
ehZr7rU4BuZcYI+JIlmyvbiaQTO6NBXJUIx8VBNG4698I+JXZ22Nf8lVbJou
PbCL16fvEqdXEndVPmUptX+H/PqhK7htIgD7ebGY7+JhGFCvHZGRWjSXqL5e
sYnIPkJP5Fgh3S4xNCkL6Uofx0592WNXNh0aVsUld4U0krsqVSD2zfs6wy/o
T/EQXSFsYhT0EaofXO/ARpFgLF2DU5Q8YxeITS2oSVEzB4VSLqZNCuuNp7i9
AjeqTFW9xfTPGZ80SBxfv829VKcJgFgipoWbM/LnUFWjI9k2VP2J58pqa5FK
aJRA00z11Ntt/g3XVeeZJNEOufAEzpkFMo8aYqRs/SIdaQL/bs2OVzg9GLCb
kGAzp5vFfhMtop/Mmea8be/fyzdIqDm0L2AdeVWrnG0ubJBWzrIswYjIKXGv
cNyFuyKGAA7DyAAU+0C8qC9owzP/voqqUIKVcKFBUKYj+573qGlWXTAUgdMs
+zedlm/Wb6YZ4kC/0UpsQdg9qiO2ifrklvQx61IdsuhRsAi46G+bg2zsM2Ol
HjdSrETAfIPWG9KgIKkWSVo1or5Mt5asTCAtJBVzn+pOgViYO8f23iELEy8r
g/FhYwcpfFNxiucKkbTgooOw6q8bsdy7rEK2CTx28PyURmBhBiufUuzrD+np
cZHesWGZqsTYLwiK4AK37LnU/RBb6O6CGCzZ7NqMU7Zz5zGcEuHRjFSpzKzR
Yo9PCf6jWE0+HnM0/pKVcygoqeq7+lMsldTEvhz09UPGEB6FSkYgi8kUcJWU
QanGkdKSky5ganhlnTWEnjobg3de475JrdHbfXRdEpKLrkkpTSRAVue/PklJ
s9WWcqgaJyDsnS3bt+vNsNccHtJRIkraS7V2I9mifuH23Ieqp8sB8Yd78W69
Xs2z17TE42BXISMPxU10wPdauziud7wnKgZvDVvhDI0kiuTfbrft/I2vzTS3
0g3xsAfrNVGit2YgqGfLaChewrVM25SLwgkvoGvMYBIP8uu4rRecKqLQRBYY
qpGYzTcmIdM0JrAqgYVz0ZdTss6uJLwuVaeIu2Lz5YSNMqkjSU0oKRWpcL1a
uO/SgKGApAUnjBp3naRARoxsgSPAhe5IbGgtc8fdOfEhvkmKJPiiVnsbOKmf
a8Pr7QMLMK+GvQbfq0rEievvsbq9h4CrVAAC4PGxZTL4GriRYOx4QiNpb86R
nUx2Ik2IrUYTNL5R+2g8X4hgu4xdtZo4aCTG+ZoqKSU6w1M0wFZiVEVyctBa
vLuFiptLXi5MH8Wq+9VVfBnIHIe8WJbGa2zJAjENPIw911AhX4rr6hXdcBbO
ndeLyTIoJGpJa5ekAFW5WOSc+uJ2qoqU4AVO4hBuSxRgJjvToTS4VCjcOnLr
8hrygw+bynxyMGMhchgaRWAQgTiG/Weu7hfee3IsGTSWZIMYJ5jQLq+nByww
4PaVeIWgNtjMdlUv2UXXrpxLlMdQDDegHcxKom+jgqE1Li8iuYPk1XiWHJfs
3ogrisBkF6eU1WZT/867fjj3eUQ4az4hjMfGQaPx0C/tds0CjbMlHglD8+Fm
WKc63GzioQLaUnwWPUEd7abvkti7K2WBXE4oPgi0CK1AmGoQ0vdT+07rD8JO
Q8UFSTp42DTJe2Xiwm/zB9lS/7B5gX/xKH/kHkYVwq/wZ7D4Sfr708ZPFOGD
0AifVv7PYkUkozw7eGxZ5vh+hxcS2C2g5n2PlysPs7dSbOyvzn3xKEJzSTEo
fEyzUpYthOPD7fqQ0UL61SHneEdeS5a2djlGJdPmKTuAOShBejnttnCPEoun
VslOZigj9KEAkvCndGpfCcCKKW/oW8Ay0zhVWkLwHhfHxKoMVBRrmQoCue+h
npFr/MCCgfVoN7NP/nUxa9jPmkDu5Zv9xUcPDprD5sGMl1FT+kb3D6V5oMqd
ayE8QbJYn2H/e+pBbwOpMFaJ/mn/BhfuDxNzckZje5lpWdlF5FshU7qwTCv5
FKOGAioNsiKDc71IuC+Bt+gq3khLXZRWsQ3s/G4u8pWauPzUyHVX/cXVhSwE
hafyBKSqiEBkYPu/PpVyriwnIa1PJKRm722/4VKVe1TpIsQ7MbY+8JXoVwwl
GvVKhN90fckFMFFOmNtge4LCZFm2Fa1RvF7Xm2uik1fsf3zbDd4jxznoW8rd
o8epHOAhz61b6B7rAePoUgKF4GQxXKLikHwOhxA/Yb7g2ScfPp8dcJwSXIGl
Y549xMG98K8Lpk55CA2SocbFKrhggMFMHFpMFpGZUdikbTQ4cjp7qsi68kDx
qKJ9c+3hWENABp2IaEUjn/iI3HhDb5HXAyNCzvQtWFQLU11HiXkVPiBc8qsL
vj/mkYoHcNwk6hddi1QUonSjHOWExrGPWR8wNM0HWTVsyDpEWx6NiTdEghJ6
xn2ROlHcEhWHevDQLg15ksbGD/zl/ncHQXorEKvyc8M9qXK9XixG+vo/m09Q
jMr115LQ+RTRZ3Fn9ve+bJe0dZAsFtrq+x/3Jq4dG1AGlup9zbJkeIzqbN3H
b+/O+ygj7H/y4Yc43AfN71yjNqZF81FcEvz1Mr4anwZJ4gP08cgvz8vvDuyb
KTbx0ciG/eVh9hzv8eiD+y/jyB7qw7wb9DXfvPtendx1uawVVqvNTy5fHXzu
8urdoVD2x24aZs5ZLDQPZJBK4sLepKh8GPoordLeLDpBiMaIk6gFvZRN5/lo
BuJWlcSbjlgKKRz67/NgKWJuCkWTWo33KUcpMTXR5UW1bFf0D6x2k2b2l6NJ
882k+WzS/HnSPJ40J5PmyaT5dtI8nTT/MmmefTfTFaBAlWCTgkqwIGbL/fae
JFVCoA3EdqiHZp8NQi9poVI8UJu9cCAcpG2Ht6+L8Ohvi79T5bjpIf18hP9P
9dOPs4f/Kh//OW+jOZHPfyg+58ansdGp+xR/B2v8r/bFx9bJN9qw/PsvqaOP
5YWRf8NR/Pez+N/j+N+T+N/T+N8zaeYkjAaKPwj3mweRufyi+WXzq+bXzW+a
f2r+OZ763x2mn0/jcmd/41v99NPYSvZ3OIy/HcZPR//FcXz/sNn222X3aO/5
qJTZZFImWVO+P9QMrLjLe82PfCubcs+58juM86W9XRU21ZcC1xNRcDat/+VB
PEZAvUZqpOVaXlKVyPB0QYCCIi5ojhobVTiqW8TZL58fO5OPZqzlx18Aq7wm
VidxbIt0HFKng6rTZ51mgmQ6HjB/kxqNlVh1S60FLuULTYFfbzSNp0jiHErj
0nCOI+5BCDCpKKYTDtkpKQLaWT+kqTGv0tqrgtuKFkmui5KjZH7CPuy+ZWsl
WezPztaoxRsfeuEjLOoBZ3yTWJ7TrNGeBFgONzYkxgWyn0nVU7/CLtM0XInt
+Q18iUx0C94Cmg4RgixJpIKXqCq4hAnlDPngbmvXpxxLorJhjUtUBEtAMPvp
Ec4+dsSgSDmdK5npDVWnouQP1P7EgBl8gumqxKO0fev52qooswai5H3WvROA
nIa87M6ZrYJsYOcMbGjs/zrHlaoJ21j29etNe3nez91tLC1y0dwMQ9W7L8mY
wqIxGmuFzsRrQoYQyfVNiAkScCOj01aAyZlgXQq0HaVjWghN+UU05VxKRXeK
QRJwTBnzm8xGg/hWhk45Ba9yCgdx4Qyrjg5tu7lOJsdwuqE0PYRsYdf4dZgR
XRCQZFnyyo9hovidIUgU2lqX8msZASvUhDdff7zNV93rNTLDxbEzvl28HaW3
CuyXMu6zqZOYd0GAIxTgAggGMbClakvCWVKxaqZBOoUBcFDv3/9fL589/s2v
//nXkOQ+33I4U6rZuOmHN/R+uXJItiBux2Ukg8FtEfIV46CITsNBoG7hxFrj
8+N2FzrOF5zs1BR6j9uLWFBUs9pw2i65uLDQ0+U6jpYq9Yn5Z8XGWOYbOJGX
68j7UvCodR/X+FicuEy0L5OCTTPexEuOrPtRPSQ/GDsKiezfrntNCOebLlC9
6UVkauJW7nPbpiuMyxMUwu0WclGu+sijgveI8x3MKl3bnEc+TEBacSD7x9bV
EQ7SAWNDSMO0Uhz2Gdks7QbznSwyUBdACM23rh5oehS5celMmfGlIg6I+Ho7
KofyTK3ddAZqBwAJ3AflE4kaFt0lDZtji+lZCYejoiHsdMb41LkfknbvqMxz
vHa+WcfbRpuJEz/ONwx9EwlTVJ0+pr3LhW+wfFq0knNbiDI2raK2bMWJLG1w
KBo8K3F96CFIAeaV9YsA86crb561I2OgUK5ArjfmmO7taXHnZ28zWgqrHeJ4
w3Nk6P7Dq1cvPv5kYiB4dNDmipElsQ1gevGjV2nfGOTqWLS+f55+Mv2EWmMW
888PHvwCwSKMxS93UCjFC6mWzOFi3v7O5KrRP24gDo88MUjY2Ua4N3ojvp2K
rKpjNmqL4jGyJtnib3ZLHzAD3i5O4KsVBBfhsHn1dw8JFXaElMoVgVhFcgqp
0Lk9dzUouEKyBgMUkoZ3RXkhVAQPtrWT/yYSGGGq5ZDyQrV2l/C5Rjy/unwH
Q1FxrzI2lyi2dOiLMD5ETbGknQIoxh520P9xXdM09XCzyBzZS5yrF5+jnoHZ
asaoLSyRiDtgLooCcpBcQCYT+e/RjDNYuEucEZnsLKzj+eA44TC6obL1k9ym
b3nx7SUzy94ywWB/oDVLqUd1oVIUSPey+xxFh9W9z6JgPt1wes1ebQ76iPRK
h1fS6dU86ioipNuQ4r5wCVuLh2hRSrQ6QA+ZbEo9yMdATcEFN5AnUueH6u3C
OLVqZF6j2biiJGTGe9UBECSJz4RjC12O3O9rRA/FA+VixGwvJV8/3DLwSRbx
Gu/0jYIx2CRS5hHdFOn9qdcRQVMd0bzGA84jOZMztNytOGLSBCiyIX4dMkw5
cTeQKUDkkpOcjhK/9KEd94as/LkydrZLEeAnq+nXetxBCR6fM4sTgbKoBel1
+bYUpglGdHYFD0OO0RcZEcIw08kSaEcOlrAYUjh12eZFqKnEiVaQ3/yy5tca
nL/p68Hc39yMCVohio6ssg6QIgdZ0ySJEWsjMbxn75dUCI+TGLYaQsbLwIGM
waQNditb2N1pPD+rlRhccwXHe6p5n1K8RSiYt2fARHw3cF6DKcu4bXBpWT1c
cxYpfxTpMq7dZ+vTg0mDP4rAD7M8okDAgPJXjrbZIIWTjbHGhpQUBr6sEqBi
YGAkUz5SSfsqlp81JFo5F87siiP1F/2y3YQ8BZMkkPfvo4jxT7/8pWgx+HDi
GrGm+baJb5JRLv4DcPughgaihMGTrsRQP8b3f+gisTqklpUKRBvUkvqe1ozS
6xF4dr7u512yoik8hMh6ZQfHaIM7IGORAfo4XEpny4kT/DKb4OByXjObeODQ
NIaJWeXoLQBIYPP+Lp0dkZ2JAfA6cVOOid+hofZ0fZWl0lMq/5Yya10SfUoS
FdDUtQQ2lZfgAQ/BrDWfA/GDBtkxqp8XsZTl47Z21BTvjdg9szlc9XI1+wQZ
h1W7us7warstgQ2kmCTgteTIx8Ugc7TuSSmr+YsqkyM0/okiTUmjofIGLrVb
pxN7jrOo0w7aWlwg8WiX2bcI0to5qvY1LKqIBRRB3MYylQOTYHHoxX6TXbb5
0G+SifCu0duU7FlhZH/bjUahd4tsrPeGnbOVuPcx5GId1GgedJVm5oA3djQ2
krCwH8+EL1Mz2tdBZair0ZPdWuZwyUlCUu9bTqJTYc6JUyaWLIqsmThwUyd+
NicaoUMSP3oX1ebDJHAHz25JqPVIu88UfZ8E6KhoT2AsgLtN7AUSFC+wvYFM
N8tk9lsqZAl4mmGgY6JRcAROgkOHQmNKd0TNngMsItPd9oNCQCCS1fmy25WH
EhbBguxeElIrNo8tKsNxgBZu/ZXkanPunTsX2YizCG03YiEOLs/HkMU07qsV
IT+/XvX/g/I1EFQSmjscnWamJ0eSKLmxESRnBdzx5ItkQ4shG8m4zFeMXChs
WIirFJpqnXD9RfpM+Mw3rEl1Xm5aEkJVyK7VaiqpSNtR5OW8RFn0npYZc+2Y
7g8mDCB/FUl9h2BDsVGGSCWxKJ+Wye0usyvlF476MFIEnxy52J+vDztUFiTP
77IT96oikNiWqz9lTNqzZ4Yy8S7G8iLLp6iByTvn1JuyMAjiSNl6KACbSw9k
TmfoYEt2ajZfac6FtpK5QhHwINXwVhybWjHCPCBfoqQpRD0rPUFWlHRhk4Fl
x90C/9wFmRS36831RFcwStWD3virfAnoWvYyiKU75DrgjhtZjBqOvbm7UfQu
9cKBXSmWtB+/k9qTKctcTu7G8dWfBNZerq30zY8/HpABMyCpx7JDcnDa/bE6
HgesQjDaO3th6pwT7WNiyYW04E4eK/DelWfCNC66txdZSOG7BUreLipcYOG0
i1wBSRKtK/3hbar/63/+P79Xb/JLhrB3Av0RFf+4GmgkITPo/a//+f+SfCxo
9xqoXy4CWVX/6Tf3H6jKA+FaZcyzAAVBytxY4LYNVKtXFpfPxNgOTM91iqXo
bgrIL8GNZMaQJRW3oLcwpCIAXBfMrvZDW1AKT69uADaVKsRzftPHgZiAwHnP
g230HMHMa3gNYVDVK1sNq6yFJ02OJSqsBQPW8wXvd1yTb5wGw6m5nE561n8P
LwZSr9zaZrqYrA1Ecrg7uJ2i3kHb8NoGESj4dpGFnpNEkeDVSI5nItHCdJEl
230/9Tx/6j0Ds92P+RIOOx9K9apu6C+ZZPKnih4celLxzXhdifBMrgUnMlnR
T9BqenpSSAEoDssg1sJc/F1/9K36Ha41wXMQsS5phxzMnDJ7u2stPhw8kTfj
RK4hzFU8hqacQcYMHkN5yGxp4q1gEomNDxAH24v1FbvG5FzSPCM5ZsSROTI0
Q3ycQC3JmozFdvsEKze5XunQ5LjvM/XKheJ6PZg0ZaqzXdQ5yjmf4m7BNGxY
CEpqSHcAWST/gKOx9HUmooxRVHXV5eR1pPqsrBoZwjZac0+mBjI57RCATbby
bpOSDd62GwruDmJFlyjp9+/7dtUeqsOQNR0JnoRxDEZYYJGfRV19a0kFQqec
nEepD2xe5cFZMYe8PqXchDJuCt5u4cdjs/7DMLv//f2j+0eEuXL/+wdHD+S3
T44+kd9+cfQL+e2XR7+U33519Cv57ddHv5bffnP0m/gbtfdPR/8kn/3z0T/L
b0fxh3/77Ogz+e3x0WP57cnRkyOFdbn//dOjp0czTo3ohM7ip8+Onh3F4xpF
nsHHRGhyI5HUBvnyB7QOQ5dROoU9h8IsxtQqeRsI2JyoQDhhsVdPpGoQBf2Z
ZtUmuI7GzB0pxcEkBWIm8P60S3+3AYADsgiCndaNaLlbPw0J8Ve0aLKxJ8ZD
YXLda00M7DfhaiuBGev/r7mvf2vjyNL9vf+KXvI8CySSjLCdZJg4sxhw7B3b
8TWexM7sXGikBnoturVqyaC1M3/7rfOec6pOdbfADOO9yzMfstRVXd91Pt93
hrzokTWkxkEbdffZcJJLMxSGtST73YTTPdhoE3rQOhhoNeL+g2Iy4zD4mtna
7M2Au1WDYS8WnKjQD5XZZ4NwhwZahDyyCeG2t1XL8UjvTYxuhwh4XN32YZ8k
4d8dkF5o2qIRGrQMa9y5cPDFA5rNFGtXYvgiUfKPSSOymZeUR9ludcyvLE0b
bTQu+So9dKKvO1zF73CITLc9ifX8+FXtf/1d8rTafDOuRZxSDLMeK7NweTHc
uKuwl7QRvm9BcT/QnCSNQUWciF6ZjQax/jSmtBVpAsQeS9PCbRKnJcW41noZ
BwFRTVwamJOGkdBQUxACOwXngvTEScVpWDgzESOVCVmfqN50U9et5vbEi86h
9AIEQOALybW0aUCkoHA7csecG5AJjfOh+CsJtLkMMFPopQ9UbQZR1AVRhWRl
jiSjJGoSTMgKShYFsWKJ+cAL94i6awlZBKnWdTX5kPsrKhBP+Dcn3jwIFg+O
GXyjzBBj8eXnngNQrj2EvZhaQ3U04dWIRpBxguQUnxFfLjk2lCdw7OqZVFN/
ssohOGKpHsqIhprQ7naTUNNIU6qoCEIa4+gXkGtxVVKWG2cpeS2MRXDOZkPO
l5PA0KwghDHRIs2Za8Z7GvtZ4FU0iJ18SrzPp/PEJ2T1lMonIoOkoz+tVOJc
Z7Z0WqmACGpHO4pNllEbRkuxDahiwipFc9X4I+aiGjMaqj+OZJ95mVcdZuoF
Jr2LvZ+Z0EzaoKWOzR5CW5KIR8KLPwJCwoemzhzht84H6SG7ATl9zkPd+Ipa
mJ9ZC3yEku2Y4UFs23DdS2K2JgES+NSEhAev+Ek1lJUF4Y+ht6D4tQOYAx+q
zDGtMjl78tYWZ28LQyssTk+LEY2vm/+TRb30Hik5kuUcIptOSas4MSRHTDra
PEpN2NRS4wsmgnLAGeWesIvWyTiHcwcRLgUC6TmjKNOzimUZnJiYNo7OS+SI
GS/L7KIYefNUA/ktCot4oVtd8h2KC1rI08VsKrB1bSQyJrSynrnINa4whDbu
HFAGYm9u5u3PATllIzX8MQr5TTHBO1xOql56ZGKP62lDlOgZagxxfY3d4aTQ
TQncpjMmodWFwTlaggo3DiRBOpPhXYP0gK2ooJ0CT237VXoOyDzOirMzJeGz
PJVsmBZkUQ6xbwO98M+eUD3DRWlgTURt8tRSyvhSr+qTCXAYiEyinhYJZK6N
nMfMrBYigVDWbE/FZo1TfMxRYbp+adkDQMne5Hw1CecVukBN60lbe4ZxFyla
EpzLuYI4lyFqTWjdc05dXZHgJExhQUekydYTmIOPQtAVkpHRYo2Eced1MS1E
aMTByp2Qe4Pbk0jwp49mLQXblp+NyZk4Vpoilxi9FM3GwSq1DSwXYaNxYgjx
AY3qhfQSPF+ugVDM++lB7GTJ5Qx3Mdyk4Toi8pMFjGwe0KnGIXoK3U2RRkPN
xZwln6JM7F5WhJtgBmb2Bll2vEgCjjjLCLqfODSVXTWRaGSuyN13AInwUVEe
gYLCcdytU1DU9yhPsjNavdTbjA5z14BssqzJ6ZmPzkE2UHMqjOFH40cpXHbv
+bOXz/Ye7f/8bDDccv/Z+u7eH777vn+/f3/4h/7W9w+3vu1/d/T977/Ts0/3
/n34rX90+P239+rh/W/vP+xvDb/tb23d3+p/R2G3v2LVktVREnj4+gvC2jRb
gsgIV9jpDMcRXUAcJ504nYqTaAOVSs2uMNdu7xW4zE8kHKbmcC8GPphLVCsN
FfMaKtpMXoLMuZEmwoKUBz4CGQQHKWX1+5qCjZI1aJq0py/drqoMvKo7CYv8
T2smQywra3I4rv2aj926GmfLNXFSniDv/T0fxfS6MZLy3KHqJN2cbl/RGgOH
F6c2DzRp3uY5H0957Rif//ErtlTILSda0LEmzYg1N7IsahAZpCiEbLUP/kM8
ybgBi5rXI0BJSUj3e0Bj8el8l/FGRhoiDoIHBi7aU10KJMxKdntYmnIGUCpR
NY/1FE8p4QaZfXt6QIyymRtIt+KSkDuWybF4kV0BK0E7R6/lYF/pihBj1moc
R36FE4/o0qqNisANPsmXlXCtw7Q/KQJKEyJIJfIT5KFOVplUS9hmiCiBrHW8
9V9LbC+UoY9fzcw/ncq8zxdKuGJ6MmFGcJYRYz+xMlqXlFkF1kCVBhKfl3Pi
FnoALSbKF2UExSi67f2svz8oZvPT/uh0dtbP8mzc59412O5zVk1U2DHTq3zp
bUlK8GMp34fu7gxk6R3SzCB9mnubk7xD7UWKHCsplFrYLUaaDeSStQ/SQaoA
KP6cZorFRkRUieU9I1sqyTcGvj2AjAY9SGzrRk7kCK6NaTVnI/FkuZlQxMAH
sMWWp4UYj2kqEBmhYqSa0cTYGrITnF4BOi+3Tp1mzxp9wMjidbSfT7Kl3Mmv
c1xP7l9d90mSHEKjwuR1jFOA0Z53yA6Cl8ZrEc1PjIInF2rDN9kaI9GG0coB
m+9869iKjALj6MEoATNInnKA6TWtsudcQbj5Ypb62k0dIC5jUWLpx/c2xa/W
JkBd0pCpgWZyNf1YE4LmangwwVOGESoMAoswgMAcy+QBTlnmrmkokTOJk5No
LXAymesJiSwQi0l0y/NpZ28S6Q0wjNSdpMGkejIKnI7UEzYMHWTihadorjj9
gY3HXmSdiZiKbKcGCDnLr5RFJAJ0EmXe6c99/ZlcFV2DgNOjMRIJTijvwY17
RBoCERdyi9W6i5PII/k1VhCpxUKFnXtt3XiGVYcMi0u0kvYagyVtnUzQRKfr
dp0kurEkcy4wQrr9Qn0QFyBQGE+VMr7S3VTDw8X+L7dDKVOiOu0rqyTfv4xu
KgjiIqYGWV+xaTgsBFZ20kr8qHk6Ds0GbDgQL9w5NgoWJmWeZUlHzALh4Hfj
Y+RvAkK5OpW/4844dr4d5LShNAbY2rT9tc0gdnLHRG3ajVabXCn4Ziidki9r
xf4hNSNkbSn5C1m35c7ci1xoSqMuP55VlAEgSXq8AeKYCdynubtPKa0lm43O
C9L/3SEPITk8n8I8o4noPnad2EJzYGe6JvPLEFVByygl6JAJgc7JhUsXA6x3
vnleDSiCJKbANE6z9XSbybgaLS5Y5KL+rei8R1hxxa7vW+KzwCRLUN0OOBIp
lDkfN5uZSyT/G5XtfDOS5LEYlKBQWLuMGFRCMoQuOR4cNh52XL0tHjNLbCRJ
gWxlcudswoGV/sUcwx1eXZQskFI8pwdutjiql+cVomqrE2graaO+UN5bg9W+
RgZBE82emGb2jC/I3kqhN2JBOi+mSJVMJHCqH77//Xf3skl1uemEfEkV8Y1m
ZQoHbmhQwrrSqiNH0+YDhq07WhBmYoPkCWaMg00+kNYDacva4aMBjc1nnDuE
NYu975UN9Ye8Ptj7+cWLg5f7B/tpFDZnZg+6gpMiE0hmmQYXe6VCAnZqSfX4
k8/1oA79n78825Mv/7C1tQW5GNmSjVVmQ7ZTYdpJOC8qujIpH2HSwXzEXKJs
LYsT8l4bVBRJHiZ/Vq3QqDaRJ075rJRyrDDcWJT/0czkDx5+TYTciTzhdMyy
Hc+kDQqOWsJRUewDbTGVmORTWMhqifiOGyY0dh7CUMURAgGUvOCvI4wNirac
FVk5/5q39xwI7uAyViQ8ll9EHEN8ebxNlHoSuMFqZ/TXYcMOAW7GSXWWAUYB
4PLccF8gqlsUeFWRSfEwRvdGq9rtUcgH/YVTunnZ6gbStZOpr0+xFRTX2QQC
u5MrJEm4uUS+Fha917ArpOoZZrNI9+mQcJl93pN3dO8ItiSk+05X5RGJDRau
Bxmg6Tw2zJoI+aTdrsnAq0ZSW0tlErylHOnqrQkhgarDxEyV96nyftBDaUvv
mjRL7PhzpwrnM4OKo5qzPwqGPZ+L/nDwgEzWnIuHxxK4M2SN6l54+nIokCML
LoeL8L+1dS93XyJiZ5csZpwqz/dZMA9xWPYJBGlZssfcKYSeWYusN/1HrLVJ
nLBBSgLMAtZqeWq1LYn0Oj4+tuS1G4BjRo2bTrh79frJRrsZPenHpqGLNk+l
j5KUaWgP82xialTLB9eVZePoi01qCy8mHDnqrR/hqJ8LkSQGKhrpMYa/vSYw
6kjW2hhuphpKviAojdjtY4aIbK9ufdBQLcpVTyGmamM71ClrqY7MkWFbyXSV
kpTm38DnI82dEwrzyelA1XoYBbtmvwAwAQDIw/2ihvaY55KuUUPfo9jLYe7t
87IDvJC6e7BthLpArBjG1SuewjBxtiD09HkuGn1TUutcen8J/FKwJHd2Ga6E
sE9kA9mECjdg5AitE29PgR3Q9NTsdWhSC01oxw6JljwdoBxjmdiIrgsyKRkz
G2g5LVBVYI8myQZJ6GRjuQJatpv+n18nqqhcVhSCUCCW0GljHsWzYTAOYoM3
8Xm0H7qzKJ4GKe6Loj5nzBBaESaOM90oBvmgF8oXNLPDvkhJGhN3PoNlNIEu
gMnd5DLVWEyMrsWtKVDhOfCbklWOFJjJMtn+oV5Mf+w/v7f9wz365MbQt+Sk
mM3Px5nYMOU+jbtXWxgaBnUxRgacAarncGaWOFMgTaqco1zW/20X2RQeuCkC
cUTANa9Zrxn763RRjjy5DHzrCEStFYidXNjGSO70u0kREOjM4pRxGG5/z+Pg
riPKIGLjoAWY8QwaWJR+iuJhWXkZsyz6wqljY9zHJCV7zHMdnOaWNJuC3HwG
I48NoBzymEj0pP6EIFsTQO1tfl+3k2dq4fFYlOEOB7yT+o4b2HySYOVR5KpZ
O0AJU16nzDalwsY175PbPnCVN+SURlF2zNSMRq11aDNpVFYVD9dWyIOMQFSw
os0U4IITLDyT/rReJ5E43CQrqn2sRjHvBDik0cma6Ns+Tpl5hhuZvQGTL0Dl
IeYk8AZcZrhQ6nArmPCNtNLEpsgSLcNARlDoRkvRmuWsCzHgrJ8aXZndSj7X
hjd04VGmWXfGSvwpULrtWb438WtzbATjs+JriShyjz+xPwaDboxb598Qkbb9
1NDJRSXwUVwXshEps19xtZVYsOVG04t0gbFPzLHCY+QZCa23TbP1wtD07LEm
IWpJRvHDwUS2fyh5uQonwbv5aXVp0/vZ+uWXxFieiPzogrPdfso1CO+kKy/i
LaPFy1wVrdSgKFuPWYgQY3AtmiQwxjsPg2rW2KTIbGejKWnHY1WmG/iBZSUI
ewhy8hITDInxGgzcHhIvfzrx5qNFGaxJqjgqhweg4d11Db7hZAEfIEGH0YYQ
g+EybAZdPNUsNlBpMFeLFlNGdr+XHgTXjo6KX+58O/hjia4rf2CZuKbQxWf7
JtYEx/aF1/Gqi4QXluAtNcrAANG5z0KNGuMHFLtqnhg7oIRCuP+ZBumN3xeZ
55YceOg9DOypqHPLlRfCNTSU3Q5aBDqy25EMi+Zx+Ch5PG2yJUX7UURUNdM+
l54k8GQZ4eeYFD6fCAW1sPOhgAkmCz3JGkudYhDqqCUmfZc6YvJ+YX9c9TBT
SnagErBjD4qKx07AftYiXfC6zS/Xa6trqLKUeKOalRkar0zbryzjg6XHLoEL
IqazNCyiRHd06VUQfPQcaD5FSn6gHLfXWr9PAPRsoYSZURz0YoBUrF4xLGFF
21s/drHrHgm4C4FdA2uXJthOWRLNb1i+Lxp3kc6wsRvDZ+7Ry93RzUlmtJTB
NGKOdo3XBaSY54vyaeXetyy1rzcwSTkWLmuCoyW+XDe8i3+RghNJQDMb/ZYi
iAQvdgtLWaI2EP9pl3mM5BzuXzHBw7TWHGgzcm6gNRkihsayo6spB+AnRdas
W1rEg8i+/Au9Q3jLSzJDbTHLVl5ouiTMoKlvQWKQDEROFME8uqnZOHtYNBPc
fXLeTyZB+tAqJARADS+drgnKYo03fm24yhRUGTZto0AwvZoEW7Y0gsIAQ4vs
Kg0G0YqnBSYPcoV2R5IMyabsqSGheCUUOBtFI5x900K/bVRJD0chNwkqIRoF
tC2Yauu6GnnMXn2xepd9CDCjF4SyKuEpOmqgIDFnIRG/G3Q192wnEEEdU6vy
XcHGiVWrWC3983MN5Vak1gCR6M8SqijEKfu0V5EQmoeGADW0mdDYrai6deC0
+S/oxXxM9dJ8cDboCWKwxWxLGJBN4hPM4eA9PyTzTWi8GGOLlnwD14j83ElY
2qb1gfiUM03hgdZlAvo5bteJ0nFmCZtSy+UF+dPNCWj0ETp1Ybc39nG1ZAYe
RjpFBWQ6wtzkA55FEe84i1E5L/01yBi8ukIiREJB2Mh89kM1K86KEmILZ8+U
3nDSiRrBYQRN43xNbmx28XiTYEBfjcT3UNYTx5K5Y8HBjAh4afnSolhmboK3
pRlJu6sJSwgcAnyepcdhPR/Ns7NjOYSwDoo5g/2lL3b3AvC8PzakhYkPUVjd
Qh9lUDHeUdd03TxH/jhszlFmSGW7HIXB3xaNhGv72FU0J9HSUtCKvzFI98Zo
G5GEup5r16IFSzgYeEHcF2A2Ez7iKEhAFmKcYj1V2s9YeRQvtJ75HUSlNPpF
RGgqR2pWJt71bdjmA+wmbTR7TRQXTrerqzIgL/Dr/ig6NSeCsnoeDg5ZZSOO
/xHWVZYXPetq1QCL8a6oxDS7Lfk0k/yLgMdC1x6DqowD066xEeB9JCc3qUf9
4PwjpLDwGyIeSGyUjdrZOuEuWsbzNDSxRld2ojMoctRsrsy1/Xq+nORdVQo/
7ooBiyD/mqF2NC0US3amdzBcBAgia/TK85Ryu9xd36/P3YodJziCZQFyFzwB
rUdJk0yLjKhFGzF20T4vzxK5/cOl4CW7EBfhA9jNmqxKHxlhV1dyLeHqjPiI
yENJ7Wowr36g4OSL9oZ+g3u8nnu1SAbQHlJNfYixTHCJ++VInEhOarzwmCsc
m2tqaHEDr0IutMytch0+kejQQ85QZKusa3V/L4xAiDd6Euczqkox75vxCp4u
8op4YgT/tVPiCiG2Scht3p/gyCc7iiIGp833GOichvEaWDps2kyANYN1jHTh
mYfH04TVjBO7CNJjZqfYIjRJHtSrVb3qaop5FfZk0awvuWyeC4ITH5oMqbem
NOm///3vXZRS+Auz0kmzlFqmqc/4AUxSv/Cv/dbfp45Pzb8fV9Xa+GT/3rjp
iZif5CWhWNdbmivVvqWxYm9sk1/RMUvUbZY3yKFWrpIIHl287bDQ1azTMnng
LD9bIIOWTVxyXxYzFpVxJXchj/8lejjxD3v0kkhqYtEjsDyL9G0ynqokkN5T
8AjQEkOMC7nxxj5xmowcuaBLyGoeIB8lEaVX8MxaQOLBhyaO8fTV3qFk+UqG
ceKvIoEmVq+M8pu/MOKc1lJcKO8k1YcYunIchpJirsTczdM5tcz2x9NsrqAJ
cSRMEjEVDBSHmgx/8GELiUCdW1cmtSD47hOhveewJrIDX6oxrvOctoQDeuNI
unyPCZe1uLjjlR4GzATNxdtYdg3Afp84GU00lgpyKizTRnMF9lJlm/UrjsKi
OlYdnNpumfdFsB+0Tvav2Uf0dUj8X9VQldrjwIzapOPbRE9OYuEQrJBfGIT/
gVHv44bTKmlne/G7cNBDnNEcog6vU5xPXvkEDH+qBHCLrFzqmifJkaNrOVWA
1xYLTW9C4ndQUFB9EcR5su5Up6fERyxJDXiLE3yKaqxwCN3ZA5wM5hmcAB+R
fxAUiFj5YL0OqCrmXRTHj7dJjARVmFBvFOmQ9+J7oHTBJ8i3H9pGMIMvPV8A
hz/C6jP3rEdemNQjyN6lmJmNjN2NyarzerNnBwujqVafLNAVqFGc0omN0YrP
xNgeaKMAPRRBdCryvKEP7sCi0ESVobF8CLWQ7IqSexEuAw8oQs1qWuAWU8oP
JUXgQpW/fU4iXQK+vBjl+ma4mekBaiKJhzOynUQUYbp2GqNA0moF/u73ORux
TuB7qtkVDMtN9JvtN+TKvyC7thQgBgnNTd+Q0dj1KH1FuTes815rszHMxziu
TVac+xnxTMmxL8LfiR8cKGzGVs2Uq5owFwd+IZaU7yA2JweMl/Vgt6q9JC3w
LbapDdwqb46E65otDU1ThXGDegJBggTVaiOwLfbnci7F2SwbY6DjUcaAFaVt
MC3zmtQFZmm5or1P4MBE2g3ndng26WCawMC5gmR7d71rUoMA9sUjdIWblBNV
9NJ265NB2iUH7JQilTiokN7ep7f3AQoruKO95ONHfUef4J3iX7FM8IRgYPUJ
0E3v6XjltW4LRhvNPT11PEAYF5vH5Qu5/cu9f5XNz9W9Kl3JJ3V+qdxcftjA
wrSqmdgj5oB5nQM0vhk4QKa4UuZDY4uFRlq2ORxjPb4ELYJo4o8kjxTgyWk6
fBsTRTrw9vTCI2KeUFIaX0reimWazrIjr+h6Wc/zC9cw9KfpQKD5dzM+TtQY
sfSGqSRp2JEpxT9Anc9yb2lcQ2oYgSDN5mu2HUbxTzQhYmU+BvGMFc0xSwuP
LqHnY2JHxp+PcRbLKOZv0cFsbCdyc8gNh514ni3Y0k6CZPbBbRDE65jxgsyp
1QpWaqtDiTVmXDsrOp10s3Dysl0uMKbXZNjKBSbPrbLilOV1G7nrk2ujK8cq
pgiJaKDW20CIm/KOjJGL434+5GVThc8iCSCOYLA/JfuHwhjEmY1kD4Lo4dcB
IzIw5yxv6ZmJROslwkZrE3OQnMqpqZoreSFCGrudjBuGdo84zUScVUTAs2zq
AdLdNdAXmb4jd1hT2YS4B1PC4EHkog9pHKkJYQ0rlDetSs8T9ziSh9S0xitH
holS5LNSII8mlSvsbRyAZuATIGnjtxSSOxq3jTuLdX2yjEhx2GvbiJxDMLm0
pgPozMetJxZYTZS7Ws9bA7BHkbccWwB50o+UIrnzawpXO2P+sGwrymJRa1J9
j1egXIlssXGr1ICmeakSQ03LUIU7sNZIA6U6hSemcOR5dYborJ6I+wFo0Gau
KSQNt5fiY51ynKibx2bTte3PxtbPuS1IEya0dtWWF1MQ5qhGzOjsctN3xYr5
O0DzZigaga2nWDHqPfftYql1rKbj2B+oB2svWZS24QyNl+4ivMC/kvNkKE1m
YPYJwBfBAZsIxTytct1qtLC6gk8kPy32B3aeZyseMUoGyct0QENornMgz6aI
WQ4PacR6W1rfjaZsl7eik0rIAZClJwXf0dDpktjejqNT2aeUXSrwHvVYJ82U
hCg2g7PVs2Angt/GWWC1DQhogXiE9s3uofeNlEZvqyWWBwn8EKC42v1r3D6p
zY/11GSaXLmqAY3hajuGoFoH1jpqB8vn5BQDR21WJ6a1fLePcxYRNNpgHHKd
IO9zd57xBdU6uDJJlCTpcmQDl9V3vvfzy2d/PnSyLX/gtElSht7Ych8//vkN
J0lx5JI48KPDi0DegMghecN8s7oZc7IrhG83NIqKryEFu4fMK9w6DYk02Lvr
Fe/FjWYIIxEoZa+pVpelYoVSK9IPlethEpOfGWd+lH+JH51SJQ75Bu3zK4Zw
OGCCPnJ5sI7oTj5a6m6u/fLgrHVLvkNlxW8Xk4IDXg/k5Yl53vK9ixrWSOan
Wtg7CEuNZZUWATEJQkAblu6PfGSPhJOeOQc9TAXzGpAsr+4L699VWleTzs83
hKE65+R6I5vVNk0yWdGQNrcC2uABINyC11BxJeY0hHPSujHH6Q3SZvRrUZ4z
JKzJh1BfNMuuVJ/IrlG7MKk6SrB+CCJB5NAT+0nCgwEvpJBUYN8/mWVnnsGI
1t4Lj8bwjDP26yThTRBtKAvbEBz/gTU8XTuVmtfMKeNuz9EsO52LvVuZTYKe
CEVoxJZiJhoxOqTP5Qyogwnou9xvaouETOdRdjnrNzYaNyLyBIocke7z80Tr
CTB1GmHBEJeKdthI93NnlFQKmMF+/qGaLFT7PpH73XSlXrohv7IE7CLMmtTi
bHZSuAOSkFWJL4j57HzoCWcXaTWEZaLOAm9OZ0Fjfm5dF2awZB75Pis5slJV
XB+0x1pRws4SsTGzNJixQcAtpseVxxKrLTmtq20xDQGDHIJjgLixYPa8tx1k
FyAg5yC5rpgfH+7m3S/SC7TfDwFge8RD6CfVAKv59GfqRUDWAc1eGB+0mjFT
RA0D7qtBJYaPusbbbCheqMKvFyDgCLBz7MskZcVjoyq6DIEOazo0rC4CUyVk
YUU5V9hZwkXMLbZ00hgb9FcaCUSfsSSHzc89E2W8OpVmlZZVglmzlM46Vc3w
V1GWNfIrGMcZkApIHYkEg3jmBEUvr20koTGdVyxtQEkSlc0zZ0GwyWcz7qMG
fXCkqCfmsYBxpJwr5DDhdtK6x/HtyU1RGbeKHSieUq5U2GYPIccaD9TkJDoa
Q249Mk5IxA8wVPYs5ENUeP9GwpfNRpbwvepCQP0o4UsMQ8AmOLl8unZML+Fs
oowiXc5nVUnndRREFAQmLPHMczwZ/ABek4hTFNkpS5lw3PgarYtDQivZAkN1
9uwCUtoRRSHu4q88V2B0j+AeIrEZOJTXpNuMBUdGnC5m84C5XNtA/gy+RB+4
A4WPipLuVVJ7OYjfbngcmxzlOBJ/ovdYkV2x1OU4wlFjQqtC5Fte+5OGU0EE
P1xDZsheZlYu2qM6qo9GUm8mFmZY1sbkA13PXUU4hTrCkCT2lI8r+FYiOKfr
lg9dR65VZXXpNi+BFi4Q8UwUyCvOcX9OaQ0z4EtzcpkulDoAUPM9BjjyxYUi
8ZpXMndZhBTOUYmCN2CMDxRi1A+7aeq6CjG0WV1wYIjg4gTExMKP2JNwHuzF
eWyzINlcBIx0VlUK3wNlC1dA40o1GGbdL2PZUO8wBT4ifXZRTOb9wlJcgg4A
26sxVF7aWKoHje2pHaFThBc3A0TVs92Xux3wVDbNWa2dfEoYBGbsEw/yQkoh
agskMsjxo57t2XzqDeFnN9/9/vumPPlr4ZbQE4SO+ycv3Xd9Dic3T4ZkpTcQ
O+Rhn6airO/6vM/pix73rpPG04GwJ36+zSqvJQ69seF5dpJPfAlvhOhP8L1p
Ed/WpNUeBM9LXJpv9L670Q24SKumgyvcprNG4Vy+Ns8nuzbHwvD9GHBmiYKm
/GXZ42ucEEL/ek5Lx8cErfWASMEIPLxhfT6K8NSmh2Qi1xQ5J+NLWJ2odh8/
/gtBIw23QYN9CISpce70fQh3NxEzU+f3cx5iV6cbh5zwXDf2D2rylLua04P9
Z29+fr2TviJO8NwHdr51f6kAjVJt/gynMoLA44GFEExq9gS0qObCpqw3m1iP
GARGVjE2JA/LJkEjhpJ7zuqjTWgyuAQcMRRBaFN+kHlhmV0g29tHA5cMhDOq
Shhfq3IHAXMWdIXLHzISwPPDo+e/PD/688GLI4qHP3q6e/j06PDZT+mj9Jfd
5385+CNCwMgi6+YY3zRzu5BnWhduD+Zl/wQRSfP8LJ/Ji+eTOlm4r4bfpubF
Uu0n2BErsqin9FmyOu729yn5tGOi5naawXL/4J+rNnVD5aPk3tiwcsDGEb1Y
6kag3rxda1M3+lG19O+AvuERdp6++vMBXSRxilkw4zSrRYKDqbaB6hHXa8N6
jHGio7W0RGy1yLW6rlrdtbD/OSV6OucycbW06Gy14XDtqNvDD8Sm51ZrJcp4
srgIbLtKMCZAYrJ7+Ob6hUzlO3i/OxByAopnli+5+8xmp8dfuu0nT2cX3Q/9
9a+pPZLemERws7W9DTVTRJtIkABmU5mMyZrSB3ai21b92eno+wcPvjspSPyV
s86Ji2fiZL+s/OEF0/Pcw/2PycB+xjF8Iic48SMwfw3Sv/2Nuvc6J2kYHvYd
nyhv2Xc5JyE+AGehkIr6zw7ePBkkKY1uMbbMU2vv1nrp2ss1FrfX9tcaaFsA
GRSpcZxDCXHVRDOyZhq5JlNNzXC1khM7n/tYRvMgAfMjPMg1wFXoeoJ3E2gG
BWSpwYoektAmgXsQasGaCvpiGqfvajqkDHtIwLs8xR8/hqsucQ98nb7bcdrS
WAySPo6Chki8UyVx7y7Mb2hHjFHIzgjE8QoMiI+6xoQGE31ElH5aBAAEJS8J
KZHFHBVeBgimQbrnpokUgFmQDKiwLizedt7wYN6FqiJJPkAQWOHUIlAgZlyB
PDDpGBbWRak+v7aswUESSz6IRZSuJFs1y8iXFtufqopfD52Td4pYiQRfleza
qDbwn8U9dbpo3FN2FmSgdaVUBsaal8l/2Tn5mGANcERQSk4LzdKXYSB46LgQ
3upXDaSvsgr9MAIT7cwY6MOsD1QTDTpkHrGsaa8KWWKhyfGymmSXZNcBlSFV
KPZCs5jha6rNpDLyBKbNLHnkRjO1Fw0Kty4DOVWGPa04SmwJgDdPfcmds0+b
dAHPPlVl5kYmZH/1hDDkiFt8s4xCNGnwxepFIPquXsPThNohn/EIUptZDrP0
J5aPpLmAeTzYCsIk96mSF4XTWwH3PKSKE70uKZl8hQiZwicaTbF9G9toSV6D
i0eHLLyW7JJKQzDgG0FA8vjW8wojh3d1XQcK5pY8Y2uGz93dIfEP9629sXGl
XiMudf59Sl/Tf/NTL020hL5/TAykUqYkiSlbV1vuL3r3weHB618O9m/X4j6V
dIIBlBJf8dA+QsL5cPv7o/2nTiB8u/3w4fAPTkg/dF/9tPfi6PDp7vbDb48O
xvghlHrXWfH2yopfUS2taunbRou7K75/U4v3nu66/2xvvfr5+bvh/a2HzYav
qvhBs2IqxBU/ePA9tdh9IS1+ONx29bmvP6fFD1dW/Orh9rBdMX37WUPx7cqK
0eKugYgbvqri71a3+P73D+IW0xf07eDmFu9u7dpHhKrzVn+dFRNV7xepmJh/
v0jFRCT8RSomXuIvUjHRHH+Riok1+YtUTCTMX6Ri4nT+IhUTRfQXqZgYp79I
xURg/UUqJj7sL1Ix0Wt/kYqJqfuLVPyErv8+fXB/EDsM8bpgwaUENnttxY3r
P7bRRlikJKI9JWgINptuD7ceENCwcg7SLwFBFCk+ISSCzCwULJlH+KbqhnGC
sqh00QudlEqmm4RYLgsK6a173IAIrVSIBwnqPsTc+fCo2hhWEujAfxh+v+Xa
zfowUPGtAOhtYO7D/hP+IOarT+lTNhZ9MiaheDSDvHerD10WPpHC+MP2Vtr4
Bh9YgHEf8lj2Mu1RoYs/DG+qZzSugUE8df+eDY/q8ww/BBlrZXvu36Y9D7Se
qLhvKssjqKchSjXqeaj92r6hHt8vJ0Jxv/BDEJhWtuf+bdrznbZnmDZGXtvj
BKKoPe7f3B78wGZCLG9vYVxltCxqH0oxU2Uo+AIbpnn2jDdsggFeGGiPvXSN
J3CNP7kWqT2MB2AtwYvUnei+7Lune/jgHu6JZrrbp8Hy2zONiJIOnx7CAPUs
xoyA4xaBwhO1Yl0ortLHj8EV0/Dc9QRUOIl6xVTTeT4XK2uzukZeAydpeCB9
bh7HX44/FLV63MFPNT/PW5wK8lY4PiiwDpx7EtdwTjGsdaJRe5x1oFou+Dgp
piGH/xNg6x+KWQVnljAee7e2fVcCU5skXxMKZD5zR+6SYofIGW25yIMTB/ld
cYBvMUvs6PRS287ReUVWOQ9Bf1k1vAx1uiHA16lTtcjjAn+cWxL0eXOQ/hqS
4polr3nRaVYT8RQrbfdIYSGj5wfJqnzy7NVhOnyw1d9muiDQEcjvtFv23ZVT
5P2nbhwuMqSSJWV+VrmplljMPXmzj0+V1++dZ+4/TimqJktSilIwCRz2nTaj
IbIU7iFBnhlDnmc16uTgmVYNDISYUmIc289M4xE7gMxbigbXCOZrejfo8vNE
9ME2PzO47mjQ4vsSQZXmpe350dweeXPCx9IFWZTn1WzZn1d94iZn+549amgG
6KwaDraoe8e3MRwoFBXFfSV79Ga+Q6hOy03dw7TQinN1eP+OkwzovgZqFdXL
JxNlnap6j9gFn7FJNGiuoboOcWSEPjXtR5L4bLtqnAfeVeumGFEI7ShNN5GU
VGhDHTS5sBl5ICEQ3jlEy6eOMN70VvAhjyH3R6P4TgRV0b3c1S9yFsUypOzJ
VsrVGvv6ZDlHDus494C2HCFrS3CHkyxkTwLuRu1Q7uhjSZQQsnI3ku5A+yxP
lnnHak9W46HIH3Qo7ircL+3ojs+0Ftqu/jOthQ2T4G1tgg3D320tfw35foV9
zw3aEQd7HKk/U3961118u1Wc9Y24/Mri95vFLwUqstH4FcUfNIsj5uuIwjQ+
p/jDZnF3vBxNJR/zhuKfrXS1R143eyN46PP2uwEtFnFJIvoR0MEbPMDkMi3g
dXuc93ejgDnTijL5523x+DWrd3n7OQGD3ag3+WnLsBbyXkI53OrTKbBfxrPs
sgwpaT5aLEkxxjvsd/nzqx2bjstAyDV+ev5yJyB52h9+2tuJsKvjH5/ttICV
6y90aIWO3/rIuv7MCuPePMC6zq+bDrBVp1nXYXb9afby3m74x42eC/e7iTw8
cgve/vT85aq93nXMud8tuUSjXT89u7Gu+3FdEop2NMqmIZmU69q7sa4HUV0a
tEtn+O3b9bC7LiXrNnXd1K7IjH+dpeuT23U9bdtnWO7vVldsrL9bXbF9/m51
xSb5u9UVW+HvVldseL9bXbGt/W51xeb1u9UVW9TvVldsRL9bXbHd/G51xaby
u9UVW8fvVldsEL9bXRDHPlMeu+7uUNksDtT+TFVM1bCAam/1METEkOnA4NK7
XzyMpihnt5XdmsJeJLv9E9Uzjwp4vejWeuy20s6BXDwhvi8LlSoyK3oqeUPQ
bymbqUyP9dY6lnxGJ4gJyoT+4oPtKRIdESRIiNSIcPtWSe0YkS2BQSO624GV
wcXd++YVxxBRmFUEsSRAhm5JSpMUW2jzcwNZvpiUR4KdG3f3vxiMO0p5/LM8
dCcpr4//pvK/nyPljcetasyh8Y4HYlVdsZQnCBir6nopn1bU1ZTykHJ+fbtW
1hVLedP6/R36GEt5nNL1j9b1bVTAS4zNKj9rvL6LCrAeP2Kt6sjovJ8xXreQ
Pt/dsL5uI33eVNdtpM+b6rqN9HlTXbeRPm+q6zbS50113Ub6vKmu20ifN9V1
G+nzprpuI33eVNdtpM+b6rqN9HlTXbeRPm+q6zbS50113Ub6vKmu20if191p
PqOrkfh3S/nTon9YCVRdyUmTgaNcYUiMOKyuk0YTb0lslvhS4mjjPdfkvrQf
/AIGOPOWLyCb/RPEsTtIYDcJXRT5Pupu/OdY064ebrUCRK4pfsvr/Y43+h0v
8Tve23e8qu94O9/xQr7jHXzHa/eON+0dL9c73qd3vELveGve8aK8493YcR02
s9o5DOGYvqbQEnx57OMa4jgjwTKjAMUPVTEWrH5GKQc15QIKtQadGChnyjXx
cYuiilC4wEHGPFmcA1kHrz+xSglGNXLdFbyBkXemFYf2gF0AoRb6Ko87rtc7
JZXNxswQylnzK/nfOdZKcJxMproUA85NwhXnAssNjBVL7UpQ0TB5eAEixE8u
PMwkJYMmDaxvCBQRmDIFGTRuckwP35yU5u/5LCyMyrHM4TSbudfMObasMcH/
C25uNKS55m++oDvv4bUn1NWxpJi/eXy41rV/1tTviAdW7bK14LjU57qe8t5I
X1nrKW//vAYWQraffH/jDuxEj4j2Y6KsAe39yFOKrUeyKaFh88ERtqakjdbI
R77dhk27N2zyD27YtHPDJrfesOm1Gzbp2LBhjC06f7x5Of29Y98m/+x921oZ
/xu37udK1s1tGwBzaFt2b1ohPF1beTGGEJAIM0X4FfTL7v2kP9e0h2QdRTzA
lWAGIujRs0j4+Ad6Ly0UCo0fLya0mp8X7zm4lILn/etNZHxPSyb+V4FQlY0T
Q1nr7g3b0bZwXVko5whV4fpae2pF13RrSLIBMmnhSaHTJCGo5UL5of9Jq9n1
uq/z9D+8kt9YcAhOx06LxupWtupCRI02/8DJ0gL41sxMJJgOeVPjF/BvgjmI
6lNu3Pq8uuSYUAY2mGRLAy2njR2ELfcpgjn4FEbDbLl46zXD3DZe3tul8BP+
f91R4V9hO7VQeNJXRIv88atx7mZiBQaQAUSwJ7rgTZHhIhzHSXY6h29ofk4w
m26Rvycq4CK/9LQ9wZayf+CWOtHvci44RRr9QCvEVdfnQv9GyBmDanb2Y08L
Uqg5I+aDgHbGCNUyvFJrwM5PPMqyxoLSv0Ye6kesL9NZAc4fSzIQtrSrUeOl
ZuSlkEGQSpSsiamU3Jc1CJkZCQg530kdDayyc+NdFHtOGEi2Sj+2teBEm65F
4yVMEjRSiSS6C/8mmup6RapDvUBoVbrBwdlrr7n66LDAOMg9lz4mLiaZ6DVy
vpn49Ggye1HLLISeDhWIqkqm1p119LEH9L5FKRyYIru70apNvoO8IIm6TlIC
xRATGncJS56MgEb7A6TPnW9KkVmOiS9Jd/oJwSHXi7MzYoeGlI/T85xzEy6y
90qTyWMVgPUGK+aK4e5mjMzlhvQCFxKDn8rSJz4phpcvk+1hOiZOAbE8niBB
wE/2s4PDn9ZrApxnSCiZ6FpAa1lwwaD+UOT1Wdgm0fIg5KlZgeuNm+fpTxS5
X7EqdAo9TZ12Abyk4vAN3mtXMJrM8YJPz7wOCOV6NyNzpOcr4VM4Ylpy21Az
WjqAIIBlApgKHkvq+SSPMTJpLdhWxo3LORmIuLHpJiG+uwYsdmsVMxR3I5uk
Lxi/CbJdqtnS8v60bzZKjqEYd0TM43ZgUMVwhrIDtY4lD2pDAK5ImOAcaJ9+
qfFiMF2M98l6cxFwjo4sdj2aiG+icL33L+VVQdC1lO9wXnHEvuCpe/gwXgWu
l1MmD4F03S3GePHaKQzRCdiLELAZj5x2QDZGso5ARMpJU50mjekciQBDiVrM
SMKCQtacdzlFGIzmBM0e5cCKzmrBSETUgtJxAJyEko7yWsGXAztdwuMkiJP8
D91QY5vt9Z+LMXC19U5iTURvJlzFJEesSYTuPbdy1tIXz14cwJXRxnXkE5oF
sI5CoIqUOAszqnzpMQelSjC1XgFP37x55dbsn5DkObz/+++bTMNRfnDXGLVU
o4dJSKSayV+wk+x4zpXkcHEyj34g2TygBqp8WNNvpbuok+TnqaLaRz8KwB4Q
T+TzDv7BsqB1uXgwPnesE2CqR7KDuIpCxz9cZP9ZzX4c/ODOLvf/x4z6XDG4
O+drSCWECDUcbK0JmLKAzUT42hLnhJf/IsVcR4dbRJnAaTIUis/ZTYKiE14g
2W/qO6K5wpAF4Zm3Tdj/qKL5QoI0BUKoEuvI773oX04sfZ/XAkGTj0hYHlEy
jtM0q7HAC5qUGhp5O88ixQWIwKAZO40nQaW1B49yd+rZgtSKv4r+8zfkXEkO
XlSvQukCb2cOck/MGsEtuhOQ0ghdKxWockUrC+a+8BjpFx7nEhCpnpaJg4sI
m40yQGXOkejkodop+dD9m8v5fYHmu9J1dztaRsV0Q1XVTUPdgGTNBjBPu0NO
Kk+SVyr6pdHBSL9rzQ2gYGUf4YaETS9j1GfQ8zAy9iBOEmURMC7RVU3b7UTz
lByAfVoiI57ESUH6lqBZzkK4F9dDT79wTRnJPkBigv7wpJgYg03004tsRPYk
SsOjh7BjCAPTP5S8AuFL+q9uZxAgvUdPxgE2z0Z8dCvadNSHHQayQiJZxXBP
zLJAakcQongeoY5BfaaChOP280s64+i4kfxASGLyAA/eYn5ezVa/yAlkiG1E
U2dOF8/l4cOfXMcI66zmobc32Z/SjdqD1DGCpJMmNvHSKkmI5hrY1IQUrKdH
+jP4GXE7H7CYA6rKGq/hRwwOpQj+RDVAtn8YDHRlIterRT7pNKvltBgxmxPg
u/kudYLDhOAKIbUAZhmEHCOfWB3AFN3Jm/v0vyQ6zSzTicc257BBpkPQRnIG
HpO5iDjHrBFJc8/SVValgRcGeYE0mBDfnJA5ATMEQA6+JgIjYSJWygxkgD7u
pYOBu0B/co88QQglH00XU7fXFQm8FgTDt730XS/91T36k8S31ekeZLv9Xnri
DlGsi1966V9YgtVyUujxTfW/Qalfr+1X0Blu0bunwHSkDGn6/5jtYTEHfxXP
I6Nrf85YvGNiJ5ARO0VqXs1qV2zfj8tjJubqhUTbgFnNTNP1Ds6HxzRueMCs
MaxOqQJPHbpV+pZvyHk1BZ632JXLpT8ahC6zbNZGle271h26jsPG0NFn3/Cf
zFR21PMTRtudUbUwMglEuVvTjwVLnmVMgyRPRm9X22Ma/EV5AdxPKvD22pn2
jCafN9FuqPftIktpB7SXMAbtXTRVe+Hn3/zPj7v7uKd9NLVjgki2IwpWHzCM
4nvNLusLtAiGVWZMoo9JMHHLSlraY/0OS27d1MUsatcOIJOo9ikF/JYnwa4f
myeCU9A1lm/8RqfdffB5O+bX1etH3rVi9TxpDqXW5y6JA10qtEJfMXfsU8ad
+fjV9NyQ42DATlyLyJ4dwEDJSiKcs4JXw3ji7ubOyOzRc+M9Jz68qnrPkIRz
XNXz5JxBr5cpveODwDrUF6Teaoy/4tw3TgHP1OIUwnA9uCkaEt1cIF7QgWJ2
4e2BDt9jj54RJjFel/cHuozllL6xxIOBe7RzHgcMpZ1l9QfWTLr/3nV9t35N
gU9d3618ftD/pj/o+o5KPHr0o/9SP9/D//5H13fmJW9NdW/X+f+PHv3W+u43
05N7Uqv9vOK7RKMp6P8fNz5Tat1+13eAJ/+4k86L+SR/tPZ4UUzGLJKcVotZ
X6kdabsT+MhksoB8lccLeS39HV4F0bXiNR4geg1PRO3tuWzOGRscpXSD/YeX
uYjuObkHZmQAHKfHU8p8cKKqeUsvPZ7Lt2gpf4enq1p+SZh6m/jeihOYefyj
m7odeMXvAK7+bYJZ+Do93h3wq44Ac/EonZ5vOAXmUfp0w92V0/NHawSo7F7z
aH6+8Xhz8zih7aNbokfAq1Tf4/Wem2En2/h63663K363maLmd62af3M192Rh
sOHmGN8ecyJJnR5vuJcdufe5FsgbHne84e26tH0dr4gbEV63i47cDzvVblPu
0Z6r4Tfq0bq+77euHsn73q23uuSa4vrEvZGeHfPXplO7PGyP10O39jpe85u8
5jd+zW8rurWPboFBJ7oYiDayjulyYPMCmaNQjsFTFp+u/I4EzWCfCC875a+i
pwtB3R2n5qrkqFZSdWEdpTP5vJiySxnp4J/0hgl1px1/nxhq/E+Nb5N2lsx1
f92PAVmfX7JiqTfb8rJyE8XI4vk4tMVNntZy46Ijn3beJkagWva0lpvn+Jpa
9rmpG2Re67klQHYOWGgjUr5N7dG93c5a3mpbOjdq17iwIPGbHx2q5TdfS/fm
iGvp7hGgrthYeknBIiy+03qmb2gpnxYCRG7X7fyc16E7Cd97aZ6W+k7HFRzu
Vn9pym0of7jmGveXXEwJ3zfuN5q/5n3zymwJboqTM0s13bs56vO5I4c93xwK
ns3XDoMjzRlP8JwYJsGM7Em6R2zKkuqgdcTVmc6DtE6E27q9Xwmmp5rLacCW
GyqUCi03numxPaWAeYBj16fNTsIQ6inlQQU3Os9H78ORopenU8P640phJmiZ
nDY8MO68gqFeZpkUnnWcVIaI0tQp580HXOdUH/MqkdLAxTj505SQOI7LgujO
Cgl+72r5STWfVxd94joL7cLqSzzeOCaIO+OWBC4WZnLTptL48O+uG2iiJ7KU
RxJeJ5ngliF0CqYfAIoTWpG6aBR8SWDTOS+SmesxjbBBUh2X2TJoNczyIVvG
jhx8HNloLhEN5iei6wT5lVvi3hcYV6hP7LdL+9/cxlldmo5ORiSRq5EX7y6a
6sZyg4uqQm1vJtLy1zeJ2HAiK/Xmzo4B5UamOkPli93Bv4CiOLq72JEPFXFB
3gzlPqSS+XotR22WjooZe4ZCRYzXJ00QxxGHp6mLylzVzF4n97MZKKH9hP4i
DhuoSRGJTABOCUmvTY5T/QG08eRfiLekyq3BnWIOkOANEJedkqT60U5g22f+
Axj36nmeSUiA6aUKIUaQ8FWI6ZjpZPOkfYoJlxyvBT2qmCmzubKkmB+XhAFl
eJWWfsPrkShH3FxFfbXrSLOkuT6eOKGdxa5h0LV4M1VRuufYzyHu/mks7hRj
dpps5Ffw/rKQqAMi+UW+AvLcjUbVomQrdsN+sQk2uN3ZLFv2H8PgLzbdn0sK
SSpzYgtxm4S9NwDGy+fEvDDJgHnJZLtFoE1YMvEx3Or0cHI6QRSDe0FjARjz
bXNlgPWe5851PXG7o+yz0V/oTGtj1jsuj/vuI8q4Vx1vf13CSUdHErwac1Gr
gJ92jmwqJxaMx40qXZmWCx8TiDd9LwNGs5A07Ai6sbvkg66/t9f92KF7D7zc
+Y3/NGg9dq+zuv9oPve287GORnUZBloNHEij2jYB+d48HBr4H9Gz5vvwdGQR
WPXZP96l93d8TvzH0IZrPyf2pZ/1v3R/jvOddCtNh2m6nab30/RBmj5M02/T
9LvUraP0D+lwKx0O0+F2OryfDh8kCUWco0iKUikKpiiboniKGlJU4v6+a4iK
u2X6fWSPaHKzlbwDxRYBentYExbi5eKTNL6zPPooVcibEVt6SdGNF1lZAFuB
NgDUONqT7rI4l3AklSwQ+sRWPMHVZIXPbxoEkbu2V7Ml42xybttsMcntuZKe
F2fnfQ5GIHo1hGDzuQit8ryYyD5OpDns3Im3qvZQzCjp8dWx+IKDP5fo6zgA
YLPNm8evfLQ1vEof/eiOhFP3eevK9Zy4VB4Nt66Y044Fb0gubUGgwCgUDDNr
8UKV+hDMU2M2AVMcgpyEgqkL1hZws1bmAqKK/wvomHzuenLqGf92/PLYy/Q4
v7Ag2B49Hu8QsTMJNccv02/S4TF7IDSWUWxTEHqEO4gKDxBoS2bqHXdrLEqa
2PArbGIUWgSZ5HjjZX+46TbV9rGrB9STAw62NZrX0olgJXyzTpK6YJqeub2W
zQ3XYIjlIMUEbxbPtZd8ONAeE4k3JF8J6ouQDkqfnGBF0UzpFP589+W2m1+Q
6LrlcTVID9zwugHhAModV0lKYu/GBfG4nk6qasYfJ9XZhlsQ25ubm06MO03d
v7c3rjY5BMWJDG7hPEq3dvzRNcvdLijTLbZ9vU/dj8zAdU7e6o2r9Mcf0/eb
6Y+2zPv0m0fpMDHF3/eHifTLw9NmEessDceAMPU+iHGdn9vCKixUyKhdJeHH
YS/N5yNWyVCZk1Wx02ZkJKKVNTeRWowv3HM1QAaiyedqBC77IrsKjQPBtVY1
nSzI9Z0PeMTomXjI/pXSUIe3Gzk/dFx4k0oPrx1DHcGAMs07JkhSIWgtM7JB
KbIBN5/KHF0W4/n5Rhn6UK5qPP2D8kJaP21/vVGm/dQ13O1IbZo72/IrH/pd
Vayo82yvahA95pty6YYpaqEdgY1h+sMPvGIvNzfp5WFRnc7lkKV3CZS2Fa90
7k7nfupoSnQydRzeN8chI7/7ASRZitxY97KfRt/rKlnfTGxbr9L/m25gVbgm
b7zHSG1qc/mQ/Iz24sH/2Qbf72qwXGV+13Lr+Fs6TsrGARLNaWezwuKQZnFl
2qhWV0/cF7xlXNu+obbJxokWyBXZBzHk790DrkMn0ptvbG/Y5uaHXx0b62o3
4t6Js8F2b0oWa9Pp0Ocf0mlrh/DkTTdX7yEsx6lvV8OVnokbH1IF6VpkW8F0
0lZ348ft5FJHVMq2dZb6aYinptWKv/6Nx3zsSrjP4Yy6Sv8lev6qq/soOchw
P+tkScVj7Zjwj39+n7jA562sdidaI8K/DIqyzmfzDXenXOlX02q6EbX5rzrt
SyqIC3oJj+7fQmcuLhBez2EdWEGXlUovkvLnLula1nfI+YXO/1UrjuOkYv3Q
n4j8hiN9w1GdO3l2XoyoM8swJGOajzqfb/z16m9kN6ePra5LR5f66LLz0aV5
9IqeHdOlNl7q0DuxYsP9sHnTYXOauXWDqwhGzcZQNU6ciwKV9ij37BE2++b/
vzHmAjLCRzLCX6VPnaRL9kgTdU0RMiKU2+bpuYKCE1fPZGnOsG+GPfm8dJ91
WDcm7uRwD7mBJYl64+rHH6nUo3RJH/wil/FaykGCgksUvDIFr7TgVbPgVRL3
Rs4/6hN+uCKKCCcBpNT7TmnlqqSjYFn6qQ9FSjqTh/gXfdAH2vLLhnsUB7M7
jDfkWuwP5R6HWuLm7XlRvo8tPU559Oj7rBxRZpJQM1DU3pxicK2pkA3T6RpZ
m1nYXkuaJhyeShhIsYBQC1l6JBWtVv1A5E4a5ntAauTLkwwKG7tuaU05O0R0
ECvgx6802QhCqcJ2sbkw3je1MG+PwwnZrfpiO6yrfhtpToPNND1ELlZr+Ehc
RPcEzo5bwKZ5qw7TRvKGNK8Px1qdUX4UjVCNeuOxMYo6sRseftbCkLtS+hA7
DsUmRW3cUrqgbdVOmZ/moJm/rFOJqKkj3dSTmPrOcqb1K6hUsX41mmROb4Id
hE88dxwcAaPu6GijzienPdYse6xAv4S7kTVo+mzuHnp4wB7eR8HT+5Xg+RjR
Ii4BafURC60pl3geBNj28ywuPhKxEc+/NhIkCqDEvxG3bjG6yF0/x75vUJaP
xN67MXZn9bnpgztN8FVD/zAbl0ZqAz1P/M/PXXPo+0FH5W5T++def+ZzzVfJ
2D/XgX8t76b+wK+IiTLdeH7E7sZH6YYZY3q5azclVvlvB1zetPEfL6pHm10I
WpAOZm0VfZbXJLL+3sBj27n+mitM5octcF9RTDoLU7r3GquFJGtuBFaK1cKC
n0Hix9w9Iq3iuilEMRPzinoI5GzDRIRJwF5vNtctJtviSFhodWfY/sm3vXvF
+WduWl/hPZsrBmf1OutoK64yGaHIlMQ7UsOCdWz0nFs1OtwImSJdXxB+Zafz
T43N2JC11vayEmnb2h6rYW9RtUO+INbMIJKm78o0XqjL+pYvDE55GQD7JjN6
fTvVdhZCM2gSIAP8Pys5KS+zKAQA
</rfc> </rfc>
 End of changes. 1458 change blocks. 
6834 lines changed or deleted 6473 lines changed or added

This html diff was produced by rfcdiff 1.48.