IETF-OCM-MLS.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.43 (Ruby 3.2.11) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-ietf-ocm-mls-federated-groups-00" category="std" consensus="true" submissionType="IETF">
  <front>
    <title abbrev="OCM MLS Federated Groups">Federated Groups in Open Cloud Mesh using Messaging Layer Security</title>

    <author initials="M." surname="Nordin" fullname="Micke Nordin">
      <organization>SUNET</organization>
      <address>
        <email>kano@sunet.se</email>
        <uri>https://code.smolnet.org/micke</uri>
      </address>
    </author>
    <author initials="G." surname="Lo Presti" fullname="Giuseppe Lo Presti">
      <organization>CERN</organization>
      <address>
        <email>giuseppe.lopresti@cern.ch</email>
        <uri>https://cern.ch/lopresti</uri>
      </address>
    </author>
    <author initials="M." surname="Baghbani" fullname="Mahdi Baghbani">
      <organization>Ponder Source</organization>
      <address>
        <email>mahdi@pondersource.org</email>
        <uri>https://pondersource.com</uri>
      </address>
    </author>

    <date year="2026" month="September" day="11"/>

    <area>Applications and Real-Time</area>
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<?line 34?>

<t>This document defines an extension to the Open Cloud Mesh (OCM) protocol
to support federated groups as Receiving Parties of shares.  This is
achieved using the Messaging Layer Security (MLS) protocol (RFC 9420) as
a group management layer.  MLS is used for establishing and rotating a
shared group key across federated group members, as well as for
maintaining group state.  This gives not only a way of federating group
membership, but also a standardized way of distributing encryption keys
in a cryptographically secure way, so that files shared with a group can
optionally be encrypted and decrypted.  MLS usage in OCM acts as a
vehicle for group management that gives users optional encryption
capabilities for resources shared with federated groups.</t>



    </abstract>



  </front>

  <middle>


<?line 48?>

<section anchor="introduction"><name>Introduction</name>

<t>Open Cloud Mesh [OCM] currently supports sharing resources with
individual users across federated servers and with groups on a single
server.  This document defines a new <spanx style="verb">shareType</spanx>, <spanx style="verb">"federation"</spanx>, and
registers it in the "OCM Share Types" registry defined by [OCM].  A
<spanx style="verb">"federation"</spanx> share is addressed to a federated group identified by an
OCM Address such as <spanx style="verb">research-group@receiver.example.org</spanx> whose
membership spans multiple OCM servers, with group state managed through
the MLS [RFC9420] epoch mechanism.</t>

<t>In many Enterprise File Sync and Share (EFSS) systems, which constitute
the vast majority of all OCM Servers, there is a tight coupling between
a client and a server, because the server offers a built-in web
interface as its primary client.  In addition to this, a sync client is
often offered as a way of syncing files between the EFSS system and the
user's devices.</t>

<t>In MLS, a client is defined as an agent that establishes shared
cryptographic state with other clients, defined by the cryptographic
keys it holds.  An EFSS server meets this definition directly.  For
deployments where the primary user interface is a web client, the OCM
Server fulfils the MLS client role server-side, holding key material on
behalf of its users, and the word "client" as used in this document
should not necessarily be taken to mean the user's file sync client.
Implementations that do provide a native client application SHOULD
perform cryptographic operations in the native client on the user's
devices, rather than on the server, because this provides stronger
isolation of key material from the server.  A user participating from
multiple native devices MUST do so using an MLS Virtual Client as
specified in [ietf-mls-virtual-clients], with the devices acting as
Emulator Clients.  In either case the same MLS client model applies.</t>

<t>Each user who is a member of a federated group has exactly one MLS leaf
node, enabling individual users to be added and removed independently.
The OCM Server can act as the MLS client on behalf of its users.  For
implementations where the primary interface is a web client, the OCM
Server holds and uses key material server-side.  Implementations with a
native client application SHOULD perform cryptographic operations in the
native client, with the server acting as a relay for MLS messages.</t>

<t>Throughout this document, actions described as being performed by an OCM
server are understood to be performed by that server in its capacity as
an MLS client, on behalf of one of its users.  The server holds no group
membership or cryptographic state independent of its users.</t>

<t>The group and its membership exist and evolve independently of any
sharing activity.  A user that wants to share a resource with a group
can do so without the need to know the current membership details of
that group.  The MLS Delivery Service role is distributed: proposals are
delivered to the home servers of all admins, the Group Owner Server
arbitrates Commits, and File Key (FK) distribution messages are sent
directly from sending servers to member servers, just like OCM share
notifications.  Group membership changes are managed entirely through
MLS group lifecycle operations.</t>

<t>Every group has one or more admins: users who administer the group.  The
user who creates a group is its first admin.  Adding a member, or
removing a member other than oneself, requires the approval of an admin,
placing a human in the loop for changes that grant or revoke access.
Any member can remove themselves from a group without admin approval,
though the Commit is still performed by an admin client.  All Commits
that advance the MLS epoch are constructed by the MLS clients of admins
and arbitrated by the Group Owner Server.</t>

<t>The group's OCM Address is a stable label.  It is minted under the
domain of the server where the group was created, which guarantees its
uniqueness, but it carries no routing semantics: all protocol messages
are routed using the OCM Addresses of individual members and admins,
never the group's.</t>

<t>Files shared with a group can optionally be encrypted with a per-file
key (FK), wrapped with the current group key.  The group key is derived
from the MLS epoch secret and rotates with every epoch transition.  On
every epoch transition the sending server re-wraps the FK under the new
group key and redistributes it, so that the current group key is always
sufficient to unwrap the current FK.  When a member is added to a group,
their MLS client receives the new group key and the re-wrapped FKs, and
can immediately decrypt all resources shared with the group.</t>

<t>When a member is removed from the group, sending servers MAY
additionally generate a new FK and re-encrypt affected resources,
depending on their policy and the nature of the shared data.</t>

</section>
<section anchor="terminology"><name>Terminology</name>

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
[RFC2119] [RFC8174] when, and only when, they appear in all capitals, as
shown here.</t>

<t>Unless stated otherwise, every base64 encoded value this document,
including MLS wire-format messages, KeyPackages, <spanx style="verb">group_id</spanx> values, and
wrapped keys, is encoded using base64url (the URL- and filename-safe
alphabet defined in [RFC4648], Section 5) with padding omitted.  A
decoder MUST accept such a value whether or not padding is present.</t>

<t>This document uses terminology from [OCM], [RFC9420] and
[ietf-mls-virtual-clients].  Additional definitions:</t>

<t><list style="symbols">
  <t><strong>Group</strong> - A Receiving Party identified by an OCM Address whose
identifier resolves to a set of members spanning multiple OCM servers,
with group state managed through MLS.  The Group's OCM Address is a
stable label assigned at creation and MUST NOT change for the lifetime
of the Group; it carries no routing semantics.  In [RFC9420] a group is
defined as: "a logical collection of clients that share a common 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>
  <t><strong>MLS Client</strong> - As defined in [RFC9420]: an agent that establishes
shared cryptographic state with other clients, defined by the
cryptographic keys it holds.  In this protocol an OCM Server can fulfill
this role.</t>
  <t><strong>Virtual Client</strong> and <strong>Emulator Client</strong> - As defined in
[ietf-mls-virtual-clients].  When a user participates from multiple
devices, the user's single leaf in the federated group represents a
Virtual Client and the devices are its Emulator Clients.  The federated
group is the Higher-level Group in that document.</t>
  <t><strong>Member Server</strong> - An OCM server with one or more users who are
members of a given Group, acting as MLS client on their behalf.</t>
  <t><strong>Group Owner Server</strong> - The server currently arbitrating Commits for
the Group: the home server of the first Admin in the admin set.
Initially this is the server at which the Group was created.</t>
  <t><strong>Admin</strong> - A user who administers the Group membership.  The user who
creates a Group is its first Admin.  Only the MLS clients of Admins
(admin clients) construct Commits.  The admin set is part of the group
state (<xref target="admin-set"/>).</t>
  <t><strong>Admin Server</strong> - The home server of an Admin.  Admin Servers
collectively queue proposals for the Group.</t>
  <t><strong>Group Key</strong> - A symmetric key derived from the current MLS epoch
secret via the MLS Exporter, with the key length of the AEAD algorithm
of the group's cipher suite.  Rotates with every epoch transition.</t>
  <t><strong>File Key (FK)</strong> - A random symmetric key used to encrypt a single
shared resource.  Wrapped with the current Group Key and distributed to
Member Servers via MLS Application Messages.  Re-wrapped under the new
Group Key on every epoch transition (<xref target="fk-rewrap"/>).  Member Servers
always store the most current wrapped FK for each resource.</t>
  <t><strong>Re-encryption mode</strong> - On member removal, the sending server
generates a new FK, re-encrypts the resource, and distributes the new
wrapped key.  Provides strong cryptographic guarantees independent of
trust assumptions.</t>
  <t><strong>Key-reuse mode</strong> - On member removal, the existing FK is kept and
only the standard re-wrap on epoch change (<xref target="fk-rewrap"/>) is performed,
without re-encrypting the resource.  Appropriate only within formally
trusted federations and where re-encryption is impractical.  Mode is not
a binary choice; sending servers can choose one mode for one epoch and
another mode for another epoch, depending on policy and other
circumstances.</t>
  <t><strong>KeyPackage</strong> - As defined in [RFC9420].  A signed object that
enables adding an MLS client to a group asynchronously.  KeyPackages
MUST be used only once, except for a designated last resort KeyPackage
([RFC9420] Section 16.8).</t>
</list></t>

</section>
<section anchor="mls-roles-in-ocm"><name>MLS Roles in OCM</name>

<t>MLS is designed to operate with two supporting services: an
Authentication Service (AS) and a Delivery Service (DS) ([RFC9420]
Section 3; see also the MLS architecture [RFC9750]).  This section
describes how those roles are fulfilled by OCM.</t>

<section anchor="authentication-service"><name>Authentication Service</name>

<t>The AS role is fulfilled by each user's home OCM server.  Credentials in
this protocol are MLS basic credentials ([RFC9420] Section 5.3) whose
identity field is the UTF-8 encoded OCM Address of the user.  Each user
has their own distinct signing key material so that individual users can
be identified and addressed independently within the MLS group, for
example to add or remove a specific user.  In web-client deployments the
signing key material is generated and held by the OCM Server on the
user's behalf.  In native client deployments with one device it is held
on that device.  With multiple devices, signing key material is managed
as specified for the Virtual Client in
[ietf-mls-virtual-clients], and the server's role is limited to
publishing the user's KeyPackages.</t>

<t>A basic credential carries no verifiable binding of its own; the binding
between a user's OCM Address and their signature key is attested by
authenticated delivery from the user's home server.  A KeyPackage
fetched over TLS from the <spanx style="verb">&lt;endPoint&gt;/mls-key-packages</spanx> endpoint of the
server named in the credential's OCM Address, with the response signed
using HTTP Signatures [RFC9421] verifying against that server's JWKS
endpoint at <spanx style="verb">/.well-known/jwks.json</spanx> [RFC7517], is considered validated
with the AS.  The full validation procedure, including how credentials
introduced later in the life of a group are validated, is specified in
<xref target="trust-and-authentication"/>.</t>

</section>
<section anchor="delivery-service"><name>Delivery Service</name>

<t>The DS role is distributed across the servers of the group rather than
centralised on a single server.  MLS places no constraints on how the DS
is arranged, as long as messages are delivered ([RFC9420] Section 3).</t>

<t><list style="symbols">
  <t>Proposal delivery: <spanx style="verb">MLS_PROPOSAL</spanx> notifications are sent to the home
server of every admin (<xref target="admins"/>), derived from the admin set and the
OCM Addresses in the ratchet tree's leaf credentials.  Admin Servers
queue proposals, deduplicated by ProposalRef ([RFC9420] Section 5.2),
and make them available to their admin clients.</t>
  <t>Commit arbitration: the Group Owner Server, the home server of the
first admin in the admin set, accepts exactly one Commit per epoch from
an admin client and broadcasts it to all Member Servers.</t>
  <t>FK distribution: <spanx style="verb">MLS_APPLICATION</spanx> messages carrying wrapped file keys
are sent directly from the sending server to all current Member Servers,
exactly like OCM share notifications; credential updates are sent to a
single Member Server (<xref target="credential-update"/>).</t>
</list></t>

<t>All MLS messages are delivered to the <spanx style="verb">&lt;endPoint&gt;/notifications</spanx>
endpoint of each recipient server, authenticated with HTTP Signatures
[RFC9421].</t>

<t>For a Virtual Client, the user's home server MUST deliver messages sent
to or by the Virtual Client to all of its Emulator Clients, as required
by [ietf-mls-virtual-clients] Section 5.1.</t>

<t>Commits are constructed and signed by admin clients, but only the Commit
accepted by the Group Owner Server takes effect; competing Commits for
the same epoch are discarded by their senders.  Designating a single
arbiter of Commits eliminates conflicting Commits for the same epoch
during normal operation, satisfying the sequencing requirement of
[RFC9420] Section 14; conflicting Commits can arise only during failover
and are then resolved deterministically (<xref target="failover"/>).  Per [RFC9420]
Section 14, generating a Commit does not modify the sender's state, so
an admin client whose Commit is rejected simply discards it and
constructs a new Commit on the new epoch.</t>

<t>OCM share notifications are sent directly from the sending server to
each Member Server.  Since sending servers must be group members, they
hold the current MLS ratchet tree after processing each <spanx style="verb">MLS_COMMIT</spanx>,
and can derive the current membership - specifically the OCM Address in
each leaf node's credential - to determine which Member Servers to
contact.  No proxying through the Group Owner Server is required for
OCM-level communication.</t>

<t>MLS is designed to protect confidentiality and integrity even against a
misbehaving DS.  No single server in this design carries the full DS
role, and no server holds key material by virtue of its DS duties; the
MLS security properties with respect to message confidentiality hold
regardless.</t>

</section>
</section>
<section anchor="how-mls-is-implemented-over-ocm"><name>How MLS is implemented over OCM</name>

<t><list style="symbols">
  <t><strong>MLS for group key management only.</strong> MLS establishes and rotates a
shared group key.  The only MLS application messages used in this
protocol carry wrapped file keys (<xref target="key-distribution"/>) and per-server
transport credential updates (<xref target="credential-update"/>).</t>
  <t><strong>Exactly one MLS leaf per user.</strong> Each user who is a member of a
federated group has exactly one MLS leaf node, enabling individual users
to be added and removed independently.  In web-client deployments the
OCM Server manages that leaf on the user's behalf.  A user participating
from multiple native devices MUST represent those devices by a single
Virtual Client leaf, with the devices acting as Emulator Clients in
accordance with [ietf-mls-virtual-clients].  A leaf per device, the
Simple Multi-client model defined by that document, MUST NOT be used.
Adding or removing a device MUST use the emulation-group management
procedures in [ietf-mls-virtual-clients] Section 6, not an Add or
Remove in the federated group.</t>
</list></t>

<t>Transitioning from a single device to multiple devices is an
implementation detail that does not affect the protocol.  A native
client implementation is however RECOMMENDED to establish an emulation
group when enrolling the user's first device and represent the user as a
Virtual Client, even while that device is the only Emulator Client.</t>

<t><list style="symbols">
  <t><strong>The OCM Server is a MLS client.</strong> An OCM Server meets the MLS
definition of a client.  For web-client deployments this means key
material is held server-side.  For native client deployments
cryptographic operations SHOULD be performed in the native client.</t>
  <t><strong>Admins approve membership changes.</strong> Every group has one or more
admins (<xref target="admins"/>).  Commits are constructed by admin clients and
arbitrated by the Group Owner Server.  Add proposals and Remove
proposals targeting another user require admin approval; any member may
remove themselves, and Update proposals are committed automatically.</t>
  <t><strong>Encryption is optional.</strong> MLS group management is useful
independently of whether encryption is used.  A federation share MAY be
unencrypted, in which case the <spanx style="verb">encryption</spanx> field is omitted from the
Share Creation Notification and the MLS layer provides only group
membership management.</t>
  <t><strong>FK re-wrap on every epoch change.</strong> After processing an <spanx style="verb">MLS_COMMIT</spanx>
for a group, a sending server MUST re-wrap the current FK of every
resource it shares with that group under the new Group Key and
distribute it via <spanx style="verb">MLS_APPLICATION</spanx> (<xref target="fk-rewrap"/>).  This maintains the
invariant that the current Group Key is always sufficient to unwrap the
current wrapped FK.</t>
  <t><strong>FK rotation on member removal.</strong> On member removal, a sending server
SHOULD additionally rotate the FK for affected resources: generate a new
FK, re-encrypt the resource, and distribute the new wrapped FK to all
groups that share those resources.  FK rotation may also be triggered by
other factors such as periodic key rotation policy or suspected key
compromise.  Member addition does not require FK rotation; the standard
re-wrap is sufficient.</t>
  <t><strong>Key-reuse mode as an alternative.</strong> Where re-encryption on removal
is impractical and where participating servers are mutually trusted
within a formal federation, a sending server MAY instead keep the
existing FK, relying on the standard per-epoch re-wrap alone.</t>
  <t><strong>Sending servers must have group members.</strong> To share a resource with
a group, the sending server must have at least one user who is a member
of that group, allowing it to work out the members to share with, and to
be able to wrap the FK for encrypted shares.  This is by design, to
mitigate spam shares and other abusive behaviour.</t>
  <t><strong>OCM messages are still just OCM messages.</strong> Proposals flow to the
servers of all admins, Commits are arbitrated by the Group Owner Server,
and FK distribution and OCM share notifications flow directly from the
sending server to each Member Server, derived from the sending server's
local view of group membership from the MLS ratchet tree.  No message is
proxied through a single central server.</t>
  <t><strong>Sending servers derive membership from the ratchet tree.</strong> Since
sending servers must have group members, they process all <spanx style="verb">MLS_COMMIT</spanx>
messages and hold the current ratchet tree.  The OCM Address in each
leaf node's credential identifies the corresponding Member Server.  The
sending server uses this to determine which Member Servers to contact
directly for share notifications and FK distribution.</t>
  <t><strong>Push-based FK distribution.</strong> Wrapped file keys are distributed via
<spanx style="verb">MLS_APPLICATION</spanx> directly from the sending server to all current Member
Servers, at share creation and after every epoch transition
(<xref target="fk-rewrap"/>).  Member Servers always hold the current wrapped FK for
each resource and use their current Group Key to unwrap it at access
time.</t>
  <t><strong>Minimal protocol surface.</strong> The <spanx style="verb">shareType: "federation"</spanx> value
already defined in the OCM specification is used without modification,
with <spanx style="verb">shareWith</spanx> carrying the group's OCM Address.  A federation share
is otherwise a standard OCM share, carrying every field REQUIRED by
[OCM] including the <spanx style="verb">protocol</spanx> object.  All new server-to-server
messages use the existing <spanx style="verb">/notifications</spanx> endpoint with new
<spanx style="verb">notificationType</spanx> values.</t>
</list></t>

</section>
<section anchor="discovery"><name>Discovery</name>

<t>A server signals support for federation shares by including
<spanx style="verb">"federation"</spanx> in the <spanx style="verb">shareTypes</spanx> array for a given resource type in
its OCM discovery document at <spanx style="verb">/.well-known/ocm</spanx>:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "enabled": true,
  "apiVersion": "1.5.0",
  "endPoint": "https://cloud.example.org/ocm",
  "provider": "Example Cloud",
  "resourceTypes": [
    {
      "name": "file",
      "shareTypes": ["user", "group", "federation"],
      "protocols": { "webdav": "/webdav/", "webdav-receive": {} }
    }
  ]
}
]]></sourcecode></figure>

<t>No additional discovery fields are introduced.  The notifications
endpoint is derived as <spanx style="verb">&lt;endPoint&gt;/notifications</spanx> per the base OCM
specification.  The KeyPackage endpoint is derived as
<spanx style="verb">&lt;endPoint&gt;/mls-key-packages</spanx>.</t>

<t>A server that advertises <spanx style="verb">"federation"</spanx> MUST be able to receive OCM
Notifications, since all MLS lifecycle messages are delivered as
notifications, and SHOULD include <spanx style="verb">"notifications"</spanx> in its
<spanx style="verb">capabilities</spanx> array.</t>

</section>
<section anchor="keypackage-distribution"><name>KeyPackage Distribution</name>

<t>Each OCM Server acting as an MLS client generates and maintains
KeyPackages for its users and exposes them at:</t>

<figure><artwork><![CDATA[
GET <endPoint>/mls-key-packages?userId={userId}
]]></artwork></figure>

<t>Response:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "userId": "alice@cloud.example.org",
  "keyPackages": [
    {
      "mediaType": "message/mls",
      "encoding": "base64url",
      "content": "<base64url-encoded MLS KeyPackage>"
    }
  ]
}
]]></sourcecode></figure>

<t>Requests to this endpoint MUST be signed using HTTP Message Signatures
[RFC9421] (<xref target="security-considerations"/>).</t>

<t>In native client deployments, the user's device generates KeyPackages
and publishes them to the home server, which exposes them at the same
endpoint without interpreting them.  For a user with multiple devices,
the Emulator Clients MUST create and coordinate the Virtual Client's
KeyPackages as specified in [ietf-mls-virtual-clients] Section 5.5.1
before publishing them to the home server.</t>

<t>Each KeyPackage contains an MLS Credential identifying the user by their
OCM Address, signed by the user's own signing key pair.  Users who
require stronger isolation of key material from their server should use
a native client implementation.</t>

<t>KeyPackages MUST be one-time use, with the exception of a designated
"last resort" KeyPackage ([RFC9420] Section 16.8).  The server MUST
remove a KeyPackage after it has been delivered.  Servers SHOULD
pre-generate multiple KeyPackages per user to support concurrent group
additions, MAY designate a last resort KeyPackage per user to be
returned when all single-use KeyPackages are exhausted, and SHOULD
rate-limit KeyPackage requests, so that an attacker cannot block a
user's addition to groups by exhausting their KeyPackages.  KeyPackages
carry a leaf node lifetime, and applications MUST define a maximum total
lifetime they accept ([RFC9420] Section 7.2).</t>

<t>The <spanx style="verb">userId</spanx> fields defined in this document carry the user's full OCM
Address, not the bare identifier that [OCM] calls <spanx style="verb">userID</spanx>; the full
address is required because these messages routinely cross server
boundaries.</t>

</section>
<section anchor="group-lifecycle"><name>Group Lifecycle</name>

<t>The group lifecycle is entirely independent of other OCM lifecycles
(token-exchange, shares, invitations etc.).  Members are added and
removed through MLS group operations conveyed via the <spanx style="verb">/notifications</spanx>
endpoint.</t>

<section anchor="group-creation"><name>Group Creation</name>

<t>The creating server creates an MLS group on behalf of one of its users
and initialises leaf nodes for each of its users who are initial
members.  The creating user becomes the group's first admin
(<xref target="admins"/>), making the creating server the initial Group Owner Server.
No notifications are required for this step.  The group becomes
addressable at its OCM Address immediately upon creation.</t>

<t>The group's OCM Address is minted under the creating server's domain,
which guarantees its uniqueness, and MUST NOT change for the lifetime of
the group.  It is a label only: no protocol message is routed based on
it, and it remains valid even after the Group Owner Server role has
moved to another server.  The MLS <spanx style="verb">group_id</spanx> SHOULD be a fresh random
value, as recommended by [RFC9420] Section 11.</t>

<t>The creator selects the group's MLS cipher suite based on the
capabilities advertised in the prospective members' KeyPackages
([RFC9420] Section 11).  Implementations of this document MUST support
the mandatory-to-implement MLS cipher suite
MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519 ([RFC9420] Section 17.1).</t>

</section>
<section anchor="admins"><name>Group Admins</name>

<t>Every group has a set of admins: users who administer the group
membership.  The user who creates the group is its first admin, and an
admin MAY appoint further admins.  Admins are ordinary group members and
MAY be homed on any Member Server.  An admin's MLS clients are referred
to as admin clients.</t>

<t>Commits MUST be constructed and signed by admin clients.  This is an
application-level policy on top of MLS, as anticipated by [RFC9420]
Section 16.11, and it is enforced at two points.  First, the Group Owner
Server MUST reject Commits submitted by any other client.  Second, every
Member Server processing an <spanx style="verb">MLS_COMMIT</spanx> MUST verify that the Commit is
signed by an admin client: a Commit is signed by the leaf indicated in
its sender field ([RFC9420] Section 6.1), and the credential at that
leaf, in the ratchet tree of the epoch in which the Commit was created,
must identify a user listed in <spanx style="verb">admins</spanx> (<xref target="admin-set"/>) as of that same
epoch.  A Commit that fails this check MUST be rejected, regardless of
which server broadcast it.  Because the admin set is part of the
GroupContext, every member performs this check locally; acceptance of a
Commit does not rely on trusting the Group Owner Server.</t>

<t>Proposals are handled according to the following policy:</t>

<t><list style="symbols">
  <t>An Add proposal, or a Remove proposal targeting a leaf that does not
belong to the proposing user, MUST be explicitly approved by an admin
before an admin client commits it, unless both are part of a rejoin pair
as described below.  This places a human in the loop for changes that
grant or revoke another party's access.</t>
  <t>A Remove proposal targeting a leaf that belongs to the proposing user
(self-removal) does not require admin approval.  Any member MAY leave a
group at any time, and admin clients SHOULD commit self-removal
proposals automatically.</t>
  <t>A rejoin pair - a Remove of a leaf together with an Add of a fresh
KeyPackage whose credential carries the same OCM Address as the removed
leaf's credential (<xref target="rejoin"/>) - is identity-preserving and grants no
new party access.  It does not require explicit admin approval, and
admin clients SHOULD commit rejoin pairs automatically.</t>
  <t>Update proposals do not require admin approval, and admin clients
SHOULD commit pending Update proposals automatically whenever they are
online.</t>
</list></t>

