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

 <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>
<?rfc docmapping="yes"?> "rfc2629-xhtml.ent">

 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-suit-architecture-16" category="info"> number="9019" obsoletes="" updates="" submissionType="IETF" category="info" consensus="true" xml:lang="en" tocInclude="true"
 sortRefs="true" symRefs="true" version="3">

   <front>
     <title abbrev="A abbrev="IoT Firmware Update Architecture for IoT">A Architecture">A Firmware Update Architecture for Internet of Things</title>
     <seriesInfo name="RFC" value="9019"/>
     <author initials="B." surname="Moran" fullname="Brendan Moran">
       <organization>Arm Limited</organization>
       <address>
	 <email>Brendan.Moran@arm.com</email>
       </address>
     </author>
     <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
       <organization>Arm Limited</organization>
       <address>
	 <email>hannes.tschofenig@arm.com</email>
       </address>
     </author>
     <author initials="D." surname="Brown" fullname="David Brown">
       <organization>Linaro</organization>
       <address>
	 <email>david.brown@linaro.org</email>
       </address>
     </author>
     <author initials="M." surname="Meriac" fullname="Milosch Meriac">
       <organization>Consultant</organization>
       <address>
	 <email>milosch@meriac.com</email>
       </address>
     </author>
     <date year="2021" month="January" day="27"/> month="April"/>
     <area>Security</area>
     <workgroup>SUIT</workgroup>
    <keyword>Internet-Draft</keyword>

 <keyword>IoT</keyword>
 <keyword>update</keyword>
 <keyword>software</keyword>
 <keyword>firmware</keyword>
 <keyword>constrained</keyword>
 <keyword>Secure</keyword>
 <keyword>Boot</keyword>

     <abstract>
       <t>Vulnerabilities in Internet of Things (IoT) devices have raised
 the need for a reliable and secure firmware update mechanism
 suitable for devices with resource constraints. Incorporating such an
 update mechanism is a fundamental requirement for fixing vulnerabilities vulnerabilities,
 but it also enables other important capabilities such as updating
 configuration settings
as well as
 and adding new functionality.</t>
       <t>In addition to the definition of terminology and an architecture architecture,
 this document motivates provides the motivation for the standardization of a manifest format
 as a transport-agnostic means for describing and protecting firmware
 updates.</t>
     </abstract>
   </front>
   <middle>
     <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
       <name>Introduction</name>
       <t>Firmware updates can help to fix security vulnerabilities, and
 performing updates is an important building block in securing
 IoT devices. Due to rising concerns about insecure IoT devices devices, the Internet
 Architecture Board (IAB) organized a ‘Workshop on the Internet of Things
(IoT) Software Update (IOTSU)’ (IoTSU) Workshop <xref target="RFC8240"/> target="RFC8240" format="default"/> to take a look at
 the bigger picture. The workshop revealed a number of challenges for developers
 and led to the formation of the IETF
 Software Updates for Internet of Things (SUIT) working group.</t> Working Group.</t>
       <t>Developing secure Internet of Things (IoT) IoT devices is not an easy
task
 task, and supporting a firmware update solution requires skillful
 engineers. Once devices are deployed, firmware updates play a
 critical part in their lifecycle life-cycle management, particularly when devices have a
 long lifetime, lifetime or are deployed in remote or inaccessible areas where manual
 intervention is cost prohibitive or otherwise difficult. Firmware updates<vspace /> updates
 for IoT devices are expected to work automatically, i.e. i.e., without user
 involvement. Conversely, non-IoT devices are expected to account for user
 preferences and consent when scheduling updates.
 Automatic updates that do not require human intervention
 are key to a scalable solution for fixing software vulnerabilities.</t>
       <t>Firmware updates are done not only to fix bugs, bugs                                                  but also to add new functionality and to reconfigure
 the device to work in new environments or to behave differently in
 an already deployed already-deployed context.</t>
       <t>The manifest specification has to allow that</t>

<t><list style="symbols">
  <t>The the following:</t>
       <ul spacing="normal">
	 <li>The firmware image is authenticated and integrity protected.
 Attempts to flash a maliciously modified firmware image or an image from
 an unknown, untrusted source must be prevented. In examples this This document
 uses asymmetric cryptography in examples because it is the preferred approach by
 many IoT deployments. The use of symmetric credentials is also supported
 and can be used by very constrained IoT devices.</t>
  <t>The devices.</li>
	 <li>The firmware image can be confidentiality protected so that
 attempts by an adversary to recover the plaintext binary can
 be mitigated or at least made more difficult. Obtaining the firmware is often one of
 the first steps to mount mounting an attack since it gives the adversary
 valuable insights into the software libraries used, configuration
settings
 settings, and generic functionality. Even though reverse
 engineering the binary can be a tedious process process, modern reverse
 engineering frameworks have made this task a lot easier.</t>
</list></t> easier.</li>
       </ul>
       <t>Authentication and integrity protection of firmware images must be used in a deployment deployment, but the confidential protection of firmware is optional.</t>
       <t>While the standardization work has been informed by and optimized for firmware
 update use cases of Class 1 devices (according to the device class
 definitions in RFC 7228 <xref target="RFC7228"/>), target="RFC7228" format="default"/>), there is nothing in
 the architecture that restricts its use to only these constrained IoT devices.
 Moreover, this architecture is not limited to managing firmware and software updates, updates
 but can also be applied to managing the delivery of arbitrary data, such
 as configuration information and keys. Unlike higher end higher-end devices, like
 laptops and desktop PCs, many IoT devices do not have user interfaces;
and therefore,
 support for unattended updates is, therefore, is essential for the design
 of a practical solution. Constrained IoT devices often use a
 software engineering model where a developer is responsible for creating
 and compiling all software running on the device into a single, monolithic
 firmware image. On higher end devices higher-end devices, application software is, on the other
 hand, often downloaded separately and even obtained from developers different
to
 from the developers of the lower level lower-level software. The details for how to obtain
 those application layer application-layer software binaries then depends depend heavily on the platform,
 the programming language used used, and the sandbox in which the software is executed.</t>
       <t>While the IETF standardization work has been focused on the
 manifest format, a fully interoperable solution needs more than a standardized
 manifest. For example, protocols for transferring firmware images
 and manifests to the device need to be available available, as well as the status tracker
 functionality. Devices also require a mechanism to discover the status
 tracker(s) and/or firmware servers, for example example, using pre-configured preconfigured hostnames
 or DNS-SD DNS-based Service Discovery (DNS-SD) <xref target="RFC6763"/>. target="RFC6763" format="default"/>.
 These building blocks have been developed by various organizations
 under the umbrella of an IoT device management solution. The LwM2M Lightweight Machine-to-Machine (LwM2M) protocol <xref target="LwM2M"/> target="LwM2M" format="default"/> is one
 IoT device management protocol.</t>

<t>There are, however,

       <t>However, there are several areas that (partially) fall outside the scope of the IETF
 and other standards organizations but need to be considered by firmware authors, authors
 as well as device and network operators. Here are some of them, as highlighted during
 the IOTSU IoTSU workshop:</t>

<t><list style="symbols">
  <t>Installing
       <ul spacing="normal">
	 <li>Installing firmware updates in a robust fashion so that the
 update does not break the device functionality of the environment
 in which this device operates in. operates. This requires proper testing and offering of recovery strategies when a firmware update is unsuccessful.</t>
  <t>Making unsuccessful.</li>
	 <li>Making firmware updates available in a timely fashion considering the
 complexity of the decision making decision-making process for updating devices,
 potential re-certification recertification requirements, the length of a supply chain
 an update needs to go through before it reaches the end customer,
 and the need for user consent to install updates.</t>
  <t>Ensuring updates.</li>
	 <li>Ensuring an energy efficient energy-efficient design of a battery-powered IoT device because device; a
 firmware update, particularly radio communication and writing the firmware image
 to flash, is an energy-intensive task for a device.</t>
  <t>Creating device.</li>

	 <li>Creating incentives for device operators to use a firmware update mechanism and to
demand the
 require its integration of it from IoT device vendors.</t>
  <t>Ensuring vendors.</li>
	 <li>Ensuring that firmware updates addressing critical flaws can be
 obtained even after a product is discontinued or a vendor goes out of
business.</t>
</list></t>
 business.</li>
       </ul>

       <t>This document starts with a terminology list followed by the a description of the architecture.
 We then explain the bootloader and how it integrates with the firmware update mechanism.
 Subsequently, we offer a categorization of IoT devices in terms of their hardware
 capabilities relevant for firmware updates. Next, we talk about the manifest structure
 and how to use it to secure firmware updates. We conclude with a more detailed example.</t> example of a message flow for distributing a firmware image to a device.</t>
     </section>
     <section anchor="terminology" title="Conventions numbered="true" toc="default">
       <name>Conventions and Terminology"> Terminology</name>
       <section anchor="terms" title="Terms"> numbered="true" toc="default">
	 <name>Terms</name>
	 <t>This document uses the following terms:</t>

<t><list style="symbols">
  <t>Firmware Image: The
	 <dl newline="true">
	     <dt>Firmware Image:</dt><dd><t>The firmware image, or simply the “image”, "image", is a binary
 that may contain the complete software of a device or a subset of
 it. The firmware image may consist of multiple images, images if
 the device contains more than one microcontroller. Often Often,
 it is also a compressed archive that contains code,
 configuration data, and even the entire file system. The
 image may consist of a differential update for performance
 reasons.  <vspace blankLines='1'/>  </t>
	     <t>
 The terms,
firmware image, firmware, terms "firmware image", "firmware", and image, "image" are used in this
 document and are interchangeable. We use the term application "application firmware
image
 image" to differentiate it from a firmware image that
 contains the bootloader. An application firmware image, as the
 name indicates, contains the application program often including
 all the necessary code to run it (such as protocol stacks, stacks and
 an embedded operating system).</t>
  <t>Manifest: The system (OS)).</t></dd>
	   <dt>Manifest:</dt><dd>The manifest contains meta-data metadata about the firmware
 image. The manifest is protected against modification and
 provides information about the author.</t>
  <t>Microcontroller (MCU for author.</dd>

	   <dt>Microcontroller:</dt><dd>A microcontroller unit): An MCU unit (MCU) is a
 compact integrated circuit designed for use in embedded systems.
 A typical microcontroller includes a processor, memory (RAM and
 flash), input/output (I/O) ports ports, and other features connected via
 some bus on a single chip. The term ’system "system on chip (SoC)’ chip" (SoC) is
 often used interchangeably with MCU, but MCU tends to imply more
 limited peripheral functions.</t>
  <t>Rich functions.</dd>
	   <dt>Rich Execution Environment (REE): (REE):</dt><dd> An environment that is provided
 and governed by a typical OS (e.g., Linux, Windows, Android, iOS),
 potentially in conjunction with other supporting operating systems
 and hypervisors; it is outside of the TEE. Trusted Execution Environment (TEE).  This environment and the applications running on it are considered un-trusted.</t>
  <t>Software: untrusted.</dd>
	   <dt>Software:</dt><dd> Similar to firmware, firmware but typically dynamically loaded by an
Operating System.
 OS. Used interchangeably with firmware in this document.</t>
  <t>System document.</dd>
	   <dt>System on Chip (SoC): (SoC):</dt><dd> An SoC is an integrated circuit that
 contains all components of a computer, such as the CPU, memory,
input/output
 I/O ports, secondary storage, a bus to connect the
 components, and other hardware blocks of logic.</t>
  <t>Trust Anchor: logic.</dd>
	   <dt>Trust Anchor:</dt><dd> A trust anchor, as defined in RFC 6024 <xref target="RFC6024"/>, target="RFC6024" format="default"/>, represents
 an authoritative entity via a public key and associated data.  The
 public key is used to verify digital signatures, and the associated
 data is used to constrain the types of information for which the
 trust anchor is authoritative.</t>
  <t>Trust authoritative.</dd>
	   <dt>Trust Anchor Store: Store:</dt><dd> A trust anchor store, as defined in <xref target="RFC6024"/>, target="RFC6024" format="default"/>,
 is a set of one or more trust anchors stored in a device.  A device
 may have more than one trust anchor store, each of which may be used
 by one or more applications. A trust anchor store must resist
 modification against unauthorized insertion, deletion, and modification.</t>
  <t>Trusted modification.</dd>
	   <dt>Trusted Applications (TAs): (TAs):</dt><dd> An application component that runs in
 a TEE.</t>
  <t>Trusted TEE.</dd>
	   <dt>Trusted Execution Environments (TEEs): An (TEEs):</dt><dd>An execution environment
 that runs alongside of, but is isolated from, an REE. For more
 information about TEEs TEEs, see <xref target="I-D.ietf-teep-architecture"/>.</t>
</list></t> target="I-D.ietf-teep-architecture" format="default"/>.</dd>
	 </dl>
       </section>
       <section anchor="stakeholders" title="Stakeholders"> numbered="true" toc="default">
	 <name>Stakeholders</name>
	 <t>The following stakeholders are used in this document:</t>

<t><list style="symbols">
  <t>Author: The
	 <dl newline="true">
	   <dt>Author:</dt><dd>The author is the entity that creates the firmware image.
 There may be multiple authors involved in producing firmware running
 on an IoT device. <xref target="device"/> target="device" format="default"/> talks about those IoT device deployment cases.</t>
  <t>Device Operator: cases.</dd>
	   <dt>Device Operator:</dt><dd> The device operator is responsible for the day-to-day operation
 of a fleet of IoT devices. Customers of IoT devices, as the owners of
 IoT devices - such (such as enterprise customers or end users - users), interact
 with their IoT devices indirectly through the device operator via
web
 the Web or smart phone apps.</t>
  <t>Network Operator: smartphone apps.</dd>
	   <dt>Network Operator:</dt><dd> The network operator is responsible for the operation of a
 network to which IoT devices connect.</t>
  <t>Trust connect.</dd>
	   <dt>Trust Provisioning Authority (TPA): The (TPA):</dt><dd>The TPA distributes
 trust anchors and authorization policies to devices and various stakeholders.
 The TPA may also delegate rights to stakeholders. Typically, the
Original Equipment Manufacturer
 original equipment manufacturer (OEM) or Original Design Manufacturer original design manufacturer
 (ODM) will act as a TPA, however TPA; however, complex supply chains may require
 a different design. In some cases, the TPA may decide to remain in
 full control over the firmware update process of their products.</t>
  <t>User: The end-user products.</dd>
	   <dt>User:</dt><dd>The end user of a device. The user may interact with devices
 via web the Web or smart phone smartphone apps, as well as through direct user interfaces.</t>
</list></t> interfaces.</dd>
	 </dl>
       </section>
       <section anchor="functions" title="Functions">

<t><list style="symbols">
  <t>(IoT) Device: numbered="true" toc="default">
	 <name>Functions</name>
	 <dl newline="true">
	   <dt>(IoT) Device:</dt><dd> A device refers to the entire IoT product, which
 consists of one or many MCUs, sensors sensors, and/or actuators. Many IoT
 devices sold today contain multiple MCUs and therefore MCUs; therefore, a single
 device may need to obtain more than one firmware image and
 manifest to successfully perform an update.</t>
  <t>Status Tracker: The update.</dd>

	     <dt>Status Tracker:</dt><dd><t>The status tracker has a client and a server component
 and performs three tasks:
