draft-ietf-suit-information-model.xml

<?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 docmapping="yes"?>

<rfc ipr="trust200902" docName="draft-ietf-suit-information-model-13" category="info">

  <front>
    <title abbrev="A Firmware Manifest Information Model">A Manifest Information Model for Firmware Updates in IoT Devices</title>

    <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@gmx.net</email>
      </address>
    </author>
    <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
      <organization>Fraunhofer SIT</organization>
      <address>
        <email>henk.birkholz@sit.fraunhofer.de</email>
      </address>
    </author>

    <date year="2021" month="July" day="08"/>

    <area>Security</area>
    <workgroup>SUIT</workgroup>
    <keyword>Internet-Draft</keyword>

    <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.</t>

<t>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>

  <middle>


<section anchor="introduction" title="Introduction">

<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.</t>

<t>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>

<t>This document describes all the information elements required in a manifest to secure firmware updates of IoT devices. Each information element is motiviated by user stories and threats it aims to mitigate. These threats and user stories are not intended to be an exhaustive list of the threats against IoT devices, nor of the possible user stories that describe how to conduct a firmware update. Instead they are intended to describe the threats against firmware updates in isolation and provide sufficient motivation to specify the information elements that cover a wide range of user stories.</t>

<t>To distinguish information elements from their encoding and serialization over the wire this document presents an information model. RFC 3444 <xref target="RFC3444"/> describes the differences between information and data models.</t>

<t>Because this document covers a wide range of user stories and a wide range of threats, not all information elements apply to all scenarios. As a result, various information elements are optional to implement and optional to use, depending on which threats exist in a particular domain of application and which user stories are important for deployments.</t>

</section>
<section anchor="requirements-and-terminology" title="Requirements and Terminology">

<section anchor="requirements-notation" title="Requirements Notation">

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

<t>Unless otherwise stated these words apply to the design of the manifest format, not its implementation or application. Hence, whenever an information is declared as “REQUIRED” this implies that the manifest format document has to include support for it.</t>

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

<t>This document uses terms defined in <xref target="I-D.ietf-suit-architecture"/>.
The term ‘Operator’ refers to both Device and Network Operator.</t>

<t>Secure time and secure clock refer to a set of requirements on time sources. For local time sources, this primarily means that the clock must be monotonically increasing, including across power cycles, firmware updates, etc. For remote time sources, the provided time must be both authenticated and guaranteed to be correct to within some predetermined bounds, whenever the time source is accessible.</t>

<t>The term Envelope is used to describe an encoding that allows the bundling of a manifest with related information elements that are not directly contained within the manifest.</t>

<t>The term Payload is used to describe the data that is delivered to a device during an update. This is distinct from a “firmware image”, as described in <xref target="I-D.ietf-suit-architecture"/>, because the payload is often in an intermediate state, such as being encrypted, compressed and/or encoded as a differential update. The payload, taken in isolation, is often not the final firmware image.</t>

</section>
</section>
<section anchor="manifest-information-elements" title="Manifest Information Elements">

<t>Each manifest information element is anchored in a security requirement or a usability requirement. The manifest elements are described below, justified by their requirements.</t>

<section anchor="element-version-id" title="Version ID of the Manifest Structure">

<t>An identifier that describes which iteration of the manifest format is contained in the structure. This allows devices to identify the version of the manifest data model that is in use.</t>

<t>This element is REQUIRED.</t>

</section>
<section anchor="element-sequence-number" title="Monotonic Sequence Number">

<t>A monotonically increasing (unsigned) sequence number to prevent malicious actors from reverting a firmware update against the policies of the relevant authority. This number must not wrap around.</t>

<t>For convenience, the monotonic sequence number may be a UTC timestamp. This allows global synchronisation of sequence numbers without any additional management.</t>

<t>This element is REQUIRED.</t>

<t>Implements: <xref target="req-sec-sequence">REQ.SEC.SEQUENCE</xref></t>

</section>
<section anchor="element-vendor-id" title="Vendor ID">

<t>The Vendor ID element helps to distinguish between identically named products from different vendors. Vendor ID is not intended to be a human-readable element. It is intended for binary match/mismatch comparison only.</t>

<t>Recommended practice is to use <xref target="RFC4122"/> version 5 UUIDs with the vendor’s domain name and the DNS name space ID. Other options include type 1 and type 4 UUIDs.</t>

<t>Fixed-size binary identifiers are preferred because they are simple to match, unambiguous in length, explicitly non-parsable, and require no issuing authority. Guaranteed unique integers are preferred because they are small and simple to match, however they may not be fixed length and they may require an issuing authority to ensure uniqueness. Free-form text is avoided because it is variable-length, prone to error, and often requires parsing outside the scope of the manifest serialization.</t>

<t>If human-readable content is required, it SHOULD be contained in a separate manifest information element: <xref target="manifest-element-text">Manifest text information</xref></t>

<t>This element is RECOMMENDED.</t>

<t>Implements: <xref target="req-sec-compatible">REQ.SEC.COMPATIBLE</xref>, <xref target="req-sec-authentic-compatibility">REQ.SEC.AUTH.COMPATIBILITY</xref>.</t>

<t>Here is an example for a domain name-based UUID. Vendor A creates a UUID based on a domain name it controls, such as vendorId = UUID5(DNS, “vendor-a.example”)</t>

<t>Because the DNS infrastructure prevents multiple registrations of the same domain name, this UUID is (with very high probability) guaranteed to be unique. Because the domain name is known, this UUID is reproducible. Type 1 and type 4 UUIDs produce similar guarantees of uniqueness, but not reproducibility.</t>

<t>This approach creates a contention when a vendor changes its name or relinquishes control of a domain name. In this scenario, it is possible that another vendor would start using that same domain name. However, this UUID is not proof of identity; a device’s trust in a vendor must be anchored in a cryptographic key, not a UUID.</t>

</section>
<section anchor="element-class-id" title="Class ID">

<t>A device “Class” is a set of different device types that can accept the same firmware update without modification. It thereby allows devices to determine applicability of a firmware in an unambiguous way. Class IDs must be unique within the scope of a Vendor ID. This is to prevent similarly, or identically named devices colliding in their customer’s infrastructure.</t>

<t>Recommended practice is to use <xref target="RFC4122"/> version 5 UUIDs with as much information as necessary to define firmware compatibility. Possible information used to derive the class UUID includes:</t>

<t><list style="symbols">
  <t>model name or number</t>
  <t>hardware revision</t>
  <t>runtime library version</t>
  <t>bootloader version</t>
  <t>ROM revision</t>
  <t>silicon batch number</t>
</list></t>

<t>The Class ID UUID should use the Vendor ID as the name space identifier. Classes may be more fine-grained granular than is required to identify firmware compatibility. Classes must not be less granular than is required to identify firmware compatibility. Devices may have multiple Class IDs.</t>

<t>Class ID is not intended to be a human-readable element. It is intended for binary match/mismatch comparison only. A manifest serialization SHOULD NOT permit free-form text content to be used for Class ID. A fixed-size binary identifier SHOULD be used.</t>

<t>Some organizations desire to keep the same product naming across multiple, incompatible hardware revisions for ease of user experience. If this naming is propagated into the firmware, then matching a specific hardware version becomes a challenge. An opaque, non-readable binary identifier has no naming implications and so is more likely to be usable for distinguishing among incompatible device groupings, regardless of naming.</t>

<t>Fixed-size binary identifiers are preferred because they are simple to match, unambiguous in length, opaque and free from naming implications, and explicitly non-parsable. Free-form text is avoided because it is variable-length, prone to error, often requires parsing outside the scope of the manifest serialization, and may be homogenized across incompatible device groupings.</t>

<t>If Class ID is not implemented, then each logical device class must use a unique trust anchor for authorization.</t>

<t>This element is RECOMMENDED.</t>

<t>Implements: Security Requirement <xref target="req-sec-compatible">REQ.SEC.COMPATIBLE</xref>, <xref target="req-sec-authentic-compatibility">REQ.SEC.AUTH.COMPATIBILITY</xref>.</t>

<section anchor="example-1-different-classes" title="Example 1: Different Classes">

<t>Vendor A creates product Z and product Y. The firmware images of products Z and Y are not interchangeable. Vendor A creates UUIDs as follows:</t>

<t><list style="symbols">
  <t>vendorId = UUID5(DNS, “vendor-a.example”)</t>
  <t>ZclassId = UUID5(vendorId, “Product Z”)</t>
  <t>YclassId = UUID5(vendorId, “Product Y”)</t>
</list></t>

<t>This ensures that Vendor A’s Product Z cannot install firmware for Product Y and Product Y cannot install firmware for Product Z.</t>

</section>
<section anchor="example-2-upgrading-class-id" title="Example 2: Upgrading Class ID">

<t>Vendor A creates product X. Later, Vendor A adds a new feature to product X, creating product X v2. Product X requires a firmware update to work with firmware intended for product X v2.</t>

<t>Vendor A creates UUIDs as follows:</t>

<t><list style="symbols">
  <t>vendorId = UUID5(DNS, “vendor-a.example”)</t>
  <t>XclassId = UUID5(vendorId, “Product X”)</t>
  <t>Xv2classId = UUID5(vendorId, “Product X v2”)</t>
</list></t>

<t>When product X receives the firmware update necessary to be compatible with product X v2, part of the firmware update changes the class ID to Xv2classId.</t>

</section>
<section anchor="example-3-shared-functionality" title="Example 3: Shared Functionality">

<t>Vendor A produces two products, product X and product Y. These components share a common core (such as an operating system), but have different applications. The common core and the applications can be updated independently. To enable X and Y to receive the same common core update, they require the same class ID. To ensure that only product X receives application X and only product Y receives application Y, product X and product Y must have different class IDs. The vendor creates Class IDs as follows:</t>

<t><list style="symbols">
  <t>vendorId = UUID5(DNS, “vendor-a.example”)</t>
  <t>XclassId = UUID5(vendorId, “Product X”)</t>
  <t>YclassId = UUID5(vendorId, “Product Y”)</t>
  <t>CommonClassId = UUID5(vendorId, “common core”)</t>
</list></t>

<t>Product X matches against both XclassId and CommonClassId. Product Y matches against both YclassId and CommonClassId.</t>

</section>
<section anchor="example-4-white-labelling" title="Example 4: White-labelling">

<t>Vendor A creates a product A and its firmware. Vendor B sells the product under its own name as Product B with some customised configuration. The vendors create the Class IDs as follows:</t>

<t><list style="symbols">
  <t>vendorIdA = UUID5(DNS, “vendor-a.example”)</t>
  <t>classIdA = UUID5(vendorIdA, “Product A-Unlabelled”)</t>
  <t>vendorIdB = UUID5(DNS, “vendor-b.example”)</t>
  <t>classIdB = UUID5(vendorIdB, “Product B”)</t>
</list></t>

<t>The product will match against each of these class IDs. If Vendor A and Vendor B provide different components for the device, the implementor may choose to make ID matching scoped to each component. Then, the vendorIdA, classIdA match the component ID supplied by Vendor A, and the vendorIdB, classIdB match the component ID supplied by Vendor B.</t>

</section>
</section>
<section anchor="element-precursor-digest" title="Precursor Image Digest Condition">

<t>This element provides information about the payload that needs to be present on the device for an update to apply. This may, for example, be the case with differential updates.</t>

<t>This element is OPTIONAL.</t>

<t>Implements: <xref target="req-sec-authentic-precursor">REQ.SEC.AUTH.PRECURSOR</xref></t>

</section>
<section anchor="element-required-version" title="Required Image Version List">

<t>Payloads may only be applied to a specific firmware version or firmware versions. For example, a payload containing a differential update may be applied only to a specific firmware version.</t>

<t>When a payload applies to multiple versions of a firmware, the required image version list specifies which firmware versions must be present for the update to be applied. This allows the update author to target specific versions of firmware for an update, while excluding those to which it should not or cannot be applied.</t>

<t>This element is OPTIONAL.</t>

<t>Implements: <xref target="req-use-img-versions">REQ.USE.IMG.VERSIONS</xref></t>

</section>
<section anchor="manifest-element-expiration" title="Expiration Time">

<t>This element tells a device the time at which the manifest expires and should no longer be used. This element should be used where a secure source of time is provided and firmware is intended to expire predictably. This element may also be displayed (e.g. via an app) for user confirmation since users typically have a reliable knowledge of the date.</t>

<t>Special consideration is required for end-of-life if a firmware will not be updated again, for example if a business stops issuing updates to a device. In this case the last valid firmware should not have an expiration time.</t>

<t>This element is OPTIONAL.</t>

<t>Implements: <xref target="req-sec-exp">REQ.SEC.EXP</xref></t>

</section>
<section anchor="manifest-element-format" title="Payload Format">

<t>This element describes the payload format within the signed metadata. It is used to enable devices to decode payloads correctly.</t>

<t>This element is REQUIRED.</t>

<t>Implements: <xref target="req-sec-authentic-image-type">REQ.SEC.AUTH.IMG_TYPE</xref>, <xref target="req-use-img-format">REQ.USE.IMG.FORMAT</xref></t>

</section>
<section anchor="manifest-element-processing-steps" title="Processing Steps">

<t>A representation of the Processing Steps required to decode a payload, in particular those that are compressed, packed, or encrypted. The representation must describe which algorithms are used and must convey any additional parameters required by those algorithms.</t>

<t>A Processing Step may indicate the expected digest of the payload after the processing is complete.</t>

<t>This element is RECOMMENDED.</t>

<t>Implements: <xref target="req-use-img-nested">REQ.USE.IMG.NESTED</xref></t>

</section>
<section anchor="maniest-element-storage-location" title="Storage Location">

<t>This element tells the device where to store a payload within a given component. The device can use this to establish which permissions are necessary and the physical storage location to use.</t>

<t>This element is REQUIRED.</t>

<t>Implements: <xref target="req-sec-authentic-image-location">REQ.SEC.AUTH.IMG_LOC</xref></t>

<section anchor="example-1-two-storage-locations" title="Example 1: Two Storage Locations">

<t>A device supports two components: an OS and an application. These components can be updated independently, expressing dependencies to ensure compatibility between the components. The Author chooses two storage identifiers:</t>

<t><list style="symbols">
  <t>“OS”</t>
  <t>“APP”</t>
</list></t>

</section>
<section anchor="example-2-file-system" title="Example 2: File System">

<t>A device supports a full-featured filesystem. The Author chooses to use the storage identifier as the path at which to install the payload. The payload may be a tarball, in which case, it unpacks the tarball into the specified path.</t>

</section>
<section anchor="example-3-flash-memory" title="Example 3: Flash Memory">

<t>A device supports flash memory. The Author chooses to make the storage identifier the offset where the image should be written.</t>

</section>
</section>
<section anchor="manifest-element-component-identifier" title="Component Identifier">

<t>In a device with more than one storage subsystem, a storage identifier is insufficient to identify where and how to store a payload. To resolve this, a component identifier indicates to which part of the storage subsystem the payload shall be placed.</t>

<t>A serialization may choose to combine Component Identifier and <xref target="maniest-element-storage-location">Storage Location</xref>.</t>

<t>This element is OPTIONAL.</t>

<t>Implements: <xref target="req-use-mfst-component">REQ.USE.MFST.COMPONENT</xref></t>

</section>
<section anchor="manifest-element-payload-indicator" title="Payload Indicator">

<t>This element provides the information required for the device to acquire the payload. This functionality is only needed when the target device does not intrinsically know where to find the payload.</t>

<t>This can be encoded in several ways:</t>

<t><list style="symbols">
  <t>One URI</t>
  <t>A list of URIs</t>
  <t>A prioritised list of URIs</t>
  <t>A list of signed URIs</t>
</list></t>

<t>This element is OPTIONAL.</t>

<t>Implements: <xref target="req-sec-authenticated-remote-payload">REQ.SEC.AUTH.REMOTE_LOC</xref></t>

</section>
<section anchor="manifest-element-payload-digest" title="Payload Digests">

<t>This element contains one or more digests of one or more payloads. This allows the target device to ensure authenticity of the payload(s) when combined with the <xref target="manifest-element-signature">Signature</xref> element. A manifest format must provide a mechanism to select one payload from a list based on system parameters, such as Execute-In-Place Installation Address.</t>

<t>This element is REQUIRED. Support for more than one digest is OPTIONAL.</t>

<t>Implements: <xref target="req-sec-authentic">REQ.SEC.AUTHENTIC</xref>, <xref target="req-use-img-select">REQ.USE.IMG.SELECT</xref></t>

</section>
<section anchor="manifest-element-size" title="Size">

<t>The size of the payload in bytes, which informs the target device how big of a payload to expect. Without it, devices are exposed to some classes of denial of service attack.</t>

<t>This element is REQUIRED.</t>

<t>Implements: <xref target="req-sec-authentic-execution">REQ.SEC.AUTH.EXEC</xref></t>

</section>
<section anchor="manifest-element-signature" title="Manifest Envelope Element: Signature">

<t>The Signature element contains all the information necessary to protect the contents of the manifest against modification and to offer authentication of the signer. Because the Signature element authenticates the manifest, it cannot be contained within the manifest. Instead, the manifest is either contained within the signature element, or the signature element is a member of the Manifest Envelope and bundled with the manifest.</t>

<t>The Signature element represents the foundation of all security properties of the manifest. Manifests, which are included as dependencies by another manifests, should include a signature so that the recipient can distinguish between different actors with different permissions.</t>

<t>The Signature element must support multiple signers and multiple signing algorithms. A manifest format may allow multiple manifests to be covered by a single Signature element.</t>

<t>This element is REQUIRED in non-dependency manifests.</t>

<t>Implements: <xref target="req-sec-authentic">REQ.SEC.AUTHENTIC</xref>, <xref target="req-sec-rights">REQ.SEC.RIGHTS</xref>, <xref target="req-use-mfst-multi-auth">REQ.USE.MFST.MULTI_AUTH</xref></t>

</section>
<section anchor="manifest-element-additional-install-info" title="Additional Installation Instructions">

<t>Additional installation instructions are machine-readable commands the device should execute when processing the manifest. This information is distinct from the information necessary to process a payload. Additional installation instructions include information such as update timing (for example, install only on Sunday, at 0200), procedural considerations (for example, shut down the equipment under control before executing the update), pre- and post-installation steps (for example, run a script). Other installation instructions could include requesting user confirmation before installing.</t>

