iot-nets.xml

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


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

]>

<?rfc rfcedstyle="yes"?>
<?rfc tocindent="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>
<?rfc docmapping="yes"?>
<?rfc toc_levels="4"?>

<rfc ipr="trust200902" docName="draft-ietf-iotops-security-summary-03" category="info" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="IoT networking security summary">A summary of security-enabling technologies for IoT devices</title>

    <author initials="B." surname="Moran" fullname="Brendan Moran">
      <organization>Arm Limited</organization>
      <address>
        <email>brendan.moran.ietf@gmail.com</email>
      </address>
    </author>

    <date year="2024" month="October" day="21"/>

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

    <abstract>


<t>The IETF has developed security technologies that help to secure the Internet of Things even over constrained networks and when targetting constrained nodes. These technologies can be used independenly or can be composed into larger systems to mitigate a variety of threats. This documents illustrates an overview over these technologies and highlights their relationships. Ultimately, a threat model is presented as a basis to derive requirements that interconnect existing and emerging solution technologies.</t>



    </abstract>



  </front>

  <middle>


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

<t>This memo serves as an entry-point to detail which technologies are available for use in IoT networks and to enable IoT designers to discover technologies that may solve their problems. This draft addresses.</t>

<t>Many baseline security requirements documents have been drafted by standards setting organisations, however these documents typically do not specify the technologies available to satisfy those requirements. They also do not express the next steps if an implementor wants to go above and beyond the baseline in order to differentiate their products and enable even better security. This memo defines the mapping from some IoT baseline security requirements definitions to ietf and related security technologies. It also highlights some gaps in those IoT baseline security requirements.</t>

</section>
<section anchor="conventions-and-terminology"><name>Conventions and Terminology</name>

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

</section>
<section anchor="survey-of-baseline-security-requirements"><name>Survey of baseline security requirements</name>

<t>At time of writing, there are IoT baseline security requirements provided by several organisations:</t>

<t><list style="symbols">
  <t>ENISA's Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures (<xref target="ENISA-Baseline"/>)</t>
  <t>ETSI's Cyber Security for Consumer Internet of Things: Baseline Requirements <xref target="ETSI-Baseline"/></t>
  <t>NIST's IoT Device Cybersecurity Capability Core Baseline <xref target="NIST-Baseline"/></t>
</list></t>

</section>
<section anchor="requirement-mapping"><name>Requirement Mapping</name>

<t>Requirements that pertain to hardware, procedure, and policy compliance are noted, but do not map to ietf and related technologies. NIST's requirements (<xref target="NIST-Baseline"/>) are very broad and already have mappings to ENISA baseline security recommendations.</t>

<section anchor="hardware-security"><name>Hardware Security</name>

<section anchor="identity"><name>Identity</name>

<t>ENISA GP-PS-10: Establish and maintain asset management procedures and configuration controls for key network and information systems.</t>

<t>NIST Device Identification: The IoT device can be uniquely identified logically and physically.</t>

<t>ETSI Provision 5.4-2: Where a hard-coded unique per device identity is used in a device for security purposes, it shall be implemented in such a way that it resists tampering by means such as physical, electrical or software.</t>

<t>These requirements are architectural requirements, however <xref target="RFC4122"/> can be used for identifiers.</t>

</section>
<section anchor="hardware-immutable-root-of-trust"><name>Hardware Immutable Root of Trust</name>

<t>ENISA GP-TM-01: Employ a hardware-based immutable root of trust.</t>

<t>This is an architectural requirement.</t>

</section>
<section anchor="hardware-backed-secret-storage"><name>Hardware-Backed Secret Storage</name>

<t>ENISA GP-TM-02: Use hardware that incorporates security features to strengthen the protection and integrity of the device - for example, specialized security chips / coprocessors that integrate security at the transistor level, embedded in the processor, providing, among other things, a trusted storage of device identity and authentication means, protection of keys at rest and in use, and preventing unprivileged from accessing to security sensitive code. Protection against local and physical attacks can be covered via functional security.</t>

<t>NIST Data Protection: The ability to use demonstrably secure cryptographic modules for standardized cryptographic algorithms (e.g., encryption with authentication, cryptographic hashes, digital signature validation) to prevent the confidentiality and integrity of the device’s stored and transmitted data from being compromised</t>

<t>ETSI Provision 5.4-1: Sensitive security parameters in persistent storage shall be stored securely by the device.</t>

<t>This is an architectural requirement.</t>

</section>
</section>
<section anchor="software-integrity-authenticity"><name>Software Integrity &amp; Authenticity</name>

<section anchor="boot-environment-trustworthiness-and-integrity"><name>Boot Environment Trustworthiness and Integrity</name>

<t>ENISA GP-TM-03: Trust must be established in the boot environment before any trust in any other software or executable program can be claimed.</t>

<t>ETSI defines the following boot environment requirements:</t>

<t><list style="symbols">
  <t>Provision 5.7-1: The consumer IoT device should verify its software using secure boot mechanisms.</t>
</list></t>

<t>Satisfying this requirement can be done in several ways, increasing in security guarantees:</t>

<t><list style="numbers">
  <t>Implement secure boot to verify the bootloader and boot environment. Trust is established purely by construction: if code is running in the boot environment, it must have been signed, therefore it is trustworthy.</t>
  <t>Record critical measurements of each step of boot in a TPM. Trust is established by evaluating the measurements recorded by the TPM.</t>
  <t>Use Remote Attestation. Remote attestation allows a device to report to third parties the critical measurements it has recorded (either in a TPM or signed by each stage) in order to prove the trustworthiness of the boot environment and running software. Remote Attestation is implemented in <xref target="I-D.ietf-rats-eat"/>.</t>
</list></t>

</section>
<section anchor="code-integrity-and-authenticity"><name>Code Integrity and Authenticity</name>

<t>ENISA GP-TM-04: Sign code cryptographically to ensure it has not been tampered with after signing it as safe for the device, and implement run-time protection and secure execution monitoring to make sure malicious attacks do not overwrite code after it is loaded.</t>

<t>Satisfying this requirement requires a secure invocation mechanism. In monolithic IoT software images, this is accomplished by Secure Boot. In IoT devices with more fully-featured operating systems, this is accomplished with an operating system-specific code signing practice.</t>

<t>Secure Invocation can be achieved using the SUIT Manifest format, which provides for secure invocation procedures. See <xref target="I-D.ietf-suit-manifest"/>.</t>

<t>To satisfy the associated requirement of run-time protection and secure execution monitoring, the use of a TEE is recommended to protect sensitive processes. The TEEP protocol (see <xref target="I-D.ietf-teep-architecture"/>) is recommended for managing TEEs.</t>

</section>
<section anchor="secure-softwarefirmware-update"><name>Secure Software/Firmware Update</name>

<t>Technical requirements for Software Updates are provided for in the SUIT information model (<xref target="RFC9124"/>) and TEEP Architecture (<xref target="RFC9397"/>). Procedural and architectural requirements should be independently assessed by the implementor.</t>

<t>ENISA Software Update Requirements:</t>

<t><list style="symbols">
  <t>GP-TM-05: Control the installation of software in operating systems, to prevent unauthenticated software and files from being loaded onto it.</t>
  <t>GP-TM-18: Ensure that the device software/firmware, its configuration and its applications have the ability to update Over-The-Air (OTA), that the update server is secure, that the update file is transmitted via a secure connection, that it does not contain sensitive data (e.g. hardcoded credentials), that it is signed by an authorised trust entity and encrypted using accepted encryption methods, and that the update package has its digital signature, signing certificate and signing certificate chain, verified by the device before the update process begins.</t>
  <t>GP-TM-19: Offer an automatic firmware update mechanism.</t>
  <t>GP-TM-20: (Procedural / Architectural) Backward compatibility of firmware updates. Automatic firmware updates should not modify user-configured preferences, security, and/or privacy settings without user notification.</t>
</list></t>

<t>NIST Software Update:</t>

<t><list style="numbers">
  <t>The ability to update the device’s software through remote (e.g., network download) and/or local means (e.g., removable media)</t>
  <t>The ability to verify and authenticate any update before installing it</t>
  <t>The ability for authorized entities to roll back updated software to a previous version</t>
  <t>The ability to restrict updating actions to authorized entities only</t>
  <t>The ability to enable or disable updating</t>
  <t>Configuration settings for use with the Device Configuration capability including, but not limited to:</t>
  <t>The ability to configure any remote update mechanisms to be either automatically or manually initiated for update downloads and installations</t>
  <t>The ability to enable or disable notification when an update is available and specify who or what is to be notified</t>
</list></t>

<t>ETSI Keep Software Updated:</t>

<t><list style="symbols">
  <t>Provision 5.3-1 All software components in consumer IoT devices should be securely updateable.</t>
  <t>Provision 5.3-2 When the device is not a constrained device, it shall have an update mechanism for the secure installation of updates.</t>
  <t>Provision 5.3-3 An update shall be simple for the user to apply.</t>
  <t>Provision 5.3-4 Automatic mechanisms should be used for software updates.</t>
  <t>Provision 5.3-5 The device should check after initialization, and then periodically, whether security updates are available.</t>
  <t>Provision 5.3-6 If the device supports automatic updates and/or update notifications, these should be enabled in the initialized state and configurable so that the user can enable, disable, or postpone installation of security updates and/or update notifications.</t>
  <t>Provision 5.3-7 The device shall use best practice cryptography to facilitate secure update mechanisms.</t>
  <t>Provision 5.3-8 Security updates shall be timely.</t>
  <t>Provision 5.3-9 The device should verify the authenticity and integrity of software updates.</t>
  <t>Provision 5.3-10 Where updates are delivered over a network interface, the device shall verify the authenticity and integrity of each update via a trust relationship.</t>
  <t>Provision 5.3-11 The manufacturer should inform the user in a recognizable and apparent manner that a security update is required together with information on the risks mitigated by that update.</t>
  <t>Provision 5.3-12 The device should notify the user when the application of a software update will disrupt the basic functioning of the device.</t>
  <t>Provision 5.3-13 The manufacturer shall publish, in an accessible way that is clear and transparent to the user, the defined support period.</t>
  <t>Provision 5.3-14 For constrained devices that cannot have their software updated, the rationale for the absence of software updates, the period and method of hardware replacement support and a defined support period should be published by the manufacturer in an accessible way that is clear and transparent to the user.</t>
  <t>Provision 5.3-15 For constrained devices that cannot have their software updated, the product should be isolable and the hardware replaceable.</t>
  <t>Provision 5.3-16 The model designation of the consumer IoT device shall be clearly recognizable, either by labelling on the device or via a physical interface.</t>
  <t>Provision 5.5-3 Cryptographic algorithms and primitives should be updateable.</t>
</list></t>

<t>Many fully-featured operating systems have dedicated means of implementing this requirement. The SUIT manifest (See <xref target="I-D.ietf-suit-manifest"/>) is recommended as a means of providing secure, authenticated software update, including for constrained devices. Where the software is deployed to a TEE, TEEP (See <xref target="I-D.ietf-teep-protocol"/>) is recommended for software update and management.</t>

</section>
<section anchor="configuration"><name>Configuration</name>

<t>NIST Device Configuration:</t>

<t><list style="numbers">
  <t>The ability to change the device’s software configuration settings</t>
  <t>The ability to restrict configuration changes to authorized entities only</t>
  <t>The ability for authorized entities to restore the device to a secure configuration defined by an authorized entity</t>
</list></t>

<t>ETSI defines the following configuration requirements:</t>

<t><list style="symbols">
  <t>Provision 5.12-1: Installation and maintenance of consumer IoT should involve minimal decisions by the user and should follow security best practice on usability.</t>
  <t>Provision 5.12-2 The manufacturer should provide users with guidance on how to securely set up their device.</t>
  <t>Provision 5.12-3 The manufacturer should provide users with guidance on how to check whether their device is securely set up.</t>
