rfc9124xml2.original.xml   rfc9124.xml 
<?xml version="1.0" encoding="UTF-8"?> <?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" [ <!-- [CS] updated by Chris 07/09/21 -->
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?rfc rfcedstyle="yes"?> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.24 -->
<?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"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -ietf-suit-information-model-13" number="9124" obsoletes="" updates="" submissio nType="IETF" category="info" consensus="true" xml:lang="en" tocInclude="true" so rtRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.9.1 -->
<front> <front>
<title abbrev="A Firmware Manifest Information Model">A Manifest Information <title abbrev="A Firmware Manifest Information Model">A Manifest Information
Model for Firmware Updates in IoT Devices</title> Model for Firmware Updates in Internet of Things (IoT) Devices</title>
<seriesInfo name="RFC" value="9124"/>
<author initials="B." surname="Moran" fullname="Brendan Moran"> <author initials="B." surname="Moran" fullname="Brendan Moran">
<organization>Arm Limited</organization> <organization>Arm Limited</organization>
<address> <address>
<email>Brendan.Moran@arm.com</email> <email>Brendan.Moran@arm.com</email>
</address> </address>
</author> </author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig"> <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Arm Limited</organization> <organization>Arm Limited</organization>
<address> <address>
<email>hannes.tschofenig@gmx.net</email> <email>hannes.tschofenig@gmx.net</email>
</address> </address>
</author> </author>
<author initials="H." surname="Birkholz" fullname="Henk Birkholz"> <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
<organization>Fraunhofer SIT</organization> <organization>Fraunhofer SIT</organization>
<address> <address>
<email>henk.birkholz@sit.fraunhofer.de</email> <email>henk.birkholz@sit.fraunhofer.de</email>
</address> </address>
</author> </author>
<date year="2022" month="January"/>
<date year="2021" month="July" day="08"/>
<area>Security</area> <area>Security</area>
<workgroup>SUIT</workgroup> <workgroup>SUIT</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <keyword>computer security</keyword>
<keyword>smart objects</keyword>
<t>Vulnerabilities with Internet of Things (IoT) devices have raised the need fo
r a reliable and secure firmware update mechanism that is also suitable for cons
trained devices. Ensuring that devices function and remain secure over their ser
vice life requires such an update mechanism to fix vulnerabilities, to update co
nfiguration 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 pr
esent in the manifest.</t>
<abstract>
<t>Vulnerabilities with Internet of Things (IoT) devices have raised the n
eed for a reliable and secure firmware update mechanism that is also suitable fo
r constrained devices. Ensuring that devices function and remain secure over the
ir service lifetime requires such an update mechanism to fix vulnerabilities, up
date configuration settings, and add new functionality.</t>
<t>One component of such a firmware update is a concise and machine-proces
sable metadata document, or manifest, that describes the firmware image(s) and o
ffers appropriate protection. This document describes the information that must
be present in the manifest.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<section anchor="introduction" title="Introduction"> <name>Introduction</name>
<t>Vulnerabilities with Internet of Things (IoT) devices have raised the n
<t>Vulnerabilities with Internet of Things (IoT) devices have raised the need fo eed for a reliable and secure firmware update mechanism that is also suitable fo
r a reliable and secure firmware update mechanism that is also suitable for cons r constrained devices. Ensuring that devices function and remain secure over the
trained devices. Ensuring that devices function and remain secure over their ser ir service lifetime requires such an update mechanism to fix vulnerabilities, up
vice life requires such an update mechanism to fix vulnerabilities, to update co date configuration settings, and add new functionality.</t>
nfiguration settings, as well as adding new functionality.</t> <t>One component of such a firmware update is a concise and machine-proces
sable metadata document, or manifest, that describes the firmware image(s) and o
<t>One component of such a firmware update is a concise and machine-processable ffers appropriate protection. This document describes the information that must
meta-data document, or manifest, that describes the firmware image(s) and offers be present in the manifest.</t>
appropriate protection. This document describes the information that must be pr <t>This document describes all the information elements required in a mani
esent in the manifest.</t> fest to secure firmware updates of IoT devices. Each information element is moti
vated by user stories and threats it aims to mitigate. These threats and user st
<t>This document describes all the information elements required in a manifest t ories are not intended to be an exhaustive list of the threats against IoT devic
o secure firmware updates of IoT devices. Each information element is motiviated es and possible user stories that describe how to conduct a firmware update. Ins
by user stories and threats it aims to mitigate. These threats and user stories tead, they are intended to describe the threats against firmware updates in isol
are not intended to be an exhaustive list of the threats against IoT devices, n ation and provide sufficient motivation to specify the information elements that
or of the possible user stories that describe how to conduct a firmware update. cover a wide range of user stories.</t>
Instead they are intended to describe the threats against firmware updates in is <t>To distinguish information elements from their encoding and serializati
olation and provide sufficient motivation to specify the information elements th on over the wire, this document presents an information model. RFC 3444 <xref ta
at cover a wide range of user stories.</t> rget="RFC3444" format="default"/> describes the differences between information
models and data models.</t>
<t>To distinguish information elements from their encoding and serialization ove <t>Because this document covers a wide range of user stories and a wide ra
r the wire this document presents an information model. RFC 3444 <xref target="R nge of threats, not all information elements apply to all scenarios. As a result
FC3444"/> describes the differences between information and data models.</t> , various information elements are optional to implement and optional to use, de
pending on which threats exist in a particular domain of application and which u
<t>Because this document covers a wide range of user stories and a wide range of ser stories are important for deployments.</t>
threats, not all information elements apply to all scenarios. As a result, vari </section>
ous information elements are optional to implement and optional to use, dependin <section anchor="requirements-and-terminology" numbered="true" toc="default"
g on which threats exist in a particular domain of application and which user st >
ories are important for deployments.</t> <name>Requirements and Terminology</name>
<section anchor="requirements-notation" numbered="true" toc="default">
</section> <name>Requirements Notation</name>
<section anchor="requirements-and-terminology" title="Requirements and Terminolo <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
gy"> "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
<section anchor="requirements-notation" title="Requirements Notation"> "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, are to be interpreted as described in BCP&nbsp;14
“MAY”, and “OPTIONAL” in this document are to be interpreted as <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and when, they appear in all capitals, as shown here.</t>
only when, they <t>Unless otherwise stated, these words apply to the design of the manif
appear in all capitals, as shown here.</t> est format, not its implementation or application. Hence, whenever an informatio
n element is declared as "<bcp14>REQUIRED</bcp14>", this implies that the manife
<t>Unless otherwise stated these words apply to the design of the manifest forma st format document has to include support for it.</t>
t, not its implementation or application. Hence, whenever an information is decl </section>
ared as “REQUIRED” this implies that the manifest format document has to include <section anchor="terminology" numbered="true" toc="default">
support for it.</t> <name>Terminology</name>
<t>This document uses terms defined in <xref target="RFC9019" format="de
</section> fault"/>.
<section anchor="terminology" title="Terminology"> The term "Operator" refers to either a device operator or a network operator.</t
>
<t>This document uses terms defined in <xref target="I-D.ietf-suit-architecture" <t>"Secure time" and "secure clock" refer to a set of requirements on ti
/>. me sources. For local time sources, this primarily means that the clock must be
The term ‘Operator’ refers to both Device and Network Operator.</t> monotonically increasing, including across power cycles, firmware updates, etc.
For remote time sources, the provided time must be both authenticated and guaran
<t>Secure time and secure clock refer to a set of requirements on time sources. teed to be correct to within some predetermined bounds, whenever the time source
For local time sources, this primarily means that the clock must be monotonicall is accessible.</t>
y increasing, including across power cycles, firmware updates, etc. For remote t <t>The term "Envelope" (or "Manifest Envelope") is used to describe an e
ime sources, the provided time must be both authenticated and guaranteed to be c ncoding that allows the bundling of a manifest with related information elements
orrect to within some predetermined bounds, whenever the time source is accessib that are not directly contained within the manifest.</t>
le.</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 describe
<t>The term Envelope is used to describe an encoding that allows the bundling of d in <xref target="RFC9019" format="default"/>, because the payload is often in
a manifest with related information elements that are not directly contained wi an intermediate state, such as being encrypted, compressed, and/or encoded as a
thin the manifest.</t> differential update. The payload, taken in isolation, is often not the final fir
mware image.</t>
<t>The term Payload is used to describe the data that is delivered to a device d </section>
uring an update. This is distinct from a “firmware image”, as described in <xref </section>
target="I-D.ietf-suit-architecture"/>, because the payload is often in an inter <section anchor="manifest-information-elements" numbered="true" toc="default
mediate state, such as being encrypted, compressed and/or encoded as a different ">
ial update. The payload, taken in isolation, is often not the final firmware ima <name>Manifest Information Elements</name>
ge.</t> <t>Each manifest information element is anchored in a security requirement
or a usability requirement. The manifest elements are described below, justifie
</section> d by their requirements.</t>
</section> <section anchor="element-version-id" numbered="true" toc="default">
<section anchor="manifest-information-elements" title="Manifest Information Elem <name>Version ID of the Manifest Structure</name>
ents"> <t>This is an identifier that describes which iteration of the manifest
format is contained in the structure. This allows devices to identify the versio
<t>Each manifest information element is anchored in a security requirement or a n of the manifest data model that is in use.</t>
usability requirement. The manifest elements are described below, justified by t <t>This element is <bcp14>REQUIRED</bcp14>.</t>
heir requirements.</t> </section>
<section anchor="element-sequence-number" numbered="true" toc="default">
<section anchor="element-version-id" title="Version ID of the Manifest Structure <name>Monotonic Sequence Number</name>
"> <t>This element provides a monotonically increasing (unsigned) sequence
number to prevent malicious actors from reverting a firmware update against the
<t>An identifier that describes which iteration of the manifest format is contai policies of the relevant authority. This number must not wrap around.</t>
ned in the structure. This allows devices to identify the version of the manifes <t>For convenience, the monotonic sequence number may be a UTC timestamp
t data model that is in use.</t> . This allows global synchronization of sequence numbers without any additional
management.</t>
<t>This element is REQUIRED.</t> <t>This element is <bcp14>REQUIRED</bcp14>.</t>
<dl spacing="normal">
</section> <dt>Implements:</dt><dd><xref target="req-sec-sequence" format="default"
<section anchor="element-sequence-number" title="Monotonic Sequence Number"> >REQ.SEC.SEQUENCE</xref></dd>
</dl>
<t>A monotonically increasing (unsigned) sequence number to prevent malicious ac </section>
tors from reverting a firmware update against the policies of the relevant autho <section anchor="element-vendor-id" numbered="true" toc="default">
rity. This number must not wrap around.</t> <name>Vendor ID</name>
<t>The Vendor ID element helps to distinguish between identically named
<t>For convenience, the monotonic sequence number may be a UTC timestamp. This a products from different vendors. The Vendor ID is not intended to be a human-rea
llows global synchronisation of sequence numbers without any additional manageme dable element. It is intended for binary match/mismatch comparison only.</t>
nt.</t> <t>Recommended practice is to use version 5 Universally Unique Identifie
rs (UUIDs) <xref target="RFC4122" format="default"/> with the vendor's domain na
<t>This element is REQUIRED.</t> me 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 t
<t>Implements: <xref target="req-sec-sequence">REQ.SEC.SEQUENCE</xref></t> o match, unambiguous in length, explicitly non-parsable, and require no issuing
authority. Guaranteed unique integers are preferred because they are small and s
</section> imple to match; however, they may not be fixed length, and they may require an i
<section anchor="element-vendor-id" title="Vendor ID"> ssuing authority to ensure uniqueness. Free-form text is avoided because it is v
ariable length, prone to error, and often requires parsing outside the scope of
<t>The Vendor ID element helps to distinguish between identically named products the manifest serialization.</t>
from different vendors. Vendor ID is not intended to be a human-readable elemen <t>If human-readable content is required, it <bcp14>SHOULD</bcp14> be co
t. It is intended for binary match/mismatch comparison only.</t> ntained in a separate manifest information element: <xref target="manifest-eleme
nt-text" format="default">Manifest Text Information</xref>.</t>
<t>Recommended practice is to use <xref target="RFC4122"/> version 5 UUIDs with <t>This element is <bcp14>RECOMMENDED</bcp14>.</t>
the vendor’s domain name and the DNS name space ID. Other options include type 1 <dl spacing="normal">
and type 4 UUIDs.</t> <dt>Implements:</dt><dd><xref target="req-sec-compatible" format="defaul
t">REQ.SEC.COMPATIBLE</xref>, <xref target="req-sec-authentic-compatibility" for
<t>Fixed-size binary identifiers are preferred because they are simple to match, mat="default">REQ.SEC.AUTH.COMPATIBILITY</xref></dd>
unambiguous in length, explicitly non-parsable, and require no issuing authorit </dl>
y. Guaranteed unique integers are preferred because they are small and simple to <t>Here is an example for a domain-name-based UUID. Vendor A creates a U
match, however they may not be fixed length and they may require an issuing aut UID based on a domain name it controls, such as vendorId = UUID5(DNS, "vendor-a.
hority to ensure uniqueness. Free-form text is avoided because it is variable-le example").</t>
ngth, prone to error, and often requires parsing outside the scope of the manife <t>Because the DNS infrastructure prevents multiple registrations of the
st serialization.</t> same domain name, this UUID is (with very high probability) guaranteed to be un
ique. Because the domain name is known, this UUID is reproducible. Type 1 and ty
<t>If human-readable content is required, it SHOULD be contained in a separate m pe 4 UUIDs produce similar guarantees of uniqueness, but not reproducibility.</t
anifest information element: <xref target="manifest-element-text">Manifest text >
information</xref></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 ano
<t>This element is RECOMMENDED.</t> ther vendor would start using that same domain name. However, this UUID is not p
roof of identity; a device's trust in a vendor must be anchored in a cryptograph
<t>Implements: <xref target="req-sec-compatible">REQ.SEC.COMPATIBLE</xref>, <xre ic key, not a UUID.</t>
f target="req-sec-authentic-compatibility">REQ.SEC.AUTH.COMPATIBILITY</xref>.</t </section>
> <section anchor="element-class-id" numbered="true" toc="default">
<name>Class ID</name>
<t>Here is an example for a domain name-based UUID. Vendor A creates a UUID base <t>A device "Class" is a set of different device types that can accept t
d on a domain name it controls, such as vendorId = UUID5(DNS, “vendor-a.example” he same firmware update without modification. It thereby allows devices to deter
)</t> mine the applicability of the firmware in an unambiguous way. Class IDs must be
unique within the scope of a Vendor ID. This is to prevent similarly or identica
<t>Because the DNS infrastructure prevents multiple registrations of the same do lly named devices from colliding in their customer's infrastructure.</t>
main name, this UUID is (with very high probability) guaranteed to be unique. Be <t>Recommended practice is to use version 5 UUIDs <xref target="RFC4122"
cause the domain name is known, this UUID is reproducible. Type 1 and type 4 UUI format="default"/> with as much information as necessary to define firmware com
Ds produce similar guarantees of uniqueness, but not reproducibility.</t> patibility. Possible information used to derive the Class ID UUID includes:</t>
<ul spacing="normal">
<t>This approach creates a contention when a vendor changes its name or relinqui <li>Model name or number</li>
shes control of a domain name. In this scenario, it is possible that another ven <li>Hardware revision</li>
dor would start using that same domain name. However, this UUID is not proof of <li>Runtime library version</li>
identity; a device’s trust in a vendor must be anchored in a cryptographic key, <li>Bootloader version</li>
not a UUID.</t> <li>ROM revision</li>
<li>Silicon batch number</li>
</section> </ul>
<section anchor="element-class-id" title="Class ID"> <t>The Class ID UUID should use the Vendor ID as the name space identifi
er. Classes may be more fine-grained than is required to identify firmware compa
<t>A device “Class” is a set of different device types that can accept the same tibility. Classes must not be less granular than is required to identify firmwar
firmware update without modification. It thereby allows devices to determine app e compatibility. Devices may have multiple Class IDs.</t>
licability of a firmware in an unambiguous way. Class IDs must be unique within <t>The Class ID is not intended to be a human-readable element. It is in
the scope of a Vendor ID. This is to prevent similarly, or identically named dev tended for binary match/mismatch comparison only. A manifest serialization <bcp1
ices colliding in their customer’s infrastructure.</t> 4>SHOULD NOT</bcp14> permit free-form text content to be used for the Class ID.
A fixed-size binary identifier <bcp14>SHOULD</bcp14> be used.</t>
<t>Recommended practice is to use <xref target="RFC4122"/> version 5 UUIDs with <t>Some organizations desire to keep the same product naming across mult
as much information as necessary to define firmware compatibility. Possible info iple, incompatible hardware revisions for ease of user experience. If this namin
rmation used to derive the class UUID includes:</t> g is propagated into the firmware, then matching a specific hardware version bec
omes a challenge. An opaque, non-readable binary identifier has no naming implic
<t><list style="symbols"> ations and so is more likely to be usable for distinguishing among incompatible
<t>model name or number</t> device groupings, regardless of naming.</t>
<t>hardware revision</t> <t>Fixed-size binary identifiers are preferred because they are simple t
<t>runtime library version</t> o match, unambiguous in length, opaque and free from naming implications, and ex
<t>bootloader version</t> plicitly non-parsable. Free-form text is avoided because it is variable length,
<t>ROM revision</t> prone to error, often requires parsing outside the scope of the manifest seriali
<t>silicon batch number</t> zation, and may be homogenized across incompatible device groupings.</t>
</list></t> <t>If the Class ID is not implemented, then each logical device class mu
st use a unique trust anchor for authorization.</t>
<t>The Class ID UUID should use the Vendor ID as the name space identifier. Clas <t>This element is <bcp14>RECOMMENDED</bcp14>.</t>
ses may be more fine-grained granular than is required to identify firmware comp <dl spacing="normal">
atibility. Classes must not be less granular than is required to identify firmwa <dt>Implements:</dt><dd><xref target="req-sec-compatible" format="defaul
re compatibility. Devices may have multiple Class IDs.</t> t">REQ.SEC.COMPATIBLE</xref>, <xref target="req-sec-authentic-compatibility" for
mat="default">REQ.SEC.AUTH.COMPATIBILITY</xref></dd>
<t>Class ID is not intended to be a human-readable element. It is intended for b </dl>
inary match/mismatch comparison only. A manifest serialization SHOULD NOT permit <section anchor="example-1-different-classes" numbered="true" toc="defau
free-form text content to be used for Class ID. A fixed-size binary identifier lt">
SHOULD be used.</t> <name>Example 1: Different Classes</name>
<t>Vendor A creates Product Z and Product Y. The firmware images of Pr
<t>Some organizations desire to keep the same product naming across multiple, in oducts Z and Y are not interchangeable. Vendor A creates UUIDs as follows:</t>
compatible hardware revisions for ease of user experience. If this naming is pro <ul spacing="normal">
pagated into the firmware, then matching a specific hardware version becomes a c <li>vendorId = UUID5(DNS, "vendor-a.example")</li>
hallenge. An opaque, non-readable binary identifier has no naming implications a <li>ZclassId = UUID5(vendorId, "Product Z")</li>
nd so is more likely to be usable for distinguishing among incompatible device g <li>YclassId = UUID5(vendorId, "Product Y")</li>
roupings, regardless of naming.</t> </ul>
<t>This ensures that Vendor A's Product Z cannot install firmware for
<t>Fixed-size binary identifiers are preferred because they are simple to match, Product Y and Product Y cannot install firmware for Product Z.</t>
unambiguous in length, opaque and free from naming implications, and explicitly </section>
non-parsable. Free-form text is avoided because it is variable-length, prone to <section anchor="example-2-upgrading-class-id" numbered="true" toc="defa
error, often requires parsing outside the scope of the manifest serialization, ult">
and may be homogenized across incompatible device groupings.</t> <name>Example 2: Upgrading Class ID</name>
<t>Vendor A creates Product X. Later, Vendor A adds a new feature to P
<t>If Class ID is not implemented, then each logical device class must use a uni roduct X, creating Product X v2. Product X requires a firmware update to work wi
que trust anchor for authorization.</t> th firmware intended for Product X v2.</t>
<t>Vendor A creates UUIDs as follows:</t>
<t>This element is RECOMMENDED.</t> <ul spacing="normal">
<li>vendorId = UUID5(DNS, "vendor-a.example")</li>
<t>Implements: Security Requirement <xref target="req-sec-compatible">REQ.SEC.CO <li>XclassId = UUID5(vendorId, "Product X")</li>
MPATIBLE</xref>, <xref target="req-sec-authentic-compatibility">REQ.SEC.AUTH.COM <li>Xv2classId = UUID5(vendorId, "Product X v2")</li>
PATIBILITY</xref>.</t> </ul>
<t>When Product X receives the firmware update necessary to be compati
<section anchor="example-1-different-classes" title="Example 1: Different Classe ble with Product X v2, part of the firmware update changes the Class ID to Xv2cl
s"> assId.</t>
</section>
<t>Vendor A creates product Z and product Y. The firmware images of products Z a <section anchor="example-3-shared-functionality" numbered="true" toc="de
nd Y are not interchangeable. Vendor A creates UUIDs as follows:</t> fault">
<name>Example 3: Shared Functionality</name>
<t><list style="symbols"> <t>Vendor A produces two products: Product X and Product Y. These comp
<t>vendorId = UUID5(DNS, “vendor-a.example”)</t> onents share a common core (such as an operating system (OS)) but have different
<t>ZclassId = UUID5(vendorId, “Product Z”)</t> applications. The common core and the applications can be updated independently
<t>YclassId = UUID5(vendorId, “Product Y”)</t> . To enable X and Y to receive the same common core update, they require the sam
</list></t> e Class ID. To ensure that only Product X receives Application X and only Produc
t Y receives Application Y, Product X and Product Y must have different Class ID
<t>This ensures that Vendor A’s Product Z cannot install firmware for Product Y s. The vendor creates Class IDs as follows:</t>
and Product Y cannot install firmware for Product Z.</t> <ul spacing="normal">
<li>vendorId = UUID5(DNS, "vendor-a.example")</li>
</section> <li>XclassId = UUID5(vendorId, "Product X")</li>
<section anchor="example-2-upgrading-class-id" title="Example 2: Upgrading Class <li>YclassId = UUID5(vendorId, "Product Y")</li>
ID"> <li>CommonClassId = UUID5(vendorId, "common core")</li>
</ul>
<t>Vendor A creates product X. Later, Vendor A adds a new feature to product X, <t>Product X matches against both XclassId and CommonClassId. Product
creating product X v2. Product X requires a firmware update to work with firmwar Y matches against both YclassId and CommonClassId.</t>
e intended for product X v2.</t> </section>
<section anchor="example-4-rebranding" numbered="true" toc="default">
<t>Vendor A creates UUIDs as follows:</t> <name>Example 4: Rebranding</name>
<t>Vendor A creates a Product A and its firmware. Vendor B sells the p
<t><list style="symbols"> roduct under its own name as Product B with some customized configuration. The v
<t>vendorId = UUID5(DNS, “vendor-a.example”)</t> endors create the Class IDs as follows:</t>
<t>XclassId = UUID5(vendorId, “Product X”)</t> <ul spacing="normal">
<t>Xv2classId = UUID5(vendorId, “Product X v2”)</t> <li>vendorIdA = UUID5(DNS, "vendor-a.example")</li>
</list></t> <li>classIdA = UUID5(vendorIdA, "Product A-Unlabeled")</li>
<li>vendorIdB = UUID5(DNS, "vendor-b.example")</li>
<t>When product X receives the firmware update necessary to be compatible with p <li>classIdB = UUID5(vendorIdB, "Product B")</li>
roduct X v2, part of the firmware update changes the class ID to Xv2classId.</t> </ul>
<t>The product will match against each of these Class IDs. If Vendor A
</section> and Vendor B provide different components for the device, the implementor may c
<section anchor="example-3-shared-functionality" title="Example 3: Shared Functi hoose to make ID matching scoped to each component. Then, the vendorIdA, classId
onality"> A match the component ID supplied by Vendor A, and the vendorIdB, classIdB match
the component ID supplied by Vendor B.</t>
<t>Vendor A produces two products, product X and product Y. These components sha </section>
re a common core (such as an operating system), but have different applications. </section>
The common core and the applications can be updated independently. To enable X <section anchor="element-precursor-digest" numbered="true" toc="default">
and Y to receive the same common core update, they require the same class ID. To <name>Precursor Image Digest Condition</name>
ensure that only product X receives application X and only product Y receives a <t>This element provides information about the payload that needs to be
pplication Y, product X and product Y must have different class IDs. The vendor present on the device for an update to apply. This may, for example, be the case
creates Class IDs as follows:</t> with differential updates.</t>
<t>This element is <bcp14>OPTIONAL</bcp14>.</t>
<t><list style="symbols"> <dl spacing="normal">
<t>vendorId = UUID5(DNS, “vendor-a.example”)</t> <dt>Implements:</dt><dd><xref target="req-sec-authentic-precursor" forma
<t>XclassId = UUID5(vendorId, “Product X”)</t> t="default">REQ.SEC.AUTH.PRECURSOR</xref></dd>
<t>YclassId = UUID5(vendorId, “Product Y”)</t> </dl>
<t>CommonClassId = UUID5(vendorId, “common core”)</t> </section>
</list></t> <section anchor="element-required-version" numbered="true" toc="default">
<name>Required Image Version List</name>
<t>Product X matches against both XclassId and CommonClassId. Product Y matches <t>Payloads may only be applied to a specific firmware version or multip
against both YclassId and CommonClassId.</t> le firmware versions. For example, a payload containing a differential update ma
y be applied only to a specific firmware version.</t>
</section> <t>When a payload applies to multiple versions of firmware, the required
<section anchor="example-4-white-labelling" title="Example 4: White-labelling"> image version list specifies which firmware versions must be present for the up
date to be applied. This allows the update author to target specific versions of
<t>Vendor A creates a product A and its firmware. Vendor B sells the product und firmware for an update, while excluding those to which it should not or cannot
er its own name as Product B with some customised configuration. The vendors cre be applied.</t>
ate the Class IDs as follows:</t> <t>This element is <bcp14>OPTIONAL</bcp14>.</t>
<dl spacing="normal">
<t><list style="symbols"> <dt>Implements:</dt><dd><xref target="req-use-img-versions" format="defa
<t>vendorIdA = UUID5(DNS, “vendor-a.example”)</t> ult">REQ.USE.IMG.VERSIONS</xref></dd>
<t>classIdA = UUID5(vendorIdA, “Product A-Unlabelled”)</t> </dl>
<t>vendorIdB = UUID5(DNS, “vendor-b.example”)</t> </section>
<t>classIdB = UUID5(vendorIdB, “Product B”)</t> <section anchor="manifest-element-expiration" numbered="true" toc="default
</list></t> ">
<name>Expiration Time</name>
<t>The product will match against each of these class IDs. If Vendor A and Vendo <t>This element tells a device the time at which the manifest expires an
r B provide different components for the device, the implementor may choose to m d should no longer be used. This element should be used where a secure source of
ake ID matching scoped to each component. Then, the vendorIdA, classIdA match th time is provided and firmware is intended to expire predictably. This element m
e component ID supplied by Vendor A, and the vendorIdB, classIdB match the compo ay also be displayed (e.g., via an app) for user confirmation, since users typic
nent ID supplied by Vendor B.</t> ally have a reliable knowledge of the date.</t>
<t>Special consideration is required for end-of-life if firmware will no
</section> t be updated again -- for example, if a business stops issuing updates to a devi
</section> ce. In this case, the last valid firmware should not have an expiration time.</t
<section anchor="element-precursor-digest" title="Precursor Image Digest Conditi >
on"> <t>This element is <bcp14>OPTIONAL</bcp14>.</t>
<dl spacing="normal">
<t>This element provides information about the payload that needs to be present <dt>Implements:</dt><dd><xref target="req-sec-exp" format="default">REQ.
on the device for an update to apply. This may, for example, be the case with di SEC.EXP</xref></dd>
fferential updates.</t> </dl>
</section>
<t>This element is OPTIONAL.</t> <section anchor="manifest-element-format" numbered="true" toc="default">
<name>Payload Format</name>
<t>Implements: <xref target="req-sec-authentic-precursor">REQ.SEC.AUTH.PRECURSOR <t>This element describes the payload format within the signed metadata.
</xref></t> It is used to enable devices to decode payloads correctly.</t>
<t>This element is <bcp14>REQUIRED</bcp14>.</t>
</section> <dl spacing="normal">
<section anchor="element-required-version" title="Required Image Version List"> <dt>Implements:</dt><dd><xref target="req-sec-authentic-image-type" form
at="default">REQ.SEC.AUTH.IMG_TYPE</xref>, <xref target="req-use-img-format" for
<t>Payloads may only be applied to a specific firmware version or firmware versi mat="default">REQ.USE.IMG.FORMAT</xref></dd>
ons. For example, a payload containing a differential update may be applied only </dl>
to a specific firmware version.</t> </section>
<section anchor="manifest-element-processing-steps" numbered="true" toc="d
<t>When a payload applies to multiple versions of a firmware, the required image efault">
version list specifies which firmware versions must be present for the update t <name>Processing Steps</name>
o be applied. This allows the update author to target specific versions of firmw <t>This element provides a representation of the processing steps requir
are for an update, while excluding those to which it should not or cannot be app ed to decode a payload -- in particular, those that are compressed, packed, or e
lied.</t> ncrypted. The representation must describe which algorithms are used and must co
nvey any additional parameters required by those algorithms.</t>
<t>This element is OPTIONAL.</t> <t>A processing step may indicate the expected digest of the payload aft
er the processing is complete.</t>
<t>Implements: <xref target="req-use-img-versions">REQ.USE.IMG.VERSIONS</xref></ <t>This element is <bcp14>RECOMMENDED</bcp14>.</t>
t> <dl spacing="normal">
<dt>Implements:</dt><dd><xref target="req-use-img-nested" format="defaul
</section> t">REQ.USE.IMG.NESTED</xref></dd>
<section anchor="manifest-element-expiration" title="Expiration Time"> </dl>
</section>
<t>This element tells a device the time at which the manifest expires and should <section anchor="maniest-element-storage-location" numbered="true" toc="de
no longer be used. This element should be used where a secure source of time is fault">
provided and firmware is intended to expire predictably. This element may also <name>Storage Location</name>
be displayed (e.g. via an app) for user confirmation since users typically have <t>This element tells the device where to store a payload within a given
a reliable knowledge of the date.</t> component. The device can use this to establish which permissions are necessary
and the physical storage location to use.</t>
<t>Special consideration is required for end-of-life if a firmware will not be u <t>This element is <bcp14>REQUIRED</bcp14>.</t>
pdated again, for example if a business stops issuing updates to a device. In th <dl spacing="normal">
is case the last valid firmware should not have an expiration time.</t> <dt>Implements:</dt><dd><xref target="req-sec-authentic-image-location"
format="default">REQ.SEC.AUTH.IMG_LOC</xref></dd>
<t>This element is OPTIONAL.</t> </dl>
<section anchor="example-1-two-storage-locations" numbered="true" toc="d
<t>Implements: <xref target="req-sec-exp">REQ.SEC.EXP</xref></t> efault">
<name>Example 1: Two Storage Locations</name>
</section> <t>A device supports two components: an OS and an application. These c
<section anchor="manifest-element-format" title="Payload Format"> omponents can be updated independently, expressing dependencies to ensure compat
ibility between the components. The author chooses two storage identifiers:</t>
<t>This element describes the payload format within the signed metadata. It is u <ul spacing="normal">
sed to enable devices to decode payloads correctly.</t> <li>"OS"</li>
<li>"APP"</li>
<t>This element is REQUIRED.</t> </ul>
</section>
<t>Implements: <xref target="req-sec-authentic-image-type">REQ.SEC.AUTH.IMG_TYPE <section anchor="example-2-file-system" numbered="true" toc="default">
</xref>, <xref target="req-use-img-format">REQ.USE.IMG.FORMAT</xref></t> <name>Example 2: Filesystem</name>
<t>A device supports a full-featured filesystem. The author chooses to
</section> use the storage identifier as the path at which to install the payload. The pay
<section anchor="manifest-element-processing-steps" title="Processing Steps"> load may be a tarball, in which case it unpacks the tarball into the specified p
ath.</t>
<t>A representation of the Processing Steps required to decode a payload, in par </section>
ticular those that are compressed, packed, or encrypted. The representation must <section anchor="example-3-flash-memory" numbered="true" toc="default">
describe which algorithms are used and must convey any additional parameters re <name>Example 3: Flash Memory</name>
quired by those algorithms.</t> <t>A device supports flash memory. The author chooses to make the stor
age identifier the offset where the image should be written.</t>
<t>A Processing Step may indicate the expected digest of the payload after the p </section>
rocessing is complete.</t> </section>
<section anchor="manifest-element-component-identifier" numbered="true" to
<t>This element is RECOMMENDED.</t> c="default">
<name>Component Identifier</name>
<t>Implements: <xref target="req-use-img-nested">REQ.USE.IMG.NESTED</xref></t> <t>In a device with more than one storage subsystem, a storage identifie
r is insufficient to identify where and how to store a payload. To resolve this,
</section> a component identifier indicates to which part of the storage subsystem the pay
<section anchor="maniest-element-storage-location" title="Storage Location"> load shall be placed.</t>
<t>A serialization may choose to combine the use of a component identifi
<t>This element tells the device where to store a payload within a given compone er and <xref target="maniest-element-storage-location" format="default">storage
nt. The device can use this to establish which permissions are necessary and the location</xref>.</t>
physical storage location to use.</t> <t>This element is <bcp14>OPTIONAL</bcp14>.</t>
<dl spacing="normal">
<t>This element is REQUIRED.</t> <dt>Implements:</dt><dd><xref target="req-use-mfst-component" format="de
fault">REQ.USE.MFST.COMPONENT</xref></dd>
<t>Implements: <xref target="req-sec-authentic-image-location">REQ.SEC.AUTH.IMG_ </dl>
LOC</xref></t> </section>
<section anchor="manifest-element-payload-indicator" numbered="true" toc="
<section anchor="example-1-two-storage-locations" title="Example 1: Two Storage default">
Locations"> <name>Payload Indicator</name>
<t>This element provides the information required for the device to acqu
<t>A device supports two components: an OS and an application. These components ire the payload. This functionality is only needed when the target device does n
can be updated independently, expressing dependencies to ensure compatibility be ot intrinsically know where to find the payload.</t>
tween the components. The Author chooses two storage identifiers:</t> <t>This can be encoded in several ways:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>One URI</li>
<t>“OS”</t> <li>A list of URIs</li>
<t>“APP”</t> <li>A prioritized list of URIs</li>
</list></t> <li>A list of signed URIs</li>
</ul>
</section> <t>This element is <bcp14>OPTIONAL</bcp14>.</t>
<section anchor="example-2-file-system" title="Example 2: File System"> <dl spacing="normal">
<dt>Implements:</dt><dd><xref target="req-sec-authenticated-remote-paylo
<t>A device supports a full-featured filesystem. The Author chooses to use the s ad" format="default">REQ.SEC.AUTH.REMOTE_LOC</xref></dd>
torage identifier as the path at which to install the payload. The payload may b </dl>
e a tarball, in which case, it unpacks the tarball into the specified path.</t> </section>
<section anchor="manifest-element-payload-digest" numbered="true" toc="def
</section> ault">
<section anchor="example-3-flash-memory" title="Example 3: Flash Memory"> <name>Payload Digests</name>
<t>This element contains one or more digests of one or more payloads. Th
<t>A device supports flash memory. The Author chooses to make the storage identi is allows the target device to ensure authenticity of the payload(s) when combin
fier the offset where the image should be written.</t> ed with the <xref target="manifest-element-signature" format="default">Signature
</xref> element. A manifest format must provide a mechanism to select one payloa
</section> d from a list based on system parameters, such as an execute-in-place (XIP) inst
</section> allation address.</t>
<section anchor="manifest-element-component-identifier" title="Component Identif <t>This element is <bcp14>REQUIRED</bcp14>. Support for more than one di
ier"> gest is <bcp14>OPTIONAL</bcp14>.</t>
<dl spacing="normal">
<t>In a device with more than one storage subsystem, a storage identifier is ins <dt>Implements:</dt><dd><xref target="req-sec-authentic" format="default
ufficient to identify where and how to store a payload. To resolve this, a compo ">REQ.SEC.AUTHENTIC</xref>, <xref target="req-use-img-select" format="default">R
nent identifier indicates to which part of the storage subsystem the payload sha EQ.USE.IMG.SELECT</xref></dd>
ll be placed.</t> </dl>
</section>
<t>A serialization may choose to combine Component Identifier and <xref target=" <section anchor="manifest-element-size" numbered="true" toc="default">
maniest-element-storage-location">Storage Location</xref>.</t> <name>Size</name>
<t>This element provides the size of the payload in bytes, which informs
<t>This element is OPTIONAL.</t> the target device how big of a payload to expect. Without it, devices are expos
ed to some classes of denial-of-service attacks.</t>
<t>Implements: <xref target="req-use-mfst-component">REQ.USE.MFST.COMPONENT</xre <t>This element is <bcp14>REQUIRED</bcp14>.</t>
f></t> <dl spacing="normal">
<dt>Implements:</dt><dd><xref target="req-sec-authentic-execution" forma
</section> t="default">REQ.SEC.AUTH.EXEC</xref></dd>
<section anchor="manifest-element-payload-indicator" title="Payload Indicator"> </dl>
</section>
<t>This element provides the information required for the device to acquire the <section anchor="manifest-element-signature" numbered="true" toc="default"
payload. This functionality is only needed when the target device does not intri >
nsically know where to find the payload.</t> <name>Manifest Envelope Element: Signature</name>
<t>The signature element contains all the information necessary to prote
<t>This can be encoded in several ways:</t> ct the contents of the manifest against modification and to offer authentication
of the signer. Because the signature element authenticates the manifest, it can
<t><list style="symbols"> not be contained within the manifest. Instead, either the manifest is contained
<t>One URI</t> within the signature element or the signature element is a member of the Manifes
<t>A list of URIs</t> t Envelope and bundled with the manifest.</t>
<t>A prioritised list of URIs</t> <t>The signature element represents the foundation of all security prope
<t>A list of signed URIs</t> rties of the manifest. Manifests, which are included as dependencies by other ma
</list></t> nifests, should include a signature so that the recipient can distinguish betwee
n different actors with different permissions.</t>
<t>This element is OPTIONAL.</t> <t>The signature element must support multiple signers and multiple sign
ing algorithms. A manifest format may allow multiple manifests to be covered by
<t>Implements: <xref target="req-sec-authenticated-remote-payload">REQ.SEC.AUTH. a single signature element.</t>
REMOTE_LOC</xref></t> <t>This element is <bcp14>REQUIRED</bcp14> in non-dependency manifests.<
/t>
</section> <dl spacing="normal">
<section anchor="manifest-element-payload-digest" title="Payload Digests"> <dt>Implements:</dt><dd><xref target="req-sec-authentic" format="default
">REQ.SEC.AUTHENTIC</xref>, <xref target="req-sec-rights" format="default">REQ.S
<t>This element contains one or more digests of one or more payloads. This allow EC.RIGHTS</xref>, <xref target="req-use-mfst-multi-auth" format="default">REQ.US
s the target device to ensure authenticity of the payload(s) when combined with E.MFST.MULTI_AUTH</xref></dd>
the <xref target="manifest-element-signature">Signature</xref> element. A manife </dl>
st format must provide a mechanism to select one payload from a list based on sy </section>
stem parameters, such as Execute-In-Place Installation Address.</t> <section anchor="manifest-element-additional-install-info" numbered="true"
toc="default">
<t>This element is REQUIRED. Support for more than one digest is OPTIONAL.</t> <name>Additional Installation Instructions</name>
<t>Additional installation instructions are machine-readable commands th
<t>Implements: <xref target="req-sec-authentic">REQ.SEC.AUTHENTIC</xref>, <xref e device should execute when processing the manifest. This information is distin
target="req-use-img-select">REQ.USE.IMG.SELECT</xref></t> ct from the information necessary to process a payload. Additional installation
instructions include information such as update timing (for example, install onl
</section> y on Sunday, at 0200), procedural considerations (for example, shut down the equ
<section anchor="manifest-element-size" title="Size"> ipment under control before executing the update), and pre- and post-installatio
n steps (for example, run a script). Other installation instructions could inclu
<t>The size of the payload in bytes, which informs the target device how big of de requesting user confirmation before installing.</t>
a payload to expect. Without it, devices are exposed to some classes of denial o <t>This element is <bcp14>OPTIONAL</bcp14>.</t>
f service attack.</t> <dl spacing="normal">
<dt>Implements:</dt><dd><xref target="req-use-mfst-pre-check" format="de
<t>This element is REQUIRED.</t> fault">REQ.USE.MFST.PRE_CHECK</xref></dd>
</dl>
<t>Implements: <xref target="req-sec-authentic-execution">REQ.SEC.AUTH.EXEC</xre </section>
f></t> <section anchor="manifest-element-text" numbered="true" toc="default">
<name>Manifest Text Information</name>
</section> <t>This is textual information pertaining to the update described by the
<section anchor="manifest-element-signature" title="Manifest Envelope Element: S manifest. This information is for human consumption only. It <bcp14>MUST NOT</b
ignature"> cp14> be the basis of any decision made by the recipient.</t>
<t>This element is <bcp14>OPTIONAL</bcp14>.</t>
<t>The Signature element contains all the information necessary to protect the c <dl spacing="normal">
ontents of the manifest against modification and to offer authentication of the <dt>Implements:</dt><dd><xref target="req-use-mfst-text" format="default
signer. Because the Signature element authenticates the manifest, it cannot be c ">REQ.USE.MFST.TEXT</xref></dd>
ontained within the manifest. Instead, the manifest is either contained within t </dl>
he signature element, or the signature element is a member of the Manifest Envel </section>
ope and bundled with the manifest.</t> <section anchor="manifest-element-aliases" numbered="true" toc="default">
<name>Aliases</name>
<t>The Signature element represents the foundation of all security properties of <t>Aliases provide a mechanism for a manifest to augment or replace URIs
the manifest. Manifests, which are included as dependencies by another manifest or URI lists defined by one or more of its dependencies.</t>
s, should include a signature so that the recipient can distinguish between diff <t>This element is <bcp14>OPTIONAL</bcp14>.</t>
erent actors with different permissions.</t> <dl spacing="normal">
<dt>Implements:</dt><dd><xref target="req-use-mfst-override" format="def
<t>The Signature element must support multiple signers and multiple signing algo ault">REQ.USE.MFST.OVERRIDE_REMOTE</xref></dd>
rithms. A manifest format may allow multiple manifests to be covered by a single </dl>
Signature element.</t> </section>
<section anchor="manifest-element-dependencies" numbered="true" toc="defau
<t>This element is REQUIRED in non-dependency manifests.</t> lt">
<name>Dependencies</name>
<t>Implements: <xref target="req-sec-authentic">REQ.SEC.AUTHENTIC</xref>, <xref <t>This is a list of other manifests that are required by the current ma
target="req-sec-rights">REQ.SEC.RIGHTS</xref>, <xref target="req-use-mfst-multi- nifest. Manifests are identified in an unambiguous way, such as a cryptographic
auth">REQ.USE.MFST.MULTI_AUTH</xref></t> digest.</t>
<t>This element is <bcp14>REQUIRED</bcp14> to support deployments that i
</section> nclude both multiple authorities and multiple payloads.</t>
<section anchor="manifest-element-additional-install-info" title="Additional Ins <dl spacing="normal">
tallation Instructions"> <dt>Implements:</dt><dd><xref target="req-use-mfst-component" format="de
fault">REQ.USE.MFST.COMPONENT</xref></dd>
<t>Additional installation instructions are machine-readable commands the device </dl>
should execute when processing the manifest. This information is distinct from </section>
the information necessary to process a payload. Additional installation instruct <section anchor="manifest-element-encryption-wrapper" numbered="true" toc=
ions include information such as update timing (for example, install only on Sun "default">
day, at 0200), procedural considerations (for example, shut down the equipment u <name>Encryption Wrapper</name>
nder control before executing the update), pre- and post-installation steps (for <t>Encrypting firmware images requires symmetric content encryption keys
example, run a script). Other installation instructions could include requestin . The encryption wrapper provides the information needed for a device to obtain
g user confirmation before installing.</t> or locate a key that it uses to decrypt the firmware.</t>
<t>This element is <bcp14>REQUIRED</bcp14> for encrypted payloads.</t>
<t>This element is OPTIONAL.</t> <dl spacing="normal">
<dt>Implements:</dt><dd><xref target="req-sec-image-confidentiality" for
<t>Implements: <xref target="req-use-mfst-pre-check">REQ.USE.MFST.PRE_CHECK</xre mat="default">REQ.SEC.IMG.CONFIDENTIALITY</xref></dd>
f></t> </dl>
</section>
</section> <section anchor="manifest-element-xip-address" numbered="true" toc="defaul
<section anchor="manifest-element-text" title="Manifest text information"> t">
<name>XIP Address</name>
<t>Textual information pertaining to the update described by the manifest. This <t>In order to support XIP systems with multiple possible base addresses
information is for human consumption only. It MUST NOT be the basis of any decis , it is necessary to specify which address the payload is linked for.</t>
ion made by the recipient.</t> <t>For example, a microcontroller may have a simple bootloader that choo
ses one of two images to boot. That microcontroller then needs to choose one of
<t>Implements: <xref target="req-use-mfst-text">REQ.USE.MFST.TEXT</xref></t> two firmware images to install, based on which of its two images is older.</t>
<t>This element is <bcp14>OPTIONAL</bcp14>.</t>
</section> <dl spacing="normal">
<section anchor="manifest-element-aliases" title="Aliases"> <dt>Implements:</dt><dd><xref target="req-use-img-select" format="defaul
t">REQ.USE.IMG.SELECT</xref></dd>
<t>A mechanism for a manifest to augment or replace URIs or URI lists defined by </dl>
one or more of its dependencies.</t> </section>
<section anchor="manifest-element-load-metadata" numbered="true" toc="defa
<t>This element is OPTIONAL.</t> ult">
<name>Load-Time Metadata</name>
<t>Implements: <xref target="req-use-mfst-override">REQ.USE.MFST.OVERRIDE_REMOTE <t>Load-time metadata provides the device with information that it needs
</xref></t> in order to load one or more images. This metadata may include any of the follo
wing:</t>
</section> <ul spacing="normal">
<section anchor="manifest-element-dependencies" title="Dependencies"> <li>The source (e.g., non-volatile storage)</li>
<li>The destination (e.g., an address in RAM)</li>
<t>A list of other manifests that are required by the current manifest. Manifest <li>Cryptographic information</li>
s are identified an unambiguous way, such as a cryptographic digest.</t> <li>Decompression information</li>
<li>Unpacking information</li>
<t>This element is REQUIRED to support deployments that include both multiple au </ul>
thorities and multiple payloads.</t> <t>Typically, loading is done by copying an image from its permanent sto
rage location into its active use location. The metadata allows operations such
<t>Implements: <xref target="req-use-mfst-component">REQ.USE.MFST.COMPONENT</xre as decryption, decompression, and unpacking to be performed during that copy.</t
f></t> >
<t>This element is <bcp14>OPTIONAL</bcp14>.</t>
</section> <dl spacing="normal">
<section anchor="manifest-element-encryption-wrapper" title="Encryption Wrapper" <dt>Implements:</dt><dd><xref target="req-use-load" format="default">REQ
> .USE.LOAD</xref></dd>
</dl>
<t>Encrypting firmware images requires symmetric content encryption keys. The en </section>
cryption wrapper provides the information needed for a device to obtain or locat <section anchor="manifest-element-exec-metadata" numbered="true" toc="defa
e a key that it uses to decrypt the firmware.</t> ult">
<name>Runtime Metadata</name>
<t>This element is REQUIRED for encrypted payloads.</t> <t>Runtime metadata provides the device with any extra information neede
d to boot the device. This may include the entry point of an XIP image or the ke
<t>Implements: <xref target="req-sec-image-confidentiality">REQ.SEC.IMG.CONFIDEN rnel command line to boot a Linux image.</t>
TIALITY</xref></t> <t>This element is <bcp14>OPTIONAL</bcp14>.</t>
<dl spacing="normal">
</section> <dt>Implements:</dt><dd><xref target="req-use-exec" format="default">REQ
<section anchor="manifest-element-xip-address" title="XIP Address"> .USE.EXEC</xref></dd>
</dl>
<t>In order to support execute in place (XIP) systems with multiple possible bas </section>
e addresses, it is necessary to specify which address the payload is linked for. <section anchor="manifest-element-payload" numbered="true" toc="default">
</t> <name>Payload</name>
<t>The Payload element is contained within the manifest or Manifest Enve
<t>For example a microcontroller may have a simple bootloader that chooses one o lope and enables the manifest and payload to be delivered simultaneously. This i
f two images to boot. That microcontroller then needs to choose one of two firmw s used for delivering small payloads, such as cryptographic keys or configuratio
are images to install, based on which of its two images is older.</t> n data.</t>
<t>This element is <bcp14>OPTIONAL</bcp14>.</t>
<t>This element is OPTIONAL.</t> <dl spacing="normal">
<dt>Implements:</dt><dd><xref target="req-use-payload" format="default">
<t>Implements: <xref target="req-use-img-select">REQ.USE.IMG.SELECT</xref></t> REQ.USE.PAYLOAD</xref></dd>
</dl>
</section> </section>
<section anchor="manifest-element-load-metadata" title="Load-time Metadata"> <section anchor="manifest-element-key-claims" numbered="true" toc="default
">
<t>Load-time metadata provides the device with information that it needs in orde <name>Manifest Envelope Element: Delegation Chain</name>
r to load one or more images. This metadata may include any of:</t> <t>The delegation chain offers enhanced authorization functionality via
authorization tokens, such as Concise Binary Object Representation (CBOR) Web To
<t><list style="symbols"> kens <xref target="RFC8392" format="default"/> with Proof-of-Possession Key Sema
<t>the source (e.g. non-volatile storage)</t> ntics <xref target="RFC8747" format="default"/>. Each token itself is protected
<t>the destination (e.g. an address in RAM)</t> and does not require another layer of protection. Each authorization token typic
<t>cryptographic information</t> ally includes a public key or a public key fingerprint; however, this is depende
<t>decompression information</t> nt on the tokens used. Each token <bcp14>MAY</bcp14> include additional metadata
<t>unpacking information</t> , such as key usage information. Because the delegation chain is needed to verif
</list></t> y the signature, it must be placed in the Manifest Envelope, rather than the man
ifest.</t>
<t>Typically, loading is done by copying an image from its permanent storage loc <t>The first token in any delegation chain <bcp14>MUST</bcp14> be authen
ation into its active use location. The metadata allows operations such as decry ticated by the recipient's trust anchor. Each subsequent token <bcp14>MUST</bcp1
ption, decompression, and unpacking to be performed during that copy.</t> 4> be authenticated using the previous token. This allows a recipient to discard
each antecedent token after it has authenticated the subsequent token. The fina
<t>This element is OPTIONAL.</t> l token <bcp14>MUST</bcp14> enable authentication of the manifest. More than one
delegation chain <bcp14>MAY</bcp14> be used if more than one signature is used.
<t>Implements: <xref target="req-use-load">REQ.USE.LOAD</xref></t> Note that no restriction is placed on the encoding order of these tokens; the o
rder of elements is logical only.</t>
</section> <t>This element is <bcp14>OPTIONAL</bcp14>.</t>
<section anchor="manifest-element-exec-metadata" title="Run-time metadata"> <dl spacing="normal">
<dt>Implements:</dt><dd><xref target="req-use-delegation" format="defaul
<t>Run-time metadata provides the device with any extra information needed to bo t">REQ.USE.DELEGATION</xref>, <xref target="req-sec-key-rotation" format="defaul
ot the device. This may include the entry-point of an XIP image or the kernel co t">REQ.SEC.KEY.ROTATION</xref></dd>
mmand-line to boot a Linux image.</t> </dl>
</section>
<t>This element is OPTIONAL.</t> </section>
<section anchor="design-motivation" numbered="true" toc="default">
<t>Implements: <xref target="req-use-exec">REQ.USE.EXEC</xref></t> <name>Security Considerations</name>
<t>The following subsections describe the threat model, user stories, secu
</section> rity requirements, and usability requirements. This section also provides the mo
<section anchor="manifest-element-payload" title="Payload"> tivations for each of the manifest information elements.</t>
<t>Note that it is worthwhile to recall that a firmware update is, by defi
<t>The Payload element is contained within the manifest or manifest envelope and nition, remote code execution. Hence, if a device is configured to trust an enti
enables the manifest and payload to be delivered simultaneously. This is used f ty to provide firmware, it trusts this entity to behave correctly. Many classes
or delivering small payloads, such as cryptographic keys or configuration data.< of attacks can be mitigated by verifying that a firmware update came from a trus
/t> ted party and that no rollback is taking place. However, if the trusted entity h
as been compromised and distributes attacker-provided firmware to devices, then
<t>This element is OPTIONAL.</t> the possibilities for defense are limited.</t>
<section anchor="threat-model" numbered="true" toc="default">
<t>Implements: <xref target="req-use-payload">REQ.USE.PAYLOAD</xref></t> <name>Threat Model</name>
<t>The following subsections aim to provide information about the threat
</section> s that were considered, the security requirements that are derived from those th
<section anchor="manifest-element-key-claims" title="Manifest Envelope Element: reats, and the fields that permit implementation of the security requirements. T
Delegation Chain"> his model uses the Spoofing, Tampering, Repudiation, Information Disclosure, Den
ial of Service, and Elevation of Privilege (STRIDE) approach <xref target="STRID
<t>The delegation chain offers enhanced authorization functionality via authoriz E" format="default"/>. Each threat is classified according to the following:</t>
ation tokens, such as CBOR Web Tokens <xref target="RFC8392"/> with Proof of Pos <ul spacing="normal">
session Key Semantics <xref target="RFC8747"/>. Each token itself is protected a <li>Spoofing identity</li>
nd does not require another layer of protection. Each authorization token typica <li>Tampering with data</li>
lly includes a public key or a public key fingerprint, however this is dependent <li>Repudiation</li>
on the tokens used. Each token MAY include additional metadata, such as key usa <li>Information disclosure</li>
ge information. Because the delegation chain is needed to verify the signature, <li>Denial of service</li>
it must be placed in the Manifest Envelope, rather than the Manifest.</t> <li>Elevation of privilege</li>
</ul>
<t>The first token in any delegation chain MUST be autheticated by the recipient <t>This threat model only covers elements related to the transport of fi
’s Trust Anchor. Each subsequent token MUST be authenticated using the previous rmware updates. It explicitly does not cover threats outside of the transport of
token. This allows a recipient to discard each antecedent token after it has aut firmware updates. For example, threats to an IoT device due to physical access
henticated the subsequent token. The final token MUST enable authentication of t are out of scope.</t>
he manifest. More than one delegation chain MAY be used if more than one signatu </section>
re is used. Note that no restriction is placed on the encoding order of these to <section anchor="threat-descriptions" numbered="true" toc="default">
kens, the order of elements is logical only.</t> <name>Threat Descriptions</name>
<t>Many of the threats detailed in this section contain a "threat escala
<t>This element is OPTIONAL.</t> tion" description. This explains how the described threat might fit together wit
h other threats and produce a high-severity threat. This is important because so
<t>Implements: <xref target="req-use-delegation">REQ.USE.DELEGATION</xref>, <xre me of the described threats may seem low severity but could be used with others
f target="req-sec-key-rotation">REQ.SEC.KEY.ROTATION</xref></t> to construct a high-severity compromise.</t>
<section anchor="threat-expired" numbered="true" toc="default">
</section> <name>THREAT.IMG.EXPIRED: Old Firmware</name>
</section> <dl spacing="normal">
<section anchor="design-motivation" title="Security Considerations"> <dt>Classification:</dt><dd>Elevation of Privilege</dd>
</dl>
<t>The following sub-sections describe the threat model, user stories, security <t>An attacker sends an old, but valid, manifest with an old, but vali
requirements, and usability requirements. This section also provides the motivat d, firmware image to a device. If there is a known vulnerability in the provided
ions for each of the manifest information elements.</t> firmware image, this may allow an attacker to exploit the vulnerability and gai
n control of the device.</t>
<t>Note that it is worthwhile to recall that a firmware update is, by definition <dl spacing="normal">
, remote code execution. Hence, if a device is configured to trust an entity to <dt>Threat Escalation:</dt><dd>If the attacker is able to exploit the
provide firmware, it trusts this entity to do the “right thing”. Many classes of known vulnerability, then this threat can be escalated to all types.</dd>
attacks can be mitigated by verifying that a firmware update came from a truste <dt>Mitigated by:</dt><dd><xref target="req-sec-sequence" format="defa
d party and that no rollback is taking place. However, if the trusted entity has ult">REQ.SEC.SEQUENCE</xref></dd>
been compromised and distributes attacker-provided firmware to devices then the </dl>
possibilities for deference are limited.</t> </section>
<section anchor="threat-expired-offline" numbered="true" toc="default">
<section anchor="threat-model" title="Threat Model"> <name>THREAT.IMG.EXPIRED.OFFLINE: Offline Device + Old Firmware</name>
<dl spacing="normal">
<t>The following sub-sections aim to provide information about the threats that <dt>Classification:</dt><dd>Elevation of Privilege</dd>
were considered, the security requirements that are derived from those threats a </dl>
nd the fields that permit implementation of the security requirements. This mode <t>An attacker targets a device that has been offline for a long time
l uses the S.T.R.I.D.E. <xref target="STRIDE"/> approach. Each threat is classif and runs an old firmware version. The attacker sends an old, but valid, manifest
ied according to:</t> to a device with an old, but valid, firmware image. The attacker-provided firmw
are is newer than the installed firmware but older than the most recently availa
<t><list style="symbols"> ble firmware. If there is a known vulnerability in the provided firmware image,
<t>Spoofing identity</t> then this may allow an attacker to gain control of a device. Because the device
<t>Tampering with data</t> has been offline for a long time, it is unaware of any new updates. As such, it
<t>Repudiation</t> will treat the old manifest as the most current.</t>
<t>Information disclosure</t> <t>The exact mitigation for this threat depends on where the threat co
<t>Denial of service</t> mes from. This requires careful consideration by the implementor. If the threat
<t>Elevation of privilege</t> is from a network actor, including an on-path attacker, or an intruder into a ma
</list></t> nagement system, then a user confirmation can mitigate this attack, simply by di
splaying an expiration date and requesting confirmation. On the other hand, if t
<t>This threat model only covers elements related to the transport of firmware u he user is the attacker, then an online confirmation system (for example, a trus
pdates. It explicitly does not cover threats outside of the transport of firmwar ted timestamp server) can be used as a mitigation system.</t>
e updates. For example, threats to an IoT device due to physical access are out <dl spacing="normal">
of scope.</t> <dt>Threat Escalation:</dt><dd>If the attacker is able to exploit the
known vulnerability, then this threat can be escalated to all types.</dd>
</section> <dt>Mitigated by:</dt><dd><xref target="req-sec-exp" format="default">
<section anchor="threat-descriptions" title="Threat Descriptions"> REQ.SEC.EXP</xref>, <xref target="req-use-mfst-pre-check" format="default">REQ.U
SE.MFST.PRE_CHECK</xref></dd>
<t>Many of the threats detailed in this section contain a “threat escalation” de </dl>
scription. This explains how the described threat might fit together with other </section>
threats and produce a high severity threat. This is important because some of th <section anchor="threat-incompatible" numbered="true" toc="default">
e described threats may seem low severity but could be used with others to const <name>THREAT.IMG.INCOMPATIBLE: Mismatched Firmware</name>
ruct a high severity compromise.</t> <dl spacing="normal">
<dt>Classification:</dt><dd>Denial of Service</dd>
<section anchor="threat-expired" title="THREAT.IMG.EXPIRED: Old Firmware"> </dl>
<t>An attacker sends a valid firmware image, for the wrong type of dev
<t>Classification: Elevation of Privilege</t> ice, signed by an actor with firmware installation permission on both device typ
es. The firmware is verified by the device positively because it is signed by an
<t>An attacker sends an old, but valid manifest with an old, but valid firmware actor with the appropriate permission. This could have wide-ranging consequence
image to a device. If there is a known vulnerability in the provided firmware im s. For devices that are similar, it could cause minor breakage or expose securit
age, this may allow an attacker to exploit the vulnerability and gain control of y vulnerabilities. For devices that are very different, it is likely to render d
the device.</t> evices inoperable.</t>
<dl spacing="normal">
<t>Threat Escalation: If the attacker is able to exploit the known vulnerability <dt>Mitigated by:</dt><dd><xref target="req-sec-compatible" format="de
, then this threat can be escalated to ALL TYPES.</t> fault">REQ.SEC.COMPATIBLE</xref></dd>
</dl>
<t>Mitigated by: <xref target="req-sec-sequence">REQ.SEC.SEQUENCE</xref></t> <t>For example, suppose that two vendors -- Vendor A and Vendor B -- a
dopt the same trade name in different geographic regions, and they both make pro
</section> ducts with the same names, or product name matching is not used. This causes fir
<section anchor="threat-expired-offline" title="THREAT.IMG.EXPIRED.OFFLINE : Off mware from Vendor A to match devices from Vendor B.</t>
line device + Old Firmware"> <t>If the vendors are the firmware authorities, then devices from Vend
or A will reject images signed by Vendor B, since they use different credentials
<t>Classification: Elevation of Privilege</t> . However, if both devices trust the same author, then devices from Vendor A cou
ld install firmware intended for devices from Vendor B.</t>
<t>An attacker targets a device that has been offline for a long time and runs a </section>
n old firmware version. The attacker sends an old, but valid manifest to a devic <section anchor="threat-img-format" numbered="true" toc="default">
e with an old, but valid firmware image. The attacker-provided firmware is newer <name>THREAT.IMG.FORMAT: The Target Device Misinterprets the Type of P
than the installed one but older than the most recently available firmware. If ayload</name>
there is a known vulnerability in the provided firmware image then this may allo <dl spacing="normal">
w an attacker to gain control of a device. Because the device has been offline f <dt>Classification:</dt><dd>Denial of Service</dd>
or a long time, it is unaware of any new updates. As such it will treat the old </dl>
manifest as the most current.</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
<t>The exact mitigation for this threat depends on where the threat comes from. firmware image would likely cause the device to stop functioning.</t>
This requires careful consideration by the implementor. If the threat is from a <dl spacing="normal">
network actor, including an on-path attacker, or an intruder into a management s <dt>Threat Escalation:</dt><dd>An attacker that can cause a device to
ystem, then a user confirmation can mitigate this attack, simply by displaying a misinterpret the received firmware image may gain elevation of privilege and pot
n expiration date and requesting confirmation. On the other hand, if the user is entially expand this to all types of threats.</dd>
the attacker, then an online confirmation system (for example a trusted timesta <dt>Mitigated by:</dt><dd><xref target="req-sec-authentic-image-type"
mp server) can be used as a mitigation system.</t> format="default">REQ.SEC.AUTH.IMG_TYPE</xref></dd>
</dl>
<t>Threat Escalation: If the attacker is able to exploit the known vulnerability </section>
, then this threat can be escalated to ALL TYPES.</t> <section anchor="threat-img-location" numbered="true" toc="default">
<name>THREAT.IMG.LOCATION: The Target Device Installs the Payload to t
<t>Mitigated by: <xref target="req-sec-exp">REQ.SEC.EXP</xref>, <xref target="re he Wrong Location</name>
q-use-mfst-pre-check">REQ.USE.MFST.PRE_CHECK</xref>,</t> <dl spacing="normal">
<dt>Classification:</dt><dd>Denial of Service</dd>
</section> </dl>
<section anchor="threat-incompatible" title="THREAT.IMG.INCOMPATIBLE: Mismatched <t>If a device installs a firmware image to the wrong location on the
Firmware"> device, then it is likely to break. For example, a firmware image installed as a
n application could cause a device and/or application to stop functioning.</t>
<t>Classification: Denial of Service</t> <dl spacing="normal">
<dt>Threat Escalation:</dt><dd>An attacker that can cause a device to
<t>An attacker sends a valid firmware image, for the wrong type of device, signe misinterpret the received code may gain elevation of privilege and potentially e
d by an actor with firmware installation permission on both types of device. The xpand this to all types of threats.</dd>
firmware is verified by the device positively because it is signed by an actor <dt>Mitigated by:</dt><dd><xref target="req-sec-authentic-image-locati
with the appropriate permission. This could have wide-ranging consequences. For on" format="default">REQ.SEC.AUTH.IMG_LOC</xref></dd>
devices that are similar, it could cause minor breakage, or expose security vuln </dl>
erabilities. For devices that are very different, it is likely to render devices </section>
inoperable.</t> <section anchor="threat-net-redirect" numbered="true" toc="default">
<name>THREAT.NET.REDIRECT: Redirection to Inauthentic Payload Hosting<
<t>Mitigated by: <xref target="req-sec-compatible">REQ.SEC.COMPATIBLE</xref></t> /name>
<dl spacing="normal">
<t>For example, suppose that two vendors, Vendor A and Vendor B, adopt the same <dt>Classification:</dt><dd>Denial of Service</dd>
trade name in different geographic regions, and they both make products with the </dl>
same names, or product name matching is not used. This causes firmware from Ven <t>If a device is tricked into fetching a payload for an attacker-cont
dor A to match devices from Vendor B.</t> rolled site, the attacker may send corrupted payloads to devices.</t>
<dl spacing="normal">
<t>If the vendors are the firmware authorities, then devices from Vendor A will <dt>Mitigated by:</dt><dd><xref target="req-sec-authenticated-remote-p
reject images signed by Vendor B since they use different credentials. However, ayload" format="default">REQ.SEC.AUTH.REMOTE_LOC</xref></dd>
if both devices trust the same Author, then, devices from Vendor A could install </dl>
firmware intended for devices from Vendor B.</t> </section>
<section anchor="threat-net-onpath" numbered="true" toc="default">
</section> <name>THREAT.NET.ONPATH: Traffic Interception</name>
<section anchor="threat-img-format" title="THREAT.IMG.FORMAT: The target device <dl spacing="normal">
misinterprets the type of payload"> <dt>Classification:</dt><dd>Spoofing Identity, Tampering with Data</dd
>
<t>Classification: Denial of Service</t> </dl>
<t>An attacker intercepts all traffic to and from a device. The attack
<t>If a device misinterprets the format of the firmware image, it may cause a de er can monitor or modify any data sent to or received from the device. This can
vice to install a firmware image incorrectly. An incorrectly installed firmware take the form of manifests, payloads, status reports, and capability reports bei
image would likely cause the device to stop functioning.</t> ng modified or not delivered to the intended recipient. It can also take the for
m of analysis of data sent to or from the device, in content, size, or frequency
<t>Threat Escalation: An attacker that can cause a device to misinterpret the re .</t>
ceived firmware image may gain elevation of privilege and potentially expand thi <dl spacing="normal">
s to all types of threat.</t> <dt>Mitigated by:</dt><dd><xref target="req-sec-authentic" format="def
ault">REQ.SEC.AUTHENTIC</xref>, <xref target="req-sec-image-confidentiality" for
<t>Mitigated by: <xref target="req-sec-authentic-image-type">REQ.SEC.AUTH.IMG_TY mat="default">REQ.SEC.IMG.CONFIDENTIALITY</xref>, <xref target="req-sec-authenti
PE</xref></t> cated-remote-payload" format="default">REQ.SEC.AUTH.REMOTE_LOC</xref>, <xref tar
get="req-sec-mfst-confidentiality" format="default">REQ.SEC.MFST.CONFIDENTIALITY
</section> </xref>, <xref target="req-sec-reporting" format="default">REQ.SEC.REPORTING</xr
<section anchor="threat-img-location" title="THREAT.IMG.LOCATION: The target dev ef></dd>
ice installs the payload to the wrong location"> </dl>
</section>
<t>Classification: Denial of Service</t> <section anchor="threat-image-replacement" numbered="true" toc="default"
>
<t>If a device installs a firmware image to the wrong location on the device, th <name>THREAT.IMG.REPLACE: Payload Replacement</name>
en it is likely to break. For example, a firmware image installed as an applicat <dl spacing="normal">
ion could cause a device and/or an application to stop functioning.</t> <dt>Classification:</dt><dd>Elevation of Privilege</dd>
</dl>
<t>Threat Escalation: An attacker that can cause a device to misinterpret the re <t>An attacker replaces newly downloaded firmware after a device finis
ceived code may gain elevation of privilege and potentially expand this to all t hes verifying a manifest. This could cause the device to execute the attacker's
ypes of threat.</t> 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
<t>Mitigated by: <xref target="req-sec-authentic-image-location">REQ.SEC.AUTH.IM allows remote execution. This is a typical Time Of Check / Time Of Use (TOCTOU)
G_LOC</xref></t> attack.</t>
<dl spacing="normal">
</section> <dt>Threat Escalation:</dt><dd>If the attacker is able to exploit a kn
<section anchor="threat-net-redirect" title="THREAT.NET.REDIRECT: Redirection to own vulnerability or if the attacker can supply their own firmware, then this th
inauthentic payload hosting"> reat can be escalated to all types.</dd>
<dt>Mitigated by:</dt><dd><xref target="req-sec-authentic-execution" f
<t>Classification: Denial of Service</t> ormat="default">REQ.SEC.AUTH.EXEC</xref></dd>
</dl>
<t>If a device is tricked into fetching a payload for an attacker controlled sit </section>
e, the attacker may send corrupted payloads to devices.</t> <section anchor="threat-img-unauthenticated" numbered="true" toc="defaul
t">
<t>Mitigated by: <xref target="req-sec-authenticated-remote-payload">REQ.SEC.AUT <name>THREAT.IMG.NON_AUTH: Unauthenticated Images</name>
H.REMOTE_LOC</xref></t> <dl spacing="normal">
<dt>Classification:</dt><dd>Elevation of Privilege / all types</dd>
</section> </dl>
<section anchor="threat-net-onpath" title="THREAT.NET.ONPATH: Traffic intercepti <t>If an attacker can install their firmware on a device -- for exampl
on"> e, by manipulating either payload or metadata -- then they have complete control
of the device.</t>
<t>Classification: Spoofing Identity, Tampering with Data</t> <dl spacing="normal">
<dt>Mitigated by:</dt><dd><xref target="req-sec-authentic" format="def
<t>An attacker intercepts all traffic to and from a device. The attacker can mon ault">REQ.SEC.AUTHENTIC</xref></dd>
itor or modify any data sent to or received from the device. This can take the f </dl>
orm of: manifests, payloads, status reports, and capability reports being modifi </section>
ed or not delivered to the intended recipient. It can also take the form of anal <section anchor="threat-upd-wrong-precursor" numbered="true" toc="defaul
ysis of data sent to or from the device, either in content, size, or frequency.< t">
/t> <name>THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor Images</name>
<dl spacing="normal">
<t>Mitigated by: <xref target="req-sec-authentic">REQ.SEC.AUTHENTIC</xref>, <xre <dt>Classification:</dt><dd>Denial of Service / all types</dd>
f target="req-sec-image-confidentiality">REQ.SEC.IMG.CONFIDENTIALITY</xref>, <xr </dl>
ef target="req-sec-authenticated-remote-payload">REQ.SEC.AUTH.REMOTE_LOC</xref>, <t>Modifications of payloads and metadata allow an attacker to introdu
<xref target="req-sec-mfst-confidentiality">REQ.SEC.MFST.CONFIDENTIALITY</xref> ce a number of denial-of-service attacks. Below are some examples.</t>
, <xref target="req-sec-reporting">REQ.SEC.REPORTING</xref></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
</section> example, delta updates) and that precursor image is not available on the target
<section anchor="threat-image-replacement" title="THREAT.IMG.REPLACE: Payload Re device, it could cause the update to break.</t>
placement"> <t>An attacker that can cause a device to install a payload against th
e wrong precursor image could gain elevation of privilege and potentially expand
<t>Classification: Elevation of Privilege</t> this to all types of threats. However, it is unlikely that a valid differential
update applied to an incorrect precursor would result in functional, but vulner
<t>An attacker replaces a newly downloaded firmware after a device finishes veri able, firmware.</t>
fying a manifest. This could cause the device to execute the attacker’s code. Th <dl spacing="normal">
is attack likely requires physical access to the device. However, it is possible <dt>Mitigated by:</dt><dd><xref target="req-sec-authentic-precursor" f
that this attack is carried out in combination with another threat that allows ormat="default">REQ.SEC.AUTH.PRECURSOR</xref></dd>
remote execution. This is a typical Time Of Check/Time Of Use (TICTOC) attack.</ </dl>
t> </section>
<section anchor="threat-upd-unapproved" numbered="true" toc="default">
<t>Threat Escalation: If the attacker is able to exploit a known vulnerability, <name>THREAT.UPD.UNAPPROVED: Unapproved Firmware</name>
or if the attacker can supply their own firmware, then this threat can be escala <dl spacing="normal">
ted to ALL TYPES.</t> <dt>Classification:</dt><dd>Denial of Service, Elevation of Privilege<
/dd>
<t>Mitigated by: <xref target="req-sec-authentic-execution">REQ.SEC.AUTH.EXEC</x </dl>
ref></t> <t>This threat can appear in several ways; however, it is ultimately a
bout ensuring that devices retain the behavior required by their owner or Operat
</section> or. The owner or Operator of a device typically requires that the device maintai
<section anchor="threat-img-unauthenticated" title="THREAT.IMG.NON_AUTH: Unauthe n certain features, functions, capabilities, behaviors, or interoperability cons
nticated Images"> traints (more generally, behavior). If these requirements are broken, then a dev
ice will not fulfill its purpose. Therefore, if any party other than the device'
<t>Classification: Elevation of Privilege / All Types</t> s owner or the owner's contracted device operator has the ability to modify devi
ce behavior without approval, then this constitutes an elevation of privilege.</
<t>If an attacker can install their firmware on a device, for example by manipul t>
ating either payload or metadata, then they have complete control of the device. <t>Similarly, a network operator may require that devices behave in a
</t> particular way in order to maintain the integrity of the network. If device beha
vior on a network can be modified without the approval of the network operator,
<t>Mitigated by: <xref target="req-sec-authentic">REQ.SEC.AUTHENTIC</xref></t> 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 bec
</section> ause of Features A, B, and C, and a firmware update that removes Feature A is is
<section anchor="threat-upd-wrong-precursor" title="THREAT.UPD.WRONG_PRECURSOR: sued by the manufacturer, then the device may not fulfill the owner's requiremen
Unexpected Precursor images"> ts any more. In certain circumstances, this can cause significantly greater thre
ats. Suppose that Feature A is used to implement a safety-critical system, wheth
<t>Classification: Denial of Service / All Types</t> er the manufacturer intended this behavior or not. When unapproved firmware is i
nstalled, the system may become unsafe.</t>
<t>Modifications of payloads and metadata allow an attacker to introduce a numbe <t>In a second example, the owner or Operator of a system of two or mo
r of denial of service attacks. Below are some examples.</t> re interoperating devices needs to approve firmware for their system in order to
ensure interoperability with other devices in the system. If the firmware is no
<t>An attacker sends a valid, current manifest to a device that has an unexpecte t qualified, the system as a whole may not work. Therefore, if a device installs
d precursor image. If a payload format requires a precursor image (for example, firmware without the approval of the device owner or Operator, this is a threat
delta updates) and that precursor image is not available on the target device, i to devices or the system as a whole.</t>
t could cause the update to break.</t> <t>Similarly, the Operator of a network may need to approve firmware f
or devices attached to the network in order to ensure favorable operating condit
<t>An attacker that can cause a device to install a payload against the wrong pr ions within the network. If the firmware is not qualified, it may degrade the pe
ecursor image could gain elevation of privilege and potentially expand this to a rformance of the network. Therefore, if a device installs firmware without the a
ll types of threat. However, it is unlikely that a valid differential update app pproval of the network operator, this is a threat to the network itself.</t>
lied to an incorrect precursor would result in a functional, but vulnerable firm <dl spacing="normal">
ware.</t> <dt>Threat Escalation:</dt><dd>If the network operator expects configu
ration that is present in devices deployed in Network A, but not in devices depl
<t>Mitigated by: <xref target="req-sec-authentic-precursor">REQ.SEC.AUTH.PRECURS oyed in Network B, then the device may experience degraded security, leading to
OR</xref></t> threats of all types.</dd>
<dt>Mitigated by:</dt><dd><xref target="req-sec-rights" format="defaul
</section> t">REQ.SEC.RIGHTS</xref>, <xref target="req-sec-access-control" format="default"
<section anchor="threat-upd-unapproved" title="THREAT.UPD.UNAPPROVED: Unapproved >REQ.SEC.ACCESS_CONTROL</xref></dd>
Firmware"> </dl>
<section anchor="example-1-multiple-network-operators-with-a-single-de
<t>Classification: Denial of Service, Elevation of Privilege</t> vice-operator" numbered="true" toc="default">
<name>Example 1: Multiple Network Operators with a Single Device Ope
<t>This threat can appear in several ways, however it is ultimately about ensuri rator</name>
ng that devices retain the behaviour required by their owner, or operator. The o <t>In this example, assume that device operators expect the rights t
wner or operator of a device typically requires that the device maintain certain o create firmware but that network operators expect the rights to qualify firmwa
features, functions, capabilities, behaviours, or interoperability constraints re as "fit for purpose" on their networks. Additionally, assume that device oper
(more generally, behaviour). If these requirements are broken, then a device wil ators manage devices that can be deployed on any network, including Network A an
l not fulfill its purpose. Therefore, if any party other than the device’s owner d Network B in our example.</t>
or the owner’s contracted Device Operator has the ability to modify device beha <t>An attacker may obtain a manifest for a device on Network A. Then
viour without approval, then this constitutes an elevation of privilege.</t> , this attacker sends that manifest to a device on Network B. Because Network A
and Network B are under the control of different Operators, and the firmware for
<t>Similarly, a Network Operator may require that devices behave in a particular a device on Network A has not been qualified to be deployed on Network B, the t
way in order to maintain the integrity of the network. If devices behaviour on arget device on Network B is now in violation of Operator B's policy and may be
a network can be modified without the approval of the Network Operator, then thi disabled by this unqualified, but signed, firmware.</t>
s constitutes an elevation of privilege with respect to the network.</t> <t>This is a denial of service because it can render devices inopera
ble. This is an elevation of privilege because it allows the attacker to make in
<t>For example, if the owner of a device has purchased that device because of fe stallation decisions that should be made by the Operator.</t>
atures A, B, and C, and a firmware update is issued by the manufacturer, which r </section>
emoves feature A, then the device may not fulfill the owner’s requirements any m <section anchor="example-2-single-network-operator-with-multiple-devic
ore. In certain circumstances, this can cause significantly greater threats. Sup e-operators" numbered="true" toc="default">
pose that feature A is used to implement a safety-critical system, whether the m <name>Example 2: Single Network Operator with Multiple Device Operat
anufacturer intended this behaviour or not. When unapproved firmware is installe ors</name>
d, the system may become unsafe.</t> <t>Multiple devices that interoperate are used on the same network a
nd communicate with each other. Some devices are manufactured and managed by Dev
<t>In a second example, the owner or operator of a system of two or more interop ice Operator A and other devices by Device Operator B. New firmware is released
erating devices needs to approve firmware for their system in order to ensure in by Device Operator A that breaks compatibility with devices from Device Operator
teroperability with other devices in the system. If the firmware is not qualifie B. An attacker sends the new firmware to the devices managed by Device Operator
d, the system as a whole may not work. Therefore, if a device installs firmware A without the approval of the network operator. This breaks the behavior of the
without the approval of the device owner or operator, this is a threat to device larger system, causing denial of service and, possibly, other threats. Where th
s or the system as a whole.</t> e network is a distributed Supervisory Control and Data Acquisition (SCADA) syst
em, this could cause misbehavior of the process that is under control.</t>
<t>Similarly, the operator of a network may need to approve firmware for devices </section>
attached to the network in order to ensure favourable operating conditions with </section>
in the network. If the firmware is not qualified, it may degrade the performance <section anchor="threat-img-disclosure" numbered="true" toc="default">
of the network. Therefore, if a device installs firmware without the approval o <name>THREAT.IMG.DISCLOSURE: Reverse Engineering of Firmware Image for
f the Network Operator, this is a threat to the network itself.</t> Vulnerability Analysis</name>
<dl spacing="normal">
<t>Threat Escalation: If the firmware expects configuration that is present in d <dt>Classification:</dt><dd>all types</dd>
evices deployed in Network A, but not in devices deployed in Network B, then the </dl>
device may experience degraded security, leading to threats of All Types.</t> <t>An attacker wants to mount an attack on an IoT device. To prepare t
he attack, the provided firmware image is reverse engineered and analyzed for vu
<t>Mitigated by: <xref target="req-sec-rights">REQ.SEC.RIGHTS</xref>, <xref targ lnerabilities.</t>
et="req-sec-access-control">REQ.SEC.ACCESS_CONTROL</xref></t> <dl spacing="normal">
<dt>Mitigated by:</dt><dd><xref target="req-sec-image-confidentiality"
<section anchor="example-1-multiple-network-operators-with-a-single-device-opera format="default">REQ.SEC.IMG.CONFIDENTIALITY</xref></dd>
tor" title="Example 1: Multiple Network Operators with a Single Device Operator" </dl>
> </section>
<section anchor="threat-mfst-override" numbered="true" toc="default">
<t>In this example, assume that Device Operators expect the rights to create fir <name>THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements</nam
mware but that Network Operators expect the rights to qualify firmware as fit-fo e>
r-purpose on their networks. Additionally, assume that Device Operators manage d <dl spacing="normal">
evices that can be deployed on any network, including Network A and B in our exa <dt>Classification:</dt><dd>Elevation of Privilege</dd>
mple.</t> </dl>
<t>An authorized actor, but not the author, uses an override mechanism
<t>An attacker may obtain a manifest for a device on Network A. Then, this attac (<xref target="user-story-override" format="default">USER_STORY.OVERRIDE</xref>
ker sends that manifest to a device on Network B. Because Network A and Network ) to change an information element in a manifest signed by the author. For examp
B are under control of different Operators, and the firmware for a device on Net le, if the authorized actor overrides the digest and URI of the payload, the act
work A has not been qualified to be deployed on Network B, the target device on or can replace the entire payload with a payload of their choice.</t>
Network B is now in violation of the Operator B’s policy and may be disabled by <dl spacing="normal">
this unqualified, but signed firmware.</t> <dt>Threat Escalation:</dt><dd>By overriding elements such as payload
installation instructions or a firmware digest, this threat can be escalated to
<t>This is a denial of service because it can render devices inoperable. This is all types.</dd>
an elevation of privilege because it allows the attacker to make installation d <dt>Mitigated by:</dt><dd><xref target="req-sec-access-control" format
ecisions that should be made by the Operator.</t> ="default">REQ.SEC.ACCESS_CONTROL</xref></dd>
</dl>
</section> </section>
<section anchor="example-2-single-network-operator-with-multiple-device-operator <section anchor="threat-mfst-exposure" numbered="true" toc="default">
s" title="Example 2: Single Network Operator with Multiple Device Operators"> <name>THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure</na
me>
<t>Multiple devices that interoperate are used on the same network and communica <dl spacing="normal">
te with each other. Some devices are manufactured and managed by Device Operator <dt>Classification:</dt><dd>Information Disclosure</dd>
A and other devices by Device Operator B. A new firmware is released by Device </dl>
Operator A that breaks compatibility with devices from Device Operator B. An att <t>A third party may be able to extract sensitive information from the
acker sends the new firmware to the devices managed by Device Operator A without manifest.</t>
approval of the Network Operator. This breaks the behaviour of the larger syste <dl spacing="normal">
m causing denial of service and possibly other threats. Where the network is a d <dt>Mitigated by:</dt><dd><xref target="req-sec-mfst-confidentiality"
istributed SCADA system, this could cause misbehaviour of the process that is un format="default">REQ.SEC.MFST.CONFIDENTIALITY</xref></dd>
der control.</t> </dl>
</section>
</section> <section anchor="threat-img-extra" numbered="true" toc="default">
</section> <name>THREAT.IMG.EXTRA: Extra Data after Image</name>
<section anchor="threat-img-disclosure" title="THREAT.IMG.DISCLOSURE: Reverse En <dl spacing="normal">
gineering Of Firmware Image for Vulnerability Analysis"> <dt>Classification:</dt><dd>all types</dd>
</dl>
<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
<t>An attacker wants to mount an attack on an IoT device. To prepare the attack order to make better use of an existing vulnerability.</t>
he or she retrieves the provided firmware image and performs reverse engineering <dl spacing="normal">
of the firmware image to analyze it for specific vulnerabilities.</t> <dt>Mitigated by:</dt><dd><xref target="req-sec-img-complete-digest" f
ormat="default">REQ.SEC.IMG.COMPLETE_DIGEST</xref></dd>
<t>Mitigated by: <xref target="req-sec-image-confidentiality">REQ.SEC.IMG.CONFID </dl>
ENTIALITY</xref></t> </section>
<section anchor="threat-key-exposure" numbered="true" toc="default">
</section> <name>THREAT.KEY.EXPOSURE: Exposure of Signing Keys</name>
<section anchor="threat-mfst-override" title="THREAT.MFST.OVERRIDE: Overriding C <dl spacing="normal">
ritical Manifest Elements"> <dt>Classification:</dt><dd>all types</dd>
</dl>
<t>Classification: Elevation of Privilege</t> <t>If a third party obtains a key or even indirect access to a key --
for example, in a hardware security module (HSM) -- then they can perform the sa
<t>An authorized actor, but not the Author, uses an override mechanism (<xref ta me actions as the legitimate owner of the key. If the key is trusted for firmwar
rget="user-story-override">USER_STORY.OVERRIDE</xref>) to change an information e updates, then the third party can perform firmware updates as though they were
element in a manifest signed by the Author. For example, if the authorized actor the legitimate owner of the key.</t>
overrides the digest and URI of the payload, the actor can replace the entire p <t>For example, if manifest signing is performed on a server connected
ayload with a payload of their choice.</t> 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 acc
<t>Threat Escalation: By overriding elements such as payload installation instru essed by the server.</t>
ctions or firmware digest, this threat can be escalated to all types.</t> <dl spacing="normal">
<dt>Mitigated by:</dt><dd><xref target="req-sec-key-protection" format
<t>Mitigated by: <xref target="req-sec-access-control">REQ.SEC.ACCESS_CONTROL</x ="default">REQ.SEC.KEY.PROTECTION</xref>, <xref target="req-sec-key-rotation" fo
ref></t> rmat="default">REQ.SEC.KEY.ROTATION</xref></dd>
</dl>
</section> </section>
<section anchor="threat-mfst-exposure" title="THREAT.MFST.EXPOSURE: Confidential <section anchor="threat-mfst-modification" numbered="true" toc="default"
Manifest Element Exposure"> >
<name>THREAT.MFST.MODIFICATION: Modification of Manifest or Payload pr
<t>Classification: Information Disclosure</t> ior to Signing</name>
<dl spacing="normal">
<t>A third party may be able to extract sensitive information from the manifest. <dt>Classification:</dt><dd>all types</dd>
</t> </dl>
<t>If an attacker can alter a manifest or payload before it is signed,
<t>Mitigated by: <xref target="req-sec-mfst-confidentiality">REQ.SEC.MFST.CONFID they can perform all the same actions as the manifest author. This allows the a
ENTIALITY</xref></t> ttacker 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 manif
</section> est is created, they can insert their own code. If an attacker can modify the ma
<section anchor="threat-img-extra" title="THREAT.IMG.EXTRA: Extra data after ima nifest before it is signed, they can redirect the manifest to their own payload.
ge"> </t>
<t>For example, the attacker deploys malware to the developer's comput
<t>Classification: All Types</t> er or signing service that watches manifest creation activities and inserts code
into any binary that is referenced by a manifest.</t>
<t>If a third party modifies the image so that it contains extra code after a va <t>For example, the attacker deploys malware to the developer's comput
lid, authentic image, that third party can then use their own code in order to m er or signing service that replaces the referenced binary (digest) and URI with
ake better use of an existing vulnerability.</t> the attacker's binary (digest) and URI.</t>
<dl spacing="normal">
<t>Mitigated by: <xref target="req-sec-img-complete-digest">REQ.SEC.IMG.COMPLETE <dt>Mitigated by:</dt><dd><xref target="req-sec-mfst-check" format="de
_DIGEST</xref></t> fault">REQ.SEC.MFST.CHECK</xref>, <xref target="req-sec-mfst-trusted" format="de
fault">REQ.SEC.MFST.TRUSTED</xref></dd>
</section> </dl>
<section anchor="threat-key-exposure" title="THREAT.KEY.EXPOSURE: Exposure of si </section>
gning keys"> <section anchor="threat-mfst-toctou" numbered="true" toc="default">
<name>THREAT.MFST.TOCTOU: Modification of Manifest between Authenticat
<t>Classification: All Types</t> ion and Use</name>
<dl spacing="normal">
<t>If a third party obtains a key or even indirect access to a key, for example <dt>Classification:</dt><dd>all types</dd>
in an hardware security module (HSM), then they can perform the same actions as </dl>
the legitimate owner of the key. If the key is trusted for firmware update, then <t>If an attacker can modify a manifest after it is authenticated (tim
the third party can perform firmware updates as though they were the legitimate e of check) but before it is used (time of use), then the attacker can place any
owner of the key.</t> content whatsoever in the manifest.</t>
<dl spacing="normal">
<t>For example, if manifest signing is performed on a server connected to the in <dt>Mitigated by:</dt><dd><xref target="req-sec-mfst-const" format="de
ternet, an attacker may compromise the server and then be able to sign manifests fault">REQ.SEC.MFST.CONST</xref></dd>
, even if the keys for manifest signing are held in an HSM that is accessed by t </dl>
he server.</t> </section>
</section>
<t>Mitigated by: <xref target="req-sec-key-protection">REQ.SEC.KEY.PROTECTION</x <section anchor="security-requirements" numbered="true" toc="default">
ref>, <xref target="req-sec-key-rotation">REQ.SEC.KEY.ROTATION</xref></t> <name>Security Requirements</name>
<t>The security requirements here are a set of policies that mitigate th
</section> e threats described in <xref target="threat-model" format="default"/>.</t>
<section anchor="threat-mfst-modification" title="THREAT.MFST.MODIFICATION: Modi <section anchor="req-sec-sequence" numbered="true" toc="default">
fication of manifest or payload prior to signing"> <name>REQ.SEC.SEQUENCE: Monotonic Sequence Numbers</name>
<t>Only an actor with firmware installation authority is permitted to
<t>Classification: All Types</t> decide when device firmware can be installed. To enforce this rule, manifests <b
cp14>MUST</bcp14> contain monotonically increasing sequence numbers. Manifests m
<t>If an attacker can alter a manifest or payload before it is signed, they can ay use UTC epoch timestamps to coordinate monotonically increasing sequence numb
perform all the same actions as the manifest author. This allows the attacker to ers across many actors in many locations. If UTC epoch timestamps are used, they
deploy firmware updates to any devices that trust the manifest author. If an at must not be treated as times; they must be treated only as sequence numbers. De
tacker can modify the code of a payload before the corresponding manifest is cre vices must reject manifests with sequence numbers smaller than any onboard seque
ated, they can insert their own code. If an attacker can modify the manifest bef nce number, i.e., there is no sequence number rollover.</t>
ore it is signed, they can redirect the manifest to their own payload.</t> <aside><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 manife
<t>For example, the attacker deploys malware to the developer’s computer or sign st for the old firmware version with a later sequence number.</t></aside>
ing service that watches manifest creation activities and inserts code into any <dl spacing="normal">
binary that is referenced by a manifest.</t> <dt>Mitigates:</dt><dd><xref target="threat-expired" format="default">
THREAT.IMG.EXPIRED</xref></dd>
<t>For example, the attacker deploys malware to the developer’s computer or sign <dt>Implemented by:</dt><dd><xref target="element-sequence-number" for
ing service that replaces the referenced binary (digest) and URI with the attack mat="default">Monotonic Sequence Number</xref></dd>
er’s binary (digest) and URI.</t> </dl>
</section>
<t>Mitigated by: <xref target="req-sec-mfst-check">REQ.SEC.MFST.CHECK</xref>, <x <section anchor="req-sec-compatible" numbered="true" toc="default">
ref target="req-sec-mfst-trusted">REQ.SEC.MFST.TRUSTED</xref></t> <name>REQ.SEC.COMPATIBLE: Vendor, Device-Type Identifiers</name>
<t>Devices <bcp14>MUST</bcp14> only apply firmware that is intended fo
</section> r them. Devices must know that a given update applies to their vendor, model, ha
<section anchor="threat-mfst-toctou" title="THREAT.MFST.TOCTOU: Modification of rdware revision, and software revision. Human-readable identifiers are often pro
manifest between authentication and use"> ne to error in this regard, so unique identifiers should be used instead.</t>
<dl spacing="normal">
<t>Classification: All Types</t> <dt>Mitigates:</dt><dd><xref target="threat-incompatible" format="defa
ult">THREAT.IMG.INCOMPATIBLE</xref></dd>
<t>If an attacker can modify a manifest after it is authenticated (Time Of Check <dt>Implemented by:</dt><dd><xref target="element-vendor-id" format="d
) but before it is used (Time Of Use), then the attacker can place any content w efault">Vendor ID Condition</xref>, <xref target="element-class-id" format="defa
hatsoever in the manifest.</t> ult">Class ID Condition</xref></dd>
</dl>
<t>Mitigated by: <xref target="req-sec-mfst-const">REQ.SEC.MFST.CONST</xref></t> </section>
<section anchor="req-sec-exp" numbered="true" toc="default">
</section> <name>REQ.SEC.EXP: Expiration Time</name>
</section> <t>A firmware manifest <bcp14>MAY</bcp14> expire after a given time, a
<section anchor="security-requirements" title="Security Requirements"> nd devices may have a secure clock (local or remote). If a secure clock is provi
ded and the firmware manifest has an expiration timestamp, the device must rejec
<t>The security requirements here are a set of policies that mitigate the threat t the manifest if the current time is later than the expiration time.</t>
s described in <xref target="threat-model"/>.</t> <t>Special consideration is required for end-of-life in cases where a
device will not be updated again -- for example, if a business stops issuing upd
<section anchor="req-sec-sequence" title="REQ.SEC.SEQUENCE: Monotonic Sequence N ates for a device. The last valid firmware should not have an expiration time.</
umbers"> t>
<t>If a device has a flawed time source (either local or remote), an o
<t>Only an actor with firmware installation authority is permitted to decide whe ld update can be deployed as new.</t>
n device firmware can be installed. To enforce this rule, manifests MUST contain <dl spacing="normal">
monotonically increasing sequence numbers. Manifests may use UTC epoch timestam <dt>Mitigates:</dt><dd><xref target="threat-expired-offline" format="d
ps to coordinate monotonically increasing sequence numbers across many actors in efault">THREAT.IMG.EXPIRED.OFFLINE</xref></dd>
many locations. If UTC epoch timestamps are used, they must not be treated as t <dt>Implemented by:</dt><dd><xref target="manifest-element-expiration"
imes, they must be treated only as sequence numbers. Devices must reject manifes format="default">Expiration Time</xref></dd>
ts with sequence numbers smaller than any onboard sequence number, i.e. there is </dl>
no sequence number roll over.</t> </section>
<section anchor="req-sec-authentic" numbered="true" toc="default">
<t>Note: This is not a firmware version field. It is a manifest sequence number. <name>REQ.SEC.AUTHENTIC: Cryptographic Authenticity</name>
A firmware version may be rolled back by creating a new manifest for the old fi <t>The authenticity of an update <bcp14>MUST</bcp14> be demonstrable.
rmware version with a later sequence number.</t> Typically, this means that updates must be digitally signed. Because the manifes
t contains information about how to install the update, the manifest's authentic
<t>Mitigates: <xref target="threat-expired">THREAT.IMG.EXPIRED</xref></t> ity must also be demonstrable. To reduce the overhead required for validation, t
he manifest contains the cryptographic digest of the firmware image, rather than
<t>Implemented by: <xref target="element-sequence-number">Monotonic Sequence Num a second digital signature. The authenticity of the manifest can be verified wi
ber</xref></t> th a digital signature or Message Authentication Code. The authenticity of the f
irmware image is tied to the manifest by the use of a cryptographic digest of th
</section> e firmware image.</t>
<section anchor="req-sec-compatible" title="REQ.SEC.COMPATIBLE: Vendor, Device-t <dl spacing="normal">
ype Identifiers"> <dt>Mitigates:</dt><dd><xref target="threat-img-unauthenticated" forma
t="default">THREAT.IMG.NON_AUTH</xref>, <xref target="threat-net-onpath" format=
<t>Devices MUST only apply firmware that is intended for them. Devices must know "default">THREAT.NET.ONPATH</xref></dd>
that a given update applies to their vendor, model, hardware revision, and soft <dt>Implemented by:</dt><dd><xref target="manifest-element-signature"
ware revision. Human-readable identifiers are often error-prone in this regard, format="default">Signature</xref>, <xref target="manifest-element-payload-digest
so unique identifiers should be used instead.</t> " format="default">Payload Digests</xref></dd>
</dl>
<t>Mitigates: <xref target="threat-incompatible">THREAT.IMG.INCOMPATIBLE</xref>< </section>
/t> <section anchor="req-sec-authentic-image-type" numbered="true" toc="defa
ult">
<t>Implemented by: <xref target="element-vendor-id">Vendor ID Condition</xref>, <name>REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type</name>
<xref target="element-class-id">Class ID Condition</xref></t> <t>The type of payload <bcp14>MUST</bcp14> be authenticated. For examp
le, the target must know whether the payload is XIP firmware, a loadable module,
</section> or configuration data.</t>
<section anchor="req-sec-exp" title="REQ.SEC.EXP: Expiration Time"> <dl spacing="normal">
<dt>Mitigates:</dt><dd><xref target="threat-img-format" format="defaul
<t>A firmware manifest MAY expire after a given time and devices may have a secu t">THREAT.IMG.FORMAT</xref></dd>
re clock (local or remote). If a secure clock is provided and the Firmware manif <dt>Implemented by:</dt><dd><xref target="manifest-element-format" for
est has an expiration timestamp, the device must reject the manifest if current mat="default">Payload Format</xref>, <xref target="manifest-element-signature" f
time is later than the expiration time.</t> ormat="default">Signature</xref></dd>
</dl>
<t>Special consideration is required for end-of-life in case device will not be </section>
updated again, for example if a business stops issuing updates for a device. The <section anchor="req-sec-authentic-image-location" numbered="true" toc="
last valid firmware should not have an expiration time.</t> default">
<name>REQ.SEC.AUTH.IMG_LOC: Authenticated Storage Location</name>
<t>If a device has a flawed time source (either local or remote), an old update <t>The location on the target where the payload is to be stored <bcp14
can be deployed as new.</t> >MUST</bcp14> be authenticated.</t>
<dl spacing="normal">
<t>Mitigates: <xref target="threat-expired-offline">THREAT.IMG.EXPIRED.OFFLINE</ <dt>Mitigates:</dt><dd><xref target="threat-img-location" format="defa
xref></t> ult">THREAT.IMG.LOCATION</xref></dd>
<dt>Implemented by:</dt><dd><xref target="maniest-element-storage-loca
<t>Implemented by: <xref target="manifest-element-expiration">Expiration Time</x tion" format="default">Storage Location</xref></dd>
ref></t> </dl>
</section>
</section> <section anchor="req-sec-authenticated-remote-payload" numbered="true" t
<section anchor="req-sec-authentic" title="REQ.SEC.AUTHENTIC: Cryptographic Auth oc="default">
enticity"> <name>REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Payload</name>
<t>The location where a target should find a payload <bcp14>MUST</bcp1
<t>The authenticity of an update MUST be demonstrable. Typically, this means tha 4> be authenticated. Remote resources need to receive an equal amount of cryptog
t updates must be digitally signed. Because the manifest contains information ab raphic protection as the manifest itself, when dereferencing URIs. The security
out how to install the update, the manifest’s authenticity must also be demonstr considerations of Uniform Resource Identifiers (URIs) are applicable <xref targe
able. To reduce the overhead required for validation, the manifest contains the t="RFC3986" format="default"/>.</t>
cryptographic digest of the firmware image, rather than a second digital signatu <dl spacing="normal">
re. The authenticity of the manifest can be verified with a digital signature or <dt>Mitigates:</dt><dd><xref target="threat-net-redirect" format="defa
Message Authentication Code. The authenticity of the firmware image is tied to ult">THREAT.NET.REDIRECT</xref>, <xref target="threat-net-onpath" format="defaul
the manifest by the use of a cryptographic digest of the firmware image.</t> t">THREAT.NET.ONPATH</xref></dd>
<dt>Implemented by:</dt><dd><xref target="manifest-element-payload-ind
<t>Mitigates: <xref target="threat-img-unauthenticated">THREAT.IMG.NON_AUTH</xre icator" format="default">Payload Indicator</xref></dd>
f>, <xref target="threat-net-onpath">THREAT.NET.ONPATH</xref></t> </dl>
</section>
<t>Implemented by: <xref target="manifest-element-signature">Signature</xref>, < <section anchor="req-sec-authentic-execution" numbered="true" toc="defau
xref target="manifest-element-payload-digest">Payload Digest</xref></t> lt">
<name>REQ.SEC.AUTH.EXEC: Secure Execution</name>
</section> <t>The target <bcp14>SHOULD</bcp14> verify firmware at the time of boo
<section anchor="req-sec-authentic-image-type" title="REQ.SEC.AUTH.IMG_TYPE: Aut t. This requires authenticated payload size and firmware digest.</t>
henticated Payload Type"> <dl spacing="normal">
<dt>Mitigates:</dt><dd><xref target="threat-image-replacement" format=
<t>The type of payload MUST be authenticated. For example, the target must know "default">THREAT.IMG.REPLACE</xref></dd>
whether the payload is XIP firmware, a loadable module, or configuration data.</ <dt>Implemented by:</dt><dd><xref target="manifest-element-payload-dig
t> est" format="default">Payload Digests</xref>, <xref target="manifest-element-siz
e" format="default">Size</xref></dd>
<t>Mitigates: <xref target="threat-img-format">THREAT.IMG.FORMAT</xref></t> </dl>
</section>
<t>Implemented by: <xref target="manifest-element-format">Payload Format</xref>, <section anchor="req-sec-authentic-precursor" numbered="true" toc="defau
<xref target="manifest-element-signature">Signature</xref></t> lt">
<name>REQ.SEC.AUTH.PRECURSOR: Authenticated Precursor Images</name>
</section> <t>If an update uses a differential compression method, it <bcp14>MUST
<section anchor="req-sec-authentic-image-location" title="Security Requirement R </bcp14> specify the digest of the precursor image, and that digest <bcp14>MUST<
EQ.SEC.AUTH.IMG_LOC: Authenticated Storage Location"> /bcp14> be authenticated.</t>
<dl spacing="normal">
<t>The location on the target where the payload is to be stored MUST be authenti <dt>Mitigates:</dt><dd><xref target="threat-upd-wrong-precursor" forma
cated.</t> t="default">THREAT.UPD.WRONG_PRECURSOR</xref></dd>
<dt>Implemented by:</dt><dd><xref target="element-precursor-digest" fo
<t>Mitigates: <xref target="threat-img-location">THREAT.IMG.LOCATION</xref></t> rmat="default">Precursor Image Digest</xref></dd>
</dl>
<t>Implemented by: <xref target="maniest-element-storage-location">Storage Locat </section>
ion</xref></t> <section anchor="req-sec-authentic-compatibility" numbered="true" toc="d
efault">
</section> <name>REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and Class IDs</
<section anchor="req-sec-authenticated-remote-payload" title="REQ.SEC.AUTH.REMOT name>
E_LOC: Authenticated Remote Payload"> <t>The identifiers that specify firmware compatibility <bcp14>MUST</bc
p14> be authenticated to ensure that only compatible firmware is installed on a
<t>The location where a target should find a payload MUST be authenticated. Remo target device.</t>
te resources need to receive an equal amount of cryptographic protection as the <dl spacing="normal">
manifest itself, when dereferencing URIs. The security considerations of Uniform <dt>Mitigates:</dt><dd><xref target="threat-incompatible" format="defa
Resource Identifiers (URIs) are applicable <xref target="RFC3986"/>.</t> ult">THREAT.IMG.INCOMPATIBLE</xref></dd>
<dt>Implemented by:</dt><dd><xref target="element-vendor-id" format="d
<t>Mitigates: <xref target="threat-net-redirect">THREAT.NET.REDIRECT</xref>, <xr efault">Vendor ID Condition</xref>, <xref target="element-class-id" format="defa
ef target="threat-net-onpath">THREAT.NET.ONPATH</xref></t> ult">Class ID Condition</xref></dd>
</dl>
<t>Implemented by: <xref target="manifest-element-payload-indicator">Payload Ind </section>
icator</xref></t> <section anchor="req-sec-rights" numbered="true" toc="default">
<name>REQ.SEC.RIGHTS: Rights Require Authenticity</name>
</section> <t>If a device grants different rights to different actors, exercising
<section anchor="req-sec-authentic-execution" title="REQ.SEC.AUTH.EXEC: Secure E those rights <bcp14>MUST</bcp14> be accompanied by proof of those rights, in th
xecution"> e form of proof of authenticity. Authenticity mechanisms, such as those required
in <xref target="req-sec-authentic" format="default">REQ.SEC.AUTHENTIC</xref>,
<t>The target SHOULD verify firmware at time of boot. This requires authenticate can be used to prove authenticity.</t>
d payload size, and digest.</t> <t>For example, if a device has a policy that requires that firmware h
ave both an Authorship right and a Qualification right and if that device grants
<t>Mitigates: <xref target="threat-image-replacement">THREAT.IMG.REPLACE</xref>< Authorship and Qualification rights to different parties, such as a device oper
/t> ator 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>Implemented by: <xref target="manifest-element-payload-digest">Payload Digest </t>
</xref>, <xref target="manifest-element-size">Size</xref></t> <dl spacing="normal">
<dt>Mitigates:</dt><dd><xref target="threat-upd-unapproved" format="de
</section> fault">THREAT.UPD.UNAPPROVED</xref></dd>
<section anchor="req-sec-authentic-precursor" title="REQ.SEC.AUTH.PRECURSOR: Aut <dt>Implemented by:</dt><dd><xref target="manifest-element-signature"
henticated precursor images"> format="default">Signature</xref></dd>
</dl>
<t>If an update uses a differential compression method, it MUST specify the dige </section>
st of the precursor image and that digest MUST be authenticated.</t> <section anchor="req-sec-image-confidentiality" numbered="true" toc="def
ault">
<t>Mitigates: <xref target="threat-upd-wrong-precursor">THREAT.UPD.WRONG_PRECURS <name>REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption</name>
OR</xref></t> <t>The manifest information model <bcp14>MUST</bcp14> enable encrypted
payloads. Encryption helps to prevent third parties, including attackers, from
<t>Implemented by: <xref target="element-precursor-digest">Precursor Image Diges reading the content of the firmware image. This can protect against confidential
t</xref></t> information disclosures and discovery of vulnerabilities through reverse engine
ering. Therefore, the manifest must convey the information required to allow an
</section> intended recipient to decrypt an encrypted payload.</t>
<section anchor="req-sec-authentic-compatibility" title="REQ.SEC.AUTH.COMPATIBIL <dl spacing="normal">
ITY: Authenticated Vendor and Class IDs"> <dt>Mitigates:</dt><dd><xref target="threat-img-disclosure" format="de
fault">THREAT.IMG.DISCLOSURE</xref>, <xref target="threat-net-onpath" format="de
<t>The identifiers that specify firmware compatibility MUST be authenticated to fault">THREAT.NET.ONPATH</xref></dd>
ensure that only compatible firmware is installed on a target device.</t> <dt>Implemented by:</dt><dd><xref target="manifest-element-encryption-
wrapper" format="default">Encryption Wrapper</xref></dd>
<t>Mitigates: <xref target="threat-incompatible">THREAT.IMG.INCOMPATIBLE</xref>< </dl>
/t> </section>
<section anchor="req-sec-access-control" numbered="true" toc="default">
<t>Implemented By: <xref target="element-vendor-id">Vendor ID Condition</xref>, <name>REQ.SEC.ACCESS_CONTROL: Access Control</name>
<xref target="element-class-id">Class ID Condition</xref></t> <t>If a device grants different rights to different actors, then an ex
ercise of those rights <bcp14>MUST</bcp14> be validated against a list of rights
</section> for the actor. This typically takes the form of an Access Control List (ACL). A
<section anchor="req-sec-rights" title="REQ.SEC.RIGHTS: Rights Require Authentic CLs are applied to two scenarios:</t>
ity"> <ol spacing="normal" type="1"><li>An ACL decides which elements of the
manifest may be overridden and by which actors.</li>
<t>If a device grants different rights to different actors, exercising those rig <li>An ACL decides which component identifier / storage identifier p
hts MUST be accompanied by proof of those rights, in the form of proof of authen airs can be written by which actors.</li>
ticity. Authenticity mechanisms, such as those required in <xref target="req-sec </ol>
-authentic">REQ.SEC.AUTHENTIC</xref>, can be used to prove authenticity.</t> <dl spacing="normal">
<dt>Mitigates:</dt><dd><xref target="threat-mfst-override" format="def
<t>For example, if a device has a policy that requires that firmware have both a ault">THREAT.MFST.OVERRIDE</xref>, <xref target="threat-upd-unapproved" format="
n Authorship right and a Qualification right and if that device grants Authorshi default">THREAT.UPD.UNAPPROVED</xref></dd>
p and Qualification rights to different parties, such as a Device Operator and a <dt>Implemented by:</dt><dd>Client-side code, not specified in manifes
Network Operator, respectively, then the firmware cannot be installed without p t</dd>
roof of rights from both the Device Operator and the Network Operator.</t> </dl>
</section>
<t>Mitigates: <xref target="threat-upd-unapproved">THREAT.UPD.UNAPPROVED</xref>< <section anchor="req-sec-mfst-confidentiality" numbered="true" toc="defa
/t> ult">
<name>REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests</name>
<t>Implemented by: <xref target="manifest-element-signature">Signature</xref></t <t>A manifest format <bcp14>MUST</bcp14> allow encryption of selected
> parts of the manifest or encryption of the entire manifest to prevent sensitive
content of the firmware metadata from being leaked.</t>
</section> <dl spacing="normal">
<section anchor="req-sec-image-confidentiality" title="REQ.SEC.IMG.CONFIDENTIALI <dt>Mitigates:</dt><dd><xref target="threat-mfst-exposure" format="def
TY: Payload Encryption"> ault">THREAT.MFST.EXPOSURE</xref>, <xref target="threat-net-onpath" format="defa
ult">THREAT.NET.ONPATH</xref></dd>
<t>The manifest information model MUST enable encrypted payloads. Encryption hel <dt>Implemented by:</dt><dd>Manifest Encryption Wrapper / Transport Se
ps to prevent third parties, including attackers, from reading the content of th curity</dd>
e firmware image. This can protect against confidential information disclosures </dl>
and discovery of vulnerabilities through reverse engineering. Therefore the mani </section>
fest must convey the information required to allow an intended recipient to decr <section anchor="req-sec-img-complete-digest" numbered="true" toc="defau
ypt an encrypted payload.</t> lt">
<name>REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest</name>
<t>Mitigates: <xref target="threat-img-disclosure">THREAT.IMG.DISCLOSURE</xref>, <t>The digest <bcp14>SHOULD</bcp14> cover all available space in a fix
<xref target="threat-net-onpath">THREAT.NET.ONPATH</xref></t> ed-size storage location. Variable-size storage locations <bcp14>MUST</bcp14> be
restricted to exactly the size of deployed payload. This prevents any data from
<t>Implemented by: <xref target="manifest-element-encryption-wrapper">Encryption being distributed without being covered by the digest. For example, XIP microco
Wrapper</xref></t> ntrollers typically have fixed-size storage. These devices should deploy a diges
t that covers the deployed firmware image, concatenated with the default erased
</section> value of any remaining space.</t>
<section anchor="req-sec-access-control" title="REQ.SEC.ACCESS_CONTROL: Access C <dl spacing="normal">
ontrol"> <dt>Mitigates:</dt><dd><xref target="threat-img-extra" format="default
">THREAT.IMG.EXTRA</xref></dd>
<t>If a device grants different rights to different actors, then an exercise of <dt>Implemented by:</dt><dd><xref target="manifest-element-payload-dig
those rights MUST be validated against a list of rights for the actor. This typi est" format="default">Payload Digests</xref></dd>
cally takes the form of an Access Control List (ACL). ACLs are applied to two sc </dl>
enarios:</t> </section>
<section anchor="req-sec-reporting" numbered="true" toc="default">
<t><list style="numbers"> <name>REQ.SEC.REPORTING: Secure Reporting</name>
<t>An ACL decides which elements of the manifest may be overridden and by whic <t>Status reports from the device to any remote system <bcp14>MUST</bc
h actors.</t> p14> be performed over an authenticated, confidential channel in order to preven
<t>An ACL decides which component identifier/storage identifier pairs can be w t modification or spoofing of the reports.</t>
ritten by which actors.</t> <dl spacing="normal">
</list></t> <dt>Mitigates:</dt><dd><xref target="threat-net-onpath" format="defaul
t">THREAT.NET.ONPATH</xref></dd>
<t>Mitigates: <xref target="threat-mfst-override">THREAT.MFST.OVERRIDE</xref>, < <dt>Implemented by:</dt><dd>Transport Security / Manifest format trigg
xref target="threat-upd-unapproved">THREAT.UPD.UNAPPROVED</xref></t> ering generation of reports</dd>
</dl>
<t>Implemented by: Client-side code, not specified in manifest.</t> </section>
<section anchor="req-sec-key-protection" numbered="true" toc="default">
</section> <name>REQ.SEC.KEY.PROTECTION: Protected Storage of Signing Keys</name>
<section anchor="req-sec-mfst-confidentiality" title="REQ.SEC.MFST.CONFIDENTIALI <t>Cryptographic keys for signing/authenticating manifests <bcp14>SHOU
TY: Encrypted Manifests"> LD</bcp14> be stored in a manner that is inaccessible to networked devices -- fo
r example, in an HSM or an air-gapped computer. This protects against an attacke
<t>A manifest format MUST allow encryption of selected parts of the manifest or r obtaining the keys.</t>
encryption of the entire manifest to prevent sensitive content of the firmware m <t>Keys <bcp14>SHOULD</bcp14> be stored in a way that limits the risk
etadata to be leaked.</t> of a legitimate, but compromised, entity (such as a server or developer computer
) issuing signing requests.</t>
<t>Mitigates: <xref target="threat-mfst-exposure">THREAT.MFST.EXPOSURE</xref>, < <dl spacing="normal">
xref target="threat-net-onpath">THREAT.NET.ONPATH</xref></t> <dt>Mitigates:</dt><dd><xref target="threat-key-exposure" format="defa
ult">THREAT.KEY.EXPOSURE</xref></dd>
<t>Implemented by: Manifest Encryption Wrapper / Transport Security</t> <dt>Implemented by:</dt><dd>Hardware-assisted isolation technologies,
which are outside the scope of the manifest format</dd>
</section> </dl>
<section anchor="req-sec-img-complete-digest" title="REQ.SEC.IMG.COMPLETE_DIGEST </section>
: Whole Image Digest"> <section anchor="req-sec-key-rotation" numbered="true" toc="default">
<name>REQ.SEC.KEY.ROTATION: Protected Storage of Signing Keys</name>
<t>The digest SHOULD cover all available space in a fixed-size storage location. <t>Cryptographic keys for signing/authenticating manifests <bcp14>SHOU
Variable-size storage locations MUST be restricted to exactly the size of deplo LD</bcp14> be replaced from time to time. Because it is difficult and risky to r
yed payload. This prevents any data from being distributed without being covered eplace a trust anchor, keys used for signing updates <bcp14>SHOULD</bcp14> be de
by the digest. For example, XIP microcontrollers typically have fixed-size stor legates of that trust anchor.</t>
age. These devices should deploy a digest that covers the deployed firmware imag <t>If key expiration is performed based on time, then a secure clock i
e, concatenated with the default erased value of any remaining space.</t> s needed. If the time source used by a recipient to check for expiration is flaw
ed, an old signing key can be used as current, which compounds <xref target="thr
<t>Mitigates: <xref target="threat-img-extra">THREAT.IMG.EXTRA</xref></t> eat-key-exposure" format="default">THREAT.KEY.EXPOSURE</xref>.</t>
<dl spacing="normal">
<t>Implemented by: <xref target="manifest-element-payload-digest">Payload Digest <dt>Mitigates:</dt><dd><xref target="threat-key-exposure" format="defa
s</xref></t> ult">THREAT.KEY.EXPOSURE</xref></dd>
<dt>Implemented by:</dt><dd>Secure storage technology, which is a syst
</section> em design/implementation aspect outside the scope of the manifest format</dd>
<section anchor="req-sec-reporting" title="REQ.SEC.REPORTING: Secure Reporting"> </dl>
</section>
<t>Status reports from the device to any remote system MUST be performed over an <section anchor="req-sec-mfst-check" numbered="true" toc="default">
authenticated, confidential channel in order to prevent modification or spoofin <name>REQ.SEC.MFST.CHECK: Validate Manifests prior to Deployment</name
g of the reports.</t> >
<t>Manifests <bcp14>SHOULD</bcp14> be verified prior to deployment. Th
<t>Mitigates: <xref target="threat-net-onpath">THREAT.NET.ONPATH</xref></t> is reduces problems that may arise with devices installing firmware images that
damage devices unintentionally.</t>
<t>Implemented by: Transport Security / Manifest format triggering generation of <dl spacing="normal">
reports</t> <dt>Mitigates:</dt><dd><xref target="threat-mfst-modification" format=
"default">THREAT.MFST.MODIFICATION</xref></dd>
</section> <dt>Implemented by:</dt><dd>Testing infrastructure. While outside the
<section anchor="req-sec-key-protection" title="REQ.SEC.KEY.PROTECTION: Protecte scope of the manifest format, proper testing of low-level software is essential
d storage of signing keys"> for avoiding unnecessary downtime or worse situations.</dd>
</dl>
<t>Cryptographic keys for signing/authenticating manifests SHOULD be stored in a </section>
manner that is inaccessible to networked devices, for example in an HSM, or an <section anchor="req-sec-mfst-trusted" numbered="true" toc="default">
air-gapped computer. This protects against an attacker obtaining the keys.</t> <name>REQ.SEC.MFST.TRUSTED: Construct Manifests in a Trusted Environme
nt</name>
<t>Keys SHOULD be stored in a way that limits the risk of a legitimate, but comp <t>For high-risk deployments, such as large numbers of devices or devi
romised, entity (such as a server or developer computer) issuing signing request ces that provide critical functions, manifests <bcp14>SHOULD</bcp14> be construc
s.</t> ted 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 t
<t>Mitigates: <xref target="threat-key-exposure">THREAT.KEY.EXPOSURE</xref></t> his requirement (see <xref target="threat-mfst-modification" format="default">TH
REAT.MFST.MODIFICATION</xref>).</t>
<t>Implemented by: Hardware-assisted isolation technologies, which are outside t <dl spacing="normal">
he scope of the manifest format.</t> <dt>Mitigates:</dt><dd><xref target="threat-mfst-modification" format=
"default">THREAT.MFST.MODIFICATION</xref></dd>
</section> <dt>Implemented by:</dt><dd>Physical and network security for protecti
<section anchor="req-sec-key-rotation" title="REQ.SEC.KEY.ROTATION: Protected st ng the environment where firmware updates are prepared to avoid unauthorized acc
orage of signing keys"> ess to this infrastructure</dd>
</dl>
<t>Cryptographic keys for signing/authenticating manifests SHOULD be replaced fr </section>
om time to time. Because it is difficult and risky to replace a Trust Anchor, ke <section anchor="req-sec-mfst-const" numbered="true" toc="default">
ys used for signing updates SHOULD be delegates of that Trust Anchor.</t> <name>REQ.SEC.MFST.CONST: Manifest Kept Immutable between Check and Us
e</name>
<t>If key expiration is performed based on time, then a secure clock is needed. <t>Both the manifest and any data extracted from it <bcp14>MUST</bcp14
If the time source used by a recipient to check for expiration is flawed, an old > be held immutable between its authenticity verification (time of check) and it
signing key can be used as current, which compounds <xref target="threat-key-ex s use (time of use). To make this guarantee, the manifest <bcp14>MUST</bcp14> fi
posure">THREAT.KEY.EXPOSURE</xref>.</t> t within internal memory or secure memory, such as encrypted memory. The recipie
nt <bcp14>SHOULD</bcp14> defend the manifest from tampering by code or hardware
<t>Mitigates: <xref target="threat-key-exposure">THREAT.KEY.EXPOSURE</xref></t> resident in the recipient -- for example, other processes or debuggers.</t>
<t>If an application requires that the manifest be verified before sto
<t>Implemented by: Secure storage technology, which is a system design/implement ring it, then this means the manifest <bcp14>MUST</bcp14> fit in RAM.</t>
ation aspect outside the scope of the manifest format.</t> <dl spacing="normal">
<dt>Mitigates:</dt><dd><xref target="threat-mfst-toctou" format="defau
</section> lt">THREAT.MFST.TOCTOU</xref></dd>
<section anchor="req-sec-mfst-check" title="REQ.SEC.MFST.CHECK: Validate manifes <dt>Implemented by:</dt><dd>Proper system design with sufficient resou
ts prior to deployment"> rces and implementation avoiding TOCTOU attacks</dd>
</dl>
<t>Manifests SHOULD be verified prior to deployment. This reduces problems that </section>
may arise with devices installing firmware images that damage devices unintentio </section>
nally.</t> <section anchor="user-stories" numbered="true" toc="default">
<name>User Stories</name>
<t>Mitigates: <xref target="threat-mfst-modification">THREAT.MFST.MODIFICATION</ <t>User stories provide expected use cases. These are used to feed into
xref></t> usability requirements.</t>
<section anchor="user-story-install-instructions" numbered="true" toc="d
<t>Implemented by: Testing infrastructure. While outside the scope of the manife efault">
st format, proper testing of low-level software is essential for avoiding unnece <name>USER_STORY.INSTALL.INSTRUCTIONS: Installation Instructions</name
ssary down-time or worse situations.</t> >
<t>As a device operator, I want to provide my devices with additional
</section> installation instructions so that I can keep process details out of my payload d
<section anchor="req-sec-mfst-trusted" title="REQ.SEC.MFST.TRUSTED: Construct ma ata.</t>
nifests in a trusted environment"> <t>Some installation instructions might be as follows:</t>
<ul spacing="normal">
<t>For high risk deployments, such as large numbers of devices or critical funct <li>Use a table of hashes to ensure that each block of the payload i
ion devices, manifests SHOULD be constructed in an environment that is protected s validated before writing.</li>
from interference, such as an air-gapped computer. Note that a networked comput <li>Do not report progress.</li>
er connected to an HSM does not fulfill this requirement (see <xref target="thre <li>Pre-cache the update, but do not install.</li>
at-mfst-modification">THREAT.MFST.MODIFICATION</xref>).</t> <li>Install the pre-cached update matching this manifest.</li>
<li>Install this update immediately, overriding any long-running tas
<t>Mitigates: <xref target="threat-mfst-modification">THREAT.MFST.MODIFICATION</ ks.</li>
xref></t> </ul>
<dl spacing="normal">
<t>Implemented by: Physical and network security for protecting the environment <dt>Satisfied by:</dt><dd><xref target="req-use-mfst-pre-check" format
where firmware updates are prepared to avoid unauthorized access to this infrast ="default">REQ.USE.MFST.PRE_CHECK</xref></dd>
ructure.</t> </dl>
</section>
</section> <section anchor="user-story-fail-early" numbered="true" toc="default">
<section anchor="req-sec-mfst-const" title="REQ.SEC.MFST.CONST: Manifest kept im <name>USER_STORY.MFST.FAIL_EARLY: Fail Early</name>
mutable between check and use"> <t>As a designer of a resource-constrained IoT device, I want bad upda
tes to fail as early as possible to preserve battery life and limit consumed ban
<t>Both the manifest and any data extracted from it MUST be held immutable betwe dwidth.</t>
en its authenticity verification (time of check) and its use (time of use). To m <dl spacing="normal">
ake this guarantee, the manifest MUST fit within an internal memory or a secure <dt>Satisfied by:</dt><dd><xref target="req-use-mfst-pre-check" format
memory, such as encrypted memory. The recipient SHOULD defend the manifest from ="default">REQ.USE.MFST.PRE_CHECK</xref></dd>
tampering by code or hardware resident in the recipient, for example other proce </dl>
sses or debuggers.</t> </section>
<section anchor="user-story-override" numbered="true" toc="default">
<t>If an application requires that the manifest is verified before storing it, t <name>USER_STORY.OVERRIDE: Override Non-critical Manifest Elements</na
hen this means the manifest MUST fit in RAM.</t> me>
<t>As a device operator, I would like to be able to override the non-c
<t>Mitigates: <xref target="threat-mfst-toctou">THREAT.MFST.TOCTOU</xref></t> ritical information in the manifest so that I can control my devices more precis
ely. The authority to override this information is provided via the installation
<t>Implemented by: Proper system design with sufficient resources and implementa of a limited trust anchor by another authority.</t>
tion avoiding TOCTOU attacks.</t> <t>Some examples of potentially overridable information:</t>
<dl spacing="normal">
</section> <dt><xref target="manifest-element-payload-indicator" format="defaul
</section> t">URIs</xref>:</dt><dd>This allows the device operator to direct devices to the
<section anchor="user-stories" title="User Stories"> ir own infrastructure in order to reduce network load.</dd>
<dt>Conditions:</dt><dd>This allows the device operator to impose ad
<t>User stories provide expected use cases. These are used to feed into usabilit ditional constraints on the installation of the manifest.</dd>
y requirements.</t> <dt><xref target="manifest-element-additional-install-info" format="
default">Directives</xref>:</dt><dd>This allows the device operator to add more
<section anchor="user-story-install-instructions" title="USER_STORY.INSTALL.INST instructions, such as time of installation.</dd>
RUCTIONS: Installation Instructions"> <dt><xref target="manifest-element-processing-steps" format="default
">Processing Steps</xref>:</dt><dd>If an intermediary performs an action on beha
<t>As a Device Operator, I want to provide my devices with additional installati lf of a device, it may need to override the processing steps. It is still possib
on instructions so that I can keep process details out of my payload data.</t> le for a device to verify the final content and the result of any processing ste
p that specifies a digest. Some processing steps should be non-overridable.</dd>
<t>Some installation instructions might be:</t> <dt>Satisfied by:</dt><dd><xref target="req-use-mfst-component" format
="default">REQ.USE.MFST.COMPONENT</xref></dd>
<t><list style="symbols"> </dl>
<t>Use a table of hashes to ensure that each block of the payload is validated </section>
before writing.</t> <section anchor="user-story-component" numbered="true" toc="default">
<t>Do not report progress.</t> <name>USER_STORY.COMPONENT: Component Update</name>
<t>Pre-cache the update, but do not install.</t> <t>As a device operator, I want to divide my firmware into components,
<t>Install the pre-cached update matching this manifest.</t> so that I can reduce the size of updates, make different parties responsible fo
<t>Install this update immediately, overriding any long-running tasks.</t> r different components, and divide my firmware into frequently updated and infre
</list></t> quently updated components.</t>
<dl spacing="normal">
<t>Satisfied by: <xref target="req-use-mfst-pre-check">REQ.USE.MFST.PRE_CHECK</x <dt>Satisfied by:</dt><dd><xref target="req-use-mfst-component" format
ref></t> ="default">REQ.USE.MFST.COMPONENT</xref></dd>
</dl>
</section> </section>
<section anchor="user-story-fail-early" title="USER_STORY.MFST.FAIL_EARLY: Fail <section anchor="user-story-multi-auth" numbered="true" toc="default">
Early"> <name>USER_STORY.MULTI_AUTH: Multiple Authorizations</name>
<t>As a device operator, I want to ensure the quality of a firmware up
<t>As a designer of a resource-constrained IoT device, I want bad updates to fai date before installing it, so that I can ensure interoperability of all devices
l as early as possible to preserve battery life and limit consumed bandwidth.</t in my product family. I want to restrict the ability to make changes to my devic
> es to require my express approval.</t>
<dl spacing="normal">
<t>Satisfied by: <xref target="req-use-mfst-pre-check">REQ.USE.MFST.PRE_CHECK</x <dt>Satisfied by:</dt><dd><xref target="req-use-mfst-multi-auth" forma
ref></t> t="default">REQ.USE.MFST.MULTI_AUTH</xref>, <xref target="req-sec-access-control
" format="default">REQ.SEC.ACCESS_CONTROL</xref></dd>
</section> </dl>
<section anchor="user-story-override" title="USER_STORY.OVERRIDE: Override Non-C </section>
ritical Manifest Elements"> <section anchor="user-story-img-format" numbered="true" toc="default">
<name>USER_STORY.IMG.FORMAT: Multiple Payload Formats</name>
<t>As a Device Operator, I would like to be able to override the non-critical in <t>As a device operator, I want to be able to send multiple payload fo
formation in the manifest so that I can control my devices more precisely. The a rmats to suit the needs of my update, so that I can optimize the bandwidth used
uthority to override this information is provided via the installation of a limi by my devices.</t>
ted trust anchor by another authority.</t> <dl spacing="normal">
<dt>Satisfied by:</dt><dd><xref target="req-use-img-format" format="de
<t>Some examples of potentially overridable information:</t> fault">REQ.USE.IMG.FORMAT</xref></dd>
</dl>
<t><list style="symbols"> </section>
<t><xref target="manifest-element-payload-indicator">URIs</xref>: this allows <section anchor="user-story-img-confidentiality" numbered="true" toc="de
the Device Operator to direct devices to their own infrastructure in order to re fault">
duce network load.</t> <name>USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential Information
<t>Conditions: this allows the Device Operator to pose additional constraints Disclosures</name>
on the installation of the manifest.</t> <t>As a firmware author, I want to prevent confidential information in
<t><xref target="manifest-element-additional-install-info">Directives</xref>: the manifest from being disclosed when distributing manifests and firmware imag
this allows the Device Operator to add more instructions such as time of install es. Confidential information may include information about the device these upda
ation.</t> tes are being applied to as well as information in the firmware image itself.</t
<t><xref target="manifest-element-processing-steps">Processing Steps</xref>: I >
f an intermediary performs an action on behalf of a device, it may need to overr <dl spacing="normal">
ide the processing steps. It is still possible for a device to verify the final <dt>Satisfied by:</dt><dd><xref target="req-sec-image-confidentiality"
content and the result of any processing step that specifies a digest. Some proc format="default">REQ.SEC.IMG.CONFIDENTIALITY</xref></dd>
essing steps should be non-overridable.</t> </dl>
</list></t> </section>
<section anchor="user-story-img-unknown-format" numbered="true" toc="def
<t>Satisfied by: <xref target="req-use-mfst-component">REQ.USE.MFST.COMPONENT</x ault">
ref></t> <name>USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from Unpacking Un
known Formats</name>
</section> <t>As a device operator, I want devices to determine whether they can
<section anchor="user-story-component" title="USER_STORY.COMPONENT: Component Up process a payload prior to downloading it.</t>
date"> <t>In some cases, it may be desirable for a third party to perform som
e processing on behalf of a target. For this to occur, the third party <bcp14>MU
<t>As a Device Operator, I want to divide my firmware into components, so that I ST</bcp14> indicate what processing occurred and how to verify it against the Tr
can reduce the size of updates, make different parties responsible for differen ust Provisioning Authority's intent.</t>
t components, and divide my firmware into frequently updated and infrequently up <t>This amounts to overriding <xref target="manifest-element-processin
dated components.</t> g-steps" format="default">Processing Steps</xref> and <xref target="manifest-ele
ment-payload-indicator" format="default">Payload Indicator</xref>.</t>
<t>Satisfied by: <xref target="req-use-mfst-component">REQ.USE.MFST.COMPONENT</x <dl spacing="normal">
ref></t> <dt>Satisfied by:</dt><dd><xref target="req-use-img-format" format="de
fault">REQ.USE.IMG.FORMAT</xref>, <xref target="req-use-img-nested" format="defa
</section> ult">REQ.USE.IMG.NESTED</xref>, <xref target="req-use-mfst-override" format="def
<section anchor="user-story-multi-auth" title="USER_STORY.MULTI_AUTH: Multiple A ault">REQ.USE.MFST.OVERRIDE_REMOTE</xref></dd>
uthorizations"> </dl>
</section>
<t>As a Device Operator, I want to ensure the quality of a firmware update befor <section anchor="user-story-img-current-version" numbered="true" toc="de
e installing it, so that I can ensure interoperability of all devices in my prod fault">
uct family. I want to restrict the ability to make changes to my devices to requ <name>USER_STORY.IMG.CURRENT_VERSION: Specify Version Numbers of Targe
ire my express approval.</t> t Firmware</name>
<t>As a device operator, I want to be able to target devices for updat
<t>Satisfied by: <xref target="req-use-mfst-multi-auth">REQ.USE.MFST.MULTI_AUTH< es based on their current firmware version, so that I can control which versions
/xref>, <xref target="req-sec-access-control">REQ.SEC.ACCESS_CONTROL</xref></t> are replaced with a single manifest.</t>
<dl spacing="normal">
</section> <dt>Satisfied by:</dt><dd><xref target="req-use-img-versions" format="
<section anchor="user-story-img-format" title="USER_STORY.IMG.FORMAT: Multiple P default">REQ.USE.IMG.VERSIONS</xref></dd>
ayload Formats"> </dl>
</section>
<t>As a Device Operator, I want to be able to send multiple payload formats to s <section anchor="user-story-img-select" numbered="true" toc="default">
uit the needs of my update, so that I can optimise the bandwidth used by my devi <name>USER_STORY.IMG.SELECT: Enable Devices to Choose between Images</
ces.</t> name>
<t>As a developer, I want to be able to sign two or more versions of m
<t>Satisfied by: <xref target="req-use-img-format">REQ.USE.IMG.FORMAT</xref></t> y 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>
</section> <dl spacing="normal">
<section anchor="user-story-img-confidentiality" title="USER_STORY.IMG.CONFIDENT <dt>Satisfied by:</dt><dd><xref target="req-use-img-select" format="de
IALITY: Prevent Confidential Information Disclosures"> fault">REQ.USE.IMG.SELECT</xref></dd>
</dl>
<t>As a firmware author, I want to prevent confidential information in the manif </section>
est from being disclosed when distributing manifests and firmware images. Confid <section anchor="user-story-exec-mfst" numbered="true" toc="default">
ential information may include information about the device these updates are be <name>USER_STORY.EXEC.MFST: Secure Execution Using Manifests</name>
ing applied to as well as information in the firmware image itself.</t> <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 siz
<t>Satisfied by: <xref target="req-sec-image-confidentiality">REQ.SEC.IMG.CONFID e is smaller, I can share common code, and I can reduce signature verifications.
ENTIALITY</xref></t> </t>
<dl spacing="normal">
</section> <dt>Satisfied by:</dt><dd><xref target="req-use-exec" format="default"
<section anchor="user-story-img-unknown-format" title="USER_STORY.IMG.UNKNOWN_FO >REQ.USE.EXEC</xref></dd>
RMAT: Prevent Devices from Unpacking Unknown Formats"> </dl>
</section>
<t>As a Device Operator, I want devices to determine whether they can process a <section anchor="user-story-exec-decompress" numbered="true" toc="defaul
payload prior to downloading it.</t> t">
<name>USER_STORY.EXEC.DECOMPRESS: Decompress on Load</name>
<t>In some cases, it may be desirable for a third party to perform some processi <t>As a developer of firmware for a run-from-RAM device, I would like
ng on behalf of a target. For this to occur, the third party MUST indicate what to use compressed images and to indicate to the bootloader that I am using a com
processing occurred and how to verify it against the Trust Provisioning Authorit pressed image in the manifest so that it can be used with secure execution/boot.
y’s intent.</t> </t>
<dl spacing="normal">
<t>This amounts to overriding <xref target="manifest-element-processing-steps">P <dt>Satisfied by:</dt><dd><xref target="req-use-load" format="default"
rocessing Steps</xref> and <xref target="manifest-element-payload-indicator">Pay >REQ.USE.LOAD</xref></dd>
load Indicator</xref>.</t> </dl>
</section>
<t>Satisfied by: <xref target="req-use-img-format">REQ.USE.IMG.FORMAT</xref>, <x <section anchor="user-story-mfst-img" numbered="true" toc="default">
ref target="req-use-img-nested">REQ.USE.IMG.NESTED</xref>, <xref target="req-use <name>USER_STORY.MFST.IMG: Payload in Manifest</name>
-mfst-override">REQ.USE.MFST.OVERRIDE_REMOTE</xref></t> <t>As an Operator of devices on a constrained network, I would like th
e manifest to be able to include a small payload in the same packet so that I ca
</section> n reduce network traffic.</t>
<section anchor="user-story-img-current-version" title="USER_STORY.IMG.CURRENT_V <t>Small payloads may include, for example, wrapped content encryption
ERSION: Specify Version Numbers of Target Firmware"> keys, configuration information, public keys, authorization tokens, or X.509 ce
rtificates.</t>
<t>As a Device Operator, I want to be able to target devices for updates based o <dl spacing="normal">
n their current firmware version, so that I can control which versions are repla <dt>Satisfied by:</dt><dd><xref target="req-use-payload" format="defau
ced with a single manifest.</t> lt">REQ.USE.PAYLOAD</xref></dd>
</dl>
<t>Satisfied by: <xref target="req-use-img-versions">REQ.USE.IMG.VERSIONS</xref> </section>
</t> <section anchor="user-story-mfst-parse" numbered="true" toc="default">
<name>USER_STORY.MFST.PARSE: Simple Parsing</name>
</section> <t>As a developer for constrained devices, I want a low-complexity lib
<section anchor="user-story-img-select" title="USER_STORY.IMG.SELECT: Enable Dev rary for processing updates so that I can fit more application code on my device
ices to Choose Between Images"> .</t>
<dl spacing="normal">
<t>As a developer, I want to be able to sign two or more versions of my firmware <dt>Satisfied by:</dt><dd><xref target="req-use-parse" format="default
in a single manifest so that I can use a very simple bootloader that chooses be ">REQ.USE.PARSE</xref></dd>
tween two or more images that are executed in-place.</t> </dl>
</section>
<t>Satisfied by: <xref target="req-use-img-select">REQ.USE.IMG.SELECT</xref></t> <section anchor="user-story-mfst-delegation" numbered="true" toc="defaul
t">
</section> <name>USER_STORY.MFST.DELEGATION: Delegated Authority in Manifest</nam
<section anchor="user-story-exec-mfst" title="USER_STORY.EXEC.MFST: Secure Execu e>
tion Using Manifests"> <t>As a device operator that rotates delegated authority more often th
an delivering firmware updates, I would like to delegate a new authority when I
<t>As a signer for both secure execution/boot and firmware deployment, I would l deliver a firmware update so that I can accomplish both tasks in a single transm
ike to use the same signed document for both tasks so that my data size is small ission.</t>
er, I can share common code, and I can reduce signature verifications.</t> <dl spacing="normal">
<dt>Satisfied by:</dt><dd><xref target="req-use-delegation" format="de
<t>Satisfied by: <xref target="req-use-exec">REQ.USE.EXEC</xref></t> fault">REQ.USE.DELEGATION</xref></dd>
</dl>
</section> </section>
<section anchor="user-story-exec-decompress" title="USER_STORY.EXEC.DECOMPRESS: <section anchor="user-story-mfst-pre-check" numbered="true" toc="default
Decompress on Load"> ">
<name>USER_STORY.MFST.PRE_CHECK: Update Evaluation</name>
<t>As a developer of firmware for a run-from-RAM device, I would like to use com <t>As an Operator of a constrained network, I would like devices on my
pressed images and to indicate to the bootloader that I am using a compressed im network to be able to evaluate the suitability of an update prior to initiating
age in the manifest so that it can be used with secure execution/boot.</t> any large download so that I can prevent unnecessary consumption of bandwidth.<
/t>
<t>Satisfied by: <xref target="req-use-load">REQ.USE.LOAD</xref></t> <dl spacing="normal">
<dt>Satisfied by:</dt><dd><xref target="req-use-mfst-pre-check" format
</section> ="default">REQ.USE.MFST.PRE_CHECK</xref></dd>
<section anchor="user-story-mfst-img" title="USER_STORY.MFST.IMG: Payload in Man </dl>
ifest"> </section>
<section anchor="user-story-mfst-admin" numbered="true" toc="default">
<t>As an operator of devices on a constrained network, I would like the manifest <name>USER_STORY.MFST.ADMINISTRATION: Administration of Manifests</nam
to be able to include a small payload in the same packet so that I can reduce n e>
etwork traffic.</t> <t>As a device operator, I want to understand what an update will do a
nd to which devices it applies so that I can make informed choices about which u
<t>Small payloads may include, for example, wrapped content encryption keys, con pdates to apply, when to apply them, and which devices should be updated.</t>
figuration information, public keys, authorization tokens, or X.509 certificates <dl spacing="normal">
.</t> <dt>Satisfied by:</dt><dd><xref target="req-use-mfst-text" format="def
ault">REQ.USE.MFST.TEXT</xref></dd>
<t>Satisfied by: <xref target="req-use-payload">REQ.USE.PAYLOAD</xref></t> </dl>
</section>
</section> </section>
<section anchor="user-story-mfst-parse" title="USER_STORY.MFST.PARSE: Simple Par <section anchor="usability-requirements" numbered="true" toc="default">
sing"> <name>Usability Requirements</name>
<t>The following usability requirements satisfy the user stories listed
<t>As a developer for constrained devices, I want a low complexity library for p above.</t>
rocessing updates so that I can fit more application code on my device.</t> <section anchor="req-use-mfst-pre-check" numbered="true" toc="default">
<name>REQ.USE.MFST.PRE_CHECK: Pre-installation Checks</name>
<t>Satisfied by: <xref target="req-use-parse">REQ.USE.PARSE</xref></t> <t>A manifest format <bcp14>MUST</bcp14> be able to carry all informat
ion required to process an update.</t>
</section> <t>For example, information about which precursor image is required fo
<section anchor="user-story-mfst-delegation" title="USER_STORY.MFST.DELEGATION: r a differential update must be placed in the manifest.</t>
Delegated Authority in Manifest"> <dl spacing="normal">
<dt>Satisfies:</dt><dd><xref target="user-story-mfst-pre-check">USER_STO
<t>As a Device Operator that rotates delegated authority more often than deliver RY.MFST.PRE_CHECK</xref>,
ing firmware updates, I would like to delegate a new authority when I deliver a <xref target="user-story-install-instructions" format="default">USER_STORY.INS
firmware update so that I can accomplish both tasks in a single transmission.</t TALL.INSTRUCTIONS</xref></dd>
> <dt>Implemented by:</dt><dd><xref target="manifest-element-additional-
install-info" format="default">Additional Installation Instructions</xref></dd>
<t>Satisfied by: <xref target="req-use-delegation">REQ.USE.DELEGATION</xref></t> </dl>
</section>
</section> <section anchor="req-use-mfst-text" numbered="true" toc="default">
<section anchor="user-story-mfst-pre-check" title="USER_STORY.MFST.PRE_CHECK: Up <name>REQ.USE.MFST.TEXT: Descriptive Manifest Information</name>
date Evaluation"> <t>It <bcp14>MUST</bcp14> be possible for a device operator to determi
ne what a manifest will do and which devices will accept it prior to distributio
<t>As an operator of a constrained network, I would like devices on my network t n.</t>
o be able to evaluate the suitability of an update prior to initiating any large <dl spacing="normal">
download so that I can prevent unnecessary consumption of bandwidth.</t> <dt>Satisfies:</dt><dd><xref target="user-story-mfst-admin" format="de
fault">USER_STORY.MFST.ADMINISTRATION</xref></dd>
<t>Satisfied by: <xref target="req-use-mfst-pre-check">REQ.USE.MFST.PRE_CHECK</x <dt>Implemented by:</dt><dd><xref target="manifest-element-text" forma
ref></t> t="default">Manifest Text Information</xref></dd>
</dl>
</section> </section>
<section anchor="user-story-mfst-admin" title="USER_STORY.MFST.ADMINISTRATION: A <section anchor="req-use-mfst-override" numbered="true" toc="default">
dministration of manifests"> <name>REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location<
/name>
<t>As a Device Operator, I want to understand what an update will do and to whic <t>A manifest format <bcp14>MUST</bcp14> be able to redirect payload f
h devices it applies so that I can make informed choices about which updates to etches. This applies where two manifests are used in conjunction. For example, a
apply, when to apply them, and which devices should be updated.</t> device operator creates a manifest specifying a payload and signs it, and provi
des a URI for that payload. A network operator creates a second manifest, with a
<t>Satisfied by <xref target="req-use-mfst-text">REQ.USE.MFST.TEXT</xref></t> dependency on the first. They use this second manifest to override the URIs pro
vided by the device operator, directing them into their own infrastructure inste
</section> ad. Some devices may provide this capability, while others may only look at cano
</section> nical sources of firmware. For this to be possible, the device must fetch the pa
<section anchor="usability-requirements" title="Usability Requirements"> yload, whereas a device that accepts payload pushes will ignore this feature.</t
>
<t>The following usability requirements satisfy the user stories listed above.</ <dl spacing="normal">
t> <dt>Satisfies:</dt><dd><xref target="user-story-override" format="defa
ult">USER_STORY.OVERRIDE</xref></dd>
<section anchor="req-use-mfst-pre-check" title="REQ.USE.MFST.PRE_CHECK: Pre-Inst <dt>Implemented by:</dt><dd><xref target="manifest-element-aliases" fo
allation Checks"> rmat="default">Aliases</xref></dd>
</dl>
<t>A manifest format MUST be able to carry all information required to process a </section>
n update.</t> <section anchor="req-use-mfst-component" numbered="true" toc="default">
<name>REQ.USE.MFST.COMPONENT: Component Updates</name>
<t>For example: Information about which precursor image is required for a differ <t>A manifest format <bcp14>MUST</bcp14> be able to express the requir
ential update must be placed in the manifest.</t> ement to install one or more payloads from one or more authorities so that a mul
ti-payload update can be described. This allows multiple parties with different
<t>Satisfies: [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check), <xref targ permissions to collaborate in creating a single update for the IoT device, acros
et="user-story-install-instructions">USER_STORY.INSTALL.INSTRUCTIONS</xref></t> s multiple components.</t>
<t>This requirement implies that it must be possible to construct a tr
<t>Implemented by: <xref target="manifest-element-additional-install-info">Addit ee of manifests on a multi-image target.</t>
ional installation instructions</xref></t> <t>In order to enable devices with a heterogeneous storage architectur
e, the manifest must enable specification of both a storage system and the stora
</section> ge location within that storage system.</t>
<section anchor="req-use-mfst-text" title="REQ.USE.MFST.TEXT: Descriptive Manife <dl spacing="normal">
st Information"> <dt>Satisfies:</dt><dd><xref target="user-story-override" format="defa
ult">USER_STORY.OVERRIDE</xref>, <xref target="user-story-component" format="def
<t>It MUST be possible for a Device Operator to determine what a manifest will d ault">USER_STORY.COMPONENT</xref></dd>
o and which devices will accept it prior to distribution.</t> <dt>Implemented by:</dt><dd>Dependencies, StorageIdentifier, Component
Identifier</dd>
<t>Satisfies: <xref target="user-story-mfst-admin">USER_STORY.MFST.ADMINISTRATIO </dl>
N</xref></t> <section anchor="example-1-multiple-microcontrollers" numbered="true"
toc="default">
<t>Implemented by: <xref target="manifest-element-text">Manifest text informatio <name>Example 1: Multiple Microcontrollers</name>
n</xref></t> <t>An IoT device with multiple microcontrollers in the same physical
device will likely require multiple payloads with different component identifie
</section> rs.</t>
<section anchor="req-use-mfst-override" title="REQ.USE.MFST.OVERRIDE_REMOTE: Ove </section>
rride Remote Resource Location"> <section anchor="example-2-code-and-configuration" numbered="true" toc
="default">
<t>A manifest format MUST be able to redirect payload fetches. This applies wher <name>Example 2: Code and Configuration</name>
e two manifests are used in conjunction. For example, a Device Operator creates <t>A firmware image can be divided into two payloads: code and confi
a manifest specifying a payload and signs it, and provides a URI for that payloa guration. These payloads may require authorizations from different actors in ord
d. A Network Operator creates a second manifest, with a dependency on the first. er to install (see <xref target="req-sec-rights" format="default">REQ.SEC.RIGHTS
They use this second manifest to override the URIs provided by the Device Opera </xref> and <xref target="req-sec-access-control" format="default">REQ.SEC.ACCES
tor, directing them into their own infrastructure instead. Some devices may prov S_CONTROL</xref>). This structure means that multiple manifests may be required,
ide this capability, while others may only look at canonical sources of firmware with a dependency structure between them.</t>
. For this to be possible, the device must fetch the payload, whereas a device t </section>
hat accepts payload pushes will ignore this feature.</t> <section anchor="example-3-multiple-software-modules" numbered="true"
toc="default">
<t>Satisfies: <xref target="user-story-override">USER_STORY.OVERRIDE</xref></t> <name>Example 3: Multiple Software Modules</name>
<t>A firmware image can be divided into multiple functional blocks f
<t>Implemented by: <xref target="manifest-element-aliases">Aliases</xref></t> or separate testing and distribution. This means that code would need to be dist
ributed in multiple payloads. For example, this might be desirable in order to e
</section> nsure that common code between devices is identical in order to reduce distribut
<section anchor="req-use-mfst-component" title="REQ.USE.MFST.COMPONENT: Componen ion bandwidth.</t>
t Updates"> </section>
</section>
<t>A manifest format MUST be able to express the requirement to install one or m <section anchor="req-use-mfst-multi-auth" numbered="true" toc="default">
ore payloads from one or more authorities so that a multi-payload update can be <name>REQ.USE.MFST.MULTI_AUTH: Multiple Authentications</name>
described. This allows multiple parties with different permissions to collaborat <t>A manifest format <bcp14>MUST</bcp14> be able to carry multiple sig
e in creating a single update for the IoT device, across multiple components.</t natures so that authorizations from multiple parties with different permissions
> can be required in order to authorize installation of a manifest.</t>
<dl spacing="normal">
<t>This requirement implies that it must be possible to construct a tree of mani <dt>Satisfies:</dt><dd><xref target="user-story-multi-auth" format="de
fests on a multi-image target.</t> fault">USER_STORY.MULTI_AUTH</xref></dd>
<dt>Implemented by:</dt><dd><xref target="manifest-element-signature"
<t>In order to enable devices with a heterogeneous storage architecture, the man format="default">Signature</xref></dd>
ifest must enable specification of both storage system and the storage location </dl>
within that storage system.</t> </section>
<section anchor="req-use-img-format" numbered="true" toc="default">
<t>Satisfies: <xref target="user-story-override">USER_STORY.OVERRIDE</xref>, <xr <name>REQ.USE.IMG.FORMAT: Format Usability</name>
ef target="user-story-component">USER_STORY.COMPONENT</xref></t> <t>The manifest format <bcp14>MUST</bcp14> accommodate any payload for
mat that an Operator wishes to use. This enables the recipient to detect which f
<t>Implemented by: Dependencies, StorageIdentifier, ComponentIdentifier</t> ormat the Operator has chosen. Some examples of payload format are as follows:</
t>
<section anchor="example-1-multiple-microcontrollers" title="Example 1: Multiple <ul spacing="normal">
Microcontrollers"> <li>Binary</li>
<li>Executable and Linkable Format (ELF)</li>
<t>An IoT device with multiple microcontrollers in the same physical device will <li>Differential</li>
likely require multiple payloads with different component identifiers.</t> <li>Compressed</li>
<li>Packed configuration</li>
</section> <li>Intel HEX</li>
<section anchor="example-2-code-and-configuration" title="Example 2: Code and Co <li>Motorola S-Record</li>
nfiguration"> </ul>
<dl spacing="normal">
<t>A firmware image can be divided into two payloads: code and configuration. Th <dt>Satisfies:</dt><dd><xref target="user-story-img-format" format="de
ese payloads may require authorizations from different actors in order to instal fault">USER_STORY.IMG.FORMAT</xref> <xref target="user-story-img-unknown-format"
l (see <xref target="req-sec-rights">REQ.SEC.RIGHTS</xref> and <xref target="req format="default">USER_STORY.IMG.UNKNOWN_FORMAT</xref></dd>
-sec-access-control">REQ.SEC.ACCESS_CONTROL</xref>). This structure means that m <dt>Implemented by:</dt><dd><xref target="manifest-element-format" for
ultiple manifests may be required, with a dependency structure between them.</t> mat="default">Payload Format</xref></dd>
</dl>
</section> </section>
<section anchor="example-3-multiple-software-modules" title="Example 3: Multiple <section anchor="req-use-img-nested" numbered="true" toc="default">
Software Modules"> <name>REQ.USE.IMG.NESTED: Nested Formats</name>
<t>The manifest format <bcp14>MUST</bcp14> accommodate nested formats,
<t>A firmware image can be divided into multiple functional blocks for separate announcing to the target device all the nesting steps and any parameters used b
testing and distribution. This means that code would need to be distributed in m y those steps.</t>
ultiple payloads. For example, this might be desirable in order to ensure that c <dl spacing="normal">
ommon code between devices is identical in order to reduce distribution bandwidt <dt>Satisfies:</dt><dd><xref target="user-story-img-confidentiality" f
h.</t> ormat="default">USER_STORY.IMG.CONFIDENTIALITY</xref></dd>
<dt>Implemented by:</dt><dd><xref target="manifest-element-processing-
</section> steps" format="default">Processing Steps</xref></dd>
</section> </dl>
<section anchor="req-use-mfst-multi-auth" title="REQ.USE.MFST.MULTI_AUTH: Multip </section>
le authentications"> <section anchor="req-use-img-versions" numbered="true" toc="default">
<name>REQ.USE.IMG.VERSIONS: Target Version Matching</name>
<t>A manifest format MUST be able to carry multiple signatures so that authoriza <t>The manifest format <bcp14>MUST</bcp14> provide a method to specify
tions from multiple parties with different permissions can be required in order multiple version numbers of firmware to which the manifest applies, either with
to authorize installation of a manifest.</t> a list or with range matching.</t>
<dl spacing="normal">
<t>Satisfies: <xref target="user-story-multi-auth">USER_STORY.MULTI_AUTH</xref>< <dt>Satisfies:</dt><dd><xref target="user-story-img-current-version" f
/t> ormat="default">USER_STORY.IMG.CURRENT_VERSION</xref></dd>
<dt>Implemented by:</dt><dd><xref target="element-required-version" fo
<t>Implemented by: <xref target="manifest-element-signature">Signature</xref></t rmat="default">Required Image Version List</xref></dd>
> </dl>
</section>
</section> <section anchor="req-use-img-select" numbered="true" toc="default">
<section anchor="req-use-img-format" title="REQ.USE.IMG.FORMAT: Format Usability <name>REQ.USE.IMG.SELECT: Select Image by Destination</name>
"> <t>The manifest format <bcp14>MUST</bcp14> provide a mechanism to list
multiple equivalent payloads by execute-in-place (XIP) installation address, in
<t>The manifest format MUST accommodate any payload format that an Operator wish cluding the payload digest and, optionally, payload URIs.</t>
es to use. This enables the recipient to detect which format the Operator has ch <dl spacing="normal">
osen. Some examples of payload format are:</t> <dt>Satisfies:</dt><dd><xref target="user-story-img-select" format="de
fault">USER_STORY.IMG.SELECT</xref></dd>
<t><list style="symbols"> <dt>Implemented by:</dt><dd><xref target="manifest-element-xip-address
<t>Binary</t> " format="default">XIP Address</xref></dd>
<t>Executable and Linkable Format (ELF)</t> </dl>
<t>Differential</t> </section>
<t>Compressed</t> <section anchor="req-use-exec" numbered="true" toc="default">
<t>Packed configuration</t> <name>REQ.USE.EXEC: Executable Manifest</name>
<t>Intel HEX</t> <t>The manifest format <bcp14>MUST</bcp14> allow the description of an
<t>Motorola S-Record</t> executable system with a manifest on both XIP microcontrollers and complex oper
</list></t> ating systems. In addition, the manifest format <bcp14>MUST</bcp14> be able to e
xpress metadata, such as a kernel command line, used by any loader or bootloader
<t>Satisfies: <xref target="user-story-img-format">USER_STORY.IMG.FORMAT</xref> .</t>
<xref target="user-story-img-unknown-format">USER_STORY.IMG.UNKNOWN_FORMAT</xref <dl spacing="normal">
></t> <dt>Satisfies:</dt><dd><xref target="user-story-exec-mfst" format="def
ault">USER_STORY.EXEC.MFST</xref></dd>
<t>Implemented by: <xref target="manifest-element-format">Payload Format</xref>< <dt>Implemented by:</dt><dd><xref target="manifest-element-exec-metada
/t> ta" format="default">Runtime Metadata</xref></dd>
</dl>
</section> </section>
<section anchor="req-use-img-nested" title="REQ.USE.IMG.NESTED: Nested Formats"> <section anchor="req-use-load" numbered="true" toc="default">
<name>REQ.USE.LOAD: Load-Time Information</name>
<t>The manifest format MUST accommodate nested formats, announcing to the target <t>The manifest format <bcp14>MUST</bcp14> enable carrying additional
device all the nesting steps and any parameters used by those steps.</t> metadata for load-time processing of a payload, such as cryptographic informatio
n, load address, and compression algorithm. Note that load comes before executio
<t>Satisfies: <xref target="user-story-img-confidentiality">USER_STORY.IMG.CONFI n/boot.</t>
DENTIALITY</xref></t> <dl spacing="normal">
<dt>Satisfies:</dt><dd><xref target="user-story-exec-decompress" forma
<t>Implemented by: <xref target="manifest-element-processing-steps">Processing S t="default">USER_STORY.EXEC.DECOMPRESS</xref></dd>
teps</xref></t> <dt>Implemented by:</dt><dd><xref target="manifest-element-load-metada
ta" format="default">Load-Time Metadata</xref></dd>
</section> </dl>
<section anchor="req-use-img-versions" title="REQ.USE.IMG.VERSIONS: Target Versi </section>
on Matching"> <section anchor="req-use-payload" numbered="true" toc="default">
<name>REQ.USE.PAYLOAD: Payload in Manifest Envelope</name>
<t>The manifest format MUST provide a method to specify multiple version numbers <t>The manifest format <bcp14>MUST</bcp14> allow placing a payload in
of firmware to which the manifest applies, either with a list or with range mat the same structure as the manifest. This may place the payload in the same packe
ching.</t> t as the manifest.</t>
<t>Integrated payloads may include, for example, binaries as well as c
<t>Satisfies: <xref target="user-story-img-current-version">USER_STORY.IMG.CURRE onfiguration information, and keying material.</t>
NT_VERSION</xref></t> <t>When an integrated payload is provided, this increases the size of
the manifest. Manifest size can cause several processing and storage concerns th
<t>Implemented by: <xref target="element-required-version">Required Image Versio at require careful consideration. The payload can prevent the whole manifest fro
n List</xref></t> m 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
</section> reassembly and retransmission logic. The manifest <bcp14>MUST</bcp14> be held i
<section anchor="req-use-img-select" title="REQ.USE.IMG.SELECT: Select Image by mmutable between verification and processing (see <xref target="req-sec-mfst-con
Destination"> st" format="default">REQ.SEC.MFST.CONST</xref>), so a larger manifest will consu
me more memory with immutability guarantees -- for example, internal RAM or NVRA
<t>The manifest format MUST provide a mechanism to list multiple equivalent payl M, or external secure memory. If the manifest exceeds the available immutable me
oads by Execute-In-Place Installation Address, including the payload digest and, mory, then it <bcp14>MUST</bcp14> be processed modularly, evaluating each of the
optionally, payload URIs.</t> following: delegation chains; the security container; and the actual manifest,
which includes verifying the integrated payload. If the security model calls for
<t>Satisfies: <xref target="user-story-img-select">USER_STORY.IMG.SELECT</xref>< downloading the manifest and validating it before storing to NVRAM in order to
/t> prevent wear to NVRAM and energy expenditure in NVRAM, then either increasing me
mory allocated to manifest storage or modular processing of the received manifes
<t>Implemented by: <xref target="manifest-element-xip-address">XIP Address</xref t may be required. While the manifest has been organized to enable this type of
></t> processing, it creates additional complexity in the parser. If the manifest is s
tored in NVRAM prior to processing, the integrated payload may cause the manifes
</section> t to exceed the available storage. Because the manifest is received prior to val
<section anchor="req-use-exec" title="REQ.USE.EXEC: Executable Manifest"> idation of applicability, authority, or correctness, integrated payloads cause t
he recipient to expend network bandwidth and energy that may not be required if
<t>The manifest format MUST allow to describe an executable system with a manife the manifest is discarded, and these costs vary with the size of the integrated
st on both Execute-In-Place microcontrollers and on complex operating systems. I payload.</t>
n addition, the manifest format MUST be able to express metadata, such as a kern <dl spacing="normal">
el command-line, used by any loader or bootloader.</t> <dt>See also:</dt><dd><xref target="req-sec-mfst-const" format="defaul
t">REQ.SEC.MFST.CONST</xref></dd>
<t>Satisfies: <xref target="user-story-exec-mfst">USER_STORY.EXEC.MFST</xref></t <dt>Satisfies:</dt><dd><xref target="user-story-mfst-img" format="defa
> ult">USER_STORY.MFST.IMG</xref></dd>
<dt>Implemented by:</dt><dd><xref target="manifest-element-payload" fo
<t>Implemented by: <xref target="manifest-element-exec-metadata">Run-time metada rmat="default">Payload</xref></dd>
ta</xref></t> </dl>
</section>
</section> <section anchor="req-use-parse" numbered="true" toc="default">
<section anchor="req-use-load" title="REQ.USE.LOAD: Load-Time Information"> <name>REQ.USE.PARSE: Simple Parsing</name>
<t>The structure of the manifest <bcp14>MUST</bcp14> be simple to pars
<t>The manifest format MUST enable carrying additional metadata for load time pr e to reduce the attack vectors against manifest parsers.</t>
ocessing of a payload, such as cryptographic information, load-address, and comp <dl spacing="normal">
ression algorithm. Note that load comes before execution/boot.</t> <dt>Satisfies:</dt><dd><xref target="user-story-mfst-parse" format="de
fault">USER_STORY.MFST.PARSE</xref></dd>
<t>Satisfies: <xref target="user-story-exec-decompress">USER_STORY.EXEC.DECOMPRE <dt>Implemented by:</dt><dd>N/A</dd>
SS</xref></t> </dl>
</section>
<t>Implemented by: <xref target="manifest-element-load-metadata">Load-time metad <section anchor="req-use-delegation" numbered="true" toc="default">
ata</xref></t> <name>REQ.USE.DELEGATION: Delegation of Authority in Manifest</name>
<t>A manifest format <bcp14>MUST</bcp14> enable the delivery of delega
</section> tion information. This information delivers a new key with which the recipient c
<section anchor="req-use-payload" title="REQ.USE.PAYLOAD: Payload in Manifest En an verify the manifest.</t>
velope"> <dl spacing="normal">
<dt>Satisfies:</dt><dd><xref target="user-story-mfst-delegation" forma
<t>The manifest format MUST allow placing a payload in the same structure as the t="default">USER_STORY.MFST.DELEGATION</xref></dd>
manifest. This may place the payload in the same packet as the manifest.</t> <dt>Implemented by:</dt><dd><xref target="manifest-element-key-claims"
format="default">Delegation Chain</xref></dd>
<t>Integrated payloads may include, for example, binaries as well as configurati </dl>
on information, and keying material.</t> </section>
</section>
<t>When an integrated payload is provided, this increases the size of the manife </section>
st. Manifest size can cause several processing and storage concerns that require <section anchor="iana-considerations" numbered="true" toc="default">
careful consideration. The payload can prevent the whole manifest from being co <name>IANA Considerations</name>
ntained in a single network packet, which can cause fragmentation and the loss o <t>This document has no IANA actions.</t>
f portions of the manifest in lossy networks. This causes the need for reassembl </section>
y and retransmission logic. The manifest MUST be held immutable between verifica
tion and processing (see <xref target="req-sec-mfst-const">REQ.SEC.MFST.CONST</x
ref>), so a larger manifest will consume more memory with immutability guarantee
s, for example internal RAM or NVRAM, or external secure memory. If the manifest
exceeds the available immutable memory, then it MUST be processed modularly, ev
aluating each of: delegation chains, the security container, and the actual mani
fest, which includes verifying the integrated payload. If the security model cal
ls for downloading the manifest and validating it before storing to NVRAM in ord
er to prevent wear to NVRAM and energy expenditure in NVRAM, then either increas
ing memory allocated to manifest storage or modular processing of the received m
anifest may be required. While the manifest has been organised to enable this ty
pe of processing, it creates additional complexity in the parser. If the manifes
t is stored in NVRAM prior to processing, the integrated payload may cause the m
anifest to exceed the available storage. Because the manifest is received prior
to validation of applicability, authority, or correctness, integrated payloads c
ause the recipient to expend network bandwidth and energy that may not be requir
ed if the manifest is discarded and these costs vary with the size of the integr
ated 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 ve
ctors 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 Au
thority in Manifest">
<t>A manifest format MUST enable the delivery of delegation information. This in
formation delivers a new key with which the recipient can verify the manifest.</
t>
<t>Satisfies: <xref target="user-story-mfst-delegation">USER_STORY.MFST.DELEGATI
ON</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 an
d 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, Carst
en 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 infor
mation model. In particular, we would like to thank Milosch Meriac, Jean-Luc Gir
aud, Dan Ros, Amyas Philips, and Gary Thomson.</t>
<t>Finally, we would like to thank the following IESG members for their review f
eedback: Erik Kline, Murray Kucherawy, Barry Leiba, Alissa Cooper, Stephen Farre
ll and Benjamin Kaduk.</t>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4122.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8747.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8392.xml"/>
<references title='Normative References'> <!-- draft-ietf-suit-architecture (RFC 9019) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> FC.9019.xml"/>
<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 Comm
unity, 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 /></auth
or>
<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 UU
IDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDenti
fier). A UUID is 128 bits long, and can guarantee uniqueness across space and t
ime. UUIDs were originally used in the Apollo Network Computing System and late
r in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DC
E), 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 Th
e 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 /></auth
or>
<author initials='L.' surname='Seitz' fullname='L. Seitz'><organization /></auth
or>
<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'><organizatio
n /></author>
<date year='2020' month='March' />
<abstract><t>This specification describes how to declare in a CBOR Web Token (CW
T) (which is defined by RFC 8392) that the presenter of the CWT possesses a part
icular 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 equi
valent functionality to &quot;Proof-of-Possession Key Semantics for JSON Web Tok
ens (JWTs)&quot; (RFC 7800) but using Concise Binary Object Representation (CBOR
) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JW
Ts).</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 /></auth
or>
<author initials='E.' surname='Wahlstroem' fullname='E. Wahlstroem'><organizatio
n /></author>
<author initials='S.' surname='Erdtman' fullname='S. Erdtman'><organization /></
author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organizatio
n /></author>
<date year='2018' month='May' />
<abstract><t>CBOR Web Token (CWT) is a compact means of representing claims to b
e transferred between two parties. The claims in a CWT are encoded in the Conci
se Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (
COSE) is used for added application-layer security protection. A claim is a pie
ce of information asserted about a subject and is represented as a name/value pa
ir consisting of a claim name and a claim value. CWT is derived from JSON Web T
oken (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 n
eed for a reliable and secure firmware update mechanism suitable for devices wit
h resource constraints. Incorporating such an update mechanism is a fundamental
requirement for fixing vulnerabilities, but it also enables other important capa
bilities 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 trans
port-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-ar
chitecture-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 /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</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'><organ
ization /></author>
<date year='2003' month='January' />
<abstract><t>There has been ongoing confusion about the differences between Info
rmation Models and Data Models for defining managed objects in network managemen
t. 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 Mana
gement Task Force (DMTF)) fit into the universe of Information Models and Data M
odels. This memo documents the main results of the 8th workshop of the Network M
anagement Research Group (NMRG) of the Internet Research Task Force (IRTF) hoste
d 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/ee82
3878(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'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.8174.xml"/>
<title>Uniform Resource Identifier (URI): Generic Syntax</title> </references>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organizat <references>
ion /></author> <name>Informative References</name>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</author> FC.3444.xml"/>
<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 charac
ters that identifies an abstract or physical resource. This specification defin
es 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 u
se 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 possi
ble identifier. This specification does not define a generative grammar for URI
s; 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>
<reference anchor="STRIDE" target="https://docs.microsoft.com/en-us/prev
ious-versions/commerce-server/ee823878(v=cs.20)?redirectedfrom=MSDN">
<front>
<title>The STRIDE Threat Model</title>
<author>
<organization>Microsoft</organization>
</author>
<date year="2009" month="November"/>
</front>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3986.xml"/>
</references>
</references> </references>
<section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>We would like to thank our working group chairs -- <contact fullname="D
ave Thaler"/>, <contact fullname="Russ Housley"/>, and <contact fullname="David
Waltermire"/> -- for their review comments and their support.</t>
<t>We would like to thank the participants of the 2018 Berlin Software Upd
ates for Internet of Things (SUIT) Hackathon and the June 2018 virtual design te
am meetings for their discussion input.</t>
<t>In particular, we would like to thank <contact fullname="Koen Zandberg"
/>, <contact fullname="Emmanuel Baccelli"/>, <contact fullname="Carsten Bormann"
/>, <contact fullname="David Brown"/>, <contact fullname="Markus Gueller"/>, <co
ntact fullname="Frank Audun Kvamtrø"/>, <contact fullname="Øyvind Rønningstad"/>
, <contact fullname="Michael Richardson"/>, <contact fullname="Jan-Frederik Riec
kers"/>, <contact fullname="Francisco Acosta"/>, <contact fullname="Anton Gerasi
mov"/>,
<contact fullname="Matthias Wählisch"/>, <contact fullname="Max Gröning"/>, <con
tact fullname="Daniel Petry"/>, <contact fullname="Gaëtan Harter"/>, <contact fu
llname="Ralph Hamm"/>, <contact fullname="Steve Patrick"/>, <contact fullname="F
abio Utzig"/>, <contact fullname="Paul Lambert"/>, <contact fullname="Saïd Gharo
ut"/>, and <contact fullname="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 <contact fullname="Mil
osch Meriac"/>, <contact fullname="Jean-Luc Giraud"/>, <contact fullname="Dan Ro
s"/>, <contact fullname="Amyas Phillips"/>, and <contact fullname="Gary Thomson"
/>.</t>
<t>Finally, we would like to thank the following IESG members for their re
view feedback: <contact fullname="Erik Kline"/>, <contact fullname="Murray Kuche
rawy"/>, <contact fullname="Barry Leiba"/>, <contact fullname="Alissa Cooper"/>,
<contact fullname="Stephen Farrell"/>, and <contact fullname="Benjamin Kaduk"/>
.</t>
</section>
</back> </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> </rfc>
 End of changes. 20 change blocks. 
2675 lines changed or deleted 1960 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/