<t>This element is OPTIONAL.</t>

<t>Implements: <xref target="req-use-mfst-pre-check">REQ.USE.MFST.PRE_CHECK</xref></t>

</section>
<section anchor="manifest-element-text" title="Manifest text information">

<t>Textual information pertaining to the update described by the manifest. This information is for human consumption only. It MUST NOT be the basis of any decision made by the recipient.</t>

<t>Implements: <xref target="req-use-mfst-text">REQ.USE.MFST.TEXT</xref></t>

</section>
<section anchor="manifest-element-aliases" title="Aliases">

<t>A mechanism for a manifest to augment or replace URIs or URI lists defined by one or more of its dependencies.</t>

<t>This element is OPTIONAL.</t>

<t>Implements: <xref target="req-use-mfst-override">REQ.USE.MFST.OVERRIDE_REMOTE</xref></t>

</section>
<section anchor="manifest-element-dependencies" title="Dependencies">

<t>A list of other manifests that are required by the current manifest. Manifests are identified an unambiguous way, such as a cryptographic digest.</t>

<t>This element is REQUIRED to support deployments that include both multiple authorities and multiple payloads.</t>

<t>Implements: <xref target="req-use-mfst-component">REQ.USE.MFST.COMPONENT</xref></t>

</section>
<section anchor="manifest-element-encryption-wrapper" title="Encryption Wrapper">

<t>Encrypting firmware images requires symmetric content encryption keys. The encryption wrapper provides the information needed for a device to obtain or locate a key that it uses to decrypt the firmware.</t>

<t>This element is REQUIRED for encrypted payloads.</t>

<t>Implements: <xref target="req-sec-image-confidentiality">REQ.SEC.IMG.CONFIDENTIALITY</xref></t>

</section>
<section anchor="manifest-element-xip-address" title="XIP Address">

<t>In order to support execute in place (XIP) systems with multiple possible base addresses, it is necessary to specify which address the payload is linked for.</t>

<t>For example a microcontroller may have a simple bootloader that chooses one of two images to boot. That microcontroller then needs to choose one of two firmware images to install, based on which of its two images is older.</t>

<t>This element is OPTIONAL.</t>

<t>Implements: <xref target="req-use-img-select">REQ.USE.IMG.SELECT</xref></t>

</section>
<section anchor="manifest-element-load-metadata" title="Load-time Metadata">

<t>Load-time metadata provides the device with information that it needs in order to load one or more images. This metadata may include any of:</t>

<t><list style="symbols">
  <t>the source (e.g. non-volatile storage)</t>
  <t>the destination (e.g. an address in RAM)</t>
  <t>cryptographic information</t>
  <t>decompression information</t>
  <t>unpacking information</t>
</list></t>

<t>Typically, loading is done by copying an image from its permanent storage location into its active use location. The metadata allows operations such as decryption, decompression, and unpacking to be performed during that copy.</t>

<t>This element is OPTIONAL.</t>

<t>Implements: <xref target="req-use-load">REQ.USE.LOAD</xref></t>

</section>
<section anchor="manifest-element-exec-metadata" title="Run-time metadata">

<t>Run-time metadata provides the device with any extra information needed to boot the device. This may include the entry-point of an XIP image or the kernel command-line to boot a Linux image.</t>

<t>This element is OPTIONAL.</t>

<t>Implements: <xref target="req-use-exec">REQ.USE.EXEC</xref></t>

</section>
<section anchor="manifest-element-payload" title="Payload">

<t>The Payload element is contained within the manifest or manifest envelope and enables the manifest and payload to be delivered simultaneously. This is used for delivering small payloads, such as cryptographic keys or configuration data.</t>

<t>This element is OPTIONAL.</t>

<t>Implements: <xref target="req-use-payload">REQ.USE.PAYLOAD</xref></t>

</section>
<section anchor="manifest-element-key-claims" title="Manifest Envelope Element: Delegation Chain">

<t>The delegation chain offers enhanced authorization functionality via authorization tokens, such as CBOR Web Tokens <xref target="RFC8392"/> with Proof of Possession Key Semantics <xref target="RFC8747"/>. Each token itself is protected and does not require another layer of protection. Each authorization token typically includes a public key or a public key fingerprint, however this is dependent on the tokens used. Each token MAY include additional metadata, such as key usage information. Because the delegation chain is needed to verify the signature, it must be placed in the Manifest Envelope, rather than the Manifest.</t>

<t>The first token in any delegation chain MUST be autheticated by the recipient’s Trust Anchor. Each subsequent token MUST be authenticated using the previous token. This allows a recipient to discard each antecedent token after it has authenticated the subsequent token. The final token MUST enable authentication of the manifest. More than one delegation chain MAY be used if more than one signature is used. Note that no restriction is placed on the encoding order of these tokens, the order of elements is logical only.</t>

<t>This element is OPTIONAL.</t>

<t>Implements: <xref target="req-use-delegation">REQ.USE.DELEGATION</xref>, <xref target="req-sec-key-rotation">REQ.SEC.KEY.ROTATION</xref></t>

</section>
</section>
<section anchor="design-motivation" title="Security Considerations">

<t>The following sub-sections describe the threat model, user stories, security requirements, and usability requirements. This section also provides the motivations for each of the manifest information elements.</t>

<t>Note that it is worthwhile to recall that a firmware update is, by definition, remote code execution. Hence, if a device is configured to trust an entity to provide firmware, it trusts this entity to do the “right thing”. Many classes of attacks can be mitigated by verifying that a firmware update came from a trusted party and that no rollback is taking place. However, if the trusted entity has been compromised and distributes attacker-provided firmware to devices then the possibilities for deference are limited.</t>

<section anchor="threat-model" title="Threat Model">

<t>The following sub-sections aim to provide information about the threats that were considered, the security requirements that are derived from those threats and the fields that permit implementation of the security requirements. This model uses the S.T.R.I.D.E. <xref target="STRIDE"/> approach. Each threat is classified according to:</t>

<t><list style="symbols">
  <t>Spoofing identity</t>
  <t>Tampering with data</t>
  <t>Repudiation</t>
  <t>Information disclosure</t>
  <t>Denial of service</t>
  <t>Elevation of privilege</t>
</list></t>

<t>This threat model only covers elements related to the transport of firmware updates. It explicitly does not cover threats outside of the transport of firmware updates. For example, threats to an IoT device due to physical access are out of scope.</t>

</section>
<section anchor="threat-descriptions" title="Threat Descriptions">

<t>Many of the threats detailed in this section contain a “threat escalation” description. This explains how the described threat might fit together with other threats and produce a high severity threat. This is important because some of the described threats may seem low severity but could be used with others to construct a high severity compromise.</t>

<section anchor="threat-expired" title="THREAT.IMG.EXPIRED: Old Firmware">

<t>Classification: Elevation of Privilege</t>

<t>An attacker sends an old, but valid manifest with an old, but valid firmware image to a device. If there is a known vulnerability in the provided firmware image, this may allow an attacker to exploit the vulnerability and gain control of the device.</t>

<t>Threat Escalation: If the attacker is able to exploit the known vulnerability, then this threat can be escalated to ALL TYPES.</t>

<t>Mitigated by: <xref target="req-sec-sequence">REQ.SEC.SEQUENCE</xref></t>

</section>
<section anchor="threat-expired-offline" title="THREAT.IMG.EXPIRED.OFFLINE : Offline device + Old Firmware">

<t>Classification: Elevation of Privilege</t>

<t>An attacker targets a device that has been offline for a long time and runs an old firmware version. The attacker sends an old, but valid manifest to a device with an old, but valid firmware image. The attacker-provided firmware is newer than the installed one but older than the most recently available firmware. If there is a known vulnerability in the provided firmware image then this may allow an attacker to gain control of a device. Because the device has been offline for a long time, it is unaware of any new updates. As such it will treat the old manifest as the most current.</t>

<t>The exact mitigation for this threat depends on where the threat comes from. This requires careful consideration by the implementor. If the threat is from a network actor, including an on-path attacker, or an intruder into a management system, then a user confirmation can mitigate this attack, simply by displaying an expiration date and requesting confirmation. On the other hand, if the user is the attacker, then an online confirmation system (for example a trusted timestamp server) can be used as a mitigation system.</t>

<t>Threat Escalation: If the attacker is able to exploit the known vulnerability, then this threat can be escalated to ALL TYPES.</t>

<t>Mitigated by: <xref target="req-sec-exp">REQ.SEC.EXP</xref>, <xref target="req-use-mfst-pre-check">REQ.USE.MFST.PRE_CHECK</xref>,</t>

</section>
<section anchor="threat-incompatible" title="THREAT.IMG.INCOMPATIBLE: Mismatched Firmware">

<t>Classification: Denial of Service</t>

<t>An attacker sends a valid firmware image, for the wrong type of device, signed by an actor with firmware installation permission on both types of device. The firmware is verified by the device positively because it is signed by an actor with the appropriate permission. This could have wide-ranging consequences. For devices that are similar, it could cause minor breakage, or expose security vulnerabilities. For devices that are very different, it is likely to render devices inoperable.</t>

<t>Mitigated by: <xref target="req-sec-compatible">REQ.SEC.COMPATIBLE</xref></t>

<t>For example, suppose that two vendors, Vendor A and Vendor B, adopt the same trade name in different geographic regions, and they both make products with the same names, or product name matching is not used. This causes firmware from Vendor A to match devices from Vendor B.</t>

<t>If the vendors are the firmware authorities, then devices from Vendor A will reject images signed by Vendor B since they use different credentials. However, if both devices trust the same Author, then, devices from Vendor A could install firmware intended for devices from Vendor B.</t>

</section>
<section anchor="threat-img-format" title="THREAT.IMG.FORMAT: The target device misinterprets the type of payload">

<t>Classification: Denial of Service</t>

<t>If a device misinterprets the format of the firmware image, it may cause a device to install a firmware image incorrectly. An incorrectly installed firmware image would likely cause the device to stop functioning.</t>

<t>Threat Escalation: An attacker that can cause a device to misinterpret the received firmware image may gain elevation of privilege and potentially expand this to all types of threat.</t>

<t>Mitigated by: <xref target="req-sec-authentic-image-type">REQ.SEC.AUTH.IMG_TYPE</xref></t>

</section>
<section anchor="threat-img-location" title="THREAT.IMG.LOCATION: The target device installs the payload to the wrong location">

<t>Classification: Denial of Service</t>

<t>If a device installs a firmware image to the wrong location on the device, then it is likely to break. For example, a firmware image installed as an application could cause a device and/or an application to stop functioning.</t>

<t>Threat Escalation: An attacker that can cause a device to misinterpret the received code may gain elevation of privilege and potentially expand this to all types of threat.</t>

<t>Mitigated by: <xref target="req-sec-authentic-image-location">REQ.SEC.AUTH.IMG_LOC</xref></t>

</section>
<section anchor="threat-net-redirect" title="THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting">

<t>Classification: Denial of Service</t>

<t>If a device is tricked into fetching a payload for an attacker controlled site, the attacker may send corrupted payloads to devices.</t>

<t>Mitigated by: <xref target="req-sec-authenticated-remote-payload">REQ.SEC.AUTH.REMOTE_LOC</xref></t>

</section>
<section anchor="threat-net-onpath" title="THREAT.NET.ONPATH: Traffic interception">

<t>Classification: Spoofing Identity, Tampering with Data</t>

<t>An attacker intercepts all traffic to and from a device. The attacker can monitor or modify any data sent to or received from the device. This can take the form of: manifests, payloads, status reports, and capability reports being modified or not delivered to the intended recipient. It can also take the form of analysis of data sent to or from the device, either in content, size, or frequency.</t>

<t>Mitigated by: <xref target="req-sec-authentic">REQ.SEC.AUTHENTIC</xref>, <xref target="req-sec-image-confidentiality">REQ.SEC.IMG.CONFIDENTIALITY</xref>, <xref target="req-sec-authenticated-remote-payload">REQ.SEC.AUTH.REMOTE_LOC</xref>, <xref target="req-sec-mfst-confidentiality">REQ.SEC.MFST.CONFIDENTIALITY</xref>, <xref target="req-sec-reporting">REQ.SEC.REPORTING</xref></t>

</section>
<section anchor="threat-image-replacement" title="THREAT.IMG.REPLACE: Payload Replacement">

<t>Classification: Elevation of Privilege</t>

<t>An attacker replaces a newly downloaded firmware after a device finishes verifying a manifest. This could cause the device to execute the attacker’s code. This attack likely requires physical access to the device. However, it is possible that this attack is carried out in combination with another threat that allows remote execution. This is a typical Time Of Check/Time Of Use (TICTOC) attack.</t>

<t>Threat Escalation: If the attacker is able to exploit a known vulnerability, or if the attacker can supply their own firmware, then this threat can be escalated to ALL TYPES.</t>

<t>Mitigated by: <xref target="req-sec-authentic-execution">REQ.SEC.AUTH.EXEC</xref></t>

</section>
<section anchor="threat-img-unauthenticated" title="THREAT.IMG.NON_AUTH: Unauthenticated Images">

<t>Classification: Elevation of Privilege / All Types</t>

<t>If an attacker can install their firmware on a device, for example by manipulating either payload or metadata, then they have complete control of the device.</t>

<t>Mitigated by: <xref target="req-sec-authentic">REQ.SEC.AUTHENTIC</xref></t>

</section>
<section anchor="threat-upd-wrong-precursor" title="THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor images">

<t>Classification: Denial of Service / All Types</t>

<t>Modifications of payloads and metadata allow an attacker to introduce a number of denial of service attacks. Below are some examples.</t>

<t>An attacker sends a valid, current manifest to a device that has an unexpected precursor image. If a payload format requires a precursor image (for example, delta updates) and that precursor image is not available on the target device, it could cause the update to break.</t>

<t>An attacker that can cause a device to install a payload against the wrong precursor image could gain elevation of privilege and potentially expand this to all types of threat. However, it is unlikely that a valid differential update applied to an incorrect precursor would result in a functional, but vulnerable firmware.</t>

<t>Mitigated by: <xref target="req-sec-authentic-precursor">REQ.SEC.AUTH.PRECURSOR</xref></t>

</section>
<section anchor="threat-upd-unapproved" title="THREAT.UPD.UNAPPROVED: Unapproved Firmware">

<t>Classification: Denial of Service, Elevation of Privilege</t>

<t>This threat can appear in several ways, however it is ultimately about ensuring that devices retain the behaviour required by their owner, or operator. The owner or operator of a device typically requires that the device maintain certain features, functions, capabilities, behaviours, or interoperability constraints (more generally, behaviour). If these requirements are broken, then a device will not fulfill its purpose. Therefore, if any party other than the device’s owner or the owner’s contracted Device Operator has the ability to modify device behaviour without approval, then this constitutes an elevation of privilege.</t>

<t>Similarly, a Network Operator may require that devices behave in a particular way in order to maintain the integrity of the network. If devices behaviour on a network can be modified without the approval of the Network Operator, then this constitutes an elevation of privilege with respect to the network.</t>

<t>For example, if the owner of a device has purchased that device because of features A, B, and C, and a firmware update is issued by the manufacturer, which removes feature A, then the device may not fulfill the owner’s requirements any more. In certain circumstances, this can cause significantly greater threats. Suppose that feature A is used to implement a safety-critical system, whether the manufacturer intended this behaviour or not. When unapproved firmware is installed, the system may become unsafe.</t>

<t>In a second example, the owner or operator of a system of two or more interoperating devices needs to approve firmware for their system in order to ensure interoperability with other devices in the system. If the firmware is not qualified, the system as a whole may not work. Therefore, if a device installs firmware without the approval of the device owner or operator, this is a threat to devices or the system as a whole.</t>

<t>Similarly, the operator of a network may need to approve firmware for devices attached to the network in order to ensure favourable operating conditions within the network. If the firmware is not qualified, it may degrade the performance of the network. Therefore, if a device installs firmware without the approval of the Network Operator, this is a threat to the network itself.</t>

<t>Threat Escalation: If the firmware expects configuration that is present in devices deployed in Network A, but not in devices deployed in Network B, then the device may experience degraded security, leading to threats of All Types.</t>

<t>Mitigated by: <xref target="req-sec-rights">REQ.SEC.RIGHTS</xref>, <xref target="req-sec-access-control">REQ.SEC.ACCESS_CONTROL</xref></t>

<section anchor="example-1-multiple-network-operators-with-a-single-device-operator" title="Example 1: Multiple Network Operators with a Single Device Operator">

<t>In this example, assume that Device Operators expect the rights to create firmware but that Network Operators expect the rights to qualify firmware as fit-for-purpose on their networks. Additionally, assume that Device Operators manage devices that can be deployed on any network, including Network A and B in our example.</t>

<t>An attacker may obtain a manifest for a device on Network A. Then, this attacker sends that manifest to a device on Network B. Because Network A and Network B are under control of different Operators, and the firmware for a device on Network A has not been qualified to be deployed on Network B, the target device on Network B is now in violation of the Operator B’s policy and may be disabled by this unqualified, but signed firmware.</t>

<t>This is a denial of service because it can render devices inoperable. This is an elevation of privilege because it allows the attacker to make installation decisions that should be made by the Operator.</t>

</section>
<section anchor="example-2-single-network-operator-with-multiple-device-operators" title="Example 2: Single Network Operator with Multiple Device Operators">

<t>Multiple devices that interoperate are used on the same network and communicate with each other. Some devices are manufactured and managed by Device Operator A and other devices by Device Operator B. A new firmware is released by Device Operator A that breaks compatibility with devices from Device Operator B. An attacker sends the new firmware to the devices managed by Device Operator A without approval of the Network Operator. This breaks the behaviour of the larger system causing denial of service and possibly other threats. Where the network is a distributed SCADA system, this could cause misbehaviour of the process that is under control.</t>

</section>
</section>
<section anchor="threat-img-disclosure" title="THREAT.IMG.DISCLOSURE: Reverse Engineering Of Firmware Image for Vulnerability Analysis">

<t>Classification: All Types</t>