</list></t>

<t>Configuration can be delivered to a device either via a firmware update, such as in <xref target="I-D.ietf-suit-manifest"/>, or via a runtime configuration interface, such as <xref target="LwM2M"/>.</t>

</section>
<section anchor="resilience-to-failure"><name>Resilience to Failure</name>

<t>ENISA GP-TM-06: Enable a system to return to a state that was known to be secure, after a security breach has occured or if an upgrade has not been successful.</t>

<t>ETSI defines the following resilience requirements:</t>

<t><list style="symbols">
  <t>Provision 5.9-1: Resilience should be built in to consumer IoT devices and services, taking into account the possibility of outages of data networks and power.</t>
  <t>Provision 5.9-2: Consumer IoT devices should remain operating and locally functional in the case of a loss of network access and should recover cleanly in the case of restoration of a loss of power.</t>
  <t>Provision 5.9-3: The consumer IoT device should connect to networks in an expected, operational and stable state and in an orderly fashion, taking the capability of the infrastructure into consideration.</t>
</list></t>

<t>While there is no specificaiton for this, it is also required in <xref target="RFC9019"/></t>

</section>
<section anchor="trust-anchor-management"><name>Trust Anchor Management</name>

<t>ENISA GP-TM-07: Use protocols and mechanisms able to represent and manage trust and trust relationships.</t>

<t>EST (<eref target="https://datatracker.ietf.org/doc/html/rfc7030"/>) and LwM2M Bootstrap (<xref target="LwM2M"/>) provide a mechanism to replace trust anchors (manage trust/trust relationships).</t>

</section>
</section>
<section anchor="default-security-privacy"><name>Default Security &amp; Privacy</name>

<section anchor="security-on-by-default"><name>Security ON by Default</name>

<t>ENISA GP-TM-08: Any applicable security features should be enabled by default, and any unused or insecure functionalities should be disabled by default.</t>

<t>NIST Logical Access to Interfaces:</t>

<t><list style="numbers">
  <t>The ability to logically or physically disable any local and network interfaces that are not necessary for the core functionality of the device</t>
  <t>The ability to logically restrict access to each network interface to only authorized entities (e.g., device authentication, user authentication)</t>
  <t>Configuration settings for use with the Device Configuration capability including, but not limited to, the ability to enable, disable, and adjust thresholds for any ability the device might have to lock or disable an account or to delay additional authentication attempts after too many failed authentication attempts</t>
</list></t>

<t>ETSI Minimize exposed attack surfaces:</t>

<t><list style="symbols">
  <t>Provision 5.6-1: All unused network and logical interfaces shall be disabled.</t>
  <t>Provision 5.6-2: In the initialized state, the network interfaces of the device shall minimize the unauthenticated disclosure of security-relevant information.</t>
  <t>Provision 5.6-5: The manufacturer should only enable software services that are used or required for the intended use or operation of the device.</t>
  <t>Provision 5.6-6: Code should be minimized to the functionality necessary for the service/device to operate.</t>
  <t>Provision 5.6-7: Software should run with least necessary privileges, taking account of both security and functionality.</t>
</list></t>

<t>These are procedural requirements, rather than a protocol or document requirement.</t>

</section>
<section anchor="default-unique-passwords"><name>Default Unique Passwords</name>

<t>ENISA GP-TM-09: Establish hard to crack, device-individual default passwords.</t>

<t>ETSI Provision 5.1-1: Where passwords are used and in any state other than the factory default, all consumer IoT device passwords shall be unique per device or defined by the user.</t>

<t>This is a procedural requirement, rather than a protocol or document requirement.</t>

</section>
</section>
<section anchor="data-protection"><name>Data Protection</name>

<t>The data protection requirements are largely procedural/architectural. While this memo can recommend using TEEs to protect data, and TEEP (<xref target="I-D.ietf-teep-architecture"/>) to manage TEEs, implementors must choose to architect their software in such a way that TEEs are helpful in meeting these requirements.</t>

<t>ENISA Data Protection requirements:</t>

<t><list style="symbols">
  <t>GP-TM-10: Personal data must be collected and processed fairly and lawfully, it should never be collected and processed without the data subject's consent.</t>
  <t>GP-TM-11: Make sure that personal data is used for the specified purposes for which they were collected, and that any further processing of personal data is compatible and that the data subjects are well informed.</t>
  <t>GP-TM-12: Minimise the data collected and retained.</t>
  <t>GP-TM-13: IoT stakeholders must be compliant with the EU General Data Protection Regulation (GDPR).</t>
  <t>GP-TM-14: Users of IoT products and services must be able to exercise their rights to information, access, erasure, rectification, data portability, restriction of processing, objection to processing, and their right not to be evaluated on the basis of automated processing.</t>
</list></t>

<t>NIST Data Protection:</t>

<t><list style="numbers">
  <t>The ability to use demonstrably secure cryptographic modules for standardized cryptographic algorithms (e.g., encryption with authentication, cryptographic hashes, digital signature validation) to prevent the confidentiality and integrity of the device’s stored and transmitted data from being compromised</t>
  <t>The ability for authorized entities to render all data on the device inaccessible by all entities, whether previously authorized or not (e.g., through a wipe of internal storage, destruction of cryptographic keys for encrypted data)</t>
  <t>Configuration settings for use with the Device Configuration capability including, but not limited to, the ability for authorized entities to configure the cryptography use itself, such as choosing a key length</t>
</list></t>

<t>ETSI Data Protection requirements:</t>

<t><list style="symbols">
  <t>Provision 5.8-3: All external sensing capabilities of the device shall be documented in an accessible way that is clear and transparent for the user.</t>
  <t>Provision 5.11-1: The user shall be provided with functionality such that user data can be erased from the device in a simple manner.</t>
  <t>Provision 5.11-2: The consumer should be provided with functionality on the device such that personal data can be removed from associated services in a simple manner.</t>
  <t>Provision 5.11-3: Users should be given clear instructions on how to delete their personal data.</t>
  <t>Provision 5.11-4: Users should be provided with clear confirmation that personal data has been deleted from services, devices and applications.</t>
  <t>Provision 6-1: The manufacturer shall provide consumers with clear and transparent information about what personal data is processed, how it is being used, by whom, and for what purposes, for each device and service. This also applies to third parties that can be involved, including advertisers.</t>
  <t>Provision 6-2: Where personal data is processed on the basis of consumers' consent, this consent shall be obtained in a valid way.</t>
  <t>Provision 6-3: Consumers who gave consent for the processing of their personal data shall have the capability to withdraw it at any time.</t>
  <t>Provision 6-4: If telemetry data is collected from consumer IoT devices and services, the processing of personal data should be kept to the minimum necessary for the intended functionality.</t>
  <t>Provision 6-5: If telemetry data is collected from consumer IoT devices and services, consumers shall be provided with information on what telemetry data is collected, how it is being used, by whom, and for what purposes.</t>
</list></t>

</section>
<section anchor="system-safety-and-reliability"><name>System Safety and Reliability</name>

<t>Safety and reliability requirements are procedural/architectural. Implementors should ensure they have processes and architectures in place to meet these requirements.</t>

<t>ENISA Safety and Reliability requirements:</t>

<t><list style="symbols">
  <t>GP-TM-15: Design with system and operational disruption in mind, preventing the system from causing an unacceptable risk of injury or physical damage.</t>
  <t>GP-TM-16: Mechanisms for self-diagnosis and self-repair/healing to recover from failure, malfunction or a compromised state.</t>
  <t>GP-TM-17: Ensure standalone operation - essential features should continue to work with a loss of communications and chronicle negative impacts from compromised devices or cloud-based systems.</t>
</list></t>

</section>
<section anchor="authentication"><name>Authentication</name>

<t>ETSI architectural requirements:</t>

<t><list style="symbols">
  <t>Provision 5.1-4 Where a user can authenticate against a device, the device shall provide to the user or an administrator a simple mechanism to change the authentication value used.</t>
  <t>Provision 5.1-5 When the device is not a constrained device, it shall have a mechanism available which makes brute-force attacks on authentication mechanisms via network interfaces impracticable.</t>
</list></t>

<t>EST (<eref target="https://datatracker.ietf.org/doc/html/rfc7030"/>) and LwM2M Bootstrap (<xref target="LwM2M"/>) provide a mechanism to replace trust anchors (manage trust/trust relationships) and perform other forms of credential management (Provision 5.1-4).</t>

<section anchor="align-authentication-schemes-with-threat-models"><name>Align Authentication Schemes with Threat Models</name>

<t>ENISA GP-TM-21: Design the authentication and authorisation schemes (unique per device) based on the system-level threat models.</t>

<t>This is a procedural / architectural requirement.</t>

</section>
<section anchor="password-rules"><name>Password Rules</name>

<t>ENISA applies the following requirements to Password-based authentication:</t>

<t><list style="symbols">
  <t>GP-TM-22: Ensure that default passwords and even default usernames are changed during the initial setup, and that weak, null or blank passwords are not allowed.</t>
  <t>GP-TM-23: Authentication mechanisms must use strong passwords or personal identification numbers (PINs), and should consider using two-factor authentication (2FA) or multi-factor authentication (MFA) like Smartphones, Biometrics, etc., on top of certificates.</t>
  <t>GP-TM-24: Authentication credentials shall be salted, hashed and/or encrypted.</t>
  <t>GP-TM-25: Protect against 'brute force' and/or other abusive login attempts. This protection should also consider keys stored in devices.</t>
  <t>GP-TM-26: Ensure password recovery or reset mechanism is robust and does not supply an attacker with information indicating a valid account. The same applies to key update and recovery mechanisms.</t>
</list></t>

<t>ETSI applies a the following requirements to password-based authentication:</t>

<t><list style="symbols">
  <t>Provision 5.1-1: Where passwords are used and in any state other than the factory default, all consumer IoT device passwords shall be unique per device or defined by the user.</t>
  <t>Provision 5.1-2 Where pre-installed unique per device passwords are used, these shall be generated with a mechanism that reduces the risk of automated attacks against a class or type of device.</t>
</list></t>

<t>As an alternative, implementors are encouraged to consider passwordless schemes, such as FIDO.</t>

</section>
</section>
<section anchor="authorisation"><name>Authorisation</name>

<section anchor="principle-of-least-privilege"><name>Principle of Least Privilege</name>

<t>ENISA GP-TM-27: Limit the actions allowed for a given system by Implementing fine-grained authorisation mechanisms and using the Principle of least privilege (POLP): applications must operate at the lowest privilege level possible.</t>

<t>This is a procedural / architectural requirement, however at the network level, this can be implemented using Manufacturer Usage Descriptions (see <xref target="RFC8520"/>).</t>

</section>
<section anchor="software-isolation"><name>Software Isolation</name>

<t>ENISA GP-TM-28: Device firmware should be designed to isolate privileged code, processes and data from portions of the firmware that do not need access to them. Device hardware should provide isolation concepts to prevent unprivileged from accessing security sensitive code.</t>

<t>Implementors should use TEEs to address this requirement. The provisioning and management of TEEs can be accomplished using TEEP (see <xref target="I-D.ietf-teep-architecture"/>).</t>

<t>ETSI Provision 5.6-8: The device should include a hardware-level access control mechanism for memory.</t>

<t>Implementors should enable and correctly configure the MPU(s) and MMU(s) that are present in most devices.</t>

</section>
<section anchor="access-control"><name>Access Control</name>

<t>ENISA Requirements:</t>

<t><list style="symbols">
  <t>GP-TM-29: Data integrity and confidentiality must be enforced by access controls. When the subject requesting access has been authorised to access particular processes, it is necessary to enforce the defined security policy.</t>
  <t>GP-TM-30: Ensure a context-based security and privacy that reflects different levels of importance.</t>
</list></t>