<t>The group MUST have at least one admin at all times.  A proposal that
would remove the last admin, including a self-removal, MUST be rejected
by the Group Owner Server until another admin has been appointed.</t>

<t>Removing an admin from the group and removing an admin from the admin
set are distinct operations; when an admin's membership ends, a single
Commit combines them (<xref target="admin-set"/>).  An admin MAY instead resign from
the admin set while remaining a member: this is a GroupContextExtensions
proposal only, and the resigning admin's own client MAY commit it.
Removing an admin's membership is constrained by MLS: a Commit that
removes its own committer is invalid ([RFC9420] Section 12.2).  A Commit
that removes an admin's single leaf is therefore necessarily committed
by an admin client of a different admin.</t>

<section anchor="admin-set"><name>Group OCM Address and Admin Set</name>

<t>The group's OCM Address and the admin set are part of the group state,
carried in a GroupContext extension <spanx style="verb">ocm_federated_group</spanx> ([RFC9420]
Section 13.4):</t>

<figure><artwork><![CDATA[
struct {
  opaque ocm_address<V>;
} Admin;

struct {
  opaque group_ocm_address<V>;
  Admin admins<V>;
} OCMFederatedGroup;
]]></artwork></figure>

<t>All addresses are UTF-8 encoded OCM Addresses.  The <spanx style="verb">group_ocm_address</spanx>
field carries the group's OCM Address and MUST NOT change for the
lifetime of the group.</t>

<t>The <spanx style="verb">admins</spanx> list is ordered by appointment: a newly appointed admin is
appended at the end, a departing admin is deleted by the same Commit
that ends their membership or admin role (see below), and the list MUST
NOT otherwise be reordered.  The home server of the first admin in the
list is the current Group Owner Server.  Succession is therefore
automatic: when the first admin leaves the group or resigns as admin,
the home server of the next admin in the list becomes the Group Owner
Server.  For example, if alice on server1 creates the group and appoints
bob on server2 and then charlie on server3, the list is (alice, bob,
charlie) and server1 is the Group Owner Server; after bob leaves it is
(alice, charlie); after alice then leaves it is (charlie,) and server3
is the Group Owner Server.</t>

<t>An admin client is any MLS client whose leaf credential identifies a
user listed in <spanx style="verb">admins</spanx>.  Because this extension is part of the
GroupContext, it is agreed upon by all members through the MLS key
schedule, every member can verify which clients are entitled to
construct Commits and which server arbitrates them, and new members
learn the group's OCM Address and admin set from the GroupInfo in their
Welcome.  Changes to the admin set are made with a
GroupContextExtensions proposal ([RFC9420] Section 12.1.7); such
proposals MUST be explicitly approved by an admin, MUST be committed by
an admin client, and MUST NOT change <spanx style="verb">group_ocm_address</spanx>.</t>

<t>The admin set and the group membership are coupled: an entry in <spanx style="verb">admins</spanx>
is only meaningful while that admin's leaf is in the ratchet tree.  A
Commit that removes an admin's leaf MUST therefore also include a
GroupContextExtensions proposal deleting that admin from <spanx style="verb">admins</spanx>, and
the Group Owner Server and all Member Servers MUST reject a Commit that
would leave an entry in <spanx style="verb">admins</spanx> with no corresponding leaf in the tree.
(A rejoin pair (<xref target="rejoin"/>) that replaces an admin's leaf does not
trigger this rule, since the admin retains a leaf after the Commit.)
Because a GroupContextExtensions proposal replaces the extension list
wholesale ([RFC9420] Section 12.1.7), the proposal carries the complete
new <spanx style="verb">OCMFederatedGroup</spanx> value, with the departing admin deleted and
<spanx style="verb">group_ocm_address</spanx> unchanged.  A GroupContextExtensions proposal whose
only change to the admin set is deleting admins whose leaves are removed
in the same Commit requires no separate admin approval; it follows the
approval status of the Remove proposals it accompanies, so that the
self-removal of an admin can still be committed automatically.</t>

<t>Clients implementing this document MUST list the <spanx style="verb">ocm_federated_group</spanx>
extension type in the <spanx style="verb">capabilities.extensions</spanx> field of their
KeyPackages, since GroupContext extensions must be supported by every
member of the group ([RFC9420] Section 13.4).</t>

</section>
</section>
<section anchor="failover"><name>Group Owner Server Failover</name>

<t>The Group Owner Server can become unavailable, leaving the group without
an arbiter and therefore unable to advance its epoch.  Leaf staleness
(<xref target="leaf-key-updates"/>) anchors the failover trigger: the absence of
committed Updates from a leaf is part of the group state that all
members observe identically.  The other trigger condition, the absence
of broadcast Commits, is necessarily observer-dependent - a server that
missed a broadcast cannot distinguish silence from loss - which is why
divergent failover decisions are tolerated and resolved
deterministically in step 3 below.</t>

<t>In addition to the update deadline, groups MUST define a takeover time
T.  T MUST be longer than the update deadline, so that the staleness of
the first admin's leaf is observable before takeover is permitted.
Failover proceeds as follows:</t>

<t><list style="numbers" type="1">
  <t>Trigger: no <spanx style="verb">MLS_COMMIT</spanx> has been broadcast for time T, and the
first admin's leaf is stale.</t>
  <t>Takeover: the home server of the next admin in the admin set MAY
begin arbitrating Commits.  The first Commit it arbitrates SHOULD
cover a Remove proposal evicting the stale first admin's leaf,
together with the GroupContextExtensions proposal deleting that
admin from the admin set as required by <xref target="admin-set"/>, constructed
by one of its own admin clients.  This makes the takeover permanent
through the normal succession rule.</t>
  <t>Conflict resolution: if a Member Server receives two different
Commits for the same epoch from two arbiters, it MUST process the
one arbitrated by the server of the admin listed earlier in the
admin set and discard the other.</t>
  <t>Hold-back: a Member Server that has observed the trigger conditions
of step 1 SHOULD retain the previous epoch's group state when
processing a Commit, so that it can revert and reprocess the
winning Commit if conflict resolution later discards the one it
processed first. Retained state MUST be deleted after a bounded
time, per [RFC9420] Section 14; the security trade-off is discussed
in Security Considerations.</t>
  <t>Rejoin: a Member Server that processed a discarded Commit and no
longer holds the state needed to reprocess the winning Commit has
drifted from the group.  It recovers through the rejoin procedure
(<xref target="rejoin"/>).  Wrapped FKs are re-wrapped and redistributed by
their sending servers in the new epoch as usual (<xref target="fk-rewrap"/>).</t>
</list></t>

<t>Since an unavailable arbiter only pauses membership changes, while
sharing, resource access, and FK distribution continue to operate, the
takeover time T MAY be generous, for example several hours.  Loose time
synchronisation between servers is sufficient and is already assumed by
MLS for leaf node lifetimes ([RFC9420] Section 7.2).</t>

</section>
<section anchor="mls-notification-types"><name>MLS Notification Types</name>

<t>All MLS group lifecycle messages are sent as OCM Notifications to
<spanx style="verb">&lt;endPoint&gt;/notifications</spanx> using HTTP POST with <spanx style="verb">Content-Type:
application/json</spanx> and HTTP Signatures [RFC9421].</t>

<t>Proposals and Commits MUST be encoded as PublicMessage objects
([RFC9420] Section 6.2), and Application Messages as PrivateMessage
objects ([RFC9420] Section 6.3).  Handshake messages are sent in the
clear at the MLS layer because the servers that route and arbitrate them
are required to track the public group state, i.e the ratchet tree and
GroupContext, in order to derive membership for share routing, resolve
shares to local users, and verify that Commits are signed by admin
clients; in native client deployments those servers do not hold the
group's secrets.  A recipient that holds the group's secrets MUST verify
the membership_tag on a PublicMessage ([RFC9420] Section 6.2); a server
relaying or arbitrating without group secrets verifies what it can,
namely the signature against the sender's leaf in its copy of the
ratchet tree and the policy checks of <xref target="admins"/>.  The confidentiality
trade-off relative to encrypted handshake messages is discussed in
Security Considerations.</t>

<t>The notification types defined in this document are group-scoped rather
than share-scoped.  [OCM] requires a <spanx style="verb">providerId</spanx> field in notifications
because the notification types it defines all refer to a Share; the MLS
notification types refer to a group instead, so this document updates
that requirement: <spanx style="verb">providerId</spanx> is REQUIRED only for notification types
that refer to a Share, and the MLS notification types omit it.  All
MLS-specific parameters are carried inside the <spanx style="verb">notification</spanx> object
that [OCM] provides for type-specific parameters.  The <spanx style="verb">mlsGroupId</spanx>
field carries the base64url-encoded MLS <spanx style="verb">group_id</spanx> as advisory routing
information, used to dispatch the message to the right group state
without parsing the MLS message; the authoritative <spanx style="verb">group_id</spanx> is the one
inside the MLS message itself, and a mismatch between the two MUST be
treated as an error.  At the OCM layer, groups are otherwise identified
by their OCM Address: in particular, the <spanx style="verb">groupId</spanx> field of the
application data carried inside <spanx style="verb">MLS_APPLICATION</spanx> messages
(<xref target="key-distribution"/>, <xref target="credential-update"/>) is the group's OCM
Address, never the MLS <spanx style="verb">group_id</spanx>.</t>

<t>Since <spanx style="verb">MLS_PROPOSAL</spanx> is delivered only to Admin Servers and never
broadcast to other Member Servers, Member Servers never observe pending
proposals.  Proposals covered by a Commit are instead redistributed
together with that Commit, as described under <spanx style="verb">MLS_COMMIT</spanx> below.  Admin
clients, as the only committers (<xref target="admins"/>), MUST satisfy all
considerations of [RFC9420] Section 12.4.</t>

<section anchor="mlswelcome"><name>MLS_WELCOME</name>

<t>Sent to a Member Server when one of its users is added to the group.
The Welcome is constructed by the admin client that created the
corresponding Commit ([RFC9420] Section 12.4.3.1) and delivered by that
admin's home server directly to the added user's server, after the Group
Owner Server has accepted the Commit.  Delivers the MLS Welcome message
for the added user, enabling the receiving MLS client to initialise its
state and derive the current Group Key.  A single <spanx style="verb">MLS_COMMIT</spanx> covering
multiple Add proposals will result in one <spanx style="verb">MLS_WELCOME</spanx> notification per
added user.</t>

<figure><sourcecode type="json"><![CDATA[
{
  "notificationType": "MLS_WELCOME",
  "senderDomain": "othercloud.example.org",
  "shareType": "federation",
  "notification": {
    "federation": {
      "mlsGroupId": "<base64url MLS group ID>",
      "userId": "bob@othercloud.example.org",
      "content": "<base64url MLS Welcome wire format>"
    }
  }
}
]]></sourcecode></figure>

<t>The Welcome message MUST include the group's ratchet tree in a
<spanx style="verb">ratchet_tree</spanx> extension ([RFC9420] Section 12.4.3.3).  By default a
Welcome carries only a hash of the tree, and this document defines no
other channel through which a newly added Member Server could obtain it.
Member Servers depend on holding the current ratchet tree, both to
derive the group membership and to process subsequent Commits.  Carrying
the tree inside the Welcome also gives it the same confidentiality
protection as the rest of the group state, as recommended by [RFC9420]
Section 12.4.3.3.</t>

<t>A Member Server processing a Welcome learns the group's OCM Address from
the <spanx style="verb">ocm_federated_group</spanx> extension in the GroupContext (<xref target="admin-set"/>).
It MUST reject a Welcome whose <spanx style="verb">group_ocm_address</spanx> is already bound to a
different MLS <spanx style="verb">group_id</spanx>, unless the Welcome reinitialises the group as
described in <xref target="reinit"/>.  This keeps the local wrapped FK store, keyed
by <spanx style="verb">(resourceId, groupId)</spanx>, unambiguous.</t>

</section>
<section anchor="mlsproposal"><name>MLS_PROPOSAL</name>

<t>Sent by a Member Server to the home server of every admin to propose a
group change (for example Add, Remove, Update, GroupContextExtensions,
or ReInit) on behalf of one of its users.  This notification is NOT
broadcast to other Member Servers.  Each Admin Server queues received
proposals, deduplicated by ProposalRef ([RFC9420] Section 5.2), for
handling by its admin clients according to the policy in <xref target="admins"/>.
Sending the proposal to all Admin Servers removes the dependency on any
single server being available and lets whichever admin is online next
act on it.</t>

<figure><sourcecode type="json"><![CDATA[
{
  "notificationType": "MLS_PROPOSAL",
  "senderDomain": "cloud.example.org",
  "shareType": "federation",
  "notification": {
    "federation": {
      "mlsGroupId": "<base64url MLS group ID>",
      "content": "<base64url MLS PublicMessage carrying the Proposal>"
    }
  }
}
]]></sourcecode></figure>

</section>
<section anchor="mlscommit"><name>MLS_COMMIT</name>

<t>Constructed and signed by an admin client (<xref target="admins"/>) and submitted to
the Group Owner Server, which accepts at most one Commit per epoch, MUST
reject Commits submitted by non-admin clients, and broadcasts the
accepted Commit to all Member Servers to advance the group epoch.  An
admin client whose Commit is rejected discards it and MAY construct a
new Commit on the resulting epoch ([RFC9420] Section 14).  A Member
Server receiving a broadcast <spanx style="verb">MLS_COMMIT</spanx> MUST verify that the Commit is
signed by an admin client before processing it, as specified in
<xref target="admins"/>, and MUST reject it otherwise, regardless of which server
broadcast it.  Commits are ordered by the MLS epoch itself: each Commit
advances the epoch by exactly one, so Member Servers MUST process
Commits in epoch order, and a Commit arriving for an epoch later than
the next expected one indicates one or more missed Commits.  Member
Servers MUST apply the new epoch secret before sending any application
data, per [RFC9420] Section 15.2.</t>

<figure><sourcecode type="json"><![CDATA[
{
  "notificationType": "MLS_COMMIT",
  "senderDomain": "cloud.example.org",
  "shareType": "federation",
  "notification": {
    "federation": {
      "mlsGroupId": "<base64url MLS group ID>",
      "proposals": [
        "<base64url MLS PublicMessage carrying a Proposal>"
      ],
      "content": "<base64url MLS PublicMessage carrying the Commit>"
    }
  }
}
]]></sourcecode></figure>

<t>A Commit covers each proposal either by value or by reference ([RFC9420]
Section 12.4).  Proposals included by value are carried inside the
Commit itself and are necessarily proposals originated by the committing
admin client, since a by-value proposal carries no sender of its own.
Proposals received from Member Servers via <spanx style="verb">MLS_PROPOSAL</spanx> - in
particular Update proposals, which can only be applied relative to their
original sender's leaf - are covered by reference, and receiving Member
Servers need the original proposal messages in order to validate and
apply the Commit ([RFC9420] Sections 12.1 and 12.4.2).  The <spanx style="verb">proposals</spanx>
array therefore carries every proposal covered by reference, verbatim as
originally sent by their proposers, in the order in which the
corresponding references appear in the Commit.  It MUST be present
whenever the Commit covers at least one proposal by reference and MAY be
omitted otherwise.  A Member Server processing an <spanx style="verb">MLS_COMMIT</spanx> MUST
process the carried proposals before processing the Commit itself.</t>

<t>The <spanx style="verb">MLS_COMMIT</spanx> serves as the signal to all sending servers that the
epoch has advanced: each sending server then re-wraps and redistributes
the FKs of the resources it shares with the group (<xref target="fk-rewrap"/>), and
on member removal MAY additionally rotate them according to its policy
(<xref target="fk-rotation"/>).  Any Commit covering a Remove, Update, or
GroupContextExtensions proposal MUST include an UpdatePath ([RFC9420]
Section 12.4).</t>

</section>
<section anchor="mlsapplication"><name>MLS_APPLICATION</name>

<t>Sent by a sending server directly to Member Servers, derived from the
ratchet tree, to deliver updated wrapped file keys and, optionally,
updated per-server transport credentials (<xref target="credential-update"/>).  No
central relay is involved.  Messages carrying wrapped FKs are sent to
all current Member Servers; messages carrying a transport credential are
sent only to the affected Member Server.  The <spanx style="verb">content</spanx> is a
<spanx style="verb">PrivateMessage</spanx> carrying application data encrypted in the current
epoch ([RFC9420] Section 15).</t>

<figure><sourcecode type="json"><![CDATA[
{
  "notificationType": "MLS_APPLICATION",
  "senderDomain": "cloud.example.org",
  "shareType": "federation",
  "notification": {
    "federation": {
      "mlsGroupId": "<base64url MLS group ID>",
      "content": "<base64url MLS PrivateMessage wire format>"
    }
  }
}
]]></sourcecode></figure>

<t>Ordering is provided by authenticated MLS metadata rather than a
transport counter: the <spanx style="verb">PrivateMessage</spanx> carries the epoch in the clear,
and the sender's leaf and generation counter are learned upon decryption
([RFC9420] Section 6.3).  Since all FK updates for a given <spanx style="verb">(resourceId,
groupId)</spanx> originate from the resource's sending server, the <spanx style="verb">(epoch,
generation)</spanx> pair totally orders them; see <xref target="key-distribution"/>.  A
Member Server that receives an <spanx style="verb">MLS_APPLICATION</spanx> encrypted in an epoch
it has not yet entered SHOULD queue it until the corresponding
<spanx style="verb">MLS_COMMIT</spanx> has been processed.</t>

<t>Because credential-bearing messages are delivered to a single Member
Server, other Member Servers will observe a gap in the sending leaf's
generation counter on the next message they do receive.  Such gaps are
expected and MUST NOT be treated as an error; receivers ratchet forward
past skipped generations as described in [RFC9420] Section 15.3.
Deployments MUST limit the number of generations a receiver will advance
a sender ratchet in response to a single message and reject messages
beyond that limit, bounding the key derivation work a malicious sender
can trigger ([RFC9420] Section 15.3).</t>

</section>
<section anchor="mlsrejoin"><name>MLS_REJOIN</name>

<t>Sent by a drifted Member Server to the home server of every admin to
request re-admission of its users after local MLS state loss
(<xref target="rejoin"/>).  Unlike the other notification types, the content is not
an MLS message: a drifted server holds no usable MLS state, so the
request is authenticated only at the OCM layer, by the HTTP Signature of
the sending server.  Each entry in <spanx style="verb">keyPackages</spanx> carries a fresh MLS
KeyPackage for one affected user, in the same format as entries served
by the KeyPackage endpoint.</t>

<figure><sourcecode type="json"><![CDATA[
{
  "notificationType": "MLS_REJOIN",
  "senderDomain": "othercloud.example.org",
  "shareType": "federation",
  "notification": {
    "federation": {
      "mlsGroupId": "<base64url MLS group ID>",
      "keyPackages": [
        {
          "userId": "bob@othercloud.example.org",
          "mediaType": "message/mls",
          "encoding": "base64url",
          "content": "<base64url-encoded MLS KeyPackage>"
        }
      ]
    }
  }
}
]]></sourcecode></figure>

<t>Admin Servers queue rejoin requests alongside proposals and make them
available to their admin clients, which handle them as described in
<xref target="rejoin"/>.  A later rejoin request for the same group and user
supersedes an earlier one; admin clients act on the most recent request.</t>

</section>
</section>
<section anchor="leaf-key-updates"><name>Leaf Key Updates</name>

<t>To maintain post-compromise security ([RFC9420] Section 16.6), Member
Servers SHOULD periodically send <spanx style="verb">MLS_PROPOSAL</spanx> (Update) to the Admin
Servers to rotate their users' leaf keys.  Admin clients SHOULD commit
pending Update proposals automatically whenever they are online, without
user interaction; an Update only achieves post-compromise security once
it has been committed ([RFC9420] Section 16.6).</t>

<t>Groups MUST define an update deadline: the maximum time allowed between
committed Updates of a leaf.  A leaf that has not been updated within
the deadline is stale.  Members with stale leaves SHOULD be removed from
the group per [RFC9420] Section 3.2, and stale admins in particular
SHOULD be removed promptly: an admin whose clients no longer update
cannot commit, and a stale first admin additionally blocks Commit
arbitration until failover (<xref target="failover"/>).</t>

</section>
<section anchor="rejoin"><name>Rejoin After State Loss</name>

<t>A Member Server can lose its MLS state for a group: it may have
processed a Commit that was later discarded during failover conflict
resolution (<xref target="failover"/>) and already deleted the superseded epoch's
secrets per the deletion schedule ([RFC9420] Section 9.2), or its stored
state may be lost or corrupted for any other reason.  Such a server has
drifted from the group: it can no longer process Commits or decrypt
Application Messages, and because MLS messages are bound to the current
GroupContext, it cannot sign a valid Proposal with which to recover.  A
drifted server detects its condition when an <spanx style="verb">MLS_COMMIT</spanx> fails to
process against its local state, for example through a confirmation tag
mismatch, or arrives for an epoch it cannot reach after Commit
retransmission has been exhausted.</t>

<t>Recovery is mediated by an admin client through the normal Commit path:</t>

<t><list style="numbers" type="1">
  <t>The drifted server discards its MLS state for the group and
generates a fresh KeyPackage for each of its users who are members
of the group.  A KeyPackage for a Virtual Client MUST be generated
and coordinated as specified in [ietf-mls-virtual-clients]
Section 5.5.1.</t>
  <t>It sends an <spanx style="verb">MLS_REJOIN</spanx> notification carrying those KeyPackages to
the home server of every admin.  The notification is authenticated
at the OCM layer with HTTP Signatures [RFC9421], the same trust
anchor that authenticates KeyPackage distribution itself, so a
rejoin request is exactly as trustworthy as a freshly fetched
KeyPackage.</t>
  <t>An admin client verifies that each KeyPackage's credential carries
the OCM Address of a leaf currently in the ratchet tree, and that
the notification was signed by the server named in those OCM
Addresses.  A rejoin MUST NOT admit a user without a leaf in the
tree; it can only replace existing members.</t>
  <t>The admin client constructs a single Commit containing, by value, a
Remove proposal for each stale leaf and an Add proposal for the
corresponding fresh KeyPackage.  This rejoin pair preserves the OCM
Address of every affected leaf and grants no new party access, so
admin clients SHOULD commit it automatically, per the policy in
<xref target="admins"/>.</t>
  <t>The Commit is arbitrated and broadcast as usual, and the drifted
server receives one <spanx style="verb">MLS_WELCOME</spanx> per re-added user, restoring clean
state from the Welcome's <spanx style="verb">ratchet_tree</spanx> extension.</t>
</list></t>

<t>A single Commit recovers all of the drifted server's users at once.
Until the rejoin completes, the drifted server can continue to serve
resources whose wrapped FKs it received before the fork, using the Group
Key of the last epoch it processed; wrapped FKs distributed after the
fork become accessible when the re-wrap following the rejoin Commit
(<xref target="fk-rewrap"/>) arrives.</t>

</section>
<section anchor="reinit"><name>Group Reinitialisation</name>

<t>Reinitialisation ([RFC9420] Section 11.2) replaces a group with a new
MLS group with the same membership and the same OCM Address but
different parameters: a new MLS version, cipher suite, or extension set,
and necessarily a fresh MLS <spanx style="verb">group_id</spanx>.  It is the migration path for
cryptographic agility, for example moving a long-lived group to a
stronger cipher suite.</t>

<t>A ReInit proposal is a group parameter change and is handled like other
group-changing proposals: it MUST be explicitly approved by an admin and
MUST be committed by an admin client.  Per [RFC9420] Section 12.2, a
ReInit proposal is committed alone.  The <spanx style="verb">extensions</spanx> field of the
ReInit proposal MUST include an <spanx style="verb">ocm_federated_group</spanx> extension with
<spanx style="verb">group_ocm_address</spanx> unchanged; the admin set is normally carried over
unchanged.</t>

<t>After the ReInit Commit is processed, the old group MUST NOT be used to
send messages ([RFC9420] Section 12.4.2).  In particular, sending
servers MUST NOT send <spanx style="verb">MLS_APPLICATION</spanx> messages in the old group; the
per-epoch re-wrap obligation (<xref target="fk-rewrap"/>) arising from the ReInit
Commit is deferred to the new group.</t>

<t>The admin client that committed the ReInit SHOULD create the new group:
it fetches fresh KeyPackages, valid for the new version and cipher
suite, for every member of the old group, creates the new group with an
initial Commit re-admitting them, and sends each member a Welcome
carrying a PreSharedKeyID of type resumption with usage reinit, as
specified by [RFC9420] Section 11.2.  The Add proposals of this initial
Commit re-admit the old group's members and require no separate admin
approval.  If the committing admin client fails to complete this step in
reasonable time, any other admin client MAY do so instead.  If a Member
Server receives competing reinitialisation Welcomes for the same
<spanx style="verb">group_ocm_address</spanx>, it MUST accept the one whose new group was created
by the admin listed earliest in the old group's admin set and reject the
others.</t>

<t>A Member Server processing a reinitialisation Welcome MUST perform the
verifications of [RFC9420] Section 12.4.3.1 for usage reinit: the last
Commit of the old group contains the ReInit proposal, the new group's
parameters match it, and every member of the old group is a member of
the new group, where members are equivalent if their leaf credentials
carry the same OCM Address.  It MUST additionally verify that the
<spanx style="verb">group_ocm_address</spanx> of the new group equals that of the old group.  On
success it rebinds the OCM Address from the old <spanx style="verb">group_id</spanx> to the new
one; this is the only case in which that binding may change.  Because
the local wrapped FK store is keyed by the group's OCM Address, stored
entries carry over unchanged.</t>

<t>After joining the new group, a sending server MUST re-wrap the FK of
every resource it shares with the group under the new group's Group Key
and redistribute the wrapped FKs to all Member Servers, exactly as for
an epoch change (<xref target="fk-rewrap"/>).  The new group's Group Key differs from
any key of the old group both through the fresh epoch secret and through
the new <spanx style="verb">group_id</spanx> in the Exporter context, so no wrapped FK from the
old group can be unwrapped in the new one.  Until the re-wrapped FKs
arrive, Member Servers retain the old group's last Group Key under the
same retention rule as for an epoch change.  Members SHOULD retain the
resumption PSK of the old group's final epoch until the reinitialisation
has completed ([RFC9420] Section 8.6).</t>