<t>An attacker wants to mount an attack on an IoT device. To prepare the attack he or she retrieves the provided firmware image and performs reverse engineering of the firmware image to analyze it for specific vulnerabilities.</t>

<t>Mitigated by: <xref target="req-sec-image-confidentiality">REQ.SEC.IMG.CONFIDENTIALITY</xref></t>

</section>
<section anchor="threat-mfst-override" title="THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements">

<t>Classification: Elevation of Privilege</t>

<t>An authorized actor, but not the Author, uses an override mechanism (<xref target="user-story-override">USER_STORY.OVERRIDE</xref>) to change an information element in a manifest signed by the Author. For example, if the authorized actor overrides the digest and URI of the payload, the actor can replace the entire payload with a payload of their choice.</t>

<t>Threat Escalation: By overriding elements such as payload installation instructions or firmware digest, this threat can be escalated to all types.</t>

<t>Mitigated by: <xref target="req-sec-access-control">REQ.SEC.ACCESS_CONTROL</xref></t>

</section>
<section anchor="threat-mfst-exposure" title="THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure">

<t>Classification: Information Disclosure</t>

<t>A third party may be able to extract sensitive information from the manifest.</t>

<t>Mitigated by: <xref target="req-sec-mfst-confidentiality">REQ.SEC.MFST.CONFIDENTIALITY</xref></t>

</section>
<section anchor="threat-img-extra" title="THREAT.IMG.EXTRA: Extra data after image">

<t>Classification: All Types</t>

<t>If a third party modifies the image so that it contains extra code after a valid, authentic image, that third party can then use their own code in order to make better use of an existing vulnerability.</t>

<t>Mitigated by: <xref target="req-sec-img-complete-digest">REQ.SEC.IMG.COMPLETE_DIGEST</xref></t>

</section>
<section anchor="threat-key-exposure" title="THREAT.KEY.EXPOSURE: Exposure of signing keys">

<t>Classification: All Types</t>

<t>If a third party obtains a key or even indirect access to a key, for example in an hardware security module (HSM), then they can perform the same actions as the legitimate owner of the key. If the key is trusted for firmware update, then the third party can perform firmware updates as though they were the legitimate owner of the key.</t>

<t>For example, if manifest signing is performed on a server connected to the internet, an attacker may compromise the server and then be able to sign manifests, even if the keys for manifest signing are held in an HSM that is accessed by the server.</t>

<t>Mitigated by: <xref target="req-sec-key-protection">REQ.SEC.KEY.PROTECTION</xref>, <xref target="req-sec-key-rotation">REQ.SEC.KEY.ROTATION</xref></t>

</section>
<section anchor="threat-mfst-modification" title="THREAT.MFST.MODIFICATION: Modification of manifest or payload prior to signing">

<t>Classification: All Types</t>

<t>If an attacker can alter a manifest or payload before it is signed, they can perform all the same actions as the manifest author. This allows the attacker to deploy firmware updates to any devices that trust the manifest author. If an attacker can modify the code of a payload before the corresponding manifest is created, they can insert their own code. If an attacker can modify the manifest before it is signed, they can redirect the manifest to their own payload.</t>

<t>For example, the attacker deploys malware to the developer’s computer or signing service that watches manifest creation activities and inserts code into any binary that is referenced by a manifest.</t>

<t>For example, the attacker deploys malware to the developer’s computer or signing service that replaces the referenced binary (digest) and URI with the attacker’s binary (digest) and URI.</t>

<t>Mitigated by: <xref target="req-sec-mfst-check">REQ.SEC.MFST.CHECK</xref>, <xref target="req-sec-mfst-trusted">REQ.SEC.MFST.TRUSTED</xref></t>

</section>
<section anchor="threat-mfst-toctou" title="THREAT.MFST.TOCTOU: Modification of manifest between authentication and use">

<t>Classification: All Types</t>

<t>If an attacker can modify a manifest after it is authenticated (Time Of Check) but before it is used (Time Of Use), then the attacker can place any content whatsoever in the manifest.</t>

<t>Mitigated by: <xref target="req-sec-mfst-const">REQ.SEC.MFST.CONST</xref></t>

</section>
</section>
<section anchor="security-requirements" title="Security Requirements">

<t>The security requirements here are a set of policies that mitigate the threats described in <xref target="threat-model"/>.</t>

<section anchor="req-sec-sequence" title="REQ.SEC.SEQUENCE: Monotonic Sequence Numbers">

<t>Only an actor with firmware installation authority is permitted to decide when device firmware can be installed. To enforce this rule, manifests MUST contain monotonically increasing sequence numbers. Manifests may use UTC epoch timestamps to coordinate monotonically increasing sequence numbers across many actors in many locations. If UTC epoch timestamps are used, they must not be treated as times, they must be treated only as sequence numbers. Devices must reject manifests with sequence numbers smaller than any onboard sequence number, i.e. there is no sequence number roll over.</t>

<t>Note: This is not a firmware version field. It is a manifest sequence number. A firmware version may be rolled back by creating a new manifest for the old firmware version with a later sequence number.</t>

<t>Mitigates: <xref target="threat-expired">THREAT.IMG.EXPIRED</xref></t>

<t>Implemented by: <xref target="element-sequence-number">Monotonic Sequence Number</xref></t>

</section>
<section anchor="req-sec-compatible" title="REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers">

<t>Devices MUST only apply firmware that is intended for them. Devices must know that a given update applies to their vendor, model, hardware revision, and software revision. Human-readable identifiers are often error-prone in this regard, so unique identifiers should be used instead.</t>

<t>Mitigates: <xref target="threat-incompatible">THREAT.IMG.INCOMPATIBLE</xref></t>

<t>Implemented by: <xref target="element-vendor-id">Vendor ID Condition</xref>, <xref target="element-class-id">Class ID Condition</xref></t>

</section>
<section anchor="req-sec-exp" title="REQ.SEC.EXP: Expiration Time">

<t>A firmware manifest MAY expire after a given time and devices may have a secure clock (local or remote). If a secure clock is provided and the Firmware manifest has an expiration timestamp, the device must reject the manifest if current time is later than the expiration time.</t>

<t>Special consideration is required for end-of-life in case device will not be updated again, for example if a business stops issuing updates for a device. The last valid firmware should not have an expiration time.</t>

<t>If a device has a flawed time source (either local or remote), an old update can be deployed as new.</t>

<t>Mitigates: <xref target="threat-expired-offline">THREAT.IMG.EXPIRED.OFFLINE</xref></t>

<t>Implemented by: <xref target="manifest-element-expiration">Expiration Time</xref></t>

</section>
<section anchor="req-sec-authentic" title="REQ.SEC.AUTHENTIC: Cryptographic Authenticity">

<t>The authenticity of an update MUST be demonstrable. Typically, this means that updates must be digitally signed. Because the manifest contains information about how to install the update, the manifest’s authenticity must also be demonstrable. To reduce the overhead required for validation, the manifest contains the cryptographic digest of the firmware image, rather than a second digital signature. The authenticity of the manifest can be verified with a digital signature or Message Authentication Code. The authenticity of the firmware image is tied to the manifest by the use of a cryptographic digest of the firmware image.</t>

<t>Mitigates: <xref target="threat-img-unauthenticated">THREAT.IMG.NON_AUTH</xref>, <xref target="threat-net-onpath">THREAT.NET.ONPATH</xref></t>

<t>Implemented by: <xref target="manifest-element-signature">Signature</xref>, <xref target="manifest-element-payload-digest">Payload Digest</xref></t>

</section>
<section anchor="req-sec-authentic-image-type" title="REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type">

<t>The type of payload MUST be authenticated. For example, the target must know whether the payload is XIP firmware, a loadable module, or configuration data.</t>

<t>Mitigates: <xref target="threat-img-format">THREAT.IMG.FORMAT</xref></t>

<t>Implemented by: <xref target="manifest-element-format">Payload Format</xref>, <xref target="manifest-element-signature">Signature</xref></t>

</section>
<section anchor="req-sec-authentic-image-location" title="Security Requirement REQ.SEC.AUTH.IMG_LOC: Authenticated Storage Location">

<t>The location on the target where the payload is to be stored MUST be authenticated.</t>

<t>Mitigates: <xref target="threat-img-location">THREAT.IMG.LOCATION</xref></t>

<t>Implemented by: <xref target="maniest-element-storage-location">Storage Location</xref></t>

</section>
<section anchor="req-sec-authenticated-remote-payload" title="REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Payload">

<t>The location where a target should find a payload MUST be authenticated. Remote resources need to receive an equal amount of cryptographic protection as the manifest itself, when dereferencing URIs. The security considerations of Uniform Resource Identifiers (URIs) are applicable <xref target="RFC3986"/>.</t>

<t>Mitigates: <xref target="threat-net-redirect">THREAT.NET.REDIRECT</xref>, <xref target="threat-net-onpath">THREAT.NET.ONPATH</xref></t>

<t>Implemented by: <xref target="manifest-element-payload-indicator">Payload Indicator</xref></t>

</section>
<section anchor="req-sec-authentic-execution" title="REQ.SEC.AUTH.EXEC: Secure Execution">

<t>The target SHOULD verify firmware at time of boot. This requires authenticated payload size, and digest.</t>

<t>Mitigates: <xref target="threat-image-replacement">THREAT.IMG.REPLACE</xref></t>

<t>Implemented by: <xref target="manifest-element-payload-digest">Payload Digest</xref>, <xref target="manifest-element-size">Size</xref></t>

</section>
<section anchor="req-sec-authentic-precursor" title="REQ.SEC.AUTH.PRECURSOR: Authenticated precursor images">

<t>If an update uses a differential compression method, it MUST specify the digest of the precursor image and that digest MUST be authenticated.</t>

<t>Mitigates: <xref target="threat-upd-wrong-precursor">THREAT.UPD.WRONG_PRECURSOR</xref></t>

<t>Implemented by: <xref target="element-precursor-digest">Precursor Image Digest</xref></t>

</section>
<section anchor="req-sec-authentic-compatibility" title="REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and Class IDs">

<t>The identifiers that specify firmware compatibility MUST be authenticated to ensure that only compatible firmware is installed on a target device.</t>

<t>Mitigates: <xref target="threat-incompatible">THREAT.IMG.INCOMPATIBLE</xref></t>

<t>Implemented By: <xref target="element-vendor-id">Vendor ID Condition</xref>, <xref target="element-class-id">Class ID Condition</xref></t>

</section>
<section anchor="req-sec-rights" title="REQ.SEC.RIGHTS: Rights Require Authenticity">

<t>If a device grants different rights to different actors, exercising those rights MUST be accompanied by proof of those rights, in the form of proof of authenticity. Authenticity mechanisms, such as those required in <xref target="req-sec-authentic">REQ.SEC.AUTHENTIC</xref>, can be used to prove authenticity.</t>

<t>For example, if a device has a policy that requires that firmware have both an Authorship right and a Qualification right and if that device grants Authorship and Qualification rights to different parties, such as a Device Operator and a Network Operator, respectively, then the firmware cannot be installed without proof of rights from both the Device Operator and the Network Operator.</t>

<t>Mitigates: <xref target="threat-upd-unapproved">THREAT.UPD.UNAPPROVED</xref></t>

<t>Implemented by: <xref target="manifest-element-signature">Signature</xref></t>

</section>
<section anchor="req-sec-image-confidentiality" title="REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption">

<t>The manifest information model MUST enable encrypted payloads. Encryption helps to prevent third parties, including attackers, from reading the content of the firmware image. This can protect against confidential information disclosures and discovery of vulnerabilities through reverse engineering. Therefore the manifest must convey the information required to allow an intended recipient to decrypt an encrypted payload.</t>

<t>Mitigates: <xref target="threat-img-disclosure">THREAT.IMG.DISCLOSURE</xref>, <xref target="threat-net-onpath">THREAT.NET.ONPATH</xref></t>

<t>Implemented by: <xref target="manifest-element-encryption-wrapper">Encryption Wrapper</xref></t>

</section>
<section anchor="req-sec-access-control" title="REQ.SEC.ACCESS_CONTROL: Access Control">

<t>If a device grants different rights to different actors, then an exercise of those rights MUST be validated against a list of rights for the actor. This typically takes the form of an Access Control List (ACL). ACLs are applied to two scenarios:</t>

<t><list style="numbers">
  <t>An ACL decides which elements of the manifest may be overridden and by which actors.</t>
  <t>An ACL decides which component identifier/storage identifier pairs can be written by which actors.</t>
</list></t>

<t>Mitigates: <xref target="threat-mfst-override">THREAT.MFST.OVERRIDE</xref>, <xref target="threat-upd-unapproved">THREAT.UPD.UNAPPROVED</xref></t>

<t>Implemented by: Client-side code, not specified in manifest.</t>

</section>
<section anchor="req-sec-mfst-confidentiality" title="REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests">

<t>A manifest format MUST allow encryption of selected parts of the manifest or encryption of the entire manifest to prevent sensitive content of the firmware metadata to be leaked.</t>

<t>Mitigates: <xref target="threat-mfst-exposure">THREAT.MFST.EXPOSURE</xref>, <xref target="threat-net-onpath">THREAT.NET.ONPATH</xref></t>

<t>Implemented by: Manifest Encryption Wrapper / Transport Security</t>

</section>
<section anchor="req-sec-img-complete-digest" title="REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest">

<t>The digest SHOULD cover all available space in a fixed-size storage location. Variable-size storage locations MUST be restricted to exactly the size of deployed payload. This prevents any data from being distributed without being covered by the digest. For example, XIP microcontrollers typically have fixed-size storage. These devices should deploy a digest that covers the deployed firmware image, concatenated with the default erased value of any remaining space.</t>

<t>Mitigates: <xref target="threat-img-extra">THREAT.IMG.EXTRA</xref></t>

<t>Implemented by: <xref target="manifest-element-payload-digest">Payload Digests</xref></t>

</section>
<section anchor="req-sec-reporting" title="REQ.SEC.REPORTING: Secure Reporting">

<t>Status reports from the device to any remote system MUST be performed over an authenticated, confidential channel in order to prevent modification or spoofing of the reports.</t>

<t>Mitigates: <xref target="threat-net-onpath">THREAT.NET.ONPATH</xref></t>

<t>Implemented by: Transport Security / Manifest format triggering generation of reports</t>

</section>
<section anchor="req-sec-key-protection" title="REQ.SEC.KEY.PROTECTION: Protected storage of signing keys">

<t>Cryptographic keys for signing/authenticating manifests SHOULD be stored in a manner that is inaccessible to networked devices, for example in an HSM, or an air-gapped computer. This protects against an attacker obtaining the keys.</t>

<t>Keys SHOULD be stored in a way that limits the risk of a legitimate, but compromised, entity (such as a server or developer computer) issuing signing requests.</t>

<t>Mitigates: <xref target="threat-key-exposure">THREAT.KEY.EXPOSURE</xref></t>

<t>Implemented by: Hardware-assisted isolation technologies, which are outside the scope of the manifest format.</t>

</section>
<section anchor="req-sec-key-rotation" title="REQ.SEC.KEY.ROTATION: Protected storage of signing keys">

<t>Cryptographic keys for signing/authenticating manifests SHOULD be replaced from time to time. Because it is difficult and risky to replace a Trust Anchor, keys used for signing updates SHOULD be delegates of that Trust Anchor.</t>

<t>If key expiration is performed based on time, then a secure clock is needed. If the time source used by a recipient to check for expiration is flawed, an old signing key can be used as current, which compounds <xref target="threat-key-exposure">THREAT.KEY.EXPOSURE</xref>.</t>

<t>Mitigates: <xref target="threat-key-exposure">THREAT.KEY.EXPOSURE</xref></t>

<t>Implemented by: Secure storage technology, which is a system design/implementation aspect outside the scope of the manifest format.</t>

</section>
<section anchor="req-sec-mfst-check" title="REQ.SEC.MFST.CHECK: Validate manifests prior to deployment">

<t>Manifests SHOULD be verified prior to deployment. This reduces problems that may arise with devices installing firmware images that damage devices unintentionally.</t>

<t>Mitigates: <xref target="threat-mfst-modification">THREAT.MFST.MODIFICATION</xref></t>

<t>Implemented by: Testing infrastructure. While outside the scope of the manifest format, proper testing of low-level software is essential for avoiding unnecessary down-time or worse situations.</t>

</section>
<section anchor="req-sec-mfst-trusted" title="REQ.SEC.MFST.TRUSTED: Construct manifests in a trusted environment">

<t>For high risk deployments, such as large numbers of devices or critical function devices, manifests SHOULD be constructed in an environment that is protected from interference, such as an air-gapped computer. Note that a networked computer connected to an HSM does not fulfill this requirement (see <xref target="threat-mfst-modification">THREAT.MFST.MODIFICATION</xref>).</t>

<t>Mitigates: <xref target="threat-mfst-modification">THREAT.MFST.MODIFICATION</xref></t>

<t>Implemented by: Physical and network security for protecting the environment where firmware updates are prepared to avoid unauthorized access to this infrastructure.</t>

</section>
<section anchor="req-sec-mfst-const" title="REQ.SEC.MFST.CONST: Manifest kept immutable between check and use">

<t>Both the manifest and any data extracted from it MUST be held immutable between its authenticity verification (time of check) and its use (time of use). To make this guarantee, the manifest MUST fit within an internal memory or a secure memory, such as encrypted memory. The recipient SHOULD defend the manifest from tampering by code or hardware resident in the recipient, for example other processes or debuggers.</t>

<t>If an application requires that the manifest is verified before storing it, then this means the manifest MUST fit in RAM.</t>

<t>Mitigates: <xref target="threat-mfst-toctou">THREAT.MFST.TOCTOU</xref></t>

<t>Implemented by: Proper system design with sufficient resources and implementation avoiding TOCTOU attacks.</t>

</section>
</section>
<section anchor="user-stories" title="User Stories">

<t>User stories provide expected use cases. These are used to feed into usability requirements.</t>

<section anchor="user-story-install-instructions" title="USER_STORY.INSTALL.INSTRUCTIONS: Installation Instructions">

<t>As a Device Operator, I want to provide my devices with additional installation instructions so that I can keep process details out of my payload data.</t>