<t>These requirements are complex and require a variety of technologies to implement. Use of TEEs can provide a building block for these requirements, but is not sufficient in itself to meet these requiremnents.</t>

<t>ETSI Requirements:</t>

<t><list style="symbols">
  <t>Provision 5.5-4: Access to device functionality via a network interface in the initialized state should only be possible after authentication on that interface.</t>
  <t>Provision 5.5-5: Device functionality that allows security-relevant changes in configuration via a network interface shall only be accessible after authentication. The exception is for network service protocols that are relied upon by the device and where the manufacturer cannot guarantee what configuration will be required for the device to operate.</t>
  <t>Provision 5.5-5: Device functionality that allows security-relevant changes in configuration via a network interface shall only be accessible after authentication. The exception is for network service protocols that are relied upon by the device and where the manufacturer cannot guarantee what configuration will be required for the device to operate.</t>
</list></t>

</section>
</section>
<section anchor="environmental-and-physical-security"><name>Environmental and Physical Security</name>

<t>ENISA defines the following physical security requirements. These are hardware-architectural requirements and not covered by protocol and format specifications.</t>

<t><list style="symbols">
  <t>GP-TM-31: Measures for tamper protection and detection. Detection and reaction to hardware
tampering should not rely on network connectivity.</t>
  <t>GP-TM-32: Ensure that the device cannot be easily disassembled and that the data storage medium is encrypted at rest and cannot be easily removed.</t>
  <t>GP-TM-33: Ensure that devices only feature the essential physical external ports (such as USB) necessary for them to function and that the test/debug modes are secure, so they cannot be used to maliciously access the devices. In general, lock down physical ports to only trusted connections.</t>
</list></t>

<t>ETSI defines the following physical security requirements:</t>

<t><list style="symbols">
  <t>Provision 5.6-3: Device hardware should not unnecessarily expose physical interfaces to attack.</t>
  <t>Provision 5.6-4: Where a debug interface is physically accessible, it shall be disabled in software.</t>
</list></t>

</section>
<section anchor="cryptography"><name>Cryptography</name>

<t>ENISA makes the following architectural cryptography requirements for IoT devices:</t>

<t><list style="symbols">
  <t>GP-TM-34: Ensure a proper and effective use of cryptography to protect the confidentiality, authenticity and/or integrity of data and information (including control messages), in transit and in rest. Ensure the proper selection of standard and strong encryption algorithms and strong keys, and disable insecure protocols. Verify the robustness of the implementation.</t>
  <t>GP-TM-35: Cryptographic keys must be securely managed.</t>
  <t>GP-TM-36: Build devices to be compatible with lightweight encryption and security techniques.</t>
  <t>GP-TM-37: Support scalable key management schemes.</t>
</list></t>

<t>ETSI makes the following architectural cryptography requirement for IoT devices:</t>

<t><list style="symbols">
  <t>Provision 5.1-3: Authentication mechanisms used to authenticate users against a device shall use best practice cryptography, appropriate to the properties of the technology, risk and usage.</t>
  <t>Provision 5.4-3: Hard-coded critical security parameters in device software source code shall not be used.</t>
  <t>Provision 5.4-4: Any critical security parameters used for integrity and authenticity checks of software updates and for protection of communication with associated services in device software shall be unique per device and shall be produced with a mechanism that reduces the risk of automated attacks against classes of devices.</t>
  <t>Provision 5.5-3: Cryptographic algorithms and primitives should be updateable.</t>
</list></t>

</section>
<section anchor="secure-and-trusted-communications"><name>Secure and Trusted Communications</name>

<section anchor="data-security"><name>Data Security</name>

<t>ENISA GP-TM-38: Guarantee the different security aspects -confidentiality (privacy), integrity, availability and authenticity- of the information in transit on the networks or stored in the IoT application or in the Cloud.</t>

<t>ETSI Data Security Requirements:</t>

<t><list style="symbols">
  <t>Provision 5.5-6: Critical security parameters should be encrypted in transit, with such encryption appropriate to the properties of the technology, risk and usage.</t>
  <t>Provision 5.5-7 The consumer IoT device shall protect the confidentiality of critical security parameters that are communicated via remotely accessible network interfaces.</t>
  <t>Provision 5.5-8 The manufacturer shall follow secure management processes for critical security parameters that relate to the device.</t>
  <t>Provision 5.8-1 The confidentiality of personal data transiting between a device and a service, especially associated services, should be protected, with best practice cryptography.</t>
  <t>Provision 5.8-2 The confidentiality of sensitive personal data communicated between the device and associated services shall be protected, with cryptography appropriate to the properties of the technology and usage.</t>
</list></t>

<t>This Data Security requirement can be fulfilled using COSE <xref target="RFC8152"/> for ensuring the authenticity, integrity, and confidentiality of data either in transit or at rest. Secure Transport (see <xref target="secure-transport"/>) technologies can be used to protect data in transit.</t>

</section>
<section anchor="secure-transport"><name>Secure Transport</name>

<t>ENISA Requirements:</t>

<t><list style="symbols">
  <t>GP-TM-39: Ensure that communication security is provided using state-of-the-art, standardised security protocols, such as TLS for encryption.</t>
  <t>GP-TM-40: Ensure credentials are not exposed in internal or external network traffic.</t>
</list></t>

<t>ETSI Requirements:</t>

<t><list style="symbols">
  <t>Provision 5.5-1: The consumer IoT device shall use best practice cryptography to communicate securely.</t>
  <t>Provision 5.5-2: The consumer IoT device should use reviewed or evaluated implementations to deliver network and security functionalities, particularly in the field of cryptography.</t>
  <t>Provision 5.5-4: Access to device functionality via a network interface in the initialized state should only be possible after authentication on that interface.</t>
</list></t>

<t>This requirement is satisfied by several standards:</t>

<t><list style="symbols">
  <t>TLS (<xref target="RFC8446"/>).</t>
  <t>DTLS (<xref target="RFC9147"/>).</t>
  <t>QUIC (<xref target="RFC9000"/>).</t>
  <t>OSCORE (<xref target="RFC9203"/>).</t>
</list></t>

</section>
<section anchor="data-authenticity"><name>Data Authenticity</name>

<t>ENISA GP-TM-41: Guarantee data authenticity to enable reliable exchanges from data emission to data reception. Data should always be signed whenever and wherever it is captured and stored.</t>

<t>The authenticity of data can be protected using COSE <xref target="RFC8152"/>.</t>

<t>ENISA GP-TM-42: Do not trust data received and always verify any interconnections. Discover, identify and verify/authenticate the devices connected to the network before trust can be established, and preserve
their integrity for reliable solutions and services.</t>

<t>Verifying communication partners can be done in many ways. Key technologies supporting authentication of communication partners are:</t>

<t><list style="symbols">
  <t>RATS: Remote attestation of a communication partner (See <xref target="I-D.ietf-rats-architecture"/>).</t>
  <t>TLS/DTLS: Mutual authentication of communication partners (See <xref target="RFC8446"/> / <xref target="RFC9147"/>).</t>
  <t>ATLS: Application-layer TLS for authenticating a connection that may traverse multiple secure transport connections.</t>
  <t>Attested TLS: The use of attestation in session establishment in TLS (See <xref target="I-D.fossati-tls-attestation"/>).</t>
</list></t>

</section>
<section anchor="least-privilege-communication"><name>Least Privilege Communication</name>

<t>ENISA GP-TM-43: IoT devices should be restrictive rather than permissive in communicating.</t>

<t>This Requirement can be enabled and enforced using Manufacturer Usage Descriptions, which codify expected communication (See <xref target="RFC8520"/>)</t>

<t>ENISA GP-TM-44: Make intentional connections. Prevent unauthorised connections to it or other devices the
product is connected to, at all levels of the protocols.</t>

<t>This requirement can be satisfied through authenticating connections (TLS / DTLS mutual authentication. See <xref target="RFC8446"/> / <xref target="RFC9147"/>) and declaring communication patterns (Manufacturer Usage Descriptions. See <xref target="RFC8520"/>)</t>

<t>Architectural / Procedural requirements:</t>

<t><list style="symbols">
  <t>ENISA GP-TM-45: Disable specific ports and/or network connections for selective connectivity.</t>
  <t>ENISA GP-TM-46: Rate limiting. Controlling the traffic sent or received by a network to reduce the risk of automated attacks.</t>
</list></t>

</section>
</section>
<section anchor="secure-interfaces-and-network-services"><name>Secure Interfaces and network services</name>

<t>ENISA Architectural / Procedural requirements:</t>

<t><list style="symbols">
  <t>GP-TM-47: Risk Segmentation. Splitting network elements into separate components to help isolate security breaches and minimise the overall risk.</t>
  <t>GP-TM-48: Protocols should be designed to ensure that, if a single device is compromised, it does not affect the whole set.</t>
  <t>GP-TM-49: Avoid provisioning the same secret key in an entire product family, since compromising a single device would be enough to expose the rest of the product family.</t>
  <t>GP-TM-50: Ensure only necessary ports are exposed and available.</t>
  <t>GP-TM-51: Implement a DDoS-resistant and Load-Balancing infrastructure.</t>
  <t>GP-TM-53: Avoid security issues when designing error messages.</t>
</list></t>

<t>ETSI Architectural requirements:</t>

<t><list style="symbols">
  <t>Provision 5.1-5 When the device is not a constrained device, it shall have a mechanism available which makes brute-force attacks on authentication mechanisms via network interfaces impracticable.</t>
</list></t>

<section anchor="encrypted-user-sessions"><name>Encrypted User Sessions</name>

<t>ENISA GP-TM-52: Ensure web interfaces fully encrypt the user session, from the device to the backend services, and that they are not susceptible to XSS, CSRF, SQL injection, etc.</t>

<t>This requirement can be partially satisfied through use of TLS or QUIC (See <xref target="RFC8446"/> and <xref target="RFC9000"/>)</t>

</section>
</section>
<section anchor="secure-input-and-output-handling"><name>Secure input and output handling</name>

<t>Architectural / Procedural requirements:</t>

<t>ENISA GP-TM-54: Data input validation (ensuring that data is safe prior to use) and output filtering.</t>

<t>ETSI Provision 5.13-1: The consumer IoT device software shall validate data input via user interfaces or transferred via Application Programming Interfaces (APIs) or between networks in services and devices.</t>

</section>
<section anchor="logging"><name>Logging</name>

<t>Architectural / Procedural requirements:</t>

<t>ENISA GP-TM-55: Implement a logging system that records events relating to user authentication, management of accounts and access rights, modifications to security rules, and the functioning of the system. Logs must be preserved on durable storage and retrievable via authenticated connections.</t>

<t>NIST Cybersecurity State Awareness</t>

<t><list style="numbers">
  <t>The ability to report the device’s cybersecurity state</t>
  <t>The ability to differentiate between when a device will likely operate as expected from when it may be in a degraded cybersecurity state</t>
  <t>The ability to restrict access to the state indicator so only authorized entities can view it</t>
  <t>The ability to prevent any entities (authorized or unauthorized) from editing the state except for those entities that are responsible for maintaining the device’s state information</t>
  <t>The ability to make the state information available to a service on another device, such as an event/state log server</t>
</list></t>

<t>ETSI defines the following logging requirements:</t>

<t><list style="symbols">
  <t>Provision 5.7-2: If an unauthorized change is detected to the software, the device should alert the user and/or administrator to the issue and should not connect to wider networks than those necessary to perform the alerting function.</t>
</list></t>

<t>Certain logs and indicators of cybersecurity state can be transported via RATS: See <xref target="I-D.ietf-rats-eat"/>. Where associated with SUIT firmware updates, logs can be transported using SUIT Reports. See <xref target="I-D.ietf-suit-report"/>.</t>

</section>
<section anchor="monitoring-and-auditing"><name>Monitoring and Auditing</name>

<t>ENISA Architectural / Procedural requirements:</t>