1) It tasks:</t>
 <ol type="1">
 <li>It communicates the availability of a new firmware version. This
    information will flow from the server to the client. <vspace />
2) It </li>
	     <li>It conveys information about the software and hardware characteristics of
    the device. The information flow is from the client to the server. <vspace />
3) It </li>
	     <li>It can remotely trigger the firmware update process. The
    information flow is from the server to the client.  <vspace blankLines='1'/>  </li></ol>
	     <t>
 For example, a device operator may want to read the installed firmware
 version number running on the device and information
 about available flash memory. Once an update has been triggered, the device
 operator may want to obtain information about the state of the firmware
 update. If errors occurred, the device operator may want to
 troubleshoot problems by first obtaining diagnostic information (typically
 using a device management protocol).  <vspace blankLines='1'/>  </t>
	     <t>
 We make no
 assumptions about where the server-side component is deployed.
 The deployment of status trackers is flexible: they may
     be found at cloud-based servers or on-premise servers,
     or they may be embedded in edge computing devices. A status tracker server component may even be
 deployed on an IoT device. For example, if the IoT device contains
 multiple MCUs, then the main MCU may act as a status tracker towards the
 other MCUs. Such deployment is useful when updates have to be
 synchronized across MCUs.  <vspace blankLines='1'/>  </t>
	     <t>
 The status tracker may be operated by any suitable stakeholder; stakeholder,
 typically the Author, Device Operator, author, device operator, or Network Operator.</t>
  <t>Firmware Consumer: network operator.</t>
	   </dd>
	   <dt>Firmware Consumer:</dt><dd> The firmware consumer is the recipient of the
 firmware image and the manifest. It is responsible for parsing
 and verifying the received manifest and for storing the obtained
 firmware image. The firmware consumer plays the role of the
 update component on the IoT device, typically running in the
 application firmware. It interacts with the firmware server and
with
 the status tracker client (locally).</t>
  <t>Firmware Server: (locally).</dd>

	     <dt>Firmware Server:</dt><dd> The firmware server stores firmware images and
 manifests and distributes them to IoT devices. Some deployments
 may require a store-and-forward concept, which requires storing
 the firmware images/manifests images and/or manifests on more than one entity before<vspace /> before they reach the device. There is typically some interaction between the
 firmware server and the status tracker tracker, and these two entities are often
 physically separated on different devices for scalability reasons.</t>
  <t>Bootloader: reasons.</dd>
	   <dt>Bootloader:</dt><dd> A bootloader is a piece of software that is
 executed once a microcontroller has been reset. It is
 responsible for deciding what code to execute.</t>
</list></t> execute.</dd>
	 </dl>
       </section>
     </section>
     <section anchor="architecture" title="Architecture"> numbered="true" toc="default">
       <name>Architecture</name>
       <t>More devices today than ever before are connected to the Internet,
 which drives the need for firmware updates to be provided over the
 Internet rather than through traditional interfaces, such as USB or
 RS-232. Sending updates over the Internet requires the device to fetch
 the new firmware image as well as the manifest.</t>
       <t>Hence, the following components are necessary on a device for a firmware
 update solution:</t>

<t><list style="symbols">
  <t>the
       <ul spacing="normal">

	 <li>The Internet protocol stack for firmware downloads. Because firmware

Firmware images are often multiple kilobytes, sometimes
 exceeding one hundred kilobytes, for low-end IoT devices and can even be
 several megabytes for IoT devices running full-fledged operating systems
 like Linux, the Linux. The protocol mechanism for retrieving these images needs
 to offer features like congestion control, flow control, fragmentation
 and reassembly, and mechanisms to resume interrupted or corrupted transfers.</t>
  <t>the transfers.</li>
	 <li>The capability to write the received firmware image to
 persistent storage (most likely flash memory).</t>
  <t>a memory).</li>
	 <li>A manifest parser with code to verify a digital
 signature or a message authentication code.</t>
  <t>the code (MAC).</li>
	 <li>The ability to unpack, to decompress decompress, and/or to decrypt the
 received firmware image.</t>
  <t>a image.</li>
	 <li>A status tracker.</t>
</list></t> tracker.</li>
       </ul>
       <t>The features listed above are most likely offered provided by code in the application firmware
 image running
 on the device rather than by the bootloader itself. Note that
 cryptographic algorithms will likely run in a trusted execution
environment,
 environment on a separate MCU, MCU in a hardware security module, module or in a secure element
 rather than in the same context with as the application code.</t>
       <t><xref target="arch-figure"/> target="arch-figure" format="default"/> shows the architecture where a
 firmware image is created by an author, author and made available to a firmware
 server. For security reasons, the author will not have the permissions to
 upload firmware images to the firmware server and to initiate an update directly.
 Instead, authors will make firmware images available to the device operators. Note that
 there may be a longer supply chain involved to pass software updates from the author all
 the way to the party that authorizing party, which can then finally make a decision to deploy it with IoT devices.</t>
       <t>As a first step in the firmware update process, the status tracker
 server needs to inform the status tracker client that a new firmware
 update is available. This can be accomplished via polling (client-initiated), (client initiated),
 push notifications (server-initiated), (server initiated), or more complex mechanisms (such as a hybrid approach):</t>

<t><list style="symbols">
  <t>Client-initiated
       <ul spacing="normal">
	 <li>Client-initiated updates take the form of a status tracker client proactively
 checking (polling) for updates.</t>
  <t>With Server-initiated updates updates.</li>

        <li>With server-initiated updates, the server-side component of the status tracker
learns about a new firmware version and determines which devices qualify for a
firmware update. Once the relevant devices have been selected, the
status tracker informs these devices devices, and the firmware consumers obtain those
images and manifests. Server-initiated updates are important because they allow a quick
response time. Note that in this mode mode, the client-side status tracker needs to be reachable by the server-side
component. This may require devices to keep reachability information on the
server-side up-to-date
server side up to date and the state at NATs and stateful packet filtering
firewalls alive.</t>
  <t>Using alive.</li>
        <li>Using a hybrid approach approach, the server-side server side of the status tracker
pushes notifications of availability of an update availability notifications to the client side and requests that
the firmware consumer to pull the manifest and the firmware image from the
firmware server.</t>
</list></t> server.</li>
      </ul>
      <t>Once the device operator triggers an update via the status tracker, it will keep
track of the update process on the device. This allows the device operator to know what
devices have received an update and which of them are still pending an update.</t>
      <t>Firmware images can be conveyed to devices in a variety of ways,
including USB, UART,  Universal Asynchronous Receiver Transmitter (UART), WiFi, BLE, Bluetooth Low Energy (BLE), low-power WAN technologies, mesh networks and many more.
At the application layer layer,
a variety of protocols are also available: MQTT, CoAP, Message Queuing Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), and HTTP are the
most popular application layer application-layer protocols used by IoT devices. This architecture
does not make assumptions about how the firmware images are distributed to the
devices and therefore aims to support all these technologies.</t>
      <t>In some cases cases, it may be desirable to distribute firmware images using a multicast
or broadcast protocol. This architecture does not make recommendations for any
such protocol. However, given that broadcast may be desirable for some networks,
updates must cause the least disruption possible both in the metadata
and firmware transmission. For an update to be broadcast friendly, it cannot rely on link
layer, network layer, link-layer, network-layer, or transport layer transport-layer security. A solution has
to rely on security protection applied to the manifest and firmware image
instead. In addition,
the same manifest must be deliverable to many devices, both those
to which it applies and those to which it does not, without a
chance that the wrong device will accept the update. Considerations
that apply to network broadcasts apply equally to the use of
third-party content distribution networks for payload distribution.</t>
      <figure title="Architecture." anchor="arch-figure"><artwork><![CDATA[ anchor="arch-figure">
        <name>Architecture</name>
        <artwork name="" type="" align="center" alt=""><![CDATA[
                                                      +----------+
                                                      |          |
                                                      |  Author  |
                                                      |          |
                                                      +----------+
                       Firmware + Manifest                 |
              +----------------------------------+         | Firmware +
              |                                  |         | Manifest
              |                               ---+-------  |
              |                           ----   |       --|-
              |                         //+----------+     | \\
             -+--                      // |          |     |   \
        ----/ |  ----                |/   | Firmware |<-+  |    \
      //      |      \\              |    | Server   |  |  |     \
     /        |        \             /    |          |  +  +      \
    /         |         \           /     +----------+   \ /       |
   / +--------+--------+ \         /                      |        |
  /  |        v        |  \       /                       v        |
 |   | +------------+  |   |     |          +----------------+      |
 |   | |  Firmware  |  |   |     |          |     Device     |      |
 |   | |  Consumer  |  |   |     |          |     Management |      |
|    | +------------+  |    |    |          |                |      |
|    | +------------+  |    |    |          |    +--------+  |      |
|    | |  Status    |<-+--------------------+->  |        |  |      |
|    | |  Tracker   |  |    |    |          |    | Status |  |      |
|    | |  Client    |  |    |    |          |    | Tracker|  |     |
 |   | +------------+  |   |     |          |    | Server |  |     |
 |   |    Device       |   |      |         |    +--------+  |     |
 |   +-----------------+   |       \        |                |    /
  \                       /         \       +----------------+   /
   \       Network       /           \                          /
    \     Operator      /             \     Device Operator    /
     \\               //                \ \               \\                    //
        ----     ----                     ----           ----
            -----                             -----------
]]></artwork></figure>
]]></artwork>
      </figure>
      <t>Firmware images and manifests may be conveyed as a bundle or detached. The
manifest format must support both approaches.</t>
      <t>For distribution as a bundle, the firmware image is embedded into the manifest.
This is a useful approach for deployments where devices are not connected
to the Internet and cannot contact a dedicated firmware server for the firmware
download. It is also applicable when the firmware update happens via a USB sticks or short range short-range radio technologies (such as Bluetooth Smart).</t>
      <t>Alternatively, the manifest is distributed detached from the firmware image.
Using this approach, the firmware consumer is presented with the manifest first
and then needs to obtain one or more firmware images as dictated in the
manifest.</t>
      <t>The pre-authorisation pre-authorization step involves verifying whether the entity
signing the manifest is indeed authorized to perform an update.
The firmware consumer must also determine whether it should fetch and
process a firmware image, which is referenced in a manifest.</t>
      <t>A dependency resolution phase is needed when more than one
component can be updated or when a differential update is used.
The necessary dependencies must be available prior to installation.</t>
      <t>The download step is the process of acquiring a local copy of the
firmware image.  When the download is client-initiated, client initiated, this means
that the firmware consumer chooses when a download occurs and initiates
the download process.  When a download is server-initiated, server initiated,
this means that the status tracker tells
the device when to download or that it initiates the transfer
directly to the firmware consumer. For example, a download from an
HTTP/1.1-based firmware server is client-initiated. client initiated. Pushing a manifest
and firmware image to the Package resource Resource of the LwM2M
Firmware Update object Object <xref target="LwM2M"/> target="LwM2M" format="default"/> is a server-initiated update.</t>
      <t>If the firmware consumer has downloaded a new firmware image and is ready to
install it, to initiate the installation, it may</t>

<t><list style="symbols">
  <t>either need
      <ul spacing="normal">
        <li>need to wait for a trigger from the status tracker,</t>
  <t>or trigger tracker,</li>
        <li>trigger the update automatically,</t>
  <t>or go automatically, or</li>
        <li>go through a more complex decision making decision-making process to determine</t>
</list></t>

<t>the determine
      the appropriate timing for an update. update.</li></ul><t> Sometimes the final decision may
require confirmation of the user of the device for safety reasons.</t>
      <t>Installation is the act of processing the payload into a format that
the IoT device can recognize recognize, and the bootloader is responsible for
then booting from the newly installed firmware image.
This process is different when a bootloader is not involved. For example,
when an application is updated in a full-featured operating system, OS, the
updater may halt and restart the application in isolation.
Devices must not fail when a disruption, such as a power failure or network
interruption, occurs during the update process.</t>
    </section>
    <section anchor="invocation" title="Invoking numbered="true" toc="default">
      <name>Invoking the Firmware"> Firmware</name>

      <t><xref target="architecture"/> target="architecture" format="default"/> describes the steps for getting the firmware image and the manifest
from the author to the firmware consumer on the IoT device. Once the firmware consumer
has retrieved and successfully processed the manifest and the firmware image image, it needs
to invoke the new firmware image. This is managed in many different ways, ways depending
on the type of device, but it typically involves halting the current version of the
firmware, handing control over control to a firmware with a higher privilege/trust privilege or trust level
(the firmware verifier),
verifying the new firmware’s firmware's authenticity &amp; and integrity, and then invoking it.</t>
      <t>In an execute-in-place microcontroller, this is often done by rebooting into a
bootloader (simultaneously halting the application &amp; and handing over control to the higher
privilege level) then executing a secure boot process (verifying and invoking
the new image).</t>
      <t>In a rich OS, this may be done by halting one or more processes, processes and then invoking
new applications. In some OSs, OSes, this implicitly involves the kernel verifying
the code signatures on the new applications.</t>
      <t>The invocation process is security sensitive. An attacker will typically try to
retrieve a firmware image from the device for reverse engineering or will try to get
the firmware verifier to execute an attacker-modified firmware image. The Therefore,
firmware verifier will therefore have to perform security checks on the
firmware image before it can be invoked. These security checks by the
firmware verifier happen in addition to the security checks that took place
when the firmware image and the manifest were downloaded by the firmware consumer.</t>
      <t>The overlap between the firmware consumer and the firmware verifier
functionality comes in two forms, namely</t>

<t><list style="symbols">
  <t>A namely:</t>
      <ul spacing="normal">
        <li>A firmware verifier must verify the firmware image it boots as
part of the secure boot process. Doing so requires meta-data metadata to be
stored alongside the firmware image so that the firmware verifier can
cryptographically verify the firmware image before booting it to
ensure it has not been tampered with or replaced. This meta-data metadata
used by the firmware verifier may well be the same manifest obtained with the
firmware image during the update process.</t>
  <t>An process.</li>
        <li>An IoT device needs a recovery strategy in case the firmware
update / invocation
update/invocation process fails. The recovery
strategy may include storing two or more application firmware images
on the device or offering the ability to invoke a recovery image to
perform the firmware update process again using firmware updates over
serial, USB USB, or even wireless connectivity like Bluetooth Smart.
In the latter case case, the firmware consumer functionality is contained in the
recovery image and requires the necessary functionality for
executing the firmware update process, including manifest parsing.</t>
</list></t> parsing.</li>
      </ul>
      <t>While this document assumes that the firmware verifier itself is
distinct from the role of the firmware consumer and therefore does not
manage the firmware update process, this is not a requirement requirement, and these
roles may be combined in practice.</t>
      <t>Using a bootloader as the firmware verifier requires some special
considerations, particularly when the bootloader
implements the robustness requirements identified by the IOTSU IoTSU workshop <xref target="RFC8240"/>.</t> target="RFC8240" format="default"/>.</t>
      <section anchor="bootloader" title="The Bootloader"> numbered="true" toc="default">
        <name>The Bootloader</name>
        <t>In most cases cases, the MCU must restart in order to hand over control to the bootloader.