</section>
</section>
<section anchor="encryption-model"><name>Encryption Model</name>

<section anchor="group-key-derivation"><name>Group Key Derivation</name>

<t>After processing any MLS Welcome or Commit, the MLS client MUST apply
the new epoch secret before encrypting any application data, then
derives the current Group Key:</t>

<figure><artwork><![CDATA[
group_key = MLS-Exporter("ocm-group-key", group_id_bytes, AEAD.Nk)
]]></artwork></figure>

<t><spanx style="verb">AEAD.Nk</spanx> is the length in bytes of a key for the AEAD algorithm of the
group's negotiated MLS cipher suite ([RFC9420] Section 9.1).  Deriving
the Group Key at exactly this length makes it a valid key for the wrap
AEAD (<xref target="file-key-wrapping"/>), which is the AEAD algorithm of the group's
cipher suite, for every cipher suite, including those whose AEAD takes a
16-byte key such as AES-128-GCM.</t>

<t>The MLS Exporter ([RFC9420] Section 8.5) produces application-specific
key material from the epoch secret without exposing the epoch secret
itself.  The label <spanx style="verb">"ocm-group-key"</spanx> scopes the output to this
application.  The <spanx style="verb">group_id_bytes</spanx> context, the raw MLS <spanx style="verb">group_id</spanx> of
the group, further binds the output to this specific group.  The Group
Key therefore changes with every epoch transition and cannot be derived
by any party that did not participate in that epoch.</t>

<t>Per [RFC9420] Section 8.5, the Group Key SHOULD be refreshed after each
processed Commit.  Security-sensitive values derived from the epoch
secret MUST be deleted as soon as they are consumed, per [RFC9420]
Section 9.2.</t>

<t>All MLS clients in the group independently derive the same Group Key for
a given epoch.</t>

</section>
<section anchor="resource-id"><name>Resource Id</name>

<t>The <spanx style="verb">resourceId</spanx> used in the AEAD associated data MUST be a stable
identifier for the underlying file, consistent across all groups it is
shared with.  It identifies the resource, not a particular version of
it or a specific share.  This ensures that the FK unwrapped by members
of any group correctly decrypts the same ciphertext.  The <spanx style="verb">providerId</spanx>
values in separate share notifications, for the same resource, MUST
differ, per the <spanx style="verb">providerId</spanx> definition in [OCM], but the <spanx style="verb">resourceId</spanx>
in the AEAD associated data MUST be the same.  This means that the
<spanx style="verb">providerId</spanx> MUST NOT be reused as <spanx style="verb">resourceId</spanx>.  The sending server is
responsible for maintaining this stable <spanx style="verb">resourceId</spanx> and MUST send it
in the <spanx style="verb">encryption</spanx> object of the share payload (<xref target="share-creation"/>).</t>

</section>
<section anchor="file-key-wrapping"><name>File Key Wrapping</name>

<t>Two AEAD algorithms are involved in protecting a resource, and they are
deliberately decoupled.  The content AEAD encrypts the resource itself:
it is chosen by the sending server from the AEAD algorithms defined for
HPKE ([RFC9180] Section 7.3), it is fixed for the lifetime of a
ciphertext and identical across all groups the resource is shared with,
and it is identified explicitly by the <spanx style="verb">cipher</spanx> field of the
<spanx style="verb">encryption</spanx> object (<xref target="share-creation"/>).  The wrap AEAD protects the FK
in transit: it is always the AEAD algorithm of the respective group's
MLS cipher suite, keyed with that group's Group Key, and may therefore
differ between groups that share the same resource.</t>

<t>When sharing an encrypted resource with a group, the sending MLS client
acts on behalf of a user who is a member of that group:</t>

<t><list style="numbers" type="1">
  <t>Chooses the content AEAD and generates a random per-file key (FK)
whose length is the key length of that algorithm.</t>
  <t>Encrypts the resource with FK using the content AEAD.
Implementations supporting native client decryption of large files
SHOULD use a chunked AEAD construction to enable streaming
decryption.</t>
  <t>Derives the current Group Key from the user's local MLS state.</t>
  <t>Wraps FK using the wrap AEAD:  <vspace blankLines='1'/>
    <figure><artwork><![CDATA[
wrapped_file_key = AEAD-Encrypt(
  key       = group_key,
  nonce     = random_nonce,
  plaintext = FK,
  aad       = FKWrapAAD
)
]]></artwork></figure>
  <vspace blankLines='1'/>
where the associated data is the serialisation of the following
structure, in the presentation language of [RFC9420]:  <vspace blankLines='1'/>
    <figure><artwork><![CDATA[
struct {
  opaque group_ocm_address<V>;
  opaque resource_id<V>;
} FKWrapAAD;
]]></artwork></figure>
  <vspace blankLines='1'/>
The <spanx style="verb">group_ocm_address</spanx> field is the UTF-8 encoding of the group's
OCM Address (the same value carried in the <spanx style="verb">shareWith</spanx> field of the
share notification) and <spanx style="verb">resource_id</spanx> is the UTF-8 encoding of the
<spanx style="verb">resourceId</spanx> field of the <spanx style="verb">encryption</spanx> object.  The length-prefixed
encoding makes the pair unambiguous; raw concatenation of the two
strings would allow distinct (address, identifier) pairs to produce
identical associated data.  The MLS <spanx style="verb">group_id</spanx> is NOT used in the
associated data.</t>
  <t>Sends an <spanx style="verb">MLS_APPLICATION</spanx> notification directly to all current
Member Servers, carrying the wrapped FK keyed by <spanx style="verb">(resourceId,
groupId)</spanx>.</t>
</list></t>

</section>
<section anchor="fk-rewrap"><name>FK Re-wrap on Epoch Change</name>

<t>The Group Key changes with every epoch transition, whatever the reason
for the transition: a Commit covering Add, Remove, Update, or
GroupContextExtensions proposals, or an empty Commit, all advance the
epoch.  To maintain the invariant that the current Group Key is always
sufficient to unwrap the current wrapped FK, a sending server MUST,
after processing an <spanx style="verb">MLS_COMMIT</spanx> for a group, or after joining the
successor group of a reinitialisation via its Welcome (<xref target="reinit"/>), for
every resource it shares with that group:</t>

<t><list style="numbers" type="1">
  <t>Re-wrap the resource's current FK under the new Group Key, following
the procedure in <xref target="file-key-wrapping"/>.</t>
  <t>Distribute the new wrapped FK to all current Member Servers, derived
from the new ratchet tree, via <spanx style="verb">MLS_APPLICATION</spanx>.</t>
</list></t>

<t>Note that the FK itself is unchanged by this procedure; only its
wrapping is refreshed.  Whether the FK is also rotated is a separate,
removal-triggered policy decision (<xref target="fk-rotation"/>).</t>

<t>If the Commit added one or more members, the set of Member Servers may
have grown.  The sending server MUST identify Member Servers that are
new to the group and send them the Share Creation Notifications for its
federation shares with the group, as described in <xref target="share-creation"/>, in
addition to the wrapped FKs.  A server that joins the group after a
share was created thereby receives both the share itself and a wrapped
FK it can decrypt, since the <spanx style="verb">MLS_APPLICATION</spanx> is encrypted in an epoch
in which it is a member.</t>

<t>Between processing a Commit and receiving the re-wrapped FK for a
resource, a Member Server holds a wrapped FK produced under the previous
epoch's Group Key.  To remain able to serve access requests in this
window, a Member Server SHOULD retain the previous epoch's Group Key
until it has received a strictly newer wrapped FK (<xref target="key-distribution"/>)
for every locally stored <spanx style="verb">(resourceId, groupId)</spanx> pair of that group, or
until a bounded time has elapsed, whichever comes first, and MUST delete
it at that point.  The security trade-off of this retention window is
discussed in Security Considerations.</t>

<t>The volume of <spanx style="verb">MLS_APPLICATION</spanx> traffic produced by this rule grows with
the number of shared resources and the frequency of epoch transitions;
see the batching item in Open Issues.</t>

</section>
<section anchor="key-distribution"><name>Key Distribution via MLS Application Messages</name>

<t>Wrapped file keys are distributed to Member Servers via MLS Application
Messages, <spanx style="verb">PrivateMessage</spanx> objects carrying application data ([RFC9420]
Section 15).  Wrapped FKs are distributed at share creation and
re-distributed after every epoch transition (<xref target="fk-rewrap"/>).  A sending
server MUST process the <spanx style="verb">MLS_COMMIT</spanx> and derive the new Group Key before
sending an <spanx style="verb">MLS_APPLICATION</spanx> with updated wrapped keys, per [RFC9420]
Section 15.2.</t>

<t>The <spanx style="verb">PrivateMessage</spanx> application data is a JSON object carrying the
current wrapped FK for each <spanx style="verb">(resourceId, groupId)</spanx> pair in a <spanx style="verb">keys</spanx>
array, and MAY also carry a <spanx style="verb">credentials</spanx> array (<xref target="credential-update"/>):</t>

<figure><sourcecode type="json"><![CDATA[
{
  "keys": [
    {
      "resourceId": "3a02538b-aa54-42f2-8853-a38996e211b1",
      "groupId": "research-group@receiver.example.org",
      "wrappedKey": "<base64url nonce || wrapped_file_key || tag>"
    }
  ]
}
]]></sourcecode></figure>

<t>The <spanx style="verb">groupId</spanx> field carries the group's OCM Address, matching the
<spanx style="verb">shareWith</spanx> of the corresponding share notification, and the
<spanx style="verb">resourceId</spanx> field matches the <spanx style="verb">resourceId</spanx> in the <spanx style="verb">encryption</spanx> object
of that notification.</t>

<t>The <spanx style="verb">PrivateMessage</spanx> is encrypted using the current epoch's keys, so
only current group members can decrypt it.  A just-removed member cannot
decrypt the Application Message even if they receive the notification,
as they do not hold the new epoch's key material.</t>

<t>Member Servers store the received wrapped FKs locally, keyed by
<spanx style="verb">(resourceId, groupId)</spanx>, always replacing any previous wrapped FK for
the same pair with the latest one.  "Latest" is defined by the
authenticated <spanx style="verb">(epoch, generation)</spanx> of the enclosing <spanx style="verb">PrivateMessage</spanx>,
compared lexicographically, not by arrival order: a stored wrapped FK
MUST only be replaced by one with a strictly higher <spanx style="verb">(epoch,
generation)</spanx>.  A sending server MUST send all FK updates for a given
group through a single MLS leaf within any given epoch, since generation
counters are maintained per leaf; updates from a later epoch always
supersede updates from an earlier epoch regardless of leaf.  MLS
Application Messages may be delayed or reordered in transit ([RFC9420]
Section 15.3); a Member Server that receives an out-of-order
<spanx style="verb">MLS_APPLICATION</spanx> simply ignores wrapped FKs that are not newer than
those it already holds.  At access time, the Member Server uses its
current Group Key, derived from its current MLS state for the identified
group, to unwrap the FK.</t>

</section>
<section anchor="credential-update"><name>Transport Credential Updates</name>

<t>The per-server transport credential of a share (<xref target="share-creation"/>) may
need to be rotated during the lifetime of the share.  In particular, in
native client deployments the user's device interacts directly with the
sending server and therefore holds its server's credential, so when such
a user is removed from the group, the credential of their server can no
longer be considered private to that server's remaining users.  On
removal of a member whose clients may have held a server's transport
credential, the sending server SHOULD rotate that server's credential
for every share affected.  Rotation MAY also be triggered by policy or
suspected leakage.</t>

<t>A rotated credential is delivered in an <spanx style="verb">MLS_APPLICATION</spanx> message sent
only to the affected Member Server, carrying a <spanx style="verb">credentials</spanx> array in
the application data:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "credentials": [
    {
      "providerId": "7c084226-d9a1-11e6-bf26-cec0c932ce01",
      "groupId": "research-group@receiver.example.org",
      "recipient": "othercloud.example.org",
      "sharedSecret": "<new transport credential>"
    }
  ]
}
]]></sourcecode></figure>

<t>Each entry identifies the share by its <spanx style="verb">providerId</spanx>, the group by its
OCM Address in <spanx style="verb">groupId</spanx>, and the intended Member Server by its FQDN in
<spanx style="verb">recipient</spanx>.  A Member Server MUST ignore entries whose <spanx style="verb">recipient</spanx> does
not name itself.  Upon accepting an entry, the Member Server replaces
the stored transport credential for that share; replacement follows the
same <spanx style="verb">(epoch, generation)</spanx> supersede rule as wrapped FKs
(<xref target="key-distribution"/>).  The sending server invalidates the old
credential once the rotation has been delivered.</t>

<t>Encrypting the credential update in the current epoch guarantees that
the removed member cannot read it, independent of transport protection:
they do not hold the new epoch's key material.  Confidentiality with
respect to other Member Servers, by contrast, rests on targeted
delivery: the <spanx style="verb">PrivateMessage</spanx> is decryptable by any group member that
obtains it, so delivering it to the affected server only is a routing
measure, not a cryptographic one (see Security Considerations).</t>

<t>A <spanx style="verb">keys</spanx> array and a <spanx style="verb">credentials</spanx> array MAY appear in the same
application data object when both are destined for the same single
Member Server.</t>

</section>
<section anchor="resource-access"><name>Resource Access</name>

<t>To access a resource:</t>

<t><list style="numbers" type="1">
  <t>The resource is fetched from the sending server using the standard
OCM resource access procedure ([OCM]), with the protocol details and
per-server credential from the <spanx style="verb">protocol</spanx> object of the share
notification.  For an encrypted resource, what is fetched is ciphertext.</t>
  <t>The MLS client identifies the relevant group from the <spanx style="verb">shareWith</spanx>
field of the share notification and looks up the locally stored
<spanx style="verb">wrapped_file_key</spanx> for the <spanx style="verb">(resourceId, groupId)</spanx> pair.</t>
  <t>The MLS client derives the current Group Key from its local MLS
state for that group and unwraps FK using the wrap AEAD of the
group's cipher suite.</t>
  <t>The MLS client decrypts the resource using FK and the content AEAD
named in the <spanx style="verb">cipher</spanx> field of the <spanx style="verb">encryption</spanx> object.</t>
</list></t>

<t>In web-client deployments, decryption happens server-side and the
plaintext is served to the user through whatever access protocol is in
use (WebDAV [RFC4918], SFTP, webapp, etc.).  In native client
deployments, decryption happens on the user's device and the client
interacts directly with the sending server, which serves only
ciphertext.</t>

</section>
<section anchor="resource-modification-by-member-servers"><name>Resource Modification by Member Servers</name>

<t>A common operation is for a user on a Member Server to open a shared
encrypted resource, modify it, and save it back.  The cryptographic flow
is as follows:</t>

<t><list style="numbers" type="1">
  <t>The Member Server fetches the encrypted resource from the sending
server using the standard OCM resource access procedure, with the
credential from the share's <spanx style="verb">protocol</spanx> object.</t>
  <t>The Member Server identifies the relevant group from the <spanx style="verb">shareWith</spanx>
field of the share notification, looks up the locally stored
<spanx style="verb">wrapped_file_key</spanx> for the <spanx style="verb">(resourceId, groupId)</spanx> pair, derives the
current Group Key from its local MLS state for that group, and unwraps
FK.</t>
  <t>The Member Server decrypts the resource using FK and presents the
plaintext to the user.</t>
  <t>The user modifies the resource.</t>
  <t>The Member Server re-encrypts the modified resource using the same
FK and the same content AEAD, but a fresh random nonce.  The nonce
MUST NOT be reused with the same key, as required by AEAD security.</t>
  <t>The Member Server uploads the re-encrypted resource to the sending
server.  This requires the share to grant <spanx style="verb">write</spanx> permission in its
<spanx style="verb">protocol</spanx> object.</t>
</list></t>

<t>The FK is reused across modifications of the same resource because it is
bound to the group's OCM Address and <spanx style="verb">resourceId</spanx> in the AEAD associated
data, making it specific to that resource.  No new <spanx style="verb">MLS_APPLICATION</spanx>
message is needed, as the wrapped FK in all Member Servers' local stores
remains valid for the updated ciphertext.</t>

<t>FK rotation for a resource is only necessary on member removal in
re-encryption mode (<xref target="fk-rotation"/>).</t>

</section>
<section anchor="sharing-a-resource-with-multiple-groups"><name>Sharing a Resource with Multiple Groups</name>

<t>A sending server MAY share the same encrypted resource with more than
one group.  The file is encrypted once, with a single FK and a single
content AEAD; the <spanx style="verb">cipher</spanx> field in every group's share notification
names that same algorithm.  Each group receives its own wrapped FK,
produced with that group's wrap AEAD, Group Key, and OCM Address:</t>

<figure><artwork><![CDATA[
wrapped_file_key_group1 = AEAD-Encrypt(group_key_1, nonce_1, FK,
                  FKWrapAAD(group_ocm_address_1, resource_id))
wrapped_file_key_group2 = AEAD-Encrypt(group_key_2, nonce_2, FK,
                  FKWrapAAD(group_ocm_address_2, resource_id))
]]></artwork></figure>

<t>A separate Share Creation Notification is sent to each Member Server of
each group.  A separate <spanx style="verb">MLS_APPLICATION</spanx> carrying the respective
wrapped FK is broadcast to each group's Member Servers.  Members of each
group can only unwrap the FK using their own group's Group Key and
cannot access the other group's wrapped FK or Group Key.</t>

<t>The sending server MUST maintain a mapping from each resource to all
groups it has been shared with.  This mapping is required to correctly
handle member removal in re-encryption mode, as described in the
following section.</t>

</section>
<section anchor="fk-rotation"><name>FK Rotation (RECOMMENDED)</name>

<t>FK rotation is distinct from the re-wrap performed on every epoch change
(<xref target="fk-rewrap"/>): rotation generates a new FK and re-encrypts the
resource, whereas a re-wrap only refreshes the wrapping of the existing
FK.  A sending server SHOULD rotate the FK for a resource when a member
is removed from any group that has access to it.  FK rotation may also
be triggered by other factors, such as periodic key rotation policy,
regulatory requirements, or a suspected compromise of key material.
Applications SHOULD define a policy for the frequency of FK rotation
independent of membership changes.</t>

<t>When rotating the FK for a resource, the sending server:</t>

<t><list style="numbers" type="1">
  <t>Generates a new FK for the resource.</t>
  <t>Re-encrypts the resource with the new FK.</t>
  <t>For every group that has access to the resource, wraps the new FK
using that group's current Group Key:  <vspace blankLines='1'/>
    <figure><artwork><![CDATA[
new_wrapped_file_key_groupN = AEAD-Encrypt(group_key_N, nonce_N,
      new_FK, FKWrapAAD(group_ocm_address_N, resource_id))
]]></artwork></figure>
  </t>
  <t>Broadcasts an <spanx style="verb">MLS_APPLICATION</spanx> notification carrying the respective
new wrapped FK directly to each group's Member Servers.</t>
</list></t>

<t>Distributing the new wrapped FK to all groups that share the resource is
necessary because all groups share the same ciphertext.  If only one
group received the new wrapped FK, members of other groups would hold a
wrapped FK that no longer decrypts the current ciphertext.</t>

<t>A member removed from one group but still a member of another group that
shares the same resource retains the ability to decrypt that resource
through the second group.  This is correct and intended behaviour:
access is determined by current group membership, and the user remains a
member of the second group.  The default safe rule is to rotate the FK
and redistribute to all groups on any removal event.  A sending server
MAY instead compare the unique set of users with access before and after
an epoch change, and skip FK rotation if that set is unchanged, for
example because the removed user remains a member of every other group
that has access to the same resource.  Whether this optimisation is
worth the added complexity depends on the nature of the resource and the
frequency of membership changes.</t>

<t>Member addition does not require FK rotation.  The new member receives
the current Group Key via their Welcome, and the re-wrap triggered by
the Add Commit (<xref target="fk-rewrap"/>) delivers a wrapped FK, encrypted in an
epoch in which the new member is a member, that the new member can
unwrap with that Group Key.</t>

</section>
<section anchor="member-removal-key-reuse-mode-optional"><name>Member Removal: Key-reuse Mode (OPTIONAL)</name>

<t>Where re-encryption is impractical, for example due to frequent changes
of very large files, and where all participating servers belong to a
formal federation with explicit governance and mutual trust, a sending
server MAY instead keep the existing FK.  In that case no action beyond
the standard re-wrap on epoch change (<xref target="fk-rewrap"/>) is required: the
Remove Commit advances the epoch, and the sending server re-wraps the
existing FK under the new Group Key and distributes it to the remaining
Member Servers of the affected group.</t>

<t>When a resource is shared with multiple groups, only the epoch of the
group from which the member was removed has advanced, so only that
group's FK wrapping is refreshed.  The wrapped FKs for other groups are
unchanged and remain valid for their respective members.</t>

<t>In this mode, access-follows-membership relies on trust rather than
cryptography: the FK itself is unchanged, so a removed member's server
and, in native client deployments, the removed user's devices, may still
hold the superseded Group Key together with the old wrapped FK, or the
unwrapped FK itself, any of which decrypts the unchanged ciphertext.
Key-reuse mode therefore relies on trusting servers to discard key
material they are no longer entitled to after a Remove Commit.  A
removed member who is also a member of another group that has access to
the same resource will still be able to decrypt via that group's wrapped
FK, which is the expected behaviour - they remain a member of that
group.  This assumption is appropriate within a formal federation but
SHOULD NOT be made in open or ad-hoc sharing contexts.</t>

<t>The sending server's choice of mode is its own policy decision and is
not signalled in the protocol.</t>

</section>
<section anchor="member-removal-ocm-notifications"><name>Member Removal: OCM Notifications</name>

<t>Member removal requires no OCM-level notification by itself.  Because
federation shares are addressed to the group (<xref target="share-creation"/>), each
Member Server observes the Remove Commit and re-evaluates which of its
local users the share resolves to; a removed user loses access without
any action by the sending server.  If the removed member's clients may
have held their server's transport credential, the sending server SHOULD
additionally rotate that credential (<xref target="credential-update"/>).</t>

<t>When the last member homed on a given server is removed from the group,
that server no longer has any user with access.  A well-behaved sending
server SHOULD then reconcile the OCM state of the share, revoke that
server's per-server transport credential (<xref target="share-creation"/>), and send
a <spanx style="verb">SHARE_UNSHARED</spanx> notification to the <spanx style="verb">/notifications</spanx> endpoint of that
server.</t>

</section>
</section>
<section anchor="share-creation"><name>Share Creation</name>

<t>The sending server sends one OCM Share Creation Notification directly to
each current Member Server, identified through the OCM Addresses in the
ratchet tree's leaf credentials.  This is standard OCM server-to-server
communication, with <spanx style="verb">shareWith</spanx> set to the group's OCM Address and
<spanx style="verb">shareType</spanx> set to <spanx style="verb">"federation"</spanx>.  The share is addressed to the group
as the Receiving Party; no per-user notifications are sent.</t>

<t>A federation share is a standard OCM share: every field that is REQUIRED
by [OCM], including the <spanx style="verb">protocol</spanx> object, is REQUIRED here too, and
resource access follows the standard OCM resource access procedure
driven by the <spanx style="verb">protocol</spanx> object.  For encrypted resources the protocol
endpoint serves ciphertext; the plaintext is obtained by unwrapping the
FK as described in the Encryption Model.</t>

<t>Each Member Server SHOULD be given its own <spanx style="verb">sharedSecret</spanx> (or equivalent
protocol credential) in its copy of the notification.  The credential is
per server, not per user: all users on a Member Server share it,
mirroring how the server holds MLS state on behalf of its users.
Distinct per-server credentials allow the sending server to revoke a
single server's transport access, for example when the last group member
on that server is removed, without affecting other Member Servers.
Share Creation Notifications sent to servers that join the group later
(<xref target="fk-rewrap"/>) carry credentials minted at that time, and a server's
credential can be rotated during the share's lifetime
(<xref target="credential-update"/>).</t>

<t>Share Permissions apply uniformly to the whole group: every member of
the group receives the same permissions on the resource.  A sending
server that needs different permissions for different parties should use
separate groups or individual shares.  Receiving Server criteria that
affect the share payload, such as <spanx style="verb">must-exchange-token</spanx>, are evaluated
per Member Server against that server's discovery document, exactly as
in base OCM.</t>

<t>The receiving server resolves <spanx style="verb">shareWith</spanx> against its local MLS state:
it identifies the group whose <spanx style="verb">group_ocm_address</spanx> (<xref target="admin-set"/>)
matches the <spanx style="verb">shareWith</spanx> value and delivers the share to every local user
whose leaf credential appears in that group's ratchet tree.  On every
subsequent <spanx style="verb">MLS_COMMIT</spanx> the receiving server MUST re-evaluate this
resolution, so that local users added to the group gain access to
existing federation shares, and removed users lose it, without any
further OCM notifications.</t>

<t>Addressing the share to the group also allows the receiving server to
distinguish between shares of the same resource arriving via different
groups - a user may be a member of two groups that both have access to
the same resource from the same sending server - and to correctly key
its local wrapped FK store by <spanx style="verb">(resourceId, groupId)</spanx> rather than
<spanx style="verb">resourceId</spanx> alone, where <spanx style="verb">groupId</spanx> is the group OCM Address carried in
<spanx style="verb">shareWith</spanx>, ensuring that FK updates delivered via <spanx style="verb">MLS_APPLICATION</spanx>
are applied to the correct entry.</t>

<t>Because notifications can be delayed or reordered in transit, a
federation share MAY arrive before the receiving server has processed
the Welcome or Commit that made it a Member Server of the group.  A
receiving server that does not recognise the <spanx style="verb">shareWith</spanx> value as a
known group SHOULD queue the share, or reject it in a way that causes
the sender to retry, rather than fail it permanently.  Since sending
servers only contact servers present in the ratchet tree, this condition
is transient.</t>