<t><list style="symbols">
  <t>ENISA GP-TM-56: Implement regular monitoring to verify the device behaviour, to detect malware and to discover integrity errors.</t>
  <t>ENISA GP-TM-57: Conduct periodic audits and reviews of security controls to ensure that the controls are effective. Perform penetration tests at least biannually.</t>
</list></t>

<t>ETSI Architectural / Procedural requirements:</t>

<t><list style="symbols">
  <t>Provision 5.2-1: The manufacturer shall make a vulnerability disclosure policy publicly available.</t>
  <t>Provision 5.2-2: Disclosed vulnerabilities should be acted on in a timely manner.</t>
  <t>Provision 5.2-3: Manufacturers should continually monitor for, identify and rectify security vulnerabilities within products and services they sell, produce, have produced and services they operate during the defined support period.</t>
  <t>Provision 5.6-9: The manufacturer should follow secure development processes for software deployed on the device.</t>
  <t>Provision 5.10-1 If telemetry data is collected from consumer IoT devices and services, such as usage and measurement data, it should be examined for security anomalies.</t>
</list></t>

<t>Supply Chain Integrity, Transparency, and Trust (<xref target="I-D.ietf-scitt-architecture"/>) enables monitoring for inclusion of disclosed vulnerabilities within products and services, so can be used to satisfy Provision 5.2-3.</t>

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

<t>No additional security considerations are required; they are laid out in the preceeding sections.</t>

</section>


  </middle>

  <back>


    <references title='Normative References'>



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

<reference anchor='RFC8520'>
  <front>
    <title>Manufacturer Usage Description Specification</title>
    <author fullname='E. Lear' initials='E.' surname='Lear'/>
    <author fullname='R. Droms' initials='R.' surname='Droms'/>
    <author fullname='D. Romascanu' initials='D.' surname='Romascanu'/>
    <date month='March' year='2019'/>
    <abstract>
      <t>This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.</t>
      <t>This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='8520'/>
  <seriesInfo name='DOI' value='10.17487/RFC8520'/>
</reference>

<reference anchor='RFC8995'>
  <front>
    <title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title>
    <author fullname='M. Pritikin' initials='M.' surname='Pritikin'/>
    <author fullname='M. Richardson' initials='M.' surname='Richardson'/>
    <author fullname='T. Eckert' initials='T.' surname='Eckert'/>
    <author fullname='M. Behringer' initials='M.' surname='Behringer'/>
    <author fullname='K. Watsen' initials='K.' surname='Watsen'/>
    <date month='May' year='2021'/>
    <abstract>
      <t>This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='8995'/>
  <seriesInfo name='DOI' value='10.17487/RFC8995'/>
</reference>

<reference anchor='RFC7030'>
  <front>
    <title>Enrollment over Secure Transport</title>
    <author fullname='M. Pritikin' initials='M.' role='editor' surname='Pritikin'/>
    <author fullname='P. Yee' initials='P.' role='editor' surname='Yee'/>
    <author fullname='D. Harkins' initials='D.' role='editor' surname='Harkins'/>
    <date month='October' year='2013'/>
    <abstract>
      <t>This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='7030'/>
  <seriesInfo name='DOI' value='10.17487/RFC7030'/>
</reference>

<reference anchor='RFC8446'>
  <front>
    <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
    <author fullname='E. Rescorla' initials='E.' surname='Rescorla'/>
    <date month='August' year='2018'/>
    <abstract>
      <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
      <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='8446'/>
  <seriesInfo name='DOI' value='10.17487/RFC8446'/>
</reference>

<reference anchor='RFC9019'>
  <front>
    <title>A Firmware Update Architecture for Internet of Things</title>
    <author fullname='B. Moran' initials='B.' surname='Moran'/>
    <author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'/>
    <author fullname='D. Brown' initials='D.' surname='Brown'/>
    <author fullname='M. Meriac' initials='M.' surname='Meriac'/>
    <date month='April' year='2021'/>
    <abstract>
      <t>Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality.</t>
      <t>In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='9019'/>
  <seriesInfo name='DOI' value='10.17487/RFC9019'/>
</reference>

<reference anchor='RFC9203'>
  <front>
    <title>The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework</title>
    <author fullname='F. Palombini' initials='F.' surname='Palombini'/>
    <author fullname='L. Seitz' initials='L.' surname='Seitz'/>
    <author fullname='G. Selander' initials='G.' surname='Selander'/>
    <author fullname='M. Gunnarsson' initials='M.' surname='Gunnarsson'/>
    <date month='August' year='2022'/>
    <abstract>
      <t>This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='9203'/>
  <seriesInfo name='DOI' value='10.17487/RFC9203'/>
</reference>

<reference anchor='RFC8152'>
  <front>
    <title>CBOR Object Signing and Encryption (COSE)</title>
    <author fullname='J. Schaad' initials='J.' surname='Schaad'/>
    <date month='July' year='2017'/>
    <abstract>
      <t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='8152'/>
  <seriesInfo name='DOI' value='10.17487/RFC8152'/>
</reference>

<reference anchor='RFC9000'>
  <front>
    <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
    <author fullname='J. Iyengar' initials='J.' role='editor' surname='Iyengar'/>
    <author fullname='M. Thomson' initials='M.' role='editor' surname='Thomson'/>
    <date month='May' year='2021'/>
    <abstract>
      <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='9000'/>
  <seriesInfo name='DOI' value='10.17487/RFC9000'/>
</reference>

<reference anchor='RFC9124'>
  <front>
    <title>A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices</title>
    <author fullname='B. Moran' initials='B.' surname='Moran'/>
    <author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'/>
    <author fullname='H. Birkholz' initials='H.' surname='Birkholz'/>
    <date month='January' year='2022'/>
    <abstract>
      <t>Vulnerabilities with Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism that is also suitable for constrained devices. Ensuring that devices function and remain secure over their service lifetime requires such an update mechanism to fix vulnerabilities, update configuration settings, and add new functionality.</t>
      <t>One component of such a firmware update is a concise and machine-processable metadata document, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes the information that must be present in the manifest.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='9124'/>
  <seriesInfo name='DOI' value='10.17487/RFC9124'/>
</reference>

<reference anchor='RFC9147'>
  <front>
    <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
    <author fullname='E. Rescorla' initials='E.' surname='Rescorla'/>
    <author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'/>
    <author fullname='N. Modadugu' initials='N.' surname='Modadugu'/>
    <date month='April' year='2022'/>
    <abstract>
      <t>This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
      <t>The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.</t>
      <t>This document obsoletes RFC 6347.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='9147'/>
  <seriesInfo name='DOI' value='10.17487/RFC9147'/>
</reference>

<reference anchor='RFC9397'>
  <front>
    <title>Trusted Execution Environment Provisioning (TEEP) Architecture</title>
    <author fullname='M. Pei' initials='M.' surname='Pei'/>
    <author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'/>
    <author fullname='D. Thaler' initials='D.' surname='Thaler'/>
    <author fullname='D. Wheeler' initials='D.' surname='Wheeler'/>
    <date month='July' year='2023'/>
    <abstract>
      <t>A Trusted Execution Environment (TEE) is an environment that enforces the following: any code within the environment cannot be tampered with, and any data used by such code cannot be read or tampered with by any code outside the environment. This architecture document discusses the motivation for designing and standardizing a protocol for managing the lifecycle of Trusted Applications running inside such a TEE.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='9397'/>
  <seriesInfo name='DOI' value='10.17487/RFC9397'/>
</reference>


<reference anchor="FDO" target="https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-RD-v1.0-20201202.html">
  <front>
    <title>FIDO Device Onboarding</title>
    <author initials="" surname="FIDO Alliance">
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="LwM2M" target="http://openmobilealliance.org/release/LightweightM2M/V1_2-20201110-A/OMA-TS-LightweightM2M_Core-V1_2-20201110-A.pdf">
  <front>
    <title>LwM2M Core Specification</title>
    <author initials="" surname="OMA">
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="ENISA-Baseline" target="https://www.enisa.europa.eu/publications/baseline-security-recommendations-for-iot/">
  <front>
    <title>Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures</title>
    <author initials="" surname="ENISA">
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="ETSI-Baseline" target="https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf">
  <front>
    <title>Cyber Security for Consumer Internet of Things: Baseline Requirements</title>
    <author initials="" surname="ETSI">
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="NIST-Baseline" target="https://www.nist.gov/publications/iot-device-cybersecurity-capability-core-baseline">
  <front>
    <title>IoT Device Cybersecurity Capability Core Baseline</title>
    <author initials="" surname="NIST">
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>



<reference anchor='I-D.ietf-rats-eat'>
   <front>
      <title>The Entity Attestation Token (EAT)</title>
      <author fullname='Laurence Lundblade' initials='L.' surname='Lundblade'>
         <organization>Security Theory LLC</organization>
      </author>
      <author fullname='Giridhar Mandyam' initials='G.' surname='Mandyam'>
         <organization>Mediatek USA</organization>
      </author>
      <author fullname='Jeremy O&#x27;Donoghue' initials='J.' surname='O&#x27;Donoghue'>
         <organization>Qualcomm Technologies Inc.</organization>
      </author>
      <author fullname='Carl Wallace' initials='C.' surname='Wallace'>
         <organization>Red Hound Software, Inc.</organization>
      </author>
      <date day='6' month='September' year='2024'/>
      <abstract>
	 <t>   An Entity Attestation Token (EAT) provides an attested claims set
   that describes state and characteristics of an entity, a device like
   a smartphone, IoT device, network equipment or such.  This claims set
   is used by a relying party, server or service to determine the type
   and degree of trust placed in the entity.

   An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with
   attestation-oriented claims.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-rats-eat-31'/>
   
</reference>


<reference anchor='I-D.ietf-suit-manifest'>
   <front>
      <title>A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest</title>
      <author fullname='Brendan Moran' initials='B.' surname='Moran'>
         <organization>Arm Limited</organization>
      </author>
      <author fullname='Hannes Tschofenig' initials='H.' surname='Tschofenig'>
         </author>
      <author fullname='Henk Birkholz' initials='H.' surname='Birkholz'>
         <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname='Koen Zandberg' initials='K.' surname='Zandberg'>
         <organization>Inria</organization>
      </author>
      <author fullname='Øyvind Rønningstad' initials='O.' surname='Rønningstad'>
         <organization>Nordic Semiconductor</organization>
      </author>
      <date day='21' month='October' year='2024'/>
      <abstract>
	 <t>   This specification describes the format of a manifest.  A manifest is
   a bundle of metadata about code/data obtained by a recipient (chiefly
   the firmware for an IoT device), where to find the code/data, the
   devices to which it applies, and cryptographic information protecting
   the manifest.  Software updates and Trusted Invocation both tend to
   use sequences of common operations, so the manifest encodes those
   sequences of operations, rather than declaring the metadata.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-suit-manifest-28'/>
   
</reference>


<reference anchor='I-D.ietf-sacm-coswid'>
   <front>
      <title>Concise Software Identification Tags</title>
      <author fullname='Henk Birkholz' initials='H.' surname='Birkholz'>
         <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname='Jessica Fitzgerald-McKay' initials='J.' surname='Fitzgerald-McKay'>
         <organization>National Security Agency</organization>
      </author>
      <author fullname='Charles Schmidt' initials='C.' surname='Schmidt'>
         <organization>The MITRE Corporation</organization>
      </author>
      <author fullname='David Waltermire' initials='D.' surname='Waltermire'>
         <organization>National Institute of Standards and Technology</organization>
      </author>
      <date day='24' month='February' year='2023'/>
      <abstract>
	 <t>ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles.  SWID tag representations can be too large for devices with network and storage constraints.  This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags.  CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format.
	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-sacm-coswid-24'/>
   
</reference>