Once the MCU has initiated a restart, the bootloader determines whether a newly available
firmware image should be executed. If the bootloader concludes that the newly available
firmware image is invalid, a recovery strategy is necessary. There are only two
approaches for recovering from an invalid firmware: either the bootloader must be able
to select a different, valid firmware, firmware or it must be able to obtain a new, valid firmware.
Both of these approaches have implications for the architecture of the update system.</t>
        <t>Assuming the first approach, there are (at least) three firmware images available
on the device:</t>

<t><list style="symbols">
  <t>First,
        <ul spacing="normal">
          <li>First, the bootloader is also firmware. If a bootloader is updatable updatable, then its
firmware image is treated like any other application firmware image.</t>
  <t>Second, image.</li>
          <li>Second, the firmware image that has to be replaced is still available on the
device as a backup in case the freshly downloaded firmware image does not
boot or operate correctly.</t>
  <t>Third, correctly.</li>
          <li>Third, there is the newly downloaded firmware image.</t>
</list></t> image.</li>
        </ul>
        <t>Therefore, the firmware consumer must know where to store the new firmware.
In some cases, this may be implicit, for example implicit (for example, replacing the least-recently-used least recently used
firmware image. image). In other cases, the storage location of the new firmware must be
explicit, for example example, when a device has one or more application firmware images
and a recovery image with limited functionality, sufficient only to perform an update.</t>
        <t>Since many low end low-end IoT devices do not use position-independent code,
either the bootloader needs to copy the newly downloaded application firmware image
into the location of the old application firmware image and vice versa or
multiple versions of the firmware need to be prepared for different locations.</t>
        <t>In general, it is assumed that the bootloader itself, or a minimal part of it,
will not be updated since a failed update of the bootloader poses a
reliability risk.</t>
        <t>For a bootloader to offer a secure boot functionality functionality, it needs to
implement the following functionality:</t>

<t><list style="symbols">
  <t>The
        <ul spacing="normal">
          <li>The bootloader needs to fetch the manifest
from nonvolatile storage and parse its
contents for subsequent cryptographic verification.</t>
  <t>Cryptographic verification.</li>
          <li>Cryptographic libraries with hash functions, digital signatures
(for asymmetric crypto), and message authentication codes (for symmetric
crypto) need to be accessible.</t>
  <t>The accessible.</li>
          <li>The device needs to have a trust anchor store to verify the
digital signature. (Alternatively, Alternatively, access to a key store for use
with the message authentication code.)</t>
  <t>There code may be used.</li>
          <li>There must be an ability to expose boot process-related boot-process-related data to the application
firmware (such as to the status tracker).  This allows
sharing
information sharing about the current firmware version, version and the
status of the firmware update process and whether errors have occurred.</t>
  <t>Produce occurred.</li>
          <li>Produce boot measurements as part of an attestation solution. See solution; see
<xref target="I-D.ietf-rats-architecture"/> target="I-D.ietf-rats-architecture" format="default"/> for more information. (optional)</t>
  <t>The information (optional).</li>
          <li>The bootloader must be able to decrypt firmware images, images in case confidentiality protection
was applied. This requires a solution for key management. (optional)</t>
</list></t> management (optional).</li>
        </ul>
      </section>
    </section>
    <section anchor="device" title="Types numbered="true" toc="default">
      <name>Types of IoT Devices">

<t>There Devices</name>
      <t>Today, there are billions of MCUs used in devices today produced by a large
number of silicon manufacturers. While MCUs can vary significantly
in their characteristics, there are a number of similiaries allowing similarities that allow us to categorize in them into groups.</t>
      <t>The firmware update architecture, and the manifest format in particular,
needs to offer enough flexibility to cover these common deployment cases.</t>
      <section anchor="single-mcu" title="Single MCU"> numbered="true" toc="default">
        <name>Single MCU</name>
        <t>The simplest, simplest and currently most common, common architecture consists of
a single MCU along with its own peripherals.  These SoCs generally
contain some amount of flash memory for code and fixed data, as
well as RAM for working storage.  A notable characteristic of these
SoCs is that the primary code is generally execute in place (XIP).
Due to the non-relocatable nature of the code, the firmware image
needs to be placed in a specific location in flash memory since the code
cannot be executed from an arbitrary location in flash. therein. Hence, when
the firmware image is updated updated, it is necessary to swap the old and
the new image.</t>
      </section>
      <section anchor="single-cpu-with-secure-normal-mode-partitioning" title="Single numbered="true" toc="default">

        <name>Single CPU with Partitioning between Secure - Normal Mode Partitioning"> and Normal Mode</name>
        <t>Another configuration consists of a similar architecture to the
previous, with
one previously discussed: it contains a single CPU.  However, this CPU supports a security
partitioning scheme that allows memory (in addition to and other things) system components to be divided into secure and normal mode.  There will generally be
two images, images: one for secure mode, mode and one for normal mode.  In this
configuration, firmware upgrades will generally be done by the CPU
in secure mode, which is able to write to both areas of the flash
device. In addition, there are requirements to be able to update
either image independently, independently as well as to update them together
atomically, as specified in the associated manifests.</t>
      </section>
      <section anchor="symmetric-multiple-cpus" title="Symmetric numbered="true" toc="default">
        <name>Symmetric Multiple CPUs"> CPUs</name>
        <t>In more complex SoCs with symmetric multi-processing multiprocessing support, advanced
operating systems, such as Linux, are often used. These SoCs frequently
use an external storage medium, such as raw NAND flash or eMMC. an embedded Multimedia Card (eMMC). Due to
the higher quantity of resources, these devices are often capable of
storing multiple copies of their firmware images and selecting the most
appropriate one to boot. Many SoCs also support bootloaders that are
capable of updating the firmware image, however image; however, this is typically a last
resort because it requires the device to be held in the bootloader while
the new firmware is downloaded and installed, which results in down-time downtime
for the device. Firmware updates in this class of device are typically
not done in-place.</t> in place.</t>
      </section>
      <section anchor="dual-cpu-shared-memory" title="Dual numbered="true" toc="default">
        <name>Dual CPU, shared memory"> Shared Memory</name>
        <t>This configuration has two or more heterogeneous CPUs in a single SoC that
share memory (flash and RAM).  Generally, there will be a mechanism to prevent
one CPU from unintentionally accessing memory currently allocated to the other.
Upgrades in this case will typically be done by one of the CPUs, CPUs and is
similar to the single CPU with secure mode.</t>
      </section>
      <section anchor="dual-cpu-other-bus" title="Dual numbered="true" toc="default">
        <name>Dual CPU, other bus"> Other Bus</name>
        <t>This configuration has two or more heterogeneous CPUs, each having their own memory.
There will be a communication channel between them, but it will be
used as a peripheral, not via shared memory.  In this case, each CPU
will have to be responsible for its own firmware upgrade.  It is
likely that one of the CPUs will be considered the primary CPU, CPU and will
direct the other CPU to do the upgrade.  This configuration is
commonly used to offload specific work to other CPUs.  Firmware
dependencies are similar to the other solutions above, above: sometimes
allowing only one image to be upgraded, other times requiring several
to be upgraded atomically.  Because the updates are happening on
multiple CPUs, upgrading the two images atomically is challenging.</t>
      </section>
    </section>
    <section anchor="manifests" title="Manifests"> numbered="true" toc="default">
      <name>Manifests</name>
      <t>In order for a firmware consumer to apply an update, it has to make several decisions
using manifest-provided information and data available on the device itself. For more
detailed information and a longer list of information elements in the manifest manifest, consult the
information model specification <xref target="I-D.ietf-suit-information-model"/>, target="I-D.ietf-suit-information-model" format="default"/>, which offers justifications
for each element, and the manifest specification <xref target="I-D.ietf-suit-manifest"/> target="I-D.ietf-suit-manifest" format="default"/> for details about how this
      information is included in the manifest.</t>

<t><xref target="manifest-info"/> provides examples of decisions to be made.</t>

<texttable title="Firmware

      <table anchor="manifest-info" align="center">
        <name>Example Firmware Update Decisions." anchor="manifest-info">
      <ttcol align='right'>Decision</ttcol>
      <ttcol align='left'>Information Elements</ttcol>
      <c>Should Decisions</name>
        <thead>
          <tr>
            <th align="right">Decision</th>
            <th align="left">Information Elements</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="right">Should I trust the author of the firmware?</c>
      <c>Trust firmware?</td>
            <td align="left">Trust anchors and authorization policies on the device</c>
      <c>Has device</td>
          </tr>
          <tr>
            <td align="right">Has the firmware been corrupted?</c>
      <c>Digital corrupted?</td>
            <td align="left">Digital signature and MAC covering the firmware image</c>
      <c>Does image</td>
          </tr>
          <tr>
            <td align="right">Does the firmware update apply to this device?</c>
      <c>Conditions device?</td>
            <td align="left">Conditions with Vendor ID, Class ID ID, and Device ID</c>
      <c>Is ID</td>
          </tr>
          <tr>
            <td align="right">Is the update older than the active firmware?</c>
      <c>Sequence firmware?</td>
            <td align="left">Sequence number in the manifest (1)</c>
      <c>When (1)</td>
          </tr>
          <tr>
            <td align="right">When should the device apply the update?</c>
      <c>Wait directive</c>
      <c>How update?</td>
            <td align="left">Wait directive</td>
          </tr>
          <tr>
            <td align="right">How should the device apply the update?</c>
      <c>Manifest commands</c>
      <c>What update?</td>
            <td align="left">Manifest commands</td>
          </tr>
          <tr>
            <td align="right">What kind of firmware binary is it?</c>
      <c>Unpack it?</td>
            <td align="left">Unpack algorithms to interpret a format.</c>
      <c>Where format</td>
          </tr>
          <tr>
            <td align="right">Where should the update be obtained?</c>
      <c>Dependencies obtained?</td>
            <td align="left">Dependencies on other manifests and firmware image URI in Manifest</c>
      <c>Where the manifest</td>
          </tr>
          <tr>
            <td align="right">Where should the firmware be stored?</c>
      <c>Storage Location and Component Identifier</c>
</texttable>

<t>(1): A stored?</td>
            <td align="left">Storage location and component identifier</td>
          </tr>
        </tbody>
      </table>
      <dl indent="6" newline="false"><dt>(1):</dt><dd>A device presented with an old, old but valid manifest and firmware
must not be tricked into installing such firmware since a
vulnerability in the old firmware image may allow an attacker to
gain control of the device.</t> device.</dd></dl>
      <t>Keeping the code size and complexity of a manifest parsers parser small is important
for constrained IoT devices. Since the manifest parsing code may
also be used by the bootloader bootloader, it can be part of the trusted computing base.</t>
      <t>A manifest may be used to protect not only firmware images but also
configuration data such as network credentials or personalization data
related to the firmware or software.
Personalization data demonstrates the need for confidentiality to be
maintained between two or more stakeholders that both deliver images to
the same device. Personalization data is used with
Trusted Execution Environments (TEEs),
TEEs, which
benefit from a protocol for managing the lifecycle life cycle of trusted
applications (TAs) TAs running inside a TEE. TEEs may obtain TAs
from different authors authors, and those TAs may require personalization data,
such as payment information, to be securely conveyed to the TEE. The
TA’s
TA's author does not want to expose the TA’s TA's code to any other stakeholder
or third party.
The user does not want to expose the payment information to any other
stakeholder or third party.</t>
    </section>
    <section anchor="securing" title="Securing numbered="true" toc="default">
      <name>Securing Firmware Updates"> Updates</name>
      <t>Using firmware updates to fix vulnerabilities in devices is important important, but securing this
update mechanism is equally important since security problems are
exacerbated by the update mechanism: mechanism. An update is essentially authorized
remote code execution, so any security problems in the update process
expose that remote code execution system. Failure
to secure the firmware update process will help attackers to take control over of devices.</t>
      <t>End-to-end security mechanisms are used to protect the firmware
image and the manifest. The following assumptions are made to allow
the firmware consumer to verify the received firmware image and
manifest before updating the software:</t>

<t><list style="symbols">
  <t>Authentication
      <ul spacing="normal">
        <li>Authentication ensures that the device can cryptographically identify
the author(s) creating firmware images and manifests. Authenticated
identities may be used as input to the authorization process. Not all
entities creating and signing manifests have the same
permissions. A device needs to determine whether the requested action
is indeed covered by the permission of the party that signed the manifest.
Informing the device about the permissions of the different parties
also happens in an out-of-band fashion and is a duty of the
Trust Provisioning Authority.</t>
  <t>Integrity Authority.</li>
        <li>Integrity protection ensures that no third party can modify the manifest
or the firmware image. To accept an update, a device needs to verify the signature covering
the manifest. There may be one or multiple manifests that need to be
validated, potentially signed by different parties. The device needs
to be in possession of the trust anchors to verify those signatures.
Installing trust anchors to devices via the Trust Provisioning Authority
happens in an out-of-band fashion prior to the firmware update process.</t>
  <t>For confidentiality process.</li>
<li>

  Confidentiality protection of the firmware image, it image must be done in such a
way that no one aside from the intended firmware consumer(s), consumer(s) and other authorized parties,
and no one else parties can decrypt it. The information
that is encrypted individually for each device/recipient must be done in a way that is
usable with Content Distribution Networks, Networks (CDNs), bulk storage, and
broadcast protocols. For confidentiality protection of firmware images images, the author needs
to be in possession of the certificate/public key or a pre-shared key
of a device. The use of confidentiality protection of firmware images
is optional.</t>
</list></t> optional.</li>
      </ul>

      <t>A manifest specification must support different cryptographic algorithms
and algorithm extensibility. Moreover, since RSA- and ECC-based signature
schemes based on RSA and Elliptic Curve Cryptography (ECC) may become vulnerable to quantum-accelerated key extraction in the
future, unchangeable bootloader code in ROM is recommended to use post-quantum
secure signature schemes such as hash-based signatures <xref target="RFC8778"/>. target="RFC8778" format="default"/>. A
bootloader author must carefully consider the service lifetime of their
product and the time horizon for quantum-accelerated key extraction.
The worst-case estimate, at
At the time of writing, the worst-case estimate for the time horizon to key
extraction with quantum acceleration is approximately 2030, based on
current research <xref target="quantum-factorization"/>.</t> target="quantum-factorization" format="default"/>.</t>
      <t>When a device obtains a monolithic firmware image from a single author
without any additional approval steps, the authorization flow is
relatively simple. There are, however, However, there are other cases where more complex
policy decisions need to be made before updating a device.</t>
      <t>In this architecture architecture, the authorization policy is separated from
the underlying communication architecture. This is accomplished
by separating the entities from their permissions. For example,
an author may not have the authority to install a firmware image
on a device in critical infrastructure without the authorization
of a device operator. In this case, the device may be programmed
to reject firmware updates unless they are signed both by the
      firmware author and by the device operator.</t>

      <t>Alternatively, a device may trust precisely one entity, which entity that
does all permission management and coordination. This entity
allows the device to offload complex permissions
calculations for the device.</t>
    </section>
    <section anchor="example" title="Example"> numbered="true" toc="default">
      <name>Example</name>
      <t><xref target="firmware-update"/> target="firmware-update" format="default"/> illustrates an example message flow