<t>Some installation instructions might be:</t>

<t><list style="symbols">
  <t>Use a table of hashes to ensure that each block of the payload is validated before writing.</t>
  <t>Do not report progress.</t>
  <t>Pre-cache the update, but do not install.</t>
  <t>Install the pre-cached update matching this manifest.</t>
  <t>Install this update immediately, overriding any long-running tasks.</t>
</list></t>

<t>Satisfied by: <xref target="req-use-mfst-pre-check">REQ.USE.MFST.PRE_CHECK</xref></t>

</section>
<section anchor="user-story-fail-early" title="USER_STORY.MFST.FAIL_EARLY: Fail Early">

<t>As a designer of a resource-constrained IoT device, I want bad updates to fail as early as possible to preserve battery life and limit consumed bandwidth.</t>

<t>Satisfied by: <xref target="req-use-mfst-pre-check">REQ.USE.MFST.PRE_CHECK</xref></t>

</section>
<section anchor="user-story-override" title="USER_STORY.OVERRIDE: Override Non-Critical Manifest Elements">

<t>As a Device Operator, I would like to be able to override the non-critical information in the manifest so that I can control my devices more precisely. The authority to override this information is provided via the installation of a limited trust anchor by another authority.</t>

<t>Some examples of potentially overridable information:</t>

<t><list style="symbols">
  <t><xref target="manifest-element-payload-indicator">URIs</xref>: this allows the Device Operator to direct devices to their own infrastructure in order to reduce network load.</t>
  <t>Conditions: this allows the Device Operator to pose additional constraints on the installation of the manifest.</t>
  <t><xref target="manifest-element-additional-install-info">Directives</xref>: this allows the Device Operator to add more instructions such as time of installation.</t>
  <t><xref target="manifest-element-processing-steps">Processing Steps</xref>: If an intermediary performs an action on behalf of a device, it may need to override the processing steps. It is still possible for a device to verify the final content and the result of any processing step that specifies a digest. Some processing steps should be non-overridable.</t>
</list></t>

<t>Satisfied by: <xref target="req-use-mfst-component">REQ.USE.MFST.COMPONENT</xref></t>

</section>
<section anchor="user-story-component" title="USER_STORY.COMPONENT: Component Update">

<t>As a Device Operator, I want to divide my firmware into components, so that I can reduce the size of updates, make different parties responsible for different components, and divide my firmware into frequently updated and infrequently updated components.</t>

<t>Satisfied by: <xref target="req-use-mfst-component">REQ.USE.MFST.COMPONENT</xref></t>

</section>
<section anchor="user-story-multi-auth" title="USER_STORY.MULTI_AUTH: Multiple Authorizations">

<t>As a Device Operator, I want to ensure the quality of a firmware update before installing it, so that I can ensure interoperability of all devices in my product family. I want to restrict the ability to make changes to my devices to require my express approval.</t>

<t>Satisfied by: <xref target="req-use-mfst-multi-auth">REQ.USE.MFST.MULTI_AUTH</xref>, <xref target="req-sec-access-control">REQ.SEC.ACCESS_CONTROL</xref></t>

</section>
<section anchor="user-story-img-format" title="USER_STORY.IMG.FORMAT: Multiple Payload Formats">

<t>As a Device Operator, I want to be able to send multiple payload formats to suit the needs of my update, so that I can optimise the bandwidth used by my devices.</t>

<t>Satisfied by: <xref target="req-use-img-format">REQ.USE.IMG.FORMAT</xref></t>

</section>
<section anchor="user-story-img-confidentiality" title="USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential Information Disclosures">

<t>As a firmware author, I want to prevent confidential information in the manifest from being disclosed when distributing manifests and firmware images. Confidential information may include information about the device these updates are being applied to as well as information in the firmware image itself.</t>

<t>Satisfied by: <xref target="req-sec-image-confidentiality">REQ.SEC.IMG.CONFIDENTIALITY</xref></t>

</section>
<section anchor="user-story-img-unknown-format" title="USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from Unpacking Unknown Formats">

<t>As a Device Operator, I want devices to determine whether they can process a payload prior to downloading it.</t>

<t>In some cases, it may be desirable for a third party to perform some processing on behalf of a target. For this to occur, the third party MUST indicate what processing occurred and how to verify it against the Trust Provisioning Authority’s intent.</t>

<t>This amounts to overriding <xref target="manifest-element-processing-steps">Processing Steps</xref> and <xref target="manifest-element-payload-indicator">Payload Indicator</xref>.</t>

<t>Satisfied by: <xref target="req-use-img-format">REQ.USE.IMG.FORMAT</xref>, <xref target="req-use-img-nested">REQ.USE.IMG.NESTED</xref>, <xref target="req-use-mfst-override">REQ.USE.MFST.OVERRIDE_REMOTE</xref></t>

</section>
<section anchor="user-story-img-current-version" title="USER_STORY.IMG.CURRENT_VERSION: Specify Version Numbers of Target Firmware">

<t>As a Device Operator, I want to be able to target devices for updates based on their current firmware version, so that I can control which versions are replaced with a single manifest.</t>

<t>Satisfied by: <xref target="req-use-img-versions">REQ.USE.IMG.VERSIONS</xref></t>

</section>
<section anchor="user-story-img-select" title="USER_STORY.IMG.SELECT: Enable Devices to Choose Between Images">

<t>As a developer, I want to be able to sign two or more versions of my firmware in a single manifest so that I can use a very simple bootloader that chooses between two or more images that are executed in-place.</t>

<t>Satisfied by: <xref target="req-use-img-select">REQ.USE.IMG.SELECT</xref></t>

</section>
<section anchor="user-story-exec-mfst" title="USER_STORY.EXEC.MFST: Secure Execution Using Manifests">

<t>As a signer for both secure execution/boot and firmware deployment, I would like to use the same signed document for both tasks so that my data size is smaller, I can share common code, and I can reduce signature verifications.</t>

<t>Satisfied by: <xref target="req-use-exec">REQ.USE.EXEC</xref></t>

</section>
<section anchor="user-story-exec-decompress" title="USER_STORY.EXEC.DECOMPRESS: Decompress on Load">

<t>As a developer of firmware for a run-from-RAM device, I would like to use compressed images and to indicate to the bootloader that I am using a compressed image in the manifest so that it can be used with secure execution/boot.</t>

<t>Satisfied by: <xref target="req-use-load">REQ.USE.LOAD</xref></t>

</section>
<section anchor="user-story-mfst-img" title="USER_STORY.MFST.IMG: Payload in Manifest">

<t>As an operator of devices on a constrained network, I would like the manifest to be able to include a small payload in the same packet so that I can reduce network traffic.</t>

<t>Small payloads may include, for example, wrapped content encryption keys, configuration information, public keys, authorization tokens, or X.509 certificates.</t>

<t>Satisfied by: <xref target="req-use-payload">REQ.USE.PAYLOAD</xref></t>

</section>
<section anchor="user-story-mfst-parse" title="USER_STORY.MFST.PARSE: Simple Parsing">

<t>As a developer for constrained devices, I want a low complexity library for processing updates so that I can fit more application code on my device.</t>

<t>Satisfied by: <xref target="req-use-parse">REQ.USE.PARSE</xref></t>

</section>
<section anchor="user-story-mfst-delegation" title="USER_STORY.MFST.DELEGATION: Delegated Authority in Manifest">

<t>As a Device Operator that rotates delegated authority more often than delivering firmware updates, I would like to delegate a new authority when I deliver a firmware update so that I can accomplish both tasks in a single transmission.</t>

<t>Satisfied by: <xref target="req-use-delegation">REQ.USE.DELEGATION</xref></t>

</section>
<section anchor="user-story-mfst-pre-check" title="USER_STORY.MFST.PRE_CHECK: Update Evaluation">

<t>As an operator of a constrained network, I would like devices on my network to be able to evaluate the suitability of an update prior to initiating any large download so that I can prevent unnecessary consumption of bandwidth.</t>

<t>Satisfied by: <xref target="req-use-mfst-pre-check">REQ.USE.MFST.PRE_CHECK</xref></t>

</section>
<section anchor="user-story-mfst-admin" title="USER_STORY.MFST.ADMINISTRATION: Administration of manifests">

<t>As a Device Operator, I want to understand what an update will do and to which devices it applies so that I can make informed choices about which updates to apply, when to apply them, and which devices should be updated.</t>

<t>Satisfied by <xref target="req-use-mfst-text">REQ.USE.MFST.TEXT</xref></t>

</section>
</section>
<section anchor="usability-requirements" title="Usability Requirements">

<t>The following usability requirements satisfy the user stories listed above.</t>

<section anchor="req-use-mfst-pre-check" title="REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks">

<t>A manifest format MUST be able to carry all information required to process an update.</t>

<t>For example: Information about which precursor image is required for a differential update must be placed in the manifest.</t>

<t>Satisfies: [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check), <xref target="user-story-install-instructions">USER_STORY.INSTALL.INSTRUCTIONS</xref></t>

<t>Implemented by: <xref target="manifest-element-additional-install-info">Additional installation instructions</xref></t>

</section>
<section anchor="req-use-mfst-text" title="REQ.USE.MFST.TEXT: Descriptive Manifest Information">

<t>It MUST be possible for a Device Operator to determine what a manifest will do and which devices will accept it prior to distribution.</t>

<t>Satisfies: <xref target="user-story-mfst-admin">USER_STORY.MFST.ADMINISTRATION</xref></t>

<t>Implemented by: <xref target="manifest-element-text">Manifest text information</xref></t>

</section>
<section anchor="req-use-mfst-override" title="REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location">

<t>A manifest format MUST be able to redirect payload fetches. This applies where two manifests are used in conjunction. For example, a Device Operator creates a manifest specifying a payload and signs it, and provides a URI for that payload. A Network Operator creates a second manifest, with a dependency on the first. They use this second manifest to override the URIs provided by the Device Operator, directing them into their own infrastructure instead. Some devices may provide this capability, while others may only look at canonical sources of firmware. For this to be possible, the device must fetch the payload, whereas a device that accepts payload pushes will ignore this feature.</t>

<t>Satisfies: <xref target="user-story-override">USER_STORY.OVERRIDE</xref></t>

<t>Implemented by: <xref target="manifest-element-aliases">Aliases</xref></t>

</section>
<section anchor="req-use-mfst-component" title="REQ.USE.MFST.COMPONENT: Component Updates">

<t>A manifest format MUST be able to express the requirement to install one or more payloads from one or more authorities so that a multi-payload update can be described. This allows multiple parties with different permissions to collaborate in creating a single update for the IoT device, across multiple components.</t>

<t>This requirement implies that it must be possible to construct a tree of manifests on a multi-image target.</t>

<t>In order to enable devices with a heterogeneous storage architecture, the manifest must enable specification of both storage system and the storage location within that storage system.</t>

<t>Satisfies: <xref target="user-story-override">USER_STORY.OVERRIDE</xref>, <xref target="user-story-component">USER_STORY.COMPONENT</xref></t>

<t>Implemented by: Dependencies, StorageIdentifier, ComponentIdentifier</t>

<section anchor="example-1-multiple-microcontrollers" title="Example 1: Multiple Microcontrollers">

<t>An IoT device with multiple microcontrollers in the same physical device will likely require multiple payloads with different component identifiers.</t>

</section>
<section anchor="example-2-code-and-configuration" title="Example 2: Code and Configuration">

<t>A firmware image can be divided into two payloads: code and configuration. These payloads may require authorizations from different actors in order to install (see <xref target="req-sec-rights">REQ.SEC.RIGHTS</xref> and <xref target="req-sec-access-control">REQ.SEC.ACCESS_CONTROL</xref>). This structure means that multiple manifests may be required, with a dependency structure between them.</t>

</section>
<section anchor="example-3-multiple-software-modules" title="Example 3: Multiple Software Modules">

<t>A firmware image can be divided into multiple functional blocks for separate testing and distribution. This means that code would need to be distributed in multiple payloads. For example, this might be desirable in order to ensure that common code between devices is identical in order to reduce distribution bandwidth.</t>

</section>
</section>
<section anchor="req-use-mfst-multi-auth" title="REQ.USE.MFST.MULTI_AUTH: Multiple authentications">

<t>A manifest format MUST be able to carry multiple signatures so that authorizations from multiple parties with different permissions can be required in order to authorize installation of a manifest.</t>

<t>Satisfies: <xref target="user-story-multi-auth">USER_STORY.MULTI_AUTH</xref></t>

<t>Implemented by: <xref target="manifest-element-signature">Signature</xref></t>

</section>
<section anchor="req-use-img-format" title="REQ.USE.IMG.FORMAT: Format Usability">

<t>The manifest format MUST accommodate any payload format that an Operator wishes to use. This enables the recipient to detect which format the Operator has chosen. Some examples of payload format are:</t>

<t><list style="symbols">
  <t>Binary</t>
  <t>Executable and Linkable Format (ELF)</t>
  <t>Differential</t>
  <t>Compressed</t>
  <t>Packed configuration</t>
  <t>Intel HEX</t>
  <t>Motorola S-Record</t>
</list></t>

<t>Satisfies: <xref target="user-story-img-format">USER_STORY.IMG.FORMAT</xref> <xref target="user-story-img-unknown-format">USER_STORY.IMG.UNKNOWN_FORMAT</xref></t>

<t>Implemented by: <xref target="manifest-element-format">Payload Format</xref></t>

</section>
<section anchor="req-use-img-nested" title="REQ.USE.IMG.NESTED: Nested Formats">

<t>The manifest format MUST accommodate nested formats, announcing to the target device all the nesting steps and any parameters used by those steps.</t>

<t>Satisfies: <xref target="user-story-img-confidentiality">USER_STORY.IMG.CONFIDENTIALITY</xref></t>

<t>Implemented by: <xref target="manifest-element-processing-steps">Processing Steps</xref></t>

</section>
<section anchor="req-use-img-versions" title="REQ.USE.IMG.VERSIONS: Target Version Matching">

<t>The manifest format MUST provide a method to specify multiple version numbers of firmware to which the manifest applies, either with a list or with range matching.</t>

<t>Satisfies: <xref target="user-story-img-current-version">USER_STORY.IMG.CURRENT_VERSION</xref></t>

<t>Implemented by: <xref target="element-required-version">Required Image Version List</xref></t>

</section>
<section anchor="req-use-img-select" title="REQ.USE.IMG.SELECT: Select Image by Destination">

<t>The manifest format MUST provide a mechanism to list multiple equivalent payloads by Execute-In-Place Installation Address, including the payload digest and, optionally, payload URIs.</t>

<t>Satisfies: <xref target="user-story-img-select">USER_STORY.IMG.SELECT</xref></t>

<t>Implemented by: <xref target="manifest-element-xip-address">XIP Address</xref></t>

</section>
<section anchor="req-use-exec" title="REQ.USE.EXEC: Executable Manifest">

<t>The manifest format MUST allow to describe an executable system with a manifest on both Execute-In-Place microcontrollers and on complex operating systems. In addition, the manifest format MUST be able to express metadata, such as a kernel command-line, used by any loader or bootloader.</t>

<t>Satisfies: <xref target="user-story-exec-mfst">USER_STORY.EXEC.MFST</xref></t>

<t>Implemented by: <xref target="manifest-element-exec-metadata">Run-time metadata</xref></t>

</section>
<section anchor="req-use-load" title="REQ.USE.LOAD: Load-Time Information">

<t>The manifest format MUST enable carrying additional metadata for load time processing of a payload, such as cryptographic information, load-address, and compression algorithm. Note that load comes before execution/boot.</t>

<t>Satisfies: <xref target="user-story-exec-decompress">USER_STORY.EXEC.DECOMPRESS</xref></t>

<t>Implemented by: <xref target="manifest-element-load-metadata">Load-time metadata</xref></t>

</section>
<section anchor="req-use-payload" title="REQ.USE.PAYLOAD: Payload in Manifest Envelope">

<t>The manifest format MUST allow placing a payload in the same structure as the manifest. This may place the payload in the same packet as the manifest.</t>

<t>Integrated payloads may include, for example, binaries as well as configuration information, and keying material.</t>

<t>When an integrated payload is provided, this increases the size of the manifest. Manifest size can cause several processing and storage concerns that require careful consideration. The payload can prevent the whole manifest from being contained in a single network packet, which can cause fragmentation and the loss of portions of the manifest in lossy networks. This causes the need for reassembly and retransmission logic. The manifest MUST be held immutable between verification and processing (see <xref target="req-sec-mfst-const">REQ.SEC.MFST.CONST</xref>), so a larger manifest will consume more memory with immutability guarantees, for example internal RAM or NVRAM, or external secure memory. If the manifest exceeds the available immutable memory, then it MUST be processed modularly, evaluating each of: delegation chains, the security container, and the actual manifest, which includes verifying the integrated payload. If the security model calls for downloading the manifest and validating it before storing to NVRAM in order to prevent wear to NVRAM and energy expenditure in NVRAM, then either increasing memory allocated to manifest storage or modular processing of the received manifest may be required. While the manifest has been organised to enable this type of processing, it creates additional complexity in the parser. If the manifest is stored in NVRAM prior to processing, the integrated payload may cause the manifest to exceed the available storage. Because the manifest is received prior to validation of applicability, authority, or correctness, integrated payloads cause the recipient to expend network bandwidth and energy that may not be required if the manifest is discarded and these costs vary with the size of the integrated payload.</t>

<t>See also: <xref target="req-sec-mfst-const">REQ.SEC.MFST.CONST</xref>.</t>

<t>Satisfies: <xref target="user-story-mfst-img">USER_STORY.MFST.IMG</xref></t>

<t>Implemented by: <xref target="manifest-element-payload">Payload</xref></t>

</section>
<section anchor="req-use-parse" title="REQ.USE.PARSE: Simple Parsing">

<t>The structure of the manifest MUST be simple to parse to reduce the attack vectors against manifest parsers.</t>

<t>Satisfies: <xref target="user-story-mfst-parse">USER_STORY.MFST.PARSE</xref></t>

<t>Implemented by: N/A</t>

</section>
<section anchor="req-use-delegation" title="REQ.USE.DELEGATION: Delegation of Authority in Manifest">