<reference anchor='I-D.birkholz-rats-corim'>
   <front>
      <title>Concise Reference Integrity Manifest</title>
      <author fullname='Henk Birkholz' initials='H.' surname='Birkholz'>
         <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname='Thomas Fossati' initials='T.' surname='Fossati'>
         <organization>arm</organization>
      </author>
      <author fullname='Yogesh Deshpande' initials='Y.' surname='Deshpande'>
         <organization>arm</organization>
      </author>
      <author fullname='Ned Smith' initials='N.' surname='Smith'>
         <organization>Intel</organization>
      </author>
      <author fullname='Wei Pan' initials='W.' surname='Pan'>
         <organization>Huawei Technologies</organization>
      </author>
      <date day='11' month='July' year='2022'/>
      <abstract>
	 <t>   Remote Attestation Procedures (RATS) enable Relying Parties to assess
   the trustworthiness of a remote Attester and therefore to decide
   whether to engage in secure interactions with it.  Evidence about
   trustworthiness can be rather complex and it is deemed unrealistic
   that every Relying Party is capable of the appraisal of Evidence.
   Therefore that burden is typically offloaded to a Verifier.  In order
   to conduct Evidence appraisal, a Verifier requires not only fresh
   Evidence from an Attester, but also trusted Endorsements and
   Reference Values from Endorsers and Reference Value Providers, such
   as manufacturers, distributors, or device owners.  This document
   specifies Concise Reference Integrity Manifests (CoRIM) that
   represent Endorsements and Reference Values in CBOR format.
   Composite devices or systems are represented by a collection of
   Concise Module Identifiers (CoMID) and Concise Software Identifiers
   (CoSWID) bundled in a CoRIM document.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-birkholz-rats-corim-03'/>
   
</reference>


<reference anchor='I-D.ietf-teep-architecture'>
   <front>
      <title>Trusted Execution Environment Provisioning (TEEP) Architecture</title>
      <author fullname='Mingliang Pei' initials='M.' surname='Pei'>
         <organization>Broadcom</organization>
      </author>
      <author fullname='Hannes Tschofenig' initials='H.' surname='Tschofenig'>
         <organization>Arm Limited</organization>
      </author>
      <author fullname='Dave Thaler' initials='D.' surname='Thaler'>
         <organization>Microsoft</organization>
      </author>
      <author fullname='Dave Wheeler' initials='D. M.' surname='Wheeler'>
         <organization>Amazon</organization>
      </author>
      <date day='24' month='October' year='2022'/>
      <abstract>
	 <t>A Trusted Execution Environment (TEE) is an environment that enforces the following: any code within the environment cannot be tampered with, and any data used by such code cannot be read or tampered with by any code outside the environment.  This architecture document discusses the motivation for designing and standardizing a protocol for managing the lifecycle of Trusted Applications running inside such a TEE.
	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-teep-architecture-19'/>
   
</reference>


<reference anchor='I-D.ietf-teep-protocol'>
   <front>
      <title>Trusted Execution Environment Provisioning (TEEP) Protocol</title>
      <author fullname='Hannes Tschofenig' initials='H.' surname='Tschofenig'>
         </author>
      <author fullname='Mingliang Pei' initials='M.' surname='Pei'>
         <organization>Broadcom</organization>
      </author>
      <author fullname='Dave Wheeler' initials='D. M.' surname='Wheeler'>
         <organization>Amazon</organization>
      </author>
      <author fullname='Dave Thaler' initials='D.' surname='Thaler'>
         <organization>Microsoft</organization>
      </author>
      <author fullname='Akira Tsukamoto' initials='A.' surname='Tsukamoto'>
         <organization>ALAXALA Networks Corp.</organization>
      </author>
      <date day='19' month='May' year='2024'/>
      <abstract>
	 <t>   This document specifies a protocol that installs, updates, and
   deletes Trusted Components in a device with a Trusted Execution
   Environment (TEE).  This specification defines an interoperable
   protocol for managing the lifecycle of Trusted Components.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-teep-protocol-19'/>
   
</reference>


<reference anchor='I-D.ietf-rats-architecture'>
   <front>
      <title>Remote ATtestation procedureS (RATS) Architecture</title>
      <author fullname='Henk Birkholz' initials='H.' surname='Birkholz'>
         <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname='Dave Thaler' initials='D.' surname='Thaler'>
         <organization>Microsoft</organization>
      </author>
      <author fullname='Michael Richardson' initials='M.' surname='Richardson'>
         <organization>Sandelman Software Works</organization>
      </author>
      <author fullname='Ned Smith' initials='N.' surname='Smith'>
         <organization>Intel Corporation</organization>
      </author>
      <author fullname='Wei Pan' initials='W.' surname='Pan'>
         <organization>Huawei Technologies</organization>
      </author>
      <date day='28' month='September' year='2022'/>
      <abstract>
	 <t>In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state.  This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims.  It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.
	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-rats-architecture-22'/>
   
</reference>


<reference anchor='I-D.ietf-suit-report'>
   <front>
      <title>Secure Reporting of Update Status</title>
      <author fullname='Brendan Moran' initials='B.' surname='Moran'>
         <organization>Arm Limited</organization>
      </author>
      <author fullname='Henk Birkholz' initials='H.' surname='Birkholz'>
         <organization>Fraunhofer SIT</organization>
      </author>
      <date day='21' month='October' year='2024'/>
      <abstract>
	 <t>   The Software Update for the Internet of Things (SUIT) manifest
   provides a way for many different update and boot workflows to be
   described by a common format.  However, this does not provide a
   feedback mechanism for developers in the event that an update or boot
   fails.

   This specification describes a lightweight feedback mechanism that
   allows a developer in possession of a manifest to reconstruct the
   decisions made and actions performed by a manifest processor.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-suit-report-10'/>
   
</reference>


<reference anchor='I-D.fossati-tls-attestation'>
   <front>
      <title>Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
      <author fullname='Hannes Tschofenig' initials='H.' surname='Tschofenig'>
         </author>
      <author fullname='Yaron Sheffer' initials='Y.' surname='Sheffer'>
         <organization>Intuit</organization>
      </author>
      <author fullname='Paul Howard' initials='P.' surname='Howard'>
         <organization>Arm Limited</organization>
      </author>
      <author fullname='Ionuț Mihalcea' initials='I.' surname='Mihalcea'>
         <organization>Arm Limited</organization>
      </author>
      <author fullname='Yogesh Deshpande' initials='Y.' surname='Deshpande'>
         <organization>Arm Limited</organization>
      </author>
      <author fullname='Arto Niemi' initials='A.' surname='Niemi'>
         <organization>Huawei</organization>
      </author>
      <author fullname='Thomas Fossati' initials='T.' surname='Fossati'>
         <organization>Linaro</organization>
      </author>
      <date day='21' month='October' year='2024'/>
      <abstract>
	 <t>   The TLS handshake protocol allows authentication of one or both peers
   using static, long-term credentials.  In some cases, it is also
   desirable to ensure that the peer runtime environment is in a secure
   state.  Such an assurance can be achieved using attestation which is
   a process by which an entity produces evidence about itself that
   another party can use to appraise whether that entity is found in a
   secure state.  This document describes a series of protocol
   extensions to the TLS 1.3 handshake that enables the binding of the
   TLS authentication key to a remote attestation session.  This enables
   an entity capable of producing attestation evidence, such as a
   confidential workload running in a Trusted Execution Environment
   (TEE), or an IoT device that is trying to authenticate itself to a
   network access point, to present a more comprehensive set of security
   metrics to its peer.  These extensions have been designed to allow
   the peers to use any attestation technology, in any remote
   attestation topology, and mutually.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-fossati-tls-attestation-08'/>
   
</reference>


<reference anchor='I-D.ietf-scitt-architecture'>
   <front>
      <title>An Architecture for Trustworthy and Transparent Digital Supply Chains</title>
      <author fullname='Henk Birkholz' initials='H.' surname='Birkholz'>
         <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname='Antoine Delignat-Lavaud' initials='A.' surname='Delignat-Lavaud'>
         <organization>Microsoft Research</organization>
      </author>
      <author fullname='Cedric Fournet' initials='C.' surname='Fournet'>
         <organization>Microsoft Research</organization>
      </author>
      <author fullname='Yogesh Deshpande' initials='Y.' surname='Deshpande'>
         <organization>ARM</organization>
      </author>
      <author fullname='Steve Lasker' initials='S.' surname='Lasker'>
         <organization>DataTrails</organization>
      </author>
      <date day='15' month='October' year='2024'/>
      <abstract>
	 <t>   Traceability of physical and digital Artifacts in supply chains is a
   long-standing, but increasingly serious security concern.  The rise
   in popularity of verifiable data structures as a mechanism to make
   actors more accountable for breaching their compliance promises has
   found some successful applications to specific use cases (such as the
   supply chain for digital certificates), but lacks a generic and
   scalable architecture that can address a wider range of use cases.

   This document defines a generic, interoperable and scalable
   architecture to enable transparency across any supply chain with
   minimum adoption barriers.  It provides flexibility, enabling
   interoperability across different implementations of Transparency
   Services with various auditing and compliance requirements.  Issuers
   can register their Signed Statements on any Transparency Service,
   with the guarantee that any Relying Parties will be able to verify
   them.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-scitt-architecture-09'/>
   
</reference>


<reference anchor="IoTopia" target="https://globalplatform.org/iotopia/mud-file-service/">
  <front>
    <title>Global Platform Iotopia</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>


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

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




    </references>





  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA+1923IbSZbYO76i3B2xQ7YB8C6J9IvZlLqHsWKLQ1K79lNH