for distributing a firmware image to a device. The firmware
and manifest are stored on the same firmware server and
      distributed in a detached manner.</t>

      <figure title="First anchor="firmware-update">
        <name>First Example Flow for a Firmware Update." anchor="firmware-update"><artwork><![CDATA[ Update</name>
        <artwork name="" type="" align="center" alt=""><![CDATA[
+--------+    +-----------------+    +-----------------------------+
|        |    | Firmware Server |    |         IoT Device          |
| Author |    | Status Tracker  |    | +------------+ +----------+ |
+--------+    | Server          |    | |  Firmware  | |Bootloader| |
  |           +-----------------+    | |  Consumer  | |          | |
  |                   |              | +------------+ +----------+ |
  |                   |              |      |                |     |
  |                   |              |  +-----------------------+  |
  | Create Firmware   |              |  | Status Tracker Client |  |
  |--------------+    |              |  +-----------------------+  |
  |              |    |               `''''''''''''''''''''''''''''
  |<-------------+    |                     |        |       |
  |                   |                     |        |       |
  | Upload Firmware   |                     |        |       |
  |------------------>|                     |        |       |
  |                   |                     |        |       |
  | Create Manifest   |                     |        |       |
  |---------------+   |                     |        |       |
  |               |   |                     |        |       |
  |<--------------+   |                     |        |       |
  |                   |                     |        |       |
  | Sign Manifest     |                     |        |       |
  |-------------+     |                     |        |       |
  |             |     |                     |        |       |
  |<------------+     |                     |        |       |
  |                   |                     |        |       |
  | Upload Manifest   |                     |        |       |
  |------------------>|  Notification of    |        |       |
  |                   |  new firmware image |        |       |
  |                   |----------------------------->|       |
  |                   |                     |        |       |
  |                   |                     |Initiate|       |
  |                   |                     | Update |       |
  |                   |                     |<-------|       |
  |                   |                     |        |       |
  |                   |   Query Manifest    |        |       |
  |                   |<--------------------|        .       |
  |                   |                     |        .       |
  |                   |   Send Manifest     |        .       |
  |                   |-------------------->|        .       |
  |                   |                     | Validate       |
  |                   |                     | Manifest       |
  |                   |                     |--------+       |
  |                   |                     |        |       |
  |                   |                     |<-------+       |
  |                   |                     |        .       |
  |                   |  Request Firmware   |        .       |
  |                   |<--------------------|        .       |
  |                   |                     |        .       |
  |                   | Send Firmware       |        .       |
  |                   |-------------------->|        .       |
  |                   |                     | Verify .       |
  |                   |                     | Firmware       |
  |                   |                     |--------+       |
  |                   |                     |        |       |
  |                   |                     |<-------+       |
  |                   |                     |        .       |
  |                   |                     | Store  .       |
  |                   |                     | Firmware       |
  |                   |                     |--------+       |
  |                   |                     |        |       |
  |                   |                     |<-------+       |
  |                   |                     |        .       |
  |                   |                     |        .       |
  |                   |                     |        .       |
  |                   |                     |        |       |
  |                   |                     | Update |       |
  |                   |                     |Complete|       |
  |                   |                     |------->|       |
  |                   |                              |       |
  |                   |  Firmware Update Completed   |       |
  |                   |<-----------------------------|       |
  |                   |                              |       |
  |                   |  Reboot                      |       |
  |                   |----------------------------->|       |
  |                   |                     |        |       |
  |                   |                     |        |       |
  |                   |                     |        |Reboot |
  |                   |                     |        |------>|
  |                   |                     |        |       |
  |                   |                     |        .       |
  |                   |                 +---+----------------+--+
  |                   |                S|   |                |  |
  |                   |                E|   | Verify         |  |
  |                   |                C|   | Firmware       |  |
  |                   |                U|   | +--------------|  |
  |                   |                R|   | |              |  |
  |                   |                E|   | +------------->|  |
  |                   |                 |   |                |  |
  |                   |                B|   | Activate new   |  |
  |                   |                O|   | Firmware       |  |
  |                   |                O|   | +--------------|  |
  |                   |                T|   | |              |  |
  |                   |                 |   | +------------->|  |
  |                   |                P|   |                |  |
  |                   |                R|   | Boot new       |  |
  |                   |                O|   | Firmware       |  |
  |                   |                C|   | +--------------|  |
  |                   |                E|   | |              |  |
  |                   |                S|   | +------------->|  |
  |                   |                S|   |                |  |
  |                   |                 +---+----------------+--+
  |                   |                     |        .       |
  |                   |                     |        |       |
  |                   |                     .        |       |
  |                   |  Device running new firmware |       |
  |                   |<-----------------------------|       |
  |                   |                     .        |       |
  |                   |                              |       |
]]></artwork></figure>
]]></artwork>
      </figure>
      <t><xref target="firmware-update2"/> target="firmware-update2" format="default"/> shows an exchange that starts with the
status tracker querying the device for its current firmware version.
Later, a new firmware version becomes available available, and since this
device is running an older version version, the status tracker server interacts
with the device to initiate an update.</t>
      <t>The manifest and the firmware are stored on different servers in this
example. When the device processes the manifest manifest, it learns where to
download the new firmware version. The firmware consumer downloads
the firmware image with the newer version X.Y.Z after successful validation
of the manifest. Subsequently, a reboot is initiated initiated, and the secure
boot process starts. Finally, the device reports the successful boot
of the new firmware version.</t>
      <figure title="Second anchor="firmware-update2">
        <name>Second Example Flow for a Firmware Update." anchor="firmware-update2"><artwork><![CDATA[ Update</name>
        <artwork name="" type="" align="center" alt=""><![CDATA[
 +---------+   +-----------------+    +-----------------------------+
 | Status  |   | Firmware Server |    | +------------+ +----------+ |
 | Tracker |   | Status Tracker  |    | |  Firmware  | |Bootloader| |
 | Server  |   | Server          |    | |  Consumer  | |          | |
 +---------+   +-----------------+    | |  +Status   | +----------+ |
      |                |              | |  Tracker   |        |     |
      |                |              | |  Client    |        |     |
      |                |              | +------------+        |     |
      |                |              |      |  IoT Device    |     |
      |                |               `''''''''''''''''''''''''''''
      |                |                     |                |
      |        Query Firmware Version        |                |
      |------------------------------------->|                |
      |        Firmware Version A.B.C        |                |
      |<-------------------------------------|                |
      |                |                     |                |
      |         <<some time later>>          |                |
      |                |                     |                |
    _,...._         _,...._                  |                |
  ,'       `.     ,'       `.                |                |
 |   New     |   |   New     |               |                |
 \ Manifest  /   \ Firmware  /               |                |
  `.._   _,,'     `.._   _,,'                |                |
      `''             `''                    |                |
      |            Push manifest             |                |
      |----------------+-------------------->|                |
      |                |                     |                |
      |                '                     |                '
      |                |                     | Validate       |
      |                |                     | Manifest       |
      |                |                     |---------+      |
      |                |                     |         |      |
      |                |                     |<--------+      |
      |                | Request firmware    |                |
      |                | X.Y.Z               |                |
      |                |<--------------------|                |
      |                |                     |                |
      |                | Firmware X.Y.Z      |                |
      |                |-------------------->|                |
      |                |                     |                |
      |                |                     | Verify         |
      |                |                     | Firmware       |
      |                |                     |--------------+ |
      |                |                     |              | |
      |                |                     |<-------------+ |
      |                |                     |                |
      |                |                     | Store          |
      |                |                     | Firmware       |
      |                |                     |-------------+  |
      |                |                     |             |  |
      |                |                     |<------------+  |
      |                |                     |                |
      |                |                     |                |
      |                |                     | Trigger Reboot |
      |                |                     |--------------->|
      |                |                     |                |
      |                |                     |                |
      |                |                     | __..-------..._'
      |                |                    ,-'               `-.
      |                |                   |      Secure Boot    |
      |                |                   `-.                 _/
      |                |                     |`--..._____,,.,-'
      |                |                     |                |
      | Device running firmware X.Y.Z        |                |
      |<-------------------------------------|                |
      |                |                     |                |
      |                |                     |                |
]]></artwork></figure>
]]></artwork>
      </figure>
    </section>
    <section anchor="iana-considerations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document does not require any actions by IANA.</t> has no IANA actions.</t>
    </section>
    <section anchor="security-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document describes the terminology, requirements requirements, and an architecture for
firmware updates of IoT devices. The content of the document is thereby
focused on improving the security of IoT devices via firmware update mechanisms
and informs the standardization of a manifest format.</t>
      <t>An in-depth examination of the security considerations of the
architecture is presented in <xref target="I-D.ietf-suit-information-model"/>.</t>

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

<t>We would like to thank the following persons for their feedback:</t>

<t><list style="symbols">
  <t>Geraint Luff</t>
  <t>Amyas Phillips</t>
  <t>Dan Ros</t>
  <t>Thomas Eichinger</t>
  <t>Michael Richardson</t>
  <t>Emmanuel Baccelli</t>
  <t>Ned Smith</t>
  <t>Jim Schaad</t>
  <t>Carsten Bormann</t>
  <t>Cullen Jennings</t>
  <t>Olaf Bergmann</t>
  <t>Suhas Nandakumar</t>
  <t>Phillip Hallam-Baker</t>
  <t>Marti Bolivar</t>
  <t>Andrzej Puzdrowski</t>
  <t>Markus Gueller</t>
  <t>Henk Birkholz</t>
  <t>Jintao Zhu</t>
  <t>Takeshi Takahashi</t>
  <t>Jacob Beningo</t>
  <t>Kathleen Moriarty</t>
  <t>Bob Briscoe</t>
  <t>Roman Danyliw</t>
  <t>Brian Carpenter</t>
  <t>Theresa Enghardt</t>
  <t>Rich Salz</t>
  <t>Mohit Sethi</t>
  <t>Eric Vyncke</t>
  <t>Alvaro Retana</t>
  <t>Barry Leiba</t>
  <t>Benjamin Kaduk</t>
  <t>Martin Duke</t>
  <t>Robert Wilton</t>
</list></t>

<t>We would also like to thank the WG chairs, Russ Housley, David Waltermire, and
Dave Thaler, for their support and their reviews.</t> target="I-D.ietf-suit-information-model" format="default"/>.</t>
    </section>
  </middle>
  <back>

    <references title='Informative References'>

<displayreference target="I-D.ietf-suit-information-model" to="SUIT-INFO-MODEL"/>
<displayreference target="I-D.ietf-teep-architecture" to="TEEP-ARCH"/>
<displayreference target="I-D.ietf-suit-manifest" to="SUIT-MANIFEST"/>
<displayreference target="I-D.ietf-rats-architecture" to="RATS-ARCH"/>

 <references>
      <name>Informative References</name>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8240.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6024.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8778.xml"/>

      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-suit-information-model.xml"/>

      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-teep-architecture.xml"/>

      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-suit-manifest.xml"/>

      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-rats-architecture.xml"/>

      <reference  anchor="RFC8240" target='https://www.rfc-editor.org/info/rfc8240'> anchor="quantum-factorization" target="https://www.nature.com/articles/s41598-018-36058-z">
        <front>
<title>Report from the Internet of Things Software Update (IoTSU) Workshop 2016</title>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<date year='2017' month='September' />
<abstract><t>This document provides a summary of the Internet of Things Software Update (IoTSU) Workshop that took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016.  The main goal of the workshop was to foster a discussion on requirements, challenges, and solutions for bringing software and firmware updates to IoT devices. This report summarizes the discussions and lists recommendations to the standards community.</t><t>Note that this document is a report on the proceedings of the workshop.  The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.</t></abstract>
</front>
<seriesInfo name='RFC' value='8240'/>
<seriesInfo name='DOI' value='10.17487/RFC8240'/>
</reference>

<reference  anchor="RFC6024" target='https://www.rfc-editor.org/info/rfc6024'>
<front>
<title>Trust Anchor Management Requirements</title>
<author initials='R.' surname='Reddy' fullname='R. Reddy'><organization /></author>
<author initials='C.' surname='Wallace' fullname='C. Wallace'><organization /></author>
<date year='2010' month='October' />
<abstract><t>A trust anchor represents an authoritative entity via a public key and associated data.  The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative.  A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor.  This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems.  This  document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='6024'/>
<seriesInfo name='DOI' value='10.17487/RFC6024'/>
</reference>

<reference  anchor="RFC6763" target='https://www.rfc-editor.org/info/rfc6763'>
<front>
<title>DNS-Based Service Discovery</title>
<author initials='S.' surname='Cheshire' fullname='S. Cheshire'><organization /></author>
<author initials='M.' surname='Krochmal' fullname='M. Krochmal'><organization /></author>
<date year='2013' month='February' />
<abstract><t>This document specifies how DNS resource records are named and structured to facilitate service discovery.  Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.</t></abstract>
</front>
<seriesInfo name='RFC' value='6763'/>
<seriesInfo name='DOI' value='10.17487/RFC6763'/>
</reference>

<reference  anchor="RFC7228" target='https://www.rfc-editor.org/info/rfc7228'>
<front>
<title>Terminology for Constrained-Node Networks</title>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<author initials='M.' surname='Ersue' fullname='M. Ersue'><organization /></author>
<author initials='A.' surname='Keranen' fullname='A. Keranen'><organization /></author>
<date year='2014' month='May' />
<abstract><t>The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks.  This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.</t></abstract>
</front>
<seriesInfo name='RFC' value='7228'/>
<seriesInfo name='DOI' value='10.17487/RFC7228'/>
</reference>

<reference  anchor="RFC8778" target='https://www.rfc-editor.org/info/rfc8778'>
<front>
<title>Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE)</title>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<date year='2020' month='April' />
<abstract><t>This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the CBOR Object Signing and Encryption (COSE) syntax. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.</t></abstract>
</front>
<seriesInfo name='RFC' value='8778'/>
<seriesInfo name='DOI' value='10.17487/RFC8778'/>
</reference>

<reference anchor="I-D.ietf-suit-information-model">
<front>
<title>An Information Model for Firmware Updates in IoT Devices</title>

<author initials='B' surname='Moran' fullname='Brendan Moran'>
    <organization />
</author>

<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
    <organization />
</author>

<author initials='H' surname='Birkholz' fullname='Henk Birkholz'>
    <organization />
</author>

<date month='October' day='28' year='2020' />

<abstract><t>Vulnerabilities with Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism that is also suitable for constrained devices.  Ensuring that devices function and remain secure over their service life requires such an update mechanism to fix vulnerabilities, to update configuration settings, as well as adding new functionality.  One component of such a firmware update is a concise and machine- processable meta-data document, or manifest, that describes the firmware image(s) and offers appropriate protection.  This document describes the information that must be present in the manifest.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-suit-information-model-08' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-suit-information-model-08.txt' />
</reference>

<reference anchor="I-D.ietf-teep-architecture">
<front>
<title>Trusted Execution Environment Provisioning (TEEP) Architecture</title>

<author initials='M' surname='Pei' fullname='Mingliang Pei'>
    <organization />
</author>

<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
    <organization />
</author>

<author initials='D' surname='Thaler' fullname='Dave Thaler'>
    <organization />
</author>

<author initials='D' surname='Wheeler' fullname='David Wheeler'>
    <organization />
</author>

<date month='November' day='2' year='2020' />

<abstract><t>A Trusted Execution Environment (TEE) is an environment that enforces that any code within that environment cannot be tampered with, and that any data used by such code cannot be read or tampered with by any code outside that environment.  This architecture document motivates the design and standardization of a protocol for managing the lifecycle of trusted applications running inside such a TEE.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-teep-architecture-13' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-teep-architecture-13.txt' />
</reference>

<reference anchor="I-D.ietf-suit-manifest">
<front>
<title>A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest</title>

<author initials='B' surname='Moran' fullname='Brendan Moran'>
    <organization />
</author>

<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
    <organization />
</author>

<author initials='H' surname='Birkholz' fullname='Henk Birkholz'>
    <organization />
</author>

<author initials='K' surname='Zandberg' fullname='Koen Zandberg'>
    <organization />
</author>

<date month='December' day='8' year='2020' />

<abstract><t>This specification describes the format of a manifest.  A manifest is a bundle of metadata about code/data obtained by a recipient (chiefly the firmware for an IoT device), where to find the that code/data, the devices to which it applies, and cryptographic information protecting the manifest.  Software updates and Trusted Invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than declaring the metadata.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-suit-manifest-11' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-suit-manifest-11.txt' />
</reference>

<reference anchor="I-D.ietf-rats-architecture">
<front>
<title>Remote Attestation Procedures Architecture</title>

<author initials='H' surname='Birkholz' fullname='Henk Birkholz'>
    <organization />
</author>

<author initials='D' surname='Thaler' fullname='Dave Thaler'>
    <organization />
</author>

<author initials='M' surname='Richardson' fullname='Michael Richardson'>
    <organization />
</author>

<author initials='N' surname='Smith' fullname='Ned Smith'>
    <organization />
</author>

<author initials='W' surname='Pan' fullname='Wei Pan'>
    <organization />
</author>

<date month='December' day='8' year='2020' />

<abstract><t>In network protocol exchanges it is often the case that one entity requires believable evidence about the operational state of a remote peer.  Such evidence is typically conveyed as claims about the peer's software and hardware platform, and is subsequently appraised in order to assess the peer's trustworthiness.  The process of generating and appraising this kind of evidence is known as remote attestation.  This document describes an architecture for remote attestation procedures that generate, convey, and appraise evidence about a peer's operational state.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-rats-architecture-08' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-rats-architecture-08.txt' />
</reference>

<reference anchor="quantum-factorization" target="https://www.nature.com/articles/s41598-018-36058-z">
  <front>
    <title>Quantum Annealing for Prime Factorization</title>
          <title>Quantum Annealing for Prime Factorization</title>
          <author initials="S." surname="Jiang" fullname="Shuxian Jiang">
            <organization>Department of Computer Science, Purdue University</organization>
          </author>
          <author initials="K.A." surname="Britt" fullname="Keith A. Britt">
            <organization>Quantum Computing Institute, Oak Ridge National Laboratory</organization>
          </author>
          <author initials="A.J." surname="McCaskey" fullname="Alexander J. McCaskey">
            <organization>Quantum Computing Institute, Oak Ridge National Laboratory</organization>
          </author>
          <author initials="T.S." surname="Humble" fullname="Travis S. Humble">
            <organization>Quantum Computing Institute, Oak Ridge National Laboratory</organization>
          </author>
          <author initials="S." surname="Kais" fullname="Sabre Kais">
            <organization>Department of Chemistry, Physics and Birck Nanotechnology Center, Purdue University</organization>
          </author>
          <date year="2018" month="December" day="05"/> month="December"/>
        </front>
<seriesInfo name="Scientific Reports" value="8"/>
      </reference>

      <reference anchor="LwM2M" target="http://www.openmobilealliance.org/release/LightweightM2M/V1_0_2-20180209-A/OMA-TS-LightweightM2M-V1_0_2-20180209-A.pdf">
        <front>
          <title>Lightweight Machine to Machine Technical Specification, Version 1.0.2</title>
    <author initials="." surname="OMA" fullname="Open Specification</title>
          <author>
            <organization>Open Mobile Alliance">
      <organization></organization> Alliance</organization>
          </author>
          <date year="2018" month="February" day="09"/> month="February"/>
        </front>
  <format type="PDF" target="http://www.openmobilealliance.org/release/LightweightM2M/V1_0_2-20180209-A/OMA-TS-LightweightM2M-V1_0_2-20180209-A.pdf"/>
<seriesInfo name="Version" value="1.0.2"/>
      </reference>
    </references>
    <section anchor="acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>We would like to thank the following individuals for their feedback:</t>
      <ul spacing="compact">
        <li><t><contact fullname="Geraint Luff"/></t></li>
        <li><t><contact fullname="Amyas Phillips"/></t></li>
        <li><t><contact fullname="Dan Ros"/></t></li>
        <li><t><contact fullname="Thomas Eichinger"/></t></li>
        <li><t><contact fullname="Michael Richardson"/></t></li>
        <li><t><contact fullname="Emmanuel Baccelli"/></t></li>
        <li><t><contact fullname="Ned Smith"/></t></li>
        <li><t><contact fullname="Jim Schaad"/></t></li>
        <li><t><contact fullname="Carsten Bormann"/></t></li>
        <li><t><contact fullname="Cullen Jennings"/></t></li>
        <li><t><contact fullname="Olaf Bergmann"/></t></li>
        <li><t><contact fullname="Suhas Nandakumar"/></t></li>
        <li><t><contact fullname="Phillip Hallam-Baker"/></t></li>
        <li><t><contact fullname="Marti Bolivar"/></t></li>
        <li><t><contact fullname="Andrzej Puzdrowski"/></t></li>
        <li><t><contact fullname="Markus Gueller"/></t></li>
        <li><t><contact fullname="Henk Birkholz"/></t></li>
        <li><t><contact fullname="Jintao Zhu"/></t></li>
        <li><t><contact fullname="Takeshi Takahashi"/></t></li>
        <li><t><contact fullname="Jacob Beningo"/></t></li>
        <li><t><contact fullname="Kathleen Moriarty"/></t></li>
        <li><t><contact fullname="Bob Briscoe"/></t></li>
        <li><t><contact fullname="Roman Danyliw"/></t></li>
        <li><t><contact fullname="Brian Carpenter"/></t></li>
        <li><t><contact fullname="Theresa Enghardt"/></t></li>
        <li><t><contact fullname="Rich Salz"/></t></li>
        <li><t><contact fullname="Mohit Sethi"/></t></li>
        <li><t><contact fullname="Éric Vyncke"/></t></li>
        <li><t><contact fullname="Alvaro Retana"/></t></li>
        <li><t><contact fullname="Barry Leiba"/></t></li>
        <li><t><contact fullname="Benjamin Kaduk"/></t></li>
        <li><t><contact fullname="Martin Duke"/></t></li>
        <li><t><contact fullname="Robert Wilton"/></t></li>
      </ul>
      <t>We would also like to thank the WG chairs, <contact fullname="Russ Housley"/>, <contact fullname="David Waltermire"/>, and <contact fullname="Dave Thaler"/> for their support and review.</t>
    </section>
  </back>

<!-- ##markdown-source:
H4sIACw5EWAAA+19+3Lb2Jnn/3gKVLpqYsUk5XYyuXh6syPL7rST9mUsOZ6d
6qoOSIIiIhBgAFAy0/bWvsa+3j7Jfr/vci4AKEt2Z3q3alyptEgC5/Kd7347
0+k06YquzB+lJ+nXRbO5zpo8fbNdZl2enjSLddHli25H363qJn1WdXlT5V1a
r9LzdVFdtEk2nzf51e3ers+TZb2osg3NtmyyVTct8m41bXdFN82Cp6df/jpZ
0BAXdbN/lBbVqk6SYts8Srtm13YPHzz43YOHCc2UPUrP8sWuKbp9cl03lxdN
vdvSd2+enSeX+Z6+Wj5ya54+wYxJ0nZZtfw+K+uKVrHP22RbPErStFkt8mXb
7Uv9Nk27ehH8WVTLvOrsi7ZuuiZfte7zfhN97Jpi4R5e1JsNvet+LaqyqPw0
+btuWhZtN6VB5nVJj03rX9ynXwhWm2y7JTDLs9muW9cNLXZKP/K/oqKnH8/S
53WTVfalwPdxk1fLrIp/qpuLrCr+nnVFXdGRNZv022JDUF/aA/kmK0r38oxf
/tes2cxoD0l/4m9m6Xm7WNervCou4tm/yaoqb0d+vu0K1jzArHMDHFzFkxkt
t77ubf9JdlUs4x/iqb8tqqype7Mu8dZsjrf+teQHZvTWYMrnBPG8KbJFPOfz
oqxpvb3f4mlP66rdlYSCXW/qjbz8rxt+WXYKzG829OZVDhR9/fXpbx/+6oH+
+esHD39lf/7m17/UP3/z8OFv7dnf/Ib/fDZ9MvN05sasq+mmXuZl9EiX59uI
FIcDbGg3q7ztol+arGsH7wVr+NuOdrzbTFfZoqsbgwaDoMuai5xoZd112/bR
8fH19fWsyjAGgHCcNV2xKPP2uP3Vl//8u99OH3z52+kvf/3gn387/bu8Lszr
32SC9ITQJqOju2CO86opNnn6dTgpvwT+9Ch9iLG+fDh98M/8pSMv/udOXI78
bJb+scgqh8e9Y32Sb2mhoHKwxtN6s90R10nPFkVeLfJJ+mrXLHfEGSs6yqYF
v7JxBHXO1rt3NHw0R28Ff5qdANOLrjuwBgOBzA4QPKtaAg+tZJK+zC7T18Xy
Ik9f8ONZmX6bzYm8CTL9xfwpL7p12putt5qT2R+JCBanWUuM9h+9oJMyf0dM
mwA6nLS3rvMZndQ3u828zP/RqzpviFu0aX++IeL8KSvaHx1vbhxnnW9IoDR7
GmC9b4tFmxL40sdFs7ikjVU1Eem6qsv6Yp+e5pCPt8DQjOS8beXb6+cPnw/J
V6m33ubVpp4XJVFiSQi9yMFFj5ucvmjz42+Li3V3neP/aZTjP3/5/YPvH05B
jA8ePvjd9OT45fOT6fnZNH5uOnhutl2uQhbws+CF9HlGvKjKSXK7P8+x6WJB
R3q2zRfFiv4E8Cbpn7Hhukq/nD2YPfzZCC/gg6RVJSFAXtIuSbpim4Sgss8+
c3lAzOV3/KUwXRvw1ZOvfzKIJdPpNM3mhB7EFpPkz7uyypuM5i66gkR2UY1o
eek90t2O0mV+VSzomXV2lacNoQKJ7W6dp1WeL5nfZiktuciIGBjhWihnpPuZ
YrgTxXBDB0G4224SCBR+Gi/b6NfgPk3e1rtmkZPyVGGpBelPM1rZom62IEfQ
bbsjYUvKTX/YlKgyS1c7UmFAEXTgTf63XdHkTB+YalW8wwBX8d6T+a5Liy7N
yrZO8woLa9OaNtikxYZmhdROF9nWA0tW0MrGaMSEVrsqLnYNYxbtv+tESaZd
5WWJR7PlElNX+TVWuBAmQ+Q2S5JnFf/KrxLeArLLfFVU8g0dBh3LplC6BXxJ
YIQyl86Cdk5a4443uqlJcSDAtDwSq71Zs1SWgeGy1GS5oifWmZGSnVUttjvN
LqqaWOOCQEtf6SG1i6aYYwtYwbYBL+HTsFPW42hngmmbYrkk3ph8kQKvmnq5
4z0nydcxVrQE2Spd5+UWe6cDEuwhyPSPaYKZk23eYNGY2QbAsVfBUc13RcnA
npc1Mb6i0iHpnAidDd9m6ZMd84mmaPEwHeGC0J/GmtfAh0qxOHiFAWpUkkR2
zuOaYEzkcvL4yFg00UaW/vwt2Sftut6m9RiBJUJgZ/WqC02oe89enp+9Ofp5
+sMPqvx9+MCokV0ShaVlXV+mdGxYzry4uCBE3Ra8DtLM6btrm5MsNOIsvJCK
ZBU9RzMTtZRlXl3kdrJXeUmMqCF0pZPF04qETmFkHMTWn55/nfTW2h4wENN7
MMeOeC0AL9tohBtPZDqmYwXwx9gOnS+JLpwxccV90pEaIGxmt8WRM04OmE1b
lzteu/IAItrLoixXuzKhvZNcoA3P0pd05m4evL3Mt2W9z5eT/oBtui0zIr+E
yKBjaQLJC+QiyBRNWhJBLfaksYK4sgvmORN+pljsyqwp9+n1miRHxEuzhMzR
C363I411koKXBqvA8MS+iNbwCxkmC3q1LZjPkhncYsiGZ9xlJZkNBMgrmhfb
JqAtiIhBqWuiW9gSGIPZ2jVx8HRZrFZYWjdLBySZJmq3R7DJ35H87AQ/cKyQ
ljUwhKBRks5RzAj/wMVBP7s2b2hFV3V5xbCYwQSCipHj0YqskJuGp43WO2Xa
PNKWzGzaasUP09lDPIDZMUzJfsqXuzLgCbPkxNbmNtWts464JOOSIkW63m3A
OgLAwb+QkprJq6CRs5IFlUOnQIy0Rgk9RjUbYXJ8qjVpI5i9rsq9cbv57oI4
GyQQix/MulwOxQRvGswqN1GTJyIoAEB3IoQveDWvroqmrtj7gFOnn+c5YxxO
HXDsaAUFbZYkSUmYtNx7nKMJ4JugXYCXOFHRhsoToW/Lay3L+pohS1yfeY8j
m2JDVMC8mXQqwBaenSXvA/C+YBavciRfzkhDOum6fLPteOBVmbVrllRlsSjq
XUvrJbOVFgCVI54DRFPp36uGDOgUn3fVZUX2/IT+YPcRvaeqxYY+ETxo8hyH
TpMTDyL0yzbbkvEkkKY0FuEfbaLdbzY53Dvpotlvu/qiybbrPQ2zyOgBqA+F
yAfB1AZb3dL2SAlN51CqCZB7JSkAms9G2DXeJ94XzpDD6VQQRjAAgRjK7Nhh
wgRAW5zzu0saPyXK2nudib4LJd2Bs9EhGKF0vuhMUuAjjpZmtKOZ71n7WIKS
s2ZvKEkfZfMlNDbCHpJLFX5fsBOKZtkQaVwwBuC4uhQaLukq2ZJ+qpuIHb2c
dzQKKKyLFk2ovOqI3EFGNUwA/RnI2eVbxpsNsw0ssesyEv4k2hd8OhfEAOWA
3OJphKus3DF9k7iH+gw9WKWfo+6ymDdZA7UPwJ6kka4Hp59qe3wsFzlxAjrC
WMdLnxKipWCMF2sWysQG6U0TRLZVDzNAjDSyfAnUx4mA74MASFIeGGDVkNbL
kl9kC4OWcVkEJmkNHQRokTeEECeeKEHOo1Spkj/GmtaRD6MeMZwswOiUdWns
JcSqgwPSiW4FSjOSOcnbNYyqMa2VmRt4zjzPq1R8WYL4WDkG2bDCJdw5UkiZ
vBYZiBgmMvGVNv3SCZ57kDQNa4tO9WaOusCDidfD2UIiZSyFp030Mvz14cPR
BK/Jboi5Q4EBZ2VMCzVEFj+kh7CLmEbrGJ8wq4iDdd7mhyn4OdEIqGwiRxqN
rPpRKQ5VpgKoIKFyLvqSYbQKpQkf1oJlQFszym23ZdEbQmBSFsxhYD00pE00
wFMaJJuwLQQDIjaBAncjz00Slbjdm6osSINdE6kRw8jpe93gJMUPSZkRZ90K
JZHFcUkf0len9GvAPOXcVI4zpkNBEBm+yui3f0kC5VA0iAr8q1rSzrzNoMdG
v5PeRdSlqIrnZcvEEKqEzaUtTGbW+UwNYG1m7KSUReFks8QBPKRTdr6q4pZ5
7RunSNixpWELs4xJDoh5KRrPZluwjkNC159ls6uYVdZViL3MxTJwv4uStrep
yXokxaxYJDE1QwMeOQ5BBOUNbirATKdhNTIhs5v4oex4SbK2rDPAuIVTiqBc
CnVCyKY183RQKAnowObwCkni6c9+U7ODVAxaXonv3WJEci5zGrUUE2QNRaTW
iYj86jaPtkHaO43iNsO8thCRAK18S9snzplnVwWtW7dJ4qwDHk9I/4TE37Dd
WWbVxQ4ClDkgK2ZgWfTHvH4HNnFNgF7HQoRON39H9g6rOgGjg0n1EW63IlUE
E8makp7tPmGXR8nqHFEAABcrrHDStCJjiQWBXfvpSJuw4cgKICCqEjRhjl0v
aoUtuwag1UQ8ReQBI6eN0va4KHuIOuEtV3RU4iLyXhHl9R0JOfilLgmpepLz
iWEkWJSp7Vng9KHRl0XrVRAZLtHh7rVHOKHjQC4QfjYQoBPemu6YzhJ7I+Vt
6hTsJeFU28Hr1yb05JMXZ9OzJ8L6EXn58GEGDZnQLHY4qPzlszNkFh2NEA7i
PHThtsmOHdxYOVnoDcElYy5bBVwlMCkDDgQCYIesOyxaG3/x4QOL1ipPxsew
50nopqzlN2xPTkBDOQuZFv8hfidWJouue2zLwtI7SldgQWTltcVS5fWCNhm5
CVgusw/N0K23cbZ5AvyA6KPhGoGVF1zskSVZFWCN7ghTVHnH1MJ439Ww6b/R
7RCoNramzQTvgdGVUPNojqU4hHi9cLY4p8mjJEl/wbEB+GRDfHeyA0TU1HPo
QSsyU4RJCpRAoQRVVT2WdS6ymQ42uwwJIzbuFHCB2YZBxBCR52V/PDlOnoWF
+jW2TPSkLLaduedq8NRCIkqqnu8RnEZsHTyPreahz4RG3VUkz6FsEk+ZMSSe
Z5ejUPD0zPCA/4KYkMHDTlM1CCwEAqzM3wX7XZJFyR74jcxhei7LbHWtOg0B
Q2xJjRQxDTrNCR+dQRq4ekW0p/BxdWtxeEIboNURzyg4Egj7UPYs7JFQ8AIn
2LCGPmetAFYDHdtirXYD5CNx4o6wqpnIIML5nRucFRHzTNCQhSCRd0oAnk8J
wo0cVApj4WKf5jB9CrwkWoeseQ6lpdlPtxB/kZbhrM4My+idTM/p1GRkQ3Aq
wq4Ktf1ruLEGJhY4OqOeWuATda7KQqcQMXSuxN3YphDXv6xJNneqGksKs6vq
2ObyPn5PpZiAN3A4SKAeD6xmmW8M1mKkOK8kHRErFAFsSNtYgg/EwGbiHOLw
ctnAoQb3r7n1aN/XrdpgmNxpLqzHZCvE6aASskcb4GHpQ3utdmrc6hIIo6AP
7joxVonf0UQ0GztWQoc9IUnTafwji5z9qxr+FeGIqpTSOrehTza0BGbJ21z0
mfwdW+JiVdZ1x5pZwyCFngRvhQLSAi8RHvTPYpac7eYtURg7jibEiIXF0HI1
XycIL4TaMJZA+zFVriA1jSQBW2dRQAURr6vMRWniY5qlL/J3Hc9K5HSpDvou
ck51zU5iIbZFRbCCCXE8IEUDv2W5syh3JMcU/uKNYMUShy7qwYwDGezBrER6
YZ7z4Kh++CI4uA/0+Bf8c9s/bPYmiXcdZ8u4iedI7PzCO2KfgRAfjTht2EXc
FputmIzpz/jbnwmdqgOBPSMZnCvsEuoMEYQBd4FWynzGaLNhPknHrAhbdLMx
r5GO2hYte+w3u7IroECJNkgLMc+MGdKyglAFhQNnUyyI29cIDZVl3pAhAjOC
p3U+r4yXDAqFng1Ev1I72g26IGtqwrlWofUplqkzPoR7dwWjAHTjfdvlG94d
JhzbVuYNE4gbJQhgpwagNOwL/YjeArdhYPFZYkH9Y7PPsiz9knFR3SiQ9pL8
JYjCgb5GOF4DOrzIIW0ZZ9lxoLNFRo7zfdi2WDt2G+lyxzGz/rmqp89BNmYd
s/SkGp3JbaVVOQ99mRa9ZH9vO4kHDEdQk0rtx4KpUHQWyEwRrFAH2CVWLyVW
t6uwg3sWgHWabwtvn4YIkVs1z5cwRUXgsLOez/xoBjJ7bqlMaeTh9phK1D8F
DgWspg/ZWfxu0QZ+0+wCw3TqsPZCl96lh65IL2pjB4mbRbRdWWRMIOm956dv
GAF7lEMqW9EdPcL54AnQjuQebrNFwOZJdymaxa4wHcOrLEA+BzABU8vu+LTb
b1kk9meUs4L8NJWtJpthkxOF79N7r0+e62ZZhTgillBtd90x7ZH+k957dvzy
KIVvRpioGAmrnFO/2I1UCRSviowzLjcwsGDOOIcG6XHFduboLf0//+t/y7rx
EH5L753Vp0f0dco05Xwyyx417YXpE9wkBAMAduwIgPbGTBZci4Yw5xrhU7Fd
s21kKnzLx/UaJv9TNvFxpE+9Kk8QefpUDihQ8IWPCdoAI8yvfwFlvVLfpjuB
l2fpvXx2MZsgf3H3bpK+JQqrrwnhT6plUxdLAvLLsyMwHqcjs0sA8PyrLlQ2
q0aZj532aaTVlaz39MNVQWfb/otyZTP5VPc4f/p0loo1Eu5MDj8g9Tb0UiHR
oonMvV011QgNQ9ICzI/SMwI6abESKjP2yQ5mAQvtcLknfqN/q/uJncK0gJdu
X2fK798cxADPzao4/iMrcsh16pCLz5P+sOyDIZ31GSq4GsiSpB+H5VYq33ac
h2Uc7fTVGyOlCecMB6TDRAPjnMZcZmzS1Y1wXyaRrjbyUV7sp5sEtGYqmLkr
aCWktBQL3us5ToL2tkAeFHgAf87480SM7xWrwwQpcYU8ePirDx8mJAkhqTGX
xN+ElRUdp7Gy+EVKR5GBaezmhBocZWUpR/xjUTDswHQZpbD64LFCgi/YIZFH
saKDLy4KpPiAlwnrmDiDzA+YcFpWFr7vXOwiQQnJGQIhPwZjdD48aDMBDCyi
6bY2gFp6RqeS92HHZ5XfBEGcNliqKGAS5WpUawoGamUkF3ph4wvcWv7kSONe
Q0CRxjW2Gpi3mEx2ixc1sIOg3T5aQ0jPs9HNSWSIToJ0KCwjkn4qEneVAu/v
vIMWNjxy8ZZkAMhf7E4MXvXwpTdOQqZy7/ykFToM1QqH8xpx2XHoBjjJ/Coc
bZRdY9ynT3Xg3D0R+2b80CgouFCmKMypQHShLhmfoWphS+lrsMqvFZZM133x
j0np7HPCicNp2fA5sm1xhlSgdV0ukbfDgXpvT7TBbwMV03E2NjhOJN+RRakc
jIWxlWBF24ZVb2ZLHD8QtbfJDXecOaB+u1RTQHh+MZojb5IKBgjpKnZ6zggQ
8hdyn8jua52eBNd+YPEH4UeO8/EZi99YhYBtseeGGIu5sOWS7addTRrg3oQj
B3qZY6/KXOgzSiU7Vb9Q2/vF9OK0vq7kV2TPBwby1DF+zsfdNkjNWfjRJCwD
xxKeZdmF9M3UGe1F0zO4l2TmLDo2D8Wb1Y1sXHSr63zO5uQGmUzbNaidKKkV
t/AvyOoW32oMw77H9RAQHeQYbjAM9EXkqjC7Cdetcitgpq+gF8E7CHw5UY5L
6uX5q5MjWQn9BedL1xREdlJTE/FJli3KbdTkqJFNkrOkdKEueso88yHlKGrz
LEButkjBppDFkDaSLQDfQvhOem6ayURlx0t6skA++dO/7YotIymZHzsURBA9
k1r/8ulzpAz6B5+IDzB8isa59/IJPXddwANO8p0zNmlpzmdv7tXI1dnyytU1
yizQGYNqBnDqC+vYTDriObUtwz+rdheqVSrho4g2pWoNpC7s0vcdmS/XOX7U
YybUSZqYohOh95T9poEvwqXFNLwMw3rBeT03JG+QMnEAhSdxkEkIQSijHy6e
MT/92pR5rE7SD4WDPHKSNeXEHhfhUocCkFi3NhG8Fp0PQrAN5Tgi2GRfsP5W
tYqfiEvhjDV08VzD3FBbFD1JkkBtWQa+HMdjMZwpPRLJdiaSG4EhaGEW8WX2
9IKeH0C0d2fYAsNdRIDwSt0f3oMuGrLE8M4l6CYnG8f1OJ5JCm9ZOOeGBuK8
xFbDQ6fgg8vF1dwig/7Lo/RZF7iyLZ9HAhGFRVIyyZ6zXV1Jlr9ETRLN6/fC
lylqhSw2dotwMEuWpecsK2aemKYPdQnVVb4fs+GdZ40NKNOziRaBv6S4Iqta
pUAaeskE4yMdFEsi1upWpZCz7CReo67ql7KqzJJFwfwbyQu+gTTN/9UDyGDi
g+Cgd6OYcTYQM8C960xWjSxDdeFzVCTI4wMtay2GpimPZzVIlpJbKtCFoe5D
UZI2KOaTZvf6UI+LqCtwkMzlR4eAH1u30sy4vwY47szhYDtKGumzVZo3DYi9
Xix2TW/K0QlZjNU7FCGs65qDtfT3ptWoKNyTLj9uWbhU/XB995x9zOmLkiB9
OAx8xN7Lt/jtEgmqgGvb7jZb9XTzbiVhxePDlHVer2xzqFIySE1yBnoZ0hsj
dsCJjSuEA+eo4aFx9wCC1snMoUbswCMIrct6t5zOs5YzSzhyz4nM1ZTszQ3U
JYvnJ1Yh5YbDQM61BTcXKrwWrgDMqW8nfWbV50w8GPuS58JaNVd2qLRGFFFo
QNzrquYNAIsN2fhE4jYS1CjElcdah8n63gK7+ppD6qJkiF2PcWbpGfTJAPRi
+hLzlqivhb7YQOTIO5xse1KZyLqRooVFU5Pg5tHMrd2bXUGrQWl1uexTV9YT
6ET/Anx27hrsT3S5SV9D58hGX+WcRVERLqLdmHxxbG2hX5vpQlK+2BaKdgKg
oYyL4kcz8M8RPXabNa26pKElsufBgqY0S17AsHGiEs+s1Bi2pyx6OFjD7MAe
UGWg26jL3O9AeZjHSGWNHrcmAZyNf4qXI/bGuUll16pcjYUBlQpEI3A/93BB
5dK9suapj+IjO+Mhegem47LToB3kl8YKiCYDejWf0zmAuZEBdgYVNsisVjeI
TxjiyaY01pSOCLQjBT9b09qCOhE5Pp9fHK7u2K+r7itSajJr9kAqA+wlh6Av
6yUlzB8Yq+B2FjikOVFCnld9/PVHMnYW+jWiQ9e1rKfQ4oNaw2tbLgyVOTVP
j9lYaBiI5smozPUPolr5UNcv0scuMAT9OIgwsweLiG8hKe2mDqmzG6EZzYJL
axbOg9iCE9JwJhphcqAtJk22TYDi1xIPFDtFR2cnSdyI4ocvIj9Kwhm1vrCL
FWw+STam9AyVMitXl9IFBWCTRBBn2bjUcpcJMsg0kBwn8/U7sylxxU90EGv+
Lqu85Y7kDS1H9gaL9xW/OXtMTDN5fTZ9+MuHRANkS4V1cc4285MYjgc6CJzr
eUdmi2zgesAr42w9xzKT5BupVY6D2YGHG2P4EF7t3ZWaONJP1LbUtkeoV4jW
HYf5Yghb4ikxgceaFjPgKIb/XuZeFmU933OAEqSH7KU2yd8t6ABF70RtULWE
nzV4FBPTPqfwyUTlSxppTixvbpNfZPyONUBxjxpnhjU1JQWINJJhmLJNOE9a
Yz0dV5UoBHx+DEZuUDBCI4u0ad2OOasJGbWSpuGiazwsYfQFksUkTQuENxGt
339qsgsuoZWKKNodiL8lVQqODfbQ2jJa0e0hvARHm91WqzwWtX2w/FEpRWEz
wrI/uIQEyUh5LFX70WlopUgKJkEgOTMc+UjvbVDkhm0h+SzQ/o94qqDUFbKc
QMFizNiFxhIyiyZAFbJ4giREbIC9F3lYxCRwW+ZuL8FGdtWWEHQi/iVLXjBD
X75E9ZBy9QOb1ZXHvF3LsYKTZBc2KedXwqdCQPCpi17GW9Vgx2imgMDX/LCx
wRUyJU1BCnl91+blapa+qDtNHwhKo8gkyUokBnXrTStWti6OY/icMqhueOdk
TwIn+0QDviqjJEbLrzmz2hUKb+rlrpTUmEJe4nSfvGQ7Jwl3oZBokaSghW5e
s4nDCHzCP/wAsTGVhOAPH1Kyya7bQeKVpfP3suu5CJN950srnFLdV3Kml2FW
NCfsu1Mx+x7mhNunSuBJkCogkHWlEMwqkIfUtmy7EdnstjiuAU+0Gt8xxQKZ
i4Wki3jr2fzKswS5sWTMT5yPn9fAxuOA84bbGzF82xB7ujCQgHql6kIj1ebP
9NEEGm6LSp5+TYt3Wyh8SNNhyXad7W0NyI+0yAZLWyTZw/WKcL9UWLvMVKZZ
aJWIWzOixIV1J62cmtagGX4dcLlMRpQ2PWqfiCqW/A2qNq889nIlPoPXgVzz
hK2abMEO4qJdS2oFfOGc3nxPRp3akS+PJmmy3REjJaxyUbg2vad2f/icxQbN
9xxIBZeiQwS7nzeFL4c8Yvl+2pvVa0o4AdEpmo1m746CgUdDBLbcJ4t1vuAU
4nu6rSOfRKwFkG9xeGe9PQTFwYccG+rc6R1amWe+V8C4x1GrmCQtkJOuWVtU
PeBvu6yE7GFVKOnhi7quRCBqZmRUOM4aMnFfVkwl1NADkmBRq2pBqKhE+Gl2
Z2t+Lo6uJd4U84bY7DD0hOJd/wVVw9j6kQrhjPZbLC4T1eJzThcPaN9FJze1
VhQoVvJh9LbmKGWei3HFDEblU3CIiTtEJYXQIvSaf3qZ51sbSCR56EzTspsQ
OXZbCQ92WlfHTkDaxIuT89Z/A5cLtIEcicdlJwn5BPj8mmCCwLEkD0zTN+qh
69HJACfHMRGkKlUGAbGCbPpuccfJI09uykOLive3Hc45GUUQ5rg7TcyLXB5D
K9kx4aQnXmi7DrH7LlB1yrbBQsGmhjueCCumpeDgpNDHYNMPPoXajCIBI2Q7
vgTChYqwFSZlEje9MU3NL46T6JmktcREak46LGyrllgYJPm6Jxp99fVVvheJ
FmRNZxyTzOXoSHa1k8RlSMLum6RvTl6fIw/s62KSPv726YQNE64VSN+evEhd
qyfunEJq7NoCsI6sJbltlpx0A+2Hi+WSaBG+IozjG5yfa6LmUfr8385pNaf1
yStRbr45P3+ViuWfJ6yabustShJGavL8yFbNHrl2zvsFr4krqxFpPfBVc/73
0HcjTRicJ8kM+qTHHC2SVohtY4WkmpQK3hWAluuWoxAqsFN1GIRYG9N+/MSD
dZmLnq1TGqRDudmcmMASH4JyrQEo0hgUqPVBz8mlsgEWLtU+YVnsh/nGyrxQ
FF8JA/bTDRbPjiDszxBoYr1+JOPHcXst6qedwu6TgLu2K5nXJH0Resy7DBlZ
bFQ6OLB9qEqr6LwRt6LV+OWtCCOrJfcbYf1N2nlIzSZJ/suEkWri0g30o1Ux
8llqLajq1ez/t3LJdcZ2s43odO+ghD2okh4ww14pTSGqMkfZrcfTJHEWiHvV
auq10NpwhonUpZIwDEU+uxwKZFPycgx9a6kpd78agkxcZ5YsgZK2UMHLunFT
u2iIpRjANRqwVCl4RsKmli2KEsqqOU1nwHbH1OpvOfSc0qne0uoCDaua5VT0
cLbCqs7ThxStKqsSL/yeTZjwCWKo/5P+Jekn/bs/df/uf+IQ74M/P30IiYV8
1hCfu4rbwMLJrvsud364lN7LwbiH/t0P9uGn6I3zPv3ov/fBX7a+O46C1eiq
hlu56WV5wz0ynb6f3vrt4+P7fWC8T7/7Ln4f6zr0enT+7v/9ABiXH9JVxus6
TiPAv/8Ka+BhbITj42gL3303srP3ahbI5/f2sA5xHC8PP8R7iH7jP+/z//wY
x+GPI4PI7z1Ifude48M89r/7P4JRjtPRf25CDHIcfL4KnrBRDowRPJvwAO9j
0lCY++PTfwP6ud8b5X1Alx7uozvQUGswQziKhVXdKIO1yJ/PfeqAG0VRYGxH
wf+l/QGjLz5hlPv9p4JR6D+ajoSPX01HGdH96e/D4x0dRbOZgt9H1/Lephsf
RRwd6cdH0encKHdDl5gWh4OkERaEg0TscxS2OsgQkPeDt7+LBgn/8RfHSZ/0
/T9POfbEKPJjCPeEZQr0Rzg8i42gD1iKwXAAe6KXoOAHGHDC4wHtfze6jOPj
iDXHf/T/9X7Ax6T/+wHJED4h/0Rb+uFR+kXgz5YOuv/tZ2GgdPazD0NbNW7x
oQaCs1zZyTffkVLOQRPUzqIhn+SX9dqViKZrNhVrtObvkMZ5GCDUBIPBJ2Ou
BtQe+Qyfnko+k+JbDkprEozzrkgQ2SUMqAs/bEgIy8JFf609jYtJahM2fajj
RB16fal97vqOdUuLdh5bi1ta7olY1GIcQ/2/tnygvi95TQ/lZNxxLU2CGDAS
wC45K6pdA6wNipu08j80Vr1T9nG5y7sa0D9D5iyCZSdwUVWZOFQnsWUjVe7O
brYT9s72fgBLXFrSqkoB3ju9MGlHC4doQBeK8WgD33qipnnlfX/qrgwrVAbm
Pla96Pg4irh5jkbT0O5FM8RbbXYkTnyOMrRBxg+dhgaRLM8jQaTQ0nxCSOHG
iNxnnmuwYpg2O57/w/ShuebqOnaTkzlHB7wrlxKxl3646urq1/NaWgtnNWnr
TK0ZCoBwop2P6Nc9915WK3hLZrA0FqOt4FwA+yjbxTtXXStC3hdHfrW/yFgJ
tVZiyfZ9doBbRhF0mPPRo21TiH9Ok0etMojTDJWQ9OysC6NLP88W8PiKh4WT
lAjYW+tBMuiHlb41unPjIojSi1ZoGzbuj5w4O3p4mot1Xbe+4YobkrNBW01o
lTHF7+qecEm6sqAsWk4/FDNJ/HK8Wd9PGczLsg2bhgqHqYNVNeqM7/yqeCSL
3ye+uKQe3/FskBJsg0vVeZXAM3j85exLTens88kRYM/SV7t2rS4yM++GzhZb
0yvaLoe0rZW4+oa5NZIXbdpquZ7/FUUBUeekPni9E/fZ6sBBI20paIGWjWbS
VEshR7Rb7erE2sMU3SSKuXY+SVo71YtLEbECXNGgIRB282RFp9k0lvHt87Zj
rzne9m720Fset/HV54J2OFkc5DvUtacLWFaSqEe5qYl0eVPFxm7n8DyQ0/Y4
90bBikynYPx9YuEa7u/Qa0dtZSMBSrOrMlvlUbraswCWxh8grsWpvdAGMBIZ
Fk+Tts9TlcWC01EeLyfbL+oL5My6MEicCNdLWUtYgOERadepx0SIwpXa/aR4
E6WswRiMi6BhnjGVeFLoIxYlj4kxkefjasmidXybZYOkJUmSyTAvSSKN8kKj
daZlp9EjbmMziCQgaM/VkOzaTaydG7N4rHVFLN7LC3Mc+xw3BKoR08BzmpWj
zsHEpRvxC8pSlzuXe9svd0BO4DMCzaU94HjBD18AZLLiD5b04Wsute/O3LXU
R7NZoNqFtH4d00v7KcZJPzHhEAcdJvYG0eDB0wkYj2aBaTPCuFxHNp/HizkU
tys6nzkGiGgkfsjLNBTBMVU4BRh7xFvt0RNRKxXsQWoRKq5Bepa0rJcv+FRY
p30Btwy6XDxBg1psvSe9J7g4aqlt/IPCtDCnxhr8aLtL4ktXRZlf5MdSNcj9
JZN7EVRY/yvy5miSxMnfIUR+HrS4RqTgn3wnXVeSLpkrjHhFp1c+WHVxToJm
ui2zxaApjmoZrvExNxCfg7UZFxFGlQQs4F5bbPiiqVyaZodADOnynxzEDFJ4
QmCTONgIVI5kC5qnxXJYU6zmWqHCzOmeh5EoNrJjl1jKmHOku08baKcvz0yT
0qCT7tBWHar3hspWK+HGx9hxdboF5F6etQZD5L7Q8YT4hXVdwpgrvaLPi+Wc
Od9YwChyMI/on551hGzaBY5Q7cft96WFDrelzjVvKyiM4F7aiVHysD2PYx+B
pNNG0FF7WUsJkwHBoZJRlA6ypX27bFJ6DjRZF2N+OIrM5YKmVlVi5o6DAifo
GCT7aXK+356aEsJ7xIPQ5oNRJNVjZDViGrMk612o0h9ClGTco8GUlwyt7XE2
nl7nQc6x78w2VIQFOUBcZbYN0/lHWP6AHduO4m6oUMG0qdp1zdoJoTf6LZWs
G56MnDLLWU1zHWf4IGHYygnfZ2E5JkPynqVParn1wKeR+0ZJUkmknSl8T4SR
KYNOmSPrRb/4KIuUqePwBhR1HD/kCrocXf94c5CO3H+TYU96EKfFSh8c0A8f
/tLSg2w3ieUhjK+Ri/WQEj/XgrgolOv6BZovo4/thzUUPsSo8au4O7JBE09p
7ZO1MYQtC/B4jCdBgdILB2y0xI0mZdbSB8+VLxGOjTT/GPT/jVOGUZqn3UdF
5vjkaNUogt243G7jF2P+LufhQAsRzZUY1FdgPORoFVk50boIqde7LpBB17oO
AyTYaDWcB99zgiGxVbIYuPHmELyeXmOq5KtWKj11dTT1tmj5Va74wns+4rFg
J3g5ewM4Jr5jWpzjTl8EHabD1oOcKJO3N5GfpHSj4gb+Ppqh84InqEc7zMJU
DljWQSLq4c0bMSWHL/mJ7uxy9UwJJg88z5u5AVt7s8M4tzy6sOFle2CjvtoL
egLfbZKVySLKcRi7vie28hKoFdJzVkGEpsBo8hn1o03lIgQWq8pV4p7D4T1P
0o8AZOqLrMhA8ZN+YAWKc6ok4Qjjcb2ott/p9GKiulmKnF9z7ycpaBXtWKVi
0N/PJ+ZhKPBN7/7IbNRJ38qN0lvFSZmpReucd33+py5MlOZaR/RU/SrByNaW
M0DXj4zLrtcrIiNkpo9xzNZTndXgcWUQX79wXSc+EKHaFY/gjHWuHuDxHT49
Mn9Mb/HOgYllcv9RZOqGHtFJGo8kxQtd9Gbg5mag9t+ZJY/rztIP2zwIpIge
JjpvkArG/DjMHouzJrUtJpLaiaYD/tN2sRdfAXfPrnGBfYBODQez/2MZ8Qg5
c1NY3+0QoywSEhSprgZODl6wgIgtAa73HKJDp7UXzO1hnEqd9GFhxhL4jNur
jQabGBX16iNOPhb9gfV9Tvz0HmvVdK1zAUexSMPebWPJTYS1Rhs7r1D2tQXj
pKyLQbpK0TVXV2lBBl/vUzTL4CYSTy8Hh55p63e5AWOcqzM6ak4s1//X2uqr
bwTP4iTI2Koz4yvuuC/QMzRjRJoizxYthqfcg6xvgtAUcoJBrxorBCtN31Gc
jnwWSlUJ2iIPF2LeJzkqHO+BvmcD1UfamPRkPet91i8yku7warlW33YJ2FhD
lTO+tYj9Kcie75cb6uUnSKbb1i3bOVNEnSSE0mlT3HHW5AJoHAQZRZPDO05c
hLUPbnSpOfyelM9Ld+6mzVC06iox1aPTDlSL4G6AbYMyMK2t9R4mW4Q4eeXu
Jeh/2kKY1Z2llx+D0rWJ1viRpNvYhX7cVHySuLKqILAld0llrEm7oIAtOxh8
yyGfLJE7UbV4umgvNbwdMTNXohm7VHoKZueOzWscAixXdxu9wRU2rEOMnbwE
DyPnZJqKjKtqOEcIqKWnLG7Jg+JJ5bOWsakV4q4xeBpX/4mq5Xr40XpOo9/9
tVpMMGuUbrqWqpOR/o6Y+h7HD/p3sR1NbqrTbOUt9xJvQd6L7idxdyvOHPQi
K4wVKXbNjLQ+9MWknTTVGax/lt7rhdhlRnFSosmljKRdeTGGj4bfUIV6ZKv1
fI4dOt7uIq6HrODQmCdGW7qGm6YNBvTLCGGE6LIGzJcSBZaOrAWsFFbgzXad
NeKdHOuZY67cfr2Uc5byEDJHnyf0TUKuwRC9U/vs8BFZsx05yVfcnksBsCE5
szO9HB2klejFBwY1Vy89smtWznJeUNCVcXDp/YcP0piZnVh+z3Tidr3Z0RhB
9nU9Kw7uSZmJ0xgO3NSn53WdtZaa3r8iJIvvr7zk7jiWzBcvM/kCPexy18jQ
AjY/fKHNGIMLY1LCsdJ4Nzcjs06TcV8F6Y9mPY1L3Bye+PtoW0LUBYf7fMM7
tOZnC5ZHhVfwivvdIuUCTAU6QuLuXu311wp11PDi2xbthAvhOZnyzUTb5tot
BlwrzXfVmnu3j3vhwU+G/kGNGcIydcbjJPFpK8zs84oDq9L/yNGpu8OIj3qz
qaux1pZo/ildsAk2skS+DyCHMs1JSUJf3Lu67XSkSaz4Bw3qEtdVG4Yfu+6E
8eCGOlIKgpbXrbTmpeWd1aetyVuUX2pnOlYAM7mDERf9BfX4cqFZrbVmq+Kd
Mh906kuswQRah3PzXb00WEUQt7clYcyEEh+2s34SXlIRmIvbhujHescXwXKd
3xuHxHGXe//+7NXRLNELoVkpIpWKeCQUDJ7VegIIP2IFa8RASMLSRLMNuCJd
L0/1elNRKXhEq7BRE00pC6xjZ336m/cGo+DWI27GAV02GS4sivN2kSnMOv11
tvVqXLWMQzYR0p2+eiPocSbqyjR9AYwv0+cA8yvgfCdNO8mOrFRdjy5nCJsj
ZkKUKAuL7kqUwixc0Iq+nBML3bVuDYQSroqJTQ2sS9MKW1OmkKW1DVbEFwVv
1IzTOkDrWt+LGdSqO+Niz6NEDnRZSPMWVoJVW+M7qAQAKF2dmSRm/dFjHNke
cKcaQ+e2i1bZn/Ob2qBbf4iHfKa3Q0RwjG6oJqVqmbfDWV1ADQdKIErsMnSb
1CWJmRDSVhy15mby/V8mhYFpicWkw4qmgOFGfi/VrHRoQUCzSxQvvdnCKlHQ
bKZ2FWDS8OmC5XySdfXGWqzSY0pZzvMadhP3pcuCwU5tfG7GB4GkVXdakOHC
rIRRzmuabK9Mg3wRRbYJ7pNFOdUyGXRx8VkM2snFN6LhHLiQma4au14n4YuR
EG5lbbF0ijgZM8Vu4wdtsuv0xcmLJ8pIYNE+f35q99ozDWus+2+7THpT0Ula
WpSIyTZOeZXFcXMWdvYmFgxw5hqZjUUetHUd6d6l7i6XG1kjXStIBeJm5DVr
QtrylCEQXnMcqEnK0TO7Mkic0O56sCGv8y1xzbHsw6zQPmg1gEHjC9WLg52R
CHvXeelwK1DerqGejPRMitPAOAyumT2+0VhLwOQwHh6dIv8p8deOahvBfoDD
CuT5XlqfPyE1tq7dI0QHk7ylFAjmP9kRGvHNAlDNQRnM9fRuopg9s3srCP2s
4eKtwVTQIRkEoyJNeDGuQOAEKR7ZsVO9v5v2TzIdJsIfjCsZs2BeNR/c5aiX
cifYBHg6C79dxTePiZKKY1wYFep8XucBW5cMbJXkzMlnyRvjkQ6Q0Kh7UfiA
Ycol08Y39XIB4sGtv5OCbaGeVAyYax/0IlLmu/YTwa7d+snAUbwn6oN+pt1O
k/MeWOM73wBiZDoEgeiNS77RlyTuKUlXTumbsBsEyeYR7nixxJDUxUHE8GC+
veSgc5vplX3xhRG52Zv2CWKy7x2D215wfUio6zGg2Sqk5zRb1WMBHxMnvKrb
2+YdOQ8Wt9CcaSV2dQQp75JobNqc9TN3o0NDNtJNopxmTnGNcUdvYlHLrJVe
TmE/MjNSxFfIZG2JrnO3/KVhluRRCiNjISS9yJL46dTLT1rrY9+qI2rmIYkU
MrV31QkWykjGe71aE4zMIdE1uB4yUy6kHZ9VZorAleBU3AguajYh9cPOKzqx
cD6XRV/m7opSSxdtEwkNm9CfumZ7/buo5Wannqfe+Kk1tXJ3Nbir4PrDuA5F
pd4ZFj6QW1iwsKau/pIpsH/Wb8MX5Fpowyz5LvA5oLXqNHh+ys/j3hXrQcG9
yf+6a4M2ICxVmC51OSP26s0z2mPq4bD7lsM2C0Qo4T44CseRu2V/79xOyx0P
XqJh3YVY6o1X2aZnqqiOVln09vv0ieUGvyfu4yd9atB+n7yXeqdHQQUZqvHO
JOj4TH13nc/D7LmY/jtX4t3yGoEYdTDPN/2IM2eeuE54/x3VcE/6rkGe4vnJ
aeoCjiMWHEZ/Uvdv4TCnhBXiB3fGYiendbXU6+tZPP1ZbqZ89mSSnrIi8ewJ
T66lbvQJ0zxrw7Agt/FNtTElZ07jQp8QXmesusJRKr6WPs7f+/KIx+VKBg3/
BnDTxbsZMeRbJLYL/8ZsDFpCt9u9/NwT2wY3h7Y6O8mTy4Kvxw3Oh69MZLTt
8O4b7uAX9q7jzBW+mwNVX+rgmdmGmjxclIJs7hv/YswnoSCoLYgVd7jtnfab
188ARreT0dkCJNNLgfg01Fz41pwEGP7UVes8s1wErhLlksCIJq0osF8oYaTX
coUgHWlwM0KvgAsVQuVStAsJWY/2yEhcEjgSqcjIujTjuvC3L7Ox44tEJAST
XO1KqJOuXZNzXvTAKBd3cAeqIPeSjCPOJXK5wmENAfGZP+X51iUeSy6oJvnH
dxgPuku2uIgCFR2tb4eViONLL53Kl72+xc7700/ikZlRA8GGkd7LNNqG0dIm
www+a67ou52j3oZLvnzXEX/fk6je7E7mE2GNo2/b4TyxmNgRIfLUjFLrBLIg
bBRPNRcmonUnB6f+7t9JLAjR+XA/FzFqT79Z8mrkLdwGLNC06iTXdbfvH5ek
RPRT1+Qsp/wGinZ0W5K0wqn5mhHuxOLbJfquLWajja7ObhoDISS3umjKrg2Z
k66/8tdzuo6vK7k9JLtwoXI6vcV+odlYMkWSDW7GCpqAS48vua+P75nCyWtq
CT0qtQk+rmp9HX1HGXoo6p42dpyTxN3KmWnreS+iJyrJxT4q91HfK2xK1kZK
0fnJz+2GNd/dyC5j0FAWv4DnrJGrT+4IjjNhm7poltLxUUoOuWjopnFHFh/N
kAQzpP0ZoOeyYxRw73FQxFBa/e2DZasNEhmZFt6lIYMrxGp13cEC5sIkaYOK
Mja4RxsV0tqFx78njDTsbiSXTIAtkya2yJu5tS0N5Job9FFQzomcfLtw0he9
JnIViZyQ6/AK60auChjMrEw8jvAl7mBw39rYiO4y36+lQCjxvtmbIodipObl
1kkFCW9m0h/Zl5D4Vp9PqyXa/uXs4LLOs77hJU/S46ThCpJDVw+cR3H8qJtZ
I6ov4x8eONyaL8iQPtRCGX59x/o1b9q50YznulvhgjCzpFMHkZWgBm6Yq625
jvvE69j3iBkt7Gb4MYdh0GMymJuQSAZjCgiFFWcn4kZMi1zH6rklrL+o2c2f
uDHcIthLqfXbXg9zLXTB5pOgj+7MqzouwjMszxbgcxNFvkaDA7O+IJyVe09S
fngT2UFfWr2hN7aexOIxKWD6r4urh31/TaNxLJ3DIOxSaGvXQaDgKiR6f1qv
pnNWzbJ2bSojd01Y7jpXKn3TvWx8K8Azq3sKu6VF2FPVIb9kDOKCk32cjtLr
leBKUGprTBa4BbLByQS04E0sM62SAfE1ruewpX2Zv8NjhizeJYskrNVKIXh4
364e23w/hPxskFCijplCuuTlESrEF9mFewI39DkxMytuZazov2QSw/po3nSA
yceRwhXh38BY5faPEV0swIh+Uod67YPsV3Vhq1KZXGd7z3zYExxlMxofvAdd
SlM8ffMFhf8kkVCd3NRRtsK+LOXC7roPb5eyC5rJbsMzbJtwCFBkqfOtCJSP
/a0z/V1kqdsADZfsWunvAUvpVJvfPQlbnrywNosk3cvL4JJfYuDDrpDt7Bbw
7jPdwP/xUVxc4I5W9hDlx8GVvOy5QwMNdQvTd8nYHX4Y5k6LA8u0hBRur3ly
yFsV9ZLxFHeoC72ka9pHjq/BLc025CzFfSA1x5NFN3p9djJlPvj09NSunzK6
SySQbEIJZVlOY5NYJ0fcdpsp+FWptyQBajSp3fCilSKrnWSS7Cp3KXUvEV4a
+L9++VyKyrXFp/AizQHtpjphorqPZ3y2VFPOkWjX30+rBQi/+c1vP3wgYRcW
lCqaaKfPJpe6YvO/C5fFPeELMUzghXbRwURvRnRaD//KlKmpSB+Hk6jtRBC0
SY7Z4OqKjbD+LrXpELYmfjZxee7RTNzkeZ8EwGfq08lTN7k6MDlY+Y4noa0+
fPDLB5NUIEZswdLX4PJA0gKBzjaB7CWnhnAlx9sotVgsrpYbKlQ1oR3wc6zO
00XXBPiJa91JmrMF3TPtZXTFEeJ8G10LYKqQXuYnljanHWqyUFAA4eKlkzC7
WhO+w7h4wn7PfeCdDdInWU/ta5WZ96lYsCjO8xjqbjIFF9Da7UQACYvtHWF9
U+71mpkguBUO6kvTw5b3ydzdd2QKlNMKrcKpaNJI54uaJ7jLG+RCzfDCBbsO
fB80qBkU8Cbh/TfwPQFhF3yxz6ohft7s9CYJPeoBaELm6lpWz3pBuEAxVJ2G
MIQ4IXGMpbS15W4nA6tzV3GNXMcd25V9QJGBJ6RfbWsXK1ROle0vatBMKgsX
JWrKFvKyzTWuJS2VzBPC5nnGfbSdjhzcWyiOuLpZFpXmWfKJa1umYX/vIHJn
GR7BOSd0CMjSi8tkHN5+kaZPtU7ghy8UG7hFhMFjKjBE55iy3JlfivM35DVL
3gUtJquovxmTyLCLTSxDnQEZWkrabJzLbevgTpN+Ox3oDGHrLr00Xvt3bRAT
bqyXbtj471C3v4+0db2fhD0Vo/aivjNh2CLQp5j6tnXwdWtj3LjBomvION4v
MmoB+r63naBNabzAXhvN977q7j23/QzbGR6AyaCLZtSXsT9INH/48ebt3HKQ
sW+DPo63HOTQKd+3QU65tCqA3Mggg3PTVpjvdZBRSN55JcOd9Lf4l5/f8C/h
HqEfW0gfUPbHLSF68+tv5Iaew7C88fUhaH7/n7l4RYSgLfRnLP7+HV8feegu
r3/1o84ePXib18/0mnffT/uTQXc/fvCuix90k/3o61/9iLP3HrzN60oyPw7W
Kcm8CG5QgUlxx8WPNHy7/esHmFyPnn8U0N369Wda//2ps2vc+BNfNwT7T9j7
v+1QvBkS4u1f/2rswNyTs89b/G1ex6WfB5jIR1+/Edk+efF/Vt/oJ77eu2Dg
jq/HLOk/m2S++nFmvwXkX0ucYVRp+OjrPzHSMsoGC7/b6/8gpBX/+qe+3t/N
fyHtrV8/46rX/4L8p8/+nyBl/nGv/zTaxSn7gT5Zt/k8xWzw8w2v97PwbOHL
27w+yucHDP8ft/jX3KfyE1+/ce0/kUo89vqNDx54XQHzqbMbDH6Svd+d3uHC
GV7oIddN3WqEs/dj376/wxqeyggq5T9lhFMZYai23HqENzJCDxJ3GeG1jPB+
8Nhd4RCv4fd3GSH97LN4LCOcILMbLA2G891GePnZZ/Hys8/i/LPPIv3ss3j1
2WehGAWft57DXUf4/LM4/eyzePrZZ3H22Wfx+Tzq8/lk/O1PopjN+j/f8LrG
fSxNOXKgffT1f4Ruc5fF3/TPv+5uXepFC4MiCzLiLcD4NaL1UhLX0/u45mIQ
c3z44QPKQa413Cj5I5pAiHaNre9B27sL5G9wefUyCa0281B/nlnyLdr+Tw5d
dy55MEHXP82ylAIHtBTV4HfrjlwKRWg9NkY3aC/k7gVBCU626NrEdUXy4V13
dUbYRO08LKoYdFiO46c+eUimc2XCiUZxZ8G9MFbzou3I4+qNgnsi4m5465jn
bnrSYoUh6OI4r8/rtRfbsY4eDgw0YgDBf5/9j9l/pNkKHWz9TQCpJixqHkGc
A3nmWnhJrF7ay0sln2sBqvCT9KIk6vsuuIaa9coVeBuUmlw6cvC7fjl43xYy
ChG73tXzQxjJnxiTTl0kMu1Jqzgo/ZEArLuiT0c5EJV+f3NA2QeidZSDYemb
Isq3ggu/dt9dhvh+GFIeZWYDOfq+dxdi+NidRonuQvy0UfqXIX7aKPafOP3g
bqN8NK58q0EOPdZ/X4IUDrH+rOT+0fdvJA37N4wYD+YfzHwyezw7/fj8N8tp
+/fx+Q/O9JH53TdffcXdqTgvEGVnze9/f6f3P2X+7ycz+ve9+7b/+eb3Jz/X
D38RxaT/+SPv47sXqtObchp+/tj73wWhGNxv+V3A1vr3XY6u/y+y1e8nuvD+
54+9z+/8PH62//lj70c/4BoxL6lv9/6AsX4i/Ryc6Q7rx7/R7Y88dtf5R6J2
d3p/JGx3l/f7LP2T4We8/Y7vf3X7+S30tgpM3rucv2hoH1nV4fdvDt7dYv6x
f3d533GBYCN3eP8npp+D+N9zDd71/ZE41F3e7zGZz9z/+0/H/x9l/k+An4YB
P/n9HxP+9z8T/95/Bv/5MeZPf4L3z/VeySC0cZf3Bwzh/7f9f//9bKaLh4p3
N/k7mfbF+l+ms7uMoN9pT87HGnW70yZoxsF33x/fEQx/kd3j32Qyo239aMfQ
cxauRoTQTe//P2OG3PX9Qx7Eh+ZClOsqbutD/IJs3pMXJ+xb8DfdaEc6d1OQ
649g/R648Ehas6PoA0NIbcSZVcJ/ZEB/gSYXTeNC8v0kbhbK1XlxLQ9fhzS8
62kV91A5X+fWk94VPtvEchVGk8/3yYq+kxou9EFAESw3SdP1x4NyyWy/xNUX
+yfS2JFvYDOfZbXMmqWVMcXNYbRlEBriojHjMt92ay4P0QKW6NY1uectBKbV
X0eQia5NL27VK4xP7GSB6zzKfCnFNHRSb1Fdh5ZCfE0Kl/dm1aV4S11bAmn4
4epj0Pgzz5e40YQ7BqR/yNHdpku/3a1W+Hyy2Wdt+mqNBuHbFt88obN9XfOf
5+t6Q78+LRbor5s3+O45fcjyMn2N/zZLmgzfPkX/ph19/Zhr9MoCX76gHZ9t
0F+FPvyx2KRn9Eq2xKfTrGnRwfQx9l7xEKc7tKFL/5gz4+D5X5bZKn2cNxf2
zNkOneVe4Awvd5uMF6RrT7/B1cGb6ePsUheKemKaoCyu5MGTatn8Pf8rWZd/
Xzb1dXtZ6GOXuzb9Ay2+lBe/yQmqj4vmcl2Xf5elV11Wp/+x3jFQaIJ2XeC/
GWo0eZQ/Zot6TkvF0mt88aesW5doYfO8bgrU0OPLx3imKdpFnePja4JuBXjv
y+Kaf6dHK8BmC3Rp5AiIKNosfVpdANwdv4dGcmeZLO55TbhG5N3JQp6iB+6f
99Xikqc4KWnzNQl7wvuMp8iaZp9+mxfzLOXPefVX4DcteLm7TB3gaF27S13l
PG+69G1RdnTWHgu5Q8EQFd/+AR0Fi6adpK93bZt+g+tNc+IhT7KrYpm+zUrm
LNqTPXmC4rzzdca3qHqktWJhdWcXfIdmkV/z3XvTKV/Rk/xfwhIg2hzjAAA=

-->

</rfc>