<t>A manifest format MUST enable the delivery of delegation information. This information delivers a new key with which the recipient can verify the manifest.</t>

<t>Satisfies: <xref target="user-story-mfst-delegation">USER_STORY.MFST.DELEGATION</xref></t>

<t>Implemented by: <xref target="manifest-element-key-claims">Delegation Chain</xref></t>

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

<t>This document does not require any actions by IANA.</t>

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

<t>We would like to thank our working group chairs, Dave Thaler, Russ Housley and David Waltermire, for their review comments and their support.</t>

<t>We would like to thank the participants of the 2018 Berlin SUIT Hackathon and the June 2018 virtual design team meetings for their discussion input.</t>

<t>In particular, we would like to thank Koen Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus Gueller, Frank Audun Kvamtro, Oyvind Ronningstad, Michael Richardson, Jan-Frederik Rieckers, Francisco Acosta, Anton Gerasimov, Matthias Waehlisch, Max Groening, Daniel Petry, Gaetan Harter, Ralph Hamm, Steve Patrick, Fabio Utzig, Paul Lambert, Said Gharout, and Milen Stoychev.</t>

<t>We would like to thank those who contributed to the development of this information model. In particular, we would like to thank Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, and Gary Thomson.</t>

<t>Finally, we would like to thank the following IESG members for their review feedback: Erik Kline, Murray Kucherawy, Barry Leiba, Alissa Cooper, Stephen Farrell and Benjamin Kaduk.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor="RFC4122" target='https://www.rfc-editor.org/info/rfc4122'>
<front>
<title>A Universally Unique IDentifier (UUID) URN Namespace</title>
<author initials='P.' surname='Leach' fullname='P. Leach'><organization /></author>
<author initials='M.' surname='Mealling' fullname='M. Mealling'><organization /></author>
<author initials='R.' surname='Salz' fullname='R. Salz'><organization /></author>
<date year='2005' month='July' />
<abstract><t>This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier).  A UUID is 128 bits long, and can guarantee uniqueness across space and time.  UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.</t><t>This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group).  Information from earlier versions of the DCE specification have been incorporated into this document.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4122'/>
<seriesInfo name='DOI' value='10.17487/RFC4122'/>
</reference>



<reference  anchor="RFC8747" target='https://www.rfc-editor.org/info/rfc8747'>
<front>
<title>Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></author>
<author initials='L.' surname='Seitz' fullname='L. Seitz'><organization /></author>
<author initials='G.' surname='Selander' fullname='G. Selander'><organization /></author>
<author initials='S.' surname='Erdtman' fullname='S. Erdtman'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<date year='2020' month='March' />
<abstract><t>This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to &quot;Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)&quot; (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).</t></abstract>
</front>
<seriesInfo name='RFC' value='8747'/>
<seriesInfo name='DOI' value='10.17487/RFC8747'/>
</reference>



<reference  anchor="RFC8392" target='https://www.rfc-editor.org/info/rfc8392'>
<front>
<title>CBOR Web Token (CWT)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></author>
<author initials='E.' surname='Wahlstroem' fullname='E. Wahlstroem'><organization /></author>
<author initials='S.' surname='Erdtman' fullname='S. Erdtman'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<date year='2018' month='May' />
<abstract><t>CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties.  The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection.  A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value.  CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.</t></abstract>
</front>
<seriesInfo name='RFC' value='8392'/>
<seriesInfo name='DOI' value='10.17487/RFC8392'/>
</reference>


<reference anchor="I-D.ietf-suit-architecture">
   <front>
      <title>A Firmware Update Architecture for Internet of Things</title>
      <author fullname="Brendan Moran">
	 <organization>Arm Limited</organization>
      </author>
      <author fullname="Hannes Tschofenig">
	 <organization>Arm Limited</organization>
      </author>
      <author fullname="David Brown">
	 <organization>Linaro</organization>
      </author>
      <author fullname="Milosch Meriac">
	 <organization>Consultant</organization>
      </author>
      <date month="January" day="27" year="2021" />
      <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, but it also enables other important capabilities such as updating configuration settings and adding new functionality.

 In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates.
	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-suit-architecture-16" />
   <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-suit-architecture-16.txt" />
</reference>



<reference  anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor="RFC3444" target='https://www.rfc-editor.org/info/rfc3444'>
<front>
<title>On the Difference between Information Models and Data Models</title>
<author initials='A.' surname='Pras' fullname='A. Pras'><organization /></author>
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder'><organization /></author>
<date year='2003' month='January' />
<abstract><t>There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management.  This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='3444'/>
<seriesInfo name='DOI' value='10.17487/RFC3444'/>
</reference>


<reference anchor="STRIDE" target="https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx">
  <front>
    <title>The STRIDE Threat Model</title>
    <author >
      <organization>Microsoft</organization>
    </author>
    <date year="2018" month="May"/>
  </front>
  <format type="HTML" target="https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx"/>
</reference>




<reference  anchor="RFC3986" target='https://www.rfc-editor.org/info/rfc3986'>
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
<date year='2005' month='January' />
<abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/>
<seriesInfo name='DOI' value='10.17487/RFC3986'/>
</reference>




    </references>



  </back>