AZUAclSowtaFFEbREf4Nv/lb/Cn+Ep9rXqoKpNTTa+9GbD+oQaAq82Tmud9y
MpmMGtvk5iK5TOp2vU6rbVIuktrM28o224kp0llui2XSmPmqKPNyaU2dLMoq
uS4fksw82rmpR+lsVpnHC/quMM1TWX3Cd3QUHXmUlfMiXcNkWZUumok1zWJi
y6bc1BM3ozw7OTwZzdPGLMtqe5HYYlGORnZTXSRN1dbN8eHh+eHxKK1MepHc
y6sjnHdZle0GIPnw8OH2fvTJbOHLDP4uGlMBaJO3OPNoVDdpkf2a5mUB0Gxh
CRt7MUqSajE3Wd1sc/k2SZpyHny0RWaKRr+oy6qpzKJ2f2/X0Z9NZefu4Xm5
XsO77ldbwL76acznZpLbupnAILMyh8cm5Q//GX6BPVunmw3sZwDHr7l5NPjQ
6WiUts2qrAD6CfyG/9kCfvhxmtyUVVrId7ztP1amyNIi+qWslmlh/5Y2tiwA
C6p18t6ubWMy+d2sU5tfJDN+dbrGV6d4cv91ib9MYV2j0agoqzUM8WhwF+9+
ujo9Oj6Wj2/Ojg/14/n5mXx8fXjivj09fSUfzw+PzvXj8eGJPnB0duweONTX
zo+OT93H09f68eScPv709sMFrUDQ+7ufrt9+SN4SwiYfilmZVhns6Xf0jNtC
+C/aRX7rMs9tWswNP9yk1dLAsa6aZlNfHBwsbFam8sQUdvOg3ph5fQAAHODb
E55zInNO7t5OHo+mh5Pjw+PDI/hnumrWOQz8/unm+CYGmb5KrsrKJPcwpl3Y
OR1THw4Ao9yYYl3ObG4iYCoDX9Tm4L1drpong//CoAf/dPTrMYNwdHQ4uTz4
cHM5ebifxE/9ilNPOo9ON9nihU2DwRDEd79c319OfoTZCdOjpem3jniTO8MU
ktESPY+xRdKsDJBPgTSCzOkKnoedyIGoF4x2ZYGfqxQorp03bWXql86VYBs+
z6enp6kpbJ1OTVuVG/zfwaYFLsibXx/MBHbPs6oY9gmAhXztADfh4f56xx5c
bWem8huAC76Ct9s1fKv8Ctf7sAJERZLWPbsz/9LayhA7eXGhMP8z62xqS2iS
wciPpjrAL341xcHJ4cmrw8Nf8X/n5/TX6dkBIOshoO7Rr68OD0zxK3/7iJhx
eLQRvIB9fdixXjxNIUBauhMPV+kmBcSlj4js+vpLa8O5dq8NjrCZLsvH+PDg
WCYstibzEIjJ3AExmSPa6ykDc0uS68lb4nmTKm3qiUmbi/DLurXNZA1cdGHq
zi/pfA3D1U820+9ntvq0KvO/8VAwlV1HrzTGbCZpNV8BDyZc7v+6qUBmzsv8
ogfZzvcIxMpsQGLp94uyrmFTJk0O7zUNgM4yIHptbpumMyrtR/lQbmwan+/P
eTkDqrzN0wbpEh5q8KHhE1rSwxt5lnDQ8vMH6zabLICPAX1VeFAHo9FkMknS
GZB3Ogfh/QD84Prdw0/JKq1RBzE5ML/MqxuRrtKs0iZZmXwDcpMfMcRQ+hSW
wEhFUgIZILfByeD4M1Vo6gQ0huRpBY/wWhpUcaIHy8zUUxjM1CaGYQ4yd2aS
toanUIUAVg16RA6qVqW/AQPZlPw7wJnjDBUoFHVj1jVCDiLZLkEfStLkMa3g
cEhPa1agATU0qa1RVWiJKSQ2z1uEC04VwKY1PVrzxItr+gDi0lbA9XPk/Lhn
xlYJiA4mmpXdwBQf88YCszX5dgxA8MzJGtacJzD3BpguTA0LgDNJE6AeS3Bn
pgLGAmN5lsVHYnH/YfsKwKvEfAZixf1EQOCpakn6Y5m3xNxDWKeMDWubZbkZ
fY/nWJUZsH14EFEDpl2bNR519Ygrow2AaUGl3JQwKQPVgOoCh2nnq85GAHak
j/AjqL2GWDIcGsqgQLXl7YJhSDk2ognXdlkAO6HhbT3nne4h4jrd4rIejewx
kDIMsXYniNppkmYZ7GZNa71Ji22ivMijeLSf/txXKYw8M4CjNBKcxgzmQ10X
VI8aXmesZZ2v5tMdJ6vyyXjE8KM12w3KWcDTrATsbpKatJAt0U+8bW7LkMhg
3JqeAoSOICXi2CZpXpc6pPmMmEMoB/sLAh4wfgMIvMBjs+tNTm/COTylBFKZ
LEtgBbC9dAozsy3xMOBtt0lwWqDz43rwKBYLA6prY5F23J4jvvAxyhkS6c9g
e5DqZJPlTAibMrOAoRlMUceTRVWu4TDXjAEvnREOYFm1AbiQu9L8RGS7mNc0
uW54twLipBmXKW5SIXv88vyASd8nqF484l4gEDj5g6nWlibbMlcFeylBg6lO
vrv5CMJ1zP9PfvlAn+/e/eXj9d27t/j5/s+X79+7DyN54v7PHz6+f+s/+Tev
PtzcvPvlLb8M3ybRV6Pvbi7/O/yCUH334fbh+sMvl++/4xUGnI3oE7ZvZph/
AO4wyxkBAc4rOyMGmvx4dfu//9fRafLly38Ck+D46Oj8t9/kjzdHr0/hD+Tj
PFuJfJj/hMPdjuBwTVrhKID5wJ03toETGCMjqYFQCpAllYHthP28b4HFEB9+
4fBHo0vgOxbODZ59QvW1WNJ0yG2qr8IfQNpHmwlBI7WCpI3IGATzD6xy/6lO
/rXV62Tvy5dYvf/tt32cH7RNmP4P0WzhwCLl+bffYAJU+WCCb1YlYbBIM4XB
4ACD6ZIbpurR6K4nqjamAnlRIOKtgI8+wZGN8UDmJmvxI6LRpgQdc0tinK0v
OljgcCYbJ7O2UX4HzGOQ/mOyl2VGGLDXW8I+zQG4ABKiKtOMBkxzEMzZlkWB
sCpiOXReg2gWYQZyiu+TP8s6vXMFvgVhi+4P+otH+/l2cns/OTq8SN6BlAE1
u14REGvYLtqyFMQYLrpIl7zNbtuYAwHeLeyyrRjLEAurMmfsRF4kEpcetQE6
imIEsOKWKCowdGolXySkJzo3ldPCCvsvLWgxiZXHYfdx31nS0VmutjX/CRMg
Dia3SH01znw2PZ0cXyT/zLRL+ABKPBImj4vIohNa2S3Uj0T3g1fkR1yiO4NN
W6H2B2zGggRcIedBFqfij1+tW9BWUhCEW9GgGjg7ULMQTdM1zItCCdjD2qRA
4Px07RYzTkwOqlZFpI1zl4sGT3hKnL8jqFkP8mo/vBL+7FWGL1/E2QM8NdRy
cXVufytGqgCrrtfrtiHBe1eWzArQrReg1cPN5PAI0Aq2oNzKRuOrZJfBdrgB
KhmA/IJT0QAtaX07F9ABB0hq/gkGBVwHeZLcg7oB6NoBBg79I+ySwqFKLBhw
YFSRou1OcwGaMWE4KkMNaB/LhswGQEc03QzpqoLTjVnSO6TMG0WOCW2g+Zwi
BoxZ70pz+7dQUZijWp4cANEQTdV1WQWq9RJh8g/Dt6S0VYAagDEwOHkQASnW
IDMzRjABkMcai8ghUZWuS1QbUWKhQAaOQjYAbjmCxBuGa+hiPnGkFpffCFky
eo7DnYD3gNhrBBJ2rZGdQUQS3loZUlsAhLbYgD0BxuESkQwVsHSO8JKLugw8
zgbWif7IBIlzigTs9n0JjAlmyUukhJDeAYAGMKH2NhmgOMzzaNNk0Rb0Ojzl
9EPlPmmTBhMw31EpBEChBZGBEkmW4izfqhU6r7abpoSD2oAdgpZUm4tvXTV2
OvD4sTRfljD5CqzCPTNdTuEEC3oCl/YEP3S2e9x5H0zmFfKZzC5RsUnQbCFs
BbMytywD9hFq2XTVDhZ8pGmup7oDdf/P//ifNSGEYXFEGAfGK+JJhhtFhzYz
bDyvAQvWFgh6kM8eoW9fz9HzyrRK16D2VaQAA9tDhEZIFQ0d/xQweLth32fb
ANBvYRXJvTBL0l541f+QXOpGO/H4I/Kid8WjrcqCpB1xNZBgSDNo5eCOuCE6
DObkgh9P1vgPgG9UpHrqnOEEJphgZhao5qCRSNRIIgb+YFJVHp8QM4FtYJYJ
mw7osHZonqegmmYq60JTZ1HmeflEcqU7cygPSPcMz+41nt0DY46ofV4Ogxrd
5hnqLWhLWjJpBM62dnEjWewa9CJUcknYj+7ZtCRqx8MLgNDVZCWbgKokg7hE
sQpEYlIanX4TXFq2gExwHgaXcATmlkrcCAagBgFWzyAHbQsWRRZoZ2OmcooA
XXiAG4eC7DJqhVeAoYscCh+v2qIQAIfOmnQDwg1v5ZPTIRNTgjDB0syNwzvg
UsdT0v4rZCWi2gMPrluV9UC/JgVlAS1vMmZwYlJVHm5vdiwH1mGAYbRpw2dh
4iErmo+fwx9xoNHJlCToHbBCEE2X3uU41e8CNyRaX+VT7fUlOAT2X+InOHxY
DnCCxgqmDi/NNuQjdODsGUuEoasjRYj2kFbEuwA8ZD9yIqAgNCI/Y3oW1tcj
DtLs5TidojWwctzWjpb35UvP2fzbb6KwXCGmeBaEs8RMKGIop8A+YW2MX5EU
IE2XHFi4VbpLaJ4QVrE2CeCwPFmQUwRGIuRsyBJOF6zBen7KototBpc/IZO3
o/IIYTE7In2gLCwwapHg6/QTcAh8Yg2yZm7LtnZiWUwolMpoRLNsF/gY74ku
kZM9xyjkM+KWAGOLx9JpJ8JvgBkQbGDXNSg4kYE5PmXXgCT1mMdGCTJnw09p
457HRXlA4wTBct7UNdLqooVzmIi2mCUlbDrTk5g3O8bnUyl6z09qCRLyvuiJ
bdBpzgJPwLr2yxWmCYhvgV9mwoDxVO8/Xj+AUcxBjYRNr7G4TMUZUXsjJtpD
b+NNYSdMiNJRqITw+iF0GBo0GMu5JZM4PDMgtN+BUMQYSf+C94Hg370jPqsG
r8mEunG4QGUUHVic+fjabaIxl2SvjlfUi9egXd6ZBbeJbGDcXBhO7SE5D9Uu
Dn6y1Zrw6+MGdCWwQB7QK0BsLbLOcDynkvCzbLI5LxHZX4U/yNB4Zp/9Hplu
GEQnRwJ6A3Gdl8FK9JmT89fwDCnRdK6iNu+2D1XEk5tOwx0NWte4q7WXC4GD
d6rcq7OwyCdEioawt7MLdCqhv4CHAqkKfC1Vi8LTap9SkLK8htsWgcqM+qK+
iYvEQFQdKq3MYpISwzQW1EOF5+gNWKvMT8kIC6w5HfBgIec7Jq0n9n0Q90TL
e7Nx0UqW9E3HnOBt+QBccALoObm0VbL34eFyf+wnlmcoBlIhNjKR9J/A5bHC
4NV0NHcca5QIDVkS6nXISsPSAv01KelTSjqk4pNhQpYye0ZA9RLjod73oyBU
TvSiCk5xXjQGRJUNTEixcRyDQqOP/gyMH7AJVmVWsxzqrnMDAgRtA5RzuMs9
82fs+OXcVOJEYgwY+h5khIUNIa3QenSW8xalPJyeOQr8AiygDpDm/CL5gBEK
2YASSXSeKJ7o614ouTePDy+SvYAgD0LKTfP9BH0aMEZGVhaMKggElNEZHbjc
5a6ZHSWT67LMUAcGdlpNFHcNWecUYpmjQFTNmk7hoMRgi31M51sNPbH4K9uG
hsFhnb9umog93WEArJl3bWremK7dqW82q6pslytgSqRxiaWs3sSsfCqQjPcV
SHYFsN9MnsU3H8laAtPIpvuoRXdgEJug4+JgY0zgE0wQ3sT6E+rB4UjIqgX3
/0YYDVhv2XkEvA0MWThIGS/gTfBrShyMNKRHtILLYnTaAxIdKpiGxiMw7bgo
1NC0GA8ZnfXGkTgZwJrZmj7qgKNXU2TEAStzZ63xU9JY8KzUZx97fb3PHsy0
vGWXE/rMEetyzkYDGC4w86CPCg4VaePlxLuEU0vUSPR/R2qkCbN0bukzBelo
qwl4HkYRphbPh5c0mI/Xx4z+ZoWIzkkEQPAyug3jp8RxJMz6tCpxjCdimLoC
Hsl5TP4R1I8uxWQ9e/xkcoRZbB59KN2gYBupGLLSQxnuHCgMMMI57U1wjD7x
ImSDloVEGiVJqLHg/Nwk4vxmuBNz5oXTL2P5rsyrB8hJculG864g0jTcmMR8
kABA2G77Q5wGHDFAIb8jzsftPRe7wDkj5IhdH/OVAZoWw4UQLpcMTJVehjxb
FjguoSgq3oZdOuq6aAO1z6FPf/pXyXXkWa7bDRrRdSBt3EjMDGXrQowlSwRj
BH4HGMWdY8qtgtzBKjqdhoOYXZeBVMb9n1NiBv42VjoZI75vyrrZsBeno9L1
1r4b4v5OvI4PAhEDedMMzRu1kUIzmSh5kc6Rqp0vfYCz9Gd640OfXowKIqIF
M4Ry5wNoEjid0sDM77tfX8bCo0MJWYVoI0l/qM2impg6AUmxdVi6GUeoQ2v4
aqDImyK7xSolq3VhWtEAoEe0EciPAQDUzCrdDrZhPP6QEwfNrCXmLyvzBJJO
MeEDhygoXJE2qs76E0m8TwBFy5KJi+RUaCqVjN2glX6qXQqWqHupyNQBojs6
HjhNQs+tB/9J2WWg8bOd2jlOAAv2HSikajeNprqgriYhCcroCYl8AKCToV3F
46TkyHo1ZsexRlNwM32cEUyVHHMinD9fdpgccbwaRZQFMXlhMsLCBsA5TX4q
qwG5IAEs4AwoOdT6sT0+yy7PhBWINGDs6axGTXSIKPgVBomD1GQw4KMuqFeZ
TQ5ozx5gWQQh1Y6lBQxRNtIbA9Fm/327O7CDZ3/MDkouVGiw16XXRPCR7uYM
y5mjV4xh5FvgbDiH0c3OQIAwRdqAfBsR81h1NdhOAMiw+lxGGgbsAHMWF8Fz
nKsL4RnoBVe7ImkcZERF0z5Gmk+o8HAq3ks+O95ysHrFmcBGBWyCc3UM+SRZ
gyRPjTrHkr3nXWc9JxPlXbrpXPDWmf47nBy8xLFXvYmWBhBrKhKEdDLnXMHM
NgzRsy+NfGxj9iR14Y9Sl3c4ybqcj3NJNHnEecED6yHOAIl+GjQcUWovdxuO
80FDZsD4c3ZVJ4OFhn/euPoG+89QCDNEedpk75sJplYOFXlT3IjbZ6N78UjP
hvaOjjG2dx2qZi7jB7Q5Yb4RuTv5/UiZr2tQFtcpcok5DVorxySxSAYQv8Dw
edEdq2olZgjIJnapHYA83qlHiJOUphN3/LK1GYNeYGqLTxWnaD0KeuGiwwIW
phsUsN8wHZsEquWHk3n3nQMGCKFrQnPs0yl0hCbyvvBR5pQdB8/Y5QnFoacO
sxl7Vlu1BXnhY5QJNEYd8MsXql9ywas7EAq5JekM0P0EFgssqROyeoU+VJY+
wlCZDGBDC0H9hv0+IOOeYJJPBaZksmXsGB3ZVYHKN6tIF0XfXzmfM9+uJMW4
3YA8yEwcAIMloKAGXv98ULzyS3qWZs6RZIL1ewEza21OwVZ2ZPStcI5wUB0E
ajDpJ44Q417M52UrCRpgMtWBh69sMYhJcoAcslHi+qZ86msU55jUdvWMG6DC
OsDQk45Dkd8s34bJMZpPmmrQJS85TupS+WhrQzJHIUBFF6AFFOSCiYZgJhio
xzrijoWcvJh5oFUHsIluZ1hBM5838AMqR7JQWhPByqkT3rblFyhGjDuQgjlD
PnI+IV6A82uJEmSjLFo+RoQT2ANPBuj2zyt0yXNuMHlQEg3rpbaBJbKmazlV
EF1HmB7uTBmiYimkpBxXIDwO4F8WcxAIGNETadohvdec36YCuhYV2Tk/NLsf
tEAu9QiEs1h2rMF2bTwMdr0DEb335YsW/yBSYi3PJzg/ZDdcglbOD7AW8qBa
zLE6VMNSXAWJoVTUSDY4jjCWfcdb08BvxDCipurAwpXXyV4I7MEAoPuc7PPW
LNIWqNIZ8f8AGEZe7CBqh99/+AUllzze2c43F7DjW7XtCHV66YF9bwoMl/Fw
7AgiV3JB3iYK6Ing9/TGqoIfSPwo4Uiapvaec1yTSyZA2KZrZdr1oKrkk2LR
KeNyYp1PE4HzSXQ934FYIpIGDb/jtFhfrrbavOwspZNKNqB1eZCc/pW65RCT
74GBv1CO/5COJc5+YQ/dzDnWR6Iv91F7+3/i7R534349VxkhSPZXRGOsxgIk
yDOGAk/Gvel1xzUWkIhNiHsJCkfgomb7lERKybUzQBtbLEayygfjRE7M1llv
0JVIArcpMXsDTSQQ7aaX9qlPi0C9QSUQDgNZLtW9cZIHpn4oRsaM/RXKUPRh
Cz2EqeGCFiHuOdtSKaIrKF6hxLve4b0cSz1SD6XjNF2eZK1LIR22E0zGWjAQ
WEi1YV8FLMt+TIsm9Db1ITy72KlVEkpLnMFZL6ooeMpT1uEEhBIfaeuUtl6T
He3k3fOupFeTVxechuR5jq4/U5dFTNN9wte6Tm/S8OwDs4FUcsENVRdaSXTF
wvaQr7jMYK8oOYTGrDZ4xedDY2g/BNOlwUsahcZV47R3AJLVcyQWnxOCVKQV
Sv00c5UnH7lA4Data6qx6kiM87CIAp0upBOilFQGNbFFBkvMWjKeeNCNjjZU
qnCENMNWu3vOo4XTYrai1pR+cXSMgHJlFUokLIgaUKv82I7q+sUQuEfeQvWe
LZ+Fu2Pbf9eud5OyubyNlOEgfahX8kB1t/k2gOQgynJBHwirZ1oYiJaX82JI
dgJm+ISZRTjt2KfY7L2UPURpcKSq4EjjMEum5gxQUGiw7g+tAH236+YbKBgh
uPA3LIcG4wafWRujKZzdYk3Fz85W9k0dyWU4vEhuwcQlUUE7rYnMcFg5qdXi
aOPsqgwFRSUlN3n6RJ41CQyyw5wqTJ55X1MJGj3aup39FR78E+XW1IQLDjqg
hBuXW6hlXQGwWqPjmBRr3Zy6S8U59JPUDGMZ65OpAtiCvBP2E1aEtAKt+Oh7
U2pyhvO3pv3l8Jk9mTwXacHCTNYFUoxlaW38m/GOVVjuXERvnXCzHqD7Twb1
BqOYJaXoWMPWeE3m3cfkZ1NQPnUXG+7MshU/0N7Pb2/v9oNZTsmmqEhs4nRR
5a0TVjqvWhjms6nmshwsQ5ea9DKUlWPR+8YJAFWT2V8hQAunvDGtl1UjitDY
qYwi5PzJgLVHG02l5mX0gzjBFQzS0SSTgNOfKRXMBWVopRJZNVkw0q5akcHc
lv+oF3m5XuT4G5yoBeXq50J1cQjBFkFQBl2n8Ji+7aPummgTmxElJTDpvmrO
ETBcuyFtj/RGqhjiyhSU4y71n7yk0VZTDRTVfblsNwT4/5fJ8cyW+pQbOu0w
Zk7tEpra5AvvCSRpReoYFXXmVBAn6sqLwiXUZ96gcwdtAPNZdxYzDxE1dIl2
h5I+840NjDpvvikcF6aO9Py/R1rvQiajm9Gl49L5xGoxbQ5HkfEdZtvsxkWW
puVtEaqiU5MTWTi4PQDHccf7FQQonwEmpgkPWiyvBDxKjXPldz5f2zH0rwL0
RGWDh3BpsQsDb7/1RTJ14CYHm9T4Rg4hdANTnPaniDeBpyJs1oj/wLLRNcw9
NWhyWbh3yoau2jB7N4bolaLIUBBe3Fh6anUIXhcRw/yEdIb6z9OgNuP0JKrW
FW8hM9KWvp1RhtmahdxCE818KTKxIvSpqHvEC21pjUG+R1oy84VuWU7qqrIk
9pOFccY0e8SU2prqg+OtchXWu1fVE7tu8/6k2p/UT8hfnizLGetDjKgkx5AB
dIE48R7xmnLxlumjcaMpP4gVvAHEDPPcOm5h2DI86KxK6XxEdcTwShcWQGXM
4zJoBzRokzn9URU9QsqvCSH0YO5Cq7TyyWxcFgLZ+O16wJh3joSOOR3Df/aH
we9pZAeb7eTvEFI/M/Hvow5qAPJ9cs8xqvt0YUTNuTOgOvPxYhWS+77y3/fN
zt3m5nVo+snRGK0yMNLlwdWrdMsymBeLL7wkW+85Q294GTvtPTjTt5Towfsu
8TrqqRIETyRviYOEiEfZOCzoJlOL32QMSCXDv0BXGqX5c5m/rT+xTvXXtoo8
0nCkWI0VmB2vwCTygQuuUcoXk8ymy6KsrWIUfFWZDdigByuT5lJ/psEoAmbB
Qcox1qIpeuPUaaiKsvMkmP61KwRhvRybjAb+tUmCZ0W6cS8UgAUVtmjptMj1
yBq6C3mhn6EtXHkI5ViC2gnfYI6xWVILTvQXpGhlCUl5SJWiMMEjL9tMmin4
bhqA0peROSBa2u5Sn35+wOTUdcdwaZ5xfrwU4GuAeiDJUAVikANF+w4jZciK
qLcZHYSqGWH4J8jx6Dih0WZj71dPXZic/V0JzAEEPpmbnQVY0gi8pWobg50h
58YVNJZFvzmCw1sMtw94oGG9nAEhWUn/TkJr7LqBRWAKJzsa8SNjtasPCjvF
7HWwal/cqZc5spwYTZP7+QreEr3pgXvT3WAuWsfLenzkmNYAemgpB5YhiaUl
4+71HJr7CROPqCFSgkldNZKwOV69y8V58GJ/EvUUJ3do6etCnL7VSUUIuxaV
7l0h8XihARc/Po7L1np+Za6/eiT1l39CasR+wiy7mNiALtpK+bmEU9BMbTeB
X+zJpJ/GSdHm5Lud5WnxqeOXJnLDJYXOqmM0+naSCXmP0OoEFMYmJX7AMlDE
bNQaCGBYY9cowLHrX7AmLchG0Hi8lsI+lRN2hHeRZe/4p8t9qh2BTbG7HrrB
h3L7yST3a9CLNysQBqDF/GhL1EfsHD1YzXw6Jjwqqf4+KDQLSsWOT3u7ENTV
BZUOac5aTUrJqJIi71wKwYAgv8Xwdiz5T8SlEuJSf9J3mVrTGWwIcDqMtflo
nhgCgU9dtpFMA7eX5NoQL48tXEahh+WVw0I9P5XEWw5fURspx4gwdbCcac6B
q0fE5Nyc09+Iww6ldGMMZS4pLKL7S5SIPUo1YHZo06DHIshGdFBFjSlYSMpL
6QukuXmWNJO+QP23H8TpQnysAFcYtKJUQTPUIau/IF9pIkAsye/cuLr3UByt
qGNQ1s6FHaqS6D2wKmm9zjHP05p4Q7PdBC2L4BAvuRNMTq4lVKQ6kRcEEeio
bNGXl2nGFuG3riPHVASRGd7/hW3AvXLlhIsweWCbc4s6DMDynkKatxrI7Mgu
UCypNzuLLvGNCLtkd524UEShhiO6DrOO8eAmS9FjYjkXJvoUYRuACDyOuLo4
K7DPD+9v9y/immViyBLQ1b5TCGL0JstJTlvLze8Qkb4FmUyhqpL0tWLLX5wP
QYcNXtlN6IP5WKPq8pYaSG54DVLkL93rsfhdUn9cHyDMkhcFOTyiNxfqgnWJ
lkFyjpGCZ4xl0AAmCdpZYbH0uGPMeRc4hjLYGcbeTTc+i+1SkmxMFmTEwHPr
qQLk8vg7ealWl4LojPZWHRfH7264tavb1mg0ZLaijNbIqHS43ZEHv1FeonmG
gVaIreJwENe4ImiM4aKvt1/VpWEoYv5q8uZioHaHnVba8I96xjEGy15L48JO
9SIGiKvtju2Q3A0uk6sweJVvO471m9uPe6I539zQR5fXoTl4aFKXdeMlKqvI
DJW0R1AUjRopJIEKeH7BbngbdZbpBnFcW6qC1ANONI+WzyUCog9z7JIO10hv
Z37YuVPDgv9SfyXn4bzN08pTgqY6eucTpUOxLdWEdUeuRxh14/T6xcmh0y9S
7XWqxm+YEqLV6iJZFjmFX10TYWYuWs6BscVi/kwDRUJN81n0Bvqx07476g9d
ekbFnZJCXPfmGKYMk/90Rhlc4ofrzM/hHatq0QLUSSv4wtGZHf6gQh1CSBi9
zhtxQQ0qpI7VaFfLKKzAGeP9lLydRaNhctPMOPmgKd2x+qve+mdqfs48O44A
YzriDlP9nCwt4uDK6CCQtms9rKwo1EFYaQhu5nHmM7JaUkjZRaWjiqczSMR1
RI8+RGRzG3gr7jghremFb0QRBqkEc53O2I8Zr4sKDGcOC3wSxIsZWv+xxf8K
W4yaYtBFUBJsb9Xf6VvyMl8frk1w7tHhfuCJz3ZzIu2Zhj6U4UsdX7i+ZLb1
eVjiIAeF26eqSwDMM2BMv+HObHwW3GOs28spM/IXai3hD1jBofkZCu/Id70N
upRQmQya+HLY2sDmUaISAs/xzm49cpoo6dLaSr4ziKE15VUPZOlI20nsE9KS
aerj92FH0964EkcNgDrp+mLEXYtYL65imtc7kN0pu4g4V/fvqe3x8f7H/X7U
hlx5zqMdrQl70x1kZtYuyX/FkkxLa6iGHwxiv5ZWxLfr1pY7rcDvaU1N0NiS
A92c5Bb21PDgM9Saqq2NZX3zISeTfg+yD+QSn1zsUotxXW2hO4bnxBnKAzWm
rMqShdnPXD31TaJ5NwPxV4fp9J6Xxd2fXSo/ZvL5Zs1YABkkXCgTYCdzvCsx
PUdpGr12YkHALfAOnpwGehPQ6kYK9AwoRHNS+KW5WrdvgqY+DmQDjXt9Aw6o
tiFIDyK66vb83vORY69u12i7oQcPVQpqbuzaByPhTT09GYW/pj7YkoGjmVNS
40MexCBBqlMjLA+gN4t9hpo77yoznEiZJv/kGyWwryrsGOk0PZf5LRuOXc36
WUGqe7s6QLaIQt7x6iL5ETVDXwdeajKfJBhy0rS/4StaaBFowqSWoqsm8NCd
YCa21L7XgLi0bPSNBbaZOD6UVH8/SvYwcsAp9qxTWLlSFHfiAsxu9OmrWoGM
0cUB6FPxNSJlgE9hxpHT5zHbEH1R7EuR6GTc3Bjg/7NvHu/al+5oc9zpJAcf
WjR+uNEjLSDgx/3JTrka6dlZfN/2yAyMiJWqVOuh7gouTL6J+npHAUvx4A1n
DPVWuNsLyd56H/xHB+Af4x4k56AUTnofdaePQJdCv7mRgO/8SDnhIuyuotiu
lA4gI+zqe0KQby6Sn53GSbLWmanepkWFDDj8pGvM74mlS5xTjnuskUubDx3+
JKhiDLzpju1KIMxVVFJeqnr88Rck6KjXiWtReYXB6GmYERjcW/KsDYrVKM8h
dVhip0qZh3ksmQuoK4XM8I+l9TNpPbS7BcYz0pKF6zMrdKaLJzXDPRy5FVqk
YQwElPvQvtmVphbW45vepR61psi/DC5feqJ7O1xp9GZypLvW3Y84YUnOkjwi
sDryLIWcIlU2Mwa9mS9S4E6kXS40jvMEG0kPIhTZLRr6cB/vgjvoMBvnVYYn
p2vomJ5DXDPkgRG0kVz9RmwO8Zi98jFBDrRcX7T5wnKEhzywVx/u34n3/OgM
bwbhpObaR4hDvhJzoAHHoyqEvne3YzmVWlhT5agPlCmJWoq4gBlbJ41+TwU2
uy7n6xTtBHPFHXv9LF++703wkr/15Dw282IZ6YjGBpc+SV989JFNysUE9gGM
dWBfLvE/8mQ6JdSHoB7e34ep5ZHOeeqdo2FEWePxWqBpC5/QTvcJyGdlKbAB
6Gb8Sufhs/cDfF1vtoBsnGLc52bdhOh+O4CW/J94PyLn9PvKjlhLFz8ntdiI
yk99ZXdclz0OvNm+r8HCmjzr2kx9uP8NeleZHYQMAFuTUPNuaYKrly64Kwfp
5BH5uJU0XvVMkZcfkrf+W7y+Wb79y8frK/328PBQvv1wf/Xh7p1+f3x44iNy
xJx2N8E/PQq1JLYrQ4XWN+vkBM2c3IbinKRwF7Oeta1rcT/RF5UR3+KUIXBZ
D3jdBDecpEgfNnnjKKW6Dx9ds/p5uuEmUmxaoqrEsYQYRGV/wqccr9/BbKed
DQD8f8vBQU7LcuDbR6M3hhHQrp3tNgnv5iTnS/JWrrQcayYNywl+5yAyswK3
jzpwfGmwYqu2SCaQtOzB3y/h7v2hDtYjzqr2dsmCUkLkvPSW0DhRGLaBDXAp
HAo4LBIlXdXZuTGEitdxK6bJP5rOLbLS9o1M2A6ddI0cN3xKt+X+kNxdPtxf
DF1xQd1MBl/uNc/q3e4rlAFEdICUdJHctE3br9HfDZ3M4IgyOUi6xHhJA196
lX2Sp1sAToVJOBel03iUSdxtpyAWsDux4TSpjTbCkLuoSIZGbr4f5H4MwBma
/mHlO/iHF2egpGSadHizlggXcRa/gTsuOvY8pJN1EVtiHXKSwsl+k1xXXfho
ooLlDd6xWVPqFAU73NBUFEgc9a6vUmlDEG5+LgHXr8pd0Dsa5tytWzvadNAg
OH1OcOgs81SqZSm7XzK5I4ZwGzXPlzBu8ASFM0lD44Qk353QjLTpoI0ZxDjh
iFEQZRVlVVxqAwJItssLIVeFF+NmCNke4scBC6D1ENXorRW7aENCFXMQ60Pc
BS+RxWleOKhwFj2DqIc7zHo73IiAtcnowDAMJ85Idw2INPplB2s3HqKXgIo7
9NG3+tdISTQ+GNp3yN2pWhBxV7MLctXpRf9LKC+BGLTIGMwT8FpiKS6Z5z0y
kZfE96mJOs0oq1fU/abNk2W9hmUhDPdm6b2xyT1wPL4pWecyud4oVFBvOLRo
m6iNNgam8JZxTezpdB8T2NdhqXZJylJOuxCo4284L5Mjk8PZQ8abD2NqZJYg
a8jDzPUg738cXdqQku+eAHhalcSPgzr5UzBOLh9Lm8VZOI1mRtZ8RyJ6fqVl
FpBN5RuJLtK1xTJ+gGduPBAsH2Ign7xrhkiWSr8p1EKogbq/ZwHB4B7YM2+5
kFIb9AJh1K+C/jKo6YR9smUIbGboLi1Kk7dvy/sJX6uZSo+r92WaTX5M87SY
c/O1sIlXMNKJ7lxgwtUtJqWvKHtaL5IwVUXJQRy7UHvp8ltKLP6d1ip8T4Ft
9cNhbSYQHgnxTpr+mQ/PPplZOCR1iVAz1heHiC4w7hXNit6JlyiYqI4sDHpu
nbFbtzUp9tKK4L/d34+Tq/u7n8bJ/V/eY/GR3oWCSdu75RHZfeRn6ksmUWZQ
+gAasMHTlTcIXGgEhdzQFpuWEbNsG/wIh5DldHXxN3DAaLdPXQIYjucL+5O9
wGuTNq54jq7/2lSW+0TBgvZDeBYWU2hZv+m3pDl51vSPvf8CiVFnDEFnU23/
7bsyVaxNLoC0xPkZaK04P953uMZ1BLJk7/L2uqYMfvW5hd0AnZeNhb1Pr8NG
asu/a7vPYpaT83iu4SV7SOeUFk1KVi21NFyhNtCVbNzJkJSEdqkHZC8Ct9EY
8y0uLlk3vDO1wioT1/JiqL04QzjFHfAxSbXSqBQm02b/khQh7Ucqa/gyFfJZ
RA2y4hg/NcmIr/S+J9/FJaIFRlCHOmboxYBxV4l5NAy5QAZayrmoieULWxgT
+IoOJ6kweQeLODC1RDOba69bE9OhVywbPTOp1s8MdRfNBmE52d1UOErhFe+N
FC5Ql+TdHe2QAaErCy+a6d8Go1m9aOm6V/bilhZOo4e/93lpJrO+WJOA4dwq
SSdBke3bQ/hUKrDuCvYw8QVofCe4DhT1/+AFurjSwAU0dDFguBtBFbwTYtId
mdO7KKwdWh/eHYp6C27EAQ8GFCh3ZT2bZaKE+sLVp8dU68wFrH5npSiRGmY3
kU9EmV6nDlIcSqYKxJzo8nERpAxDykZYySQ3dGmr0yeqVHAsTipE8OyivFqt
0SM3Pc5OlQPCC7DxMHyFnWBz5AGcaiF4ybV8fURXoegMfmHR7BcZcnTwnZea
P+MjHxTcoC7p3XuqxgzPwExsNNNLd8QmdlxKyDwEpyUmf+NvpcRFXrZMAr/L
1oiY/6uQ+VfUPKnq3IEZXLHhbhQDzc2WbTVmbzBFKNbouJMgMjEydtEFfjLS
NOuuLXf2mhobkEatl8wAL8msCAz2hdfRjSua4d0xPjRiyb+Ruq2ZQVNsBkaY
tAG+3UgaJHpf6KJvLiWZ2bTgi5eG1eDdG9slu+Nn2msQ60iTxzbHBDRhKUFj
Rs4W5xsc5shXd12nc4y0/ZZfRCQOBozbsKZzaQxFUoDvfNnRCuUYEwpCV0G3
GJzUSEEQZKQdFyy3vdr6o+pChURjix29t0j5rU2ejzWRYux6CnBaRf9xlYBB
xefXXfzxanK+u6FlHFzO0AVUbgaiy05FdPcORM1rerVoh5OjP6r1hEoPio6y
Oe8vG5Yufza8S8N8BoO1kLSaoNCgxGxJUifvuWLxCu8T9Df7jiXAiCrPXKKi
3MU57B1Yz23T9JoHsuewDlkKJ/XM87YWl3C2E4WfQxZK/+xES/Xq1g5Go6Ls
Q8ZXYYtrUOB+KcOusiGPCR4THYKzpf+Lt9Ly1JKloWGuDfqZjN50oXrkZDIh
m280+r8qBWlw45YAAA==

-->

</rfc>