<t>When an <spanx style="verb">MLS_COMMIT</spanx> adds one or more members to the group, the sending
server MUST send each Member Server that is new to the group a Share
Creation Notification for every federation share it has with that group,
encrypted or not.  For encrypted resources this accompanies the
re-wrapped FK (<xref target="fk-rewrap"/>).  A server that joins the group after a
share was created thereby learns of the shares its users now have access
to without any further action by its users.</t>

<t>Each notification MAY include the optional <spanx style="verb">encryption</spanx> field:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "shareWith": "research-group@receiver.example.org",
  "resourceType": "file",
  "shareType": "federation",
  "sender": "alice@cloud.example.org",
  "owner": "alice@cloud.example.org",
  "providerId": "7c084226-d9a1-11e6-bf26-cec0c932ce01",
  "name": "experiment-data.tar",
  "protocol": {
    "name": "multi",
    "webdav": {
      "uri": "experiment-data.tar",
      "sharedSecret": "<per-Member-Server secret>",
      "permissions": ["read", "write"]
    }
  },
  "encryption": {
    "resourceId": "3a02538b-aa54-42f2-8853-a38996e211b1",
    "scheme": "ocm-mls",
    "ocm-mls": {
      "cipher": "AES-256-GCM"
    }
  }
}
]]></sourcecode></figure>

<t>The <spanx style="verb">encryption</spanx> field is OPTIONAL as per [OCM] Share Creation
Notification specification.  If absent, the resource is unencrypted.
If present, and the symmetric encryption available via OCM-MLS is to
be used, it MUST carry the encryption-related parameters according to
the [OCM] specification, where:
- <spanx style="verb">resourceId</spanx> is the stable resource identifier described in
<xref target="resource-id"/>
- <spanx style="verb">scheme</spanx> is to be set to <spanx style="verb">"ocm-mls"</spanx>
- <spanx style="verb">cipher</spanx> names the content AEAD that the resource is encrypted with
(<xref target="file-key-wrapping"/>), one of the AEAD algorithms defined for HPKE
([RFC9180] Section 7.3): <spanx style="verb">"AES-128-GCM"</spanx>, <spanx style="verb">"AES-256-GCM"</spanx>, or
<spanx style="verb">"CHACHA20-POLY1305"</spanx>.  The field signals that the FK is distributed via
the <spanx style="verb">MLS_APPLICATION</spanx> mechanism keyed by <spanx style="verb">(resourceId, groupId)</spanx>.  No
epoch information is carried in the share notification.  Member Servers
always hold the current wrapped FK for each <spanx style="verb">(resourceId, groupId)</spanx> pair
and use their current Group Key to unwrap it at access time.</t>

<t>The Group Owner Server is not involved in the delivery of OCM Share
notifications.  All other OCM notifications relating to a share, such as
share updates and share deletions, are likewise sent directly from the
sending server to each Member Server, referencing the share by its
<spanx style="verb">providerId</spanx> as in base OCM.</t>

</section>
<section anchor="trust-and-authentication"><name>Trust and Authentication</name>

<t>The Authentication Service role ([RFC9420] Section 3) is fulfilled by
each user's home OCM server: the server that publishes a user's
KeyPackages attests the binding between the user's OCM Address and their
signature key.  Because the basic credential itself carries no
verifiable binding, the attestation lies in the delivery channel.</t>

<section anchor="validation-procedure"><name>Validation procedure</name>

<t>A KeyPackage is considered validated with the AS when all of the
following hold:</t>

<t><list style="symbols">
  <t>it was fetched from the <spanx style="verb">&lt;endPoint&gt;/mls-key-packages</spanx> endpoint of the
server named in the credential's OCM Address, over TLS, with the
response signed using HTTP Signatures [RFC9421] verifying against that
server's JWKS [RFC7517];</t>
  <t>the OCM Address in the credential is identical to the <spanx style="verb">userId</spanx> the
KeyPackage was requested for, which is the OCM Address of the user the
requester intends to add; in particular, its host part names the server
the KeyPackage was fetched from; and</t>
  <t>the KeyPackage signature verifies with the <spanx style="verb">signature_key</spanx> of its
LeafNode, proving possession of the private key ([RFC9420] Section
10.1).</t>
</list></t>

<t>Requests to the KeyPackage endpoint are signed at the server level
(<xref target="security-considerations"/>), so in native client deployments the
fetch is performed by the admin's home server on the admin client's
behalf.  The home server SHOULD relay the response with its HTTP
Message Signature intact, allowing the native client to verify the
channel binding end-to-end against the target server's published JWKS;
a native client that cannot do so delegates the channel verification to
its home server and verifies the KeyPackage signature itself.</t>

<t>[RFC9420] Section 5.3.1 requires a credential to be validated whenever
it is introduced into the group.  This protocol distributes that duty to
the party that introduces the credential:</t>

<t><list style="symbols">
  <t>Add: the admin client committing an Add MUST have validated the
KeyPackage as described above.  Other members accept the new leaf on the
strength of the admin-signed Commit; they do not contact the new
member's home server.</t>
  <t>Update proposals, and Commits whose UpdatePath carries a new
credential: the successor credential MUST present the same OCM Address
as the credential it replaces, and members MUST reject the proposal or
Commit otherwise.  This is the successor-credential policy anticipated
by [RFC9420] Section 5.3.1.  Continuity of the signature key is anchored
in MLS itself: the message introducing the new leaf is signed with the
member's current key, so only the holder of the previous key can rotate
to a new one.</t>
  <t>Joining via Welcome: the joiner MUST verify the GroupInfo signature
and the integrity of the ratchet tree as required by [RFC9420] Section
12.4.3.1, and MUST verify that every leaf credential is a basic
credential carrying a well-formed OCM Address.  The joiner accepts the
bindings of those credentials transitively, on the basis that each was
validated by an admin client when it was introduced.  It MAY
additionally re-validate any leaf against the <spanx style="verb">/mls-key-packages</spanx>
endpoint of its home server, but such re-validation can fail benignly,
since published KeyPackages rotate independently of leaves already in
groups.</t>
</list></t>

<t>In this transitive model, each home server is trusted to attest only its
own users, and each admin client is trusted to have performed the
attestation check at introduction time.  The protocol does not
independently verify assertions made by a user's home server, because
that server is the Authentication Service for its users.  Compromise of
that trusted server is outside the threat model.</t>

<t>Users who require protection of their key material from their own server
should choose a native client implementation where cryptographic
operations occur on the user's device.</t>

</section>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>

<section anchor="threat-model"><name>Threat Model</name>

<t>The threat model follows the Internet threat model described in
[RFC3552] and inherits the trust assumptions of [OCM].  It assumes that
the OCM Servers participating in a group, including Member Servers,
Admin Servers, and the Group Owner Server, have not been compromised and
correctly enforce the protocol and their local authorization policies.
Their administrative interfaces, host operating systems, private keys,
credentials, and underlying storage are part of the trusted endpoints.
Compromise of an OCM Server or its trusted infrastructure is outside the
scope of this specification.</t>

<t>An attacker is assumed to have extensive control of the communication
channel and may observe, block, replay, insert, modify, delay, or
reorder traffic.  TLS, HTTP Message Signatures, and MLS provide the
protections described in this specification against such an attacker.</t>

<t>An attacker may control a remote user, a current or former group member,
or an OCM Server of its own.  It may send malformed messages, retain key
material it legitimately obtained while it was a member, disclose
plaintext or keys available to it, and attempt to cause inconsistent
group state or resource exhaustion.  An attacker-controlled server can
make assertions under its own identity, but must not thereby gain
authority for users outside its administrative domain or admission to a
group without the required authorization.</t>

<t>The distributed Delivery Service is not trusted to provide availability
or consistent delivery.  It can delay, drop, reorder, selectively
deliver, or partition messages and can observe metadata deliberately
exposed by this protocol.  It cannot derive group secrets or forge valid
MLS messages.  The Group Owner Server is trusted to arbitrate Commits,
but its unavailability can stall epoch transitions until failover
completes.</t>

<t>In web-client deployments, the trusted OCM Server acts as the MLS client
and holds MLS state, Group Keys, FKs, and plaintext on behalf of its
users.  Native-client deployments move that cryptographic endpoint to
the user's device.  Exposure of member key material and subsequent
recovery are considered according to the forward-secrecy and
post-compromise-security properties of [RFC9420]; full compromise of an
OCM Server remains outside scope.</t>

<t>Every current group member is an authorized recipient of the group's
cryptographic material.  MLS cannot prevent a member from retaining or
disclosing plaintext, Group Keys, or FKs that it legitimately receives.
A member with write access and the applicable FK can also create a
cryptographically valid arbitrary payload for a shared Resource.  MLS
authenticates the member performing a protocol operation; it does not
establish that the member or supplied content is benign.</t>

<t>This protocol deliberately accepts several deployment-dependent
trade-offs described below.  Encryption is optional.  Key-reuse mode
trades cryptographic revocation for operational efficiency and trust in
former Member Servers.  Temporary retention of previous or forked epoch
state weakens forward secrecy for a bounded period.  Public handshake
messages and distribution of the ratchet tree expose group membership
and membership changes to participating servers.  The protocol does not
provide protection from complete or selective denial of service.</t>

<t><strong>Virtual Clients.</strong> All Emulator Clients of a Virtual Client hold the
secret state needed to act as that Virtual Client.  Compromise of one
device therefore compromises the Virtual Client, and the devices must
fully trust one another.  Implementations MUST follow the onboarding,
removal, state-transfer, key-deletion, nonce-protection, and ratchet
coordination requirements and security considerations of
[ietf-mls-virtual-clients].</t>

<t><strong>FK rotation vs key-reuse.</strong> FK rotation provides cryptographic access
revocation on member removal, independent of trust assumptions, and
SHOULD also be performed periodically or when key compromise is
suspected.  In key-reuse mode the FK is unchanged and the ciphertext is
not re-encrypted, so revocation is not cryptographic: it relies on
trusting servers to discard all key material they are no longer entitled
to after a Remove Commit.  This includes superseded Group Keys, old
wrapped FKs, and any cached unwrapped FKs.  Key-reuse mode SHOULD only
be used within formal federations with governance agreements that
enforce this behaviour.</t>

<t><strong>Two access-control layers.</strong> For an encrypted federation share, access
is controlled at two independent layers: the per-server transport
credential in the <spanx style="verb">protocol</spanx> object gates who can fetch the ciphertext,
and the Group Key gates who can unwrap the FK and decrypt it.
Confidentiality rests on the cryptographic layer alone; the transport
credential provides defence in depth and is shared by all users on a
Member Server.  The two layers can diverge: a server whose last group
member was just removed may still hold a valid transport credential
until the sending server revokes it, which is why revocation SHOULD
accompany the <spanx style="verb">SHARE_UNSHARED</spanx> notification.  For unencrypted federation
shares the transport credential is the only access control, exactly as
in base OCM, and access-follows-membership then depends on the receiving
server re-evaluating share resolution on every Commit
(<xref target="share-creation"/>) and on the sending server revoking the credentials
of departed servers promptly.</t>

<t><strong>Credential rotation.</strong> Rotated transport credentials are delivered in
group-encrypted <spanx style="verb">MLS_APPLICATION</spanx> messages sent only to the affected
server (<xref target="credential-update"/>).  A removed member is excluded
cryptographically: it does not hold the new epoch's key material.  Other
Member Servers are excluded only by targeted delivery; a credential
message that leaks to another member server is readable by it.  Since
every Member Server already holds transport access to the same
ciphertext under its own credential, the impact of such a leak is
limited to transport-layer attribution.</t>

<t><strong>Key distribution via Application Messages.</strong> Wrapped FKs are
distributed in MLS <spanx style="verb">PrivateMessage</spanx> objects encrypted in the current
epoch.  A removed member cannot decrypt these messages as they do not
hold the new epoch's key material.  Because sending servers re-wrap and
redistribute FKs after every epoch transition (<xref target="fk-rewrap"/>), and
Member Servers always replace their locally stored wrapped FK with the
latest received, the current Group Key is always sufficient for
unwrapping once the re-wrapped FKs have arrived.</t>

<t><strong>Group Key retention window.</strong> Between processing a Commit and
receiving the re-wrapped FKs for the new epoch (<xref target="fk-rewrap"/>), a Member
Server may retain the previous epoch's Group Key in order to keep
serving access requests.  This retention extends the lifetime of the
previous epoch's Group Key and therefore weakens forward secrecy for the
duration of the window.  The window is bounded by the arrival of the
re-wrapped FKs, and Member Servers MUST delete the previous Group Key as
soon as it is no longer needed, or after a bounded time, whichever comes
first.</t>

<t><strong>Commit ordering.</strong> The Group Owner Server is the sole arbiter of
Commits, eliminating conflicting Commits for the same epoch during
normal operation.  An unavailable Group Owner Server can stall epoch
transitions, but the Delivery Service and network attackers cannot cause
the group to accept a Commit constructed by a non-admin client, because
every Member Server independently verifies the committer against the
admin set before processing a Commit (<xref target="admins"/>).  The role passes
automatically to the next admin's server when the first admin leaves the
group (<xref target="admin-set"/>), and an unavailable arbiter is eventually replaced
through failover (<xref target="failover"/>), during which conflicting Commits can
briefly exist and are resolved deterministically.</t>

<t><strong>Forked-state retention.</strong> During a detected failover window, Member
Servers retain the previous epoch's group state so that they can revert
to the winning Commit (<xref target="failover"/>).  Retaining forked state weakens
forward secrecy for its duration; [RFC9420] Section 14 requires such
state to be deleted promptly, so the retention is bounded in time and
limited to servers that have observed the failover trigger.</t>

<t><strong>Rejoin.</strong> The rejoin procedure (<xref target="rejoin"/>) lets a home server replace
its own users' leaves with fresh KeyPackages on the strength of its HTTP
Signature alone, without per-request admin approval.  The procedure
relies on the home server's existing role as the Authentication Service
for its own users and therefore introduces no additional trust
assumption.  Because admin clients verify that a rejoin only replaces
leaves whose OCM Addresses name the requesting server and that are
already present in the ratchet tree, a rejoin cannot admit a new party.</t>

<t><strong>Admin liveness and removal latency.</strong> A Remove proposal takes
cryptographic effect only when an admin client commits it.  Removing
another member additionally requires explicit admin approval, so the
revocation latency for a membership change is bounded by admin
availability.  Groups SHOULD appoint multiple admins, on multiple Member
Servers, to keep this window small and to avoid stalling group
operations when a single admin is offline.  The same bound applies to
the post-compromise security provided by Update proposals, which only
take effect once committed.</t>

<t><strong>Application message ordering.</strong> Per [RFC9420] Section 15.2, sending
servers MUST apply a new epoch secret before encrypting any application
data.  <spanx style="verb">MLS_APPLICATION</spanx> messages carrying re-wrapped keys MUST be sent
only after the sending server has processed the corresponding
<spanx style="verb">MLS_COMMIT</spanx>.</t>

<t><strong>Ordering and the DS.</strong> All ordering in this protocol derives from
MLS-authenticated metadata: Commits are ordered by the epoch they
advance, and FK updates by the <spanx style="verb">(epoch, generation)</spanx> of the enclosing
<spanx style="verb">PrivateMessage</spanx>.  No unauthenticated transport counter is relied upon.
Servers in the DS role can still delay, drop, or selectively withhold
messages, but cannot reorder them undetectably or forge them, consistent
with the MLS threat model ([RFC9420] Section 16.9).</t>

<t><strong>Reinitialisation continuity.</strong> A reinitialisation Welcome is accepted
only with a resumption PSK from the old group's final epoch and after
verification of the old group's ReInit Commit and of membership
preservation (<xref target="reinit"/>).  A party that was not a member of the old
group's final epoch cannot produce that PSK, so the binding between a
group's OCM Address and its MLS group state cannot be hijacked through a
forged reinitialisation.</t>

<t><strong>Handshake message confidentiality.</strong> Proposals and Commits are sent as
PublicMessage, so group operations are visible to the servers that
handle them.  The MLS architecture [RFC9750] recommends encrypting
handshake messages to hide membership changes and signatures from the
Delivery Service; this protocol deliberately departs from that
recommendation because the servers performing the DS role must know the
group's membership anyway: sending servers derive notification
recipients from the ratchet tree, and receiving servers resolve
federation shares to their local users.  No information is exposed to
those servers beyond what their OCM duties already require, and
transport protection (TLS and HTTP Signatures [RFC9421]) prevents
exposure to outside observers.  Application Messages, which carry key
material, are always encrypted as PrivateMessage.</t>

<t><strong>Group membership and admin enumeration.</strong> The ratchet tree contains
the OCM Address of every group member, and the GroupContext contains the
group's admin set.  This information forms part of the MLS group state
and its changes are conveyed in public handshake messages.  Every group
member and every Member Server can therefore enumerate all members and
admins of the group and observe membership and admin-set changes over
time.  This is an accepted privacy trade-off inherent to this design:
servers need the membership information to route shares and
notifications, resolve federation shares to local users, and enforce
admin policy.  Federated groups do not provide anonymous membership or
hidden administrator roles.  The information is not exposed by the
protocol to servers outside the group, although an authorized member or
Member Server can disclose it, and transport protection prevents
exposure to outside observers in transit.</t>

<t><strong>Admin set integrity.</strong> The admin set and the group's OCM Address are
carried in the GroupContext (<xref target="admin-set"/>), so they are covered by the
MLS confirmation tag and agreed upon by all members of every epoch.  A
malicious server cannot unilaterally appoint admins or seize the Group
Owner Server role; changing the admin set requires a Commit constructed
by an existing admin client.</t>

<t><strong>Post-compromise security.</strong> Member Servers SHOULD periodically rotate
their users' leaf keys via Update proposals to maintain post-compromise
security ([RFC9420] Section 16.6).  Members that do not update SHOULD
eventually be removed from the group.</t>

<t><strong>Key material deletion.</strong> Security-sensitive values MUST be deleted as
soon as they are consumed, per [RFC9420] Section 9.2.  In particular,
the exporter_secret used to derive the Group Key must not be retained
after the Group Key has been derived.</t>

<t><strong>KeyPackage reuse.</strong> KeyPackages MUST be one-time use, except for a
designated last resort KeyPackage used when a user's single-use
KeyPackages are exhausted ([RFC9420] Section 16.8).  Servers MUST remove
a KeyPackage that has been consumed, and SHOULD rate-limit KeyPackage
requests to make exhaustion attacks impractical.</t>

<t><strong>User enumeration.</strong> A server MUST only reply to HTTPS GET requests
signed using HTTP Message Signatures [RFC9421] and SHOULD implement rate
limiting and other access control methods on the <spanx style="verb">/mls-key-packages</spanx>
endpoint to avoid user enumeration.</t>

</section>
<section anchor="underlying-security-specifications"><name>Underlying Security Specifications</name>

<t>This specification relies on the base Open Cloud Mesh protocol [OCM],
the Messaging Layer Security protocol [RFC9420], HTTP Message Signatures
[RFC9421], and JSON Web Keys and JWK Sets [RFC7517].  All security
considerations in those specifications apply to implementations of this
protocol.  The security and privacy considerations of the MLS
architecture [RFC9750] also apply.</t>

<t>Implementations using Virtual Clients additionally need to follow all
security considerations of [ietf-mls-virtual-clients], as required
above.  Where this specification uses AEAD algorithms defined for HPKE,
the applicable algorithm and nonce-management considerations of
[RFC9180] apply, although this specification does not otherwise use the
HPKE construction.</t>

</section>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<t>The MLS Exporter label <spanx style="verb">"ocm-group-key"</spanx> used in the Group Key
Derivation section is to be registered in the "MLS Exporter Labels"
registry defined in [RFC9420] Section 17.8, to avoid collisions with
other applications using the MLS Exporter:</t>

<t><list style="symbols">
  <t>Label: "ocm-group-key"</t>
  <t>Recommended: N</t>
  <t>Reference: This document</t>
</list></t>

<t>The GroupContext extension <spanx style="verb">ocm_federated_group</spanx> defined in
<xref target="admin-set"/> is to be registered in the "MLS Extension Types" registry
defined in [RFC9420] Section 17.3:</t>

<t><list style="symbols">
  <t>Value: TBD</t>
  <t>Name: ocm_federated_group</t>
  <t>Message(s): GC</t>
  <t>Recommended: N</t>
  <t>Reference: This document</t>
</list></t>

<t>The following notification types are to be registered in the "OCM
Notification Types" registry defined in [OCM], within the "Open Cloud
Mesh (OCM) Parameters" group:</t>

<figure><artwork><![CDATA[
   +===================+===========+===============+
   | Notification Type | Scope     | Reference     |
   +===================+===========+===============+
   | MLS_WELCOME       | Recipient | This document |
   | MLS_PROPOSAL      | Recipient | This document |
   | MLS_COMMIT        | Recipient | This document |
   | MLS_APPLICATION   | Recipient | This document |
   | MLS_REJOIN        | Recipient | This document |
   +===================+===========+===============+
]]></artwork></figure>

<t>The following entry is to be registered in the "OCM Share Types"
registry defined in [OCM], within the "Open Cloud Mesh (OCM)
Parameters" group.  This document is the registering specification for
the "federation" share type:</t>

<figure><artwork><![CDATA[
   +============+===============+
   | Share Type | Reference     |
   +============+===============+
   | federation | This document |
   +============+===============+
]]></artwork></figure>

<t>The following entries are to be registered in the "OCM Share Payloads"
registry defined in [OCM], within the "Open Cloud Mesh (OCM)
Parameters" group.  They extend the existing "webdav", "webapp", and
"ssh" protocols to the "federation" share type; the wire format of the
share payload for these combinations is completely specified by this
document together with [OCM] (see <xref target="share-creation"/>).  These
registrations do not modify the protocols' own registrations:</t>

<figure><artwork><![CDATA[
   +===============+============+=====================+===============+
   | Resource Type | Share Type | Protocols           | Reference     |
   +===============+============+=====================+===============+
   | file          | federation | webdav, webapp, ssh | This document |
   | folder        | federation | webdav, webapp, ssh | This document |
   +===============+============+=====================+===============+
]]></artwork></figure>

<t>The following entries are to be registered in the "OCM Encryption
Schemes" registry defined in [OCM], within the "Open Cloud Mesh (OCM)
Parameters" group:</t>

<figure><artwork><![CDATA[
   +=========+============+===============+
   | Scheme  | Share Type | Reference     |
   +=========+============+===============+
   | ocm-pgp | federation | This document |
   | ocm-mls | federation | This document |
   +=========+============+===============+
]]></artwork></figure>

</section>
<section anchor="open-issues"><name>Open Issues</name>

<t>This section collects open design issues and shall be removed before
publication.</t>

<t><list style="symbols">
  <t><strong>Streaming decryption.</strong> A chunked AEAD construction enabling
streaming decryption of large files should be specified for native
client implementations.  The specific construction and its interaction
with the FK wrapping model needs to be defined.</t>
  <t><strong>Application Message batching.</strong> The frequency and batching of
<spanx style="verb">MLS_APPLICATION</spanx> messages carrying wrapped FKs needs to be defined.
Since every epoch transition triggers a re-wrap of every shared
resource's FK (<xref target="fk-rewrap"/>), batching is load-bearing when many shares
exist and epoch transitions are frequent.</t>
  <t><strong>Commit retransmission.</strong> A missed Commit is detected directly from
the MLS epoch: a Commit arriving for a later epoch than the next
expected one indicates a gap.  A mechanism for requesting retransmission
of missed Commits, from the Group Owner Server or any Admin Server,
needs to be specified.  Retransmission is the first remedy for a gap;
the rejoin procedure (<xref target="rejoin"/>) is the fallback when retransmitted
Commits can no longer be applied. The proposed OCM Journaling mechanism
can be useful in this context.</t>
</list></t>

</section>
<section anchor="changes"><name>Changes</name>

<t>This section collects the changes with respect to the previous
version in the IETF datatracker.  It is meant to ease the review
process and it shall be removed when going to RFC last call.
The complete changelog is updated in the OCM-API GitHub repository.</t>

<section anchor="working-group-version-00"><name>Working Group Version 00</name>
<t><list style="symbols">
  <t>First Working Group version, adopted by the OCM Working Group.</t>
</list></t>

</section>
<section anchor="individual-submission-version-02"><name>Individual Submission Version 02</name>
<t><list style="symbols">
  <t>Following the introduction of an <spanx style="verb">encryption</spanx> object for Shares in
Version 07 of [OCM] and a corresponding IANA Registry, this document
has been adapted and corresponding registry entries have been added.</t>
</list></t>

</section>
<section anchor="individual-submission-version-01"><name>Individual Submission Version 01</name>
<t><list style="symbols">
  <t>Following the introduction of IANA Registries in Version 06 of [OCM],
all registry entries related to the <spanx style="verb">federation</spanx> share type have been
introduced in this document.</t>
</list></t>

</section>
</section>
<section anchor="references"><name>References</name>

<section anchor="normative-references"><name>Normative References</name>

<t>[OCM] Lo Presti, G., de Jong, M.B., Baghbani, M. and Nordin, M.  "<eref target="https://datatracker.ietf.org/doc/draft-ietf-ocm-open-cloud-mesh/">Open
Cloud
Mesh</eref>",
Work in Progress, Internet-Draft.</t>

<t>[ietf-mls-virtual-clients] Alwen, J., Kohbrok, K., McMillion, B.,
Mularczyk, M. and Robert, R.  "<eref target="https://datatracker.ietf.org/doc/html/draft-ietf-mls-virtual-clients-01">MLS Virtual
Clients</eref>",
Work in Progress, Internet-Draft, draft-ietf-mls-virtual-clients-01.</t>