<!-- ##markdown-source:
H4sIAO225mAAA+196ZIbR5Lm/3qKXPYPsXoB6GjNtrrWxnbAKlCsUV1Th45p
G5MlgASQTSATk0cVIZreZZ9ln2z9jPCITIBFSt2zP3asx8QCEhGRHh4efnzu
PhwOj5q8WWcnyTi5TIt8kdVNcl4symqTNnlZJJflPFsn8HfyOq82T2mVJQ/b
edpkdZIXyXl5n5xlj/ksq4/S6bTKHnEg9+T+EY/m5axINzDvvEoXzTDPmsWw
bnP4l390uMFHh1/+6WgGEy7LaneS4NdHR/m2Okmaqq2br7744i9ffHUEs6Un
yV02a6u82R09ldXbZVW2W/js4fz+6G22g4/mJ7CQJquKrBme4bRHR3WTFvOf
03VZwFJ28Bbb/OQoSarFLJvXzW4tnyZJU87MP/NinhWNflCXVVNli9r9vdsE
fzZVPnMPz8rNBn7rvs2LdV64aYAsm3S7zYslf5K2zaqsYElD+JL+Ly/gp69G
QMYqLfRDJuWrKivmaRF+VVZL2IVfiKCwOdUmucg3eZPN9YFsk+Zr9+MR/fhf
0mozgpUexRO/GSX39WxVLrIiX4azv0mLArii+/VzV7CiAUaNG+Bflpt3I9is
vlW8yqu3q3L9S7SGrHjb+Sqc/3WVtgVOUCV3wBnREuD3o6n8/l/qvBkt3OOj
eXZ0VDBvPmbIJbevT7/68su/yD+//vKrr+Sf3/z56z/rP//0F/r0fHg28kye
VrMVUGDWtBWM5FjeDfunr7/+Gv95d397fjY5oVU2abXMgI2SVdNs65PPP9/U
82K0yWdVWZeLBrfr86wYtvXn63xapdXu8yz75qs/ffPnb14+/vOsHn31xfEo
rbfveDA+9PerTOaAf8IRauR04iOO9ZSIJ8mlTkYfohSAz9Jd8tUXX35DH/F7
6G/e3F9e/A7rPRoOh0k6hWOUzoAXvm/XRVal03ydNzkw3FPerNy5TsoFvAkc
nzp5CcLpOJmzdALmesySKs3rbJ408NZFBv9AsZYmVbbO0+k6S0AUJDWKkCxZ
qAhrSdglm2wG7JnXG/gxUCmvk3RdlwluJv0UR5qVBa4RTvNcpx0lk6IGkVQs
+Xe6mkVbzEgY4pQVMl+hM5ePwJmwwryCTyp8PFmDEIWn/rPNK/ht3c5W8Lue
lZWw7HfJY0ifAX4uz8IKF/myrVgQ11nTIKUGSQpUzNZr/G86n+Nqi+zJLTKF
gXajo6PrAkfYbEFWFkRoXkmHVkgcnGoGxKYX3KTA7UU23FYlvHxNBNtkTTqE
x1MUeS1KxAHwGDzKN8ZA6VXPqnwKb4175ibKN+kye1kf0+jlAg4nTLmF4bdV
jiuAf+HhgrWPkBtqN0c0oLlreL4N3CjJFAfIanw8L+g5XdWIeXGTz+drEAZ/
SJDvqnLe0lz/nzX/P2v+V7LmvuFSIF88ZLbOSAvRvZvjeKkbDTemn91qpC6q
fZ6NgIR9YyOxNyVcavje82S6S1rgGtCGygrPBtKnoTsHNMkmSfNNjbOCYpAv
4QdIHXhR9wg+Hv4ellSUSIcGFBc8OiWSB7gve7dKgVhwmwJ71sQO+PpupCWw
NOqk/iUGMFKlz23Lus6RD4Lpgj1PVuUTzgechGe/y2gjOPV1k6V0oHe0VrtO
N07fujoEh53J63KdulMJPPSYzzNg8sUin+VIayK0cAts3Tab5Yvd/l2nt5nR
eU5BSs1R/hTLDElg3xqZClYLRISD1+Z17z6DyKjKjciFrJiVdEpZYAHPr0Xz
ctID5qvwrS2zClPjNgdTkAEwQo0oQZUoef9elKNff43OyzzHswbTw9/TrHnK
snAkXA+daRoS3+xVNgM2iVdCRKkPUoXGih+QXRwQT+KJ66UUSIL1DncIn6hn
WZFWeQlnaFyTsK/bNYiXR/ywrfeMgHJ4y7IPB8o3WzluJHDMN7DkARBpC1yH
GwKDPK1yOKrKb9k7PBx07Ldp1eSzdp1WQAiS+PBGuNZ85qnHv+6cQVgAmD8p
LAAvGphvXe5oqSO6IG9ZvsjiYZj7rNrkRbkulzt44A/hA1dlk/JVipopWG0J
mm118uLy4e7+xYD/m1xd079vJ//2cH47OcN/370ZX1y4fxzJE3dvrh8uzvy/
/C9Pry8vJ1dn/GP4NAk+OnpxOf4JvsH1vri+uT+/vhpfvGCRa5kF35/FDp7u
CrgYJV1aHylvklh9dXrzf/73l8i8/00sBuBe/uObL/+MrPwEdgfPVhbAH/wn
So4j2IQMdgV3CThmlm7hUl/ztViDECrAYqkyoPTRQ7GG+ysp4VfVE95uYNk2
rFDAH0xFx310YLI6XxYq9JzgZ5ZjNs5RNCt/ySGuLF+M0OCaAZvhijOSJuGp
Q2JlM+ArIovZMiYkDu6Ea88yPKVXKd0OeTFbtyT5tsh1xHI53n3ISQFnhZch
cC38Hr7H9SxIDQKSvn+/3yr79dcR8SD+KPnsegtqCzD9Z3BI6UrHXQdai/OD
tu4KpE5ZvU30WVjVHV+hTb4JNLjZupy95ZFIFqC6gxtR2aOAkhx/V5dtRffs
a3hX+CEebvP5gCkJ2sUGxAZs7yZLC0NRnkuVh00J+1oWsH1reBSoCaKgBukw
EMqS5EYDDUYsn2B5s91sjZPEl9IgyZoZrwkWDCpNZ1GZXlNz/kqXQGRD2xLe
EtkIOQNIs2xTkKVN5i7yWVlVsBX4F6rRqIWWG1J/5llDO41KRdkW89rwH12o
fiWk8M1Qs8MbfXTkt3RSPGbrcktPtHV0LaMSoRcZURLIVT7xRTOFGdckUBdW
YSJVH9R1eqH9d65qLfMcXw72AFSIhvVyecuOUicLvkl36xIUir710nnGy00t
ALjiQP2p+LFU1Jxkzuq+U9BFA8Xn6YoHatNVniYvQn32BQmcQKgdPjsD2EG9
XWHP/NLB8KeLmQUFvlg2J72YxNVA9Ha8wnGlsAnVbgsUHZB2DxdkzezyeSmq
BsuV1F3/DSgc5u3c3MCR6Vue2elSA78g3BJW4/HyDF+epEu/K3Mie3t0REqw
Y4Y92nBazFal07VrcVbaY0/yFfaXTaTgK34dN0WgEPidmQJTPw2Sv6H+u8hZ
7WbNzAqXEcnL70GQ4QrPz/QWcC9511QtbWXy/g8y0/CRHx/m81+PjsZAR3SB
4iRVbBCxpgDcINZc/x2DFPHcL5xf68TCm3Lw1DjFK4CnZeVW1tSZwWt67kjA
BMCPaiaZXdE7iYlyqRIyuQOC4e2WXLWbKbykp0Qt3wwL+gbJsVeyJi/bAi/a
bH6c6O8S/h2+DfD0I+nvoCfPSOtLZ3B3iE6NX1YNndmOKavmApss+Gu2zfBv
kEPZI6pk7MNDG5nJKROTLEaef6rSLXAQStFRcnT0ml0FsKKc73UiqqNIvP5N
uiOTK3m4PyWpC4d4sw13brkup3Ck6h3wfgWj1I4lotHYW1K2qMjuyNYXVRY2
FU4hHYGDm3eumkp9kvwVPh/dTU7h///tYXJ1OvmPl3+AAwA7N3O7dyyHoJjD
W8MZsJyOnzGj46Hzz+jMq2y9JW60tpEzO+Z8tSEjoFuaDDa0E2VXnaxKeCK4
2/0MuEk9Vm2yaoEOQ2CqOfkoZCFgZwpzy+OoEE1BiFWgCKTNbPX5Jq/pHyRA
QUOokfigZALBbjOORcxphcB3OV+YbDuwrYVObVBQ9Zz9U/LwcH4mji0+gLjw
z2q1G/B9xbTPkrOrO/6g3qYw9PnZKLlG/VTMlNqpc80OLuIv+Xf4z695Gljj
6/xdNh/W+S+ZvpYXOyz7tqRHVST73JXDJndNyit5FZAEg6SF1UzzZcvWVbLO
imUDH2fvUKPN8TouQMABmcgRNBAXGMlN+AZoA1cdHkZ/qr71aktb5MBYtBXL
5yxugxo9aYXxMkGxV2VmR4cMOWKKtxMQQ1atROYHdJF4q8aLxIEzdPVlssQC
rlFQ3aosG6IkBvXiHV9PjyWpa7rUnD5FaxSpMVRqATMXtFp4sbISs4VuUecH
RAqSitQ2NVrJJNlnqG3FgjpwEeAhXsScjleEHHb1VQ1waWLRTbPwEsF7FaYn
9+OB6xhEhLvs+P39MyAr9KdDFQn4zHGf+HFW4z4JBA/cjO/PX11YGUSHsUGd
9HjgHx0/3L9xz59fnN//ZH7iVGb3Y1IRjmHeN1nFmi76vlJiJnYfm0M5nKao
O+G5cuJmnOAthS6mlL5I+Bm094PznDdE46pEy1M1ND755/Pkn+m3//QSTjvY
0iI705Gs5MWx9bSwTABaV6m76fUOrOFaWjc5rr7Kljn6q1lKCM/UuBSzLLF8
aOHw35ckk+DY7JJVvlwhm05FjTruWhd8EkaJXVrwynXytgD7OpqkyliUkzWR
3PeLLRH3JH9y9Km42eld/CEELbnle9iPm4tHm+9QdByjZun3SY5DTu6cDHeK
KZ6gq32J3kIgJL0CmWZgqfwnXk5ZrVvIdot5V/RV8luqQ2ogR995Qtl0Kci5
oPM9le16jmp7hea1s5TiXRolb1iaRZTEt4aXg8XA/1imN7v/6WwVuFEovM9H
WqZUEzLUo8lEKJegyYDaiT4j8cExr9Mlf7pOwaIN7vgZfiS6rNpHL+i5Fxwl
EJvcX9byEO60OlDhwKF1uW08g8Zqmio1oIzCpaVuk3P6RZWBdt7VcJ19q64W
MQZo47xtQjaUvdGeUriQ9FVrRy25l4x56URx6hUPbwsarVQYeL2jAEhXr9FF
z8r1OidrmWcAc2MGs4O9jqpBeNx/B8UjxZeLgg7wWZFRCKfaMRHRzePJFQjN
UXKjrG3H8HZ1hcEDdp8gOZlpWVmpT46O/ii2hZ4z1mDh41VazWk6IGCOC4fP
qrYgj4REufWV4JtpWTZonNKh0g9vry/tr2tYMJxcEM2oxMlEpJU6pqbV1Ss6
jyrLvEKZstvC6GFegxJ2gR0UVX5TUsSnyIZLiRbCfwtyDAPHF/YSDmyxfWR2
w6vBAXOQn/K3DSuQI1o1RU/dzeHYH9jMEegfplPDjdqv2STe/5xs8XCjpyXQ
v1TNkeuplnn1HXDoxQFd2KhD+Fv0PZbEmx76Qg6cnD3Wb7Ns62WWmCfII8YB
qDQl36DTV7osXtNCwdr1gRJQqOHt0cgCYi5Y8Mvg5Ksst+lSHGXijdadJpOz
YDqz3cuxLJDsbmKVCVMUI3wprkAogXoK041hK7YpCLwB6fJuc7sUQ5cyKPW6
ro3zanOcoi45gFnhyX2bseOcyOui6sb4o7WCpbwMiSV3BkHROJ4Nqg28B/vq
FzL5P8rOYcLQ2yH3sTXa8/6s0++xin5Hy+H3sRoGEsgnAbYqN+UyA5ZHxyDz
8cENYZOjIylUkUdbgxgyQy1sXS7x+tNB+G4g0YYvnepNy4oLKymsiLMp5oyc
51sRCmi0UbJ/qGnxB9CeJmJTfHmSnDltSCT70VHHllBp8u8aq6a/fmL/Zeha
pTPgnCP8g5+CyH7Fai0zXmcq1glSlECkRdHV/HzD5I/Jv9Memmf1x/CDG30P
evKnZzz50wtnIpK9LWqiLhtUITcm6o78jqBBr43LGfnFjUcE8X895zf/Hm3a
VyfJwxZuW9LOlM8P7NqPo+QCPoDT6R5J5xg7ZNwNPNzyFeJ+MOAxcHz3WfL4
1cgt6Ud/xLtuTAzvYNSMFDuj3Jq7Nxi1Z+m/mQt+fMbe/shPPn71nGdhocgK
P6Dk2BoqzDLQKyPAkNAhUF6nXuNZs+YeEGFAAXuVivFIagh69RUEGwzq1x6x
yJ9AzqwoRPvawqoMpcWghTGf3MbXA7Om7kmvDSALY9W4wJTAz3Bzz/BWfame
hBSvbIoVAAvVu7rJNsdsGpNu5y0wE3muWZzY8dTraJ8iE22qpEF9gwERMBqq
a/foGaPr/EeRPUAn2SavHtlJeCAOzjuvm3/SaWv3zudGIoDC+j2cYDEWP3oA
gCNl/5M/7SU930YR2WZOJyaaqb9ATo83GP8hJ+i5cvSPySmR/XT/42Zf8LT5
00daUOYRVRRydktEggVjj4yI7f3pT/t/Gp6kr0+SHzAKOlyn02yNUeIecZW6
7RrTgOiw0TPs7rhXoOOs17XG0enxtkBLER9H4Ad72v2V8orlBAXJ2fgmQGmA
q7QMUMuCaIoPMsH4OVwgZBp3NmtsNnc8fCiYPNmcfqUPveqfYto3xavOFK/M
FK/4HvaUe8rXa95at7Gk0LEErTN7REAd9DcfbI/bEEXdmYPlBRzeU4yqQdWQ
A2dOiyw5VAb6YFmLmv4WwyHezCE1lwxTWpcbmDaMsUCJIaYjNL9Ts7LoV3QG
tCgtOPqrLzNwAtKQzJHz+QO9YpfaTYWqaY0+BtTkQDNcomZ+WhYcuDOutq0+
OpzTQ79GGrAQNgS8pVP0mln0AAlSxEbXckUqErYsDOlZ4S6MekGoJ3FvwTYM
2FxlnkKcAr81mq90gHqQBHWPzq6osH1uf1K4b0Czf7i9u77tVbYdXY4tEG4u
BNXo/AWi9Dwx1U+i4XggpiBD2B1C98dUbkHFfzgb2ukKLnBedT4TqJGjUOp2
QAItbJf30MkFhGVuWsvhBYxES/KT8I8ZC6xeHV1Z6AIdSKxbAcxENn0xQv7K
tA6S0HnVDqpaz7FnH/8+YWDbPMX2HQHrKEfHv65deKCuOw5F7FKOzqd3ir+C
sVhKKIxCfXuo++PFzVaAWdfHcefD3WR0fvnt6PvJ7R08dCe8CSbsMN8sla9q
ZsrJu20uKI57dGK+74bGMvdIfLAbusIc/Mhhs+AcKxTVIlpwHEHXujcGmxuU
2cr5tZJgAnlMHWZP6FJXZI2DgKGQzzmk4xBp5AJxxkYduAZ5HQQ0y2eYQrGL
ZkUupxSLKV4G9Xad7uCXL7PRcpQ85inuLezMMe0zucPoDlbBVueIecDPa4wl
iD+dVDaT74HBJ7ggl873QYimo6M75Cw4cJjQAW9SOZilOwYk3Yr5sFwMKTkj
D6IGdBMK+6hSTFdiIBb5R1MM66CjCpSJbe0CywpLN8gyH0IiOYrrhYulSR7B
kDCENnzM71sknnlokz5B0E5+vDHSFcZjxlW43GvGGvXwLd81Mc+GqHIVSoJY
sjEUwvRQrgiCjdRprCEEMSuCqA7C1XTEWvGN690noFrocoEz/PP9TzeT3ruF
hOEQY1XqBdJj//r69nJ8Hx16fj+hHKfC4FbfNRlsfA/ttu6ZYY3PUBQNg5gk
RQPUV2c46+kXoqQepgfkNWh0kYWKnPQgQDSBZ2/xv4wEZJgg67fROkjEO6gk
C550vURsxGrDvtVWYIX8LCGgdjEMCUEFG4zMmTcgcB2u0I83QkpE70wSA0xP
grsSUdBBPsOzxxqRSz3RO3DRCJbVE5rhcsgNTT+K7SASQXf/anJ3PzmLdh8O
OayFd/8OtFW8Ry9KMTZ59+3m1/zIcC2P9It9o5KxXMa8lIYMdfeecp7SZAk2
bhGpvc7NmhaJy9PAo1WjUEbAFe8lxVNqvmbJdeg8Karwble7mhy3svJEVy4R
x99yAi+uTw8cQJ3ouONJvX8qO7SuTSxaEO7scvGGxgkKzes7TkEpQix+x+ty
yPlBqKdKWEs/n4niJa6LwBvs4G2BkSA+hTFrQGzh8JqV1iaOQRbli+u7F/if
8c3Ni46r8jWqQnfkAuqjBVxk7Xo9FC8k3izrjB1G/csoXTy0uxoNjMIbroxG
Ujr3qjmQAZTYwx5B25vCkyS0+Od4/RF6oi1QPvEM8pgPdqlaOqfJu96413B5
rpLLbFNWuz4yLOj7DX2/78XJxNzz5vhxuVggwkGO5koc8kajegJ5BkqRACi8
UeiH6bkXHF8M/XQgHs4LrwWSkUVhNQr9YkRIl1i3U95NNDp61k2Kmkl6s6Fi
0f3gWEhuXiRryCUH/F6uH1mUDNgdKa9lZxFBXXsd3LpbO4sNJHeNkUgyKNbp
jFTzcRQJDj0BsIIp4hR6CYxv89dYSAg67ZBAPv4Ei+Dy9d09BYiuryZXVj3Y
LGqzr6Fydc6kKnt5QUgyzPWhvXZ/nKYY6LLmHkGNc+ZdruZw5nWYEkzIfrQ+
0V/AlkGhZxENNE2IKDMHDaiAtUQZR+XbX1qLXK8RmU9eQ6SrpiFQmjQYT3DN
PKU7lnWYlvxwew7/GrtUVPi7pg+2VY46A3npOl/qB6Jm0uef5oO4nVxe30/2
3VN4MQw5g0c3LNxi9uv0K4Gywf1eHXEW1HTC0QOGx3EuoyHsy3ysSnHXwg73
y19N7gUEGGX2B5Ovab/lbM09Wvmvd0BOujv6MJ61fnnsoSAG0CE2AKmI6gtM
wxz3Gn43a+jVnOXACTW0nw5eKYLDq5QeVjl5B8YrbMZ5MbxZE2qaryM+GeP5
HO/sQwpLcmdy40I5K8rmMzkHxMB5L8/EFsXd5GJyGlsUTArRKRHW0MNACHcQ
iD0hHyItGE7UdEe5ZuIJIRHRxxco8qe5pGQ5f2EpavYo+UFAeHkzcCYZqorw
fSkGG/vNBa6EuL+sQDub8hS41EHaNHClf6quOPlx0q8oZrThqiP6FByXoDZR
xLJj3n5aypdCUP9w50D21QMIwo9So0A0PcIl1R0MhjrSLbCRNe6S6x7YJD9j
D5JEq0LkbXexVkDVwcSkXnkf2OH8OU3DH4Rrx/3LCcza+/M6Xg5Zmb3fMFYU
VDHMh4mzqNwWIlkob9AKoyjJr0sDZ8dKxBizdBwpKYFc0SGIqMJEoayzTSO3
GneMOL5OWMY5p/UZ5R8BqYLz3fgfilao6RqpoUNdJi7XtAK1dkuaGd6Nfakx
JpbLaU6hy93acnvJQgJYE4Cdi5jZqhYr3nxI3mpvnvdJ9FRQuP6H7t1dNJ6z
KZE86MFbrntWdkA0oCxDEJWj9c5P8ZtkMD54e/7tm/s781SVL1dNbcU0aXeX
Dxf35z/jsLF6R+9Ng7MQGnu3R3D94B8VF7vp1Qi8u2QoVhSVc0PvkB8xtyPm
dkTkTC3IYvI/NjDPPHAoCD+y6Mz4tjeekvAAMK45SkoP8l0/JAzxL2tJPOtl
9LDYgfWS1+hCTtC7l0FASs1PUl8ROYqnHsx1YNQvvvrii+MBr2jeVrEbuI5G
qlctZtA/sVBDnXrLyfAUR9Z0gGm2KOkqpGtIqMcLpLmyIUMMyroZBm9Ljr9o
yqqlDJxZlW+bY8322k+jWSBWUO3PSGb0uM1lmTIWgyY/yca5uZ38fPpmcvpd
fAjwVWerbPY2uojj9KA+xsdn8OKF/7RpWPsDBbMEzcT8l903Sbu7Z7As0pkA
y7Tp7WbLNwHBjs+bRAtjaEATdM2c42XFDt2sBNWFKYDOMp2T1gfJdT/5sWMN
SjIUCop1nqLC1CcL+CtOjnVKMucl2TJDabvUzGe48EjlRWsH/4b/kuLsizZM
d4HdgKkjTXiDfSpbXH8/ucU6eD+zvRS/Msr/Ck4av/aZvTJ73t0uiAig5lx0
s3rPduhSRgRHVXGsqXOP8wWuXoJ5TxaItybi7Bi2AA5dVKgKy91qarnwQvWg
EijG3ZWaaKiVcdwXzqr7PVwOE/bxIxP/UGFVlF6fQ+aeGj7xU0B+/SmcwBh+
6iuX7TZgiVVAIgXi+6Ewp0j8nOZDGX+/F0NcD5KJ5wzYctpQgR0u5oHRY6pz
wwTWSiUUGcGZAoTfoX1b2DjIQdKjyoBm2+n11WtgeNAwxhEemH3XJH7nHOBH
NDBtw4/nN2qE9tH/Xb5FJQC/ZrdfWc050V2ZSu9sjPPQYX8JQx6LRSz6oOcg
zdJByzmRgdEgZIB5cE9rzStRcmWNgT1Zwzks3vKejDjbXQOeIJOwMKVcimtJ
bpeorODrTboOp3+Jt5Uk0oKc3sJWVB2mJEGO+mU0MgHKHZBFfIFmkJhJvU96
4F0I/JoiAM3UKPTXsMRPBAV80Ja/QI8PxdMvJfTZxwfkF9LYKHCC/5V+GJ4b
6xvuVL7LFfaTG36iHbV3Ab+/4nx0Fo68idlSoKuIHHNkyzE8gOP2qJw/Ul2Q
tXPxHsuDc1JKeEH8NEZehMFgTbfjS4KmBZLWvAV8h3FODl2yDmS/41ABJ8/5
z4/uFRswoHeVCOAcX3mKZWO2O6nlwo57UmSRF9CESsmT3Il2UQACn8GUu0cK
e7ovpbyI0k1ccILLRV1NrxQRTJR4EbwWA8z82whIK6vwpTDUaYpN4vI/gUMv
rsc2dum9lbdtEbFXL1AFZJthyu6P9vIksg4oPVXaJ+HltJsfebSZL3FAt0dT
7YbbMucalbB3KE55/8TB8BZLha7V6BliaWg3fppc5EX7zlWl+VjqGRcUUg/J
Efp69/t4xamkD5pJD/pfbNlMeHvjDWF8ROjZYTvDe+8QXuPqGIEMhlsBGBt0
HIfIUcAFV56jRwlNSaUV9A702lAnU5i0zLDyKIE5Pp62N+OfIuYMvOkHvHpn
MMuS5z5doWbQswuwVExYzje1bMTc/2i24np9VJYsK0DPnqFSaFOOotgIYZSC
75vybVYYQp2+ur5NfsimyT19wRm5WMkaa9XhebjRzG3MoxWp9h1oMXcZrL3J
Z/qTP3/9519/lRKhNAmKn2y9EDBWwyAIqs2ooRhfyoKVZURXVZIn5Cqn0oA9
72AQVZqui4Z7O13zhnN9JfM3mBVLLNyXo5PP191g3nLhcoWYMp0EiWZe6nL8
k79lTOUakSuesDhlW1NY08uRqApBvLWk6KigQQ6X2kfOB0fqkAMyUtxRyyl1
+A5M9JTISkEB+4j420D5ILvsrZbp2nVXRLbmVIIwWsQttio/q5N7SoQbUyKc
0AujplR/R+cIxnIV4Vrnx8FUdKqLRI+HAaLUeBy5Fs8sreYMocZ6C0AIPxFj
anIuJRjORtSMFqbpalxM061UcF39rm1jrIVxlw4BgV8UtJgv4mi48yvmympX
VGCP8M8UxKaGAuIXkA0XDnVl61hRcgB3PeEU+tevXA0x1Iwlt1FqA32s/DsD
vfHbMT5jRKB/b+uu/G7y0+j2+t4+jEYHyrhKyn+i0PS5j6ehk+v9H7h05dDX
vBWpyIkLdAO0UxzUpT3H1XY5f38QVDMd9FZkk2TY3pJsqm3KTAwKDXQIv0TN
knZZBwfL06Dh5jedrZ0nMJ9WDBbmLCWO46Q95YcThDdMd+w2yVlXkzKNhLdz
MSdXwJMAn6Lx8K1OdyILHU1oRQVGCgppANRjsWGR9FzN4tM/Omev1wvySuOX
xfIFuTN2Nt7G0TUXVdcy0CRXWOj5YozdlDeqvMGRVloEmcBVoxAwOTjAHlOY
hEpNpKSj0uExJUpyKRUtY8hLrKggoQDUKkmsoUsLq9Tk05bSeugFsmroQMZu
lWTOCxBUgQhs2mqheFZgpIAxOXjW3CKD4Te2NwPwP/Mwd0c5zPqgMtjd6k+w
0ILARKenjIBffOIk/bn/YHjnFdfLmKszvYzKdrMLI1vP5SdSACGuLLvYP5Xq
0/T+7CHB0NDofnQ7Oh+djSYj0De4jwVoKFo1R69oJh5yNbKbOM1mMxCDbKaQ
RXi3BY2GjCypRYMf3qebLauUHKeCuxw/vs22LVatJDvtj0FFSLyD1iVCFPCb
sziIjB9OsDafvjJoHo9wopeZiFwrnjgEIAWpTcF2rjEqzmSwSYqaPCs2xUDz
VtAzbPL4nZI1k2LcvEmacK+F0g8PGSSHON4pUT74kupg7XGWsEIvuQorl69u
GdqCOU8Bf59lHDlgKOQl2+sBi85Bo8rXqt8Y0StmCJYuFRLCWCnHHF7IDbBV
OxfFExCFguGEFltZb7xuAYmrBYq1cpmRzkRMUIr65Plbyz2lXHiKUEAk++gZ
b6r4StlaJ4FABwrwjxbA5mOdZZsEQ5NuVMyLnYVpD25ZtRSl5xBLZ0FefAnm
8P7N7WR8T46fyY836Ec8Sa5hZNfAyckaTopAO/BUDhGrPichO994dh4XTiTC
CjCAh/rNes6ZvZwZEFbP7X4fesKijAMimxQ+42JdQX+JnerAXXlMo0k9Kh/8
Tc2CGTuyLnOWkOG4VK4Ymc1U1DK2P55k4qCJ48ATWa2fABc95ZvcTtTzGgO9
M7x0UOQZj8+yYHxxkWA2wB3Mf2kuz4+ohdnHD6Pr168vzq8mCTDGYkHuCDng
//0wpwxLfvwTOYbxPUHyUNr4i1gGF+c65gj5IttVWyivddPNSKt/Pl/a6snP
4tFwgh5dgKy5J2uAiW83Y3cmDkwOXP/ApqwbSgRH3HaSPoIE5BI0Lmn4t54F
w2J7z0PM8f4khtYrA7I+sFHqwW+LlFYhcUosMeHumbH4HHPJ322I98mAWZst
SmtPJImaiSkLl9SsUU2S3CBlFZwjtu9rdqcrDlrPGJUWQo1GBLgLFYGNmS3a
OAVLzF+T86vbYhQQUVELqRRPGJig9DpagENBpDPpCXrExbKrlvK/C2JKXxU3
Ucx0w4mU3dg5ygtVqJkAPPqAIxs7MhU4kU1WYdKyOMNRCqFKeN6OPkqumbf4
YgSmnTs9mpaS14Ho03VS7Dovsig7jpGRFlVgdHpXY5j0qaw6dikOtRYCN9st
mQH/z8rjbuZajNh5BlZh0JHc51e+LhC2bONaZVmfrLalkXoEtVdf71R97bnV
e+XgwGG3nyo69Dsu46T58YJrJrgZn4NOBRgDGvGwMDyrFH7mMoxuxLi6UM1G
o6+ArpIJ7K4cgx+UJW2rVe1bEbGJbeDk1iKCgZUxChViS5ghtoSRQ6LXq2jN
3ggUw0nqKzKkkYbhFWEbiyqZwh69JVrSYUCoqjePolZaeyagcqgOXqdS19cz
w56Pmf8dTIsBH26VsIdrP1R0KoirDjjuqzl8GKeU6hOD/ioLgySdl7aeJhgj
c6lemFv84DJzjnysFuuqljVYmIUBCpgB44pLub2kUXG8muhqat9lvh6D1AEz
Kce0MbVJ4kZR7l5BS6/5Lmrm61dcZIwUSSm9kcpl44YzIAoRMH0jjfkmrLK/
ITxXIr6ecX3tEMoxJlIgO5mKFVUmEf069HoQxRz7kL/HEYuTi3hZgz3rUiRX
VJkqqOO0jzaR/OIEVe5NGcK84dy5PjsCAxexsnURLJVsLqn1eXLt3Pi/utMI
UDQuuCSSLmcIKR9dC/VQcqSxuoVyV7N/sWKh+duog9GPuOCunN2OxsUZT1sX
6lGEXOfmC7RsrWLbXbslgjr2M/byhMvCVyfdMOv1awh4sGGuW2MYdcvnlLM5
yYmpslws5r2y56PynjuMdXF9Sk7nPtYSqoeAEXGx8A229gmxhsdMDuxHcpmb
scMd/dMGVU5ERsTinG6MTvmODvMpg3HtLVtZyl5CbqXSbyV69B/HcOSy/i9h
s49K7hVOu5rcj8BwBuP5FITYbcadfoRieeEGcVy2KlmpdnyF7akr+d0n8BXK
7xxz49lUWGSulKqpZhBYdw6bhGF2qW7mv2U3VDGnigVtAC8znu0PUPPTstAC
ol5fgd7xBg5vlWIGqJSHzLbhoUTilQWaUD2kc07ec3HyDmIX7xm5eC3Lumkk
cUZmJ4enS++ySqgnK5pdcDBQlSSU0hxDtxRRRbBJLWFLAr6qbFU4eoAjwYEa
zeelwqvl4sTmZxioQ5M2LdWpx0xhVolm6dYHrziDmNsrceoOOh4qbkplu0ax
a0Kub48VRo8y1T3HWFe8KJguXe8EeBy/ZPRuA03BEbcC6aeYBjbgh1l13h3m
q2flR3wK2DEunfrx/GtGEKDrvhUI3HXvAm4nN9e39+dX39oUD9pI2MTuNQeP
X4xPwfRTtM4tw6rJV2AuL3ztyn/1iY46GUEKhFKM4akglKTRFDj27kQUBiWp
JYEP7KUx+t3eRKGaowhSK6Q+q+mWUHgAfar3oq8vHMUimjI4al4d7ml+YLwm
FElKq4oOTtsw/2KmKZNK3IQ2TJDYHnIShzUhWI0PpIpe4VJL14vkFE38z/Wv
ByDFS+D3++vTY5uN+CnOjV4vIVf5j36Mh53KwGkjMfxZVK77d3CGfEySZMDu
V9dXlNN0kjwUIazjnO2jQF9rw2eezfTJ58kYpD92/Kj5vi1CEpmqEbmpqVb6
ygdhhaUpZ4Bt2zXXPRVhqFc03hcOPaRBYwEkaxWYvfGHTxKYAWEfbs5GP9xe
X337sythh/R1ZWt89b88InK7nQ9Jc/Xl7Z6jw4T0vTQ5pbWx7yTBIACpxn7q
XDqyo3YpfcoOpPPW6L6mUSoJx8kGUSGffc6uQSc/I4gUuFgFpWY4om1DopF/
OFDK0MY0pZKj56NUK7isgQTiLT/2QIf4V+LK8GGDsqcSQscD1ayCGnhkV0QR
mv2qvLd7XUEj06yO7Zp4mTz576zhxzK9LdRWYhwJey77Khna8onGPjfLZnOc
ezZzIxqPspT4kMjWdZDBcUj+fUy9yOCsPlyNb25ur7/HAC6IQXRXPvZ6fPF4
tu6B55zMwV414D6S+r5XsS2E4WGVsgfrBna8wV1gCApVdHDgHnUSVRnF85Fh
phmIvbxsqzhLii8jiZGU2naXlHD63H5sQ1YGJeqOm0tiVicQzE4rmHH+npY+
x164ss/wT6dak9/OLZRdi2Q5sEOVtW+OzOPAdfKSQH/LDDmEQP7ux8caOKqz
EG+DGzmtEMjnYj0uNClV/RbteoH/pkSAtkLPK9GjouxJhnmB/cHYKFVRUutZ
+Kz2tGuUkJ9J96iU5Jj0PNY+x9ybGVUGeU005tnWkeX5DXQtHokB8aB4/YGo
kzcMptonBbAEom9KlHaaLgfd8AKGokVw2yRbYe6JMPo+r8Ttu9o/y8qUGJHI
He1QMDC9HV32GtxTIJvaWPrqLp7wmLqbO36LjyaLth/GJKhGFVtdbOSRFwVP
dtmcCtxHYJrZinKMDPFcpATxQHIMsKDwK7YvT/k/fShEKhoZZLi2i5TaQFVa
jgD1YSxwrq0Fxl7f8WdxF3C35cvwhABv47miepR6cGd5NWs3cCMVvl22v7eo
RACKPwquL6kktoP3SDEVDV+4JdpKjy7ii4li6SJrdsMZOvKp3pxEZp9WmZy1
kAam7iiuynASGeSjhGrjenkd1SwVP55g9DhyysXJMHoNv8P1jKT8FtwlJXV1
ccitvVJShpJ0NJdg5cRZwzXjmP1dIpssMqxzy1JaBrTnTOr4dGSkwVj5qJR5
QRdVDxAVwBz/2cJljictIAfFhJ9W5dpzER/gSCh2vLKmYur+cys/6pBRuIxt
OjEBPQZUa4nEKwxlG+1PsC0qWehFpJVhL9FdiRvU1VbenaMD9OzDIn0EvmP9
0G3xTIt51za5x8rAD2yEREbm2ZKieORb53wwPIwdofq77EmfLO3uRUAOSkk5
aEq7mVmZ9wBpm6ZYuyrSuQ/fcRI1IxZ1aWPf+PEDT77qF4a+v5bSdu4iw4Nk
naVzV25AEJ4Lb17t10E/UEiE1NTT08nd3c+n11f3t9cXVk0ln8pQTFLWUIOC
l5ea1BtvkDb1S+64rkqkXpD4Yki5C2nApbIRmRw9XcsOcQSBlk+YSG514LZx
2opTpruY3t8zT5uGdNgmIacawkPRs8SuAmknfFXbQiGkrRxaNuN5wgi+qBCO
McpCUFI0vgUOOc6im/gVnfDW3fmR5UZl4qcCl7XFcPyRKw2z+h4EzgXm7GFa
Zq8NbEZ45SFi4TrdA1yENyhLErTedGTyTQzCaup965YGbw0D0ZxUcpmFnqjh
aYsig/Z7FnFPSF64p9cBcN1poK8+q7kh+842Jpvn1D1NVCGyRY2gRH6UOH6c
7J8zCDJ2XxjwCrLJfiCHdy/uVR7NWKb0nnWqEJYigORoSRHhAV831JYYUZqM
InHw1Yke9o7+TrLAyYr4mIDo0q+Ck2J0k8xXdBZPByM+FHNHgazNpi24GjPN
x2k5qHSAxoeqky0SZxQ2KRJNR5V2MjaFmK9D9aXnsVdYhor6aZm7s4LdIc27
d1x6TfLD1FFdXk5NsNiKvuk6riy+Ac0SAnd4ffgtYztu3+Ur3CfrDo15+cka
T5tTEZERWbvs+Ou4CBH65HchCJ/UZAHUuDudTo1Lz5knd6fjs7GBSkYhhk1e
d1amlZ/0dg8EVBe3cnZ+d3pxffdwO8GwLwKOs2SCULCM44vXC++P4RYfKLq+
D2C6Y42fBU5rn1TS47AxblO7yU9pwVfXpmyLxjtJ+RIxmRpUGBcUl61ikuS5
FeWk1xSIBypm2rhsH4SY9oeVO+Rlfv/MvH8veoYdbPDSv5D4QYr45hkRxG2v
3vKp1Uzc9gUVgE6Say72Qx3z1JTzmbSaiOPzsGyBoI8Mo0kKM2UkkbKqiiGS
SoFXhDxDwKzMYeopvfzrw93k9ue7++vbn9wbwMsj8pbqAu986aJjLjeC3eHY
qdlJO0xClcAjy/xqInSJRoui93BLlVIKXHgUWQRrOoV1PgVuQD/jq4wLw+Cn
uF++Pqwqii5IshCNa7Yq92ZevNrpYijMorunGdm+2Oi+ImW2RQ6/yOCDAS/n
jD7g8P0YTTpg1MmPNyJmTg1TdzgUe7eQ0Ig4NZOPezjVZrKdmUw2vH7ySnMq
tf65CymSYxCvFYbWBpzlov6m3OUeinxKmLwnb+X+dgxnjop1cJSIE79J2gRi
lRZ+WKJShCZ4d3bnSbUnLpkuFTBzU2KVa4VwbwuJfUvgyON/XBYSh5fdFDP2
x2rTAw250mChp/ItXqcNDi/OOULuc9nNMLL7Idl5eXMxuZ/8fHb+7eTuPpCd
y6GGG6XOc0hyTOb2/Og4TipX4zqozIajO2Z5H2DAQ6Rnk6WWelkohB6pRgED
pUxQnx6I+tnQpec6SDsUNWxnC1+/fHN3eWzjrLgHcpl5FTLVpFrefRDiOYcy
vC8VP4fJnW8EV5rXLn9hYWWJaSUpEbmICXQBcQomL6Bslyte7JMqP4dW1HUC
B2JeW3O7aj0l+wwxywLZuuAQpsEFVaBqDYLgK4FgXYoh040HEKOtsGIDZ7UY
Jt5Nt2DOie6sEcmwyghqjHPDvjn1jBnA31c8937OR9a9ub2+n5z2VCLwxUY+
oXRBJK8vr8/OX58r9tTGtnGDbK0cvYyoNLwSKcAGcrlWM8SHD1EEVEjXLI/6
5tUimyYhYtA9EFo/uu9Q+LQs0Rbigu7WqmQbvMvfpBPuQgvPY9I7U/S8pMSf
8HGSm0FhcHlL/rLCoAn6OREPZ+pDs8fIvj7InqxqIon8odndkIdJq3DP8Dd8
2mQ2330gSsA2NGWCou22jkw6Kv7CcbzNtm3YXa3cpSYWFwCQDqhuFdzduSy4
apiv88j0qPVikk2T7vV6KCstaiC1k40W8Pd9DYdLI0eeWQWv76VcZk4n9bk+
HlK259kPaTAmYcvrLZysFT16f/tg2jG5h+W66BEl99en99cPB4SIFtqOCtRw
CZNYE2xKULrbj5YgCmQ1J1Fr6+RxaZ2XAZTtmMyb4CiQo+algbiZeziclq0C
KhsiJTqfYKPrkrEFUeH3DyqZgZqjqmWtDQtUP7i10cX3f1C9YWijjtrBoLdG
BnelqbgrIWWQkGswV7Fm0jJtlQMtBYDlwN4H5T5+FcdDnNSNPAF2Y1mAZnkn
aWfJFeGfcOVxwjcs+hqrSzwn+05zk3aiIWywMZC2b0Nz9MnnK/khxCxyUUrp
iQ1bP5Mk1KrFk++L4VKBJS3ksNG30WJeQIOaT7m8HIO7alsZFzUQZPOH+9Mk
25ZY/EMzRqU0AhX9oFalzx0f6FOVNcnDnVatzwv+UzMAuG1w76zqjBRhT2W6
pHVBw1cMXZ35RhK/dq6Sl35NVUDSuufFz9RV11KCOCWFeXJyO+j4bag2nsI+
qMJGMS2xalb0JKiII7jdGk0rL8r4CaqnQ7a1FCs6ca5mApx1m81SERjtlGj9
DOHA6Bzt/FaMTklToDI+WAaT7ibCD6MvMwhmUAC1pwaAehHWFOmP5/aCA8tb
dQsigNQICx0cm4pYKmz2HkX4tWvYId8MeeLj8FjbFF5OlRvIdlNyk+kSZU93
kM2r3EHHipmIULze4St3dJCkB1TbRJxF7ZAEMceN+gKQXO31lEdZqVTXcvYW
1nDzJULrctEEH4+SN1jY3Nf8Nz3juGIM3C9g2lZVSSUViszVf6myJUwyQCO8
LXKgaPDbqD9szs1A9u+xTZ32G22zpPt2W1IZz89892uzz9LGPKeMAO2z3vsk
lSfCB0NWAMY76enDa/LGqcS421Z3CLDKnDSzVScEb58rleF9/b7WMffOnYFo
e5u8RAG35gwVRK0fC2Y1eCiP+uriuXvdWYzAYaN+ryQkB0F428iyQBkG01BB
t9rOdy1YHQGwdXvJfkK33IJb2MbAut/eLtfGKRmj+Mktcs8j0FaKHQGfpD6C
r2vMiPJ4CwdaG8XVTguDzCkVKPmgHNTCMB15qIVf+k5KxMV9Tbj820bHwKHX
T5LToI7r2LYCe9/FzYp+FncM8z3itQTlHAhEAE0Om/r6y1wYJUs12Klbqjc1
2Ad5Q3oEG3ZhSRRvSKl3sFuGTXoW2taTxj3khvisDl+DFuBaUYfLx+R+gsHT
PQh33wpEX8j4xHsplwfsXynZyD0dBPalQtviog5yJuTxhS0lT66nhZtfAXOl
K+Igd3ZnKGTsSywCv8w8I0g1XUkI6p8pTopFHcw7uLw9xWa8+lc/ghj7T5Bm
rJgbppuZgrdFJ/nR/8KnOfads2e2uYMpwjZ/fY+HXf56DqVLyD6xO4BJIjI2
WpJ9B9Mka8sZjdP5e4vDdirQOcSG11Ys4NKU/8dy2z51KaXC6qRwsB94sLcc
9J6ddL20O1UH+nYlbEneR2v57eDZO8i70Weudrfo4vo03qGeZs8fSnaWnYrT
0mUHfBklQ3UG3FA/1n1bupfCmrMf0thkXnd5/xP6pfYwtU/4jIl2ywl8vmj6
c9JBY7JJu1qlm1z71Go0/RD7ywKwmS3e9LUDg0oaMSkNCC5KUg7+w4kK5Zb3
bnf8tgyGHKhNr54z1GSwLQ8LVOfriPpPYQdTGAedxLeyusBSeYlDHLM/hEsJ
4OF7//5/3b4+/dNfvvkf5N3o4QSbUx/KQHWc/iZx2Wlne0gOuna2fVyDCYwn
fB4zaeW571i5lEaVfcwJd2+uHy7OtM63xxuK1lsuXGcRW5MsdLq5ZsSUTc2F
apehVyw6ZpIzbE9ZlB58iG7PvjxIsP2yR6b9kvVR1OQfhsdw201BPJAy9at6
MkXnY0hFmPplW3Rs4P4oGcFMp1C7yxg0g0MJhYlsLhFPHvsIgdeTdel3pCex
sndP3HIYY+T2xm2JPnDgRlcr+BxD8DHhxdylzA8xZ/uJH8DUhMutdc7AQSGs
9xsG4Lb+8vAet05jSJ1ctdH7syQ4ohlgO39HR8Crf4AjgOHZJ8ktw5Llst9n
/zB4+dfQWoQLAL3SHlnrIc5xa84BpqhXCPKk1DxEOMvDbk9mRI5CiqxttSeE
fXignnmtEOGeskr5KHwJB28yLSlkUDVfYNRnF4KwNQKlGHZoE/QExyP7WvC8
ElmyKYOO18hcpzJaMB1jpepVvmU6SILUvzHiV3QA/w2FvX26leySGQQf6vlx
tHGU1pbVtv1bDN3kdXRzJCR1jArjmQCM9eaLG8QfKAWBui2VNRHkh4v0rToQ
Xuci6kBF94pEn9waSkOfF/UbbKDwiPUgCX0dDdOC7v1hdKEIu94K/1za2zaT
6GnbZudaZWuOXmArDHJ/OZwIbbYpHyrhMsxRxT2oNBFk5fo477FVfZ0Z7f2s
Gdv2zYL38KDUWmvhU1VxsrAj6CZGtgiv0oMLNWk/oSZK1hxM/5hJaVUzuZMD
jLXjKgDdajW2kR61L4gIvf8C8GDe0PLwb/2bNM5uN8NeX1inm2F8WQcYQrio
GQN1KjkU7/dgCn/LpdBI8Va5HLJY4LvbQZxLmU/+T10bTBUUEqWhsYUHfWo2
Fheqg7sDBWv4hhc44Mvx6cUxXCGnF7U3LcSX81Qm9QzOWZWX9cnR0ZeEhIcn
JXRZSxKqg4XGfigJOwmCdJ5xKH3q2gwSVUZHX+0Z1zWxNIrP59qXzX8E/JhX
rvfFU4UB1qI7Sx+zBtBlz35h09LBb5enp+ucBeecITUD8lELVpsvZBN8t0za
B+s8UQGHHgEXsXx/EOvJnWSj3t3EbSwBTG9OShtYS9WNtOrZV98t06TwCNrY
4m9U5npw6z5B6qqSsLtjnQH77hEwAYo32jMFR/4W8WK6PnWapn6O9dOkvYP6
jfruwAARepL8QCm01qQI7sAOSlT7lPGjYtRy1wmqDOKqkdTbdCZZ+Yv8XTYn
Q7DTunCUfA9HGH/Q/70XO9odSawELAG+1n5Zv0gJYol0uH7eJHhkp2tfoI31
GKqUZjNJVO3hb0xneG8bRi5KdDtGTUCtoCPNsfvydDHWPiFHfEQCmkuVttJP
8ZEtKhPIiX3zMDlaT0WqLyGPL1KsYAK3NerHILVbV469yjbSuZp26VBM6P52
HF6UhID+sNOg/miXs6uG5vwst1oLzVo/+hkw4l1QEy+uQ6doQ6nLJXlIyk4G
EMtA1tASHYT6EZot2L7RwrRVgmwCyBamuUgtQhEksrz9DrCPEgHdQw4n/zIS
nsDSyyUn53AhEhWGspaQ8CFe9gR7AEr/Pj2NXdR3P6QWEWfdVowLD+X73MLX
DDCzVkni/cmasVJoSSKy+VnfyQVqLElhmQt494HD39xdaq19uIyHSxSXc4cz
dEKC3qH2Oo3BxjFAXRVuahp9dPQdvlr/qrH0CC2Zej0JUjGv33KkyYO5B9Lz
xfWeGmhjqpfe0BOkNWf/M0zSLf7YBaN1e6SW/x5us6B+z28Wut/DcW8E7DFE
KCGh3fNaU2SBZquixBZzSHtRargTECkUJJ6xHVDnnmZOHSVdVlQc9sczokK1
fxc2FBeplu5EHy3qnRiod1FgRjqiLo1FZ9jkx42WEuwCbAzaJQ54Ma67qb6O
hp79AqTJnta9AnYK2i6Sqo9pCAZGEAD9XUdp7svB+n0H4cEdKH1LCwM0aGsF
9wZ2FyFe5ZzZmRmq4FAIZp/iZg4C9xhYXbrF1NWP4NPfkcHltlEeczy90wUS
qE3uD25R+HnU4yzl+jwfw/Y9qjTii09AIWL7ynClSxtgHUAKfnZxyL9Sc60O
K7tge884LuCAkAKSgyBbN64AAOx+hcZgkIssniLc3U5Lc/J2pRtb8qAtyIDX
egkHVGebUBGpz/aW7bsWpYFJXixA36EcP8Ij/EBtFZ+7LwN8fxSwjQwHj4EF
Mlyj5PXwNixZUdeiGhD857HkLMS28K3rsV4qt6GmonIV1SRqWsWV9jCAoMYp
/U86fXkeoJvF9y98zKuy6GMEeeRXdn1SnzC6e/yWGz8i5Wg7CGnpa19hvFwz
ZLUsmr9k++Sl606WaQ6PXaQvpKIinfuaY76RQPiNd3PPTe0bZ6bm6ncZA0E2
k+QQucZ4vsRUHtSWgqs2yz6NC/fIoN/IyTeumC1cJpr17uKyC+5sQfqW6COW
zBx97uaVVZlmgjNxkF8TBqa47F5fOpc0rfAc9Vv+aEA63fNttsXWFZu2IftP
Exb4uvB5Cl1oPrDqK3UqBy3DncEmmaiOa3zwjVPGOpOi1hWAg1gEipL+UiOu
nLzBnvqGLmX/HfxxTGirDdfCBqIs2xQ9alkE3uLFLPJGiymJy7LiVtGbspL2
1HL38kee3b33kr/hULy/c+WMYRtRcbF7sUW6iat0jsBpyoqqLES3JjNG4zVu
3FBX5sILUhmBBcA8m7ZoRtQjly1i2gR0CyzaLCvfpIcdwNSKF+VzY0vgKfSu
j5aw3Nvx5YEjxikz0eHizJe+Y8WCPbjFBUnfovpGlPbIC2KJ6I5XIc8Tuzqz
lFjygA2x7rjfMDC5y9KHP4G9H0w3Ytez1ZWPRbZDbGqtjgFX54Sq/GdS739P
p2I+maZYwDkcy/HFBf339oFsujvMADeJH+c2Df69rSkgV/vQJsqjf64n5DRI
zqkYhe1Du/HJfQzs8z3T9+fha571OemJb7Ns6yp0cFvQWjuLbnYOAiH4LSrq
sn9o7vU5zagT7EPNwByqhbbAAOCKMe425EwVY6akHYfVDIirnetb2Bo9utQf
44/JWSld7sk4hxdYIuQAv7nBnl5Yry2Af6LpNy+lVhitf0QtZz1QdKu/c5Be
18ZIOvqpW9b+DlOvpErjBsyAnCqyDmypBE5wKZbDCtQVGi2tiY/vgIK1tNY6
+fiOZR1OpB++Hp9f/DwZ3178dJK8hs1MJlgGL+S6BXw+zPBz5TU+oFrHUs/l
0BVahTX6SieOE6fp3Oaa4rAkYGnG1JZ+L7mkW4Wh3RQz7YEkCBPHc09WO+kz
LdtRxfwpnzervwOFOqVJMlByiuHB4iQ9FUAOnVDXXEj815qm7WqOIKsVMKnT
92w8Lkq/i86q1vQyx54qSiIUBayG9c7DdDnPLJw3DxHTNt/gMU8lNmiONrtP
uH+2612OxjA3d+MrzE2m0kHrfnOOni8zLQvhvBS/DBIVf0U82/PAYif8IiYT
Og6MU7iNkoBd4rPN/w1VrcDFKEBv1QI5svlHDy2pnzU5FbEzkthWKy6LXjLb
PccZ/3rGzW4es16q+MHNBbIon0cb+LHWIbWXgsJDRB2zK6QV3fAVgfLrrsm2
/bvlnoEDA88cn0hWN6lnJB3h4LviRpwzKeBXrBq1Xtg6uq7spcIygyPk50po
Lk2HA0MS5LKTPEFVu6ZUPCBHnGR3KAylcAopRC6e+2gWC7XKBfjGcQpi/XhN
Jm8KT7w5AR+QbRg2ur6aXN3Hss3FQbuyzf0G7VmNlj7w1RRIMTfGMxSNea56
hm1FV/p4bD2IZJRJltBAkVwRA1btOzCbhCsH+P0ybfbMNIyN6F+OdLnBCJXL
LqLM+p4v/Jh/h024fLi4P5c2Gq7C3ljMvrRHAdzgQ4SyesZuOMUp4zKMkoDT
qRetieHeb4R2QLhP++oG44BwgEzN4M3ONXdcpJscbxm/JA0TMv7AFC7HreYa
WVw9bWelsRYW35A7taKG9lIB7wOb4gkc74qn5CfXWQ3UetNB0e1kmHkQ6/K2
VeKHttIWcEEzc6NThG0siFp1K110uUQ0K+aq14a7Wm5BgGvRGKdJOdey34X9
ZA7yMZTCQUJGD6W6WC+J1gWVtfrLYvWQsQexEPT3S6Wgm7WIeL69MKtYswqD
0rgUjOYSWF9j1GGogrqUhe7XUfh6ATqNyuEjoCwEXHGamo2akglqPUe8KNs4
A6y7bE2qdc8bxQlYWoS5Z3t/W42/aMsfrr67uv7h6mc9JLrjmvJMBH4otmC0
U9JDwY2S9h6dlh945hEywgSMVqylUGQ2W2mnIDyya9NuRSBtr8XSkYu7U98a
cg043YMCQ3Uu3UdImbDlpZDzpJpPHWkAkU7DgGkGNGirlXI2ayvJvDKDkk9G
NN6MinME484onsM3nOQ7ilaTN0GDGI5f3aCOj1h8/PFYtfXPJF290fK4nOJS
Gz0Ln/80tY+W9qnZIJ8umQbho1cTUxNGHy2yWpICg2tFDcOfOV0pvlscAKxf
+D3c3sJh+hnGuKNA6p1g8b+XQglX3uF/z7h501AmFn0crBtKkYWPu0oCVD6H
YFWy+PAkV3qUFPC4qEN8oajJyZE5eYjllIvYSk5pzZWIDXrtwD4Kre6i7dEJ
+gl9N7mgZqATxvueeRlwuirR6nol/mjXsSwiLoPZvNNDAvz7Lmb0WdrODe71
+Qo2Omj39SM6cmsngvXWOTcuK8uG+vtpCyh6hdr51IOWESbax9XzqXUfarhD
2oTDxGa6RaRmWnQJjalXdCh68q8eSBBYoKEhMC6KjovSV1xKyIWEYhd/vEvY
+hxJEN6rPmrWdaZoHjiVS5OSqvNy1lIkxk1CzjVH/I32CEVTJHdVWwayK/VK
MmU2ZSFoTFxOYMn4FGkb1DigQJnme0hrfN09VD6boI1xCwoq9ovStCk8pBec
ERlTd+4e6vAw9ZQJa7lXLdymcAsPb8eX1nXXoaoOigzFnEbWcOkvIUnnjnn2
HK6NhAtNp51R9jqz8iZAKEh9nR7e2E/ji+uxleym0W3sDwX+95kHsCLn4gvN
MJTycCqErEXQMcQFaQt6S+8SdQ0EQqJGpeeMRFGNMGVGNEVzPWejwpTF4iPy
TEnzXKSPHae2amcQbxokDHyfO3+HQe0iQmYQ5WsbRXOQbNvpWmA9A1eiWBBJ
2EaL23T9OPqnL/5C3YL4lBwyMm7GP0VbGLYrjnfxZnx7N8Fi9xs2w6qaYYrx
FoICVWfds7HgfHS3cS6yLnIfM9ifpB/kO7Rg1/m0Ql+VxH9VBdLLNNwcDJ+R
mA47gM+p54EzuQ4RA14uIAW8xB5CnIEo/1bwWmeCWJp7te4DHC4Yp/16hWRm
IbCLOqnoBN6lTC/KdYSoOoX0Og7AKc7hEwsbHVDKTPlRyfA618F6XBohxTlj
bp3XKyv07TXcIG4TLGEqi7SX8p6ahvyeSPuYUSMPJ+pfmyDcVzP/Ozyp8Yhe
4fIciWIE0GbnhUAgWjJeglyRbd5Yh45L13XmT17kYN01Lj5FwBS1iSJqq21t
0TYcrnGo/79n0IZ+OD67PL86v7u/Fd4fzzfY/LjxWNtNv1ZCo6f49DNUaepM
gB3O5mx2ecJRAaN5qRcjq8POSda4El4h5aTdhyAEubp6LT4AHsKWasWqYlIw
QP/E3dywUhJOaSpysV8zInxE9/vJjx03ZpO9kzKNDy7Ubes0cubBosRoAgm/
3oA4XFo4qyvv4gPva0avwts+ZiaVpcsL5DsYBhFzqnKpeNMuk+xPYTEnAntL
78iZuS/jzbkHdJvDBNawjrvdtZ7esEFBoCghXsPJUuZIzKZuqU3dQIRe7BU6
L/cLGDRrP4BMCFsa9MEP+nINxs/AFXxMoKqHG5BD8UrDip1bShBy95jdhfdd
HsYsPL/7UeSnLzho/EWEbXOMZA95eNzoG3QZb0l99V4k5ysMrpm+DQwl2H90
t5GEVG8VRKdMwttaZu4juTvVEX0jD4eJgEsZFFdoJCpi03GCPOvwuULMzp+d
UTlkLWQt4lLq3DyV1tFauTKDeM38TeCQUS5Qd2u50nRYEJMdMWyfuB7KBaOl
a4qKULsVDoPjT7GE8UL1IJfYNO72V/KzSXUunXTgamxlW0yjLWY7DfuCUlMT
AjjbiTWLJmn4806gE0PjPlAv6VGdO4ypLRjFDUfFDsS8uX5j2KMJbQcFFklz
z61raP/EwF50r/KTVCtiXZZvE27dwSVgEwV0GWs09HmaI9qtV0hMYlFAA+aQ
tE7CpuB8FH3XkW1L4CI6prC1nAOdu2ao+4/mB1q99MnCdY4e4l5xx1/1Hb8D
0dnONRcEaD940jSAxsFrD7Q1ZfCw0Ke6kpypSP55+41q41aNSTkwpdZZp9ah
1FcOy9ObWBYHeBnN7uO+KH5raXqGsWS4TqYltRzDI+9L0YouL5NqlrMFImlN
YZ0xCO7ex9hjtB5dxei88ReywSk5XDXBv7MsVC3JBcAkkbZL7Nan8IHpBUqb
E0LzkhXeOyUmiJVt7dIf0mq2yhFf3FYxzpWWJ2NpMyen7rJHTQbRFqiCYYiz
On3XUUQvBL/55JMRqho2Vt4HNeg5SGcqHimXSaqN+SJXA39O/IcHumFeRnmh
1BbKswpvguOTThZp4IFRSLgtXioN713kOorXdpi8L2O97unfd0q9bbAGkPW/
BIVomdP0zOV8EbCEh4tTF3AibXKoL58ZSlGugY9IXyMNoQkkE+JaBQFESkUK
w/g/1PCUA0EfG4s/FnHiLyxTM9RvYVCtfOpr2vRdwH4o515fEfMH2/Enw093
mn1ySSUN62fuiFueZnEAGxG8VRLiMCmArHTJeJGKH16J5Fc3L0y7ys4ABUJx
G0yXSI0YjZgdO8Udc4/ONRHNng7GMqlziTuKOWu3FpZm8GIHPmdfJ3AMdC7F
XrRM2HGhczmGgJlnGoGOPM6Zb664niPwMTeYcIGtqOQo4hI+eoCVz7D7LNal
FzP0u9TrCUOrJxKhN06B9z3B1rgyT1BGYkbsw6XNi10EaRGqF7ZVqSLDYQ45
AHztqVYTlKGhsjpsnrkRjRmAhaZmWEilEP02AKSGS4GzTPjTV9SgBP7BoS5i
HjyZF3nxlv4QmrycXLw+RvC5se4JIKqRD4Sfo/8+ksGEGG+ydfJm8iP8+7KE
hZbrNLkb3oL2X833skAQ8u7FGh13ng+BGd3fhUCL31RgtctEHHQ/AXuJnD8e
7dENwj+XhfhpBUShxVaULVfSlLBU2GhY8fyFiFiGYmqCE8rfDWpitUNFcdkd
RpEe3IkubuYwbqm/ruAnACq6dNb4+YkiChRrcKk5C+97A+uHiK7GXypVGykG
LlAGJxG1+YNJYrSdb/lchqllbOsPEimkrm0jci4fQ39W1ExT8y0+sAsh3KJn
F0IIRd8u3Kq05kosSjwsg2TqB6pMNyPF+6CQhDuKpstw1OoXmS/2owQYhGft
g/YnBdISwdw+4NIe0zXjaEWzg3lZgKE3dXhD6fCBW3U8n6OcsrXObMqNby86
ICShNlzX76lw7cG9cUiDXuBF305gTRdZVt9ReJdv0YuIX0fU5xKxRmCbuJeN
vR8UM1TwiG4VtmSlIpcOKXaVcKwvelSw+dUhdsesoC7WhUYWJfBDQolGRtR6
4XIFIvPvA/a+1kmyVQrfYjdBKsAKo8yH2D5g4OsKUB4SBe8JLKGh/P076qAg
4YY6oEfvyWolC1vX19+cAEeQB6J9xbjwCQEghtSho9/7a2pB9xJMzGZS/0jP
9h5sV2AKFXLia1qvhdiZLneevGHp5yBAThC2VA+XtEZ3NXDT9RL9KquNTamm
ieEpQvwQXHsv9qFvVzx0pGdvPEykb4eItB/cInqlPVsk0ft+XMWk4Ki72ayw
dveBk4iRkdBZa+1yb8RFxbbVaEIHpmt5fABbEf8cvTdNtqxs0edDWArqZ5dz
A1FF5h6ATyA/vM12DCcGzSMnlPsPUgAw70xtM7MGmrdFfbVEIdbEipAGbgfo
awLvUdWUGmtFAt8bBicXuPiBsJwViA2xNtUxAAcnW7RRxxdOL9NV2tAwruSJ
Spv1AaylDYbW6xG3nsaxeVNcdRK37gUsz6QDi29rjf4+Si2rXK30MBu6oGdc
nLx2RTlbpR/Z0Qtq5ZKC1r6ZUgO3OTVo97CBBOvszPidw3zp/YnwQd67hBaU
6KHL5EP9844JiZlyZN40cCVnlCRLst9WUt7pkpIVsd3m8uc7dZokWR5xYfD5
1ffwD4LwZO/kmyB13lWrcYvI3s0oFYGSPlwJOk8OTbmn1HNTPkDz3efcKALz
RAeKXKCu4pgNXC5OEo/BwCSSvOCCmUG9fOKoauAYIwXRgNLdh2G4mAyfYEmR
36nK0z117i1tU2O8TEE0sfPGQsY7xRO0BwzByeM0fLi2ici9Bc2esrTyT+BY
WENsSakxGWYeSpqibBPRVFRp025PuADlqKvt7eNgWs+pUsJH152Y2dj1wISi
IsealncJ3h3N7SmyflktUVWVeoF8/TZSiTSTitUyI6HrXQDNZko6AJZIbYJC
VV0GzGtTAYwJ52Kydp7+reYOy93GQqRdzcjJFjC2KyTY246IggxCOrcI3xKI
tAlp0iDBNId7kkYpFcbuClHMuxeRnzPwhDB7ODHqs30MC7myQlJ02nupugTF
NJi0Mt3HCBmKDtbHVOVLfPv0HCPQW7KMmil9RLfQD8TOwbToCZiDYXHAe3Eg
26CjzvSDCwM8nnYndTpIfO+ojBN4NzIi/s44RompqIoFCCN2rWu6hhuFGf6A
leXhkD0UUeRgTJOrz8fhK/fACIVV90EJu+i4/f5Xd/ozRfTtGEfrJjL6kVzP
QUls/lEtMEEsaUbc550L/iCgvmCSep+JpgmAf/tRkn3sZch1ildTH59hBbTZ
Os03ZLQmyfn4akxVpnyPFwlPOgC7q5zkQjPcJpV0HLDecAj0oSfjGbrv1tl8
qTCtH7IIZonAzLdJ2VIdLMq+WlZlu6WrFGtPn2Gh1PtVSkj42xYUqjdlW68z
1oLg23ye/ED9zTd5Jcovgwmw02RGSNmN1Hidyzd1u0WVbLR3OSLOsUDQNjUl
or/64stvQLBWYKwmdw/n98kbOCApMKHX+f61LeS5x7yiW14KyjRZuoGbL8Nr
tzbLRFHWshKXF9tW4rM8O95+oBz0L/K7Em6yf4d5pyA+B8kE7egWlIBXGKJa
r/NBcgpHDMGvr5Bbi2Ig5HpVgXIwgANTvW3r5Fv4DRH3dYWjjtt5WyTfPaab
pioHyfXuEfsT3ZZUDqRu0Mi8BM5OYaJb/G81r9Fu+Ne0GL4G2QHc/Ra+yKQk
PY45wyLxwAogntNBMi4aeNNvsfRsvikfcRkNXL1wM/+QZqs1PLvCz94l31bw
fnQxnmG7iXVyAxov3ELfpmDoFVh6siGWSNfbFfy12WBgFrQUEIqY5fsWJodL
rEweml9yGOQmBQvhIkVHIOhbdynQ4VtYfdkKruYStIUCQ7u72Sp7HCXJAeZA
FyxYEJxwJIGtJuhXTseEmCYSF6SnkSflGTsMayqBHskl2mEzIHIGVL5oZ8m3
eZW2c6IMbA3QebzZAQVvQOXJt2LVf4sX4f2q3NQE93qdi4Nsz1xNgJ88n9x9
i2oauU07RwoLD2E33pNkgtv9HftuLtuqgtv7uxYIWKVPMNUrCmhdZPkUNx72
tk5BsnAWEzqUUTt8Dc+QWQpLfpUVf0s3cLa+S+ftW1j0cDiktr9H/xe2R2PZ
tCQBAA==

-->

</rfc>