<t>[RFC2119] Bradner, S.  "<eref target="https://datatracker.ietf.org/doc/html/rfc2119">Key words for use in RFCs to Indicate
Requirement Levels</eref>",
March 1997.</t>

<t>[RFC4648] Josefsson, S.  "<eref target="https://datatracker.ietf.org/doc/html/rfc4648">The Base16, Base32, and Base64 Data
Encodings</eref>", October
2006.</t>

<t>[RFC7517] Jones, M., "<eref target="https://datatracker.ietf.org/doc/html/rfc7517">JSON Web Key
(JWK)</eref>", May 2015.</t>

<t>[RFC8174] Leiba, B.  "<eref target="https://datatracker.ietf.org/html/rfc8174">Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words</eref>", May 2017.</t>

<t>[RFC9180] Barnes, R., Bhargavan, K., Lipp, B. and Wood, C. A.  "<eref target="https://datatracker.ietf.org/doc/html/rfc9180">Hybrid
Public Key Encryption</eref>",
February 2022.</t>

<t>[RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara,
E. and Cohn-Gordon, K.  "<eref target="https://datatracker.ietf.org/doc/html/rfc9420">The Messaging Layer Security (MLS)
Protocol</eref>", July 2023.</t>

<t>[RFC9421] Backman, A., Richer, J. and Sporny, M.  "<eref target="https://datatracker.ietf.org/doc/html/rfc9421">HTTP Message
Signatures</eref>", February
2024.</t>

</section>
<section anchor="informative-references"><name>Informative References</name>

<t>[RFC3552] Rescorla, E. and Korver, B.  "<eref target="https://datatracker.ietf.org/doc/html/rfc3552">Guidelines for Writing RFC Text
on Security
Considerations</eref>", BCP 72,
July 2003.</t>

<t>[RFC4918] Dusseault, L. M.  "<eref target="https://datatracker.ietf.org/doc/html/rfc4918">HTTP Extensions for Web Distributed
Authoring and
Versioning</eref>", June 2007.</t>

<t>[RFC9750] Beurdouche, B., Rescorla, E., Omara, E., Inguva, S. and Duric,
A.  "<eref target="https://datatracker.ietf.org/doc/html/rfc9750">The Messaging Layer Security (MLS)
Architecture</eref>", April
2025.</t>

</section>
</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>

<t>This work builds on the Open Cloud Mesh specification and the
discussions in the OCM community.</t>

<t>Work on this document has been funded by [Sovereign Tech Agency][sta]
through the <eref target="https://www.sovereign.tech/programs/fund">Tech Fund</eref>, with a specific <eref target="https://www.sovereign.tech/tech/open-cloud-mesh">project</eref>.</t>

</section>


  </middle>

  <back>








  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA9S9bXMbR5Iu+r1+RQf9QaIPQJuS5RdyZ+5wJMrWWJa0ojw+
GxMOswE0yR4B3Vx0gxTW6/3tJ98rq7pB0TO7EXc37j1jEUB3vWRl5cuTT06n
09DX/bI6Kv44DUXxvFpU67KvFsW363Zz3RV1U7y+rpri6bLdLIofqu6q2HR1
c4n/2ZWX+F8vy221Ls6q+WZd99tQzmbr6uao2Hv99Ifih5dng2fuhUU7b8oV
vHOxLi/6aV31F9N2vpqult30Qr89vaRvTz//PMzh35ftentUdP0ihPp6fVT0
603XP/r8828+fxTKdVUeFSfX18savlq3TVeUzaJ4W5XL6bt6VYX31fa2XS+O
ihdNX62bqp8+wzeH0PXwxV/KZdvAaLZVB3+AZ63gi6fvnodQbvqrdn0ECzOF
leiOih8OilfwoLqBPxUFT+KHev6+8n9u15dlU/8HjeSoOPvx1ek7+nu1Kuvl
UfG+bNo/dRsYxUFX0QewcEfFVd9fd0effTZvF9VBt2qX+AV41GcrfH6IY/j2
oHjZFm/WVdfXbhjf1puuur6usg/TwTw9ffvKj+VSfnSwbK/pN3+aw/oczK9G
xsUffKbfDMmq/Lm8vJrBi/y6lFeLOv0gHcybtlmg5LSb9bzyo1rhL/90TR93
9CkuxHBIyTfm7SqE6XRalDPYxHIOu/vuqu4KELbNqmr6YlFd1E2FolFUH/qq
6WAQRd8W/VU1kPGHILz7xfW67dt5uwzwrW5zfd2u+8Lks2D5LMoOBG1e1Td4
Ft6U676Gd7QXRXcFYtkdFAWNou5COb+qqxv4IR8gfO2uQ1Q8hIMT3188fPv8
afHNF48+34fXhZJfDcvUlJcVzW2JP4d34XmDt8GmLoqLdl3ARpWzZd1d4Tvw
TMATYfXxH4EGKNMo4IQU5Xzddl0+w2JVrWawyhOc6W21XOL/wrMD7FXTw/+P
T+Nvwsv6Smd8Wd/AQjRtX7TNEh5e3JZbXBd5vP0qyPOv6utJMdv0RbnsWvg6
Hc0SDtV/wEjkt4satraGL+Gvq2a+3l6jKOHouwCqqizoT+3lury+Al2whBd3
uKYVPmFSdLjbJWxivYSxyQLc1v1VoWs6L5vQ0kPpx7NKXwNfxPVbVPIvWewN
7F9FWhK0HQgdyUMZbip4/bKiPRhsFg2Blwc2ag3SIi90UwKdd13O6mVN4oSP
AWEiQU/HnYvjAZ+BVb1YLEFpfIIab90uNnN6aMjl/G8w7J8LWKA1DAwXi6Wc
34GLHN+Kr4M1XoCgLzYwVh76QGbgrzf0QSMjlGPS4u6g4MOw+DsqKMMDWjTV
bXFO03y3va7OJ8X5nopN2+zBv+HpYV1dgjjgu+oedwAPFF06Z/jDAn/Z7RX8
rfVWnr4oZlueNbz+JKTP5ZXFA1QuFjBzPEU9ymJ+JOoFjLe+qPlxIDL42hP+
Dazh/Aql4Bz+VZXr+RXfZH9ak5aAeVcfytX1knTaeXF71cItEM9A0V2XcH+t
Nsu+hi+RXMmaTtyC8lkTqYJRXsEfL68CKRUQy7+BwkB98XNRXbcwnFU1vwLN
261APl40+LNtcYp34fW67qriOZyH4mzbzGnbeP0enj4/Ax3UbWGNV/hukOir
Yg6XKxgMm76id92UXQ9P+3tLWgtOKJwaGvKZDhm+JUta9PXlVQ9P2MA9DaI1
q/rbqmpAnc2XNe4/vruUyYIqqOYlyBhtK/8Nnn9BogVqol6C3dCAPpqBTMI8
Lsp5hYteg+zCnFYl7Dg/FvYZZgwbWvem8GvUZjA1mLC8G/RzewGXAr8DD3sX
VRZ+EUfMakPGTQPDNZIlouHD3wIejAcg1tVNDeeGFxz2BN9oLzNpLOk+gj1U
vWAa2w56SHSabDxJQouLKw+FGTkJx7ElP0MTiA7KVbtc4K100sjgeWlXVQUr
11/p0HixFjUILegF+P5z0PiL6nrZbvGsgjqgfcX36HLjvIu4GbTlsD8yvgnf
s09/CCwaxcVmCevZFSqysjbrdqn7Pe3gnE1oxLj6eEWtYO7rGrQPKLNZdVUu
L3B/cNNJHU10Ewo094o9fuYerjJdiaQlnMqBO7DdLBd0SzVwPOE2Xtes9vvy
fUXSsqpK3mvZVxQCLzoH4QWeZnyc2J60j4sWr2/QlRXqM/jkpjI5j4Zqcfbd
6x9fPgvXsGjtepXuGdwLopo61W/pg1o/sCACNyngNygXMIxGvzI8VHWn4wM5
gyuiuazWoe7aJY8LVjVZ74t1u3JPQgHiDb9Gi2deX/ONjl8LprtktDKw4ocf
z97husAtzCZQSQej+Gu97vFGeSrLA1b4dTVn9Qrz/hv5B+gb3PAXpyLxP4tC
xGHpO+AKpid34RSGUfZwcfJjO9YDVc1nplTNAqaqF78VWN9L3iE6u6dgtfFE
QVGzTLOuJmU3uBiuQNJAveOZgaXnJy+r8iI0LYpy1eDZhvEN7lEQNBA60FJi
Z6yrVXtD84dDVzULup4PwKKtnHpFawVnjPKdHSPYwpHzIee4zgR2eJbvf4xJ
n9CQ4Q1dKjTuGOPq528luyt87GwU9zwb6YOcaIiGM8mA+awrMJjJqsIlW5EV
Ttv9ju/RdtOnimJCP8eXwXmZgwnKqntW4SNlgGoM0OroS2FdN+Sk9G27kF1O
vk/KQr4NE8GtQtNvjvcp2vqN29VJuq0oYNnuvovz5Y1p2oGVDV5YMXalOFFL
HxtI7FjAcaPxE/e46gMYWPRBddMub6pUZumcNNugBiWu4w1MLmoQWoHbEi8V
9LPI+CjN8EzM84ACzxoE/8zbBHqmYkPtfdPe8tXHBq0f5aICX2WJnllg+xuf
JyuGK/ysWqJxtqWjBaqELyIUAfU5qsURqszrtgMPBXcWNC79hl+O771qV5VZ
wGINlYsVOMl8bigAUry+bcjXw6+Fcj2re1QhXfG0Xa3qXi4xMsm+h9P08Pn3
+87xAQlQeSXp6vAa03ua1TT8iS5MHQhdYqSzzJD8+wa2bFm/F/sS1xxUFJq0
EkCBlfnWe3+4hGhC6mvV8EQ7GE7T1ixQXEsWlWV9Uc236AXFs4oalVY5qkuS
YjBAWtx2Wqsj0YmocekvZObTArpdC6aV5+uK1k99uJrNwIt6jXKJD0BhW9Ca
qPqGo7QOpGT9X8WikpsTzPflBVyn1b9vYI6sYkE/wa2JBsgFGW749Em4XpZz
fs7VBlZGb+tl216TltGVE8kr8YShR3fTwg6UczQ8DsIJ2OQyDBRzvgHwOSsY
BzqLtLk6SZV/GoENaxLwr5es+FiecDnAZAdJzPUU/9Ss5BP4ioggH5FycVM2
88quFnYlcPfJC1iDUxmtzailWPJpJwOZ9Crh9t3hMfA6Bmws707RBURGMSxo
OauWeJXQrFZ4Sy1Yv9INsGgxJoGvd3o/Xm6ycCBzLDELdWouNyXuSVWR4IRN
U//7poLt7zggAWs4L9frmsIZoBc4/NBVsNNg+oC44jG3WI2eToxK0peTiI+b
GYeJnCUgR439INYaoaluvOg/wBP0/K7oRbEreiFfBCGYogmLDgHpFlgEuAau
9RtefVpoSPRkDBWRm7AG5bcIZhlGEekqWOA+xpskelBUdPT5OyARTUdeBjz8
dRPGP5ON9PoMDsYUR8zn8fn3cf8xbBBcOIvMqKi+cXNjCGh0niRsS/D6wATd
XIAyJJsE9OemwVcmP3r+PQz8p6uqidqDAwcaNKCn4oGs6nXi4XAcoNMhF+mQ
8a8yRdyU59/zhUBXX72C01vDgi63Goki4RuPDUWFGcJgoGpg2vbxcAeXxw8n
/xbUeSahAleVTF4J08AG8EJPRdSKEjxo0gw2qklggwCfy3sKK3LdgqEXpwzW
G4bp9OzyNBZlXx5gFOtdtYbz0C7byy1rClwt9PG6Yg/dir0J/2/x6jX999vT
f/3xxdvTZ/jfZ9+dvHxp/8HfCHtsXPKfycy0Xz59/cMPp6+e8Y/hr0X2J1iR
Pd6Svddv3r14/erk5d7AsyQ1yeZezXGWqmebMRqQ8Js/P31THH4RMFzz6PDw
m58pcPP14Vdf/Ix6q2FTgOKn/E9Ymy0q+6okaxH3HqzFugeLZEKO01V72xSo
8WDZfmyWFI/qSffS1XZbd+iG0FmbgQ/05ReoIVqUWbg9NlVm9Ya6mS83tG8o
wLdwDU7xCil7U3MTNFLelPP3/I9zEqNf6sU5P1CEV6UZoxATFD99K2tGHspm
vSwe4u7/+PbllGaOigqTCdOuvKhCuby+ggugt0AHOoewXl98+cXX4AueVWSi
F0/2WfyvS77yW7jROGB7AnKIr12zK4oXL8grx+tk/rDMZALA9YxBAX0GectV
R+5+llYgt6eP8sknikKMExeHw1XY7cmKgSJh4BiB6Y5CmBaffko35qefFlMw
mtNsw3YQjExuTw4v2lc4jEzWBOmoriJbX28ejD1SPH80/Bg+Fn5EIZGr4tsd
N3nwNzlIbFdfUhis5zsZ9w83Xs+yWE5kRJFFBTZljxk90RP0muOP3dDs+ru9
MEMxxDjcUbFXgsV2iWkDMHCWSxEneJPaNeyriYMyB1MJPua7LrD0oNEEVhzG
9kEfwDjJVunUwUKtK2KkEcYlvL1EwxwtjjnNi+5A8mrZOqkwBMEXI6tRCqZz
oLNaUNSqXR/skZzgKeV4BwtLl58VWoCj3TFHzQr9YzHHLFSZxxxfNBZ4YltJ
hNVFMzgquAz0PXTBDmheaYgI5oZC8umnWYxnOOe7j5xcilkcSy1tPQMxsOai
gJzJoNiOWvt5LMj2GsU+j3HJrWdhK4yRwxdHglbv/KODeTj46+/qS9iM6RL0
+VKMahoLhR9ZPfHy/cDXPq8zr1LjjrbsrHPEnAO2tuwEh7xYuL9layEGVdLY
E1/xHKo4iBossflpHC5gEbNQ6jHgo8UjoYyjnfij3NtWu4F9vhNybGRb2MsB
RXcQXqBSJSOm55xsEh/q5bxFD8W5CjwJerCoYXM/o4vaud9Gv1n2UL8forv6
7dBdPRF39XWzHPWrTtiveuh9t24/OmS6XvJSmzzdYCDiulAcTuFz/fDXX+l7
U/jeb7/tu6nmO5WtOJzXE3Ov49e7oOrzBg1V0GybykVOVJd/y6ZpFA4wJGRt
uy0YumC2kwpRTyOaqmqCm8cRxOO4qUtbtNMPmMlET9+MYXwYGBSXKOy8DCen
J8/AirrE/NXVKvjFgUMO6gCVXbepKa399h6+DE0nid3IlOArC4zNJDPbSIbR
TGfLkLIWVgsaddUuJ83WjvPTMVoFDw7Jwe9ofXBtHFRGMAiEVHgb3Y7UqYrv
gB/s8NRAii7eT9cVPgGlqCjSlwd2rOAuacUfX7Ug8DqN6O8wcAEvPZs+repb
czEoCAZ2HC3t60a9GnJpyuVkxGkM6rV05rZMnM/SidfFr5tkK2memjdjYX5v
0vxJdmf6oEISWQ0EXULbZ7O6lqgYzg+WF5YPszMfmxtFXHFysFg1xtyv6UYJ
rSoNxU6oI0nbRhsm9lS2WaQdNDrEdh7GluICafjCCeQJhpyu1+iNiocCvwId
QP4B6FieJh5by7ALKoACMutkN1EHrq4RtYPmF8oOLAH+FYzwUBazuqGE7lUL
t+XxwEdFwwE+A0uXLjFcPhIi/IcErWB1yoZtF/tY/0BfmRSJj+q8U/pSmNdr
uFFxYSmpKxsmjs9dxhYFusXMbWd/B7VIN3SgXFBFEQOXC5MrNAYQQE62zRzs
66bddJSJdf5WIDt5VrEioV1oGxTg6gO5NjRL9Djh9WSZLDFfj5sIN0F8TngY
bWP1og6/PPh6n3xvHNbbdll1AnMJQVBG/FzWYBziFRuxvzW8lG4TWjlodoaT
DSwnWuWS45Fo+8OTs30BAAwi8Q+fwWdxiEGH+BgloWK8kGp9xFuAtp5TMIF+
8tWTz3/eV6xJxz8N6oR3cKVhygBFZ01zREtMjFA2a2HGuAyfFOMj53DEyZnl
C5IfV5o+fNDx5RmNLhjSU7TfGzRJcG1DZhuveUbgG4M2mbuvjuzWk4PH+4mv
B34huHvLhRo5P757Pv3avG7vlcmdh4OEIVm+M1xxUhHMOAwpLEjjgOzilg+y
8RpUG6Q1EU6FIZDoonJwU9E1aapINIjupUSk0PITyAydi8WCg+cUHocbk3PF
c53BC0KFiJlfeMgCOiijw0e0mtwPPMArXDkJVjsHhQ1bBXiIdUtvTJOYCU5C
TWs29QsOyOMLQqu2On2Cdzx+11xvczt2jVm871B2RUyYq3WVORx3ukIRNsGi
+aAzaV7WYE2yLXG9MSShc4ScNoJjcjIQV++Yw6NhkOT/z2pRtZxoBBE7pqfK
34OCbEp9jxdZGS2IJis2POsave3hvuZUA6F35cBiLFHVipmR/lw6WIPTixdV
P79CzYq7/w5E0n57/i8gtW/auun/+BkuKbx+ei3rcA7nbHGNn8nh0mwwhrIW
6pfEJUpn5+xV+Oc13JqVXB+Bg2XfvXv3pjjTiXd60xz+zOu7pdvksgQ3offZ
ZXjLX376/izY2OCT888OENE5xcRp89nfb993B3/v2uacnvnVk8OvfqZgHXoX
cITXHCWsF+SJ2ihPNOYDmm+pX0ClBKpsXi1gjPAQiyOivnXKDNFbhE+ky6nn
JLhGesTh5GtwXcWX06g8SCT8+iuZG1MQjWmZKOrffmP1nV8rrLifnY0lehXW
GI9ElzhOHmIT5vCuNYyMr2Cz4aNIoS7DDCEfAnbVEDtLcZwrSVk/Owsovus1
2mcLAtsuW3atk3xvzDmPXAOP8caeomFKvpbJ/FFxDoP45c3b129en528PC+S
XK/lkX0aO0Q3jw1+diXVV+zAapwMPbPobyoaLk14yebC8sG5gvetqwrkkqIo
TigG/mTmQuKLFxt2Yfie1Rm/rS7Gr8dH+xNKRq7K95xTLcqbsl6SLuJZgzZJ
nGq08SSDavEIRK2PJzAnOyISwWWhBxGJiYSgU8yQvPRaLVMGVWX5Wlrf2bot
F3Mw6SjKhncjHMDU68JZgJfg8QMiDCdv3rx88fQEExjnUcRQW5MGUVeH4G6E
rzYpSdEGIxk6GYm56cmIJkEnm+IPUpk89lfI5nrBrpuT0zLIMUuejvIZfzjl
H1JMI2B626N9stMkou/1ejKg8+CVurin8/qaNkPhdemNQxoy09bBtDUmcsk8
T2/qyY6rSdBzPN44CYJ/oP29Vnslu/hlL+SezeOLpGcE4LAICI3eaSS4w3QI
Y9e4XA4HQLkUt2C2TU8UZ9PNSeUnBD4Cd4EDCIsJZ4TyiscYeL+uRmODBOaL
KAUQehDnhT0a7YWKwFigYJ6JU8SwDQm70EHns6vPrtACakj8YJoXoHPyVxfp
qwPcePiNhvzgiH0BOw7+t+P7mQ8NxfwZZU87sJIAwYg39sXx6OsJAEgQblpW
efUFaLaWwEUEvyCF12jmBy0hTlehSc81EhgOkN9w6OYNLMLQ4Tr8YqKGMi+b
qKpFK5Ue4FqDAWIqgSPlGDTDvPtAhZG/4lAq6+rvnDjuEKC41f0j5UYZcBUz
DeLITwUmgH+hHQDp3KFVit+jwwId8kS9wMqc1QiJySMQK4zozNQ6sIoZTNcG
zH4Mwpb+BizKCxQ6Mpc6MvHozaSlMfP84t05X16EfqMrdxfKbWrukIS5qzQD
1/Ck6MJFSOqDzuvZKWoLlY5KwuFZCBHWBfahBw0Oi/GKQM4fRKTXhjwaOcN1
1DN0XmFYkrjARNqmkS06GI0uoFOMgRM8ArWMlgCSiEZs+uqSyg8qTEyo5VuG
Vd2hi0aZ0mdnPNrENItJe3qVeSq92rJgk6FxyO4RmG4JsjLxxkDBkL40QCbY
lYsN1u6QW0Nz6rS4C+2YiuvE6IpAM5/CQq3q9cFE8ZVY8ALHYUlgsfBJ8R1Y
jrJWBuhVX4XCNJoQjEVIPGYrREKdcfDppxxHd3UHHrgzrBMTa58UDoVcXDDZ
7iUPtw8W0yDrYmhaoP5BB8pbKRiVxHEgXkliuBRspiK8Edtg98WPy3A6gskm
C4uCBrAEd+O8w31x3sVHcN7hfjjvj0UxXEyCt1Ny0zSEpCogRinG8PohSXSO
4vUtiylRMv0QL3e9NjOTA0dxFzR/YIWgXgIzoF0vCG9Iv7wbKxE3kJ9Oqjac
0TkofsD56NIxoD9JU7v06CQiDSSKehAEKaoxJr7pJHpD39aqpIqmAbI6zUv8
grm+3d0VDHbBfzmhC5QyahjfCm85vjWeW0YQimVetO4iep4yWNQnWTCJJLvJ
CgAEG60rI3c5w7jo7Xp+aeVZSIKWMqVPqimgSphFh5qiFJfqF6q/1ZWTfDaC
m+DQgLJdZuEldp9kQnxgojxKUrUcJtgnfBnADYb+XQyyaTiUlFcmhqIq3qUx
P1IFMTKPuuIkQS1o5RQpgeCKpyh4YehatPV3nmgM5lVY9gdaMPgQHwUi0zIK
fNDOcGPYWSQhKLek/GCsqEhWgfPMgiuuRlDgpDR3Q7kDRwmSeAFGvHd4Dbmr
wAmb+wCHCTjlcflU+I9nJ8Q/9uX6kl0GzfmQ4IhBkmGojwnDI9p/VW7DAInN
BsGPdMekJQFkzBDcDH3BFraSLTG9hpKMlyJ19QoeFApzJTeYImFQUqE4tTSH
RgoMD2nMuYkZ/MPJv8Heh01jgOBJRBhZNdR5fNx5zB8IgM5M5cAFok8VsPXK
mdgWSaYbkYrarcyMDt2gGiXOVxbp+fdJ2tJlm1n06AjmFjMoFW8vB858SQah
zI17udmmI6BeC3gFq0CpBfTV6Z2m5SNpljzNxIcYTsQHYOZ9GHYZ5swpS6WV
9XzZ180NuHilgrXGc/8GXC52AZfDMNPuFrwVBd7mGWdc7ZE0dL6kQfRLAhVm
G5JGLGn9ITb4KAMUhzQzf2di3lbegQc43hGk6twh9iTJp+9FTermDeecE4lY
+rmuLy8pKDTbBlYXF2C8tOtY2w06tAZfl1Ec9hBJGrcIGSGTnqECASMWcHbA
TY+oCCtItgtXtZEb1nGSzQ8qsbXfZdnEFD2gdcVLpDsh9Y77+NNI5r1tdFND
moR3ufq0xtMq/LEMaIOXLnqanOwPksIrBQbgFNHYMQSlhM5aVeI6VSymDtyA
grDcRtR4xDWgV8A6QdeEOFxkLc7GvHPwBDP/HJfk3Y6Ks2DKYyQ2EJ/HNnfX
09U35j4wpEgVxgRls70lz4CO5227fl9oGZvC7KwKDgciubkW06garTa1pWAZ
K/LISUfw4mTvdoLPAEVeX+JR667LlSo1wzjA8zcdWgLsNsNiyHqitZMWnVE9
ERWR+c9wQd9EnNcSUxutS4ANauK8OXCf257DIFk8myawK+BDgxgEe8IwYD0M
9oykN9KfPejCssWTclODDoKpJdKFd1tSG+NDPhyNUG+fXeQPtUNSmy0v2SXN
Jo0LuASFxt6cvBX2h+JXYTR+NTwhUnAg9yxtXXLLRqHApHke58omrIZ1DEbR
oocdwSjDDLBxDd4hp0O5GiGLyr0b7inj8vEY3CeoVUhQy5VSohofCyEOJVB2
5c2mu5piKcPwC6h8B1EPiVFb0hFshDC0Ef6xbEvQbEthF2ACsOeQ4ziUL3wM
yqemxmDHUxBfSEB8WiMukfihCROtlZqS01wXGQhGL8EscK3wUrF4UrehInVS
5Gi+GmXMUZESuxA8P5RLWIJFpIIR/4d0h4ZNvSltRZYU15YPpQyC34WIjfOY
NLMEcZrSHzXJ8bq1mhzHdxRV2SQ+mDeKLXKtbULrhPl7YnadjHhdnnPBm0lt
JxpK4kr2rcbUfMAuxRaeZ/mvCGqg+aOpdu6/QUw9UvRD8clndTdvyZIOJyqr
lHNZdpFNCw5ZvjB0admUcooe2bO41TAyzJpvBezG8HQTuh6+geElvGVwYRc6
KFepleMg2vnq/CiE//qv/yoQDRF+DUWxx3C9xR4xz1UT/FN5Xf8VTgOOC+Tt
8ODJwed7E/4upxDxz0afhqRLnvoHX8NfFwdpjV8/FaATcTTxxzoXJjQ6Kv5G
RGi/0v8LHyOoBH+JeoV+QH+Ny4O/2EPTBGvXSDjxP9ya/mw/UsHB3/xa7N1W
s0V5g8/+jP/zM/wl/+dUqhjxm78Vv9ET8P/9OfyGCxfCq9b5Am7ZSYal4MGg
H3I7JAIX862x2JRolXZmaCkeSCAi9GeJhcGfanlJhPcU428Id2J7Dpw0a5U0
BvPxtslEVcGZarbJktHIvM9MEC8MfJaSoo6V8zuS1TDIJn0A8TaxC8ZHB47I
XvIdPjtY33zuucXk9NCJdUvzzN1ewoLiYl6OSyOBrTqUNWEtxI0NDiRGx9S4
JZg24gNYjHzNr+A08tEL356+K+7YiP8Pf/9i8Ydf+X9F6t4KYmpwfPlbKMsl
+GjVnwbHkc/a+zjQ4Umj2ls8U/gY2RkcVzx1hK+ElcEvWE1j/BhtjIrVwr/Y
x1MFZeI6xoX6497wTL3FjHHHPBlk2ZgAq6hJyswBxQTePwpBwPiDZqWmCvJi
aeHUyV3IxgSoINHVuP8epExpnI0ml2iXh3wZWoufCYMl10Ny/eClbHW1cvGt
JDgqBV23o2BKwgkM8g+0fFyXQxI5b4nNU4MXaWz5QSrPZYpEux+C4snBITh0
F1gJkcIqx5ZGaYjc8SRrlQK0fP6eDuzmrQ+kGwAiJEDDiNNwW4loX484vS5r
tLB/1IqwoHEKZY0qPs4aVa/NAGDCLXhXyGmx0lQCTNqvsgo4+NlTtAjxCS7H
xHh3i7pHxHvYc5D3Pb+EOzHvCYsOvjcY1tj9nA1oLG4kHqCqieoZUQJiKCu9
17qaWpjLZNLPT3ORhaMahU1OGAqsDh+2DkMnNkusIx0F9iePnVUwEdAAuOWU
cMHrhr3MKVp/iVCvcU2vSgrq+Nsl4BSmhAr271mLZor8Chh96sGjes+FnRjg
moG3/L4oFT/tKfkkXIeIeX6rSC8IjgcYp8UPnE0uY+LVyoN5xKUnBBb4FBr+
GJwpP9SrDR62vlwG/Rl7u1IWPiIfXx082hemknO+UM7VnklcCl8ezoP0Ga0N
UyQGO4a4Nmy2rB1UXswLYeiEverkpc/Ojw2iEMpYW23wCsec2DkTgsuisSKP
wa3iAczaDfodtVjt7I+9VAvEcz9Fs4SuHiH+yWijOJKEasa+3oWHffu+aqZw
SimCPxFDH1MQN7XygVX9/CD6mhIU0kR50ES5KzWXYbkkF5yYm2rLrjS7CbtA
fIwJ5slqIoPnym5ydK+tXLPx77yLhyswLIVqTckuNAHtYm2b/4EW2uqPND0i
qshGxKq8msPV0CW+pgOZhhShuyrf60WQTwz/Ji8cZeQBC34InvIYHpZ00BBa
4sprIwNU0STrF2tD+owNwHGZbMBos/jE3VxAOelPPi00RogGCPz0EXKfwpP7
3IdpgAnDIvMUUw+VQmCAKa0jhAbl9D90IJn8hyNCLfqgE+FPw5A7Xd+EaBfg
0oWSXI2gpwijDjdNkEPQWiKzcyEwElDHwBFzviVcxcj3y1WozFYg2E/MWOLx
ZWbc4Z14eODOBcbEKiztTeWPXABXLGtz5sSTpzI2d8nCL7B0lCxxEcwHiZ4f
u6kP90cYBSnW7pUvba5cp7SLK4yxwCy2GAIxg2MwfsRr/XL46Otfnn33/ekP
//fRkyeH3/xycnoGf/r26Q+/nH138ujJl7+cLuiDUUviq4PDfa9jJJ/+6ydy
Noc8aEbGcT8SNJdCzQrMTWPZd0cY0eSGbDhPT+YEXJdkX19s1pwNoHEoFp+P
P5vFNm7HWBU4w0x2K9dBNNtBmPZEEKAPPF+AKpaLao0gZJTtLofiG9xY7cB7
Qo5dJgTnGg0CwR5qxg6NkGtcfCbqxW8rG0R6LoKzFQ8P7TzThQiqY85cJlgA
SYtJaUZc9QH/n/JnSiqa6kJ1kt1mJil3InTZJqQbZF3C9BfC45PWeN+RE+dX
cY1QTCUb/Da4JUyBukcR6Yv6PnEahABjIZB3ibQx+FfilSPHA9ZuPxaduaB/
KcWxDCEbqRbRMhyOWRuCwc3E87sFymuoR6Se4bLueKzFOcv4eU6BgBKgiTt2
PglXjGFceQvTyJdMYIwlUlcV2LYqnYpkxgSmYjbxIuHByv1r1RsgQPDoPzu+
6120DVyI/xTDCB965XGS1LzAepLxUHpquT0Wm5bQdYRnzIHbZMnhKVhH23uc
pu9NAneBO3OxpHqpOamGS3VfL1pNdPIRIx6jkyYB6yAHI+yJIN30rx6sw+KV
4NLAbaa6KHkP/0qNo4ntQPUBj3pNbCKMYUokW53vHJI+lxOIV/WG6bNmbc/l
BLoPmCn+Oxxu8oxDwuiFY7tVnSMlX/fhhAwDTki53fGdW/SVhCOS+Z/us168
TN34OoWHSG05lcT//hCDkCKiSHOboKGih/egQyzwPaE9cp5XguUSM4TXtvBv
dhCtDC5FlBlxmYtpFBTaAp5oe8koKOY2FOzkhVo7LoAgtQYjZakaX0oLTJUQ
gswt0kZpchL0BY8OlcWU7lcpu54SPHF9ow03aGdxcQPmX2g/dTfJmBwsvUpu
zuzJkLg7FtYt18hyDtBqi/aOHR/ZxpC+TbkShig4/2YKNCiF5ZbIhMBkrgmp
ET0GOrRDPIUMiSkOUbg4kRYFH0/OLcWTIkSPIyFi48TEWJnI3WSgqcPu6qMN
7OvSTiQPyoI+YjQhbpghu3Lx8tdScsUI+B7/EmsmKp6UzDBV3Ef/9ljiNtGK
8jTMzYK7GjAmWzQ87NaMmmpQbDFn+okWWYLFWXM9BNUdptcRA2rZe/HEuUeF
MioJq5HcUafaaKezo04+U7z8+V30LJkTBiBFHeOgRN7gjhwucLoCUqlMxbWs
7sH6ccYLyQtLSqdV5wbYJKQvQu3QIRuz6B9h8CdaAEyRq09zA0qYwWjd13zX
+AYDBhMNQ3NLQpg1NaJolMEYfQl1JvJaeC2W7dW/oP3d7Ubr2rtqXXe/RXnl
0q3AqpIMpnR3XR+l83a++sVQ6r/Q78/HSDsOHx98sS8pHqGswgRLe13+O1bP
wFMkbvAvf/3jcfiN53YcRr7Lfm7+Cy0dZstOHgKTty5kTBnICZUTwiJpcTIu
wk6ejEqjMeeD954HNnT9lbJr2XeEG4ILN8Tfa6xRrVQ0XAmQu14IPFH1z0rM
dLhjltuolLTuuEPXh518Mfsr9B8wUE7YPj19nAhdVg6ERXejF3kiIOTQbMop
z0+gSMVD5GUhY8iZ+TR6iqfj/CP0gbSwTEnWeCezm6+jDrocHoEyihA/29CF
K8gOO5HBrqojVqz5e8jK8X40t2ECfdWZj8oZpZEBN3hAkrpvGq8P3w3dQUlh
SV4SLjDEy2FmjZgm8RuHI+69BLvJ4Qyzdha//UhXHwmSyjXol/jZ40kcFSzL
Q3rRBOzdGRx5/jKXYOmL68GoZYmPJXiFr5Y1Y5dSn6mP0y/ynGhY/vvFQ/ni
xL/4cdj5YkzGZ8qTPP2tT0qz6ZdxDHh4GWckRtzCxCtDF9/U3Z1uGc+lvFxj
WwIKbeJBXUaCb18qiQNFjHCHRCObZZV5dVjyKS67YPVdzIQsziWzswwYAAW/
6xxO12oArQEpawSrVMaFdu66uVN9xRvDrBaa+4vmohUxB5/op2qJQo71Hurk
tCMXzqpcaHuHMG40RFtv/EY+PPgKZApB2c6TuKcLOHGxpJWFW/Ii5fEg8cgd
ILp6QIAxBIVymcgGzveCiFgR4Ln1YkfIMKyVwJog0M0Xm6WvZFJDQy2MkSgJ
cR37SMWInUI/p4lFE4UQ8Iof+fim0FXB0QIdF8uFzoSdlh12NcnTgLAiCYil
phub+uJ6jqybANPaDCvqOVppccLD1LdMnDlZLnXes/WyKITUCLBeWNO5ZQxP
FPN1JSl6/mmM7/OcDvaDKpddNnNcaRsQJ7tVDaHKCqDflhV8aTylzYdk4oIA
mfOLxQl445N/ej6wlATSl9RzpjaDGgy41SMHA/wnPjVcmfSxmTKJGYm/HLaB
7lAjxYbQRR1/U2k4mV132XdnxcR+HlTRDXOhDHpWAlb3EsLiGhxr+4Em8cbI
gLJQDDMVzHFF4eBWXdJtIHgH1LcPIR3PiPrZXQVkViyraQs+eYN8B13olPwc
s8mD633K2Ej+rk/SHNh3Oi0D4wmDbk/Y3lnkx12CSIogCRhhxKOYdaytjipy
THrRWfBplESBPBfKCvB6jL2CtfDIl3GR2fYCgTTunwnJTALdVXwR3QTCByK6
XLTkplFEn3ZIIaIQCRG/xMMOYrKkJCOmY/H4E3ZNatW5tH1+1QphsA5eC4+Y
Y6icdRXHa0OUiR+l2l3qffUK2OG6iV5eLiOD84xsAbF+WLKknJ+iG6rWML9Q
c9WOGwsWs8SotbUrQppO59vKO9bTiAuYWl9H1uSrmtj/Svc0wYhw1ONyg4XC
HbL/wwrQZJcIWZiKQVPjid+GBeJtiMbclnBRzevOstU9aMbI6qcEKGFIgIKa
pa+ui8cSwiXoW9ozshKqAXhFucAQ1kRRKym0BMlqeDeRp/4dLq9ZGksGTFF/
odEn+u4kJkOagnauibv+ebmZVI/l00bArK7S/iDYcaEUUbXouJEvKTlwyA9x
pCqAoBqT1JHFu+KGkeeKHus7c/EIsTg+SprMQXiEL5Hh7STxHnpOUfdjOxJ8
y6y6rJsxonDloqNRaNaq97avAJnwKYRJHklBIFjQ0iA09JFpMawzjUGbqXNf
q4meMRYHZBvSo3q2RRK9m/gcKK/J1kNRMLg1mgtdEZsSWUMqKCglZYPEBTQl
554Ii1EXPWg0dg7CYyrmZkIiPljCLYYea8bJFRve3LYxrkWv2k2jJMtx26oS
7sixopOk9UgqchQsHpSPpUIlHj37eBV5mco16PZADXehHqJfkmY8CF/AjL9r
l4vpDK6/o8Ek6dhSETyrv4XYm5k+7XjAF6xuDjWEz7aiGGkV1t7JhQKy5hU6
hinoCT7NK6sYtQe1w0ADFKEWxpqQrtltzZ0+9IhcGL+U206hZDQiJlqOBu87
PwgqaoLTcQDnqOfYK49W1Z5ZiOz8FwQ5E6HlpBHiFMdZr3gnhTkHNnhRTduL
C+FrnG/w7fQcCoDK154mUOaD8IS4zdHC37FvcSKlYw1T9j8i/6GXiP5mAiDR
DT33H2RUTrLO+RojfgefsgB33tfTe2wR4nFu8hiBOitKKkJP8V6L44d//r0a
wMblnjfCIj+XD7pyovlawDqj0+LuuRvOeiV1YSEwGxbImrOpzGoiI/66pEK8
IYHEhH1abQw5cYVipGsmY5V2BHyum03lOKeZ+yW5dvHKZTgKoW7hNE0YeSfV
NR2eDJgQ2HmEsntJ3OF0YSvbdt0xpFmJaG11kgp7gn9gPRwXlhGnO6+vEi8N
wamjBM4CLf2E6bYTRgWq4gEbFyHlHpA3RfsdkUTKbJijNAd9InEnMaKTFJ9g
8OiOmhpXSvDmNRxnLn57ypUMU6q187iaz5g/FtdlJ09tiiJoFnYLWORGwu8w
3DeIjp9rEQPXs40iwr5Eik/Ohow0N6BHresbEBf5U5BnjcNTHuOR+g6eBtL5
fmwl5eaYY8hMY+qR8mLYu1yoCAgSWCRdESkWFxJsJdqba7hl+D6gFUgyMkV9
UA1iPuR/Z4HIhlMFXAE7KBG2AldGBssRBAs5SB0e/IwLnF1zbY8f8uXbGQBL
+IG6YxzEbnZsJmWwMmZOSWtZadAoJHf34OxvJN3kG9dUcfZlj3Zi6J/N/Je+
vGSm3lS6dkjVsTkvgfoGCzmUtz21JEU2SUZALyeWt3gpTwLW62mbBmOvjnzN
jjlRA1dE9NhebzXanO86iwkj2Qj3Q/GJCANWGHHKKRfiZYrToh2KrUhgK6+G
4u9vXcR67bxxyQv3moSCDXfA5FGEaPWmHUwVCUKIYTmQq0TiKB/AZBgSb2Gc
kipeqYLSAPkkdUk1oT+SIwOrtatcJw0VL6SyuiCym2M94GHkt+7LArfkPLoY
ZEmzOPbfNXlsrJ9H6RzgJ1blS7foBfejy96sj0nHGjNuqJBGxttKPp3KgvGi
mhqHPkbDVlWv8PuY+cXd5UCRf6BWGAdXqmB0P2TTwwvHnq65VLjTOH+wGEui
jtfIOYAzJeFu6q5db1WJhbrhDoUUvNAGOyC113hqCtYEfN7FrQcT/ar3+tX6
n8B4rXGrow5mYUCuX2wbxCfHDcooxpC6x9bN/R4PNHUW5n4Xq7pb0djU1CDH
ARwfuQ7hoFalNoxrimq9bglLy9qCKi3w0rFwBOF0LbsaWy8EY8F1WZ2jgqLg
yO+yWZZCY82TiYdJ9I4nesTOnLl47KaVDqMEj5NinLNRV9AloVyxjDXETWXB
jNGM6ZyDxVI3y9zDbcouLmkwqoWx6Aaal+TWZ+TVebaCh6NhNQFFxWQUdwkS
U4cse7kjI7V45WA3zkYPeWDB7ttJ2kWUKyGSaI3CEE/8TTxRVBvH1hX20mWU
7gyZZ6ZiCh2mdaEoC6NZhi8EoYLj+On0JQzlFHZEGagzp4uy7XnZTNI+N7pF
dJVIRjFCfJLe00kCmFZKAMBsoyXZIFn38VTJFwePDw459xyFRjgjg8Z+fMTK
yDksScFNTZn5WFnB08qOkMSlCfqvFNguO1RowwLjFrRFkFMVNGgSX+qYR9lv
1E6haWuhWJtE9eDsxPKkB+TCxs8hfYwI3JRIG4k1Sr0VNqaMfLc1dyiGT8ki
beT3IiVpMwKMBIQ4oYO8jjtnnMBaavcwruJmC+oZlQHhF+gk76j4NqKEvZQz
ZJK/DZkOyGv23zpy1eF2laX13c41e/Hsj7EYPFakz9rZn+4Y4u7S8UQqsDkv
s271rnb8N60d96dI7yE665ru9Ro3sTAxzhrO5U+/4J/OXQpy90EiH+rPxLZS
4t6XiguwO540UYlHwBry4ePVgPGGkxpnTSuMbBhFaKqlxUk4MWAIKJKgVOnM
KX3czijShnDCTJVzuoJ7ciyNTWWMzGjCoHBwnN2BGeb5G+WupoBQt5kx47vv
0fhUCF6Czt2bWrpclJW/rAUmY2HS3J4Xkmxi+LGGdqOIvrsKv0K+i0R4sbvG
xEZJ4JHd4DcDk44jBR20phlE0YcdKl/0GU7ATgE5lGNpaBemofgjN5GIMMvU
nDD4v9+IdeWrOuOqll1IunpjZA6/Ka4XteirpGE9O9SOKIn6IU4QA8Qm2vlD
DYS9WIhN92KxTwMqV7P6ctNuOnfXqqUjly3ZFlmEc0AokDd1YSlF3gWD9Guf
QB81g62cSKpkIpnIyY5sxyTA795W2HB1/+5iWV2h5BKAf796/e7j5pg2LPP2
HPcb7TTrsIjG2D/WNoaYrKjOBeUdqYn6rDxtWP0izjiJgnnhQVnbEiiGsHel
FqnCdQRuQVlULlMrm21ISexnFZ3DGH1tECODncdQI5J5athOxt5Tgi2U8577
SN/7jlVRG79k//92v+6+MdOoT0LepQIxdoPqiWO7B0sSd5YgZphEb2HzV63A
D+4Q03ZZQyG50aRDUNlzv9SxDkETpanYXUXYtM00a8aSdRAiD08NUYVdjbUU
8sCHqAOtQq5JilR2N/nIunsI1l9BjGUYNvhgG5Lo0CgvMWZ6fMEY/YQEz9nB
HnHw31IbqTl3dyWKh5a1J1MBcIBC2S+coLrrWcFggt8MWcGgj746RLh6C1Ih
SaGGI+Yc0I47vHkCJqOvEfGGtTOgwNUYLE9madW4tbaVpfdrQMNc2zUvOvda
lW9yRpEap1muv/ogZLmUW5Ri0oROvBDESLScUppDHh4GKLZZ8ko6Q8s2aa4L
IcIunBEwnLEzCwnXwL11JMvT/w4NaRejUV3Rn++nLctcVxbFz/+c7uW9HdO8
VnUruVES5gjWqMkywBYsiFSUVlgUFSX40FgRyqMDUhQxNiNe0CI+Zjz+qaha
PleFNljy+Kfo+bbr+rJuPCZBwi5o8acoYyGAg+9N+fUDrCahFSnWEwEeBy6R
pvYOp5VHGn9ngbEp6qUY+RsU8ukFhEgCctSQRgKPDLF3x4QBhRSDTHWZZS+m
gna2SIpty0TS0hahSM8zptQ5WqUPtgWJ2QiX3tLWkFwlaXpgZ7SnI2QsjYEc
nUfK+3RuC3AemFeyN+CfbgXbznGHRqcHf5vBIq3QO9BJwKg6sdI5EitmN4Fb
GpnvgoEpVtieBbDsFdSdAdOP8ksLHL2IfHDSKyP4MszsMCUllzan5ATp9Tyr
gvYCsBvLXbf3pCAIHiKhJywemuGF6q9iOnZaF+WfTHekVe4yz6jaLznCwSC5
fEVccRoB78SF3JQ5xS73TyNERTfAU3R0kyHwQnxtI5kftg4wsGsKpWCg/IB8
n3k5xin1V6nbgRqB3Q6l7xUOea3z3Cb7zio8d+bA0/kYei2JGcH28k/flP3V
bkUbbWeXHfAOa7bcPqqax99zTu6QBmYo0809EjmfsBhpN1Vi8Zt231huJ0G/
GptNFWPNpnZ3mUI6b20ES9pxK+WkBDglc2VXg00F7Ehjy7C7c+bxSJvOcnSg
VGhND9SMB8WJtfnCCHt2cS53NgdKwnmKlnAcx4MsUMwYiyKS0YfdVvqT/Xsb
VE5i/ndYVXfYPsmSfixg+xovAvInOs2psgOS9BjltGJf0k64rsSwhU4w2g1y
ZTLgdnRn68Qb0H3EkB5T7g9xCcRtIL0gCZdFryBJpkiglr4tKm01MY7aoSjx
mdHfPv/eOrp5PuckKBYsKBYtLEd4L1980GVqRXKbD9llDnHw8ByqAyIyQPSA
cOW5Ru64wErWseQllViNQAkN7KpXX5IQTc6K+kRBWCQR+7KtsMK2J3tCsKHc
/Bi+w0QEbEY6iyCMI7UN0whHTQuNnO6aVQS7u6MdrrUgSEyzyWggjpM8mgaF
XUMW98bERsuwHnRhRGasf+eHPubmkS5iYZzJXMR7hc+lkQZzGZPyPGreMkiW
H+tT1jGzAcJ1iy1VrtHy6d7XpIrj2Lo0x4q0rmN+4eOD8MyhmaT8ZiVR+maj
RS7Jg200vGhieYRSzXsdIpWQSQN4vx26RGyGUAjB8uyzatvScUWrrqZkMQW7
1YxCdla6QXkHqP0IsmFioSRijnkIAW1+hS6P6u+Dx/5Wf3v6l9cvkgtdIa6/
PxIdhEoUzS38G4POkzwx51M5kE6NNckkwgKRkIFif2yox3Rv9S1DNMxEDhQp
7YID0UG4HmVZj9yEOt8CFFyyDfMb2jAE81PZNOou09ic9BqAN8RBTEGTWvmR
KjKNescCSEdbHfW5cv4haskx4aBaJcC8WgOcOPaFcnwp4RHAV9SVpLKNJGWE
Qv3e9znLyv+iPO0YJTj+36/2X783mcvD+BiZOH3rbkLx3fbG3aTiamtQ0GYk
3JLkIvj6EQi68vxSu6VLCoqkrfewuEQQrZaR0CBB3g2cPVymEBOPJlW6IZ5m
bvpJscN0KGnpSORDIJqrbgMWPVyBfB1r1QdI//Egg2NRZoqyo4puen0HA7Op
sA8blWgR3q+fDCr7wDFtjfce/LGun8bmX7GOYZx7+sv9SR4GERNA241pBGGR
B3Me8pj2VcUy8scF7KPfWDMjdPeA7Th0iBQqNE4sFf5RqidJN02sopJoFoi2
vaRJH0cHUtTi/Kqu0HjauXItXpWedTvWRu5aVNi9b0cK9Zq8+o7NY2OGrinz
vmxvideNkHkjhZhGRha70lolEHFe4xjNE6XmaIGzevzSWBsXiY8pVMBVZ1LR
HIlclQbZ0uks8eOR68cHjzjMxg+TWukE8BeGj8Y1v+6R19ZyHcKeJtLRtFoI
wxMLUrs5V3gaZQEGZXNpIIPIwDtLSSiYum3EzLWKzqw3PR1FLuaRLpBnJNkv
sT70109EXwwxC2jSLFtGPDmrwfWJPEIbG/sAIhNZuHYlQZ5JAeklk6ooTGVt
yJS2IWslVXCVVOk0hPxA2xFxeRRpMdVYC63/Cgon1+4mXD+INC5CGTIm+d9Q
6lpabRDEYCE4L5whlaJ2RDiIrsSGPBJO0yjZKAyto54pZHdb+S7WMI3XLx1p
2VkUDw30abqoXas7GMaKNCQlKb6KM8DYOTHUho8xDJhXRBaJwKwUfuU3Ri6A
J0sCq63WWpEnl9l3WCE87zuB3kvtnrGvJQ6XkIC2FtZULD/+lo1UsQw9liL2
eSMYjwCWi768DIoHZnpMTKKpM9xYUk+nuaZoJRvEcpRAVtDxV8vZFKXR+RNT
nXTjocbDxMI9mtwcqQTV3HPZX2nRMMpktnwxt5sfNoeaabhyzzWNEYs1s1Z3
86UrcQ0+JiHOQmWcPaXM2nhYjFzfz6NJ238sfkd7D/p50uKD651f9HRlx4gA
m8AZ7tGlwtqsGUPfarXeHa7TSAulge/BE8xcDz4UO4u1JtG4InJYWSRkL2CF
6N/g+76kdXsKee8QdIWPyKw4YlfiBDSG8PFN4Jz2V/RPkQusg6jQN+aJxFdx
OXLOBGXlN0xblnZQSek8xWWyZfbAtUg3KjqH6QL6rPxKQYtlb09J9gLvjZQ6
WbYR64EkdNpK2yp8gKedM7oaC3TgRHvf6QbLFUpPdcOjgIEdq14mC0uIZGKb
N201QPXN73IwtQEyuhh/sDQCGblUN6ZJ04lsbl5Pb6fYrBpJnaaEwMaGh89I
s165YlDYmOfxEeZVCWVmC+mOizq+MY6pHK1FztGKAuvKw8eJV+s+tYQndlUb
DowbSTks2BNZ7QiMcQXsCTLHym9jXY9oW3pol9XYD+HV1/Tx1KPEERjaks2C
MV4enahovdMF8wjnZBf0lzuhJTJh1csYyhWFnF4NDyyI05MtfxB+tKim7KUS
EkloJrtaUJJ9ETD9OcSMG5uqPrlSW1B2YQwZV3QnvJ9IeatBsDBQogMnIlm7
cM0ePE4e7quqDeePyPz3yjbDglSjI2wkg9q0OLJku/nLPZ5lCNUS8Gw4byMe
lZUM2r8EPMUrPvtstIsCWImO7MoR4Egz7hgTsfwlXQU5zFn/7hUnLIqD18ba
L+GpJLvghvsnTpLuC2T4REBwV/WchPAgCxfc8kVA2p+DPLn6UjwKNFYIxkm2
Zwt/vgYbEAw15DvapoaZMsySDTtdktTwChBe2Jpe+QHTSWC0a9RldVxQm7vC
aqVsXNnTKUhJZjenNqb0NSJPV1/7yMgvPs5sR5bVGLldbt8hAmYc8vSIPMcw
MifHT0UdtyV7uIsxavCIPH/8MTg4NeO+k1ZMyvE8PRjbqljmJPAC1EohEpHB
fllNjgwwKmI76ax/sBjZ0VRLmkEKC6npcHRTdhVDELrkRVpoJzFda41tT4/x
ndFaOgOK6Lho/mHYEb2dLbHZtzqfqS6pO75VRdvzIoS4CAtpx6H+Fh5Yz0k7
UnJlguFWVS9Kbq2XPOgIwzhsz3WD6x10P7tu6jLgz0RZsIlOxy+IvqADfONo
M0WF2xpNEtZUG4MSxwftg2T3GOUeemstKGEUMuPJkJH3WOFBSIBxFRXiLmA+
L57RWJBpDeGrK25SR6/ddNw5Dd+NiNEQ/YxdnXgeyXFLC6y07Y12j8omka5E
pMyWBBLTvw+48IIj/39xkYHX0u1XD9hu7sIaQ6Hpw5EEjgRLhwANMiSPoZZ2
bUEMlFQQyW8uR8G8FWmiayZSWud3nWxKyis0pkUip5B0faO1arSOxAlK7CoS
kqrDhFGo6wen80HnVJNL2eGZpUXoPlZgs2t2Asnlth/0PPZ4lNdjd6Xm44ND
WhkvgUdm86j85GcoNp10Bzz28kgO1oMuuFJyLm/W0OCdB5WvTfswJE/FlEEV
3X7mwAX5vUGiNOIw4vh2xvWrnQLHrBQHl0vCkxkUfPQGMroyFRIYS7kUfzOf
GLzodROER4tt0lktVNqDQin7qSsrj4o4UAJDCfdZYumu6yoPHMQmIDV7Txjz
47svUhrT0o5XIxVUsbSNrupIQddEo4qaIuQ1pvjn8KJFw1bNXLedA+SX4OL5
AusJVYdSwCJjBEE7UXWxK5yTxFjCGnLkHn3Vm/OjBQ8TH5pAM9ICcVollfEi
SShmbAjCfyb1cKgJ30ePI54Cri900Te+IBNIOxve9BU7Jp6GgBXR6Qfi3lxz
ivsDs4SBtnd7blA6d9SJLRPWU7/mSKHY6vNu29QtYWA/ZVAo7xjOvG4kJyuu
jm1goIMKP8IjLKxzsvxFtvwuczJgUwvu0n1z9v1goal3IiJF+YEbN6lU6QaM
o+r9Nppr+ppTTZ8Up40inoof2kW1dA4bTvGZwS/0cCR42W1S1NuuregfR+XK
uGPBg23+WMGDAI5Gah4KrnnA4J2UsY4x6cOIpVkDSxZK6x9wHFMVrId7oBSn
7LfAp3tSswgy+MtsS178yenJs4NX7/c5u3wu/zSiDNDdlz2Bzuj7HHDD9+jl
jT+AY3mJbBtXK3UsdP+a6rLtawPDJW0IRxMj1DqQdkELb+PmYKBQzjrpVxkb
UyZSxI3NUj88FP5AY0Q9UC8rygjTkYAXELjXWEt3TseuzdQRjoZt+vfY2Iaj
hmyu0JN7GmsZDr+c4nrSULsN07idnJ5NDx99Pf326Q9ix+OSmYoYleon+yig
i40Azq2BnrK6hNGOz6kwaoSSmnvrPeC/EQTYzZqTe2ueZ4J1XhADkNx4m/56
02sjdE9NkrbpUCk8j/qPI7e3OZeM7/M5sSaI8Y5O31gYqY3e7u+SGFIfiwaE
Ap+uKt5LnjmlaTixRB6NNEmuFOIcpPkfxyO5CVq9oKwy+5HUnpA1cymRKqRW
G/XoYR99C0Icos/80vViISz0cFwC1AoLlO5p2lU08puKw77dAJUtwEbZ/gEP
JCxfa2XqW6kRaYg7L6vCCi6heRCp7jQQW7t2Bb4T8XLruSzoLokTpytcgKW6
apRUFvPixYICafyvab0QUunzCEE9Z/9f3s4HuuvaOashwuLqnCkRDr5PcI2d
VXPQbbckrxH1BjO6oj+BhFjcpBmtEeH1kUpE8ixJmiTaFRtZ8MXFg+S20qUL
OZj/DJJe99x7z6SYHqtBddhdSgJZISSics0UmG0t70Ys5ltzD9YC25ckr2uu
xtoLz58rs1G6qyBCRE6S+KBMTJdQeE1SqE+cKBWVsF0VQ+8JnxZhPvioYQoP
eaomGJ/kb7p9DffZUh2CEepWZeOKSpI3+5jRuiKpKbvkldZvPjGEYacF/EmR
Y5y5woqM9p0FK5VLg8NSFKnudULnlVklStqlNw8v9XW5XbblAu8wplvTdswG
unhec896phrFUfz6yfC6g7Ny22Z3XCc0R1wNUTCVKXFViIOrOymxZG4Uh2Dk
GYUFWaRaapkRyezomNCLZG7pAdDS18ABrTnekE3MvSWrbWorH7fy1aHK+O7N
96dyRR5+nVB3Pt7Xpi8X9YcqBq18U6cyxDPA8V+lYB856uk8usIdeg6F89si
t5cPCcsUz/l9WTh2TA5Gt5yXmfwwWhTZsU70AckVX2BH2vBmeVtu7zJxUKCl
z7NaO7nFJjwYjvNq4EFNBGfo7lg5/EagZqtYiqM41Bog0j9hNkbYZ7mfiGLz
beklEyI2gReceAkhkUKXclyUsRdzGs5wUxLwxNMrpJ7VThxOpl19BaVmuHM3
VShpIVPx8Pn3+0zmLO0v2JDmp+EX5C/6YtsRBiacjh4bmjMqfDPU/LgO6H15
423p8IA/yLk+zReCQSyxUylddZxqFwuEW6DMrzbNe1h8mr3lnWum3684ftgh
un+FZjv+PD6cAQDP7vJi4hkXdq4MP84J8J+owC+ZvR0B2DF8KzoxtOZ8Hf6C
0xG3CL81lVV9KPha/IT/7w+FuVAK4G0wBSof8gb/Qn/Sz6+XqPNRY/wBBqV/
LUFN6yOff49DPjlhPvt9G6GIRSWyn19lIiMdGe0aV9ROa5qUlLQwbsNmXRlE
XGpK+TdLMG43RM3roo3ZSrnWfQTUubt9n/uKyiTY5/bhb3HKx+lsndWfhOmE
EJRn7Pr7EY9r6nzhY3ws7qHpDS7Kdp0QScWScvkJDkymZWnWAwuGUX/nblbn
dw6LHpPc7v4lY1e6+k907LETLd1H9Bx7dqT/J9CEYxU6JrcIjh5CeZpEJvrb
Vreyxq7C3IqJ4LGxUenDUkOD0dbdl360TDGEXiSztcfLL5VMmUHmmzEfkDe6
GZSR/TYQrOIsAVslObQEkeOrTF3RJT05DwAmRAUudGZR0rRAjWBtWqQm1tP3
4GBIYq4pTskD5O5oaEZZ9ND3r0GtdQ/vcUL8wlbdzekWIweM33OdUK0EeJTS
6eNVwB1jE+HOXF33WwtRlbGcifZIOWE8Jh7HhG1WQfFo5nBcX5tFERzfOmwV
OyLJj+KG7Agpg9E0jLRlMM4IBObJ5XFrjd3DZ+zvSCvwLDmDTAsIVNQI3sNI
BiZcUh8LZmcWwlsXDXe1jTp3cs181NsZSqkmZ90tLQSYm2okWsWmwbM0RI7P
dVKfHphdJdrcDUZvXXxEipczTgp/ROGwvGq1c5G4nsK1AQJhiQU2cjVZjxM6
5iQI8lnqZJhuSEIbeLlfMaGqPrZjZj0ujWAef3NAJ0FK8KdSB4fAeEZzaYuh
YlhnH4KkSpUChzBXCY8Ne85qTJITlkXKwbQN1AwbpOC2GXcPGUXBWnY74Gci
W2/NHd08l6olsfFPvC2UqC6eiuGfdQa4YPx4iIVU43mXyaBacuhRoPkQ8o5K
Lm/A9KKukBaPXkKyx81DOADi87HsBxBhhWSGJXuirq3natFXBpIrynOIGekb
+A1vDoqKjNbuasJNnCDZYSq6ZW9kpFVLxn0yyKKwNgrOMc4SxFx/WPpDKdfr
wqkDbSUTtJWMJ3N9hwB4VMuFFmlJ8S5nKK3SS6jaA+iRRXs7HMo9OtjEBBwn
WKR+x1B5JdkVdBeDyKLnFKc1yhy9H2JgnOx4LIuidOQu+kQ2dhIPjC46ae6u
LWm47AcHVy3BE8BwZKTRE0gBVrQ4Fi8OamKUoZT7jAsi9dwOWtcoXCMmt3hp
Mebj2fV397MhG+GmXW44tDCUVnjZBRGuq0youqQ0GuoVPsKcOrIyZQkzRDCl
YvsuSBqIgvBiYH90xwGL5PF7M1TwzIEG+gWm8PoaDsCLrtsocJEyYB4YjrcA
WnujXTt+/WSw9+C3D/k81lUCxBzQhoy9JcSykwElgvYG2U16McZ18mSsD08C
ENVwhKpFQurByR+iSHckCoaZ5pMMSDbokJWaORnLc2IwSM4wRJK0EdFi6FJG
rYK7sCtwL/Rp5J3l6zxYVtKgfzl7/UpjU97wDkN7LyLL7zz3qOSoSlpJnSbG
aUQmAGMX4CsONHJeMP3TDsqXo7zgGZ9uBcJWbRwHhQW6j8vPHz15/PVsWpZP
vph+8eji0fTrr588npaPv/7mmy+rR4eHs8NYeXwZy5TR5S7X8ytOh/1JGQTG
uaJleWBHswpnDjf8538OYxfwt768dDQkP3ve6LwfwEca3U8Y8KO75r3kVpFk
Hts/9JRjR8ER95ceLm9PPt4d6g6q+P1LdgllctW7KJgIn15qLPNdK71q5dOE
BdqbF9Jwo/j7puunWmoZm3wj64B+kyKoQ3WIOqERkJMZO3yK/dIFzapl3XQi
RIAHbzlbWIdMWzIIiK0SuaI9SEZu3Il5v2EnZ7HEhBliriAEsw/Scxws2EJn
1kxMrLZkejJYwL2X9K89wajWsZ4mpDQLyvNSJDwvIn+wv0tOROe7PwnUvXdN
5SEf6rmCxXnClKDdMhQfm/giUcwRmS9ke8T5MPxaafMEYb/QDo0SVjaj56q+
RL9klJrGq/jE+ic7fjdljvA4xzpDJXPBJlWIj+NiZM7fxVSoWsFxCEFoWjrp
2c5+fEVkWfSk4/h66UpL5bHSO05deClrzb4bi/IVu+zZT6WuGgksRs0DKWVd
IN8W+lkIDlUm1JifGL+rDx5TY6ePMPi0mx5stik9NAwvww57MYPTedm05BV5
JJk4YSQzbNUK6SkXIVv1L5ny3M9FTG9GyaKcpqOjRnrojw2CJRktGlWtqnM+
qL50HWE0sZFEVZ5/DxoBbbV3RiD1NJbKRfKD4a3ICvUjJGocN2GdP5Z5Iv+X
6R9bOjzinkuRdZ5XMzdviLAHh/OuzmOWCVhgu9fKiAm6GBlUHRSyA5j2g2Zn
jAqttcYpTpfwdlT4gyCcIKmhWjm+8ypqoaNJVquXNo1W/9S0QSqsZwycqFnm
r1mXsXeNxqYOhx09nIByrr9ugm9FrjdRWuivxfDFFd67ZXye7WvwEx1JrKpz
2MZ21CNr5Lw5lgst0cPwl4RXorE2s7aqrFElLNNiNUB3baV9XBgaTkyA3KIm
TYHqZtzSVZ4lItD8OI/exJPyjRmSwvyQ27wDQ9L9dGhPRmwB2nZfzT//+otH
j76cLr4pD6eHh9WX09kF/HNezT+ff/P40bz6/L/BnrSWex/h6KEvsw95RsAf
Mj8pCDWiB8aMTU9rlMJaWC6Efd8jLCYuRMQfB5/BQXYktV5jASUe9WbYIUQe
//xfn73C3Tq3iZ+PsJxyCI40v9EkSfeJ+Dswwqou0BWAho2h3H5EajwuObDs
M8x6TOtreR6bR2xojOrVC63I7rhjnfyQ2qdIm2/WZTiScfMoXtOKt/XI3vFQ
zA78SqOMvIKeWy6C12oaadPoaeQpsIMJh/c0olcztSjcLSnjpBgRl5sSC3or
QTAFNmRHLG7MlSyoLsFBx0jj2vrGpipH4fdZ1dwf2zVo4YiLgCB2NxibbSnh
vi4xyrSmEBwRQ6wvETsXZHm2O8gcSbPRonFH+K0DaMncaU24DU5XSNtoeSqH
bgZ6TgkHKMBOYATptbeqyo5Sw4w1S8sr0dJ9iJGhHXGsfdLO7JWLiuQQ7Zjy
JO2f0B1TSc8ggCBhA7pwKQzMtIaYoXTAHDoCbBCnvk+GBDwhg4xIncQ2i2gl
x37hoTrCUBCv9exgRIcSrLJmgRyEmnXOGiC7ZM1DgqztT6JThHLZzlvsJt9T
+RVGkpzl5fWCjuRcfzSKAEs6W8LEnkuGb4CKmUg/0zhXhFdFgF945JK4YnkN
QIrL6qY0dzmOMIYKOHvk893DMAH3Omnb912xYds1DQaH8zzQcW4icFe8iOEk
2RTuxMhHu9tgJb6oXjWzoydrbu+AmuQY97TY+IuxwY1BefjJ8Aq99zySh8bn
yCd2IMZGYQYhgKl9W82mQ8N64jE/V7j6jdrFU+KL08hOxLbUyi+oiodM5NjY
S5Lb8VSw5FPFI3KKFQ9/qmbPTv5Kwccvvjn8+udJcfb83ZsJDhFGMClATg+k
BDfxCMLHBi6ccKmjYKvJz7jDbxgw0Lp+Htz+LPiDk+ieH9pFFPRZnuRD1Yn1
mAjRuNbkXK0RAFpA6nA8IOBsMSIv/hcWbw1P9wpfvLVyvQ4dALgUZuX8vYIv
Ez1/AZZFqDuuziEzw6nG9P1a7isxmBxul+tMT3Ax1Jt368yoK8OYLqT5P+iG
OtGpr2To/zMabPI/ob4mXlcNgwUjumpUT028ogoYFXg8ujL30D0CGeMBpcA2
d+SjZiP5JTnMYe2ROSW3kqcJClh+vMgHZJYDjsJpRu2oZ+qR8eFKMyHoSwqg
G9MSUhGO4LtTpoz3hFjtCmvuDkeZVLxmBg/Cl6Mz2lwjHltnPx05LrJ0w8MS
yXGkRXYUPvgNsd0UIFtwmRA7jFKFcavxMHIkKK7DkAkFsTNmeeWUlLU/SIC2
xufG5QsJidtI7iCFyLmofobIl449q/K92KxWyaDBD5MY5Obn4sjcxQ/WkJkb
jmC6VxpIuNA0xgcGNaEPjNoNI3+BAyxdRlqgabJEx8MTzelhbe3NR7KxleiE
Or5lHSGooH4a72TcgmoUikLXyZnim+PFQvL5g/ZqZWpMovLJgsxgcWfg6V0I
6RWnC8oGK5OTgijK0SYJFYK3WgScY9JyDvXfwZ/D4zHTBPtOUbhIJWioWQOa
NooBL4nLU8HPQp/MmtuivdJSx4PJguXPh3h0s9UmOTTdd9fm0slcjTPLyWGO
GDZ48C+HE1Yv+B8R9+v/z0CwDweIV/yRw5ju7+94/6Pd73+k73/0j7z/Uf5+
aeJkxT13gI7YGGSkH+V1U6WIteC2d5IakYcOA3gJaDMWHwR/trsiaTIZHw5b
POg1qWXGCILAErlYK03HNomhx/sGcSe3zUgpOLpsEojQyP+VEpV7MZOxgq6I
+B1WyWN5IUNaIq874+Dowqep+bsDm3vH0jKLv6QFZlzg5PF0co0R3YcUfAXh
cB6oqmKoqoZYsZ4Is5QIq+NoSwTNqq58+PYUQQynr56dPtsXzKzqu1Sr1l3E
JLu2EAyjFL4M0kQJyoKRhTnt1lF8rK/GwOtEtFZmeQTvJlcIxiUNr8hfouBj
SKK7aBwUXYn50OAaSf3lAfXK0GJOJxNNqexGyFMNMR5kRMUqfS0nqf1aYgoA
o+4hj7qzmF6A39Ni1EorjJWpmmJh9hQO0SOm8nKzLOEXWxUkcb24GNHC9475
ub3IktUuE2gF/8rprLkAvYAT3JKbVsjifY7OTADXWh/EvxAdMljqsZyHOD/f
DqVFRxVt2UeM7x2vXzM7kn/O5vdzy5Ts3EP/kEnBYYb4GNLlqpvcfTZW9u+L
OODXv4zfI6923yOv9B555e8QfBRCte+6Q17ld4iVeqCP8OfYtvTjOP9d14AM
xatYXxJw11UQQsSwOVaTIUR6vBLNGXwh2npqKLvfZfZXUkX74oLVCZhcITFl
FiPjmRgkBVswxxtGKzkonF36m1HgMkrlnDh5KiuJXXuSqH/VNmYQkjsFmg1L
BFxBXNm40XBoWiDGQ0+CIab8STkj7j7u96WwGWf1B0+eAndK2yycYcrMOXJ/
cTWmZoSwig/RKXCO5UhRSL1HN0nAJqNYH9AdMb9E/qv6BGVIuY4Go8EA9UUJ
BjnM90JSL3XG2o8nd8hekwgZd4e22xfRQv3IFRLQsBeGrULALjzopsaiKwGl
C9Ey2em8DsIoQpY6YhRzGhwJF70HJZrcxhea9+0TCL8UQwjtogq/z9Wkq+iE
hhWgE5ywQw2mJZ++AgBdLTBKVlq2gQBn5Btm4SLYPrO9fEAp48vCwoHWnCU9
zRrZTG6d0atF1InB4TFLWHBCiunY3AI6NiE7YOyyhPFQNGJd2eyUGpQol8as
5G5yegoSymmvzIwrUFJDKdp8kqPhg3UOs76VfsgOGT8prLbDfQHs4CD2c/S1
vLmLrYb4q29ZwI/wgymFI4hnp3j4+g1q/5OX+3R3r6vM+sRDD2YFtp6YI1zB
s34umExWdq7XrULcIIPMY+UqryaXVuLpi1wc8YzhYUHFyZyhF8yc7qoouJpL
SraLS6zGakrttLnaEEs5cWC7eqbg/HI9vu+r6jqxGguyGl8IJQgxgjWYu+Ig
MjWHCkkMNVqmd1JaedOfMo9BKJ6t0CVvKR2FLrNgrY0mPsWNe1cZE0OWY7NN
l6A0WEsOYJSTaQlM1rVi0qUBF+fuwMpLUIQ16kS6J+qUkqwMX29R2BVAU0Zz
2/cVpSyrPA7uOLUrYNq7qpXeXaXUZNS3yd/cmLOLBVF8OVA9RxKEqte+7t7Y
vsMLLutQn4zU5lTi91OntNYV8hqS5kOB9D0GPZ2u5KPHq7WY9j3LwT/QtFCg
dpx1Mygdd6mZ/FqwZAyBjbdsWARLyrsuGlGOYKSs/c2wxq97nSbs45HqxKYj
pJXakD2xhuIeeHsoKicK0PWGFssW1CsNNGa4cwL6PMFIlXolyYn2GCYj+iX7
4VIZVSRHkrpaZKgHJSRY0nbcZYSld2lE5jrnBPvqkjmHJDdSQaSmGF9BWbSM
q64yMizr42d2VzHl+WpxUsaeEBIrruyM3q3umAz5eo0BYoO3FkPti8TU4jhK
5H5VLghLQskx9PAW06t2buQQQh3VjUZdHhC3COYF8bbHva5jMDEvGWTi56Ad
SuD+iOlXDbuPX3YYVUyq88yKUIPPov0gJfDt6RLMpGXqCjHAiSFISgM5LO4j
BJ60H0hj9aOAzQkHw7JA3cxR8Wd3hQRNsKSeHGQWCG7wETisztZnTFug3C3p
ce2x0yRkIS6JQEOEVVtNEdndXCc9vIYiq+1AKzn0Y4jox96BMD0CsrgXAjKU
o02cywTAtau5sNxblCDEOKUcCOwFsuAsLwO4jTpoF7Y0OACm0yV01mG9rJmE
LCY5D7fVEpuF4kIsclNEDlHP3bGROKDmTm4krZxT9KlP9Olv2veV+Hm6lh8D
DI8LndayhrI4P/vu5O3pLz++ov99lvn/IsDnnyVsUufWutA0S2cQoDxC/esn
2QBGw6+d+Ag8/buC3C7OwPHs0VLqiSf48f6syzAYH3jSB1ub9DoglfN7kwS6
QDP6VraAepyBK6j5aZIHX8KDftzd+Tup+MHmhvb1c9+N0TivuDy326FtpJIF
1IcWyr5BKrxjFF2UGZLXZFOtkTbFI3LNJhXeyezx70fiUHJuqRdw09vTf/3x
BUgT0vAJY5hnXRyBU038zwrmXmnbiRT5pTgFB8i8J6ABW1TdRAarYZZWgoOD
HF2X3C7BxF4UdDRaONWW4HIYJshhDzGLtKwLw9/DSP6A/fRAUL2jRcPYfYkm
pffluYcPnxcPcUJG8BwM+hPlel+y1nBHXxuPboZke3dVpeBvBMoZJIf4FLm6
Amt5lnr5jMBntJx8ElY1NhbGpbhqb0Xtu8LsCKlIeKGsgdUBxQ8pQTGK2euE
WmXkPqG+ZaREyyDp05FLSbvXeB/3NrlEfPAqtE3hr4Z4g1jvRvGlKFHRD2Gr
B+FOIgHN6JmhqwX+zrSgqqFB1xOuzPQrs0LpXFixtVLK+/oEj/gRJuORKhKF
AGk1Sdh9//Lk3hhUgplQ8UjUaF7G0gCwsJfWDy8jOnftGi3pbIb1tXt2q01i
LG41KPLl6GxVLbrCtVhxz8CNT5qv9NTG94qivWj2Wd5Uo4cIrF2Aml1g8IEt
QcpOqO49UyGtySvhK5OlwhlqQiMYE0LnKyx4rD6wjwT3zPuqQSQ+oubFAiTg
anbUtIleWjKC3hE3rlu08w36hp6bG7kYsNgV9aiY6pFjwaIPYkj6K23Ysc8O
MNMHptgv3kPB+o8QTj2URk9wrpH1JSQFq+61zCnFFdkSY4sLiRmIyG/A7WyV
5i252QUW3RkRrN7K3iCgih9+YOg2YJtzmCspDe/H1ksJ2XWvKGjg+lpKv2ts
N+4Mdw6gJp7DJTlz5lFa4Gfgfkw0lGEWfqeNO502arZBKXrx1kysALz8eS+S
o55RoZATHC/hwcxhkJxFvtzU3ZVxC4qPNAp1orpQfAT6v3b6NMk+VWCmlC0m
nu1tm+SKCLpOzsddTnhEMxKePb0ophyAc2l6CipEGR+w/uc0Vg5W6KM+CTqL
mgBpX4ZYJ177k+LNw8ig5uvCJ0w5a0lJV9Ia67RG+YICOauYEo4Cp3kdKqkh
IhbOLaSmolwMHykexS5IAzuSihGI5t43FBtIEPpVxqJM2zegdefpcvihH9gb
eUvLMBRSYoWO2YN5e9nUkkYZUTWYjHrfGBpFzTBu8e3cNFoMqhCoeyZPuC23
GlPGMlTrSq8WCRUvOSmhpjDUNw0upbIhSmbkZqPi4rz1EVfQY3eReW82gmBG
x3stUujSGrMixoH3i03/n8b6tIJO6saomBK1kLjwCaMGlVuPIJLUXRhyLbEH
GMY9wFjxOPRSOPqWQc4mDqvdkttzp8FfU0QEs3uNXFshZRgaZxL5Z+iX4F5a
OxAo68nYsxXEzmu0AIvltLkRrsegjbOW2YVIvHpOg3AbMYrlXnN4Ja1XIJdu
UGFpB+P3lEIalQf6tfhDzAbxJ+bu0p+jn8sf0inBT8plPa/+NF47uQeH8h7f
+gfLP/cQDIm/wHDrukbDaUqMiX25tgeTawVf4lpT+wklRaS+c++2mi3KG/sS
/AW09l0PHq8JRaeHj9FUXSv68I/xN86YxSrYPSzV25sguQnYn3s/W+3obzT8
uOdxAv8w9coeNtbmyWMHgtWy0w/0n27+7D7jd7G5wqMnX2JzhVja+lvCozIQ
TdQcmrYU+BQHG7LwUUiUh2Kd1cHFLlmzjqzhJCFNORjTDwdITida1WXntqtV
hUQUhUuVljegvSmoj5cuBpPRICZMQpDmd7FzVmyuFJ8AimVJysF1gUJ9tObo
CRszPNFkMmJJHIVpBgK3SAkOKk4wcur7QERAzsVI3/8bPo339FyAFbMqBqZ0
U8/xa4ozVvRwxspsqWu/xlEDU4Xnzi4gdPmwdryDZ7xAnvGwg2f8CMbrmnjs
geV0ngjeObGane89/e4E/r9Hn0/fvH75b4ePP39iQTeWO84+pBT/ddrOFLae
tmmsMh69ubpb7eA/ddynCL43bAClYjRZk3HpDhHcBzkNaxA2GUvz/aN8UISk
EbRJvR6BUERCDKZ1c8QcB56h9TUqbasQYiPM09z3hO3hgl3ceosLh9RhgcsX
G+aOuzMFnaVa0ARqool/LfexWssUFL/imtdlRT9nXxtbjN6iZUg2lcWfrfXT
MMo0tHUwfE8uzTz1q6TsPul7UJI/6rxxpBPB/DGO8CQy9XB0nTKhU/hoWiYf
SZw9+z6OBvNta4y1jPSseUxwhYvNEo7hkjEuNBlJHFMP9Rj6PvLhO+bv28yW
NQF0S/lN8O3Yy76nqmz8mTZYU++wv7JiwbyohWQtdNpiHY9OzMLxw8oO1LCP
VHIqXem2mlY6/HFpN7+aVT6PSSi569gk1IQPD2xTYVU6ZRf/ysX5hM21AHM4
8e3b2cBWahGt5nflTSdngjS2Xs8Oxo1nFOyuKR4gNBYHZdHn/wIS9wYD0X/8
DLQvactrWeI8N1OpJZ6Uq8aFyunHqAndu5dnrgaQ6cZQ/rkHOyNgd3a9l/5/
VDnjIlExZ/WXn74/o69/9eTwq5+PwzRPzAxHGTs2oPetWSmUFjwwOEi3+rel
UXDytZDlzbMO9Sp3Mlf+3VpQjdzWbrE4ps4bniCnx9PQcXzQXXmSCcL/zIbk
t/GYEhs8cfe1KOEsrJ4t9tw+5GpGyfm+rMqLV4RDIRWCfY9bTG1JtxrJXzC3
DfU9GJz5cPg59vXCttdCWyrr6wZmMkVJIhYDufxEvChjjve31uZN5wljAd3i
1J90N1aFz0HV81bFagPfNFSVkPEqxI/kiaByOG0gl7b/uhGuLrkHRmGyTeuM
m4pyrfyWUb5RHMo583THruPpTGDZbrT1ZRVEa5iagyXETCExj9mxqIScIoZp
VYEu6JgchzJ/CQcSqPKFO77ibXVpZCH62hvXzxSNRpbXuBKoVk3IdoqhIB5C
GN4UT6gVqgEnSn9a2Up0eg90HXrs0k8G1lKLw+A/neOvidbI0OCwaxyv2RBw
mc6Xa+5lT+wyxUF6FA770UBMkpa8DaE4ySQnPzsOPdMtSdqunIG2xPAwGR/W
WTV2w8XABoWcWUyxA7rrKiLjmcp54qgWJRKNKkUDO/KwYEALt5UHMENmFvMc
87i//ESl1uHvvMF+7norcqN6t1p8oo2s3W2pUKNyXMnipk6VasY5uYONgUc6
z8gSSWRcm/nGDudgf2sHXVxTtLpc8j0Z3NS9SKBCZaOd3agB3A6ZZXYZ2PcN
wpM15OJtC0p2N/MrKiQHgSEHjjsi0Zet9FWkztcx0HYjUIA31S7RCJERi5mK
myOwkanQYuDSiB5xPBhv5SxcIDtWW4nCzv9FWPbR2ZQQKQ8Sg1AagItqiY3v
F+BOxCkHT+10uXar4gOHeSH2yD0i/ZEdwfONawUsKZksA0O4ArLe0syj0YER
iEYugrT58Ls4Sz5zfIGIwpW7nTjZXApUCYHhttpO9PrA94uCIWsXrusQVQAR
AaW6g4w3Mc+iNpOGyCf/lkGWqqk+jMJ1tAT+DjgfWnHBW3GZ7ubyenJi4qO5
Wkdix7Oqgc2FCQZmpIyXijfGBUqVtv5j6kiicBSSxVr4MD3yNa4iwfaWjGNL
Lhj61qYTTmk2smOfAYyjU4BS+lrjr5MVTn9OSjkaBLjN3mwHIZ2/L9w9wLde
vVLCgXihSLw/pLMWOS3Bclqz40h5Bdz5xPWxDbA+0Enmv9/tcEk/ACMRfOrL
9Pg5Ot/4vHbTE+8LGQpXGM/i5Yad+JFrTK5aq3uIdFuR+HC0v6gU1YqlKnnt
OTXTKnJzo066VUmuKuEwCcahAuOdg3YbJX5hZNg4mRVCxHYYjcylyTOXhsDv
srVI4EAvkE+mQY3lv5HEt1BvPX7y5NHPUrsEM6rFI2WUdsTFch94jLTxyaZP
PDMaxSQ055LUMlDiR9IiEfqU8ZWFE5J4/afFFYcBkgmfAG5yCqonFnkuuBTa
8pQVRoqEIM6k3nxoSV9ipKBd1//hKkxrLK55R9+hc4iGF0sCcfRc8CVOHo9s
OEY8tiCwK6Qvjx4GTMvpWyVCsWadmC4lQ2rNBpx1SRLhV70Ho0mOCKrguNyF
nCb9Vd1cIOmbtNvKjk6g3rfWOyCNAIPn3qB2AqUotTa0yVHrVNzC54ajmetW
HfYiAfuZua8N9gTEC6oClvz9hA2hLQoDqhhlCppwDpUCj5JC1QYEqLnQDSc/
e+CPyMKiZSKhI5pp1AEDeFk+c7uBOBoWFyFbEpyMzpzRwz2fbayvUWOmpcas
K8PBS7lSYB40v28XilfjI0UFCBWt2VKU+8p6C0hfjATPD5cuuDtw9ay4uaWh
7MDFX1Z6J8eCKYS9IATCcWa1a2l9YJF6qt4WJBRcK6trcuaEe6WJnWWlfEXg
aesYya4+XJVYkECRV7d6U1m5ZVTrWK2FfcT8ZcPlOwrk40BHv+V7HjFAdPA1
V4jbFuQE91yvLag7EXl8TnaGFy0VBLR8uDk4QPVVgseRZCJ7xGLjJUpCQrc+
xv1M42N6xUkQ113bKpqy0lR2ijLhevVqlI3FgUnf6UQswCeYKK4ALGXwcuds
timPI+XaSe1yub1SW0tHaD2C8EFfEsGh74oaqJ92lXRD4hICHQh52NzuQbad
8mydCPuleInUh1Pf7XtZDyLc3hxaz+qeIGTio00C7jUZCI1fLZoIyNtyOewd
UnADFrT4WkEfX2M/le5ujjmvbd3JJBY28eF8h85mkQMzHWtLh5XooovcAcuA
m0GNnlckjSOjKqjIQUD9niDNzGDx+VOjoqD+650UlAokKLF5KKhvoC0EgTAG
TttmS4jW59doBWCDb8v1Ykp7Pme+EXhTP40379T606D7WjFK0LdyPMY4+jIj
ZIDT7xZdK3T16NJNhTl7DjyPFEuzb2qHk6ALwpibd2RMV9KRq9L2soCjm4k/
NUAVGYmseAmwug6iQSm0qFucigAcCKNtz/WzwjUPYpE7+cSUizZmUDF8hJJ0
xrxGKPrcYoTQEtgG2M+IfCuu15PjtN5aK2bmmpACxbcRDYrkkr7ZgTCe8cDE
wWC/04wns2+PcXLmQFSUUEV4m+UBFZO2pqauBKvSDCiS5ZBTRoo0CXH5Vs3q
x3boLJdLd0Sm5q4Ea4fk73gsmr2NjWklUajIDvggLarjh3TZaUN0tAPZ2Myx
JF76CPJZEFO5pl6JqyGkGdQg3KItbUns1dRexLAGK1FsWivt7ulOva3gZmQI
Lh6/Qo8fb6c2mmKiFHjJG/Rr5wVS6MBWv69Ccgd4suXRiAZfAQMuguBCVa72
nC60sYLlnT6mXn/OM6PjpYqaJEXvNdjLRkjrO75QQVQ+/fSv9ZpKmp9yZdXB
p59SvvN0xWQw+ndmok+/bMnewDeX2C3M1ka3EBI4yLlNf5o7qMSUIRSevZVj
Rs3Gxyh9RvRnpNyUTJmAOnEr8oNZfSmgPBh2RqYIEnt3DFNqZm1JWto6DE54
TlO6FamHPbFsS/5WGFSmcf0FIMtCABcmKX0WeE+qIwVSot5TnxTd9b/VVX+B
wIfpDU9ZrrTuZ9ozT+FwQxE8Pnm4ef4zkY/8FArIyx3GAZXdCOt25rpy6Yzk
O5T7P0ZQlGuIlGi75oAWhRrjttdd7ArAlfHvB4W5gn1Ia6nJO4od26Vo0xMx
UuTTTVBMx2Qdjjh+LBW/4a6KXzSPkmu/3131G+6o+uVAMyPjutFKaLztlgtH
9iLGD8b15iXl93wJdDdQvJqCIgJbwQNpwe2g3FbSf57k4BIUlybLSriFzN2n
G0bqgEkK390q87Z6IQXCddekQwYM1TmUUuvaA+ey1YnBm+62TaSPH8pB57Fy
RB/XVbbkAZv2pVSzthzEpBxgKkaTkIZHEGuS/irlkOPaAOsfFXJG+UgPf5Wz
8tKMGJ59LObyyFzs9C6qi6qhJih4X2MJKFUqq/WBQcSkMiqjTefbA1eVV5Kd
IHRwLqsjq8zRPvVWf6TMOOju/p3YBbQYV2v6hZlIbKSx8lBp4dhfDRDwXCfF
HPeWPL+92vpDq+W5gpWV2rq76kkFduuAdU7uPHnRaC2rBFgphiyGo0jmrkoW
OZs7CRrQDswJagwnHmwptIIjNlyLRRyRCo+1SBjty4PDkOePLfSwSQPRpyyw
zihGhMloBPW+3NL5do2FjO8GTvZbqdYaW0Jpq+jat3AAwDHk7uzlIpVoY81c
dKV2FYEhPjqjU0Do3wfSs4uhVX/kDe17tYugDGzOZEJ1UvIS6Se2tWYQFng4
TlLXRmvLdTlgjjICRFgeZPS+1q9caLcIukIIpS99qrOyLN+0alBv6GmXHLF5
FhrKC+ZrOHjci4CjeDRivHCXNciilHXom6ai13qzikmOUJEu8raiYz3DULqy
Fp3BB4QkU7qzI2hCe9RHDKL1Oh9IiUVhrLlfV7k4T9KsL9xHThQylh7Czqh8
uNzY0YTRPH9HV1E2u3JB9J38FDmZ9d51OEzLGUv3PuWmm/hFG+v2Xrhu7xfU
oDcyZFrTGF/J0ElVAdXjLEga4mPzHru4/R/py+yKbEbepRyOtj8jiydnJsiZ
wbvsXt2RiYFkLSU1SO1EOonGl/ZkjvzeOjsK8AtZeNYdLdzxwrSP2V2OKz5o
sRHjSvxQWVKhKtIexubhKuJJmyXyaNL1lAxAKmqurXK6Ym7gYNa3aId00nc7
2shK5I3GoZjIvrnzoKFzoIbOfBsJbAP3AJYdheWOSCgqOkSgUuCGK3w1EFpU
qLsavm3hfr8APUT/rWiWpBENyxFXJoOXQfazhS04Fm8B1eXocLIAa3ABVg7A
47sGsW5c+gYOQ7t+b8H+TvWV5oY1tNC3Cgqyw4I+JaWrxEBET3XqE+Axxzx2
l4xkrxXHJbCmpA64CvxoxO1L1d3YCdbi2y62piKc8DWmKjqMm7WIQWe9JfdV
g5eUIvPMVBU4L4mH5PUFVdAbCVhW6qt+VLJfKh9oLmCcciOACu4JakSVGgIn
hSL/TY+UknW2YMeECbMxs3VdXWDqFOtqeRSRNmdhBJZY0EpTZx+fgldTDqmY
MkGxf7YR1nj8IW2wDU/7wCdKrrtTw/mMk5YL061HmCCUjT5oAX3dNHFu2VpQ
PbpGdSXylsTcwpjqwiVS1XU8Aqg6/CIiAKlHIz+S8X+shhZmtUq9s1sur/Jq
BmzQNeKsl4T2gG4rSetId3VdWqFlpL15WyEsSFXQmv7lO0JhiQv+DS3zJWZ0
ygS5IuIV1Ogiz+2BCjDdztzZwoNp1Lp3CD9Dk0YUqZb8Sr4N3WW5mOSUEA3X
DdkqElMUgLmjPksxrQ+6yGBIp7W8C4cSdFdtYtlF5pCUTVtEHBNHmEKMMDlr
yuutLsF8lbr6wt4t7fh0KcmlTRl5qNef5iErH/GRgXJr2KDW9J2lrvZ6pYpf
kKFCFgihR0lcGIWBCr7RZITygqEF1sy3FHXVaJGBFXs4N3mWpWJSB5rurZTS
jqBOO3YW6Il4c2X+RQYfkwNmpJepqOix8gFDGbfEzQex7MzUoOcFn3ZEEm4u
qdcI4jWn4YzmkS8KQtDZ31K1NlFTjINTYuR0K7xqpby+vGnrBd++uM8c13B4
ImFjF64WnjZmNS5AjzeK7SI7gHujcDG7VfxnCbvCJ+wwdEOTH0JnhVMNA3S4
xXFP5/F2ZWPZe0nqOHoL6A2WJA6V5pODR5NBITdZbkyNUjoTWUL3cmtrlaB0
A3ct/KipC6zIHf67gSqdHUlACHr1zHdrZetvJFyR1OWLveH60QdfNk5L9FqW
wwLDz840h6ErZfgUlxPjHkyYLcH8+jTtT64J/SO7xvHCVgKCmacdxasyCJEo
WxiOH0HpoO7V7jzkfi03xwFrJRmbC7tw72+OElAycHONLrfe+qKxnp2x2mY7
FMN2CQDCp4ikOxo6uiGiZNBGtZ6c4gNdVSuKHKABAobUNmIW8KOJA2AEKzBB
3z2BzY2Uhx1+efDNvtyxYEpQLFVYoOeGqWZtuc6/oAQOtULkwYBjPckNbUCK
lI/yzdn3sdoJ3XrlZbmoKRfJ7dGNTDupdZB98796W72AoXgOxYRcOtAdsr4p
1aHnoWvkypUZYKyV23WmtOS4IWNDtCQ73aj8DJibGUJ5CVxpT8kr4FDIcYO8
OShPh4N7Vf8dPZDIdEfEyZcEDkh3gfbuO82XmtKap8Fx0l2qEJNSAiWJQy+S
s69yHGhOPDqnwPHrN3VXC8iqt3ohSV9I8xMUSteYESkFahRdNJlICL96AkKI
4I3Vinz1qAfDVT4ZCqVdYd51JIdLib1YtGY1nLmDdzzQSC5Lz3FZ+3XJuBIa
mnCFuspEi91GcIE/9gTvQl6R6BnB9ruRg56/LbdHg5CVQJOSvk0GBelc85bU
IiLjJmVC6dTXGeEz5U0z4KgBedq8JFnhVHT1tl2cNzNnc99TfhTK9mJDcBm1
4sTG4ejZWAfh4uE7FAx40M66w30Fs3SM7dowbZFCa8RtoOGPRTf13ueSfI85
5CpgCbHFICbogvRGcPGzZP8WYrlUzWalkQn1TTwcgYp9wKgyaLErUvR9SxTa
mOTDnjLPrj0kESfz/mOOM24e/leXYHEzRRNUAdkhYvDUDRWwo2uVwTA8HO40
DlwzVgT4Hwlq4A0YHRFdLWaKt+IqJC0l0zNBO7FSN7zfcPExyGDjJ7ScVQdw
bVHZ2K3EaOY5ghQEaMMwcanxI8WwqFCLHJn1hpEzhwGil/tFpoYUGFBWnmCY
R1KpPtFDOGT1wh+74ycVE5z4lcAOF0Bheo1/XC2UEksKyQyJ2bTNdoUBBjfQ
dh1AXy6qxsNGEd4KCkrRLdlxx2cmCMoqMkw6r90XMAgavlyi73t5laHYDDsV
hkKhGF4D6Y5qiPudfsdP5Zw/arCh1U96OGPMTE/a6O0MzmjGx5AcyEGYi+9+
hSDeOJuVoKR0FZvYlGw4U9qfDUjNJ7umNC41QVRXK+TBoShSxBzjhm2ampgi
ya1Uj05PE9qZsBNxAiEJk6IsHPMJ0issro+rAh3GNwPXT1mQwrvDtAVvdrhp
uA9ZeFu80QS9ooVxdLfEWM0F+zaYzMpdPBQMa/WWOYnBnMRx8/fLfdfMTijE
6DSwU6FJcRetnEWe7JRT2rJvBltR4BLOXItlQG601IqYyKK7pvE1F9B3gtVQ
GcOEaXEGM/nm4BFDelxNO907eHjWMJxfxPHcCLOwmBsp/sKw6TPtMATbHX3H
+EXrkMePWejUtazW4FE+pKbzbJtqSqFB+A5m+imSTpGNwGqY9B0hI1CHglZw
T2Z8DccRBDzM4QSkQE65KdaG44efjO/+17j7Sa6FtzaU/p3WBUBqdXQr8CRr
BTqi1ijM6X6o7AMioO99XYFkGZI+LLSKWAiWmxZGR0ZDtNgbBe3Rfjorvj19
ZymxMOR1GNabOH4HNw0rD6MJcdxWnX2OaKVADXTdr9oItriz8tECRJt8ilQW
9mMsKrLCsjNf4dIJ1DYte0kDqYwUwdYFT5E1DCd+Fa1+5q6mc8Ergi97SVn0
MxdLki+rwOys2Qm2hiwLfzl7/Qrc4hkBy/gvP30PT+67SI8h/DaqlUIGRqQb
h8ztZOYSSMK6lgxUKVVQdltrEE2nwy2n2f4ZAB/VOgw7PDQmBsVXYwlC9mYW
rwzPmoY62YpqFfSJXTZ3ozCL3SjMpGt00DJ9bmw0UgmFrIwfpZViMXAIdfsu
JwMJaboqG9jyFQd6B6hRo6WiJXKm0MiYDP5ihfDKuhRwNPGClfNQvDh5dZIV
VnLNDhoVp6LVQUvOqqUQdzH0Bw7f3jmrSW++oEyCV0wODpmiogSNA2xdXWIE
aR1/t5e86SW+qdsL/D2kHZYFhW+P6NavDr6exBMPgrmsO0NABtElvn1l7Enu
X0t8D/RqYaCLk4QP3qqbjp2YXtEfmJSpOmJHQKmRHVGV2nFSBwhjPUfG4gs1
tLmR47mbXkgsvnusmD4YaRC7vUJXLHxsxR7TbP+KVgGM/8/P4B+vSqz/Hxkg
fCYK6WG3f1R8+/T3L0dkKEp7ROCoCyEJHp8mqNGUhS+baSIb3C9AILH8c9PP
gfTzQ/jKPjY0EHq8PWEN547RRVH8nz8M/+//7Phv+jf+6D+LwRDhb2dUO1rQ
57Y8/O9/4k0YJf/p9OXT1z+cSmNPfLrW8fxnuvr8Jv7Rm7ev37w+O3n5u37E
8fji973J5RDu/6O3p395/eLVvd/0+1fP+CCjMFZIVXznKYstRVjuxnXSXXJX
RLkLA7nTKILNrVZabB4JRdoS5Y7gLHqDIzxVom0Y4Q5B3iFLcWb3ENEdz3Ax
h49v1L13pb6HXpDhv+G6rf+Zvam2AvLijI46osrIOqH/gstlj+OPe113tWd2
nSEzd2zWsWAv1hXj9yPvmif1V9RSRynEmRSdSCtVrgZCLCBLSaxKDbYNaQc2
pv982FVVMQI35kl3la6lvEscVa48F7SJzPEB4QGSr+/WpncKw51ipoV4ply9
6L6xBY//dy+d+4+PB7lG/cuSY8DSMSlYNiYFSMUu1XfB1D3/5HP+W+b1zxzF
WDsYzojy9R+5ou88jmNCdS8dR8P5fdruPs9FC/H68voeGpC/C87G79KW99Gb
YLvT6r3oOnDH1WcVKw8NYQJPU3s9DneA0sBvKmEptxHUEBMDBQKH5NVbnhaf
fnrWg4Kg9JPAqS1WML/aNP+vsmtbahwHou/6CtU8MVu5TwYG9imBgeGSmSlg
l4dUqlaOnUthYsqOSbFfv326JVmGsJAXiCux1S23pFb30WkkD3kHFO4ryHJw
xBUghS03M1VQVdvVFUiJkmAaw6wnhDJqK6GMiy675bHevMs7MAOJkJtX6eqw
/Kfkq6Wmi8OesbW2WPUt6R7a+K9pC1sBVavCw2jVfYtt20cQFSHMeasYQt7/
BobcYtcKToLbmrIuqiuHiHwNLKl7+go37eVdokKFiZtRYizykczmAVgRySWo
CuT4mk8AI8uV8ZWes9Fc1Cign1nmCLEaXHjWOlfom+GONYZc5XZo3NxRABd3
BT8Eo8SBaQ/aMCsPLlW+zCVOiyJhLue2jZ4bruwQUCrPmJPD48bqYuNETU1o
1HhyAdktwGA+IfesQ46ehgpfrjdzwVYGTTkPUPCvOFQaOywWCf2nWr8LS3QP
oNEdmem9vEevDwBIKoCwBhDuyJf0aDkEoWRpMMFfkA2tDGOtfKcpW8yjLJJZ
mXosjq3byaGFY1vR+Y2piVFANrXGw9MWzXWOk8O0AqchvSNv9/z77akGjoe0
YuIZZt5AXd3ESPgvMb6s+dMy2SiLPLITw+vJj3tpnlkeB9oyS1QYeQImN6pO
Xou8acYjRkL3fi0EZ/vg97k+W65/lBEipxmNkCy3pbTvspwPbInJ/G116nTU
H/qU33f9B1Zpci3j7HFd4ZPwPmq/lKefV4WkbsrI2ZNvpYdWspCDtEZ5JjxJ
Na58e8AS1ndj60qsaJHyTzzwJFe2ElgN0CVhpWvrBNjiIT4soKsot4mNZMVB
vlJ7gvcgnB/CKF57U8y5gPf17r6rdyioZXH2d+97HVGMAEbzSihHuu+4has1
/p/A2a9kp+fUaEzrPcPDxnsnBWv4U/KnT0ntC+n5q4zcX8xaDX3WAikUDVXw
U49aQ7ocmvkiosGKa+7gn3xunS/1pzG8B1WFRyZ7i/X6sThqt8OxhVgpamG0
ScR2nJvZusnhU3g18C2aXDWjSUvbov35U0PBNKEWeeVzYYZ23GrNE9wNTtg3
4696kG4Sku+ChL/MFlGe3dMHuhhNR8s05eFAiqkR8k7Tf5/vvWbXWcT0WNes
GdYNGzBWNmD8Ae0W64c0VHGLhM1O9yNKAoT3zmMsN26v2z2c6GFu4hWgGTcs
PjJfG3pVhSNpQlv0Y15Azu1KxrTLlnhAX4FF+cM65rMp2oUmI0Tkdffw8MAK
1N/vf5uQFdGsXhTobxEJk+CQZtXufoP/f+lJKgKf9/v6hNpTtA3ImEFzBznQ
HMmhf03XeIOq1+nsW0k4jQF7BsZmREbwaRwmPtTexd3l5x2awvPQ1Mg8616n
+9U286170KeBlCwjA+OCsgPaaM8dy+tf5KDlUywoTwWNt429kDei0Y/IBmJK
jt9T3EmCJgNJXNdLjH9octb4GgOYJpC5eTIrGQVXS+wDh2Lxd1kWN/RxSw9Y
5h/PUb6MLbaOc6fVrmyHToIMsIvTJMpLsLD0Or1ejce5Jl9S5nFW0iaLx2Uw
Ckk5DNipsaP51wNt6Rrqe8uiAher5hn1WMaaOQN7M1e2RwOadoV2o7+LOiQy
evqiTFmVL5UqXagyvX+AhAPIjhNqOaSVROVjlq+e3VQZJuaqYxm7GDpahCSu
Y8nSe323hM22T/GecfI6KWhtTMlAbQdeZsLuKPZ6Vi6BM1wlMmHc5ZJMhX3e
whPmYxw2D1jP9OygACSBAsPj3/qg11C2SzuuS/tkOhN9UpKjbMqUjOCqFXae
z1ZYGWkQn1RngNVAED2SAlZ2AabLXaYSEkDeNfn7JJgfVpxifGWqQZc68+SP
56t5+WR43kNP41TWtKEGHzXSQZDh3MU8SEgIP3jMlyls4yu7AoMpIJ5pEkty
0LnSfHwwKpdplRF/GUh5wdkoMUzm5CptudLKa3WUlHyuhde27IVfUvlrM3/6
Y3zDICQEFm5pU6AHc2yDJ+NibSYqLJ095q9P6Ub+solH2DAQDmm4LfyYvHS4
nPIj8i9AiuM/H2nXl5vNplW4plvU1Ys2/3nhjdh7ubH/vfkRi7h5KNr4qVLN
ZlNj66T+A22HAseomwEA

-->

</rfc>