<?xml version='1.0' encoding='UTF-8'?>

<!-- [rfced] -29 pre-edited by ST 07/11/24; updated to -30 by ST on 08/13/24; updated to -31 by ST 09/16/24-->

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

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-rats-eat-31" number="0000" number="9711" category="std" consensus="true" submissionType="IETF" tocDepth="4" tocInclude="true" updates="" obsoletes="" sortRefs="true" symRefs="true" version="3" xml:lang="en">

  <front>
    <title abbrev="EAT">The Entity Attestation Token (EAT)</title>
    <seriesInfo name="RFC" value="0000"/> value="9711"/>
    <author initials="L." surname="Lundblade" fullname="Laurence Lundblade">
      <organization>Security Theory LLC</organization>
      <address>
        <email>lgl@securitytheory.com</email>
      </address>
    </author>
    <author initials="G." surname="Mandyam" fullname="Giridhar Mandyam">
      <organization>Mediatek USA</organization>
      <address>
        <email>giridhar.mandyam@gmail.com</email>
      </address>
    </author>
    <author initials="J." surname="O'Donoghue" fullname="Jeremy O'Donoghue">
      <organization>Qualcomm Technologies Inc.</organization>
      <address>
        <postal>
          <street>279 Farnborough Road</street>
          <city>Farnborough</city>
          <code>GU14 7LS</code>
          <country>United Kingdom</country>
        </postal>
        <phone>+44 1252 363189</phone>
        <email>jodonogh@qti.qualcomm.com</email>
      </address>
    </author>
    <author initials="C." surname="Wallace" fullname="Carl Wallace">
      <organization>Red Hound Software, Inc.</organization>
      <address>
        <email>carl@redhoundsoftware.com</email>
      </address>
    </author>
    <date year="2024" month="September"/> year="2025" month="January"/>
    <area>SEC</area>
    <workgroup>rats</workgroup>
    <keyword>signing</keyword>
    <keyword>attestation</keyword>
    <keyword>cbor</keyword>
    <abstract>
      <t>An Entity Attestation Token (EAT) provides an attested claims set
that describes the state and characteristics of an entity,
a device like such as a smartphone, IoT an Internet of Things (IoT) device, network equipment equipment, or such. This claims set is used by a relying party, server server, or service to determine the type and degree of trust placed in the entity.</t>
      <t>An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>An Entity Attestation Token (EAT) is a message made up of claims about an entity.
An entity may be a device, some hardware hardware, or some software.
The claims are ultimately used by a relying party who decides if and how it will interact with the entity.
The relying party may choose to trust, not trust trust, or partially trust the entity.
For example, partial trust may be allowing a monetary transaction only up to a limit.</t>
      <t>The security model and goal for attestation are unique and are not the same as those for other security standards like those for such as server authentication, user authentication authentication, and secured messaging.
To give an example of one aspect of the difference, consider the association and life-cycle life cycle of key material.
For authentication, keys are associated with a user or service and are set up by actions performed by a user or an operator of a service.
For attestation, the keys are associated with specific devices and are configured by device manufacturers.
The Since the reader is assumed to be familiar with the goals and security model for attestation as described in RATS Architecture "Remote ATtestation procedureS (RATS) Architecture" <xref target="RFC9334"/> and target="RFC9334"/>, they are not repeated here.</t>
      <t>This document defines some common claims that are potentially of broad use.
EAT additionally allows proprietary claims and for further claims to be standardized.
Here are some examples:</t>
      <ul spacing="normal">
        <li>
          <t>Make and model of manufactured consumer device</t>
        </li>
        <li>
          <t>Make and model of a chip or processor, particularly for a security-oriented chip</t>
        </li>
        <li>
          <t>Identification and measurement of the software running on a device</t>
        </li>
        <li>
          <t>Configuration and state of a device</t>
        </li>
        <li>
          <t>Environmental characteristics of a device like such as its Global Positioning Sytem System (GPS) location</t>
        </li>
        <li>
          <t>Formal certifications received</t>
        </li>
      </ul>
      <t>EAT is constructed to support a wide range of use cases.</t>
      <t>No single set of claims can accommodate all use cases cases, so EAT is constructed as a framework for defining specific attestation tokens for specific use cases.
In particular, EAT provides a profile mechanism to be able to clearly specify the claims needed, the cryptographic algorithms that should be used, and other characteristics for a particular token and use case.
<xref target="profiles"/> describes profile contents and provides a profile that is suitable for constrained device use cases.</t>
      <t>The entity's EAT implementation generates the claims and typically signs them with an attestation key.
It is responsible for protecting the attestation key.
Some EAT implementations will use components with very high resistance to attack like such as Trusted Platform Modules or Secure Elements.
Others may rely solely on simple software defenses.</t>
      <t>Nesting of tokens and claims sets is accommodated for composite devices that have multiple subsystems.</t>
      <t>An EAT may be encoded in either JavaScript Object Notation (JSON) <xref target="RFC8259"/> or Concise Binary Object Representation (CBOR) <xref target="RFC8949"/> as needed for each use case.
EAT is built on the CBOR Web Token (CWT) <xref target="RFC8392"/> and JSON Web Token (JWT) <xref target="RFC7519"/> and inherits all their characteristics and their security mechanisms.
Like CWT and JWT, EAT does not imply any message flow.</t>
      <t>Following
      <t>The following is a very simple example. It is presented in JSON format for easy reading, but it could also be CBOR.
Only the Claims-Set, the payload for the JWT, is shown.</t>
      <artwork><![CDATA[

      <sourcecode type="json"><![CDATA[
{
    "eat_nonce": "MIDBNH28iioisjPy",
    "ueid":      "AgAEizrK3Q",
    "oemid":     76543,
    "swname":    "Acme IoT OS",
    "swversion": "3.1.4"
}
]]></artwork>
}]]></sourcecode>

<!--[rfced] Section 1. FYI - We expanded the first mentions of "ueid"
and "oemid" as shown below. Please let us know if this is not accurate.

Original:
   The ueid is
   effectively a serial number uniquely identifying the device.  This
   ueid is the base64url encoding of a 48-bit MAC address preceded by
   the type byte 0x02.  The oemid identifies the manufacturer using a
   Private Enterprise Number [PEN].

Current:
   The ueid (Universal Entity ID) is
   effectively a serial number uniquely identifying the device.  This
   ueid is the base64url encoding of a 48-bit Media Access Control (MAC)
   address preceded by the type byte 0x02.  The oemid (Hardware OEM ID)
   identifies the manufacturer using a Private Enterprise Number (PEN) [PEN].
-->
      <t>This example has a nonce for freshness.
      This nonce is the base64url encoding of a 12 byte 12-byte random binary byte string. The ueid (Universal Entity ID) is effectively a serial number uniquely identifying the device.
This ueid is the base64url encoding of a 48-bit MAC Media Access Control (MAC) address preceded by the type byte 0x02. The oemid (Hardware OEM ID) identifies the manufacturer using a Private Enterprise Number (PEN) <xref target="PEN"/>.
The software is identified by a simple string name and version.
It could be identified by a full manifest, but this is a minimal example.</t>
      <section anchor="entity-overview">
        <name>Entity Overview</name>
        <t>This document uses the term "entity" to refer to the target of an EAT.
Most of the claims defined in this document are claims about an entity.
An entity is equivalent to a target environment in an attester as defined in <xref target="RFC9334"/>.</t>
        <t>Layered attestation and composite devices, as described in <xref target="RFC9334"/>, are supported by a submodule mechanism (see <xref target="submods"/>).
Submodules allow nesting of EATs and of claims-sets so that such hierarchies can be modeled.</t>
        <t>An entity is the same as a "system component", as defined in the Internet Security Glossary <xref target="RFC4949"/>.</t>
        <t>Note that <xref target="RFC4949"/> defines "entity" and "system entity" as synonyms, and that they may be a person or organization in addition to being a system component.
In the EAT context, "entity" never refers to a person or organization.
The hardware and software that implement a web site website server or service may be an entity in the EAT sense, but the organization that operates, maintains maintains, or hosts the web site website is not an entity.</t>
        <t>Some examples of entities:</t>
        <ul spacing="normal">
          <li>
            <t>A Secure Element</t>
          </li>
          <li>
            <t>A Trusted Execution Environment (TEE)</t>
          </li>
          <li>
            <t>A network card in a router</t>
          </li>
          <li>
            <t>A router, perhaps with each network card in the router being a submodule</t>
          </li>
          <li>
            <t>An Internet of Things (IoT) IoT device</t>
          </li>
          <li>
            <t>An individual process</t>
          </li>
          <li>
            <t>An app on a smartphone</t>
          </li>
          <li>
            <t>A smartphone with many submodules for its many subsystems</t>
          </li>
          <li>
            <t>A subsystem in a smartphone like such as the modem or the camera</t>
          </li>
        </ul>
        <t>An entity may have strong security defenses against hardware invasive hardware-invasive attacks.
It may also have low security, i.e., having no special security defenses.
There is no minimum security requirement to be an entity.</t>
      </section>
      <section anchor="eat-as-a-framework">
        <name>EAT as a Framework</name>

<!--[rfced] Section 1.2. Please clarify the latter part of this
sentence. Is the intended meaning that EAT is not used for
specific token definition as shown below?

Original:
   EAT is a framework for defining attestation tokens for specific use
   cases, not a specific token definition.

Perhaps:
   EAT is a framework that is used for defining attestation tokens for
   specific use cases; it is not used for specific token definition.
-->

        <t>EAT is a framework for defining attestation tokens for specific use cases, not a specific token definition.
While EAT is based on and compatible with CWT and JWT, it can also be described as:</t>
        <ul spacing="normal">
          <li>
            <t>An identification and type system for claims in claims-sets</t>
          </li>
          <li>
            <t>Definitions of common attestation-oriented claims</t>
          </li>
          <li>
            <t>Claims defined in CDDL Concise Data Definition Language (CDDL) and serialized using CBOR or JSON</t>
          </li>
          <li>
            <t>Security envelopes based on CBOR Object Signing and Encryption (COSE) and Javascript JSON Object Signing and Encryption (JOSE)</t>
          </li>
          <li>
            <t>Nesting
            <t>The nesting of claims sets and tokens to represent complex and compound devices</t>
          </li>
          <li>
            <t>A profile mechanism for specifying and identifying specific tokens for specific use cases</t>
          </li>
        </ul>

        <t>EAT uses the name/value pairs to identify individual claims the same way as CWT and JWT to identify individual claims. JWT. <xref target="theclaims"/> defines common attestation-oriented claims that are have been added to the CWT "CBOR Web Token (CWT) Claims" and JWT "JSON Web Token Claims" IANA registries. As with CWT and JWT, no claims are mandatory and claims not recognized should be ignored.</t>
        <t>Unlike, but
        <t>Unlike (but compatible with with) CWT and JWT, EAT defines claims using Concise Data Definition Language (CDDL) CDDL <xref target="RFC8610"/>.
In most cases cases, the same CDDL definition is used for both the CBOR/CWT serialization and the JSON/JWT serialization.</t>
        <t>Like CWT and JWT, EAT uses COSE and JOSE to provide authenticity, integrity integrity, and optionally confidentiality.
EAT places no new restrictions on cryptographic algorithms, retaining all the cryptographic flexibility of CWT, COSE, JWT JWT, and JOSE.</t>
        <t>EAT defines a means for nesting tokens and claims sets to accommodate composite devices that have multiple subsystems and multiple attesters.
Tokens with security envelopes or bare claims sets may be embedded in an enclosing token.
The nested token and the enclosing token do not have to use the same encoding (e.g., a CWT may be enclosed in a JWT).</t>
        <t>EAT adds the ability to detach claims sets and send them separately from a security-enveloped EAT that contains a digest of the detached claims set.</t>
        <t>This document registers no media or content types for the identification of the type of EAT, its EAT type, serialization encoding encoding, or security envelope.
	The definition and registration of EAT media types is are addressed in <xref target="I-D.ietf-rats-eat-media-type"/>.</t>
        <t>Finally,

<!--[rfced] Sections 1.2 and 4.2.18. The term "follow-on documents"
hasn't been used since early RFCs. Would it be clearer to say
"subsequent documents" as shown below? Note that there are 2 instances.

Original:
   Finally, the notion of an EAT profile is introduced that facilitates
   the creation of narrowed definitions of EATs for specific use cases in
   follow-on documents.
   [...]

   Nested tokens can be one of three types as defined in this document or
   types standardized in follow-on documents (e.g., [UCCS]).

Perhaps:
   Finally, this document introduces the notion of an EAT profile that
   facilitates the creation of narrowed definitions of EATs for
   specific use cases in subsequent documents.
   [...]

   Nested tokens can be one of three types as defined in this document or
   types that are standardized in subsequent documents (e.g., [UCCS]).
-->

        <t>Finally, the notion of an EAT profile that facilitates the creation of narrowed definitions of EATs for specific use cases in follow-on documents is introduced.
One basic profile for constrained devices is normatively defined.</t>
      </section>
      <section anchor="operating-model-and-rats-architecture">
        <name>Operating Model and RATS Architecture</name>
        <t>EAT follows the operational model described in Figure 1 in of RATS Architecture <xref target="RFC9334"/>. (<xref target="RFC9334" sectionFormat="of" section="3"/>).
To summarize, an attester generates evidence in the form of a claims set describing various characteristics of an entity.
Evidence is usually signed by a key that proves the attester and the evidence it produces are authentic.
The claims set either includes a received nonce or uses some other means to assure freshness.</t>
        <t>A verifier confirms an EAT is valid by verifying the signature and may vet some claims using reference values.
The verifier then produces attestation results, which may also be represented as an EAT.
The attestation results are provided to the relying party, which is the ultimate consumer of the Remote Attestation Procedure. RAT.
The relying party uses the attestation results as needed for its use case, perhaps allowing an entity to access a network, allowing a financial transaction transaction, or such.
In some cases, the verifier and relying party are not distinct entities.</t>
        <section anchor="relationship">
          <name>Relationship between Evidence and Attestation Results</name>
          <t>Any claim defined in this document or in the IANA CWT "CBOR Web Token (CWT) Claims" or JWT registry "JSON Web Token Claims" registries may be used in evidence or attestation results. The relationship of claims in attestation results to evidence is fundamentally governed by the verifier and the verifier's policy.</t>
          <t>A common use case is for the verifier and its policy to perform checks, calculations calculations, and processing with evidence as the input to produce a summary result in attestation results that indicates the overall health and status of the entity.
For example, measurements in evidence may be compared to reference values values, the results of which are represented as a simple pass/fail in attestation results.</t>
          <t>It is also possible that some claims in the Evidence evidence will be forwarded unmodified to the relying party in attestation results.
This forwarding is subject to the verifier's implementation and policy.
The relying party should be aware of the verifier's policy to know what checks it has performed on claims it forwards.</t>
          <t>The verifier may modify claims it forwards, for example, to implement a privacy preservation functionality. It is also possible the verifier will put claims in the attestation results that give details about the entity that it has computed or looked up in a database.
For example, the verifier may be able to put an "oemid" claim in the attestation results by performing a look up lookup based on a "ueid" claim (e.g., serial number) it received in evidence.</t>
          <t>This specification does not establish any normative rules for the verifier to follow, as these are a matter of local policy.
It is up to each relying party to understand the processing rules of each verifier to know how to interpret claims in attestation results.</t>
        </section>
      </section>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
    "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

      <t>In this document, the structure of data is specified in CDDL <xref target="RFC8610"/> <xref target="RFC9165"/>.</t>
      <t>The examples in <xref target="examples"/> use CBOR diagnostic notation defined in <xref section="8" sectionFormat="of" target="RFC8949"/> and <xref section="G" sectionFormat="of" target="RFC8610"/>.</t>
      <t>This document reuses terminology from JWT <xref target="RFC7519"/> and CWT <xref target="RFC8392"/>:</t>
      <dl>
        <dt>base64url-encoded:</dt>
        <dd>
          <t>base64url-encoded

<!--[rfced] Section 2. We note that RFC 7515 (Section 2) defines
"base64url encoding" rather than "base64url encoded". Would you
like to update the terminology list to match RFC 7515, or is this
variance okay?

Original:
   base64url-encoded:  base64url-encoded is as described in [RFC7515],
      i.e., using URL- and filename-safe character set [RFC4648] with
      all trailing '=' characters omitted and without the inclusion of
      any line breaks, whitespace, or other additional characters.

Perhaps:
   base64url encoding:  As defined in [RFC7515], base64 encoding
      uses a URL- and filename-safe character set [RFC4648] with
      all trailing '=' characters omitted and without the
      inclusion of any line breaks, whitespace, or other additional
      characters.
-->

      <dl>
        <dt>base64url encoded:</dt>
        <dd>
          <t>As described in <xref target="RFC7515"/>, i.e., using a URL- and filename-safe character set <xref target="RFC4648"/> with all trailing '=' characters omitted and without the inclusion of any line breaks, whitespace, or other additional characters.</t>
        </dd>
        <dt>Claim:</dt>
        <dd>
          <t>A piece of information asserted about a subject. A claim is represented as a value and either a name or a key to identify it.</t>
        </dd>
        <dt>Claim Name:</dt>
        <dd>
          <t>A unique text string that identifies the claim. It is used as the claim name for JSON encoding.</t>
        </dd>
        <dt>Claim Key:</dt>
        <dd>
          <t>The

<!--[rfced] Section 2. We added a citation to RFC 9052 for "COSE" for easy
reference. If that is not correct or desired, please let us know.

Original:
   Claim Key:  The CBOR map key used to identify a claim.  (The term
      "Claim Key" comes from CWT.  This document, like COSE, uses the
      term "label" to refer to CBOR map keys to avoid confusion with
      cryptographic keys.)

Current:
   Claim Key:  The CBOR map key used to identify a claim.  (The term
      "Claim Key" comes from CWT.  This document, like COSE [RFC9052],
      uses the term "label" to refer to CBOR map keys to avoid
      confusion with cryptographic keys.)
-->

          <t>The CBOR map key used to identify a claim. (The term "Claim Key" comes from CWT. This document, like COSE <xref target="RFC9052"/>, uses the term "label" to refer to CBOR map keys to avoid confusion with cryptographic keys.)</t>
        </dd>
        <dt>Claim Value:</dt>
        <dd>
          <t>The value portion of the claim. A claim value can be any CBOR data item or JSON value.</t>
        </dd>
        <dt>Claims Set:</dt>
        <dd>
          <t>The CBOR map or JSON object that contains the claims conveyed by the CWT or JWT.</t>
        </dd>
      </dl>
      <t>This document reuses terminology from RATS Architecure Architecture <xref target="RFC9334"/>:</t>
      <dl>
        <dt>Attester:</dt>
        <dd>
          <t>A role performed by an entity (typically a device) whose evidence must be appraised in order to infer the extent to which the attester is considered trustworthy, such as when deciding whether it is authorized to perform some operation.</t>
        </dd>
        <dt>Verifier:</dt>
        <dd>
          <t>A role that appraises the validity of evidence about an attester and produces attestation results to be used by a relying party.</t>
        </dd>
        <dt>Relying Party:</dt>
        <dd>
          <t>A role that depends on the validity of information about an attester, attester for purposes of reliably applying application specific application-specific actions. Compare /relying party/ For comparison, see "relying party" in <xref target="RFC4949"/>.</t>
        </dd>
        <dt>Evidence:</dt>
        <dd>
          <t>A set of claims generated by an attester to be appraised by a verifier. Evidence may include configuration data, measurements, telemetry, or inferences.</t>
        </dd>
        <dt>Attestation Results:</dt>
        <dd>
          <t>The output generated by a verifier, typically including information about an attester, where the verifier vouches for the validity of the results</t> results.</t>
        </dd>
        <dt>Reference Values:</dt>
        <dd>
          <t>A set of values against which values of claims can be compared as part of applying an appraisal policy for evidence.  Reference Values values are sometimes referred to in other documents as known-good values, golden measurements, "known-good values", "golden measurements", or nominal values, "nominal values", although those terms typically assume comparison for equality, equality whereas here reference values in this document might be more general and be used in any sort of comparison.</t>
        </dd>
        <dt>Endorsement:</dt>
        <dd>
          <t>A secure statement that an Endorser endorser vouches for the integrity of an attester's various capabilities such as claims collection and evidence signing.</t>
        </dd>
      </dl>
      <t>This document reuses terminology from CDDL <xref target="RFC8610"/>:</t>
      <dl>
        <dt>Group Socket:</dt>
        <dd>
          <t>refers to the
          <t>The mechanism by which a CDDL definition is extended, as described in <xref target="RFC8610"/> and <xref target="RFC9165"/></t> target="RFC9165"/>.</t>
        </dd>
      </dl>
    </section>
    <section anchor="top-level-token-definition">
      <name>Top-Level Token Definition</name>
      <t>An "EAT" is an encoded (serialized) message message, the purpose of which is to transfer a Claims-Set between two parties.
An EAT <bcp14>MUST</bcp14> contain a Claims-Set.
In this document document, an EAT is always a CWT or JWT.</t>
      <t>An EAT <bcp14>MUST</bcp14> have authenticity and integrity protection.
CWT and JWT provide that in this document.</t>
      <t>Further documents may define other encodings and security mechanims mechanisms for EAT.</t>
      <t>The identification of a protocol element as an EAT follows the general conventions used for CWTs and JWTs.
Identification depends on the protocol carrying the EAT.
In some cases cases, it may be by media type (e.g., in a an HTTP Content-Type field).
In other cases cases, it may be through use of CBOR tags.
There is no fixed mechanism across all use cases.</t>
      <t>This document also defines another message, the detached EAT bundle (see <xref target="DEB"/>), which holds a collection of detached claims sets and an EAT that provides integrity and authenticity protection for them.
Detached EAT bundles can be either CBOR or JSON encoded.</t>
      <t>The following CDDL defines the top-level <tt>$EAT-CBOR-Tagged-Token</tt>, <tt>$EAT-CBOR-Untagged-Token</tt> <tt>$EAT-CBOR-Untagged-Token</tt>, and <tt>$EAT-JSON-Token-Formats</tt> sockets (see <xref section="3.9" sectionFormat="of" target="RFC8610"/>), enabling future token formats to be defined.
Any new format that plugs into one or more of these sockets <bcp14>MUST</bcp14> be defined by an IETF standards action. Standards Action <xref target="RFC8126"/>.
Of particular use may be a token type that provides no direct authenticity or integrity protection for use with transports transport mechanisms that do provide the necessary security services <xref target="I-D.ietf-rats-uccs"/>.</t>
      <t>Nesting of EATs is allowed and defined in <xref target="Nested-Token"/>.
This includes the nesting of an EAT that is in a different format than the enclosing EAT, i.e., the nested EAT may be encoded using CBOR and the enclosing EAT encoded using JSON or vice versa.
The definition of Nested-Token references the CDDL defined in this section.
When new token formats are defined, the means for identification in a nested token <bcp14>MUST</bcp14> also be defined.</t>
      <t>The top-level CDDL type for CBOR-encoded EATs is EAT-CBOR-Token and for JSON JSON-encoded EATs is EAT-JSON-Token (while CDDL and CDDL tools provide enough support for shared definitions of most items in this document, they do not provide enough support for this sharing at the top level).</t>
      <sourcecode type="CDDL"><![CDATA[
EAT-CBOR-Token = $EAT-CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token

$EAT-CBOR-Tagged-Token /= CWT-Tagged-Message
$EAT-CBOR-Tagged-Token /= BUNDLE-Tagged-Message

$EAT-CBOR-Untagged-Token /= CWT-Untagged-Message
$EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message
]]></sourcecode> BUNDLE-Untagged-Message]]></sourcecode>

      <sourcecode type="CDDL"><![CDATA[
EAT-JSON-Token = $EAT-JSON-Token-Formats

$EAT-JSON-Token-Formats /= JWT-Message
$EAT-JSON-Token-Formats /= BUNDLE-Untagged-Message
]]></sourcecode> BUNDLE-Untagged-Message]]></sourcecode>

    </section>
    <section anchor="theclaims">
      <name>The Claims</name>
      <t>This section describes new claims defined for attestation that are to be have been added to the CWT IANA "CBOR Web Token (CWT) Claims" <xref target="IANA.CWT.Claims"/> and JWT "JSON Web Token Claims" <xref target="IANA.JWT.Claims"/> IANA registries.</t>
      <t>All definitions, requirements, creation and validation procedures, security considerations, IANA registrations registrations, and so on from CWT and JWT carry over to EAT.</t>
      <t>This section also describes how several extant CWT and JWT claims apply in EAT.</t>
      <t>The set of claims that an EAT must contain to be considered valid is context dependent and is outside the scope of this specification.
Specific applications of EATs will require implementations to understand and process some claims in particular ways.
However, in the absence of such requirements, all claims that are not understood by implementations <bcp14>MUST</bcp14> be ignored.</t>
      <t>CDDL, along with a text description, is used to define each claim
independent of encoding.  Each claim is defined as a CDDL group.
In <xref target="encoding"/> on encoding, target="encoding">"Encoding and Collected CDDL"</xref>, the CDDL groups turn into CBOR map entries and JSON name/value pairs.</t>
      <t>Each claim defined in this document is added to the <tt>$$Claims-Set-Claims</tt> group socket. Claims defined by other specifications <bcp14>MUST</bcp14> also be added to the <tt>$$Claims-Set-Claims</tt> group socket.</t>
      <t>All claims in an EAT <bcp14>MUST</bcp14> use the same encoding except where otherwise explicitly stated (e.g., in a CBOR-encoded token, all claims must be CBOR-encoded).</t> encoded with CBOR).</t>

<!--[rfced] Section 4. Can "of most of what is defined" be rephrased
for clarity as shown below?

Original:
   This specification includes a CDDL definition of most of what is
   defined in [RFC8392].  Similarly, this specification includes CDDL
   for most of what is defined in [RFC7519].

Perhaps:
   This specification includes a CDDL definition that is based on the
   CDDL definitions in [RFC8392] and [RFC7519].
-->

      <t>This specification includes a CDDL definition of most of what is defined in <xref target="RFC8392"/>. Similarly, this specification includes CDDL for most of what is defined in <xref target="RFC7519"/>.
These definitions are in <xref target="CDDL_for_CWT"/> and are not normative.</t>
      <t>Each claim described has a unique text string and integer that identifies it.
CBOR-encoded tokens <bcp14>MUST</bcp14> use only use the integer for claim keys.
JSON-encoded tokens <bcp14>MUST</bcp14> use only use the text string for claim names.</t>
      <section anchor="nonce">
        <name>eat_nonce (EAT Nonce) Claim</name>
        <t>An EAT nonce is either a byte or byte, a text string string, or an array of byte bytes or text strings.
	The array option supports multistage EAT verification and consumption.</t>

        <t>A claim named "nonce" was defined for JWT and registered with IANA for JWT, in the "JSON Web Token Claims" registry, but it <bcp14>MUST NOT</bcp14> be used because it does not support multiple nonces. No previous "nonce" claim was defined for CWT.
To distinguish from the previously defined JWT "nonce" claim, this claim is named "eat_nonce" in JSON-encoded EATs. The CWT nonce defined
here is intended for general purpose use and retains the "Nonce" claim name instead of an EAT-specific name.</t>
        <t>An EAT nonce <bcp14>MUST</bcp14> have at least 64 bits of entropy.
A maximum EAT nonce size is set to limit the memory required for an implementation.
All receivers <bcp14>MUST</bcp14> be able to accommodate the maximum size.</t>
        <t>In CBOR, an EAT nonce is a byte string between 8 and 64 bytes in length.
In JSON, an EAT nonce is a text string between 8 and 88 bytes in length.</t>

        <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //=
    (nonce-label => nonce-type / [ 2* nonce-type ])

nonce-type = JC< tstr .size (8..88), bstr .size (8..64)>

]]></sourcecode> (8..64)>]]></sourcecode>

      </section>
      <section anchor="claims-describing-the-entity">
        <name>Claims Describing the Entity</name>
        <t>The claims in this section describe the entity itself.
They describe the entity whether they occur in evidence or occur in attestation results.
See <xref target="relationship"/> for discussion on how attestation results relate to evidence.</t>
        <section anchor="UEID">
          <name>ueid (Universal Entity ID) Claim</name>
          <t>The "ueid" claim conveys a UEID, which identifies an individual manufactured entity like such as a mobile phone, a water meter, a Bluetooth speaker speaker, or a networked
security camera. It may identify the entire entity or a submodule.
It does not identify types, models models, or classes of
entities. It is akin to a serial number, though it does not have to be
sequential.</t>
          <t>UEIDs <bcp14>MUST</bcp14> be universally and globally unique across manufacturers
and countries, as described in <xref target="UEIDCreateRules"/>. UEIDs <bcp14>MUST</bcp14> also be unique across protocols and systems,
as tokens are intended to be embedded in many different protocols and
systems. No two products anywhere, even in completely different
industries made by two different manufacturers in two different
countries
countries, should have the same UEID (if they are not global and
universal in this way, then relying parties receiving them will have
to track other characteristics of the entity to keep entities distinct
between manufacturers).</t>
          <t>UEIDs are not designed for direct use by humans (e.g., printing on
the case of a device), so no such representation is defined.</t>
          <t>There are privacy considerations for UEIDs. See <xref target="ueidprivacyconsiderations"/>.</t>
          <t>A Device Identifier (DevID) URN is registered for UEIDs. See <xref target="registerueidurn"/>.</t>

          <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (ueid-label => ueid-type)

ueid-type = JC<base64-url-text .size (10..44) , bstr .size (7..33)>
]]></sourcecode> (7..33)>]]></sourcecode>

          <section anchor="UEIDCreateRules">
            <name>Rules for Creating UEIDs</name>
            <t>These rules are solely for the creation of UEIDs.
The EAT consumer need not have any awareness of them.</t>
            <t>A UEID is constructed of a single type byte followed by the unique bytes for that type.
The type byte assures global uniqueness of a UEID even if the unique bytes for different types are accidentally the same.</t>
            <t>UEIDS are of variable length to accommodate the types defined here and as well as future-defined types.</t>
            <t>UEIDs <bcp14>SHOULD NOT</bcp14> be longer than 33 bytes.
If they are longer, there is no guarantee that a receiver will be able to accept them.
See <xref target="UEID-Design"/>.</t>
            <t>A UEID is permanent. It <bcp14>MUST NOT</bcp14> change for a given entity.</t>
            <t>The different types of UEIDs 1) accommodate different manufacturing processes, 2) accommodate small UEIDs, and 3) provide an option that does not require registration fees and central administration.</t>
            <t>In the unlikely event that a new UEID type is needed, it <bcp14>MUST</bcp14> be defined in a standards-track an update to this document.</t> document on the Standards Track.</t>
            <t>A manufacturer of entities <bcp14>MAY</bcp14> use different types for different products.
They <bcp14>MAY</bcp14> also change from one type to another for a given product or use one type for some items of a given product and another type for other.</t> others.</t>
            <table align="left" anchor="ueid-types-table">
              <name>UEID Composition Types</name>
              <thead>
                <tr>
                  <th align="left">Type Byte</th>
                  <th align="left">Type Name</th>
                  <th align="left">Specification</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td align="left">0x01</td>
                  <td align="left">RAND</td>
                  <td align="left">This is a 128, 192 128-, 192-, or 256-bit random number generated once and stored in the entity. This may be constructed by concatenating enough identifiers to make up an equivalent number of random bits and then feeding the concatenation through a cryptographic hash function. It may also be a cryptographic quality random number generated once at the beginning of the life of the entity and stored. It <bcp14>MUST NOT</bcp14> be smaller than 128 bits. See the length analysis in <xref target="UEID-Design"/>.</td>
                </tr>
                <tr>
                  <td align="left">0x02</td>
                  <td align="left">IEEE EUI</td>
                  <td align="left">This makes use of the device identification scheme operated by the IEEE. An EUI Extended Unique Identifier (EUI) is either an EUI-48, EUI-60 EUI-60, or EUI-64 and that is made up of an OUI, OUI-36 Organizationally Unique Identifier (OUI), an OUI-36, or a CID, Company ID (CID), which are different registered company identifiers, identifiers and some unique per-entity identifier. identifiers. EUIs are often the same as or similar to MAC addresses. This type includes MAC-48, an obsolete name for EUI-48. (Note that while entities with multiple network interfaces may have multiple MAC addresses, there is only one UEID for an entity; changeable MAC addresses that do not meet the permanence requirements in this document <bcp14>MUST NOT</bcp14> be used for the UEID or SUEID) Semi-permanent UEID (SUEID).)  See <xref target="IEEE.802-2001"/>, target="IEEE.802-2001"/> and <xref target="OUI.Guide"/>.</td>
                </tr>
                <tr>
                  <td align="left">0x03</td>
                  <td align="left">IMEI</td>
                  <td align="left">This makes use of the International Mobile Equipment Identity (IMEI) scheme operated by the GSMA. Global System for Mobile Communications Association (GSMA). This is a 14-digit identifier consisting of an 8-digit Type Allocation Code (TAC) and a 6-digit serial number allocated by the manufacturer, which <bcp14>SHALL</bcp14> be encoded as a byte string of length 14 with each byte as the digit's value (not the ASCII encoding of the digit; the digit 3 encodes as 0x03, not 0x33). The IMEI value encoded value <bcp14>SHALL NOT</bcp14> include the Luhn checksum or SVN Software Version Number (SVN) information. See <xref target="ThreeGPP.IMEI"/>.</td>
                </tr>
              </tbody>
            </table>
          </section>
          <section anchor="rules-for-consuming-ueids">
            <name>Rules for Consuming UEIDs</name>
            <t>For the consumer, a UEID is solely a globally unique opaque identifier.
The consumer does not and should not have any awareness of the rules and structure used to achieve global uniqueness.</t>
            <t>All implementations <bcp14>MUST</bcp14> be able to receive UEIDs up to 33 bytes long.
33 bytes is the longest defined in this document and gives necessary entropy for probabilistic uniqueness.</t>
            <t>The consumer of a UEID <bcp14>MUST</bcp14> treat it as a completely opaque string of bytes and <bcp14>MUST NOT</bcp14> make any use of its internal structure.
The reasons for this are:</t>
            <ul spacing="normal">
              <li>
                <t>UEIDs
                <t>UEID types vary freely from one manufacturer to the next.</t>
              </li>
              <li>
                <t>New types of UEIDs may be defined.</t>
              </li>
              <li>
                <t>The manufacturer of an entity is allowed to change from one type of UEID to another anytime they want.</t>
              </li>
            </ul>
            <t>For example, when the consumer receives a type 0x02 UEID, they should not use the OUI part to identify the manufacturer of the device because there is no guarantee all UEIDs will be type 0x02.
Different manufacturers may use different types.
A manufacturer may make some of their product with one type and others with a different type or even change to a different type for newer versions of their product.
Instead, the consumer should use the "oemid" claim.</t>
          </section>
        </section>
        <section anchor="sueids-semi-permanent-ueids-claim-sueids">

<!--[rfced] Section Titles

a) Should the title of Section 4.2.2 be updated as shown
below (i.e., remove "(SUEIDs)") for consistency with the
other section titles? (See the separate question re: removing
the hyphen in 'semipermanent'.)

Original:
   4.2.1.  ueid (Universal Entity ID) Claim
   4.2.2.  sueids (Semi-permanent UEIDs) Claim (SUEIDs)

Perhaps:
   4.2.1.  ueid (Universal Entity ID) Claim
   4.2.2.  sueids (Semipermanent UEIDs) Claim

...
b) Should the title of Section 4.2.18 contain "Claim" for
consistency?

Original:
   4.2.16. measurements (Measurements) Claim
   4.2.17. measres (Software Measurement Results) Claim
   4.2.18  submods (Submodules)

Perhaps:
   4.2.16. measurements (Measurements) Claim
   4.2.17. measres (Software Measurement Results) Claim
   4.2.18  submods (Submodules) Claim
-->

          <name>sueids (Semi-permanent UEIDs) Claim (SUEIDs)</name>
          <t>The "sueids" claim conveys one or more semi-permanent UEIDs (SUEIDs). An SUEID has the same format, characteristics characteristics, and requirements as a UEID, UEID but <bcp14>MAY</bcp14> change to a different value on entity life-cycle events.
An entity <bcp14>MAY</bcp14> have both a UEID and SUEIDs, neither, or one or the other.</t>
          <t>Examples of life-cycle events are change of ownership, factory reset reset, and on-boarding onboarding into an IoT device management system.
It is beyond the scope of this document to specify particular types of SUEIDs and the life-cycle events that trigger their change.
An EAT profile <bcp14>MAY</bcp14> provide this specification.</t>
          <t>There <bcp14>MAY</bcp14> be multiple SUEIDs. Each has a text string label label, the purpose of which is to distinguish it from others.
The label <bcp14>MAY</bcp14> name the purpose, application application, or type of the SUEID.
For example, the label for the SUEID used by the XYZ Onboarding Protocol could thus be "XYZ". It is beyond the scope of this document to specify any SUEID labeling schemes.
They are use case specific and <bcp14>MAY</bcp14> be specified in an EAT profile.</t>
          <t>If there is only one SUEID, the claim remains a map and there still <bcp14>MUST</bcp14> be a label.</t>
          <t>An SUEID provides functionality similar to an IEEE LDevID Local Device Identifier (LDevID) <xref target="IEEE.802.1AR"/>.</t>
          <t>There are privacy considerations for SUEIDs. See SUEIDs; see <xref target="ueidprivacyconsiderations"/>.</t>
          <t>A Device Identifier DevID URN is registered for SUEIDs. See SUEIDs; see <xref target="registerueidurn"/>.</t>

          <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (sueids-label => sueids-type)

sueids-type = {
    + tstr => ueid-type
}
]]></sourcecode>
}]]></sourcecode>

        </section>
        <section anchor="oemid">
          <name>oemid (Hardware OEM Identification) ID) Claim</name>
          <t>The "oemid" claim identifies the Original Equipment Manufacturer (OEM) of the hardware.
Any of the three forms described below <bcp14>MAY</bcp14> be used at the convenience of the claim sender.
The receiver of this claim <bcp14>MUST</bcp14> be able to handle all three forms.</t>
          <t>Note that the "hwmodel" claim in <xref target="hwmodel"/>, the "oemboot" claim in <xref target="oemboot"/> target="oemboot"/>, and the "dbgstat" claim in <xref target="dbgstat"/> depend on this claim.</t>
          <t>Sometimes one manufacturer will acquire or merge with another.
Depending on the situation and use case case, newly manfactured manufactured devices may continue to use the old OEM ID or switch to a new one.
This is left to the discretion of the manufacturers, but they should consider how it affects the above-mentioned claims and the attestation eco-system ecosystem for their devices.
The considerations are the same for all three forms of this claim.</t>
          <section anchor="random-number-based-oem-id">
            <name>Random Number Based Number-Based OEM ID</name>
            <t>The random number based number-based OEM ID <bcp14>MUST</bcp14> be 16 bytes (128 bits) long.</t>
            <t>The OEM may create their own ID by using a cryptographic-quality random number generator.
They would perform this only once in the life of the company to generate the single ID for said company.
They would use that same ID in every entity they make.
This uniquely identifies the OEM on a statistical basis and is large enough should there be ten billion companies.</t>
            <t>In JSON-encoded tokens tokens, this <bcp14>MUST</bcp14> be base64url-encoded.</t> base64url encoded.</t>
          </section>
          <section anchor="ieee-based-oem-id">
            <name>IEEE Based
            <name>IEEE-Based OEM ID</name>
            <t>The IEEE operates a global registry for MAC addresses and company IDs.
This claim uses that database to identify OEMs. The contents of the
claim may be either an IEEE MA-L, MA-M, MA-S MA-S, or an IEEE CID <xref target="IEEE-RA"/>.  An MA-L (formerly known as an OUI) is a 24-bit value
used as the first half of a MAC address. Similarly, MA-M is a 28-bit
value used as the first part of a MAC address, and MA-S (formerly
known as OUI-36) is a 36-bit value.

<!--[rfced] Section 4.2.3.2. Please clarify what "these" refers to in
"Many companies already have purchased one of these" (last sentence).

Original:
   The IEEE operates a global registry for MAC addresses and company
   IDs.  This claim uses that database to identify OEMs.  The contents
   of the claim may be either an IEEE MA-L, MA-M, MA-S, or CID
   [IEEE-RA].  An MA-L, formerly known as an OUI, is a 24-bit value used
   as the first half of a MAC address.  Similarly, MA-M similarly is a 28-bit
   value uses used as the first part of a MAC address, and MA-S, formerly
   known as OUI-36, is a 36-bit value.  Many companies already have
   purchased one of these.
-->

Many companies already have purchased
one of these. A CID is also a 24-bit value from the same space as an
MA-L,
MA-L but is not for use as a MAC address.  IEEE has published Guidelines
for Use of EUI, OUI, and CID <xref target="OUI.Guide"/> and provides a lookup
service <xref target="OUI.Lookup"/>.</t>
            <t>Companies that have more than one of these IDs or MAC address blocks
<bcp14>SHOULD</bcp14> select one as preferred and prefer use that for all their entities.</t>
            <t>Commonly, these are expressed in Hexadecimal Representation hexadecimal representation as described in
<xref target="IEEE.802-2001"/>. It is also called the Canonical canonical format. When this claim is
encoded
encoded, the order of bytes in the bstr are is the same as the order in the
Hexadecimal Representation.
hexadecimal representation. For example, an MA-L like "AC-DE-48" would
be encoded in 3 bytes with values 0xAC, 0xDE, and 0x48.</t>
            <t>This format is always 3 bytes in size in CBOR.</t>
            <t>In JSON-encoded tokens, this <bcp14>MUST</bcp14> be base64url-encoded base64url encoded and always 4 bytes.</t>
          </section>
          <section anchor="iana-private-enterprise-number-based-oem-id">
            <name>IANA Private Enterprise Number Based Number-Based OEM ID</name>
            <t>IANA

<!--[rfced] Section 4.2.3.3. This sentence cites the application
for PENs (https://pen.iana.org/pen/PenApplication.page), so it seems
either the text or the reference should be updated. Which do you prefer?

Original:
   IANA maintains a registry for Private Enterprise Numbers [PEN].

where
   [PEN]      "Private Enterprise Number (PEN) Request", n.d.,
              <https://pen.iana.org/pen/PenApplication.page>.

Option A (if the reference remains the same):
   IANA maintains the application for Private Enterprise
   Numbers [PEN].

Option B (if the reference is changed to the registry itself):

   IANA maintains a registry for Private Enterprise Numbers [PEN].

where:
   [PEN]  IANA, "Private Enterprise Numbers (PENs)",
          <https://www.iana.org/assignments/enterprise-numbers/>.
-->

            <t>IANA maintains a registry for Private Enterprise Numbers <xref target="PEN"/>. A PEN is an integer that identifies an enterprise enterprise, and it may be
used to construct an object identifier (OID) relative to the following OID arc that is managed by IANA: iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1).</t>
            <t>For EAT purposes, only the integer value assigned by IANA as the PEN is relevant, not the full OID value.</t>
            <t>In CBOR CBOR, this value <bcp14>MUST</bcp14> be encoded as a major type 0 integer and is typically 3 bytes.
In JSON, this value <bcp14>MUST</bcp14> be encoded as a number.</t>

            <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (
    oemid-label => oemid-pen / oemid-ieee / oemid-random
)

oemid-pen = int

oemid-ieee = JC<oemid-ieee-json, oemid-ieee-cbor>
oemid-ieee-cbor = bstr .size 3
oemid-ieee-json = base64-url-text .size 4

oemid-random = JC<oemid-random-json, oemid-random-cbor>
oemid-random-cbor = bstr .size 16
oemid-random-json = base64-url-text .size 24

]]></sourcecode> 24]]></sourcecode>

          </section>
        </section>
        <section anchor="hwmodel">
          <name>hwmodel (Hardware Model) Claim</name>
          <t>The "hwmodel" claim differentiates hardware models, products products, and variants manufactured by a particular OEM, namely the one identified by the OEM ID in <xref target="oemid"/>.
It <bcp14>MUST</bcp14> be unique within a given OEM ID.
The concatenation of the OEM ID and "hwmodel" give gives a global identifier of a particular product. The "hwmodel" claim <bcp14>MUST</bcp14> only be present if an "oemid" claim described in <xref target="oemid"/> is present.</t>
          <t>The granularity of the model identification is for each OEM to decide.
It may be very granular, perhaps including some version information.
It may be very general, perhaps only indicating top-level products.</t>
          <t>The "hwmodel" claim is for use in protocols and not for human consumption.
The format and encoding of this claim should not be human-readable human readable to discourage use other than in protocols.
If this claim is to be derived from an already-in-use human-readable identifier, it can be run through a hash function.</t>
          <t>There is no minimum length so that an OEM with a very small number of models can use a one-byte encoding.
The maximum length is 32 bytes.
All receivers of this claim <bcp14>MUST</bcp14> be able to receive this maximum size.</t>
          <t>The receiver of this claim <bcp14>MUST</bcp14> treat it as a completely opaque string of bytes, even if there is some apparent naming or structure.
The OEM is free to alter the internal structure of these bytes as long as the claim continues to uniquely identify its models.</t>

          <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (
    hardware-model-label => hardware-model-type
)

hardware-model-type = JC<base64-url-text .size (4..44),
                         bytes .size (1..32)>
]]></sourcecode> (1..32)>]]></sourcecode>

        </section>
        <section anchor="hwversion-hardware-version-claim">
          <name>hwversion (Hardware Version) Claim</name>
          <t>The "hwversion" claim is a text string the format string, of which the format is set by each manufacturer.
The structure and sorting order of this text string can be specified using the version-scheme item from CoSWID Concise Software Identification (CoSWID) <xref target="RFC9393"/>.
It is useful to know how to sort versions so the newer ones can be distinguished from the older. older ones.
A "hwversion" claim <bcp14>MUST</bcp14> only be present if a "hwmodel" claim claim, as described in <xref target="hwmodel"/> target="hwmodel"/>, is present.</t>

          <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //=  (
    hardware-version-label => hardware-version-type
)

hardware-version-type = [
    version:  tstr,
    ? scheme:  $version-scheme
]
]]></sourcecode>
]]]></sourcecode>

        </section>
        <section anchor="swname">
          <name>swname (Software Name) Claim</name>
          <t>The "swname" claim contains a very simple free-form text value for naming the software used by the entity.
Intentionally, no general rules or structure are set.
This will make it unsuitable for use cases that wish precise naming.</t>
          <t>If precise and rigourous rigorous naming of the software for the entity is needed, the "manifests" claim claim, as described in <xref target="manifests"/> target="manifests"/>, may be used instead.</t>

          <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= ( sw-name-label => tstr )
]]></sourcecode> )]]></sourcecode>

        </section>
        <section anchor="swversion-software-version-claim">
          <name>swversion (Software Version) Claim</name>
          <t>The "swversion" claim makes use of the CoSWID version-scheme defined in <xref target="RFC9393"/> to give a simple version for the software.
	  A "swversion" claim <bcp14>MUST</bcp14> only be present if a "swname" claim claim, as described in <xref target="swname"/> target="swname"/>, is present.</t>

<!--[rfced] Section 4.2.7. A word is missing after "may be". Please
confirm if "used" is the correct word as shown below.

Original:
   The "manifests" claim Section 4.2.15 may be instead if this is too
   simple.

Current:
   The "manifests" claim (Section 4.2.15) may be used instead if this
   is too simple.
-->

          <t>The "manifests" claim <xref target="manifests"/> (<xref target="manifests"/>) may be used instead if this is too simple.</t>

          <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (sw-version-label => sw-version-type)

sw-version-type = [
    version:  tstr
    ? scheme:  $version-scheme
]
]]></sourcecode>
]]]></sourcecode>

        </section>
        <section anchor="oemboot">
          <name>oemboot (OEM Authorized Boot) Claim</name>
          <t>An "oemboot" claim with a value of true "true" indicates that the entity booted with software authorized by the manufacturer of the entity as indicated by the "oemid" claim described in <xref target="oemid"/>.
It indicates that the firmware and operating system are fully under control of the OEM and may not be replaced by the end user or even the enterprise that owns the device.
The means of control may be by cryptographic authentication of the software, by the software being in Read-Only Memory (ROM), a combination of the two two, or other.
If this claim is present present, the "oemid" claim <bcp14>MUST</bcp14> be present.</t>

          <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (oem-boot-label => bool)
]]></sourcecode> bool)]]></sourcecode>

        </section>
        <section anchor="dbgstat">
          <name>dbgstat (Debug Status) Claim</name>

          <t>The "dbgstat" claim applies to entity-wide or submodule-wide debug facilities of the entity like <xref target="JTAG"/> and diagnostic hardware built into
chips. It applies to any software debug facilities related to privileged software that allows system-wide memory
inspection, tracing tracing, or modification of non-system software like user
mode user-mode
applications.</t>
          <t>This characterization assumes that debug facilities can be enabled and
disabled in a dynamic way or be disabled in some permanent way, such
that no enabling is possible. An example of dynamic enabling is one
where some authentication is required to enable debugging. An example
of permanent disabling is blowing a hardware fuse in a chip. The specific
type of the mechanism is not taken into account. For example, it does
not matter if authentication is by a global password or by per-entity
public keys.</t>
          <t>As with all claims, the absence of the "dbgstat" claim means it is not reported.</t>
          <t>This claim is not extensible so as to provide a common interoperable description of debug status.
If a particular implementation considers this claim to be inadequate, it can define its own proprietary claim.
It may consider including both this claim as a coarse indication of debug status and its own proprietary claim as a refined indication.</t>
          <t>The higher levels of debug disabling requires require that all debug disabling
of the levels below it be in effect. Since the lowest level requires
that all of the target's debug be currently disabled, all other levels
require that too.</t>
          <t>There is no inheritance of claims from a submodule to a superior
module or vice versa. There is no assumption, requirement requirement, or guarantee
that the target of a superior module encompasses the targets of
submodules. Thus, every submodule must explicitly describe its own
debug state. The receiver of an EAT <bcp14>MUST NOT</bcp14>
assume that debug is turned off in a submodule because there is a claim
indicating it is turned off in a superior module.</t>
          <t>An entity may have multiple debug
facilities. The use of plural in the description of the states
refers to that, not to any aggregation or inheritance.</t>
          <t>The architecture of some chips or devices may be such that a debug
facility operates for the whole chip or device. If the EAT for such
a chip includes submodules, then each submodule should independently
report the status of the whole-chip or whole-device debug facility.
This is the only way the receiver can know the debug status
of the submodules since there is no inheritance.</t>
          <section anchor="enabled">
            <name>Enabled</name>
            <t>If any debug facility, even manufacturer hardware diagnostics, is
currently enabled, then this level must be indicated.</t>
          </section>
          <section anchor="disabled">
            <name>Disabled</name>
            <t>This level indicates all debug facilities are currently disabled. It
may be possible to enable them in the future. It may also be
that they were enabled in the past, past but they are currently disabled.</t>
          </section>
          <section anchor="disabled-since-boot">
            <name>Disabled Since Boot</name>
            <t>This level indicates all debug facilities are currently disabled and
have been so since the entity booted/started.</t>
          </section>
          <section anchor="disabled-permanently">
            <name>Disabled Permanently</name>
            <t>This level indicates all non-manufacturer facilities are permanently
disabled such that no end user or developer can enable them. Only
the manufacturer indicated in the "oemid" claim can enable them. This
also indicates that all debug facilities are currently disabled and
have been so since boot/start.
If this debug state is reported, the "oemid" claim  <bcp14>MUST</bcp14> be present.</t>
          </section>
          <section anchor="disabled-fully-and-permanently">
            <name>Disabled Fully and Permanently</name>
            <t>This level indicates that all debug facilities for the entity are permanently disabled.</t>

            <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= ( debug-status-label => debug-status-type )

debug-status-type = ds-enabled /
                    disabled /
                    disabled-since-boot /
                    disabled-permanently /
                    disabled-fully-and-permanently

ds-enabled                     = JC< "enabled", 0 >
disabled                       = JC< "disabled", 1 >
disabled-since-boot            = JC< "disabled-since-boot", 2 >
disabled-permanently           = JC< "disabled-permanently", 3 >
disabled-fully-and-permanently =
                       JC< "disabled-fully-and-permanently", 4 >
]]></sourcecode> >]]></sourcecode>

          </section>
        </section>
        <section anchor="location">
          <name>location (Location) Claim</name>

<!-- [rfced] Section 4.2.10. We notice that [W3C.GeoLoc] is listed as
an informative reference, whereas [WGS84] is a normative
reference.  Considering the key word "MUST" in this sentence,
should [W3C.GeoLoc] be listed as a normative reference?

Original:
   Latitude, longitude, altitude, accuracy, altitude-accuracy,
   heading and speed MUST be as defined in the W3C Geolocation
   API [W3C.GeoLoc] (which, in turn, is based on [WGS84]).
 -->
          <t>The "location" claim gives the geographic position of the entity from which the attestation originates.
Latitude, longitude, altitude, accuracy, altitude-accuracy, heading heading, and speed <bcp14>MUST</bcp14> be as defined in the W3C Geolocation API <xref target="W3C.GeoLoc"/>
(which, in turn, is based on <xref target="WGS84"/>). If the entity is stationary, the heading is NaN (floating-point not-a-number). Not a Number (NaN) (i.e., a floating-point NaN). Latitude and longitude <bcp14>MUST</bcp14> be provided.
	  If any other of these values are unknown, they are omitted.</t>

<!--[rfced] Section 4.2.10. With the expansion of "GNSS",
should this be rephrased?

Original:
   For example, it might have been minutes or hours or more
   since the last contact with a GNSS satellite.

Current:
   For example, it might have been minutes, hours, or more
   since the last contact with a Global Navigation Satellite
   System (GNSS) satellite.

Perhaps:
   For example, it might have been minutes, hours, or more
   since the last contact with a satellite in the Global
   Navigation Satellite System (GNSS).
-->
          <t>The location may have been cached for a period of time before token
creation. For example, it might have been minutes or hours minutes, hours, or more
since the last contact with a GNSS Global Navigation Satellite System (GNSS) satellite. Either the timestamp or the age data item can be used to quantify the cached period.  The timestamp data item is preferred as it is a non-relative time.
If the entity has no clock or the clock is unset but has a means to measure the time interval between the acquisition of the location and the token creation creation, the age may be reported instead.
The age is in seconds.</t>
          <t>See location-related privacy considerations in <xref target="locationprivacyconsiderations"/>.</t>

          <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (location-label => location-type)

location-type = {
    latitude => number,
    longitude => number,
    ? altitude => number,
    ? accuracy => number,
    ? altitude-accuracy => number,
    ? heading => number,
    ? speed => number,
    ? timestamp => ~time-int,
    ? age => uint
}

latitude          = JC< "latitude",          1 >
longitude         = JC< "longitude",         2 >
altitude          = JC< "altitude",          3 >
accuracy          = JC< "accuracy",          4 >
altitude-accuracy = JC< "altitude-accuracy", 5 >
heading           = JC< "heading",           6 >
speed             = JC< "speed",             7 >
timestamp         = JC< "timestamp",         8 >
age               = JC< "age",               9 >
]]></sourcecode> >]]></sourcecode>

        </section>
        <section anchor="uptime-uptime-claim">
          <name>uptime (Uptime) Claim</name>
          <t>The "uptime" claim contains the number of seconds that have elapsed since the entity or submodule was last booted.</t>

          <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (uptime-label => uint)
]]></sourcecode> uint)]]></sourcecode>

        </section>
        <section anchor="bootcount-boot-count-claim">
          <name>bootcount (Boot Count) Claim</name>
          <t>The "bootcount" claim contains a count of the number
of times the entity or submodule has been booted. Support for this claim
requires a persistent storage on the device.</t>

          <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (boot-count-label => uint)
]]></sourcecode> uint)]]></sourcecode>

        </section>
        <section anchor="bootseed-boot-seed-claim">
          <name>bootseed (Boot Seed) Claim</name>
          <t>The "bootseed" claim contains a value created at system boot time that allows differentiation of attestation reports from different boot sessions of a particular entity (e.g., a certain UEID).</t>
          <t>This value is usually public.
It is not a secret and <bcp14>MUST NOT</bcp14> be used for any purpose that where a secret seed is needed, such as seeding a random number generator.</t>
          <t>There are privacy considerations for this claim. See claim; see <xref target="bootseedprivacyconsiderations"/>.</t>

          <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //=  (boot-seed-label => binary-data)
]]></sourcecode> binary-data)]]></sourcecode>

        </section>
        <section anchor="dloas">
          <name>dloas (Digital Letters of Approval) Claim</name>
          <t>The "dloas" claim conveys one or more Digital Letters of Approval (DLOAs). A DLOA <xref target="DLOA"/> is a document that describes a certification that an entity has received.
Examples of certifications represented by a DLOA include those issued by Global Platform GlobalPlatform <xref target="GP-Example"/> and those based on Common Criteria <xref target="CC-Example"/>.
The DLOA is unspecific to any particular certification type or those issued by any particular organization.</t>
          <t>This claim is typically issued by a verifier, not an attester.
Verifiers <bcp14>MUST NOT</bcp14> issue this claim unless the entity has received the certification indicated by the DLOA.</t>
          <t>This claim <bcp14>MAY</bcp14> contain more than one DLOA.
If multiple DLOAs are present, verifiers <bcp14>MUST NOT</bcp14> issue this claim unless the entity has received all of the certifications.</t>
          <t>DLOA documents are always fetched from a registrar that stores them.
This claim contains several data items used to construct a Uniform Resource Locator (URL) for fetching the DLOA from the particular registrar.</t>
          <t>This claim <bcp14>MUST</bcp14> be encoded as an array with either two or three elements. The first element <bcp14>MUST</bcp14> be the URL for the registrar.
The second element <bcp14>MUST</bcp14> be a platform label indicating which platform was certified.
If the DLOA applies to an application, then the third element is added added, which <bcp14>MUST</bcp14> be an application label.
The method of constructing the registrar URL, platform label label, and possibly application label is specified in <xref target="DLOA"/>.</t>
          <t>The retriever of a DLOA <bcp14>MUST</bcp14> follow the recommendation in <xref target="DLOA"/> and use TLS Transport Layer Security (TLS) or some other means to be sure the DLOA registrar they are accessing is authentic.
The platform and application labels in the claim indicate the correct DLOA for the entity.</t>

          <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (
    dloas-label => [ + dloa-type ]
)

dloa-type = [
    dloa_registrar: general-uri
    dloa_platform_label: text
    ? dloa_application_label: text
]
]]></sourcecode>
]]]></sourcecode>

        </section>
        <section anchor="manifests">
          <name>manifests (Software Manifests) Claim</name>
          <t>The "manifests" claim contains descriptions of software present on the entity.
These manifests are installed on the entity when the software is installed or are created as part of the installation process.
Installation is anything that adds software to the entity, possibly factory installation, the user installing elective applications applications, and so on.
The defining characteristic of a manifest is that it is created by the software manufacturer.
The purpose of this claim is to relay unmodified manifests to the verifier and possibly to the relying party.</t>
          <t>Some manifests are signed by their software manufacturer independently, and some are not either because either they do not support signing or the manufacturer chose not to sign them.
For example, a CoSWID might be signed independently before it is included in an EAT.
When signed manifests are put into an EAT, the manufacturer's signature <bcp14>SHOULD</bcp14> be included even though an EAT's signature will also cover the manifest.
This allows the receiver to directly verify the manufacturer-originated manifest.</t>
<t>This claim allows multiple manifest formats.

<!--[rfced] Section 4.2.15. Should the word 'tag' be added here,
as the term 'SWID tag' is used in RFC 9393?

Original:
   For example, the manifest may be a CBOR-encoded CoSWID, an
   XML-encoded SWID or other.

Current:
   For example, the manifest may be a CBOR-encoded CoSWID, an
   XML-encoded Software Identification (SWID), or other.

Perhaps:
   For example, the manifest may be a CBOR-encoded CoSWID, an
   XML-encoded Software Identification (SWID) tag, or other.
-->

	  For example, the manifest may be a CBOR-encoded CoSWID, an XML-encoded Software Identification (SWID), or other.

<!--[rfced] Sections 4.2.15 and 4.2.16. RFC 7252 uses Content-Format
"identifier" rather than "integer". Given this, should "integer"
be removed or replaced with "identifier" as shown below for
consistency (3 instances)?

Original:
   Identification of the type of manifest is always by a Constrained
   Application Protocol (CoAP) Content-Format integer [RFC7252].

   The first item in the array of two MUST be an integer CoAP
   Content-Format identifier.

   The identification of format is by CoAP Content Format, the same as
   the "manifests" claim in Section 4.2.15.

Perhaps:
   Identification of the type of manifest is always by a Constrained
   Application Protocol (CoAP) Content-Format identifier [RFC7252].

   The first item in the array of two MUST be a CoAP Content-Format
   identifier.

   The format is identified by a CoAP Content-Format identifier, which
   is the same for the "manifests" claim in Section 4.2.15.
-->

Identification of the type of manifest is always by a Constrained Application Protocol (CoAP) Content-Format integer <xref target="RFC7252"/>.
If there is no CoAP identifier registered for a manifest format, one <bcp14>MUST</bcp14> be registered.</t>
          <t>This claim <bcp14>MUST</bcp14> be an array of one or more manifests.
	  Each manifest in the claim <bcp14>MUST</bcp14> be an array of two. The first item in the array of two <bcp14>MUST</bcp14> be an integer CoAP Content-Format identifier.
The second item is <bcp14>MUST</bcp14> be the actual manifest.</t>
          <t>In JSON-encoded tokens tokens, the manifest, whatever encoding it is, <bcp14>MUST</bcp14> be placed in a text string.
When a non-text encoded manifest like such as a CBOR-encoded CoSWID is put in a JSON-encoded token, the manifest <bcp14>MUST</bcp14> be base-64 base64 encoded.</t>
          <t>This claim allows for multiple manifests in one token since multiple software packages are likely to be present.
The multiple manifests <bcp14>MAY</bcp14> be of different encodings.
In some cases cases, EAT submodules may be used instead of the array structure in this claim for multiple manifests.</t>
          <t>A CoSWID manifest <bcp14>MUST</bcp14> be a payload CoSWID, not an evidence CoSWID.
These are defined in <xref target="RFC9393"/>.</t>
          <t>This claim is extensible for use of manifest formats beyond those mentioned in this document.
No particular manifest format is preferred.
For manifest interoperability, an EAT profile profile, as defined in <xref target="profiles"/>, should be used to specify which manifest format(s) are is allowed.</t>

          <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (
    manifests-label => manifests-type
)

manifests-type = [+ manifest-format]

manifest-format = [
    content-type:   coap-content-format,
    content-format: JC< $manifest-body-json,
                        $manifest-body-cbor >
]

$manifest-body-cbor /= bytes .cbor untagged-coswid
$manifest-body-json /= base64-url-text

]]></sourcecode> base64-url-text]]></sourcecode>

        </section>
        <section anchor="measurements">
          <name>measurements (Measurements) Claim</name>
          <t>The "measurements" claim contains descriptions, lists, evidence evidence, or measurements of the software that exists on the entity or on any other measurable
subsystem of the entity (e.g. (e.g., hash of sections of a file system or non-volatile memory).
The defining characteristic of this claim is that its contents are created by processes on the entity that inventory, measure measure, or otherwise characterize the software on the entity.
	  The contents of this claim do not originate from the manufacturer of the measurable subsystem (e.g. (e.g., developer of a software library).</t>

<!--[rfced] Section 4.2.16. What words are missing after "a"?

Original:
   This claim can be a [RFC9393].

Perhaps:
   This claim can be a CoSWID [RFC9393].
-->

          <t>This claim can be a <xref target="RFC9393"/>.
When the CoSWID format is used, it <bcp14>MUST</bcp14> be an evidence CoSWID, not a payload CoSWID.</t>
<t>Formats other than CoSWID <bcp14>MAY</bcp14> be used. The identification of format is by CoAP Content Format, Content-Format, the same as the "manifests" claim in <xref target="manifests"/>.</t>

          <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (
    measurements-label => measurements-type
)

measurements-type = [+ measurements-format]

measurements-format = [
    content-type:   coap-content-format,
    content-format: JC< $measurements-body-json,
                        $measurements-body-cbor >
]

$measurements-body-cbor /= bytes .cbor untagged-coswid
$measurements-body-json /= base64-url-text

]]></sourcecode> base64-url-text]]></sourcecode>

        </section>
        <section anchor="measurementresults">
          <name>measres (Software Measurement Results) Claim</name>
          <t>The "measres" claim is a general-purpose structure for reporting the comparison of measurements to expected reference values.

<!--[rfced] Section 4.2.17. Should the terms/values listed in these
two paragraphs match for consistency as shown below?

Also, 'success/fail' or 'success/failure' is a corresponding pair
rather than 'successful/fail'. (If this is updated, seemingly the
CDDL below and in Section 7.3.1 would also need an update, e.g.,
'comparison-successful'.)

Current:
   This claim provides a simple standard way to report the result
   of a comparison as success, failure, fail to run, and absence.

   1 - comparison successful:  The comparison to reference values was
       successful.

   2 - comparison fail:  The comparison was completed but did not
       compare correctly to the reference values.

   3 - comparison not run:  The comparison was not run.  This includes
       error conditions such as running out of memory.

   4 - measurement absent:  The particular measurement was not
       available for comparison.

Perhaps:
   This claim provides a simple standard way to report the result
   of a comparison as a success, a failure, not run, or absent.

   1 - comparison success:  The comparison to reference values was
       successful.

   2 - comparison failure:  The comparison was completed but did not
       compare correctly to the reference values.

   3 - comparison not run:  The comparison was not run.  This includes
       error conditions such as running out of memory.

   4 - measurement absent:  The particular measurement was not
       available for comparison.
-->

This claim provides a simple standard way to report the result of a comparison as success, failure, fail to run, and absence.</t>
          <t>It is the nature of measurement systems that they are to be specific to the operating system, software software, and hardware of the entity that is being measured.
It is not possible to standardize what is measured and how it is measured across platforms, OS's, software OSes, software, and hardware.
The recipient must obtain the information about what was measured and what it indicates for the characterization of the security of the entity from the provider of the measurement system.
What this claim provides is a standard way to report basic success or failure of the measurement.
In some use cases cases, it is valuable to know if measurements succeeded or failed in a general way even if the details of what was measured is are not characterized.</t>
          <t>This claim <bcp14>MAY</bcp14> be generated by the verifier and sent to the relying party.
For example, it could be the results of the verifier comparing the contents of the "measurements" claim, <xref target="measurements"/>, claim  (<xref target="measurements"/>) to reference values.</t>
          <t>This claim <bcp14>MAY</bcp14> also be generated on the entity if the entity has the ability for one subsystem to measure and evaluate another subsystem.
For example, a TEE might have the ability to measure the software of the rich OS and may have the reference values for the rich OS.</t>
          <t>Within an entity, attestation target target, or submodule, multiple results can be reported.
For example, it may be desirable to report the results for measurements of the file system, chip configuration, installed software, running software software, and so on.</t>
          <t>Note that this claim is not for reporting the overall result of a verifier.
It is solely for reporting the result of comparison to reference values.</t>
          <t>An individual measurement result (individual-result) is an array consisting of two elements, an identifier of the measurement (result-id) (result-id), and an enumerated type of the result (result).
Different measurement systems will measure different things and perhaps measure the same thing in different ways.
It is up to each measurement system to define identifiers (result-id) for the measurements it reports.</t>
          <t>Each individual measurement result is part of a group that may contain many individual results.
Each group has a text string that names it, typically the name of the measurement scheme or system.</t>
          <t>The claim itself consists of one or more groups.</t>

          <t>The values for the results enumerated type are as follows:</t>
          <dl>
            <dt>1 -- comparison successful:</dt>
            <dd>
              <t>Indicates successful successful:</dt><dd> The comparison to reference values.</t>
            </dd> values was successful.</dd>
            <dt>2 -- comparison fail:</dt>
            <dd>
              <t>The fail:</dt><dd> The comparison was completed and but did not compare correctly to the reference values.</t>
            </dd> values.</dd>

            <dt>3 -- comparison not run:</dt>
            <dd>
              <t>The run:</dt><dd> The comparison was not run. This includes error conditions such as running out of memory.</t>
            </dd> memory.</dd>

            <dt>4 -- measurement absent:</dt>
            <dd>
              <t>The absent:</dt><dd> The particular measurement was not available for comparison.</t>
            </dd> comparison.</dd>
          </dl>

          <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (
    measurement-results-label =>
        [ + measurement-results-group ] )

measurement-results-group = [
    measurement-system: tstr,
    measurement-results: [ + individual-result ]
]

individual-result = [
    result-id:  tstr / binary-data,
    result:     result-type,
]

result-type = comparison-successful /
              comparison-fail /
              comparison-not-run /
              measurement-absent

comparison-successful    = JC< "success",       1 >
comparison-fail          = JC< "fail",          2 >
comparison-not-run       = JC< "not-run",       3 >
measurement-absent       = JC< "absent",        4 >

]]></sourcecode> >]]></sourcecode>

        </section>
        <section anchor="submods">
          <name>submods (Submodules)</name>
          <t>Some devices are complex and have many subsystems.  A mobile phone is a good example. It may have subsystems for communications (e.g., Wi-Fi and cellular), low-power audio and video playback, and multiple security-oriented subsystems like such as a TEE and a Secure Element. The claims for a subsystem can be grouped together in a submodule.</t>
          <t>Submodules may be used in either evidence or attestation results.</t>
          <t>Because system architecture will vary greatly from use case to use case, there are no set requirements for what a submodule represents either in evidence or in attestation results.
Profiles, <xref target="profiles"/>,
Profiles (<xref target="profiles"/>) may wish to impose requirements.
An attester that outputs evidence with submodules should document the semantics it associates with particular submodules for the verifier.
Likewise, a verifier that outputs attestation results with submodules should document the semantics it associates with the submodules for the relying party.</t>
          <t>A submodule claim is a map that holds some number of submodules.
Each submodule is named by its label in the submodule claim map.
The value of each entry in a submodule may be a Claims-Set, nested token token, or Detached-Submodule-Digest.
This allows for the submodule to serve as its own attester or not and allows for claims
for each submodule to be represented directly or indirectly, i.e., detached.</t>
          <t>A submodule may include a submodule, allowing for arbitrary levels of nesting.
However, submodules do not inherit anything from the containing token and must explicitly include all claims.
Submodules may contain claims that are present in any surrounding token or submodule.
For example, the top-level top level of the token may have a UEID, a submodule may have a different UEID UEID, and a further subordinate submodule may also have a UEID.</t>
          <t>The following sub-sections subsections define the three types for representing submodules:</t>
          <ul spacing="normal">
            <li>
              <t>A submodule Claims-Set</t>
            </li>
            <li>
              <t>The digest of a detached Claims-Set</t>
            </li>
            <li>
              <t>A nested token, which can be any EAT</t>
            </li>
          </ul>
          <t>The Submodule type definition and Nested-Token type definition definitions vary with the type of encoding. The definitions for CBOR-encoded EATs are as follows:</t>

          <sourcecode type="CDDL"><![CDATA[
Nested-Token = CBOR-Nested-Token

CBOR-Nested-Token =
    JSON-Token-Inside-CBOR-Token /
    CBOR-Token-Inside-CBOR-Token

CBOR-Token-Inside-CBOR-Token = bstr .cbor $EAT-CBOR-Tagged-Token

JSON-Token-Inside-CBOR-Token = tstr

$$Claims-Set-Claims //= (submods-label => { + text => Submodule })

Submodule = Claims-Set / CBOR-Nested-Token /
            Detached-Submodule-Digest
]]></sourcecode>
            Detached-Submodule-Digest]]></sourcecode>

          <t>The Submodule and Nested-Token definitions for JSON-encoded EATs is are as below. This difference in The definitions versus are necessarily different than CBOR is necessary because JSON has no tag mechanism and no byte string byte-string type to help indicate that the nested token is CBOR.</t>

          <sourcecode type="CDDL"><![CDATA[
Nested-Token = JSON-Selector

JSON-Selector = $JSON-Selector

$JSON-Selector /= [type: "JWT", nested-token: JWT-Message]
$JSON-Selector /= [type: "CBOR", nested-token:
  CBOR-Token-Inside-JSON-Token]
$JSON-Selector /= [type: "BUNDLE", nested-token: Detached-EAT-Bundle]
$JSON-Selector /= [type: "DIGEST", nested-token:
  Detached-Submodule-Digest]

CBOR-Token-Inside-JSON-Token = base64-url-text

$$Claims-Set-Claims //= (submods-label => { + text => Submodule })

Submodule = Claims-Set / JSON-Selector
]]></sourcecode> JSON-Selector]]></sourcecode>

          <t>The Detached-Submodule-Digest type is defined as follows:</t>
          <sourcecode type="CDDL"><![CDATA[
Detached-Submodule-Digest = [
   hash-algorithm : text / int,
   digest         : binary-data
]
]]></sourcecode>
]]]></sourcecode>

          <t>Nested tokens can be one of three types as defined in this document or types standardized in follow-on documents (e.g., <xref target="I-D.ietf-rats-uccs"/>).
Nested tokens are the only mechanism by which JSON can be embedded in CBOR and vice versa.</t>
          <t>The addition of further types is accomplished by augmenting the $EAT-CBOR-Tagged-Token socket or the $JSON-Selector socket.</t>
          <t>When decoding a JSON-encoded EAT, the type of submodule is determined as follows.
A JSON object indicates that the submodule is a Claims-Set.
In all other cases, it is a JSON-Selector, which is an array of two elements that indicates whether the submodule is a nested token or a Detached-Submodule-Digest.The Detached-Submodule-Digest. The first element in the array indicates the type present in the second element.
If the value is "JWT", "CBOR", "BUNDLE" "BUNDLE", or a future-standardized token types, e.g., see <xref target="I-D.ietf-rats-uccs"/>, the submodule is a nested token of the indicated type, i.e., JWT-Message, CBOR-Token-Inside-JSON-Token, Detached-EAT-Bundle, or a future type.
If the value is "DIGEST", the submodule is a Detached-Submodule-Digest.
Any other value indicates a standardized extension to this specification.</t>
          <t>When decoding a CBOR-encoded EAT, the CBOR item type indicates the type of the submodule as follows.
A map indicates a CBOR-encoded submodule Claims-Set.
An array indicates a CBOR-encoded Detached-Submodule-Digest.
A byte string indicates a CBOR-encoded CBOR-Nested-Token.
A text string indicates a JSON-encoded JSON-Selector. Where JSON-Selector is used in a CBOR-encoded EAT, the "DIGEST" type and corresponding Detached-Submodule-Digest type <bcp14>MUST NOT</bcp14> be used.</t>
          <t>The type of a CBOR-encoded nested token is always determined by the CBOR tag encountered after the byte string wrapping is removed in a CBOR-encoded enclosing token or after the base64 wrapping is removed in a JSON-encoded enclosing token.</t>
          <t>The type of a JSON-encoded nested token is always determined by the string name in JSON-Selector and is always "JWT", "BUNDLE" "BUNDLE", or a new name standardized outside this document for a further type (e.g., "UCCS").
This string name may also be "CBOR" to indicate the nested token is CBOR-encoded.</t>
          <dl>
            <dt>"JWT":</dt>
            <dd>
              <t>The CBOR encoded.</t>
          <dl spacing="normal">
            <dt>"JWT":</dt><dd> The second array item <bcp14>MUST</bcp14> be a JWT formatted according to <xref target="RFC7519"/></t>
            </dd>
            <dt>"CBOR":</dt>
            <dd>
              <t>The target="RFC7519"/>.</dd>
            <dt>"CBOR":</dt><dd> The second array item <bcp14>MUST</bcp14> be some
            base64url-encoded CBOR that is a tag, typically a CWT or
            CBOR-encoded detached EAT bundle</t>
            </dd>
            <dt>"BUNDLE":</dt>
            <dd>
              <t>The bundle.</dd>
	    <dt>"BUNDLE":</dt><dd> The second array item <bcp14>MUST</bcp14> be a
	    JSON-encoded Detached EAT Bundle as defined in this document.</t>
            </dd>
            <dt>"DIGEST":</dt>
            <dd>
              <t>The document.</dd>
	    <dt>"DIGEST":</dt><dd> The second array item <bcp14>MUST</bcp14> be a
	    JSON-encoded Detached-Submodule-Digest as defined in this document.</t>
            </dd>
	    document.</dd>
          </dl>
          <t>As noted elsewhere, additional EAT types may be defined by a standards action. Standards Action. New type specifications <bcp14>MUST</bcp14> address the integration of the new type into the Submodule claim type for submodules.</t>
          <section anchor="submodule-claims-set">
            <name>Submodule Claims-Set</name>

<!--[rfced] Sections 4.2.18.1 and 4.2.18.3. Would it be correct to say
that the keys (or no keys) are distinct from the surrounding
token produced by the attester?

Original:
   The Claims-Set type provides a means of representing claims from a
   submodule that does not have its own attesting environment, i.e., it
   has no keys distinct from the attester producing the surrounding
   token.

   The CBOR-Nested-Token and JSON-Selector types provide a means of
   representing claims from a submodule that has its own attesting
   environment, i.e., it has keys distinct from the attester producing
   the surrounding token.

Perhaps:
   The Claims-Set type provides a means of representing claims from a
   submodule that does not have its own attesting environment, i.e., it
   has no keys that are distinct from the surrounding token produced by
   the attester.

   The CBOR-Nested-Token and JSON-Selector types provide a means of
   representing claims from a submodule that has its own attesting
   environment, i.e., it has keys that are distinct from the
   surrounding token produced by the attester.
-->

            <t>The Claims-Set type provides a means of representing claims from a submodule that does not have its own attesting environment,
i.e., it has no keys distinct from the attester producing the surrounding token. Claims are represented as a Claims-Set. Submodule claims represented in this way are secured by the same
mechanism as the enclosing token (e.g., it is signed by the same attestation key).</t>
            <t>The encoding of a submodule Claims-Set <bcp14>MUST</bcp14> be the same as the encoding as of the surrounding EAT, e.g., all submodule Claims-Sets in a CBOR-encoded token must be CBOR-encoded.</t> CBOR encoded.</t>
          </section>
          <section anchor="Detached-Submodule-Digest">
            <name>Detached Submodule Digest</name>
            <t>The Detached-Submodule-Digest type is similar to a submodule Claims-Set, except a digest of the Claims-Set is included in the claim with the Claims-Set contents conveyed separately.
	    The separately-conveyed separately conveyed Claims-Set is called a detached "detached claims set. set".

<!--[rfced] Section 4.2.18.2. We updated this sentence to clarify
"is directly". If it changes the intended meaning, please let us know.

Original:
   The input to the digest algorithm is directly the CBOR or
   JSON-encoded Claims-Set for the submodule.

Current:
   The direct input to the digest algorithm is either the
   CBOR-encoded or the JSON-encoded Claims-Set for the
   submodule.
-->

The direct input to the digest algorithm is either the CBOR-encoded or the JSON-encoded Claims-Set for the submodule.
	    There is no byte-string byte string wrapping or base 64 base64 encoding.</t>
<t>The data type for this type of submodule is an array consisting of two data items: an algorithm identifier and a byte string containing the digest. The hash algorithm identifier is always from the COSE Algorithm registry, "COSE Algorithms" registry <xref target="IANA.COSE.Algorithms"/>. Either the integer or the string identifier may be used. The hash algorithm identifier is never from the JOSE Algorithm registry.</t>
            <t>A detached EAT bundle, as described in <xref target="DEB"/>, may be used to convey detached claims sets and the EAT containing the corresponding detached digests.
EAT, however, However, EAT does not require the use of a detached EAT bundle. Any other protocols may be used to convey detached claims sets and the EAT containing the corresponding detached digests.
If detached Claims-Sets are modified in transit transit, then validation can fail.</t>
          </section>
          <section anchor="Nested-Token">
            <name>Nested Tokens</name>
            <t>The CBOR-Nested-Token and JSON-Selector types provide a means of representing claims from a submodule that has its own attesting environment,
i.e., it has keys distinct from the attester producing the surrounding token. Claims are represented in a signed EAT token.</t>
            <t>Inclusion of a signed EAT as a claim cryptographically binds the EAT to the surrounding token.
If it was conveyed in parallel with the surrounding token, there would be no such binding and attackers could substitute a good attestation from another device for the attestation of an errant subsystem.</t>
            <t>A nested token need not use the same encoding as the enclosing token.
This enables composite devices to be built without regards to the encoding used by components.
Thus, a CBOR-encoded EAT can have a JSON-encoded EAT as a nested token and vice versa.</t>
          </section>
        </section>
      </section>
      <section anchor="claims-describing-the-token">
        <name>Claims Describing the Token</name>
        <t>The claims in this section provide metadata about the token they occur in.
They do not describe the entity. They may appear in evidence or attestation results.</t>
        <section anchor="iat-claim">
          <name>iat (Timestamp) Claim</name>
          <t>The "iat" claim defined in CWT and JWT is used to indicate the
date-of-creation of the token, the time at which the claims are
collected and the token is composed and signed.</t>
          <t>The data for some claims may be held or cached for some period of
time before the token is created. This period may be long, even
days. Examples are measurements taken at boot or a geographic
position fix taken the last time a satellite signal was received.
There are individual timestamps associated with these claims to
indicate their age is older than the "iat" timestamp.</t>
          <t>CWT allows the use of floating-point for this claim. claim, whereas EAT disallows
the use of floating-point. An EAT token <bcp14>MUST NOT</bcp14> contain an "iat" claim in
floating-point format. Any recipient of a token with a floating-point
	  format "iat" claim <bcp14>MUST</bcp14> consider it an error.</t>
          <t>A 64-bit integer representation of the CBOR epoch-based time
<xref target="RFC8949"/> used by this claim can represent a range of +/- 500
billion years, so the only point of a floating-point timestamp is to
have precession greater than one second. This is not needed for EAT.</t>
        </section>
        <section anchor="profile-claim">
          <name>eat_profile (EAT Profile) Claim</name>
          <t>See <xref target="profiles"/> for the detailed description of an EAT profile.</t>
          <t>The "eat_profile" claim identifies an EAT profile by either a Uniform Resource Identifier (URI) or an Object Identifier (OID). OID.
Typically, the URI will reference a document describing the profile.
An OID is just a unique identifier for the profile.
It may exist anywhere in the OID tree.
There is no requirement that the named document be publicly accessible.
The primary purpose of the "eat_profile" claim is to uniquely identify the profile even if it is a private profile.</t>
          <t>The OID is always absolute and never relative.</t>
          <t>See <xref target="common-types"/> for OID and URI encoding.</t>

          <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (profile-label => general-uri / general-oid)
]]></sourcecode> general-oid)]]></sourcecode>

        </section>
        <section anchor="intuse-intended-use-claim">
          <name>intuse (Intended Use) Claim</name>

          <t>EATs may be employed in the context of several different applications.
The "intuse" claim provides an indication to an EAT consumer about the intended usage of the token.
This claim can be used as a way for an application using EAT to internally distinguish between different ways it utilizes EAT. The possible values are in the EAT "Entity Attestation Token (EAT) Intended Use Registry Uses" registry defined in <xref target="int-use-registry"/>.</t>

          <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= ( intended-use-label => intended-use-type )

intended-use-type = JC< text, int>
]]></sourcecode> int>]]></sourcecode>

        </section>
      </section>
    </section>
    <section anchor="DEB">
      <name>Detached EAT Bundles</name>
      <t>A detached EAT bundle is a message to convey an EAT plus detached claims sets secured by that EAT.
It is a top-level message like a CWT or JWT.
It can occur in any place that a CWT or JWT occurs, for example example, as a submodule nested token as defined in <xref target="Nested-Token"/>.</t>
      <t>A detached EAT bundle may be either CBOR or JSON-encoded.</t> JSON encoded.</t>
      <t>A detached EAT bundle consists of two parts.</t>
      <t>The first part is an encoded EAT as follows:</t> that:</t>
      <ul spacing="normal">
        <li>
          <t><bcp14>MUST</bcp14> have at least one submodule that is a detached submodule digest as defined in <xref target="Detached-Submodule-Digest"/></t>
        </li>
        <li>
          <t><bcp14>MAY</bcp14> be either CBOR or JSON-encoded JSON encoded and does not have to the be the same as the encoding of the bundle</t>
        </li>
        <li>
          <t><bcp14>MAY</bcp14> be a CWT, or JWT JWT, or some future-defined token type, but it <bcp14>MUST NOT</bcp14> be a detached EAT bundle</t>
        </li>
        <li>
          <t><bcp14>MUST</bcp14> be authenticity and integrity protected</t>
        </li>
      </ul>
      <t>The same mechanism for distinguishing the type for nested token submodules is employed here.</t>
      <t>The second part is a map/object as follows:</t> that:</t>
      <ul spacing="normal">
        <li>
          <t><bcp14>MUST</bcp14> be a Claims-Set</t>
        </li>
        <li>
          <t><bcp14>MUST</bcp14> use the same encoding as the bundle</t>
        </li>
        <li>
          <t><bcp14>MUST</bcp14> be wrapped in a byte string when the encoding is CBOR and be base64url-encoded base64url encoded when the encoding is JSON</t>
        </li>
      </ul>

      <t>For a CBOR-encoded detached EAT bundles, bundle, tag 602 can be used to identify it.
The standard rules apply for use or non-use of a tag.
When it is sent as a submodule, it is always sent as a tag to distinguish it from the other types of nested tokens.</t>
      <t>The digests of the detached claims sets are associated with detached Claims-Sets by label/name.
It is up to the constructor of the detached EAT bundle to ensure that the names uniquely identify the detached claims sets.
Since the names are used only in the detached EAT bundle, they can be very short, perhaps one byte.</t>

      <sourcecode type="CDDL"><![CDATA[
BUNDLE-Messages = BUNDLE-Tagged-Message / BUNDLE-Untagged-Message

BUNDLE-Tagged-Message   = #6.602(BUNDLE-Untagged-Message)
BUNDLE-Untagged-Message = Detached-EAT-Bundle

Detached-EAT-Bundle = [
    main-token : Nested-Token,
    detached-claims-sets: {
        + tstr => JC-NEST-SAFE<json-wrapped-claims-set,
                               cbor-wrapped-claims-set>
    }
]

json-wrapped-claims-set = base64-url-text

cbor-wrapped-claims-set = bstr .cbor Claims-Set

]]></sourcecode> Claims-Set]]></sourcecode>

    </section>
    <section anchor="profiles">
      <name>Profiles</name>
      <t>EAT makes normative use of CBOR, JSON, COSE, JOSE, CWT CWT, and JWT.
Most of these have implementation options to accommodate a range of use cases.</t>
      <t>For example, COSE does not require a particular set of cryptographic algorithms so as to accommodate different usage scenarios and evolution of algorithms over time.
Section 10 of <xref target="RFC9052"/> target="RFC9052" sectionFormat="of" section="10"/> describes the profiling considerations for COSE.</t>
      <t>The use of encryption is optional for both CWT and JWT.
Section 8 of
<xref target="RFC7519"/> target="RFC7519" sectionFormat="of" section="8"/> describes implementation requirement requirements and recommendations for JWT.</t>
      <t>Similarly, CBOR provides indefinite length indefinite-length encoding, which is not commonly used, used but is valuable for very constrained devices.
For EAT itself, in a particular use case some claims will be used and others will not.
Section 4 of
<xref target="RFC8949"/> target="RFC8949" sectionFormat="of" section="4"/> describes serialization considerations for CBOR.</t>
      <t>For example example, a mobile phone use case may require the device make and model, model and may prohibit UEID and location for privacy reasons.
The general EAT standard retains all this flexibility because it too is aimed to accommodate a broad range of use cases.</t>
      <t>It is necessary to explicitly narrow these implementation options to guarantee interoperability.
EAT chooses one general and explicit mechanism, the profile, to indicate the choices made for these implementation options for all aspects of the token.</t>
      <t>Below is a list of the various issues that should be addressed by a profile.</t>
      <t>The "eat_profile" claim in <xref target="profile-claim"/> provides a unique identifier for the profile a particular token uses.</t>
      <t>A profile can apply to evidence or to results, attestation results results, or both.</t>
      <section anchor="format-of-a-profile-document">
        <name>Format of a Profile Document</name>
        <t>A profile document does not have to be in any particular format. It may be simple text, something more formal formal, or a combination.</t> combination of both.</t>
        <t>A profile may define, and possibly register, one or more new claims if needed. A profile may also reuse one or more already defined claims, claims either as-is as is or with values constrained to a subset or subrange.</t>
      </section>
      <section anchor="full-and-partial-profiles">
        <name>Full and Partial Profiles</name>
        <t>For a "full" profile, the receiver will be able to decode and verify every possible EAT sent when a sender and receiver both adhere to it.
For a "partial" profile, there are still some protocol options left undecided.</t>
        <t>For example, a profile that allows the use of signing algorithms by the sender that the receiver is not required to support is a partial profile.
The sender might choose a signing algorithm that some receivers do not support.</t>
        <t>Full profiles <bcp14>MUST</bcp14> be complete such that a complying receiver can decode, verify verify, and check for freshness for every EAT created by a complying sender.
Full profiles do not need to require the receiver to fully handle every claim in an EAT from a complying sender.
Profile specifications may assume the receiver has access to the necessary verification keys or may go into specific detail on the means to access verification keys.</t>
        <t>The "eat_profile" claim <bcp14>MUST NOT</bcp14> be used to identify partial profiles.</t>
        <t>While fewer profiles are preferrable, preferable, sometimes several may be needed for a use case.
One approach to handling variation in devices might be to define several full profiles that are variants of each other.
It is relatively easy and inexpensive to define profiles as they do not have to be standards track published on the Standards Track and do not have to be registered anywhere.
For example, flexibility for post-quantum algorithms can be handled as follows.
First, define a full profile for a set of non-post-quantum algorithms for current use.
Then, when post-quantum algorithms are settled, define another full profile derived from the first.</t>
      </section>
      <section anchor="list-of-profile-issues">
        <name>List of Profile Issues</name>
        <t>The following is a list of EAT, CWT, JWT, COSE, JOSE JOSE, and CBOR options that a profile should address.</t>
        <section anchor="use-of-json-cbor-or-both">
          <name>Use of JSON, CBOR CBOR, or both</name> Both</name>
          <t>A profile should specify whether CBOR, JSON JSON, or both may be sent.
A profile should specify that the receiver can accept all encodings that the sender is allowed to send.</t>
          <t>This should be specified for the top-level top level and all nested tokens.
For example, a profile might require all nested tokens to be of the same encoding of the top level top-level token.</t>
        </section>
        <section anchor="cbor-map-and-array-encoding">
          <name>CBOR Map and Array Encoding</name>
          <t>A profile should specify whether definite-length arrays/maps, indefinite-length arrays/maps arrays/maps, or both may be sent.
A profile should specify that the receiver be able to accept accepts all length encodings that the sender is allowed to send.</t>
          <t>This applies to individual EAT claims, CWT CWT, and COSE parts of the implementation.</t>
          <t>For most use cases, specifying that only definite-length arrays/maps may be sent is suitable.</t>
        </section>
        <section anchor="cbor-string-encoding">
          <name>CBOR String Encoding</name>
          <t>A profile should specify whether definite-length strings, indefinite-length strings strings, or both may be sent.
A profile should specify that the receiver be able to accept accepts all types of string encodings that the sender is allowed to send.</t>
          <t>For most use cases, specifying that only definite-length strings may be sent is suitable.</t>
        </section>
        <section anchor="cbor-preferred-serialization">
          <name>CBOR Preferred Serialization</name>
          <t>A profile should specify whether or not CBOR preferred serialization must be sent or not.
A profile should specify that the receiver be able to accept accepts preferred and/or non-preferred serialization serialization, so it will be able to accept anything sent by the sender.</t>
        </section>
        <section anchor="cbor-tags">
          <name>CBOR Tags</name>
          <t>The profile should specify whether the token should be a CWT Tag tag or not.</t>
          <t>When COSE protection is used, the profile should specify whether COSE tags are used or not.
Note that RFC 8392 requires COSE tags be used in a CWT tag.</t>
          <t>Often
          <t>Often, a tag is unnecessary because the surrounding or carrying protocol identifies the object as an EAT.</t>
        </section>
        <section anchor="message-type">
          <name>COSE/JOSE Protection</name>
          <t>COSE and JOSE have several options for signed, MACed MACed, and encrypted messages.
JWT may use the JOSE NULL protection option.
It is possible to implement no protection, sign only, MAC only, sign then encrypt encrypt, and so on.
All combinations allowed by COSE, JOSE, JWT, and CWT are allowed by EAT.</t>
          <t>A profile should specify all signing, encryption encryption, and MAC message formats that may be sent.
For example, a profile might allow only COSE_Sign1 to be sent.
For
As another example, a profile might allow COSE_Sign and COSE_Encrypt to be sent to carry multiple signatures for post quantum cryptography and to use encryption to provide confidentiality.</t>
          <t>A profile should specify that the receiver accepts all message formats that are allowed to be sent.</t>
          <t>When both signing and encryption are allowed, a profile should specify which is applied first.</t>
        </section>
        <section anchor="cosejose-algorithms">
          <name>COSE/JOSE Algorithms</name>
          <t>See the section on "Application Profiling Considerations" in <xref target="RFC9052"/> (<xref target="RFC9052" sectionFormat="of" section="10"/>) for a discussion on the selection of cryptographic algorithms and related issues.</t>
          <t>The profile <bcp14>MAY</bcp14> require the protocol or system using EAT to provide an algorithm negotiation mechanism.</t>
          <t>If not, the profile document should list a set of algorithms for each COSE and JOSE message type allowed by the profile per <xref target="message-type"/>.
The verifier should implement all of them.
The attester may implement any of them it wishes, possibly just one for each message type.</t>
          <t>If detached submodule digests are used used, the profile should address the determination of the hash algorithm(s) for the digests.</t>
        </section>
        <section anchor="detached-eat-bundle-support">
          <name>Detached EAT Bundle Support</name>
          <t>A profile should specify whether or not a detached EAT bundle (<xref target="DEB"/>) can be sent.
A profile should specify that a receiver be able to accept accepts a detached EAT bundle if the sender is allowed to send it.</t>
        </section>
        <section anchor="key-identification">
          <name>Key Identification</name>
          <t>A profile should specify what must be sent to identify the verification, decryption decryption, or MAC key or keys. key(s).
If multiple methods of key identification may be sent, a profile should require the receiver to support them all.</t>
          <t><xref target="keyid"/> describes a number of methods for identifying verification keys.
When encryption is used, there are further considerations.
	  In some cases cases, key identification may be very simple simple, and in others involve other cases, multiple components. components may be involved. For example, it may be simple through the use of a COSE key ID ID, or it may be complex through the use of an X.509 certificate hierarchy.</t>
          <t>While

<!--[rfced] Section 6.3.9. FYI, "end-end" has been updated to "end-to-end".
(This is similar to a change that was made in version 31 of the original.)

Original:
   While not always possible, a profile should specify or make reference
   to, a full end-end specification for key identification.

Current:
   While not always possible, a profile should specify, or make reference
   to, a full end-to-end specification for key identification.
-->

          <t>While not always possible, a profile should specify, or make reference to, a full end-to-end specification for key identification.
For example, a profile should specify in full detail how COSE key IDs are to be created, their lifecycle life cycle, and such rather than just specifying that a COSE key ID be used.
For example, a profile should specify the full details of an X.509 hierarchy including extension processing, algorithms allowed allowed, and so on rather than just saying X.509 certificates are used.</t>
        </section>
        <section anchor="endorsement-identification">
          <name>Endorsement Identification</name>

          <t>Similar to, or perhaps the same as as, verification key identification, the profile may wish to specify how endorsements are to be identified.
However
However, note that endorsement identification is optional, whereas key identification is not.</t>
        </section>
        <section anchor="freshness">
          <name>Freshness</name>
          <t>Security considerations, see considerations (see <xref target="sec-con-freshness"/>, target="sec-con-freshness"/>) require a mechanism to provide freshness. This may be the EAT nonce claim in <xref target="nonce"/>, target="nonce"/> or some claim or mechanism defined outside this document.
The section on freshness Several options are described in <xref target="RFC9334"/> describes several options. "Freshness" (<xref target="RFC9334" sectionFormat="of" section="10"/>).
A profile should specify which freshness mechanism or mechanisms can be used.</t>
          <t>If the EAT nonce claim is used, a profile should specify whether multiple nonces may be sent.
If a profile allows multiple nonces to be sent, it should require the receiver to process multiple nonces.</t>
        </section>
        <section anchor="claims-requirements">
          <name>Claims Requirements</name>
          <t>A profile may define new claims that are not defined in this document.</t>
          <t>This document requires that an EAT receiver must accept tokens with claims it does not understand.
A profile for a specific use case may reverse this and allow a receiver to reject tokens with claims it does not understand.
A profile for a specific use case may specify that specific claims are prohibited.</t>
          <t>A profile for a specific use case may modify this and specify that some claims are required.</t>
          <t>A profile may constrain the definition of claims that are defined in this document or elsewhere.
For example, a profile may require the EAT nonce to be a certain length or the "location" claim to always include the altitude.</t>
<t>Some claims are "pluggable" in that they allow different formats for their content.

<!--[rfced] Section 6.3.12. The text mentions the measurement and
measurements claims; however, Section 4.2.16 only refers to the
"measurements" claim. Should "claims" perhaps be singular, or
should "measurement" be removed or updated (perhaps "measres"
claim was intended)?

Original:
   The "manifests" claim (Section 4.2.15) along with the
   measurement and "measurements" (Section 4.2.16) claims are examples
   of this, allowing the use of CoSWID and other formats.

Perhaps:
   The "manifests" claim (Section 4.2.15) along with the
   "measurements" claim (Section 4.2.16) and "measres" claim (Section 4.2.17)
   are examples of this, allowing the use of CoSWID and other formats.
-->

The "manifests" claim (<xref target="manifests"/>) along with the measurement and "measurements" (<xref target="measurements"/>) claims are examples of this, allowing the use of CoSWID and other formats.
A profile should specify which formats are allowed to be sent, with the assumption that the corresponding CoAP content types have been registered.
A profile should require the receiver to accept all formats that are allowed to be sent.</t>
<t>Further, if there is variation within a format that is allowed, the profile should specify which variations can be sent.

<!--[rfced] Section 6.3.12. FYI - We updated the following text as the
second sentence is a fragment. If this changes the intended
meaning, please let us know.

Original:
   For example, there are variations in the CoSWID format.  A profile
   that require the receiver to accept all variations that are allowed
   to be sent.

Current:
   For example, there are variations in the CoSWID format, such as a profile
   that requires the receiver to accept all variations that are allowed
   to be sent.
-->

For example, there are variations in the CoSWID format, such as a profile that
requires the receiver to accept all variations that are allowed to be sent.</t>
        </section>
      </section>
      <section anchor="the-constrained-device-standard-profile">
        <name>The Constrained Device Standard Profile</name>
        <t>It is anticipated that there will be many profiles defined for EAT for many different use cases.
	This section gives a normative definition of one profile that is good for many constrained device use cases.</t>
        <t>The identifier for this profile is "urn:ietf:rfc:rfcTBD".</t>
        <t><cref anchor="to-be-removed-1">RFC Editor: please replace rfcTBD with this RFC number and remove this note.</cref></t> "urn:ietf:rfc:rfc9711".</t>

        <table align="left" anchor="constrained-profile">
          <name>Constrained Device Profile Definition</name>
          <thead>
            <tr>
              <th align="left">Issue</th>
              <th align="left">Profile Definition</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">CBOR/JSON</td>
              <td align="left">CBOR <bcp14>MUST</bcp14> be used</td> used.</td>
            </tr>
            <tr>
              <td align="left">CBOR Encoding</td>
              <td align="left">Definite length align="left">Definite-length maps and arrays <bcp14>MUST</bcp14> be used</td> used.</td>
            </tr>
            <tr>
              <td align="left">CBOR Encoding</td>
              <td align="left">Definite length align="left">Definite-length strings <bcp14>MUST</bcp14> be used</td> used.</td>
            </tr>
            <tr>
              <td align="left">CBOR Serialization</td>
              <td align="left">Preferred serialization <bcp14>MUST</bcp14> be used</td> used.</td>
            </tr>
            <tr>
              <td align="left">COSE Protection</td>
              <td align="left">COSE_Sign1 <bcp14>MUST</bcp14> be used</td> used.</td>
            </tr>
            <tr>
              <td align="left">Algorithms</td>
              <td align="left">The receiver <bcp14>MUST</bcp14> accept ES256, ES384 ES384, and ES512; the sender <bcp14>MUST</bcp14> send one of these</td> these.</td>
            </tr>
            <tr>
              <td align="left">Detached EAT Bundle Usage</td>
              <td align="left">Detached EAT bundles <bcp14>MUST NOT</bcp14> be sent with this profile</td> profile.</td>
            </tr>
            <tr>
              <td align="left">Verification Key Identification</td>
              <td align="left">Either the COSE kid key identifier (kid) or the UEID <bcp14>MUST</bcp14> be used to identify the verification key. If both are present, the kid takes precedence. (It is assumed the receiver has access to a database of trusted verification keys keys, which allows a lookup of the verification key ID; the key format and means of distribution are beyond the scope of this profile)</td> profile.)</td>
            </tr>
            <tr>
              <td align="left">Endorsements</td>
              <td align="left">This profile contains no endorsement identifier</td> identifier.</td>
            </tr>
            <tr>
              <td align="left">Freshness</td>
              <td align="left">A new single unique nonce <bcp14>MUST</bcp14> be used for every token request</td> request.</td>
            </tr>
            <tr>
              <td align="left">Claims</td>
              <td align="left">No requirement is made on for the presence or absence of claims other than requiring an EAT nonce. As per general EAT rules, the receiver <bcp14>MUST NOT</bcp14> error out on claims it does not understand.</td>
            </tr>
          </tbody>
        </table>
        <t>Any profile with different requirements than those above <bcp14>MUST</bcp14> have a different profile identifier.</t>
        <t>Note that many claims can be present for tokens conforming to this profile, even claims not defined in this document.
Note also that even slight deviation from the above requirements is considered a different profile that <bcp14>MUST</bcp14> have a different identifier.
For example, if a kid (key identifier) or UEID is not used for key identification, it is not in conformance with this profile.
For
As another example, requiring the presence of some claim is also not in conformance and requires another profile.</t>
        <t>Derivations of this profile are encouraged.
For example example, another profile may be simply defined as The "The Constrained Device Standard Profile Profile" plus the requirement for the presence of claim xxxx and claim yyyy.</t>
      </section>
    </section>
    <section anchor="encoding">
      <name>Encoding and Collected CDDL</name>
      <t>An EAT is fundamentally defined using CDDL.
This document specifies how to encode the CDDL in CBOR or JSON.
Since CBOR can express some things that JSON cannot (e.g., tags) or that are expressed differently (e.g., labels) labels), there is some CDDL that is specific to the encoding.</t>
      <section anchor="claims-set-and-cddl-for-cwt-and-jwt">
        <name>Claims-Set and CDDL for CWT and JWT</name>
        <t>CDDL was not used to define CWT or JWT.
It was not available at the time.</t>
        <t>This document defines CDDL for both CWT and JWT.
This document does not change the encoding or semantics of anything in a CWT or JWT.</t>
        <t>A Claims-Set is the central data structure for EAT, CWT CWT, and JWT.
It holds all the claims and is the structure that is secured by signing or other means.
It is not possible to define EAT, CWT, or JWT in CDDL without it.
The CDDL definition of Claims-Set here is applicable to EAT, CWT CWT, and JWT.</t>
        <t>This document specifies how to encode a Claims-Set in CBOR or JSON.</t>
        <t>With the exception of nested tokens and some other externally
        defined structures (e.g., SWIDs) SWIDs), an entire Claims-Set must be encoded
        in either CBOR or JSON, never a mixture.</t>

<!--[rfced] Section 7.1. This sentence mentions that CDDL for the
seven claims is included "here". Please clarify what "here"
refers to - is it referring to Section 7.1 or to one of the
subsections?

Original:
   CDDL for the seven claims defined by [RFC8392] and [RFC7519] is
   included here.

Perhaps:
   CDDL for the seven claims defined by [RFC8392] and [RFC7519] is
   also specified in this document.
-->

        <t>CDDL for the seven claims defined by <xref target="RFC8392"/> and <xref target="RFC7519"/> is included here.</t>
      </section>
      <section anchor="encoding-data-types">
        <name>Encoding Data Types</name>

<!--[rfced] Section 7.2. What does "This" refer to - is it "The
following subsections" as shown below?

Current:
7.2.  Encoding Data Types

   This makes use of the types defined in "Standard Prelude"
   (Appendix D of [RFC8610]).

Perhaps:
7.2.  Encoding Data Types

   The following subsections use the types defined in
   "Standard Prelude" (Appendix D of [RFC8610]).
-->

        <t>This makes use of the types defined in <xref target="RFC8610"/> Appendix D, Standard Prelude.</t> "Standard Prelude" (<xref target="RFC8610" sectionFormat="of" section="D"/>).</t>
        <section anchor="common-types">
          <name>Common Data Types</name>
          <t>time-int is identical to the epoch-based time, time but disallows
floating-point representation.</t>
          <t>For CBOR-encoded tokens, OIDs are specified using the CDDL type name "oid" from <xref target="RFC9090"/>.
They are encoded without the tag number.
For JSON-encoded tokens, OIDs are a text string strings in the common form of "nn.nn.nn...".</t>
          <t>Unless expliclity explicitly indicated, URIs are not the URI tag defined in <xref target="RFC8949"/>.
They are just text strings that contain a URI conforming to the format defined in <xref target="RFC3986"/>.</t>

          <sourcecode type="CDDL"><![CDATA[
time-int = #6.1(int)

binary-data = JC< base64-url-text, bstr>

base64-url-text = tstr .regexp "[A-Za-z0-9_-]+"

general-oid = JC< json-oid, ~oid >

json-oid = tstr .regexp "([0-2])((\\.0)|(\\.[1-9][0-9]*))*"

general-uri = JC< text, ~uri >

coap-content-format = uint .le 65535

]]></sourcecode> 65535]]></sourcecode>

        </section>
        <section anchor="jsoninterop">
          <name>JSON Interoperability</name>

          <t>JSON should be encoded per <xref target="RFC8610"/>, Appendix E. target="RFC8610" sectionFormat="of" section="E"/>. In addition, the following CDDL types are encoded in JSON as follows:</t>
          <ul spacing="normal">
            <li>
              <t>bstr -- <bcp14>MUST</bcp14> be base64url-encoded</t> base64url encoded.</t>
            </li>
            <li>
              <t>time -- <bcp14>MUST</bcp14> be encoded as NumericDate as described in Section 2 of <xref target="RFC7519"/>.</t> target="RFC7519" sectionFormat="of" section="2"/>.</t>
            </li>
            <li>
              <t>string-or-uri -- <bcp14>MUST</bcp14> be encoded as StringOrURI as described in Section 2 of <xref target="RFC7519"/>.</t> target="RFC7519" sectionFormat="of" section="2"/>.</t>
            </li>
            <li>
              <t>uri -- <bcp14>MUST</bcp14> be a URI <xref target="RFC3986"/>.</t>
            </li>
            <li>
              <t>oid -- <bcp14>MUST</bcp14> be encoded as a string using the well established well-established dotted-decimal notation (e.g., the text "1.2.250.1") <xref target="RFC4517"/>.</t>
            </li>
          </ul>
          <t>The CDDL generic "JC&lt;&gt;" is used in most places where there is a variance between CBOR and JSON.
The first argument is the CDDL for JSON JSON, and the second is CDDL for CBOR.</t>
        </section>
        <section anchor="labels">
          <name>Labels</name>
          <t>Most map labels, Claims-Keys, Claim-Names Claim-Names, and enumerated-type values are integers for CBOR-encoded tokens and strings for JSON-encoded tokens.
When this is the case case, the "JC&lt;&gt;" JC&lt;&gt; CDDL construct is used to give both the integer and string values.</t>
        </section>
        <section anchor="cbor-interoperability">
          <name>CBOR Interoperability</name>
          <t>CBOR allows data items to be serialized in more than one form to accommodate a variety of use cases.
This is addressed in <xref target="profiles"/>.</t>
        </section>
      </section>
      <section anchor="collected-cddl">
        <name>Collected CDDL</name>
        <section anchor="payload-cddl">
          <name>Payload CDDL</name>
          <t>This
          <t>The payload CDDL defines all the EAT Claims claims that are added to the main definition of a Claim-Set Claims-Set in <xref target="CDDL_for_CWT"/>.
Claims-Set is the payload for CWT, JWT JWT, and potentially other token types.
This is for both CBOR and JSON.

<!--[rfced] Section 7.3.1. This sentence does not parse - is "use"
perhaps missing after the comma? Please let us know how we may
update for clarity.

Original:
   When there is variation between CBOR and JSON, the
   JC<> CDDL generic defined in Appendix D.

Perhaps:
   When there is variation between CBOR and JSON, use the
   JC<> CDDL generic defined in Appendix D.
-->

When there is variation between CBOR and JSON, the JC&lt;&gt; CDDL generic defined in <xref target="CDDL_for_CWT"/>.
Note that the JC&lt;&gt; generic uses the CDDL ".feature" control operator defined in <xref target="RFC9165"/>.</t>
          <t>This CDDL uses, but does not define define, Submodule or nested tokens because the definition for these types varies between CBOR and JSON and the JC&lt;&gt; generic cannot be used to define it.
The submodule claim is the one place where a CBOR token can be nested inside a JSON token and vice versa.
Encoding-specific definitions are provided in the following sections.</t>

          <sourcecode type="CDDL"><![CDATA[
time-int = #6.1(int)

binary-data = JC< base64-url-text, bstr>

base64-url-text = tstr .regexp "[A-Za-z0-9_-]+"

general-oid = JC< json-oid, ~oid >

json-oid = tstr .regexp "([0-2])((\\.0)|(\\.[1-9][0-9]*))*"

general-uri = JC< text, ~uri >

coap-content-format = uint .le 65535

$$Claims-Set-Claims //=
    (nonce-label => nonce-type / [ 2* nonce-type ])

nonce-type = JC< tstr .size (8..88), bstr .size (8..64)>

$$Claims-Set-Claims //= (ueid-label => ueid-type)

ueid-type = JC<base64-url-text .size (10..44) , bstr .size (7..33)>

$$Claims-Set-Claims //= (sueids-label => sueids-type)

sueids-type = {
    + tstr => ueid-type
}

$$Claims-Set-Claims //= (
    oemid-label => oemid-pen / oemid-ieee / oemid-random
)

oemid-pen = int

oemid-ieee = JC<oemid-ieee-json, oemid-ieee-cbor>
oemid-ieee-cbor = bstr .size 3
oemid-ieee-json = base64-url-text .size 4

oemid-random = JC<oemid-random-json, oemid-random-cbor>
oemid-random-cbor = bstr .size 16
oemid-random-json = base64-url-text .size 24

$$Claims-Set-Claims //=  (
    hardware-version-label => hardware-version-type
)

hardware-version-type = [
    version:  tstr,
    ? scheme:  $version-scheme
]

$$Claims-Set-Claims //= (
    hardware-model-label => hardware-model-type
)

hardware-model-type = JC<base64-url-text .size (4..44),
                         bytes .size (1..32)>

$$Claims-Set-Claims //= ( sw-name-label => tstr )

$$Claims-Set-Claims //= (sw-version-label => sw-version-type)

sw-version-type = [
    version:  tstr
    ? scheme:  $version-scheme
]

$$Claims-Set-Claims //= (oem-boot-label => bool)

$$Claims-Set-Claims //= ( debug-status-label => debug-status-type )

debug-status-type = ds-enabled /
                    disabled /
                    disabled-since-boot /
                    disabled-permanently /
                    disabled-fully-and-permanently

ds-enabled                     = JC< "enabled", 0 >
disabled                       = JC< "disabled", 1 >
disabled-since-boot            = JC< "disabled-since-boot", 2 >
disabled-permanently           = JC< "disabled-permanently", 3 >
disabled-fully-and-permanently =
                       JC< "disabled-fully-and-permanently", 4 >

$$Claims-Set-Claims //= (location-label => location-type)

location-type = {
    latitude => number,
    longitude => number,
    ? altitude => number,
    ? accuracy => number,
    ? altitude-accuracy => number,
    ? heading => number,
    ? speed => number,
    ? timestamp => ~time-int,
    ? age => uint
}

latitude          = JC< "latitude",          1 >
longitude         = JC< "longitude",         2 >
altitude          = JC< "altitude",          3 >
accuracy          = JC< "accuracy",          4 >
altitude-accuracy = JC< "altitude-accuracy", 5 >
heading           = JC< "heading",           6 >
speed             = JC< "speed",             7 >
timestamp         = JC< "timestamp",         8 >
age               = JC< "age",               9 >

$$Claims-Set-Claims //= (uptime-label => uint)

$$Claims-Set-Claims //=  (boot-seed-label => binary-data)

$$Claims-Set-Claims //= (boot-count-label => uint)

$$Claims-Set-Claims //= ( intended-use-label => intended-use-type )

intended-use-type = JC< text, int>

$$Claims-Set-Claims //= (
    dloas-label => [ + dloa-type ]
)

dloa-type = [
    dloa_registrar: general-uri
    dloa_platform_label: text
    ? dloa_application_label: text
]

$$Claims-Set-Claims //= (profile-label => general-uri / general-oid)

$$Claims-Set-Claims //= (
    manifests-label => manifests-type
)

manifests-type = [+ manifest-format]

manifest-format = [
    content-type:   coap-content-format,
    content-format: JC< $manifest-body-json,
                        $manifest-body-cbor >
]

$manifest-body-cbor /= bytes .cbor untagged-coswid
$manifest-body-json /= base64-url-text

$$Claims-Set-Claims //= (
    measurements-label => measurements-type
)

measurements-type = [+ measurements-format]

measurements-format = [
    content-type:   coap-content-format,
    content-format: JC< $measurements-body-json,
                        $measurements-body-cbor >
]

$measurements-body-cbor /= bytes .cbor untagged-coswid
$measurements-body-json /= base64-url-text

$$Claims-Set-Claims //= (
    measurement-results-label =>
        [ + measurement-results-group ] )

measurement-results-group = [
    measurement-system: tstr,
    measurement-results: [ + individual-result ]
]

individual-result = [
    result-id:  tstr / binary-data,
    result:     result-type,
]

result-type = comparison-successful /
              comparison-fail /
              comparison-not-run /
              measurement-absent

comparison-successful    = JC< "success",       1 >
comparison-fail          = JC< "fail",          2 >
comparison-not-run       = JC< "not-run",       3 >
measurement-absent       = JC< "absent",        4 >

Detached-Submodule-Digest = [
   hash-algorithm : text / int,
   digest         : binary-data
]

BUNDLE-Messages = BUNDLE-Tagged-Message / BUNDLE-Untagged-Message

BUNDLE-Tagged-Message   = #6.602(BUNDLE-Untagged-Message)
BUNDLE-Untagged-Message = Detached-EAT-Bundle

Detached-EAT-Bundle = [
    main-token : Nested-Token,
    detached-claims-sets: {
        + tstr => JC-NEST-SAFE<json-wrapped-claims-set,
                               cbor-wrapped-claims-set>
    }
]

json-wrapped-claims-set = base64-url-text

cbor-wrapped-claims-set = bstr .cbor Claims-Set

nonce-label                = JC< "eat_nonce",    10 >
ueid-label                 = JC< "ueid",         256 >
sueids-label               = JC< "sueids",       257 >
oemid-label                = JC< "oemid",        258 >
hardware-model-label       = JC< "hwmodel",      259 >
hardware-version-label     = JC< "hwversion",    260 >
uptime-label               = JC< "uptime",       261 >
oem-boot-label             = JC< "oemboot",      262 >
debug-status-label         = JC< "dbgstat",      263 >
location-label             = JC< "location",     264 >
profile-label              = JC< "eat_profile",  265 >
submods-label              = JC< "submods",      266 >
boot-count-label           = JC< "bootcount",    267 >
boot-seed-label            = JC< "bootseed",     268 >
dloas-label                = JC< "dloas",        269 >
sw-name-label              = JC< "swname",       270 >
sw-version-label           = JC< "swversion",    271 >
manifests-label            = JC< "manifests",    272 >
measurements-label         = JC< "measurements", 273 >
measurement-results-label  = JC< "measres" ,     274 >
intended-use-label         = JC< "intuse",       275 >

]]></sourcecode> >]]></sourcecode>

        </section>
        <section anchor="cbor-specific-cddl">
          <name>CBOR-Specific CDDL</name>

          <sourcecode type="CDDL"><![CDATA[
EAT-CBOR-Token = $EAT-CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token

$EAT-CBOR-Tagged-Token /= CWT-Tagged-Message
$EAT-CBOR-Tagged-Token /= BUNDLE-Tagged-Message

$EAT-CBOR-Untagged-Token /= CWT-Untagged-Message
$EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message

Nested-Token = CBOR-Nested-Token

CBOR-Nested-Token =
    JSON-Token-Inside-CBOR-Token /
    CBOR-Token-Inside-CBOR-Token

CBOR-Token-Inside-CBOR-Token = bstr .cbor $EAT-CBOR-Tagged-Token

JSON-Token-Inside-CBOR-Token = tstr

$$Claims-Set-Claims //= (submods-label => { + text => Submodule })

Submodule = Claims-Set / CBOR-Nested-Token /
            Detached-Submodule-Digest

]]></sourcecode>
            Detached-Submodule-Digest]]></sourcecode>

        </section>
        <section anchor="json-specific-cddl">
          <name>JSON-Specific CDDL</name>

          <sourcecode type="CDDL"><![CDATA[
EAT-JSON-Token = $EAT-JSON-Token-Formats

$EAT-JSON-Token-Formats /= JWT-Message
$EAT-JSON-Token-Formats /= BUNDLE-Untagged-Message

Nested-Token = JSON-Selector

JSON-Selector = $JSON-Selector

$JSON-Selector /= [type: "JWT", nested-token: JWT-Message]
$JSON-Selector /= [type: "CBOR", nested-token:
  CBOR-Token-Inside-JSON-Token]
$JSON-Selector /= [type: "BUNDLE", nested-token: Detached-EAT-Bundle]
$JSON-Selector /= [type: "DIGEST", nested-token:
  Detached-Submodule-Digest]

CBOR-Token-Inside-JSON-Token = base64-url-text

$$Claims-Set-Claims //= (submods-label => { + text => Submodule })

Submodule = Claims-Set / JSON-Selector

]]></sourcecode> JSON-Selector]]></sourcecode>

        </section>
      </section>
    </section>
    <section anchor="privacyconsiderations">
      <name>Privacy Considerations</name>
      <t>Certain EAT claims can be used to track the owner of an entity;
therefore, implementations should consider privacy-preserving
options dependent on the usage of the EAT.
For example, the location claim might be suppressed in EATs sent to unauthenticated consumers.</t>
      <section anchor="ueidprivacyconsiderations">
        <name>UEID and SUEID Privacy Considerations</name>
        <t>A UEID is usually not privacy-preserving. Relying parties
receiving tokens from a particular entity will be
able to know that the tokens are from the same entity and be able to identify the entity issuing those tokens.</t>
        <t>Thus
        <t>Thus, the use of the claim may violate privacy policies. In other usage situations situations, a UEID will
not be allowed for certain products like such as browsers that give privacy
for the end user. It will often be the case that tokens will not have
a UEID for these reasons.</t>
        <t>An SUEID is also usually not privacy-preserving.  In some cases cases, it may
have fewer privacy issues than a UEID depending on when and how and
when it is generated.</t>
        <t>There are several strategies that can be used to still be able to put
UEIDs and SUEIDs in tokens:</t>
        <ul spacing="normal">
          <li>
            <t>The entity obtains explicit permission from the user of the entity
to use the UEID/SUEID. This UEID/SUEID; this may be through a prompt. It may also be prompt or through
a license agreement.  For example, agreements for some online banking
and brokerage services might already cover use of a UEID/SUEID.</t>
          </li>
          <li>
            <t>The UEID/SUEID is used only in a particular context or particular use
case. It is used only by one relying party.</t>
          </li>
          <li>
            <t>The entity authenticates the relying party and generates a derived UEID/SUEID just for that particular relying party.  For example, the relying
party could prove their identity cryptographically to the entity, then
the entity generates a UEID just for that relying party by hashing a
proofed relying party ID with the main entity UEID/SUEID.</t>
          </li>
        </ul>
        <t>Note that some of these privacy preservation strategies result in
multiple UEIDs and SUEIDs per entity. Each UEID/SUEID is used in a
different context, use case case, or system on the entity. However, from the
view of the relying party, there is just one UEID and it is still
globally universal across manufacturers.</t>
      </section>
      <section anchor="locationprivacyconsiderations">
        <name>Location Privacy Considerations</name>
        <t>Geographic location is most almost always considered personally identifiable information.
Implementers
Implementors should consider laws and regulations governing the transmission of location data from end user end-user devices to servers and services.
Implementers
Implementors should consider using location management facilities offered by the operating system on the entity generating the attestation.
For example, many mobile phones prompt the user for permission before sending location data.</t>
      </section>
      <section anchor="bootseedprivacyconsiderations">
        <name>Boot Seed Privacy Considerations</name>
        <t>The "bootseed" claim is effectively a stable entity identifier within a given boot epoch.  Therefore, it is not suitable for use in attestation schemes that are privacy-preserving.</t>
      </section>
      <section anchor="replayprivacyconsiderations">
        <name>Replay Protection and Privacy</name>
        <t>EAT defines the EAT nonce claim for replay protection and token freshness.
The nonce claim is based on a value usually derived remotely (outside of the entity).
This claim might be used to extract and convey personally identifying information either inadvertently or by intention.
For instance, an implementor may choose a nonce equivalent to a username associated with the device (e.g., account login).
If the token is inspected by a 3rd-party third party, then this information could be used to identify the source of the token or an account associated with the token.
To avoid the conveyance of privacy-related information in the nonce claim, it should be derived using a salt that originates from a true and reliable random number generator or any other source of randomness that would still meet the target system requirements for replay protection and token freshness.</t>
      </section>
    </section>
    <section anchor="securitycons">
      <name>Security Considerations</name>
      <t>The security considerations provided in Section 8 of <xref target="RFC8392"/> target="RFC8392" sectionFormat="of" section="8"/> and Section 11 of <xref target="RFC7519"/> target="RFC7519" sectionFormat="of" section="11"/> apply to EAT in its CWT and JWT form, respectively.  Moreover, Chapter 12
of <xref target="RFC9334"/> target="RFC9334" sectionFormat="of" section="12"/> is also applicable to implementations of EAT.  In addition,
implementors should consider the following.</t> information in the following subsections.</t>
      <section anchor="claim-trustworthiness">
        <name>Claim Trustworthiness</name>
        <t>This specification defines semantics for each claim.
It does not require any particular level of security in the implementation of the claims or even for the attester itself.
Such specification is far beyond the scope of this document document, which is about a message format not the security level of an implementation.</t>
<t>The receiver of an EAT comes to know knows the trustworthiness of the claims in it by understanding the implementation made by the attester vendor and/or understanding the checks and processing performed by the verifier.</t>

<!--[rfced] Section 9.1. The following text does not parse
(specifically, the latter part after the comma). Please let us
know how we may update for clarity.

Original:
   For example, this document says that a UEID is permanent and that it
   must not change, but it does not say what degree of attack to change
   it must be defended.

Perhaps:
   For example, this document states that a UEID is permanent and that it
   must not change, but it does not state if change is needed to defend
   against a certain degree of attack.
-->

        <t>For example, this document says that a UEID is permanent and that it must not change, but it does not say what degree of attack to change it must be defended.</t>
        <t>The degree of security will vary from use case to use case.
In some cases cases, the receiver may only need to know something of the implementation such as that it was implemented in a TEE.
In other cases cases, the receiver may require the attester to be certified by a particular certification program.
Or perhaps the receiver is content with very little security.</t>
      </section>
      <section anchor="key-provisioning">
        <name>Key Provisioning</name>
        <t>Private key material can be used to sign and/or encrypt the EAT, EAT or
can be used
to derive the keys used for signing and/or encryption.  In
some instances, the manufacturer of the entity may create the key
material separately and provision the key material in the entity
itself.  The manufacturer of any entity that is capable of producing
an EAT should take care to ensure that any private key material be
suitably protected prior to provisioning the key material in the
entity itself.  This can require creation of key material in an
enclave (see <xref target="RFC4949"/> for definition of "enclave"), secure
transmission of the key material from the enclave to the entity using
an appropriate protocol, and persistence of the private key material
in some form of secure storage to which (preferably) only the entity
has access.</t>
        <section anchor="transmission-of-key-material">
          <name>Transmission of Key Material</name>
          <t>Regarding transmission of key material from the enclave to the entity,
the key material may pass through one or more intermediaries.
Therefore
Therefore, some form of protection ("key wrapping") (e.g., key wrapping) may be necessary.
The transmission itself may be performed electronically, but it can also
be done by human courier.  In the latter case, there should be minimal
to no exposure of the key material to the human (e.g. (e.g., encrypted
portable memory).  Moreover, the human should transport the key
material directly from the secure enclave where it was created to a
destination secure enclave where it can be provisioned.</t>
        </section>
      </section>
      <section anchor="sec-con-freshness">
        <name>Freshness</name>
        <t>All EAT use <bcp14>MUST</bcp14> provide a freshness mechanism to prevent replay and related attacks. The extensive discussions on freshness in <xref target="RFC9334"/> including on freshness, as well as the security considerations considerations, apply here.
The EAT nonce claim, in <xref target="nonce"/>, is one One option to provide freshness.</t> freshness is the EAT nonce claim (<xref target="nonce"/>).</t>
      </section>
      <section anchor="multiple-eat-consumers">
        <name>Multiple EAT Consumers</name>
        <t>In many cases, more than one EAT consumer may be required to fully
verify the entity attestation.  Examples include individual consumers
for nested EATs, EATs or consumers for individual claims with an EAT.  When
multiple consumers are required for verification of an EAT, it is
important to minimize information exposure to each consumer.  In
addition, the communication between multiple consumers should be
secure.</t>
        <t>For instance, consider the example of an encrypted and signed EAT with
multiple claims.  A consumer may receive the EAT (denoted as the
"receiving consumer"), decrypt its payload, and verify its signature, signature but
then pass specific subsets of claims to other consumers for evaluation
("downstream consumers").  Since any COSE encryption will be removed
by the receiving consumer, the communication of claim subsets to any
downstream consumer <bcp14>MUST</bcp14> leverage an equivalent communication security protocol
(e.g. Transport Layer Security).</t>
(e.g., TLS).</t>
        <t>However, assume the EAT of the previous example is hierarchical and
each claim subset for a downstream consumer is created in the form of
a nested EAT.  Then  Then, the nested EAT is itself is encrypted and cryptographically verifiable (due to its COSE envelope) by a downstream consumer (unlike the previous example where a claims set
without a COSE envelope is sent to a downstream consumer).  Therefore, Transport Layer Security TLS between the receiving and downstream consumers is not strictly required.  Nevertheless,
downstream consumers of a nested EAT should provide a nonce unique to
the EAT they are consuming.</t>
      </section>
      <section anchor="detached-eat-bundle-digest-security-considerations">
        <name>Detached EAT Bundle Digest Security Considerations</name>
        <t>A detached EAT bundle is composed of a nested EAT and
a claims set as per <xref target="DEB"/>.  Although the attached claims set is vulnerable to
modification in transit, any modification can be detected by the receiver through the associated digest, which is a claim fully contained within an EAT.  Moreover, the digest itself can only be derived using
an appropriate COSE hash algorithm, implying that an attacker cannot induce false detection
of modified detached claims because the algorithms in the COSE registry are assumed to be
of sufficient cryptographic strength.</t>
      </section>
      <section anchor="verfication-key-sc">
        <name>Verification Keys</name>
        <t>In all cases cases, there must be some way that the verification key is itself is verified or determined to be trustworthy. The key identification itself is never enough.
This will always be by some out-of-band mechanism that is not described here.
For example, the verifier may be configured with a root certificate or a master key by the verifier system administrator.</t>
        <t>Often
        <t>Often, an X.509 certificate or an endorsement carries more than just the verification key.
For example, an X.509 certificate might have key usage constraints, and an endorsement might have reference values.
When this is the case, the key identifier must be either a protected header or in the payload, such that it is cryptographically bound to the EAT.
This is in line with the requirements in section 6 on Key Identification in "Key Identification" of JSON Web Signature <xref target="RFC7515"/>.</t> (<xref target="RFC7515" sectionFormat="of" section="6"/>).</t>
      </section>
    </section>
    <section anchor="iana-cons">
      <name>IANA Considerations</name>
      <section anchor="reuse-of-cbor-and-json-web-token-cwt-and-jwt-claims-registries">
        <name>Reuse of CBOR and JSON Web Token (CWT and JWT) Claims Registries</name>
        <t>Claims defined for EAT are compatible with those of CWT and JWT JWT,
so the CWT and JWT Claims Registries, registries, <xref target="IANA.CWT.Claims"/> and <xref target="IANA.JWT.Claims"/>, are re-used. reused. No new IANA registry
is created.</t>
        <t>All EAT claims defined in this document are have been placed in both registries.
All new EAT claims defined subsequently should be placed in both registries.</t>
        <t><xref target="Claim_Characteristics"/> describes some considerations when defining new claims.</t>
      </section>
      <section anchor="cwt-and-jwt-claims-registered-by-this-document">
        <name>CWT and JWT Claims Registered by This Document</name>
        <t>This specification adds
        <t>Per this specification, the following values have been added to the "JSON Web Token
Claims" registry established by <xref target="RFC7519"/> and the "CBOR Web Token Claims Registry" (CWT) Claims" registry established by <xref target="RFC8392"/>.
Each entry below is an addition has been added to both registries.</t>
<t>The "Claim Description", "Change Controller" Controller", and "Specification Documents" "Reference" fields are common and equivalent for the JWT and CWT registries. The "Claim Key" and "Claim Value Types(s)" Type" fields are for the CWT registry only.
The "Claim Name" field is as defined for the CWT registry, not the JWT registry.
The "JWT Claim Name" field is equivalent to the "Claim Name" field in the JWT registry.</t>
        <t>IANA is requested to register has registered the following claims. Here,
the "Claim Value Type" fields name CDDL definitions and are only for the CWT registry.</t>

<!--[rfced] Section 10.2. Is this sentence necessary?

Original:
   The "Claim Value
   Type(s)" here all name CDDL definitions and are only for the CWT registry.</t>
        <t><cref anchor="to-be-removed-3">RFC editor: please see instructions
   registry.

It seems redundant with this text in followg paragraph the preceding paragraph:

   The "Claim Key" and remove "Claim Value Types(s)" are for final publication</cref></t>
        <t>RFC Editor: the CWT registry
   only.
-->

<!--[rfced] Below are questions about the IANA-related text.
In addition to responding to these questions, please review
all of the IANA-related updates carefully and let us know
if any further updates are needed.

a) Section 4.2.18.2. Please make clarify which IANA registry is
being referred to in the following adjustments last sentence (i.e., the "JOSE Algorithm
registry"). Is it the "JSON Web Signature and Encryption
Algorithms" registry <https://www.iana.org/assignments/jose/>?

Original:
   The hash algorithm identifier is always from the COSE
   Algorithm registry, [IANA.COSE.Algorithms].  Either the integer or
   string identifier may be used.  The hash algorithm identifier is
   never from the JOSE Algorithm registry.

Perhaps:
   The hash algorithm identifier is always from the "COSE Algorithms"
   registry [IANA.COSE.Algorithms].  Either the integer or
   the string identifier may be used.  The hash algorithm identifier is
   never from the "JSON Web Signature and Encryption Algorithms" registry.

b) Section 10.2. May we remove all quote marks from the JWT Claim Name
fields? We note that quote marks are not used in the "CBOR Web Token
(CWT) Claims" registry <https://www.iana.org/assignments/cwt>.
For example:
OLD: JWT Claim Name: "eat_nonce"
NEW: JWT Claim Name: eat_nonce

c) Section 10.2. In the "CBOR Web Token (CWT) Claims" registry
for eat_nonce (Claim Key 10), the Reference field includes "OpenID
Connect Core 1.0" (https://openid.net/specs/openid-connect-core-1_0.html),
but the Reference field in the draft did not. FYI, this paragraph.
Replace "<strong>this document</strong>" with this RFC number. document
has been updated to match the registry, and "OpenID Connect Core 1.0"
has been added as an informative reference.

In the following, JWT Claims registry, should "eat_nonce" have a matching
Reference field? (This document states the claims with Reference fields are
"common and equivalent".) If so, we will ask IANA to update the registry
as follows.

Old: eat_nonce  Nonce   [IETF]  [RFC-ietf-rats-eat-30]
New: eat_nonce  Nonce   [IETF]  [OpenID Connect Core 1.0][RFC-ietf-rats-eat-30]

d) Section 10.2. Regarding "Claim Key: TBD" need Description" (in both the CWT and JWT
Claims registries), would you like to be assigned a value in update these to remove 'Indicates'
so they are similar to other descriptions? If so, we will ask IANA to
update the Specification Required Range, preferably starting around 267.
Those below already registries accordingly with a Claim Key number were given early assignment.
No change is requested any changes made.

Original:
   ueid          The Universal Entity ID

   sueids        Semi-permanent UEIDs

   hwmodel       Model identifier for them except hardware

   dbgstat       Indicates status of debug facilities

   eat_profile 	 Indicates the EAT profile followed

   intuse        Indicates intended use of the EAT

Perhaps:
   ueid          Universal Entity ID

   sueids        Semipermanent UEIDs

   hwmodel       Model identifier for Claim Key 262.
Claim 262 should be renamed from "secboot" hardware

   dbgstat       The status of debug facilities

   eat_profile 	 The EAT profile followed

   intuse        The intended use of the EAT

e) Section 10.3. In the "DEV URN Subtypes" registry, may we
update the descriptions as follows?
- change "Identifier" to "oemboot" "ID" to match the "JSON Web Token Claims"
registry, "CBOR Web Token (CWT) Claims" registry, and the running text in
this document.
- change "Semi-permanent" to "Semipermanent" per Merriam-Webster
(throughout this document and in the JWT two other registries).

Original:
   ueid    Universal Entity Identifier
   sueid   Semi-permanent Universal Entity Identifier

Perhaps:
   ueid    Universal Entity ID
   sueid   Semipermanent Universal Entity ID

f) Section 10.4. FYI - In the "CBOR Tags" registry and its description changed at
https://www.iana.org/assignments/cbor-tags/, the reference to Section 5
of this document is included under the Semantics column. We will ask
IANA to update the registry so that "RFC 9711, Section 5" is only
in both the CWT Reference column.

Original:
           +=====+============+===============================+
           | Tag | Data Items | Semantics                     |
           +=====+============+===============================+
           | 602 | array      | Detached EAT Bundle Section 5 |

Current:
   +=====+===========+=====================+=====================+
   | Tag | Data Item | Semantics           | Reference           |
   +=====+===========+=====================+=====================+
   | 602 | array     | Detached EAT Bundle | RFC 9711, Section 5 |

g) Section 10.5. The columns for the "Entity Attestation Token
(EAT) Intended Uses" registry are "Integer", "Name", and JWT registries.</t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: Nonce</t>
          </li>
          <li>
            <t>Claim Description: Nonce</t>
          </li>
          <li>
            <t>JWT
"Description" in this document, but "Value", "Description", and
"Reference" in the IANA registry <https://www.iana.org/assignments/rats>.
Which one is correct?  If the IANA registry is correct, please provide
updated text for Section 10.5 where it describes the three columns.
-->

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>Nonce</dd>
            <dt>Claim Description:</dt><dd>Nonce</dd>
            <dt>JWT Claim Name: "eat_nonce"</t>
          </li>
          <li>
            <t>Claim Key: 10</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"eat_nonce"</dd>
            <dt>Claim Key:</dt><dd>10</dd>
            <dt>Claim Value Type(s): bstr Type:</dt><dd>bstr or array</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: UEID</t>
          </li>
          <li>
            <t>Claim Description: The array</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd><xref target="OIDCC"/>, RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>UEID</dd>
            <dt>Claim Description:</dt><dd>The Universal Entity ID</t>
          </li>
          <li>
            <t>JWT ID</dd>
            <dt>JWT Claim Name: "ueid"</t>
          </li>
          <li>
            <t>CWT Name:</dt><dd>"ueid"</dd>
            <dt>CWT Claim Key: 256</t>
          </li>
          <li>
            <t>Claim Key:</dt><dd>256</dd>
            <dt>Claim Value Type(s): bstr</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: SUEIDs</t>
          </li>
          <li>
            <t>Claim Description: Semi-permanent UEIDs</t>
          </li>
          <li>
            <t>JWT Type:</dt><dd>bstr</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
	</dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>SUEIDs</dd>
            <dt>Claim Description:</dt><dd>Semi-permanent UEIDs</dd>
            <dt>JWT Claim Name: "sueids"</t>
          </li>
          <li>
            <t>CWT Name:</dt><dd>"sueids"</dd>
            <dt>CWT Claim Key: 257</t>
          </li>
          <li>
            <t>Claim Key:</dt><dd>257</dd>
            <dt>Claim Value Type(s): map</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: Hardware Type:</dt><dd>map</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>Hardware OEM ID</t>
          </li>
          <li>
            <t>Claim Description: Hardware ID</dd>
            <dt>Claim Description:</dt><dd>Hardware OEM ID</t>
          </li>
          <li>
            <t>JWT ID</dd>
            <dt>JWT Claim Name: "oemid"</t>
          </li>
          <li>
            <t>Claim Key: 258</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"oemid"</dd>
            <dt>Claim Key:</dt><dd>258</dd>
            <dt>Claim Value Type(s): bstr Type:</dt><dd>bstr or int</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: Hardware Model</t>
          </li>
          <li>
            <t>Claim Description: Model int</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>Hardware Model</dd>
            <dt>Claim Description:</dt><dd>Model identifier for hardware</t>
          </li>
          <li>
            <t>JWT hardware</dd>
            <dt>JWT Claim Name: "hwmodel"</t>
          </li>
          <li>
            <t>Claim Key: 259</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"hwmodel"</dd>
            <dt>Claim Key:</dt><dd>259</dd>
            <dt>Claim Value Type(s): bstr</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: Hardware Version</t>
          </li>
          <li>
            <t>Claim Description: Hardware Type:</dt><dd>bstr</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>Hardware Version</dd>
            <dt>Claim Description:</dt><dd>Hardware Version Identifier</t>
          </li>
          <li>
            <t>JWT Identifier</dd>
            <dt>JWT Claim Name: "hwversion"</t>
          </li>
          <li>
            <t>Claim Key: 260</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"hwversion"</dd>
            <dt>Claim Key:</dt><dd>260</dd>
            <dt>Claim Value Type(s): array</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: OEM Type:</dt><dd>array</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>Uptime</dd>
            <dt>Claim Description:</dt><dd>Uptime</dd>
            <dt>JWT Claim Name:</dt><dd>"uptime"</dd>
            <dt>Claim Key:</dt><dd>261</dd>
            <dt>Claim Value Type:</dt><dd>uint</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>OEM Authorized Boot</t>
          </li>
          <li>
            <t>Claim Description: Indicates Boot</dd>
            <dt>Claim Description:</dt><dd>Indicates whether the software booted was OEM authorized</t>
          </li>
          <li>
            <t>JWT authorized</dd>
            <dt>JWT Claim Name: "oemboot"</t>
          </li>
          <li>
            <t>Claim Key: 262</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"oemboot"</dd>
            <dt>Claim Key:</dt><dd>262</dd>
            <dt>Claim Value Type(s): bool</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: Debug Status</t>
          </li>
          <li>
            <t>Claim Description: Indicates Type:</dt><dd>bool</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>Debug Status</dd>
            <dt>Claim Description:</dt><dd>Indicates status of debug facilities</t>
          </li>
          <li>
            <t>JWT facilities</dd>
            <dt>JWT Claim Name: "dbgstat"</t>
          </li>
          <li>
            <t>Claim Key: 263</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"dbgstat"</dd>
            <dt>Claim Key:</dt><dd>263</dd>
            <dt>Claim Value Type(s): uint</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: Location</t>
          </li>
          <li>
            <t>Claim Description: The Type:</dt><dd>uint</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>Location</dd>
            <dt>Claim Description:</dt><dd>The geographic location</t>
          </li>
          <li>
            <t>JWT location</dd>
            <dt>JWT Claim Name: "location"</t>
          </li>
          <li>
            <t>Claim Key: 264</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"location"</dd>
            <dt>Claim Key:</dt><dd>264</dd>
            <dt>Claim Value Type(s): map</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: EAT Profile</t>
          </li>
          <li>
            <t>Claim Description: Indicates Type:</dt><dd>map</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>EAT Profile</dd>
            <dt>Claim Description:</dt><dd>Indicates the EAT profile followed</t>
          </li>
          <li>
            <t>JWT followed</dd>
            <dt>JWT Claim Name: "eat_profile"</t>
          </li>
          <li>
            <t>Claim Key: 265</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"eat_profile"</dd>
            <dt>Claim Key:</dt><dd>265</dd>
            <dt>Claim Value Type(s): uri Type:</dt><dd>uri or oid</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: Submodules Section</t>
          </li>
          <li>
            <t>Claim Description: The oid</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>Submodules Section</dd>
            <dt>Claim Description:</dt><dd>The section containing submodules</t>
          </li>
          <li>
            <t>JWT submodules</dd>
            <dt>JWT Claim Name: "submods"</t>
          </li>
          <li>
            <t>Claim Key: 266</t>
          </li>
          <li>
            <t>Claim Value Type(s): map</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: Uptime</t>
          </li>
          <li>
            <t>Claim Description: Uptime</t>
          </li>
          <li>
            <t>JWT Claim Name: "uptime"</t>
          </li>
          <li>
            <t>Claim Key: 261</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"submods"</dd>
            <dt>Claim Key:</dt><dd>266</dd>
            <dt>Claim Value Type(s): uint</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: Boot Count</t>
          </li>
          <li>
            <t>Claim Description: The Type:</dt><dd>map</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>Boot Count</dd>
            <dt>Claim Description:</dt><dd>The number of times the entity or submodule has been booted</t>
          </li>
          <li>
            <t>JWT booted</dd>
            <dt>JWT Claim Name: "bootcount"</t>
          </li>
          <li>
            <t>Claim Key: 267</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"bootcount"</dd>
            <dt>Claim Key:</dt><dd>267</dd>
            <dt>Claim Value Type(s): uint</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: Boot Seed</t>
          </li>
          <li>
            <t>Claim Description: Identifies Type:</dt><dd>uint</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>Boot Seed</dd>
            <dt>Claim Description:</dt><dd>Identifies a boot cycle</t>
          </li>
          <li>
            <t>JWT cycle</dd>
            <dt>JWT Claim Name: "bootseed"</t>
          </li>
          <li>
            <t>Claim Key: 268</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"bootseed"</dd>
            <dt>Claim Key:</dt><dd>268</dd>
            <dt>Claim Value Type(s): bstr</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: DLOAs</t>
          </li>
          <li>
            <t>Claim Description: Certifications Type:</dt><dd>bstr</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>DLOAs</dd>
            <dt>Claim Description:</dt><dd>Certifications received as Digital Letters of Approval</t>
          </li>
          <li>
            <t>JWT Approval</dd>
            <dt>JWT Claim Name: "dloas"</t>
          </li>
          <li>
            <t>Claim Key: 269</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"dloas"</dd>
            <dt>Claim Key:</dt><dd>269</dd>
            <dt>Claim Value Type(s): array</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: Software Name</t>
          </li>
          <li>
            <t>Claim Description: The Type:</dt><dd>array</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>Software Name</dd>
            <dt>Claim Description:</dt><dd>The name of the software running in the entity</t>
          </li>
          <li>
            <t>JWT entity</dd>
            <dt>JWT Claim Name: "swname"</t>
          </li>
          <li>
            <t>Claim Key: 270</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"swname"</dd>
            <dt>Claim Key:</dt><dd>270</dd>
            <dt>Claim Value Type(s): tstr</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: Software Version</t>
          </li>
          <li>
            <t>Claim Description: The Type:</dt><dd>tstr</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>Software Version</dd>
            <dt>Claim Description:</dt><dd>The version of software running in the entity</t>
          </li>
          <li>
            <t>JWT entity</dd>
            <dt>JWT Claim Name: "swversion"</t>
          </li>
          <li>
            <t>Claim Key: 271</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"swversion"</dd>
            <dt>Claim Key:</dt><dd>271</dd>
            <dt>Claim Value Type(s): array</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: Software Manifests</t>
          </li>
          <li>
            <t>Claim Description: Manifests Type:</dt><dd>array</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>Software Manifests</dd>
            <dt>Claim Description:</dt><dd>Manifests describing the software installed on the entity</t>
          </li>
          <li>
            <t>JWT entity</dd>
            <dt>JWT Claim Name: "manifests"</t>
          </li>
          <li>
            <t>Claim Key: 272</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"manifests"</dd>
            <dt>Claim Key:</dt><dd>272</dd>
            <dt>Claim Value Type(s): array</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: Measurements</t>
          </li>
          <li>
            <t>Claim Description: Measurements Type:</dt><dd>array</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>Measurements</dd>
            <dt>Claim Description:</dt><dd>Measurements of the software, memory configuration configuration, and such on the entity</t>
          </li>
          <li>
            <t>JWT entity</dd>
            <dt>JWT Claim Name: "measurements"</t>
          </li>
          <li>
            <t>Claim Key: 273</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"measurements"</dd>
            <dt>Claim Key:</dt><dd>273</dd>
            <dt>Claim Value Type(s): array</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: Software Type:</dt><dd>array</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>Software Measurement Results</t>
          </li>
          <li>
            <t>Claim Description: The Results</dd>
            <dt>Claim Description:</dt><dd>The results of comparing software measurements to reference values</t>
          </li>
          <li>
            <t>JWT values</dd>
            <dt>JWT Claim Name: "measres"</t>
          </li>
          <li>
            <t>Claim Key: 274</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"measres"</dd>
            <dt>Claim Key:</dt><dd>274</dd>
            <dt>Claim Value Type(s): array</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul>
        <t> </t>
        <ul spacing="normal">
          <li>
            <t>Claim Name: Intended Use</t>
          </li>
          <li>
            <t>Claim Description: Indicates Type:</dt><dd>array</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

        <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>Intended Use</dd>
            <dt>Claim Description:</dt><dd>Indicates intended use of the EAT</t>
          </li>
          <li>
            <t>JWT EAT</dd>
            <dt>JWT Claim Name: "intuse"</t>
          </li>
          <li>
            <t>Claim Key: 275</t>
          </li>
          <li>
            <t>Claim Name:</dt><dd>"intuse"</dd>
            <dt>Claim Key:</dt><dd>275</dd>
            <dt>Claim Value Type(s): uint</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Specification Document(s): <strong>this document</strong></t>
          </li>
        </ul> Type:</dt><dd>uint</dd>
            <dt>Change Controller:</dt><dd>IETF</dd>
            <dt>Reference:</dt><dd>RFC 9711</dd>
        </dl>

      </section>
      <section anchor="registerueidurn">
        <name>UEID URN URNs Registered by this This Document</name>
        <t>IANA is requested to register has registered the following new subtypes in the "DEV URN Subtypes" registry <xref target="IANA.DEV-URNs"/> under the "Device Identification". See Identification" registry group; see <xref target="RFC9039"/>.</t>
        <table align="left" anchor="ueid-urn-reg">
          <name>UEID URN Registration</name>
          <thead>
            <tr>
              <th align="left">Subtype</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">ueid</td>
              <td align="left">Universal Entity Identifier</td>
              <td align="left">This document</td> align="left">RFC 9711</td>
            </tr>
            <tr>
              <td align="left">sueid</td>
              <td align="left">Semi-permanent Universal Entity Identifier</td>
              <td align="left">This document</td> align="left">RFC 9711</td>
            </tr>
          </tbody>
        </table>
        <t>ABNF

<!-- [rfced] FYI, a normative reference to RFC 5234 has been added because
this document contains ABNF. See the IESG statement on "Guidelines for
the Use of Formal Languages in IETF Specifications"
(https://ietf.org/blog/guidelines-use-formal-languages-ietf-specifications/) -
specifically "The use of a language requires a reference to the
specification for that language. This reference is normative ..."

Please review where RFC 5234 is cited and let us know if you prefer
otherwise. Also, RFC 7405 has been added because "%s" is used.

Current:
   The ABNF [RFC5234] [RFC7405] for these two URNs is as follows follows,
   where b64ueid is the base64url-encoded binary byte-string byte string for
   the UEID or SUEID:

   body =/ ueidbody
   ueidbody = %s"ueid:" b64ueid
-->

        <t>The ABNF <xref target="RFC5234"/> <xref target="RFC7405"/> for these two URNs is as follows, where b64ueid is the base64url-encoded binary byte string for the UEID or SUEID:</t>
        <artwork><![CDATA[

        <sourcecode type="abnf"><![CDATA[
body =/ ueidbody
ueidbody = %s"ueid:" b64ueid
]]></artwork>
]]></sourcecode>

      </section>
      <section anchor="cbor-tag-for-detached-eat-bundle-registered-by-this-document">
        <name>CBOR Tag for Detached EAT Bundle Registered by this This Document</name>
        <t>In the "CBOR Tags" registry <xref target="IANA.cbor-tags"/>, IANA is requested to allocate has allocated the
following tag from the Specification Required space, range, with the present document as the
specification reference.</t>
        <table align="left" anchor="deb-tag-reg">
          <name>Detached EAT Bundle Tag Registration</name>
          <thead>
            <tr>
              <th align="left">Tag</th>
              <th align="left">Data Items</th> Item</th>
              <th align="left">Semantics</th>
	      <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">602</td>
              <td align="left">array</td>
              <td align="left">Detached EAT Bundle Bundle</td>
	      <td align="left">RFC 9711, <xref target="DEB"/></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="int-use-registry">
        <name>Intended Use Registry</name>
	<t>IANA is requested to create has created a new registry titled "Entity
	Attestation Token (EAT) Intended Uses" in a under the
	new registry group called "Remote Attestation Procedures (RATS)." (RATS)" registry group.  The registry uses the "Expert
	Review" Expert
	Review registration procedure <xref target="RFC8126"/>.</t>

        <t>Guidelines for designated experts:</t>
        <ul spacing="normal">
          <li>
            <t>Each intended use should be clearly described so a user of it can know knows what it means.</t>
          </li>
          <li>
           <t>Each intended use should be distinct from others that are registered.</t>
          </li>
          <li>
            <t>Point squatting is discouraged.</t>
          </li>
        </ul>
        <t>The three columns for the registry are:</t>
        <dl>
          <dt>Integer:</dt>
          <dd>
            <t>This
        <ol spacing="normal" type="1">
          <li>Integer: This is a unique integer that is used to identify the
          intended use in CBOR-encoded tokens.</t>
          </dd>
          <dt>Name:</dt>
          <dd>
            <t>This tokens.</li>
          <li>Name: This is unique short descriptive string that is used to
          identify the use in JSON-encoded tokens.</t>
          </dd>
          <dt>Description:</dt>
          <dd>
            <t>This tokens.</li>
          <li>Description: This is a text paragraph one or more text paragraphs that
          sufficiently defines define what the intended use means. It may also be a
          reference to another document.</t>
          </dd>
        </dl> document.</li>
        </ol>
        <t>The following 5 values represent the initial content of the registry. Note that 0 will be marked as "reserved" for the CBOR value, and the maximum CBOR value for assignment is 255.</t>
        <dl>
        <dl spacing="normal">
          <dt>1 -- Generic:</dt>
          <dd>
            <t>Generic Generic:</dt><dd> Generic attestation describes an application
          where the EAT consumer requires the most up-to-date security
          assessment of the attesting entity. It is expected that this is the
          most commonly-used commonly used application of EAT.</t>
          </dd>
          <dt>2-- Registration:</dt>
          <dd>
            <t>Entities EAT.</dd>
          <dt>2 -- Registration:</dt><dd> Entities that are registering for a new
          service may be expected to provide an attestation as part of the
          registration process.  This "intuse" setting indicates that the
          attestation is not intended for any use but registration.</t>
          </dd> registration.</dd>
          <dt>3 -- Provisioning:</dt>
          <dd>
            <t>Entities Provisioning:</dt><dd> Entities may be provisioned with different
          values or settings by an EAT consumer.  Examples include key
          material or device management trees.  The consumer may require an
          EAT to assess entity security state of the entity prior to provisioning.</t>
          </dd>
          provisioning.</dd>
          <dt>4 -- Certificate Issuance:</dt>
          <dd>
            <t>Certification Issuance:</dt><dd> Certification Authorities (CAs)
          may require attestation results (which in a background check model
          might require receiving evidence to be passed to a verifier) to make
          decisions about the issuance of certificates.  An EAT may be used as
          part of the certificate signing request (CSR).</t>
          </dd> (CSR).</dd>
          <dt>5 -- Proof-of-Possession:</dt>
          <dd>
            <t>An Proof of Possession:</dt><dd> An EAT consumer may require an
          attestation as part of an accompanying proof-of-possession (PoP)
          application. More precisely, a PoP transaction is intended to
          provide to the recipient cryptographically-verifiable with cryptographically verifiable proof that the
          sender has possession of a key.  This kind of attestation may be
          necessary to verify the security state of the entity storing the
          private key used in a PoP application.</t>
          </dd> application.</dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>

<displayreference target="I-D.ietf-cose-cbor-encoded-cert" to="CBOR.Cert.Draft"/> to="CBOR.Certs"/>
<displayreference target="I-D.ietf-rats-uccs" to="UCCS"/>
<displayreference target="I-D.ietf-rats-eat-media-type" to="EAT.media-types"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8392.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8792.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9052.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9090.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9165.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4517.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9393.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9334.xml"/>

<!-- [rfced] [WGS84] Please review title, but

<!--[rfced] FYI, we updated the URL seems correct for this reference because it
was a direct download of the PDF file. The updated URL points to
a landing page with more information and the option to download
the file instead. Please let us know if you prefer otherwise.

Original:
   [WGS84]  National Geospatial-Intelligence Agency (NGA), "WORLD GEODETIC
            SYSTEM 1984, NGA.STND.0036_1.0.0_WGS84", 8 July 2014,
            <https://earth-info.nga.mil/php/download.php?file=coord-wgs84>.

Current:
   [WGS84]  National Geospatial-Intelligence Agency (NGA), "Department
            of Defense World Geodetic System 1984: Its Definition and
            Relationships with Local Geodetic Systems",
            NGA.STND.0036_1.0.0_WGS84, July 2014,
            <https://nsgreg.nga.mil/doc/view?i=4085>.
-->

        <reference anchor="WGS84" target="https://earth-info.nga.mil/php/download.php?file=coord-wgs84"> target="https://nsgreg.nga.mil/doc/view?i=4085">
          <front>
            <title>WORLD GEODETIC SYSTEM 1984, NGA.STND.0036_1.0.0_WGS84</title>
            <title>Department of Defense World Geodetic System 1984: Its Definition and Relationships with Local Geodetic Systems</title>
            <author>
              <organization>National Geospatial-Intelligence Agency (NGA)</organization>
            </author>
            <date year="2014" month="July" day="08"/> month="July"/>
          </front>
          <refcontent>NGA.STND.0036_1.0.0_WGS84</refcontent>
        </reference>

<!-- [rfced] [IANA.CWT.Claims] URL seems correct -->
        <reference anchor="IANA.CWT.Claims" target="https://www.iana.org/assignments/cwt">
          <front>
            <title>CBOR Web Token (CWT) Claims</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>

<!-- [rfced] [IANA.JWT.Claims] URL seems correct-->  -->
        <reference anchor="IANA.JWT.Claims" target="https://www.iana.org/assignments/jwt">
          <front>
            <title>JSON Web Token (JWT)</title> Claims</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>

<!-- [rfced] [IANA.COSE.Algorithms] URL seems correct--> [IANA.COSE.Algorithms]-->
        <reference anchor="IANA.COSE.Algorithms" target="https://www.iana.org/assignments/cose">
          <front>
            <title>CBOR Object Signing and Encryption (COSE)</title>
            <title>COSE Algorithms</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>

<!-- [rfced] [ThreeGPP.IMEI]

<!--[rfced] FYI, we updated this reference to reflect the most current
version (September 2024). Please review title, URL seems correct-->
        <reference anchor="ThreeGPP.IMEI" target="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=729">
          <front>
            <title>3rd let us know if you prefer otherwise.

Original:
  [ThreeGPP.IMEI]
      3GPP, "3rd Generation Partnership Project; Technical Specification
      Group Core Network and Terminals; Numbering, addressing and
      identification", 2019, <https://portal.3gpp.org/desktopmodules/
      Specifications/SpecificationDetails.aspx?specificationId=729>.

Current:
   [ThreeGPP.IMEI]
      3GPP, "Numbering, addressing and identification", 3GPP
      TS 23.003, Version 19, September 2024,
      <https://portal.3gpp.org/desktopmodules/Specifications/
      SpecificationDetails.aspx?specificationId=729>.
-->

<!-- [ThreeGPP.IMEI]-->
        <reference anchor="ThreeGPP.IMEI" target="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=729">
          <front>
            <title>Numbering, addressing and identification</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date year="2019"/> month="September" year="2024"/>
          </front>
          <seriesInfo name="3GPP TS" value="23.003, Version 19"/>
        </reference>

<!-- [rfced] [DLOA] URL seems correct-->

        <reference anchor="DLOA" target="https://globalplatform.org/wp-content/uploads/2015/12/GPC_DigitalLetterOfApproval_v1.0.pdf">
          <front>
            <title>Digital
            <title>GlobalPlatform Card: Digital Letter of Approval</title>
            <author>
              <organization/>
              <organization>GlobalPlatform</organization>
            </author>
            <date year="2015" month="November"/>
          </front>
          <refcontent>Public Release Version 1.0</refcontent>
          <refcontent>Document Reference: GPC_SPE_095</refcontent>
        </reference>

<!-- [rfced] [PEN] Please review title, URL seems correct-->

        <reference anchor="PEN" target="https://pen.iana.org/pen/PenApplication.page">
          <front>
            <title>Private
            <title>Application for a Private Enterprise Number (PEN) Request</title> Number</title>
            <author>
              <organization/>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>

<!-- [rfced] [IANA.cbor-tags] URL seems correct-->

        <reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignments/cbor-tags">
          <front>
            <title>Concise Binary Object Representation (CBOR)
            <title>CBOR Tags</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>

        <reference anchor="IANA.DEV-URNs" target="https://www.iana.org/assignments/device-identification">
          <front>
            <title>DEV URN Subtypes</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9562.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9039.xml"/>

<!-- [rfced] [BirthdayAttack] URL contains extra period on the end that leads to an error - otherwise seemingly correct-->

        <reference anchor="OIDCC"
target="https://openid.net/specs/openid-connect-core-1_0.html">
          <front>
            <title>OpenID Connect Core 1.0 incorporating errata set 2</title>
            <author initials="N." surname="Sakimura"></author>
            <author initials="J." surname="Bradley"></author>
            <author initials="M." surname="Jones"></author>
            <author initials="B." surname="de Medeiros"></author>
            <author initials="C." surname="Mortimore"></author>
            <date month="December" year="2023"/>
          </front>
        </reference>

        <reference anchor="BirthdayAttack" target="https://en.wikipedia.org/wiki/Birthday_attack."> target="https://en.wikipedia.org/w/index.php?title=Birthday_attack&amp;oldid=1249270346">
          <front>
            <title>Birthday attack</title>
            <author>
              <organization/>
              <organization>Wikipedia</organization>
            </author>
            <date/>
            <date month="October" year="2024"/>
          </front>
        </reference>

<!-- [rfced] [IEEE.802.1AR] DOI seems correct-->

        <reference anchor="IEEE.802.1AR"> anchor="IEEE.802.1AR" target="https://ieeexplore.ieee.org/document/8423794">
          <front>
            <title>IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity</title>
            <author>
              <organization/>
              <organization>IEEE</organization>
            </author>
            <date month="July" month="August" year="2018"/>
          </front>
          <seriesInfo name="IEEE" value="standard"/> name="IEEE Std" value="802.1AR-2018"/>
          <seriesInfo name="DOI" value="10.1109/ieeestd.2018.8423794"/> value="10.1109/IEEESTD.2018.8423794"/>
        </reference>

<!--[rfced] There is a more recent version of this reference
(September 2024). May we point to that version instead, or do you
prefer the 2013 (outdated) version?

Current:
   [W3C.GeoLoc]
       Popescu, A., Ed., "Geolocation API Specification", W3C
       Recommendation, 24 October 2013,
       <https://www.w3.org/TR/2013/REC-geolocation-API-
       20131024/>.

Perhaps:
   [W3C.GeoLoc]
       Cáceres, M. and R. Grant, "Geolocation", W3C
       Recommendation, September 2024,
       <https://www.w3.org/TR/geolocation/>.
-->
<!-- [rfced] [W3C.GeoLoc] URL seems correct though yields an outdated warning-->
XML for most current version:
        <reference anchor="W3C.GeoLoc" target="https://www.w3.org/TR/geolocation/">
          <front>
            <title>Geolocation</title>
            <author fullname="Marcos Cáceres"/>
            <author fullname="Reilly Grant"/>
            <date month="September" year="2024"/>
          </front>
          <refcontent>W3C Recommendation</refcontent>
        </reference>
-->
        <reference anchor="W3C.GeoLoc" target="https://www.w3.org/TR/2013/REC-geolocation-API-20131024/">
          <front>
            <title>Geolocation API Specification</title>
            <author fullname="Andrei Popescu" role="editor"/>
            <date day="24" month="October" year="2013"/>
          </front>
          <seriesInfo name="W3C REC" value="REC-geolocation-API-20131024"/>
          <seriesInfo name="W3C" value="REC-geolocation-API-20131024"/>
          <refcontent>W3C Recommendation</refcontent>
        </reference>

<!-- [rfced]  [OUI.Guide] URL seems correct -->
        <reference anchor="OUI.Guide" target="https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/tutorials/eui.pdf">
          <front>
            <title>Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)</title>
            <author>
              <organization/>
              <organization>IEEE</organization>
            </author>
            <date year="2017" month="August"/>
          </front>
        </reference>

<!-- [rfced] [OUI.Lookup] URL seems correct--> -->
        <reference anchor="OUI.Lookup" target="https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries">
          <front>
            <title>IEEE Registration Authority Authority: Assignments</title>
            <author>
              <organization/>
              <organization>IEEE</organization>
            </author>
            <date/>
          </front>
        </reference>

<!-- [rfced] [IEEE-RA] URL seems correct -->
        <reference anchor="IEEE-RA" target="https://standards.ieee.org/products-services/regauth/index.html">
          <front>
            <title>IEEE Registration Authority</title>
            <author>
              <organization/>
              <organization>IEEE</organization>
            </author>
            <date/>
          </front>
        </reference>

<!-- [rfced] [IEEE.802-2001] URL seems correct--> [IEEE.802-2001]-->
        <reference anchor="IEEE.802-2001"> anchor="IEEE.802-2001" target="https://ieeexplore.ieee.org/document/6847097">
          <front>
            <title>IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture</title>
            <author>
              <organization/>
              <organization>IEEE</organization>
            </author>
            <date month="July" month="June" year="2014"/>
          </front>
          <seriesInfo name="IEEE" value="standard"/> name="IEEE Std" value="802-2014"/>
          <seriesInfo name="DOI" value="10.1109/ieeestd.2014.6847097"/> value="10.1109/IEEESTD.2014.6847097"/>
        </reference>

<!-- [rfced] [I-D.ietf-cose-x509] Published as RFC 9360 -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9360.xml"/>

<!-- [rfced] [I-D.ietf-cose-cbor-encoded-cert] IESG state: I-D Exists as of 08/13/24--> 11/27/24-->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-cose-cbor-encoded-cert.xml"/>

<!-- [rfced] [I-D.ietf-rats-uccs] IESG state: AD Evaluation::AD Followup in EDIT state as of 08/13/24--> 11/27/24-->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-rats-uccs.xml"/>

<!-- [rfced] [JTAG] URl seems correct; DOI: 10.1109/IEEESTD.2010.5412866--> -->
        <reference anchor="JTAG" target="https://ieeexplore.ieee.org/document/5412866">
          <front>
            <title>IEEE Standard for Reduced-Pin and Enhanced-Functionality Test Access Port and Boundary-Scan Architecture</title>
            <author>
              <organization/>
              <organization>IEEE</organization>
            </author>
            <date year="2010" month="February"/>
          </front>
          <seriesInfo name="IEEE Std" value="1149.7-2009"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2010.5412866"/>
        </reference>

<!-- [rfced] [I-D.ietf-rats-eat-media-type] IESG state: Publication Requested in EDIT*R state as of 08/13/24 11/27/24 -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-rats-eat-media-type.xml"/>

<!-- [rfced] [CC-Example] URL seems correct--> [CC-Example]-->
        <reference anchor="CC-Example" target="https://commoncriteriaportal.org/nfs/ccpfiles/files/ppfiles/pp0117V2b_pdf.pdf">
          <front>
            <title>Secure Sub-System in System-on-Chip (3S in SoC) Protection Profile</title>
            <author>
              <organization/>
              <organization>Eurosmart</organization>
            </author>
            <date/>
            <date month="October" year="2023"/>
          </front>
          <refcontent>Version 1.8</refcontent>
        </reference>

<!-- [rfced] [GP-Example] URL seems correct--> -->
        <reference anchor="GP-Example" target="https://globalplatform.org/wp-content/uploads/2021/01/GP_TEECertificationProcess_v2.0_PublicRelease.pdf">
          <front>
            <title>GlobalPlatform Technology Technology: TEE Certification Process</title>
            <author>
              <organization/>
              <organization>GlobalPlatform</organization>
            </author>
            <date/>
            <date month="January" year="2021"/>
          </front>
          <refcontent>Public Release Version 2.0</refcontent>
          <refcontent>Document Reference: GP_PRO_023</refcontent>
        </reference>
      </references>
    </references>

    <section anchor="examples">
      <name>Examples</name>
      <t>Most examples are shown as just a Claims-Set that would be a payload for a CWT, a JWT, a detached EAT bundle bundle, or future token types. The signing is left off so the Claims-Set is easier to see. Some examples of signed tokens are also given.</t>
      <t><cref anchor="to-be-removed-2">RFC

<!--[rfced] Appendix A. Please review this note and let us know if
there are any outstanding actions regarding regenerating the examples.

AUTHOR NOTE:
   RFC Editor: When the IANA values are permanently assigned, please
   contact the authors so the examples can be regenerated. Regeneration
   is required because IANA-assigned values are inside hex and based-64
   encoded data and some of these are signed.</cref></t> signed.
-->

      <section anchor="claims-set-examples">
        <name>Claims Set Examples</name>
        <section anchor="simple-tee-attestation">
          <name>Simple TEE Attestation</name>

          <t>This is a simple attestation of a TEE that TEE; it includes a manifest that is a payload CoSWID to describe the TEE's software.</t>
          <artwork><![CDATA[

<!--[rfced] Questions about the sourcecode

a) We updated <artwork> to <sourcecode> in Sections 1 and 10.3 as
well as Appendices A.1.1 - A.2.3 and D. Please confirm that this is
correct.

In addition, please consider whether the "type" attribute of any sourcecode
element should be set and/or has been set correctly.

The current list of preferred values for "type" is available at
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
If the current list does not contain an applicable type, feel free to
suggest additions for consideration. Note that it is also acceptable
to leave the "type" attribute not set.

...
Sourcecode in the Appendices

b) We notice that each sourcecode element in the appendices contains
introductory text, formatted as a comment within the sourcecode. Should this
text be moved outside of the sourcecode? If not, please consider the questions
that follow.

c) Appendix A.2.1. The text below refers to a section that is
outside of the sourcecode. Should a pointer to "Appendix A.1.7
of RFC 9711" be added?

Original:
   / This is a full CWT-format token. The payload is the   /
   / attestation hardware block above. The main structure  /
   / visible is that of the COSE_Sign1.                    /

Perhaps:
   / This is a full CWT-format token. The payload is the   /
   / attestation hardware block in Appendix A.1.7 of       /
   / RFC 9711. The main structure that is visible is       /
   / that of the COSE_Sign1.                               /

d) Appendix A.2.2. The text below refers to "the next section".
Should a pointer be added to Appendix A.2.3?

Original:
  / Most importantly, it includes a submodule that is a     /
  / detached digest which is the hash of the "TEE" claims   /
  / set in the next section.

e) Appendix D. The text below refers to the I-D
"draft-ietf-rats-uccs". May we move this sentence outside of
the sourcecode so that a citation can be added for the I-D?

Original:
   ; This is replicated from draft-ietf-rats-uccs

   Claims-Set = {
       * $$Claims-Set-Claims
       * Claim-Label .feature "extended-claims-label" => any...

Perhaps:
   The following example is replicated from [UCCS].

   Claims-Set = {
       * $$Claims-Set-Claims
       * Claim-Label .feature "extended-claims-label" => any...

f) Appendix D. Please clarify where a reader can find "claims-set.cddl"
as this is the only mention of it in this document.

Original:
   ; Note that the payload of a JWT is defined in claims-set.cddl. That
   ; definition is common to CBOR and JSON.
-->

          <sourcecode type=""><![CDATA[
/ This is an EAT payload that describes a simple TEE. /

{
    / eat_nonce /       10: h'48df7b172d70b5a18935d0460a73dd71',
    / oemboot /        262: true,
    / dbgstat /        263: 2, / disabled-since-boot /
    / manifests /      272: [
                              [
                               258, / CoAP Content ID for CoSWID    /

                               / This is byte-string wrapped a byte-string-wrapped      /
                               / payload CoSWID. It gives the TEE   /
                               / software name, the version version, and    /
                               / the name of the file it is in.     /
                               / {0: "3a24",                        /
                               /  12: 1,                            /
                               /   1: "Acme TEE OS",                /
                               /  13: "3.1.4",                      /
                               /   2: [{31: "Acme TEE OS", 33: 1},  /
                               /       {31: "Acme TEE OS", 33: 2}], /
                               /   6: {                             /
                               /       17: {                        /
                               /           24: "acme_tee_3.exe"     /
                               /       }                            /
                               /    }                               /
                               /  }                                 /
                               h' a60064336132340c01016b
                                  41636d6520544545204f530d65332e31
                                  2e340282a2181f6b41636d6520544545
                                  204f53182101a2181f6b41636d652054
                                  4545204f5318210206a111a118186e61
                                  636d655f7465655f332e657865'
                              ]
                            ]
}
]]></artwork>
          <artwork><![CDATA[
}]]></sourcecode>

          <sourcecode type=""><![CDATA[
/ A This is a payload CoSWID created by the SW software (SW) vendor. All this really does /
/ this does is name the TEE SW, name its version version, and lists list the one file that  /
/ file that makes up the TEE. /

1398229316({
    / Unique CoSWID ID /    0: "3a24",
    / tag-version /        12: 1,
    / software-name /       1: "Acme TEE OS",
    / software-version /   13: "3.1.4",
    / entity /              2: [
                                   {
        / entity-name /                31: "Acme TEE OS",
        / role        /                33: 1 / tag-creator /
                                   },
                                   {
        / entity-name /                31: "Acme TEE OS",
        / role        /                33: 2 / software-creator /
                                   }
                               ],
    / payload /                6: {
        / ...file /                17: {
            / ...fs-name /             24: "acme_tee_3.exe"
                                   }
                               }
})
]]></artwork>
})]]></sourcecode>

        </section>
        <section anchor="submodules-for-board-and-device">
          <name>Submodules for Board and Device</name>
          <artwork><![CDATA[

<!--[rfced] Appendix A.1.2. To avoid repetition, we updated "with the
CPU" to "containing the CPU". Please review.

Original:
   The main attestation is associated with the chip with the
   CPU and running the main OS.

Current:
   The main attestation is associated with the chip containing
   the CPU and running the main OS.
-->

          <sourcecode type=""><![CDATA[
/ This example shows use of submodules to give information  /
/ about the chip, board board, and overall device.                /
/                                                           /
/ The main attestation is associated with the chip with the          /
/ containing the CPU and running the main OS. It is what    /
/ has the keys and  /
/ produces the token.                      /
/                                                           /
/ The board is made by a different vendor than the chip. chip;    /
/ Perhaps perhaps it is some generic IoT board.                     /
/                                                           /
/ The device is some specific appliance that is made by a   /
/ different vendor than either the chip or the board.       /
/                                                           /
/ Here Here, the board and device submodules aren't the typical  /
/ target environments as described by the RATS architecture Architecture     /
/ document, (RFC 9334), but they are a valid use of submodules.       /

{
    / eat_nonce /       10: h'e253cabedc9eec24ac4e25bcbeaf7765',
    / ueid /           256: h'0198f50a4ff6c05861c8860d13a638ea',
    / oemid /          258: h'894823', / IEEE OUI format OEM ID /
    / hwmodel /        259: h'549dcecc8b987c737b44e40f7c635ce8'
                              / Hash of chip model name /,
    / hwversion /      260: ["1.3.4", 1], / Multipartnumeric  /
    / swname /         270: "Acme OS",
    / swversion /      271: ["3.5.5", 1],
    / oemboot /        262: true,
    / dbgstat /        263: 3, / permanent-disable  /
    / timestamp (iat) /  6: 1526542894,
    / submods / 266: {
        / A submodule to hold some claims about the circuit board /
        "board" :  {
            / oemid /     258: h'9bef8787eba13e2c8f6e7cb4b1f4619a',
            / hwmodel /   259: h'ee80f5a66c1fb9742999a8fdab930893'
                                  / Hash of board module name /,
            / hwversion / 260: ["2.0a", 2] / multipartnumeric+sfx /
        },

        / A submodule to hold claims about the overall device /
        "device" :  {
            / oemid /     258: 61234, / PEN Format OEM ID /
            / hwversion / 260: ["4.0", 1] / Multipartnumeric /
        }
    }
}
]]></artwork>
}]]></sourcecode>

        </section>

        <section anchor="eat-produced-by-attestation-hardware-block">
          <name>EAT Produced by an Attestation Hardware Block</name>
          <artwork><![CDATA[

<!--[rfced] Appendix A.1.3. Is the intention to say that 47 bytes are
encoded in CBOR "including" an 8-byte nonce and 16-byte UEID as
shown below? Please let us know how we may update for clarity.

Original:
   47 bytes encoded in CBOR (8-byte nonce, 16-byte UEID).

Perhaps:
   47 bytes are encoded in CBOR (including an 8-byte nonce and
   a 16-byte UEID).
-->

          <sourcecode type=""><![CDATA[
/ This is an example of a token produced by a HW hardware block      /
/ purpose-built purposely built for attestation.  Only the nonce claim changes  /
/ from one attestation to the next as the rest either come from either   /
/ directly from the hardware directly or from one-time-programmable memory      /
/ (e.g. (e.g., a fuse). 47 bytes are encoded in CBOR (8 byte (8-byte nonce, 16 byte     /
/ 16-byte UEID). /

{
    / eat_nonce /       10: h'd79b964ddd5471c1393c8888',
    / ueid /           256: h'0198f50a4ff6c05861c8860d13a638ea',
    / oemid /          258: 64242, / Private Enterprise Number /
    / oemboot /        262: true,
    / dbgstat /        263: 3, / disabled-permanently /
    / hwversion /      260: [ "3.1", 1 ] / Type is multipartnumeric /
}

]]></artwork>
}]]></sourcecode>

        </section>
        <section anchor="key-key-store-attestation">
          <name>Key / Key Store Attestation</name>
          <artwork><![CDATA[

<!--[rfced] Appendix A.1.4. Within the sourcecode, may we update
"eliptic" to "elliptic" as shown below? If different spacing is
desired, please let us know.

Original:
   / kty /       1: 2, / EC2, eliptic curve with x & y /

Perhaps:
   / kty /       1: 2, / EC2, elliptic curve with x & y/
-->

          <sourcecode><![CDATA[
/ This is an attestation of a public key and the key store     /
/ implementation that protects and manages it. The key store   /
/ implementation is in a security-oriented execution           /
/ environment separate from the high-level OS (HLOS), for      /
/ example example, a Trusted Execution Environment (TEE). The key store      /
/ store is the Attester. attester.                                       /
/                                                              /
/ There is some attestation of the high-level OS, HLOS, just version and      /
/ and boot & and debug status. It is a Claims-Set submodule because/ because  /
/ it has a lower security level than the key store. The key    /
/ store's implementation has access to info about the HLOS, so /
/ it is able to include it.                                    /
/                                                              /
/ A key and an indication of the user authentication given to  /
/ allow access to the key is given. The labels for these are   /
/ in the private space since as this is just a hypothetical example,      /
/ example, not part of a standard protocol.                             /

{
    / eat_nonce /       10: h'99b67438dba40743266f70bf75feb1026d5134
                              97a229bfe8',
    / oemboot /        262: true,
    / dbgstat /        263: 2, / disabled-since-boot /
    / manifests /      272: [
                                [ 258, / CoAP Content ID. /
                                  h'a600683762623334383766
                                    0c000169436172626f6e6974650d6331
                                    2e320e0102a2181f75496e6475737472
                                    69616c204175746f6d6174696f6e1821
                                    02'
                                 ]
                                 / Above is an encoded CoSWID     /
                                 / with the following data        /
                                 /   SW Name: "Carbonite"         /
                                 /   SW Vers: "1.2"               /
                                 /   SW Creator:                  /
                                 /      "Industrial Automation"   /
                            ],
    / exp /              4: 1634324274, / 2021-10-15T18:57:54Z /
    / iat /              6: 1634317080, / 2021-10-15T16:58:00Z /
                   -80000 : "fingerprint",
                   -80001 : { / The key -- A COSE_Key  /
                / kty /       1: 2, / EC2, eliptic curve with x & y /
                / kid /       2: h'36675c206f96236c3f51f54637b94ced',
                / curve /    -1: 2, / curve is P-256 /
                / x-coord /  -2: h'65eda5a12577c2bae829437fe338701a
                                   10aaa375e1bb5b5de108de439c08551d',
                / y-coord /  -3: h'1e52ed75701163f7f9e40ddf9f341b3d
                                   c9ba860af7e0ca7ca7e9eecd0084d19c'
             },

    / submods /        266 : {
                           "HLOS" : { / submod for high-level OS /
         / eat_nonce /         10: h'8b0b28782a23d3f6',
           / oemboot /        262: true,
           / manifests /      272: [
                                [ 258, / CoAP Content ID. /
                                    h'a600687337
                                      6537346b78380c000168
                                      44726f6964204f530d65
                                      52322e44320e0302a218
                                      1F75496E647573747269
                                      616c204175746f6d6174
                                      696f6e182102'
                                  ]
                                  / Above is an encoded CoSWID /
                                  / with the following data:   /
                                  /   SW Name: "Droid OS"      /
                                  /   SW Vers: "R2.D2"         /
                                  /   SW Creator:              /
                                  /     "Industrial Automation"/
                               ]
                           }
                       }
}

]]></artwork>
}]]></sourcecode>

        </section>
        <section anchor="software-measurements-of-an-iot-device">
          <name>Software Measurements of an IoT Device</name>
          <t>This is a simple token that might be for an IoT device.
It includes CoSWID format measurments measurements of the SW. The CoSWID is in byte-string byte string wrapped in the token and is also shown in diagnostic form.</t>
          <artwork><![CDATA[
          <sourcecode type=""><![CDATA[
/ This EAT payload is for an IoT device with a TEE. The attestation /
/ is produced by the TEE. There is a submodule for the IoT OS (the  /
/ main OS of the IoT device that is not as secure as the TEE). The  /
/ submodule contains claims for the IoT OS. The TEE also measures   /
/ the IoT OS and puts the measurements in the submodule.            /

{
    / eat_nonce / 10: h'5e19fba4483c7896',
    / oemboot /  262: true,
    / dbgstat /  263: 2, / disabled-since-boot /
    / oemid /    258: h'8945ad', / IEEE CID based /
    / ueid /     256: h'0198f50a4ff6c05861c8860d13a638ea',
    / submods /  266: {
                        "OS" : {
        / oemboot /         262: true,
        / dbgstat /         263: 2, / disabled-since-boot /
        / measurements /    273: [
                                   [
                                     258, / CoAP Content ID         /

                                    / This is a byte-string wrapped byte-string-wrapped /
                                    / evidence CoSWID. It has       /
                                    / hashes of the main files of   /
                                    / the IoT OS.  /
                                    h'a600663463613234350c
                                      17016d41636d6520522d496f542d4f
                                      530d65332e312e3402a2181f724163
                                      6d6520426173652041747465737465
                                      7218210103a11183a318187161636d
                                      655f725f696f745f6f732e65786514
                                      1a0044b349078201582005f6b327c1
                                      73b4192bd2c3ec248a292215eab456
                                      611bf7a783e25c1782479905a31818
                                      6d7265736f75726365732e72736314
                                      1a000c38b10782015820c142b9aba4
                                      280c4bb8c75f716a43c99526694caa
                                      be529571f5569bb7dc542f98a31818
                                      6a636f6d6d6f6e2e6c6962141a0023
                                      3d3b0782015820a6a9dcdfb3884da5
                                      f884e4e1e8e8629958c2dbc7027414
                                      43a913e34de9333be6'
                                   ]
                                 ]
                               }
                            }
}

]]></artwork>
          <artwork><![CDATA[
}]]></sourcecode>

          <sourcecode type=""><![CDATA[
/ An This is an evidence CoSWID created for the "Acme R-IoT-OS" created by     /
/ that is created by the "Acme Base Attester" (both fictious fictitious   /
/ names). It provides  /
/ measurements of the SW (other than the     /
/ attester SW) on the    /
/ device. /

1398229316({
    / Unique CoSWID ID /    0: "4ca245",
    / tag-version /        12: 23, / Attester-maintained counter /
    / software-name /       1: "Acme R-IoT-OS",
    / software-version /   13: "3.1.4",
    / entity /              2: {
        / entity-name /        31: "Acme Base Attester",
        / role        /        33: 1 / tag-creator /
                            },
    / evidence /            3: {
        / ...file /             17: [
                                    {
            / ...fs-name /              24: "acme_r_iot_os.exe",
            / ...size    /              20: 4502345,
            / ...hash    /               7: [
                                             1, / SHA-256 /
                                             h'05f6b327c173b419
                                               2bd2c3ec248a2922
                                               15eab456611bf7a7
                                               83e25c1782479905'
                                         ]
                                    },
                                    {
            / ...fs-name /              24: "resources.rsc",
            / ...size    /              20: 800945,
            / ...hash    /               7: [
                                              1, / SHA-256 /
                                             h'c142b9aba4280c4b
                                               b8c75f716a43c995
                                               26694caabe529571
                                               f5569bb7dc542f98'
                                         ]
                                    },
                                    {
            / ...fs-name /              24: "common.lib",
            / ...size    /              20: 2309435,
            / ...hash    /               7: [
                                             1, / SHA-256 /
                                             h'a6a9dcdfb3884da5
                                               f884e4e1e8e86299
                                               58c2dbc702741443
                                               a913e34de9333be6'
                                         ]
                                    }
                                ]
                            }
})
]]></artwork>
})]]></sourcecode>

        </section>
        <section anchor="attestation-results-in-json">
          <name>Attestation Results in JSON</name>
          <t>This is a JSON-encoded payload that might be the output of a verifier that evaluated the IoT Attestation example immediately above.</t>
          <t>This particular verifier knows enough about the TEE attester to be able to pass claims like such as debug status directly through to the relying party.
The verifier also knows the reference values for the measured software components and is able to check them.
It informs the relying party that they were correct in the "measres" claim.

<!--[rfced] Appendix A.1.6. We believe "Trustus Verifications" is a
service (rather than multiple services) that verifies the
software component measures, so we have updated accordingly. If
what is shown below is not correct, please let us know.

Original:
   "Trustus Verifications" is the name of the services that verifies the
   software component measurements.

Current:
   "Trustus Verifications" is the name of the service that verifies the
   software component measurements.
-->

"Trustus Verifications" is the name of the service that verifies the software component measurements.</t>
          <artwork><![CDATA[

          <sourcecode type=""><![CDATA[
{
   "eat_nonce": "jkd8KL-8xQk",
   "oemboot": true,
   "dbgstat": "disabled-since-boot",
   "oemid": "iUWt",
   "ueid": "AZj1Ck_2wFhhyIYNE6Y4",
   "swname": "Acme R-IoT-OS",
   "swversion": [
      "3.1.4"
   ],
   "measres": [
      [
         "Trustus Measurements",
         [
            [
               "all",
               "success"
            ]
         ]
      ]
   ]
}
]]></artwork>
}]]></sourcecode>

        </section>
        <section anchor="json-encoded-token-with-submodules">
          <name>JSON-encoded
          <name>JSON-Encoded Token with Submodules</name>
          <t>This example has its
          <t>The lines in this example are wrapped per <xref target="RFC8792"/>.</t>
          <artwork><![CDATA[
          <sourcecode type=""><![CDATA[
{
   "eat_nonce": "lI-IYNE6Rj6O",
   "ueid": "AJj1Ck_2wFhhyIYNE6Y46g==",
   "secboot": true,
   "dbgstat": "disabled-permanently",
   "iat": 1526542894,
   "submods": {
      "Android App Foo": {
         "swname": "Foo.app"
      },
      "Secure Element Eat": [
         "CBOR",
         "2D3ShEOhASagWGaoCkiUj4hg0TpGPhkBAFABmPUKT_bAWGHIhg0TpjjqGQ\
ECGfryGQEFBBkBBvUZAQcDGQEEgmMzLjEBGQEKoWNURUWCL1gg5c-V_ST6txRGdC3VjU\
Pa4XjlX-K5QpGpKRCC_8JjWgtYQPaQywOIZ3-mJKN3X9fLxOhAnsmBa-MvpHRzOw-Ywn\
-67bvJljuctezAPD41s6_At7NbSV3qwJlxIuqGfwe41es="
      ],
      "Linux Android": {
         "swname": "Android"
      },
      "Subsystem J": [
         "JWT",
         "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJKLUF0dGVzd\
GVyIiwiaWF0IjoxNjUxNzc0ODY4LCJleHAiOm51bGwsImF1ZCI6IiIsInN1YiI6IiJ9.\
gjw4nFMhLpJUuPXvMPzK1GMjhyJq2vWXg1416XKszwQ"
      ]
   }
}
]]></artwork>
}]]></sourcecode>

        </section>
      </section>
      <section anchor="signed-token-examples">
        <name>Signed Token Examples</name>
        <section anchor="basic-cwt-example">
          <name>Basic CWT Example</name>
          <t>This is a simple CWT-format token signed with the ECDSA algorithm.</t>
          <artwork><![CDATA[ Elliptic Curve Digital Signature Algorithm (ECDSA).</t>
          <sourcecode type=""><![CDATA[
/ This is a full CWT-format token. The payload is the    /
/ attestation hardware block above. The visible main structure     /
/ visible structure is that of the COSE_Sign1.                   /

61( 18( [
    h'A10126',                           / protected headers  /
    {},                           / empty unprotected headers /
    h'A60A4CD79B964DDD5471C1393C88881901005001
      98F50A4FF6C05861C8860D13A638EA19010219FA
      F2190106F5190107031901048263332E3101',        / payload /
    h'9B9B2F5E470000F6A20C8A4157B5763FC45BE759
      9A5334028517768C21AFFB845A56AB557E0C8973
      A07417391243A79C478562D285612E292C622162
      AB233787'                                   / signature /
] ) )
]]></artwork> )]]></sourcecode>

        </section>
        <section anchor="cbor-encoded-detached-eat-bundle">
          <name>CBOR-encoded
          <name>CBOR-Encoded Detached EAT Bundle</name>
          <t>In this detached EAT bundle, the main token is produced by a HW hardware (HW) attestation block.
The detached Claims-Set is produced by a TEE and is largely identical to the Simple simple TEE examples above. The TEE digests its Claims-Set and feeds that digest to the HW block.</t>
          <t>In a better example example, the attestation produced by the HW block would be a CWT and thus signed and secured by the HW block.
Since the signature covers the digest from the TEE TEE, that Claims-Set is also secured.</t>
          <t>The detached EAT bundle itself can be assembled by untrusted software.</t>
          <artwork><![CDATA[

          <sourcecode type=""><![CDATA[
/ This is a detached EAT bundle tag. /

602([

    / First The first part is a full EAT token with claims like nonce and /
    / and UEID. Most importantly, it includes a submodule that is a  /
    / is a detached digest digest, which is the hash of the "TEE" claims set      /
    / claims set in the next section. The COSE payload is as    /
    / follows:                                                  /
    / { /
    /      10: h'948F8860D13A463E', /
    /     256: h'0198F50A4FF6C05861C8860D13A638EA', /
    /     258: 64242, /
    /     262: true, /
    /     263: 3, /
    /     260: ["3.1", 1], /
    /     266: { /
    /         "TEE": [ /
    /             -16, /
    /              h'8DEF652F47000710D9F466A4C666E209  /
    /                DD74F927A1CEA352B03143E188838ABE' /
    /         ] /
    /     } /
    /   }  /
    h'D83DD28443A10126A05866A80A48948F8860D13A463E1901
      00500198F50A4FF6C05861C8860D13A638EA19010219FAF2
      19010504190106F5190107031901048263332E310119010A
      A163544545822F58208DEF652F47000710D9F466A4C666E2
      09DD74F927A1CEA352B03143E188838ABE5840F690CB0388
      677FA624A3775FD7CBC4E8409EC9816BE32FA474733B0F98
      C27FBAEDBBC9963B9CB5ECC03C3E35B3AFC0B7B35B495DEA
      C0997122EA867F07B8D5EB',
    {
       / A CBOR-encoded byte-string wrapped byte-string-wrapped EAT claims-set. It /
       / contains claims suitable for a TEE.                   /
       "TEE" : h'a40a48948f8860d13a463e190106f519010702
                 190111818218795858a60064336132340c0101
                 6b41636d6520544545204f530d65332e312e34
                 0282a2181f6b41636d6520544545204f531821
                 01a2181f6b41636d6520544545204f53182102
                 06a111a118186e61636d655f7465655f332e65
                 7865'
    }
 ])

]]></artwork>
          <artwork><![CDATA[
 ])]]></sourcecode>

          <sourcecode type=""><![CDATA[
/ This example contains a submodule that is a detached digest, /
/ which is the hash of a Claims-Set convey conveyed outside this token.      /
/ Other than that is token. Additionally, there is the other an example of a token from an  /
/ attestation HW block.                                        /

{
    / eat_nonce /       10: h'3515744961254b41a6cf9c02',
    / ueid /           256: h'0198f50a4ff6c05861c8860d13a638ea',
    / oemid /          258: 64242, / Private Enterprise Number /
    / oemboot /        262: true,
    / dbgstat /        263: 3, / disabled-permanently /
    / hwversion /      260: [ "3.1", 1 ], / multipartnumeric /
    / submods/         266: {
                                "TEE": [ / detached digest submod /
                                           -16, / SHA-256 /
                                           h'e5cf95fd24fab7144674
                                             2dd58d43dae178e55fe2
                                             b94291a9291082ffc263
                                             5a0b'
                                       ]
                            }
}

]]></artwork>
}]]></sourcecode>

        </section>
        <section anchor="json-encoded-detached-eat-bundle">
          <name>JSON-encoded
          <name>JSON-Encoded Detached EAT Bundle</name>
          <t>In this bundle bundle, there are two detached Claims-Sets, Claims-Sets: "Audio Subsystem" and "Graphics Subsystem".
The JWT at the start of the bundle has detached signature submodules with hashes that cover these two Claims-Sets.
The JWT itself is protected using HMAC the Hashed Message Authentication Code (HMAC) with a key of "xxxxxx".</t>
          <t>This example has its
          <t>The lines in this example are wrapped per <xref target="RFC8792"/>.</t>
          <artwork><![CDATA[

          <sourcecode type=""><![CDATA[
[
    [
        "JWT",
        "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlYXRfbm9uY2UiOiJ5dT\
c2Tk44SXVWNmUiLCJzdWJtb2RzIjp7IkF1ZGlvIFN1YnN5c3RlbSI6WyJESUdFU1QiLF\
siU0hBLTI1NiIsIkZSRW4yVlR3aTk5cWNNRVFzYmxtTVFnM2I1b2ZYUG5OM1BJYW5CME\
5RT3MiXV0sIkdyYXBoaWNzIFN1YnN5c3RlbSI6WyJESUdFU1QiLFsiU0hBLTI1NiIsIk\
52M3NqUVU3Q1Z0RFRka0RTUlhWcFZDNUNMVFBCWmVQWWhTLUhoVlZWMXMiXV19fQ.FYs\
7R-TKhgAk85NyCOPQlbtGGjFM_3chnhBEOuM6qCo"
    ],
    {
        "Audio Subsystem" : "ewogICAgImVhdF9ub25jZSI6ICJsSStJWU5FNlJ\
qNk8iLAogICAgInVlaWQiOiAiQWROSlU0b1lYdFVwQStIeDNqQTcvRFEiCiAgICAib2V\
taWQiOiAiaVVXdCIsCiAgICAib2VtYm9vdCI6IHRydWUsIAogICAgInN3bmFtZSI6ICJ\
BdWRpbyBQcm9jZXNzb3IgT1MiCn0K",
        "Graphics Subsystem" : "ewogICAgImVhdF9ub25jZSI6ICJZWStJWU5F\
NlJqNk8iLAogICAgInVlaWQiOiAiQWVUTUlRQ1NVMnhWQmtVdGlndHU3bGUiCiAgICAi\
b2VtaWQiOiA3NTAwMCwKICAgICJvZW1ib290IjogdHJ1ZSwgCiAgICAic3duYW1lIjog\
IkdyYXBoaWNzIE9TIgp9Cg"
    }
]

]]></artwork>
]]]></sourcecode>

        </section>
      </section>
    </section>
    <section anchor="UEID-Design">
      <name>UEID Design Rationale</name>
      <section anchor="collision-probability">
        <name>Collision Probability</name>
        <t>This calculation is to determine the probability of a collision of
type 0x01 UEIDs given the total possible entity population and the number of
entities in a particular entity management database.</t>
        <t>Three different sized different-sized databases are considered. The number of devices
per person roughly models non-personal devices such as traffic lights,
devices in stores they shop in, facilities they work in in, and so on,
even considering individual light bulbs. A device may have
individually attested subsystems, for example example, parts of a car or a
mobile phone. It is assumed that the largest database will have at
most 10% of the world's population of devices. Note that databases
that handle more than a trillion records exist today.</t>
        <t>The trillion-record database size models an easy-to-imagine reality
over the next decades. The quadrillion-record database is roughly at
the limit of what is imaginable and should probably be accommodated.
The 100 quadrillion database is highly speculative perhaps involving
nanorobots for every person, livestock animal animals, and domesticated
bird.
birds. It is included to round out the analysis.</t>
        <t>Note that the items counted here certainly do not have IP address addresses and
are not individually connected to the network. They may be connected
to internal buses, via serial links, Bluetooth via Bluetooth, and so on.  This is
not the same problem as sizing IP addresses.</t>
        <table align="left" anchor="database-size-examples">
          <name>Entity Database Size Examples</name>
          <thead>
            <tr>
              <th align="left">People</th>
              <th align="left">Devices / align="left">Devices/ Person</th>
              <th align="left">Subsystems / align="left">Subsystems/ Device</th>
              <th align="left">Database Portion</th>
              <th align="left">Database Size</th>
           </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">10 billion</td>
              <td align="left">100</td>
              <td align="left">10</td>
              <td align="left">10%</td>
              <td align="left">trillion (10^12)</td> (10<sup>12</sup>)</td>
            </tr>
            <tr>
              <td align="left">10 billion</td>
              <td align="left">100,000</td>
              <td align="left">10</td>
              <td align="left">10%</td>
              <td align="left">quadrillion (10^15)</td> (10<sup>15</sup>)</td>
            </tr>
            <tr>
              <td align="left">100 billion</td>
              <td align="left">1,000,000</td>
              <td align="left">10</td>
              <td align="left">10%</td>
              <td align="left">100 quadrillion (10^17)</td> (10<sup>17</sup>)</td>
            </tr>
          </tbody>
        </table>

        <t>This is conceptually similar to the Birthday Problem where m is the
        number of possible birthdays, always 365, birthdays (always 365) and k is the number of
        people. It is also conceptually similar to the Birthday Attack where
        collisions of the output of hash functions are considered.</t>
        <t>The proper formula for the collision calculation is</t> is:</t>

        <artwork><![CDATA[
   p = 1 - e^{-k^2/(2n)}

   p   Collision Probability
   n   Total e^{-k^2/(2n)}]]></artwork>

	<t>For this calculation:</t>
	<dl newline="false" spacing="compact">
	  <dt>p:</dt> <dd>Collision probability</dd>
	  <dt>n:</dt> <dd>Total possible population
   k   Actual population
]]></artwork> population</dd>
	  <dt>k:</dt> <dd>Actual population</dd>
	</dl>
        <t>However, for the very large values involved here, this formula
        requires floating
point floating-point precision higher than commonly available in
        calculators and software software, so this simple approximation is used. See
        <xref target="BirthdayAttack"/>.</t>

        <artwork><![CDATA[
   p = k^2 / 2n
]]></artwork> 2n]]></artwork>

        <t>For this calculation:</t>
        <artwork><![CDATA[
   p  Collision Probability
   n  Total
	<dl newline="false" spacing="compact">
	  <dt>p:</dt> <dd>Collision probability</dd>
	  <dt>n:</dt> <dd>Total population based on number of bits in UEID
   k  Population UEID</dd>
	  <dt>k:</dt> <dd>Population in a database
]]></artwork> database</dd>
	</dl>
        <table align="left" anchor="ueid-size-options">
          <name>UEID Size Options</name>
          <thead>
            <tr>
              <th align="left">Database Size</th>
              <th align="left">128-bit UEID</th>
              <th align="left">192-bit UEID</th>
              <th align="left">256-bit UEID</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">trillion (10^12)</td> (10<sup>12</sup>)</td>
              <td align="left">2 * 10^-15</td> 10<sup>-15</sup></td>
              <td align="left">8 * 10^-35</td> 10<sup>-35</sup></td>
              <td align="left">5 * 10^-55</td> 10<sup>-55</sup></td>
            </tr>
            <tr>
              <td align="left">quadrillion (10^15)</td> (10<sup>15</sup>)</td>
              <td align="left">2 * 10^-09</td> 10<sup>-09</sup></td>
              <td align="left">8 * 10^-29</td> 10<sup>-29</sup></td>
              <td align="left">5 * 10^-49</td> 10<sup>-49</sup></td>
            </tr>
            <tr>
              <td align="left">100 quadrillion (10^17)</td> (10<sup>17</sup>)</td>
              <td align="left">2 * 10^-05</td> 10<sup>-05</sup></td>
              <td align="left">8 * 10^-25</td> 10<sup>-25</sup></td>
              <td align="left">5 * 10^-45</td> 10<sup>-45</sup></td>
            </tr>
          </tbody>
        </table>
        <t>Next, to calculate the probability of a collision occurring in one year's
operation of a database, it is assumed that the database size is in
a steady state and that 10% of the database changes per year. For example,
a trillion record database would have 100 billion states per year. Each
of those states has the above calculated probability of a collision.</t>
        <t>This assumption is a worst-case scenario since it assumes that each
state of the database is completely independent from the previous state.
In reality reality, this is unlikely as state changes will be the addition or
deletion of a few records.</t>
        <t>The following tables table gives the time interval until there is a probability of
a collision collision, which is based on there being one tenth of the number of states per year
as the number of records in the database.</t>
        <artwork><![CDATA[
  t = 1 / ((k / 10) * p)

  t  Time p)]]></artwork>
	<t>For this calculation:</t>
	<dl newline="false" spacing="compact">
	  <dt>t:</dt> <dd>Time until a collision
  p  Collision collision</dd>
	  <dt>p:</dt> <dd>Collision probability for UEID size
  k  Database size
]]></artwork> size</dd>
	  <dt>k:</dt> <dd>Database size</dd>
	</dl>

        <table align="left" anchor="ueid-collision-probability">
          <name>UEID Collision Probability</name>
          <thead>
            <tr>
              <th align="left">Database Size</th>
              <th align="left">128-bit UEID</th>
              <th align="left">192-bit UEID</th>
              <th align="left">256-bit UEID</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">trillion (10^12)</td> (10<sup>12</sup>)</td>
              <td align="left">60,000 years</td>
              <td align="left">10^24 align="left">10<sup>24</sup> years</td>
              <td align="left">10^44 align="left">10<sup>44</sup> years</td>
            </tr>
            <tr>
              <td align="left">quadrillion (10^15)</td> (10<sup>15</sup>)</td>
              <td align="left">8 seconds</td>
              <td align="left">10^14 align="left">10<sup>14</sup> years</td>
              <td align="left">10^34 align="left">10<sup>34</sup> years</td>
            </tr>
            <tr>
              <td align="left">100 quadrillion (10^17)</td> (10<sup>17</sup>)</td>
              <td align="left">8 microseconds</td>
              <td align="left">10^11 align="left">10<sup>11</sup> years</td>
              <td align="left">10^31 align="left">10<sup>31</sup> years</td>
            </tr>
          </tbody>
        </table>
        <t>Clearly, 128 bits is enough for the near future future, thus the requirement
that type 0x01 UEIDs be a minimum of 128 bits.</t>
        <t>There is no requirement for 256 bits today as quadrillion-record databases
are not expected in the near future and because this time-to-collision
calculation is a very worst case. worst-case scenario.  A future update of the standard may
increase the requirement to 256 bits, so there is a requirement that
implementations be able to receive 256-bit UEIDs.</t>
      </section>
      <section anchor="no-use-of-uuid">
        <name>No Use of UUID</name>
        <t>A UEID is not a Universally Unique Identifier (UUID) <xref target="RFC9562"/> by conscious choice for the following reasons.</t>
        <t>UUIDs are limited to 128 bits bits, which may not be enough for some future
use cases.</t>
        <t>Today, cryptographic-quality random numbers are available from common computing platforms.
In particular, hardware randomness sources were introduced in CPUs between 2010 and 2015.
Operating systems and cryptographic libraries make use of this hardware.
Consequently, there is little need for protocols to construct random numbers from multiple sources on their own.</t>
        <t>Version 4 UUIDs do allow for the use of such cryptographic-quality
random numbers, but they do so by mapping into the overall UUID
structure of time and clock values. This structure is of no
value here yet adds complexity. It also slightly reduces the
number of actual bits with entropy.</t>
<t>The design of UUID accommodates the construction of a unique identifier by the combination of several identifiers that separately do not provide sufficient uniqueness.

<!--[rfced] Appendix B.2. How can "UEID takes the view" be reworded
to avoid personification? Also, it is not clear what "It" refers to
in the second sentence - is it also "UEID"? Please clarify.

Original:
   UEID takes the view that this construction is no longer needed, in
   particular because cryptographic-quality random number generators
   are readily available. It takes the view that hardware, software software,
   and/or manufacturing process processes implement UEID in a simple and
   direct way.
-->
UEID takes the view that this construction is no longer needed, in particular because cryptographic-quality random number generators are readily available.
It takes the view that hardware, software, and/or manufacturing processes implement UEID in a simple and direct way.</t>
        <t>Note also that that a type 2 UEID (EUI/MAC) is only 7 bytes compared to 16 for whereas a UUID.</t> UUID is 16.</t>
      </section>
    </section>
    <section anchor="eat-relation-to-ieee8021ar-secure-device-identity-devid">
      <name>EAT Relation to IEEE.802.1AR Secure Device Identity (DevID)</name>
      <t>This section describes several distinct ways in which an IEEE IDevID Initial Device Identifier (IDevID) <xref target="IEEE.802.1AR"/> relates to EAT, particularly to UEID and SUEID.</t>
      <t><xref target="IEEE.802.1AR"/> orients around the definition of an implementation called a "DevID Module." Module".
It describes how IDevIDs and LDevIDs are stored, protected protected, and accessed using a DevID Module.
A particular level of defense against attack that should be achieved to be a DevID is defined. defined here.
The intent is that IDevIDs and LDevIDs can be used with any network protocol or message format.
In these protocols and message formats formats, the DevID secret is used to sign a nonce or similar to prove the association of the DevID certificates with the device.</t>
      <t>By contrast, EAT standardizes a message format that is sent to a relying party, the very thing that is not defined in <xref target="IEEE.802.1AR"/>.
Nor does EAT give details on how keys, data data, and such are stored, protected protected, and accessed.
EAT is intended to work with a variety of different on-device implementations ranging from minimal protection of assets to the highest levels of asset protection.
It does not define any particular level of defense against attack, instead providing attack; instead, it provides a set of security considerations.</t>
      <t>EAT and DevID can be viewed as complimentary when used together or as competing to provide a device identity service.</t>
      <section anchor="devid-used-with-eat">
        <name>DevID Used With with EAT</name>
        <t>As just described, described above, EAT standardizes a message format and format, but <xref target="IEEE.802.1AR"/> does not.
Vice versa, EAT does not define a device implementation, but DevID does.</t>
        <t>Hence, EAT can be the message format that a DevID is used with.
The DevID secret becomes the attestation key used to sign EATs.
The EATs, and the DevID and its certificate chain become the endorsement sent to the verifier.</t>
        <t>In this case, the EAT and the DevID are likely to both provide a device identifier (e.g. (e.g., a serial number).
In the EAT EAT, it is the UEID (or SUEID). In the DevID (used as an endorsement), it is a device serial number included in the subject field of the DevID certificate.
It For this use, it is probably a good idea in this use for them the serial numbers to be the same serial number or for the UEID to be a hash of the DevID serial number.</t>
      </section>
      <section anchor="how-eat-provides-an-equivalent-secure-device-identity">
        <name>How EAT Provides an Equivalent Secure Device Identity</name>
        <t>The UEID, SUEID SUEID, and other claims like such as OEM ID are equivalent to the secure device identity that is put into the subject field of a DevID certificate.
These EAT claims can represent all the same fields and values that can be put in a DevID certificate subject.
EAT explicitly and carefully defines a variety of useful claims.</t>
        <t>EAT secures the conveyance of these claims by having them signed on the device by the attestation key when the EAT is generated.
EAT also signs the nonce that gives freshness at this time.
Since these claims are signed for every EAT generated, they can include things that vary over time like such as GPS location.</t>
        <t>DevID secures the device identity fields by having them when they are signed by the manufacturer of the device into a certificate.
That certificate is created once during the manufacturing of the device and never changes changes, so the fields cannot change.</t>
        <t>So in one case case, the signing of the identity happens on the device device, and in the other case, it happens in a manufacturing facility,
but facility. However, in both cases cases, the signing of the nonce that proves the binding to the actual device happens on the device.</t>
        <t>While EAT does not specify how the signing keys, signature process process, and storage of the identity values should be secured against attack,
an EAT implementation may have equal defenses against attack.
One reason EAT uses CBOR is because it is simple enough that a basic EAT implementation can be constructed entirely in hardware.
This allows EAT to be implemented with the strongest defenses possible.</t>
      </section>
      <section anchor="an-x509-format-eat">
        <name>An X.509 Format EAT</name>
        <t>It is possible to define a way to encode EAT claims in an X.509 certificate.
For example, the EAT claims might be mapped to X.509 v3 extensions.
It is even possible to stuff a whole CBOR-encoded unsigned EAT token into a an X.509 certificate.</t>
        <t>If that X.509 certificate is an IDevID or LDevID, this it becomes another way to use EAT and DevID together.</t>
        <t>Note that the DevID must still be used with an authentication protocol that has a nonce or equivalent.
The EAT here is not being used as the protocol to interact with the relying party.</t>
      </section>
      <section anchor="device-identifier-permanence">
        <name>Device Identifier Permanence</name>
        <t>In terms of permanence, an IDevID is similar to a UEID in that they do not change over the life of the device.
They cease to exist only when the device is destroyed.</t>
        <t>An SUEID is similar to an LDevID.
They change on device life-cycle events.</t>
        <t><xref target="IEEE.802.1AR"/> describes much of this permanence as resistant to attacks that seek to change the ID.
IDevID permanence can be described this way because <xref target="IEEE.802.1AR"/> is oriented around the definition of an implementation with a particular level of defense against attack.</t>
<t>EAT is not defined around a particular implementation and must work on a range of devices that have a range of defenses against attack.

<!--[rfced] Appendix C.4. We are having trouble parsing the first
sentence below. Please let us know how we may update for clarity.

Original:
   EAT thus cannot be defined permanence in terms of defense against
   attack. EAT's definition of permanence is in terms of operations and
   device lifecycle.</t> lifecycle.

Perhaps:
   Thus, EAT's permanence cannot be defined in terms of defense against
   attack; it can be defined in terms of operations and device life cycle.
-->

EAT thus cannot be defined permanence in terms of defense against attack.
EAT's definition of permanence is in terms of operations and device life cycle.</t>
      </section>
    </section>
    <section anchor="CDDL_for_CWT">
      <name>CDDL for CWT and JWT</name>
      <t><xref target="RFC8392"/> was published before CDDL was available and thus is specified in prose, not CDDL.
Following is
In the following example, CDDL specifying specifies CWT as it is needed to complete this specification.
This CDDL also covers the Claims-Set for JWT.</t>
      <t>Note that <xref target="iat-claim"/> requires that the iat "iat" claim be the type ~time-int (<xref target="common-types"/>), not the type ~time when it is used in an EAT as floating-point values are not allowed for the "iat" claim in EAT.</t>
      <t>The COSE-related types in this CDDL are defined in <xref target="RFC9052"/>.</t>
      <t>This however
      <t>This, however, is NOT a normative or standard definition of CWT or JWT in CDDL.
The prose in CWT and JWT remain remains the normative definition.</t>

      <sourcecode type="CDDL"><![CDATA[
; This is replicated from draft-ietf-rats-uccs draft-ietf-rats-uccs.

Claims-Set = {
    * $$Claims-Set-Claims
    * Claim-Label .feature "extended-claims-label" => any
}
Claim-Label = int / text
string-or-uri = text

$$Claims-Set-Claims //= ( iss-claim-label => string-or-uri  )
$$Claims-Set-Claims //= ( sub-claim-label => string-or-uri  )
$$Claims-Set-Claims //= ( aud-claim-label => string-or-uri  )
$$Claims-Set-Claims //= ( exp-claim-label => ~time )
$$Claims-Set-Claims //= ( nbf-claim-label => ~time )
$$Claims-Set-Claims //= ( iat-claim-label => ~time )
$$Claims-Set-Claims //= ( cti-claim-label => bytes )

iss-claim-label = JC<"iss", 1>
sub-claim-label = JC<"sub", 2>
aud-claim-label = JC<"aud", 3>
exp-claim-label = JC<"exp", 4>
nbf-claim-label = JC<"nbf", 5>
iat-claim-label = JC<"iat", 6>
cti-claim-label = CBOR-ONLY<7>  ; jti in JWT: different name and text

JSON-ONLY<J> = J .feature "json"
CBOR-ONLY<C> = C .feature "cbor"

JC<J,C> = JSON-ONLY<J> / CBOR-ONLY<C>

; Same as JC<> but with unwound generic nesting as it seems to cause
; problems. Perhaps this is the nesting problem described in RFC
; 8610.
JC-NEST-SAFE<J,C> = J .feature "json" / C .feature "cbor"
]]></sourcecode> "cbor"]]></sourcecode>

      <sourcecode type="CDDL"><![CDATA[
; A JWT message is either a JWS JSON Web Signature (JWS) or JWE a JSON Web
; Encryption (JWE) in compact serialization form
; with the payload
; as a Claims-Set. Compact serialization is the
; protected headers, payload
; payload, and signature, signature that are each b64url encoded b64url-encoded and
; separated
; by a ".". This CDDL simply matches the top-level syntax of of
; a JWS
; or JWE since as it is not possible to do more in CDDL.

JWT-Message =
   text .regexp "[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+"

; Note that the payload of a JWT is defined in claims-set.cddl. That
; definition is common to CBOR and JSON.
]]></sourcecode> JSON.]]></sourcecode>

      <sourcecode type="CDDL"><![CDATA[
; This is some CDDL describing a CWT at the top level level. This is
; not normative. RFC 8392 is the normative definition of CWT.

CWT-Messages = CWT-Tagged-Message / CWT-Untagged-Message

; The payload of the COSE_Message is always a Claims-Set Claims-Set.

; The contents of a CWT Tag tag must always be a COSE tag tag.
CWT-Tagged-Message = #6.61(COSE_Tagged_Message)

; An untagged CWT may be a COSE tag or not not.
CWT-Untagged-Message = COSE_Messages
]]></sourcecode> COSE_Messages]]></sourcecode>

    </section>
    <section anchor="Claim_Characteristics">
      <name>New Claim Design Considerations</name>
      <t>The following are design considerations that may be helpful to take into account when creating new EAT claims.
It This is the product of discussion in the working group.</t> RAT Working Group.</t>

      <t>EAT reuses the CWT and JWT claims registries.
There is no registry exclusively for EAT claims.
This is not an update to the expert review criteria for the JWT and CWT claims registries as that would be an overreach for this document.</t>
      <section anchor="interoperability-and-relying-party-orientation">
        <name>Interoperability and Relying Party Orientation</name>
        <t>It is a broad goal that EATs can be processed by relying parties in a general way regardless of the type, manufacturer manufacturer, or technology of the device from which they originate. It is a goal that there be general-purpose verification implementations that can verify tokens for large numbers of use cases with special cases and configurations for different device types. This is a goal of interoperability of the semantics of claims themselves, not just of the signing, encoding encoding, and serialization formats.</t>
        <t>This is a lofty goal and difficult to achieve broadly requiring as it requires careful definition of claims in a technology-neutral way.
Sometimes it will be difficult to design a claim that can represent the semantics of data from very different device types.
However, the goal remains even when difficult.</t>
      </section>
      <section anchor="operating-system-and-technology-neutral">
        <name>Operating System and Technology Neutral</name>
        <t>Claims should be defined such that they are not specific to an operating system.
They should be applicable to multiple large high-level operating systems from different vendors.
They should also be applicable vendors as well as
 to multiple small embedded operating systems from multiple vendors and everything in between.</t>
        <t>Claims should not be defined such that they are specific to a software environment or programming language.</t>
        <t>Claims should not be defined such that they are specific to a chip or particular hardware.
For example, they should not just be the contents of some HW status register as it is unlikely that the same HW status register with the same bits exists on a chip of a different manufacturer.</t>
        <t>The boot and debug state claims in this document are an example of a claim that has been defined in this neutral way.</t>
      </section>
      <section anchor="security-level-neutral">
        <name>Security Level Neutral</name>
        <t>Many use cases will have EATs generated by some of the most secure hardware and software that exists. Secure Elements and smart cards are examples of this.

<!--[rfced] Appendix E.3. May we rephrase this text for clarity?
Please let us know if this conveys the intended meaning.

Original:
   However, EAT is intended for use in low-security use cases
   the same as high-security use case.

Perhaps:
   However, EAT is intended for use in both low-security and
   high-security use cases.
-->

However, EAT is intended for use in low-security use cases the same as high-security use case.
For example, an app on a mobile device may generate EATs on its own.</t>
        <t>Claims should be defined and registered based on the basis of whether they are useful and interoperable, not based on security level.
In particular, there should be no exclusion of claims because they are just used only used in low-security environments.</t>
      </section>
      <section anchor="reuse-of-extant-data-formats">
        <name>Reuse of Extant Data Formats</name>
        <t>Where possible, claims should use already standardized data items, identifiers identifiers, and formats. formats that are already standardized. This takes advantage of the expertise put into creating those formats and improves interoperability.</t>
        <t>Often
        <t>Often, extant claims will not be defined in an encoding or serialization format used by EAT.
It is preferred to define a CBOR and JSON encoding for them so that EAT implementations do not require a plethora of encoders and decoders for serialization formats.</t>
        <t>In some cases, it may be better to use the encoding and serialization as is.
For example, signed X.509 certificates and CRLs Certificate Revocation Lists (CRLs) can be carried as-is as is in a byte string.
This retains interoperability with the extensive infrastructure for creating and processing X.509 certificates and CRLs.</t>
      </section>
      <section anchor="proprietary-claims">
        <name>Proprietary Claims</name>
        <t>It is not always possible or convenient to achieve the above goals, so the definition and use of proprietary claims is an option.</t>
        <t>For example, a device manufacturer may generate a token with proprietary claims intended only for verification by a service offered by that device manufacturer.
This is a supported use case.</t>
        <t>In many cases cases, proprietary claims will be the easiest and most obvious way to proceed, however proceed; however, for better interoperability, use of general standardized claims is preferred.</t>
      </section>
    </section>
    <section anchor="keyid">
      <name>Endorsements and Verification Keys</name>
      <t>The verifier must possess the correct key when it performs the cryptographic part of an EAT verification (e.g., verifying the COSE/JOSE signature).
This section describes several ways to identify the verification key.
There is not one standard method.</t>
      <t>The verification key itself may be a public key, a symmetric key key, or something complicated in the case of a scheme like such as Direct Anonymous Attestation (DAA).</t>
      <t>RATS Architecture <xref target="RFC9334"/> describes what is called an endorsement.
This is an input to the verifier that is usually the basis of the trust placed in an EAT and the attester that generated it.
It may contain the public key for verification of the signature on the EAT.
It EAT, and
it may contain implied claims, i.e., those that are passed on to the relying party in attestation results.</t>
      <t>There is not yet any standard format(s) for an endorsement.
One format that may be used for an endorsement is an X.509 certificate.
Endorsement data like such as reference values and implied claims can be carried in X.509 v3 extensions.
In this use, the public key in the X.509 certificate becomes the verification key, so identification of the endorsement is also identification of the verification key.</t>
      <t>The verification key identification and establishment of trust in the EAT and the attester may also be by some other means than an endorsement.</t>
      <t>For the components (attester, verifier, relying party,...) party, etc.) of a particular end-to-end attestation system to reliably interoperate, its definition should specify how the verification key is identified.
      Usually, this will be in the profile document for a particular attestation system.</t>

      <t>See also the security consideration considerations in <xref target="verfication-key-sc"/>.</t>
      <section anchor="identification-methods">
        <name>Identification Methods</name>
        <t>Following is a list of possible methods of key identification. A specific attestation system may employ any one of these or one not listed here.</t>
        <t>The following assumes endorsements are X.509 certificates or equivalent and thus does not mention or define any identifier for endorsements in other formats. If such an endorsement format is created, new identifiers for them will also need to be created.</t>
        <section anchor="cosejws-key-id">
          <name>COSE/JWS Key ID</name>
          <t>The COSE standard header parameter for Key ID (kid) may be used. See used; see <xref target="RFC9052"/> and <xref target="RFC7515"/></t> target="RFC7515"/>.</t>
          <t>COSE leaves the semantics of the key ID open-ended.
It could be a record locator in a database, a hash of a public key, an input to a Key Derivation Function (KDF), an Authority Key Identifier (AKI) for an X.509 certificate certificate, or other.
The profile document should specify what the key ID's semantics are.</t>
        </section>
        <section anchor="jws-and-cose-x509-header-parameters">
          <name>JWS and COSE X.509 Header Parameters</name>
          <t>COSE X.509 <xref target="RFC9360"/> and JSON Web Signature <xref target="RFC7515"/> define several header parameters (x5t, x5u,...) for referencing or carrying X.509 certificates certificates, any of which may be used.</t>
          <t>The X.509 certificate may be an endorsement and thus carrying additional input to the verifier. It may be just an X.509 certificate, not an endorsement. The same header parameters are used in both cases. It cases, and it is up to the attestation system design and the verifier to determine which.</t>
        </section>
        <section anchor="cbor-certificate-cose-header-parameters">
          <name>CBOR Certificate COSE Header Parameters</name>
          <t>Compressed X.509 and CBOR Native certificates are defined by CBOR Certificates <xref target="I-D.ietf-cose-cbor-encoded-cert"/>. These are semantically compatible with X.509 and therefore can be used as an equivalent to X.509 as described above.</t>
          <t>These are identified by their own header parameters (c5t, c5u,...).</t> c5u, etc.).</t>
        </section>
        <section anchor="claim-based-key-identification">
          <name>Claim-Based Key Identification</name>
          <t>For some attestation systems, a claim may be re-used reused as a key identifier. For example, the UEID uniquely identifies the entity and therefore can work well as a key identifier or endorsement identifier.</t>
          <t>This has the
          <t>An advantage of this is that key identification requires no additional bytes in the EAT and makes the EAT smaller.</t>
          <t>This has the
          <t>A disadvantage of this is that the unverified EAT must be substantially decoded to obtain the identifier since the identifier is in the COSE/JOSE payload, not in the headers.</t>
        </section>
      </section>
    </section>
    <section anchor="changes-from-previous-drafts">
      <name>Changes from Previous Drafts</name>
      <t><cref anchor="remove">RFC editor: please remove this paragraph.</cref></t>
<!-- [note] ST is not updating this with every version change-->
      <t>The following is a list of known changes since the immediately previous drafts.  This list is
non-authoritative.  It is meant to help reviewers see the significant
differences. A comprehensive history is available via the IETF Datatracker's record for this document.</t>
      <section anchor="from-draft-ietf-rats-eat-29">
        <name>From draft-ietf-rats-eat-29</name>
        <ul spacing="normal">
          <li>
            <t>Address IANA comments on intuse registry</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
      <name>Contributors</name>
      <t>Many thanks to the following contributors for their contributions to earlier draft versions of this
document:</t>
      <contact initials="H." surname="Birkholz" fullname="Henk Birkholz">
        <organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
        <address>
          <email>henk.birkholz@sit.fraunhofer.de</email>
        </address>
      </contact>
      <contact initials="T." surname="Fossati" fullname="Thomas Fossati">
        <organization>Arm Limited</organization>
        <address>
          <email>thomas.fossati@arm.com</email>
        </address>
      </contact>
      <contact initials="M." surname="Ballesteros" fullname="Miguel Ballesteros">
        <organization/>
        <address>
      </address>
      </contact>
      <contact initials="M." surname="Richardson" fullname="Michael Richardson">
        <organization>Sandelman Software Works</organization>
        <address>
          <email>mcr+ietf@sandelman.ca</email>
        </address>
      </contact>
      <contact initials="P." surname="Uiterwijk" fullname="Patrick Uiterwijk">
        <organization/>
        <address>
      </address>
      </contact>
      <contact initials="M." surname="Brossard" fullname="Mathias Brossard">
        <organization/>
        <address>
      </address>
      </contact>
      <contact initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
        <organization>Arm Limited</organization>
        <address>
          <email>hannes.tschofenig@arm.com</email>
        </address>
      </contact>
      <contact initials="P." surname="Crowley" fullname="Paul Crowley">
        <organization/>
        <address>
      </address>
      </contact>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA+y923bb2JUo+s6vwFFljJISkrraZat3VaKSZEfVvrUlp7p3
7TpukARJxCTBBkDLiuL+lv0t58vOvK+5AFB2ku7zcMb26E6JwMK6zjXvl8Fg
0Pt4mhz3enVeL7LT5GaeJZcr+HGXnNV1VtVpnRer5Kb4kK2S3cuzm71eOhqV
GXwEP3qTYrxKl/DdpEyn9SDP6umgTOtqkKX14Ohpb5zWp0lVT3q9cbGqslW1
qU6Tutxkvaous3R5mlxd3jzr5euSHlf10cHB04OjXgovT5PrbLwpYSq929lp
8vbs5rr34Ra6y2erfDVLUje/8agoe711ftpLkroYnybf3mXVt/xjkq3rOTw5
wd9VUcLA0yq0qO6W8YNxsVyn49q12IzCs1WBj8rpOJtU9R1uGTeDf+mmnhfl
aW+Q5Cvo78UwebFZTUaLdJLBJ7xPL9JNma3GWfSqKGdhsXgERXmXvHhxDq+y
ZZovTpPFbPGHShrU9H4IU9KRng+Tl+lqcpcubZzneZlP5mnpXtAoL7NJntbZ
h+Td9Vnofiath0tu/YcZPvdD/DRMXn97UayK2XwTVvNTVmbLu/gNDfMvm3QB
Xy+Tm2w8XxWLYpZnVXK1Gg9xP+EEMtjLo++eJs/ScgVnV2xm8+RtkU5w/2GN
p/4FnckEF/Xu8CT57sU1Pdis6hLavVvldTZJ/hkgYlLgMtfzYgVtf3dykhwe
PTpKjh8fHz55Gtb652JCk/3Df9T58D9knn6p58Pk53SxSMdhnedpuXAPaYlv
YdQ/wiwmyXUxrW8BYvu6QBlpDF/9ocwmc2xVSSMaCW9DXeajTc3wwqP8MVt9
SH7Myw/zYvEXHeZZmW5W82Kalcn11Q081evXeiGjzqGX4Uh6+UOV18OptRwC
uOloN/NimVbJs6Kq4A7pcGflMnmRL3FPQ5c1NR1Ouekf0lL3i3t6mc822SL5
EfYHLmRWFpV7NZ6n8O4t/reETVgZuAOkZQuAN9u+5Oei/FCFUZfj8neIUP5Q
adPhOLWe36SwgWOAY5hqeZv/+UMYM63nOazsxxLnW07C/qarFUDhTTXGzVjl
swcXPafWw9pat9b9Jt0skvOyuF1kd73eqiiXsDsfM8RBb5+df/fo8JH8+eTp
ydNTxlH8CuAytHqqrY4e2Z/HT7XBk8eHB/DtZLKQ39/Zq+OnTx7Ln08PrMen
gED1z8PHj/jb9WJT8bOTxydP5PXJo8PvtOXx02P78/jktAd///z8+skJPgQs
mpYzvLE787peV6f7+1la1vNBvpoWw9UsHS7zxf56vt6fFLerBdziIfz4/TRf
ZN+Pi6KcDG5n1ZOTHe6K6czPr9++uEieX76+uLy5Ok+u/+365vJlcvj0yUk/
efX8bHh98+pieHBw/Pj94fBgePCeJkMdKJbFvwd8fq+ICKSL5HlWVGv4kS4G
V6s6WyzyGSHbM/zPXbILPe/RhxPAgYCADg5PBgffDQ6e4Hqvzl6dDc9/vhme
L9J8CYiAHoxva3v5U/Pln93L89fXl8OzxawAHD0PnxdVhk1u5oDznr95M7x6
eXkVb6ru6RpIU7oYHs/W6yEsa3+SVR/qYr0sJhu4V/vX62ycT/MxrbXx8yKr
AWarYVqtP/2+8m+uJt9/d/TU7/xxOYF9WmUlU843cJLwo5rn6+RNWfw5G9f/
xFgbelgk0TDJc8DH6+S8gMv6Kqtv4b4mcDehebnMYf+rf0pebZajrARk3E/S
yaTMqopINTTKJxnwFdrVtqM8hj2KT+gpbt/Fi9dn3bs2WxSjFOA7radwAWnj
btcDxK8w3P5mjeBY7UM/j/YPj/afvzl/f5HPctjoFxnwD+Xr6dl6XRYf08X7
jwhp68nUb5a0TbhxUkwTbe4m+ar4mOGqcbaPejjdN5evtpxxthrm6SqlecKP
/TfZCnpcyK4M1+ks8+O/KfOPMAayZFm5LvMqkx1OdmGMPSBC/7EBnGtAiDhm
UKezCm5wD69njJOeHB4Zxnj0WDHGCaInRR7HT+nyAxmq55P0DpjAdPzh1M9J
XyEDBu861wnLvM0/5GvkNvhM4Ne+fvmevxy6PZwC9NBFubq8vBw+OTgaHp69
hf1/fTU8PBgeHh483cc31zcXQ9jlJ8MnJ0fH3z09ITx1fD6Ei/8C2T78++3l
+WCWAc/Bezo4e3M1gG+ODw+OqP3rd1fD5xsAx2hV9GSRI4GAXUvewU7DaV9+
AjCaAKUHNgN2OrkSIMYDuHx3tddPXpezdJX/RTDQ4q6r5WtqiZfgHPnI1V1y
dZHsnl9deGR0tpkB/4sw9F3nlgKru5ogDR3mWZbRpiqUT9LlPj4cWJvQev82
GwFeHm+W0LLar5HlAPxY7WebnKBdduRFUXzYrKMtwQ0HCJvlwLDx/T+jC0vC
QYVsOPXZOdsym+HtHnbM2h6BpDDA2a03o/2PeXY7nNfLxTclDwj84jbwGLw9
+9p5fu1Owp2ebMYgt1RZ+TEfA7qVBezncPyfaGYPQSsA2MHhVnA9GT5+cvLd
wdPv8BOiE//66ODp8AJlJpj+4GJIghPSisEneEPNfnz9dnielXV3M7roQNSA
L54MxtAMv3l3fn7tGpIgthmPK3z3083Z8/auXctWEMwDR7sBsWbwJl8RsF6u
gAfCB882qzHDN8kngHCSszFsUpW8AZpFbX9EHjct7wbXY2DpzsrxHLipcQ3C
TucR4MZ/AtwM/LCdgQLp/qOTw6Mnjx+7/X6WjcoN9I634wBXA7LncInIZVDf
rbOquWiUPsNr2s7zweWndLleyK3XXSCpK0uuN6PB9R0wr0uQARL+awC44xzJ
4u7xNT0tzveQROK6iHKWBbI40l1jgShUFKtxidxpngppx1WuptX+eLzGL6t9
/t/1Wv97cHj43Z+ORu/hXholaoLc8zfdK3lOhPCNEMIgeMGBwUEjJAU6DlPH
4+ue+tdS1KPD/YNDoKjvof+oe+n9/ccjYNzebEZA3d5miyytsi2LGgwGINbg
7R0DHJ+tvqCBSJACA7auAPJECwAYekyMWVJlda+ep3UC72H7R9AKu8gISlEI
gTHgSKo6H1eI4aGLjEbr91L4Bi9/ssg/QPukWgJvROIkSHbFjbztJythfYD2
5muEWGBdkmozng97N/O8cjNJ4NemgsmNgFomZba4Q25oDd3e9RNENchTlIkg
naQuYIyamCn4MYf/B+iliU+yGfCPOF/SkiRrlEQnCJXYjBcw5K07u8FRM2BC
ofOU8EjyczbSDQQGdw/H/On69Sv//Cd8fgtfeb3KAJAodA5iEa9pyGe1zEGk
gHP7BgTemjEnsnRfcXIwszRZAnAAn5Ms00mWAD8Jq5ItS0fFpg5HMsQe+U9o
fJeM8FT0FKpimSUoVJLsiLuID0zM7qEmS7uFBptFnQMvBEew7USS2znu/5gg
K5/Svs+L2ySvYV8WC9hsOBqAHt4lv+84VNwVzhbkRsDUeKh0ZgA3RS3HB7PF
djkxDPzI9/cM3md8x/vaUJrpNiwWxS1x1gmgGeD+S+wnXVUp46Zihetc4+Ap
gDOItnB0OE1VIsFnwO7QGmcF9I743yvUaMuYk8E2+JOmj12A8JukzCYVBGXW
qVFWvkJAhGEDpgLhCI5AUXGRjCf6eBLNhzQcdQiHxJAC64Q9LpIZMLIEHLw1
CDewdpgKyCg13Q2Y3SSfTjNSsfUT1DnCaZb0Iq2qYpyHMRb5FMjo3Zg7+pDh
oRGyXvABNOcKLRiStCOYH98XXoa7x7yEGg8AwYyOpErWWYkIVWFPP4IFFWuU
xgqSL1LtRWYRzqRPy9g6DRX75IJUdm6wC9N8RvsJAwuKW6arzTQlAl1WCsEp
7hVe0ara4DwBegDWpimI93laBrhHiKnCQQVwakFRZWiYkBXqcCPmILm/F5XD
588RoJXZOqO1AXxlBLswL+UQoNMpcep05ZnU6l0n3I+9rAukV3zFYF9HJZAt
3PRhD1EkCKe5sex0myokKyBi8WVSzLFi1mi6KQnSdRDaGIX2/C/ZZNj7Y4aH
UmY8KYFRlMN+m7xMPzBQ8C7BbNz2TwhMYV2lnE3nBymgE2BFEHEwdS1KQQ3j
zSItYRG093YghrnpO+jyKhK/uXMgyTABpmB8exR9JuVmRUp2bBrmdS6g5G4q
0VaaoLW6XH3My4KEA8AsXTQ3IrR5XQnzAuxkRaeCI1/fITe2+/zN9V6ishx0
/gxFWujVMxwVgMs4A+ww6fWE/uGeAsYc1wzG1Wa9JlYVgBiIDmDKGc0a4CEZ
A2OClO0VNIOBFxnd3UCUkKFNxwRlE2IkgBbYd7BjSceQKdK5aQmYkjgFPBuC
WVyYXVR/U2okkoxT7b2b3NXKHXafRgxMEP6JHCQcKGz2Kq+WAqDpaEH0B3Ac
gQj3fEcnLYtbZRlIEIxaxuXdui5mZbqe4+xMlcV3qpoXm8UEu0X6yeIso//m
CTMkhvny4ugDXdKwd38vs67g5gdeTZci7CbfwI6l0pRg06tNXtMycVA+gRRQ
w0QhzB/wjZHYbys+NLyiBKZ0BjPWimWV3yAcH9gwVIbhDoLQS6+XgvtX0SkC
coazoomVWbVG8qNzW4vgAABA1Kj51TVijfakKuY9aBnFEnqkTaGxgaDeJfN8
NsexckRGzEKycoXv1g0yDbAbJha8ZG0iIhIRfS55NNig13iaFbEYyM0AaC/w
PzDDiiYVsAPAMkAr3xpYBiGKqcIwMdrGAldEUML1mchJwVrgrmdGrehA5ylQ
+CWyajTcZlSRJFYF1lb4H5F8kaYIp/tT+jG9BiBa18nrEWoxk1eF7O8u8rp7
TGpQyQ4AB1MAXDZGfdqP+QoRvnz0NlvDbhpI7CL7rJ8+PcFPU700tJAsHc8d
VAsqGG3yRY0b18l9c2/HT4+E5nWy4tQIrQPSKF/BKhFVIvqBFefte0egSm8C
WVaMAFv4AgECJsBj/nzDaGRSwOYjxcUjBlK4ujP+fApUEXb+WaHMJnHvBHYC
EELlFOZpIaxzlM2p7oitIH3wCFj7MeEQ4B4IP5GOo/caeVW8E6xaH1xnNeOj
dXqHsiZ1hb9pznjngStfwcT+E/717kme3AFm4f0KTjTbOU12Xl5d/Pjqj0dP
8rzIqz+/udvpc6NNlk/gPf3bOZudXeZ/Kf/5+F/0dZEt7f13jx+dHPcTflHd
osGH3+ycjeGiojj4+lo/rG5hUyqAFxz8eHg4PNnpfebpMeOiHOuc6ALNk9kK
gLU5MDKVSI78JmcENAKIenyyKRcM7XLJ0uTwCPi4mojYpFgmI4ZfeoR6M2KW
4XNcLEmCwA+PUQeMp4vMJQoTK1YiM4cPL0Q5f6foiW+lzEp7emhSJ08GIxCU
Xp6dq94fMB4Q5QlznSbM0jQPPh0c8SRpy800IJjX86Zwt1jM2a4Jv79/c/nq
82fu0FAUzNe6FY5bsRhtEtnw6CrI2REQj5XGNb+dbuDawcRAaEBRDmG5xr1h
gRYIOzIldh1ANP5GReHXH5Gfz26bPOymkuWiwA8ATK13EIGXGRp1UW7Et6Sd
EU0Fqr16L4vK+DXBs8wPiz7AD0L8/xdla4SS/9jA/i7wG5IZZdgssHIJaQVV
31Iyb2/D/iJs/K+w+BfpXYZ8bSQJIFFoIv1+S0CwbvrMSjPbZge4GbE1zHE6
u1WGUgS/Al5iD0ipNquYswd8bTQKdpARpfF3AyJSVSFczgbw+TwHPgCllIy5
P4AHYsSRzY+3zcvDKSACViEapd7pN7YJ26NlsgSZPXh8APeLluo7RvonRGeI
Ia2F0XHPTfYJIIPL0aHtGSzpDtDJ3bLqC2FISXx3mhSQOivUFaAYGowYdM4i
HTEfyRewuTZiSnE9SEWIXfsEF8MmtcpQ4CdQrhikuofja2t6HJIp9A4zk6f8
EDLvQCQJgNq6M11VOJ0wO3Q8yvTSZvFqaQwWwBEgl8A91vD/xCHN4abxGdvA
ORNLd42Yc1N5D+GK3uQi+501+Cx6pGzZ5Sd4R9NwMlOye3N5uUftVNM4RhU9
nktSwiXOSnrJf/ZxX+fpWphC4kean+EKuLW/RNjJKkAjTBwQ1GpWJbtA3faC
OHeGIDHJgQPfAI4T8ZOfp+s1S4hBVUpTCz95VktkK6pwLZH2IS+jz4XN42/1
Jy/YdSU6Jb6My0S4gjFcvzLtNVSFxEkCpi9Q4NJ7pmxrks7wiOsAdvnqY1qR
eomY54qIAfZDrAp1hohEe+rjIyIiBQtVsDGtUQiySwEZphGbZWhWIsoV6VvE
NQdUREBQT4F45ZkKkibebhUuv1qmZHVkGt6wkMYd8cX8eY6SlrK0KWpNHSaH
MVC2ofONuEpgA0hkFiYv4PdUbsSq4QugMlamOIYkBKZa+cqjafj6wiZId02U
P106a/kQ1RYtKnl+cfFCFFjID6EGRzgN4thFPw6fGo4GSpgtAE+4naCmIjdc
q1Mi2c1Ikmb54fX15R7vDQgoVSSgbPvmJ/wGxnailZenaLf4aIlZEIGFDmWR
fQqkdrNSMZhvVltNEEDjruGmcRdpKh6EJAZKY2eQr9oHVmKDDHxexjTSAQpO
XgfzCEYtDff38CH/cFTvy+cdNIBAxVj7Q8KFGxldJZJgZwZWqOqA41Xh7Qfo
GYk62jsv37KmclzAOSIEBRUJnGxRErvwboVoS6WfB64NCWO6Su5eIFIE1Yu0
Th34Jy/S1WyDctouQrOKlY8PD5B5ANq8RD6RlVR2BAT34Y6bfQpPdlSIehfh
eh/nppfD3VIUw+Bm7P/UfI18X6eASYCB14Af4x9wJKLSCVp2wqpoYpnRdSMW
bW0aWtJhT1ifSwiSNGBoBCPkuspuUQmCHoGCGVZbtVl9aIkUngCeZelG2ync
onyUk7Eb7t45rgQX0Cfg0VUMGe71yNCslcodUX5zi0IEuSGnT/wbdSGsutXn
yo4jteHR2BjQRlt4wk4coJmoNgXkqImoU4gIjYEhtQUwh7ZiK2tQ5bHBKmoJ
cgddCZo6rBJRhIGeyYu72XA27KNp8mevz4GOZAa4zXuyvXCHGXxTORC2kSKX
08SJgAQnrJqrsnVasq1vWoKI7NTiuh8Tgk3aaORdieNLk0k+y4JwxeNEpuWW
JYKxCPK4SOPR5SBhRWRNdB2dE0x/0aB6MgoRPpZM+sQUxbcuiNll+1T5aNx9
xn0ovScMdywz4+kg+8AiOu/3/X3Dm4KEj2c53TzWxMChSmcshBopQQlYTMCZ
yBggueNJBT1qmdlUVmlZFreknY2oOEll3dQFZzglDdSgWNm+o7ZyRdoIaKuT
6VYBV8yAiSPc4k7ZAGGyXhPrjxv80iyiLTMVwyJPg1fFEgN7nbKRJpJjn5HB
LTn8otGLDJvVZglcLpCQfiRhB310hriSVEPMzJMql61CwddAJoBL+Qi9FZvq
QX8HwKHWK1KBjSm4VdxGmygdKSJrOc0g/isKsE6oHQKC2CcVs0emeJyoaGxz
uPMb1uqr+UYUYEXJVIMsaWxjYOSKmLNCm5XXnPXOUIXDrnZEJ0pCksq4AiuS
04KokWm4cKEpnQbh0xTf12JQ9NSXJFhaIPE0Yiu1AXGNbt2O+4YJApIGcnML
NGUehIlRFng2sRSJYuemYReQHtiayfTS2JmGLwmPIQoJdXUIhkVBNW+zJaoU
vHMG+epMNuowEXsxGE/XOatID46IS+9sEEmDm4IJZ0z8UD+Yqpza9+4McDfT
1ZgdHpw/gzrYAF/DZ8QyTO3PgpGfX4BakycI/6txbaL5EO/+N7AhC7ayoG11
BLPJ4DTtWmB/fq/eysrvvyndd59R9BSD8XZFHG6RqH+Q+UTSh0IG/EfQtell
NoKW7WI1bOqy/8NEzissIMgJ+arzyGDvM3fnp+iyx1ZauPkzuOPlKqhro231
D76tknWxyMfkcKQMuZ499Sv0LuoBAYQ/I/aPfSEAQWUgbffh0wWaCpkgiMlv
LM7jrNewQ2GIzFfrTS2MJN49UmwgFr2T1W7dA9IpgbgxNgqFC0dOcJ6lC7Lp
sVl7U+m96fTLcdbzKjovOUdi9ku+sU0kIleYZwSD8PUlu3sDNajSeg14b3+a
5ost64KzYBsM4RjgJ9nyyDpNh9RUK6aTJeviiCjKbVribd6sgJ6x5rsL12wd
n/gi6UaMRcC0kqAr/TgAalhe6cQFptpoKIhVKft6TbvhEcf5sCpuYTuRrSPQ
QrKEVpfgfBNcRfJa56vWYYNYPEPahruOxn02bikgoBzrdJRrNFTAZOgcy4+8
wKn3oB0m3UflxqdjQQiPj20rQJNr1ISjQETTHwBXYJ43AsFyg9AFS1gUwLVP
0E2J2G6QRtIRmTEjQK+bG+M8C9ZsUhDTmSDBByYLuEVOgrE9zoDcpEy7JFY6
6UpkhchqtYdLMY7B3TxlzqMAmGDgxMmMFnk1JyOncYRJaSrJaKWwOmb4+oJz
KnbvSdFPTIJB0C9lYZDLp8ped6SHjcEYBaLVBESFWjGqQ3I8CVQe44d+EgTR
6IeIcMbGr6x+GNETaytROeQCzNCN/BzQWxCodl6+u77Z6fN/k1ev6e+3l//y
7urt5QX+ff3Hsxcv7I+etLj+4+t3Ly7CX+HL89cvX16+uuCP4WkSPertvDz7
tx22Q+y8fnNz9frV2YudbmsVq0JtoYQGexFv/eP5m//nfx+eABf9fwEbfXRI
JnL+8eTwO3QkuwWmTBxU0LbMP9H20UvX6ywlUowIf5yuMbqH7VBkVVZ3s9/+
gjvz62nyP0bj9eHJD/IAFxw91D2LHtKetZ+0PuZN7HjUMYztZvS8sdPxfM/+
Lfqt++4e9tiE446Abzu7MW0Y1SJWSMKtcvrT+/sBxhbS7g80ypCER/K0UYsI
iZj6Cxojq0CqUxA4Z6sCJRO8n3JbAwN1f38tnvZPcB4U8iDOEPf3Z3CQQMQ/
Jc/5Hc2jQzpnFjbcBFYIIN/VdLA412fsmXHa65mtWwMtTnunSeshO0zG4p/2
/ejzZ5Dph9mwL9LEu7cvBuxUCAIrakoHVTrNgpxG8hFb+x6fPEFQJi+jBXHD
IFZDF99+/21oDyhjmdd0S1bsB6qon6SryqT2uwRjm5IRCOMfWCYBrLFO0UvW
3HiDT6QbAPaU1Oe49rNknWdjggqLLSMvT8DPNAc2MSvdH8IHQhGqNmPDKmKc
tvmqk0kepkOCp9cO1zqL5BVG3tJUxDsZzY5q0mc6FzsT0ASU4hJvnboXPORU
/eFV2WLD/XN2h6PdiFYUUP+aZkcd+SmmOtDujZn0rYsdpLpIYxD2MMI0uYkv
HVm2WMXYcAtYpKNsEXsF+ImwSPyxyMmLdMoHTjATqzSx6XBPV/Un3Hpdl6jq
i9IrpWQxen7cRkzhCEx8fwkz1GyKo/2jdrp5VXKd1a3d06aFsIaRBs65NMCz
j9ldEEeCxPTVtzxSvDT0LnC9z0SVweBUFshlRy7aJrPuBgdAdV3dw2iByqk/
luidj7uzXsNNFRkOiC2fGVwXcUPPPtVi8WOmP1KqiBcp+qwjfKGVGAh2Pcdo
EXRMANBFYsZRCiQbzTPWpTBDyWFvf2HYVBmLtSiqr4Ld+5NwF27hbDORqfM5
kN5EVOBB+lInkkgP9JD+Qwj6lpgLmM1b+Y2ByHfNKU0yRPOkz2/OKcJAzWkx
i77elMBeM18Fw+bA/t3hKnnANMTdOp9cNiAMOVITYGY/mu++OqmgMwb6uqgg
xROPHYdVf6fQZHsm5l6DFNoX5fmGQThDZlu0ZObFL2QSrl4sggLlzlAGqcu7
PmsbROQkDVlbi6EXEzYOmfh4rjaZvvN95ZmQaPfw1t+S2Ttipj8WAL6ey3YH
6WRhhAaVlAlJVdG+ivCs1nu+QPIw9tf28jdKf3B2RAft7Fe6/ca/s1CnokSS
NGdivv11jric0LGI93jT6RqaehoHRcZ9NZgVxUTm2E9mxQK6b5wbGowKip+3
dqiHoJQoHEGDmK1yJ8HxGbLCHJ1qaO6YzCRnbSDMHGZA59DSPSzz2bxmnyZ4
zQfPem+nfSLHjIJ3LYyDAL+aFGVFc9ezIdxKgQDszEC4BF1aqGX78IOVj/XR
CjnfVkFxna7Z4INkXFGfUYbFQhhD4h70tkheoK8mD8LDmtEUSALnN7guxh+Y
cgX3JXI7Mbv56E5VNl0W1UyCxrvd23CwX2nmv0iKjl9JWivWgxfZx2whXsDB
0EuuLTuXZzc7hONX5vy8G5wX9sxpl+RKxntBs5TzGlChOuWoQHO1NbUnUBr2
2SeDOKvPSeZJF7fpXaVEOvp42BIgnOJdvktj0u17JjuhtwCLp7OCx9qCbYc9
b79X47Ho8uIZoO1KonXCdURMyqKF3FTl9JphTHzESwZW0sqTMNM23VEoQl0A
MCaZ6n7M7OAtRXrBiKFZsYbTbO6wqkqXhU5H8TAN6mcDjtOyNEMGTTJSiyM3
IHqa0Z0z/ak2hQ7xjzc3b9C1ALmRwQ2+BUS9mOxRXxLX0eisnnOepg2DFrF0
mGsidnSa5p8ock/vSjrGPDxx1EzrjpIqzEzpK7X5EEj3Y2Ms7u9os5oAiyC+
nxeXP37+vKdGkDngWIQ6hyZQim3bciVCbhUswRZnEvshRBAaYFLx2XLYu2hP
zuiQSDfer0hvsADX1BzsAzJRIQCwwoKwwr//BvoeYC+Dm3Q2yyYDwhP/3vdv
3sEVde9o9vwah+WnA4qgqqt/B4hBPFfpNqq0fTx86mRq2FcQVEckek43pBRg
Wz+zAMrfmVEVbSHojiFhALyvi82MNrWggE3YBSI9TPurzCZCSCF0JmwTZohz
kaWpIITXUx9ihKBljq08QQL5+FwBPCd5iXJHdKbELrWRDh0wdsyBj4g9UUyq
XFSFcKmFQ0noKoFaPTRFhMBYSSsB24xJGti9t+GVnIu9TIT5SBPyirwv+ADZ
1Z0s72JArcU/Q73xHUjn7NbAMbG1OxWNHFcHDnY/IFWFdifw3Ai5cW5ybTcQ
bB83ZGEPmAB00kVX+7TltABT9usLHAuvzF2KYFirlC78jPIQAlwMlRKlhN/0
hXird04DlxM2jLxbhOpVMWDTrMN9pFkRiBEex9unC9fTDBfWnGZM0yCvw7VM
dm/J3dI8E3mAolhUBlzZivCvBjOSw8SceNyGPwW5fuXkLdQkj6wIhZ+rb+uH
OuZdht7Zq1SxUUKr35PoG5xjr7HM75NuTJXsJ9sQVa+37ZPvkULqs5dMDx5o
/OO7VxcvLpvte9vG1f7taXuE9gcyRusbDveJdsWdruxKGw3L7NovcCzgCuI5
dTd7eErIXFp0VXL/TXCrVHuJoLsQhYn3qRFa0gztNi9LEWabvpb39418ahrs
Ft795N+1fDJ7Z4uFh+u+95hGk7H6FVEMD8qT/HOtHg1VP+Bf1aqk0pUfzVmd
KyRQpqaz+RK/RWZiXKFyhW7nhH3R7ZuTqzhZlVEYSAHxRt2JVykKo3g/A5sZ
6w9MkEIkjOolZcF5y52miH1cWHtEClHmHJkfpxcgpFdKn6pxsRbq27SWDXvX
pgkJ6pHgo0V2STmHVqRqbOByVvymBdrRbRQRhr0/AtX7iKoDNR2OKnZ9mLLw
F588mW4avr5o4JPBUeAGzqE5O2Uugmsu3lPsrVAngzSRzWM/bcq5oFrjWvlT
ttDR+D1MDqUbTYEfoj5OkktrhD3oJSLFNyH2GUqaxGvf3+tnGJcaHP76gfhR
Y1jsplwxF2Xa1GxFtyWEkTa9r1FiD1PZ6p7CPoHhBv/7b34TpLwB//nvPA/h
1oZNr3rYcskGEiUqjKnp3zoIYwFn7HTSY7d3afZpnK1r0UHRhG7ReRqzTSGz
t7hjTcUkEoYi8k1MQARlqtv1zfa6rc3Oqa2pGVC6TFI5s2YRj2emJ7iE+TKn
rA79jjsaxqARpsROP9wvm7mI8aqyiFng4BdohX29h77eA6Zq5OIwU3kTmFSz
wWGtHQYZE+dJ+R0bZ9Co0973KpxtoXHB2oOFhbA5o0fE8Itf+/mEHvCekJ0c
fUAteJiyFCWv8M89hm+gl/Tms2kuLEbXzFYU04oskxuJE7sA3Ug5+0i7iXgS
ShMO/RAGrGL/bgDUGcffsB7VRcuwZ99aFPpnblGTZIfjoAG1OsRjfsFELwjb
EQ2csmKG4xPUxB0U9tk4xc3M6+BGoUyiuaDTcLCaVygFZR9Jf6dz4Hn5mYjW
g/xe2S1vtkGfDCK6rOXgPoKnLhHNqEe5FoZfZeEhCBxhOgIPpF7sMoeUmM9Q
uu+p8gLhbKUOjaq2UV0abgPvYjBV7bzyqyRTIiqms3QSxLCBmRbw/bABRk4N
VieYIq1OHp8ko7zWQMKyWGOoLiD7TxQ+Fj6t8r/QrJFnAIRKSZ5E0lkWpcWX
Cee2atDDISFW8aIpA3VUxx4foECdyvg46pD8BvDu9hUh26VIfSC66Raf0Nbh
yu5q9ghYZKtZzf6ceE5dHfnrFHf05Em7o8B5d1CVZB+4ZIrV36UBBmRWTb7/
gccjt3eQT35Jjn7rn/y6h2md7Sfw4+f/I6lhSsmQdn/3yXD45MkeXJ742eOT
vR8kPQGiF5nDRfDPJr0d2RZ73jm6IdwahvW+XAAa2WJKuOOus4GaBEnMK8bA
ADe9Se1hp+vQNSmDIg/XzxxjmFfjTcUuBSvicbvMffRh5l1N2dH+G04jsPtu
RQAHN0vi468uAqp9d3l18Zm3JHIDY2MwAgW2MHfnQEzSKEY1yq4k28I5/XrL
YoRStmT1SwE11aRpJMNVmvwIjBMwkJxOK/0gGbrUURlwRZAoKOyUHAvITKeO
AHoSpR1IEUXdkptYSLphn2HgRZ9DCShWBxZesemyZ07L6jf4gWWARjYHRIok
xntsraE4owymDuSZIqgwLA32Mdz6jR7KgjWenAISU8hJCjjW4UZJw3pMhzbM
gbZtHff3OMY5SmnZ2w25/gwTN6yyhPEQquMWeYxDnvo99NmQYKoyC4iaBSEf
vkQRxUHfFXXX02wyQOHZ3CFZX9HaRQxjH4A2I5UQB1NSCJH1huz+hsVTzl2I
rgm3hRsu2iC6zv51z3ZLXVr5dJSHxc1JdvMpX13lvvgsaP52TIYpQHzqcwyC
N1PnmWbEEmSzZMENh+uxIWj8YUvypsjlmfwPs2xtfvPmSd9TjBwtec8gyzzv
M4koYQxCulckpbB1880SVXLCh68Bz7MCc9UjN5C0ivKK7WHGR4q3ZoEwStMT
WF4WpCUTm7rixtI/53fGWQ4TRnaIaqRt3JT0tGeAuUl76VI6v3v7ip2ajKVq
darvsHMQ3KirL9KoXWwdqBP9QtQAhMj+ZjrEfmgDdEQjQinU5/BgODw52Uti
mvTdcHh8DDRJSRKGPpjXK11Rck6jk2Ms7O9tT+QG9lFlMzhlhlKDrg/x4j0g
FC6JITgEBWNFAkbCW0rO3BjCIzC3pL2mS9DIpsZpETk3W8giw2aT4CEkiIQ5
A55ayiF4PJ3wJccQVXq1+EOdCdMYQQTT7p7DjeeQOvILHo8Jm3NOT7nTch+u
qQUat4m/Yp6li83i7pTvZUBGtTEZXgb6nFrZVQs+o4gMUZvB0tYqOT7mOQPN
cUiFWxDaMKPdbANYALCqegIZZ2gBAo4xRPmaz4shHacxuKCLLhdGD3GdgeRI
yUKQdBHa57wgaD+ZZZIpDp3XXeoDsg40NlgBKznci/asC/USFmTFE9Klo/iL
aomCPXXWT44tl3BCaTiDZhMJKGrIVdcVBVVOM1G5jJFDR+Q8wfQO+n7Y09Qo
Gwr+BnhAaFLPCNKu0g4RROYhCV9et0xgnAPDMqYz5t6sJ8JjNS3fZ3HyJJeM
JHl59m+EeZtbG8OzkkRhMPEjItR6YCiloQ2PjWuF2Wr9SUofEsYXmk81SS9b
JuiuxV+w3pB7tE/oJ6ztrwmZqX/EGyx/ozco/B0XqfgrtDz4dHAIL96evbrA
tpap6fDoST85fHqEczt69JhyVkkeLUmJFRyhCo0Bq2pUGDaSLXOnFusTkNWI
6A1GF60YrYpxxbhVdihZYorPzZr8OULuJZkE+qtpdi/N+IBEHgBvovKDG4SA
lm3zacPxc56ibC3RJ8atmjqu0Vo8iL6wJSxmjuBGSI5QxpKYULfBPoTdCwhA
8BTdQ0VUcCy0Uqad1BmjyHSVLu6qvAoMZUA0etBHcMKUzP7y3ZUeNu5upY4K
7D5AJLxh+6vGgMbUOTJQEsrqj3lKsEen6aEHgxMAIfzv4wOEIvrrRIJILZ81
NH397qqP/zM4fswiwDlKLuGmOd5hLFUhHIj0xR6xNOoDcxyoDGjthjg+059i
WmerwEymJEVUrEhEgHOp2bJKwJcRkKoToQUtDlHhCEl8nQX/aF75MNkNWanY
YGkIhjP9mFZIchBRJMeUEjVYXh5rFM3JUSRS3iHeIDQpCgxe/D8JKiJ6FH2v
iBvR9jLLGEqVAo2zyIjQ1oC3dF/K3NAUMF0m/oFZNqKaD+jgf39vJUUcWB4j
WL683A6SnHlJg8hfsmB6aTnlmdtE72PsZW8brD6/fnk29BjuZDDBojUOSJj/
9e4BT6QNIdGzhabXTc5B/Ex2b87OOWVNmjyWhnHawJS/CJPwREelc455cY4D
aRXphjB8ii/54YnLXSUMGl9aHJu8AtGesasJyM+uz6+uovyD1vifwp/JsYxM
zph4IJzy6OATsMKsCqTj4c51khapY463LzbzlQQTbsjT/fpPr7wHrPL7UYUn
hoP70+QbY9uBeDMPheUavt8hsDqX1B+493gW1c7nNntOHLTx5z0KzhMCQKx1
X1lW1BwxY562JPhineJ/HOZgxZOlnlaFAaEdlk4f5NZVGiAMr+FCailLMXce
fNhisMWgs802p0ymcJ/C83FEnTKzxL8Oe/ZTgt6Jq63q7SYu0mvkH8m6rf45
omDVBL0j8jmlgKRoytFOBRGBZo1lLCm4MmWnM1MbyI4HaOfp4jQM1yw5z/ed
ooW8Zi10iRjBttXSs1cqvdLK4DwonxZvEjNzH3FVUwBETX2CSDRiCcX2tgKZ
EePcklfoOhPz2MLUBIn6t3Rbmpxl6hMhqudSvYVVlM49ywjrRldqFkxuU/bc
9IGnFOrgIV3hgrTD2CtRf1YJUi8OcNU6CKiZ3b99tE4TZzW4BDV7dEtIJj+Y
bGRzGfYutuiCcE87uO9hk2OnwGOECo7aoGnlpTHIhCdtUy0Fd6X267j7hDza
s5UeCekMG004X9EtumlzHtSqNSpq6cmq0Y9PQ3ZbdzoKAlalb4X4r0p2r+Hd
wMRB3j/V++5e809R/PInTdWvdxysOjqzXohxo7/JLmkMESPsfmfW5Ig1SIOe
mYxiIAJ17x9TjmIVVMxWUYLkvcrnWMVuCJlSmi3BIDj2tciiK+Yy+7pSnLiK
Ppcuu2RrFE7yOteU9sWtlPPrYyqemk1BaCTieNjBqNAA/RVdRlfaBkExnbEz
M+tKNah5lN0V4uwXe48Yeq0LSy/vM78rZrkWtaB00l4EK2vKfMbaC8lvDWsy
Z3RN84M7Gdwt2x4sogDEZiPHa16LZoos2Gyx9hYm1rnV273nvbESkwEQeqPL
x/iZO8BRiWd2PfWjUKOiNIyIbWhaHRH33J0yoQzPGkT1r//2P5PXKzvIN+YX
Tvexnm/wwJIdaLbzdx0gUiQekWZBqQCJ+1S1QFqGzPoudgpJG+96FCwc54xC
7ci0g9W/NjwuN7/EQqyUlgs9XQRyKNIE0a6xDDxHNqzypM3dN8q64GUh8ioG
ifHFRfYRPgg8PVYd1AjmLyuRr/9btMhxr3+fGplxaFAky29RJbtfyfcJZ1D/
HRs2vdLZcpgTJudU3bt/1JSpry9fNoqKBDsetVVDXpwbIo7OfQ0XniKfgtzz
0pPDXRhlT6+KZmtlJ3NNn4ZsNyF3b3+CZRe3Cowc9Vsr8QJ8k6t3WYA2zB6n
XLEpP/WScJMmlwroCaMQOImgzSJK3Ex0cX5LZj2XHuP+Xp6h+Ki0c1QUddRG
nok3zs5kNENja9REnlGCTHRE41ARnbEkJ+aAtRYnSNxLOmb9JpLWrJxlWtZC
KM8F9SqFYAh55PUmuKEYDgAOYoGMy8rMrpp8jSphFWja2UQ5AQvAVARCJFxX
MOyYNeKkHoXJqpM7MPzZ1HLIoBG6zHyocsRnWZJn4wWtBpSU8kopHb7mFCw+
ZoMlR+WE2BAlUt68nY2LgctOywRK1hhEKYcf0tJZ9kiDEYNJDFtDFftY8SaZ
7X+krCi8S3yZYsXcyL2PYrUASA8fi8Cxq8q1PZGcqCP8iI6G7DyyHkyAAT2N
7izrfqQeHDyoHixKIQ63tO8afUxrFCQfEth5XaFqv+CEVdMooEYGH1EAVWlu
irJoIAYoTHOEO41iMHo7ZCzdcfabjHlqLWfQKHpguAi2pBB1e03MIeAlzDBY
qRPtApPim7P8XKgtEgoUAoDPBvFxgdDC82Q35quGJ5Km7sWpKEZpJZVQeCAq
1QYDeqxJy03aD6nEcMNi3Zhlbabis5quiTHJJijPJANQJCzBwOI6ZUV5+OS4
KKDFh5iSlGb38mzwoo//+5L+91o84ujdOayDae7g7RmqSpBl5w8o/B5rFVH0
rITUkSqVtFtHJ6SyJ86757M5TPOS8nkvpiygu9UPaRZK/hd30hMVrOgxD087
EPVkEcO+p76wOIPrMNGeTZR1vaiNOX4cZgmLe4mbbiABdxRLoogqFFhEYHNh
IT1i+yUiCjMvnLNGh1T18cKDrxyBPKXx4J3q8SYiDkQZWOOXiNmNdoTPgRJj
bSgnEuxkqIDc8xWQRY0t9YuJW3LqTnXz1vpMCyoj3NOs/NyWawsT63Ju2+CS
3Bac63+V+D1AME1iOE5Gi2L8oeqJxbPKFlT4b5XJLDhDxlyqz4RCOeZAQ+Mv
ERv1ZRBE09mndciG+kfgwjG9AtbzaBQDani49Fqq4CixF4ZqZ0xIzoGecjl1
FkKHyc+s2nA+jD3DD0gcKW+E6YwEaZJFP6IrArLcnFv1ti9gmERSRsp3jj2j
ds7OBxeXg5MnO4xWe3GRJVW2ceEpjiM/+HR23of/vbjE/z15og7REmMWIoCP
wzLYaXEllX+24Mb+F5Aj66a57xO1cAu+RJ/W7aViYkxKjUPBhzTGn1t7qaT2
utadgbsKf0hs9jZvZ1aWaUeacnQkSAy1ZmpCZPMLJUdxKvzd12h8YK+8j5ly
QyFy9DVqE8pxokF/LMmTtIjLPE3gYbF7uOcK2wx8HYzd4z0QBSe7j/dEAZnV
2HrNm7B7suemDy9EVUdinSTZ6LcdtiXFTxWSytKWC9TKpsGaso/pSuuj4qqw
1g4uSNPJiLcpgwV3qsDhjAsoJ/5ZpesDm4TQ7pA9IThFqO/pl/plRuerBC+S
pUjiCcIX/1xTCBz/jTWv7QdzUz2Qy0LD73H6+oBak9NP+D34c4XRKe4Bpsf6
odd4AJ85P6DjXqMDfN3pR3SiYwur50bnJ9H48sjPwD2K53D4uNfqZ+s0jk56
XgQVockJoZSzOcidKlWJ5NkQvExzlxPbZMU/2Omy790BJ+ysw6kDnDMpJUdx
+i1AJSzAIRGKa0YJW66SHMjDn0kZ43wu0T6AGJWcPNgTgr8yicJZ+IVblm5J
IrT1cWVcZQMd2uBEBWG+ptHt2h+aGV3iUZZoVQkqhNwQ4ht+nrI6cvjhr0TI
ALlhhcO6RC98gM0Q3CrU0sP11VqH2cqwjDKuO6c9hhTDISsNacxFiR0Z6Fqd
sGt/6IPWLDlhOZm9RvkGd5jOHZOJU4jEquG7qgwYuTnGARs3c1VHcwaTyJJp
PIEzZsDMqZsBco6qfkBRuNiUGCNC5iP2mpkTEQpzEd8vHy2hEfslJdDkDPkr
ZUsH+WqA3TXGCzBlBV5GVCXWeZ7EviaqQ8uj8jdi8tVyWylDvFgvuLQgOWgF
RxhxicYRiZfFqzYgK3HI1nbjIhRkBBj2+EgxfRzr8LBWR22PNRvto7CHLymH
/kZjYN97GfJWERCna8xchO5A6VJT/8fGQNw0BD5UJ6DSZFFnIbdObD0MDLUY
INmCGqfBUw2NBHE2qgJyrSY6h68ngopeB/RhoIaN56RoBNrX8fhBR9cT8nPl
Aoyd/3i16hY7HB4fmQOsEBPFFYGc/ImfCEGxO6/VHcMVSht5B+0+e6MBGl2A
EBBa81oqqVRoB8SePiX7ZyjnT6DlB5ErFzTrrKPBsWV+A3ERoZR8HMRcXP9M
EhvlvXt6LCSIY1qBzWrml6WMT2YHrNRUfEvJYGh4ZwVR3CHaPFzXWcdubaUq
bfockxVTkcaE5Yvg14Q/3Z02BOqbFgz6FwCFv1CH8hBYadSUM+T9Xgwj8PA3
8Sn0fvXAxhVEk91rLW2HnouBb+HXyrZIuVF3NUU+8aVX8eoPWMOGQCKKATTm
Ms4gGVFHU8NRHfwXe1eky8kLKfOxKizkrdQKwQ5Eyepai9qINMdkpc4x6jqq
wRwKd7CPGJrLsBIoij08NTYA6TMyv+YzIGQYN6gIbxrPX81gwd/A163e0bqc
1RZIsvcAS3GWfTJrfxVOgyMcUMJWAyOyl+zFp2woxQ66E6VUzUvScg6Tm9u4
2c24Xr7TpDllDlCAQ6eh+6YbSTe0NfgDNzQGxca2CtR2MH7tE+k8BA2WzAXd
EW9SyCK+zs51277e7pnau26/5kZ/4UIn8Y0W4wxZqJKzkHjzR3gYGcLIhMM5
3BpGnqBMoVMv0T8rKkwg4I7faNCuXQmX67PDCa/ph1tZz9b8a1h6phbRnLC8
ilXqLKx4jthG6LJu2O9swp6HdVksvPCiug/ha8uMyng59EQq/dJ8V2QZqjrh
ep23EoEb6hRrhh/KV8iDhhxojVpgmvspEqx0Z/s6E9tqroCKlXwAWAdUrvol
x9juvn39cq/PrB7WYY7qOt0Wllq5gwnXe9Y+CmVI/waStwsdDBBMwi2AX4sI
OYmpMNm9yEabWXJNFS4CpKolUS5ww9hIDgzMHTJIDW7R/YLKskhgIz+ZUOdS
AyrPzFTgozDv73+6OXsuumOXBNwEci6fjv4pvfE8X3Pgo5sCJ6e0WvSNETkC
lVPggoiTLzJUhMVFZVPOz8dQyzPnsOke4KQ1h9/2KU5O+G+uiREgZoV4gWHe
eqbFIez2kHGJEqiobjQ4H2lRPUrlqeaX5lI0hRwmYGO9Zw8YMP7BJRvukGKO
MQ6QCrwRg2bvSZgIflIULIjhcz0abVWEzG4IkFKIgvyntGA5Zs6TIXxbrPPK
GTZYXokvFCn1JPi8lkHknGaUHSUM0IMBwgR57jLGyEoCGVxMRdCG+wZgwTYp
9T7peaeakH0wZ6/WOv2QSe4UDAbaYERSpAyXmNkeNpb6DkgBWwsbBedaqsmC
9RRo5++cg36PjCqSdbtn1SVDRpG+mJ8r74fQvHOMzzizMxea5FrYBkuW/QCL
W2DOUS4kgvaiKqqxqEV6SDgknM0HYmluOEMiAh8XviF8FSmOGgVb1Nhdeaym
pRvSCaairTPTFEjiHMpqcEu6CbiYWY2+qmL9Fg2NGeuDVkeqUtogIlmnZWXU
smMBiZYc6hyPOymNmZpEvmPJPJ+hKoU0QFXoOUCnQHdluKTZoqchMdwFe6Pk
NW9PkpELwjC5zvH0qV1xi77LrHPS3nvWu1IUqsn+bSWjYdzRpkQ9AQUp87Xn
vDWsC+LRexrCxg4pRdHQzOQr+AEMvECi+EBo3USruM7x5hsAnrwgBIcP47x+
ie+WEJvkUPKljjG1hrrS9sxHxlW5t0ESGQTVPMt1WllifGpLkfGhpDQOvmGF
SnnnC8Vj6h6X/McyJghw9ALUZFpSK+h3fLqhV69vepJ42SHrnNMyUZDqVKL1
bPCWH3Ea8kaprpHvd7uPaA+GneWtzbWRptILdIMXItLEerEpNWK8demJz6Fa
jT2f6zhVawzT2nQ2K7OZuS86iJEbk/rqhpi0i/J9IenG9t4VCDUYG0p7T6GQ
0czvgkuDCi63c0wFP6bqZtoRcAM8cc60y5XhekwTQjBTAA0JkCc1TDgb0a66
DF6Lux6jWNuVUAGM5jHQefAv8ZmNiPZd8FpiqwCWn0mZnzTAQpRIWhc+kIC1
FG24SumV4oiu+6pWz0vmD0iupvwH0ZREyxiJB0ZSA/tVoYtFL2AUYTpk9wgD
M37SbFgmUeg0LgQHCX3i1kF6CHjScTjku9zCYsjw9QRcQoEsYyXqeWZVpjg0
uhnZaJgFtj8rAwclHwE2qZ2r2JZJNJYl+BoFvH98hcTLsT84ZlGoinDSsdi3
D6BRdmxy8kbZpsXdA9NBPjU6+cbM1q4Xm1u4ocQjBoFsknHdWYZhdxrDBMWi
XksMDVKn7Hws6rR6wXX06Ay91BkR2b97a3E/eTeDOOawvxSpIRar3zHXDrks
PpBnG02f8uWj2b6mhqqrcUYeOL9CZ0W9Dxi5BNEwekps816v1374fTKpBnpx
9jsV7bblD78e0AGQgPqlln6tX2hKeoYB7Lf/CBYSJt31j5M47UiTnX5ykPwQ
IL/7n3yjreCjQ/eRX932j1wr+P7If+/XvP171wo6OPYddO5EIhmvOv7FHXd+
DUOcJJG9xIJEd18UTX9vfafaA/2td4fj7hCsZ5mpYSzyMdZVEefZrI2jvAd5
i5NJ7wU8qoHS98maJX+mC32YYo6rdHwXng3Co3mWTjQ9IciP2SQYAaPciTj+
z8fnyfOssNWfvblK7u/h6RCewk58/tzbpdly8lLg48hV0QoaQtvn109OPn/e
0ywcTostC0tLqbOtE4NXr9JXye50URCXOFgX+Yp8+gbpQKoghi2gddguNB2B
tXLwULkDFg7MKqhFVdBMsCJnxn6gilJdTNg82wRjQQnDjjn3PaeAIL6VUrZQ
cN8omxaaMr6neWLasjfXJAldLvPVpmYjBPBpZaWhX71AJRepZsTVuLg0ef7q
+jqpsPI7YFNgCi5zMYpnNBvY7iUycD20mYfqVaJlUU8skF1DlKCsjVc1TIix
tq56oQ/W6ElJmJTE9pSIb3DZyjEdTAwC6IAJJHaMbo0a88U/yE+ZDIibWqKV
rAS2lI+xZbFc/xG9lbWWB14c9OyPb5idn3q4c75zS99Dn80skb5Sw2AnuZEG
nJChymD7qXYqhqpo5wPVv20JnCH9sjbeHi/zZepmAxphsyei949+W6TLQq8N
pv/jzGn83G5Q48XvDYd0vBGksv2bwfYmet1bLxgptR4HGIZX/4m/BnD0NuCM
5rdBzzFAxLbMJkXRF4Di7R/Ss7D+5gf6wn2BBMx2pfmBvvAjIMGynWh9IC/8
ByduBLeH8QgD9+Uj+EB3tDWCvPADJI/hA97ppP0BvYiaJ8l38EE4g8YH9sJ9
9ATXMMuS+J+uYZY1+k+Sp4lL0pVs1nS9d9/Rf2MTIr9rGYnJYG++M3JDk+Br
DXdzjXiuJW14VT4lbCX8yjLI12Uuowm53GUAh3tuMdgVaV6TXRShknP8O16T
NemwffOngsh4hXwWWxeBWJOIiSwiuW6WN2BljGnziHhhogyKf60Lcq0qVG/C
hqav2Aiyw9B0H96MCiGP9wLw56S9FdigywuAizFS4A7FtYkdghhQiagPJg7v
9CikIE7byQmHiesKoc3UV5VVFhAeKYM1MQln7oOzyUrKS08ZUlQ9zdMkV5MN
+d2yUlwdUCjXBAJoKaHJnQlYkF/ReFxRGckntHvOEUCLhFWSIindHqX0dcGd
LjhLQjH1TP4BoiXQgb04U12OHOAAmYnYYgfcX5XsXmA2EyDuL7K6Fve1szVy
danzfKW2ZrzDHw8F0D/QJYz34vUZhdEn+BfWV4L/sJU/deHCrAPVkgcMBMFE
pt59jtHRkt3DKJw9+iwuE0u2FpqD5mLhcnh5VW349XM2xLwBkkauMPf3z98M
pHexL/Inxo5z/EdyXuZohEsx8fl5+II5HB6SGDANbRZFqLsDjeVKtoXmBBsf
eY/7lhnHVVoM37tKjJydxarlDa2OZxXuDn3pzSWb1QIDZxo8p1VPJ4YzWknL
TwB3I54rZUSQUhRx7A63BR7XVNMETHLV6Fz7tqJ/YNrOKBLDD0yUTs8VYsSb
zsLQNKvH5rVm0R6pBGtQnrKK9VB+tYZ5taKHMf2hMoQL3kjerXKCxbdZBZIL
EFkSlwE2dt+9fbFHqIUmok5aNN+Q/TwAi82vsfsdEQqaaZ7TKInQw/4HHHIq
JeokVJVD3LRsnXaIw8MUTQPlxidDK/ESra+AMOjtY4TmbBssxdt75CrkuEQc
tfVHxn1vOTf1M4FHGcbPtWIFD2LTib7W3ADsHgKXcyL+IXxaegQBEmD9/eaC
KLaMldB37c5bpdEVX5q7MGb8VXsSr5Ymy7E7ahkAtJStJlaRypCuRlnfvKAI
Ss4KU3N1PBEHyaQi4iB17wFb5HjM2llVolowqzZvjC2Xwqqa67PoM406Z/TA
j4qSEvoyCEeKy6/3EyZiFYjhL8nv6JFkYEe3zPBTHbfwyXtb5ql6Lg42ZR7e
67reU9+n7CcpshI1cGv1bWI/L3Nbcz59L/VZoL/Bu22bB5zhEWeCq9hYJt2q
S1ARJZqU5LthHpwBu6o5vjBqHFImWackqltjjh803jFUxq3n1qkro1RVnPvH
nlKQ2109t2rrcAcr51tTuMn0w63RRDR+BNZ4kWVBHlOyTKrZ+DH2ngm1mXzt
OPSJjnL58A3TjWIbHLvjI/KUNTedu9qO2S7/SytuAnUb6NvG7kDZxB2LrN1K
HkdoQ142a19jdobGyYZYuZpiVzsnGpstXa5ITbstNMAZoLHkW1S/Q8rlqtop
6n5MbIxYgLGhkMU4flSdVK2gsMw9mpxqAPkUhJFzaWGkgp98Gu8FFqbWLEVU
n7A50W8r+jAlu7NEBY+yMIo4EHJ8CvURfcEZMChYl4t7zcNpCA+QhkKuZr+t
tYokrI6Ou+1/OTBV9cT16Mm4dGyMkoGtVDDsSAlkTazQZVQ/h0+D4nr/9eUL
e0xH5BwRW5VsibaK85S/PKpCvqOTRpKZkmL8zJEISz20e16cvdmzgrLPJAZY
YjC5CNHRIypu5LP/rIoEP/Qha41sOGlzZzhBltL70LqbS/JFeLwEZIAmCaHC
wj216+oF+CrPRbH2V3Snro3/VreBltrcokZGRmGzVKnsmTOELa5uofC0NbdE
WGCfikIRA2JxZnQX+8GgyQ645HjiIk7kZrIam57rMLZZXFSjCwxJIU7XF963
59gAaB/qjdl0fX3c5o2helfNW0NcCuXFI402a7esVaCw6fhDOhNrh6TmZg7K
jLrEKra7l1RC6AxmShKrId2sv4yOKc6HoyPkQO8dQ0yIs8ijrADdS6VkUop6
mzuIepo7YG4COhCx0QrA8HNlK1yd1EZUQUs+dS6GGujhMYZWXrVMY0hCQm6d
dpnuV4WXdhr9RAYVxoXuipobozi4xBnGGla8+3t5XmG2JfH7cfYezXrGgkRj
HrvA47EISfktv56tteMKrG14pAFH8RNkb39nrQY8gV9DK3liXLCkY6FvT+l3
uh7oQ0GWUUN+dkrq599Yr6Nicsfh3FuD6RqNKar7B+CTe10vYAsk9o5+brQq
6biobvNJ8xOK/95vBYBHcd9i8GKBfvel++UYcPfUeHD37EE2vJ9g2ldyHwxl
kqJRmxFJxFlmn/CrBgsuWksT0qAPtLOjr6IoamN7N2lROXaWNfZ10LkSNOtX
JSHijwWyzwv1V9/7Ikfc4GGZI65CLh8vEIzuQuWExrL4QyphX6C5Wo2QyllQ
lUXn3p7F+9WWaRrZhGySwqYaAxV0I10BLmGDk7DBvKXBWYndSoOb/giExru9
GMGJETiNUeDPKk8Jvg3ICbFHVLGhjWMF9zYwMqfOIFTpQralf5exjjcpb7Fr
YQpwWp6jSJ4Jf0Qb79LDtGXRZlTc34DW3KVwmM0/NeTWfCj4zT8OOK799L8K
z/mevwrXtT7w+K775RdxXuckHsB7ivZQJekUD6Eb1C9iwbVODCjF2DwehEdR
/LKqTFTaDTwIEnc2CxFCQd9rwCZSwNTjRHTI/ITBMtkk1GwXf5JIheryQ0mA
olY0YefYInGOtzx3vrNucDTtbEiLhXlt88UGI7XwD/p8s2IhWEIqkDWu1QlX
hL149lpaLAmOoiR9O4U/ftsMcOu7ALzVJLjRNqpmSRIeDhyTUSfe8uWdWnUv
EGdqAVf9hkfh4IHosVRLExUX7Mnr62+rLbOzpJb5OselkwNvMeJS0qT3sVwZ
mBJxU/M0UF0bzeNWtSnmxmgFoJphTUoutVpeh4sXabsZMBrYPE5A/DMfUBuY
CIy3ABKm7RsrwCCNEpDpGCgw7yF0mXcbIVmzQpC/dt64ANQ/mh91BJWiNJIa
J+ULSU2weCjHlLS3WEDD09CmUMvUIdRjEWVWpHPiqMJOfVPT62qsrHC4d8bp
WJ9yB0PVGZ8CsJPHwooYETuGSU6LDhTRWpzWpfEVZyKXuZb3FAlRLAZwsaCV
ZwScsxQlWqETxfoSkoLeWrZUWzeXl94pzQ/T8MAKLI7URUAp4vW1xbna9831
B0MLfwH78bMkA1qZCtXb6jVIxjk59IN8qOenqVksWqzla6fp/au8DElPGvhX
5OwOFtjxpH2OuQCYmOazTSlq3aBuDiG1gKBXnKPH4SfR6EbpcptxbTExIpRM
VrhFRCcUWBXFuvp08cfhI0daumHzLC4p6jCTdLIbXg/40Z4kgWOpPq66gioh
tcKRwBpnaWpiv13ucZBPpBQLggRm3efQVhfrqLORKUQlCDroHeduEPh1tQBQ
pc+Kds2KFAE5pzSXOOjwGWoILaUIlengbCetgTmnE4cBukJYfpl6HSKgyzXu
0SrZP3woeeVSd3IpeYIsTUOcao1Q142VvqX++aN2gniOh8Cy4TCpvrPWM4+x
7KItVrSnNHIW6v1KKV+Fk6qpoqSJaOapJsqQS9qECbpaldgWq9Ne7zAZDDys
C0mcbhanvdPkyih5eP7lm3HU6BMpH/bGQp09JnOvpECaSKw3p7PiRmY/9PaR
1mDHjcEoEnaz2jKevNWCSBoMlpVlQckIJlL2Xr2FFC8h00MMIsrUMOoJjuoP
khjLWkf1eivXSGeQfoQdsYwoYYpI8b4iaqMpaAl2cfKWCS9oLe1qyUD8axKL
YY3XKl/5Fgympy7FTcf3pzRuC/0lv6KI1H6s49hdl4Qbyb53feq7NqeJa4+A
3cfsGz33ADoN+zpw0NsMGnGtSFp44D2612NGs2YTvwMMB0mv1z16EvxH+aF5
eKKHbXMu9k++wYfeJfQo/kbnF30jD+0z9LPtmHD0DT8LI6GrbZTHhtgLFDxN
ib2HWYr48WexW2pYJ99kvOefROz4mDGONfYKMw6fJb72tgihRTFR3sRC+Oj7
8KneoeVmZfZg8Tz8OR88yzm1dbZY4HXcw3CQ28G6wJRV6WaSF5zMEWhOgdLS
3SgdfwhMk5XzRnsdO525gcW6gawgV0O7xtZZcslknCXOrB5LcmwJnC6k3LfQ
PWHH6MaRvnnG5dnjUGG0BW8zGKgx1+smOyu3934Uc68lY3FRuUT3qTzUDJV9
Wh/KMvhLan78WwvxsTGZ0phFBXKmFALLzpjmbWuOe1YusVF1flu9+TeinO83
FPVL8meqqChAviQdhZ8FlYVRXzgmzoDE1xscX0fljDkumJZ1/86HkWoJYbjH
mEM2qqoYc3ZQ+tbhedeNEuHAdb4ASEEFaN/xovGcOpb+j0+PGrTn1fQyOHPH
5DRAWFWFHcOLxUQyDzrX8RBaz3xR6COnPF0sfqIqWf2+4vlYZqv1MHAw2DNx
iKikumvGywe7tlFGrItU1Wo2RDi6ABka3fgGdmEGF/msZbG31Fc+gwGmJc84
PIdTQxgAkXZdCtCGDvhO9yw5adTZyAF9NgkuAQWHvfIvEIeGGaCqicy6cRy4
YnVuTb1Yl2piZ8In5ShHR6c7l5MCt4WMtH8EXPcR/UMdJIgOXULFg8uOKV6E
FeZkp7ixJK02ciXYxCxvybCJpZSlFuTHLkHOlYmEWSQEwIBtuJCIHaRDfi1X
h5CBVR0U6CsjD1qgqwk98jIIKFZmK02mm1KF/gILJ1E16OhrUj+4/oX3Dlm2
ofnALDQiztDsyMky1FM2uJCPZMuoXJ8//gDnUmNvQpDM0ouCTNzqLLoQWmxT
rRew15dnNzzt6wCsyDCxicjCv15RL4Mb2tdmA6IThmJU2rR8q0kwOQV/+cgJ
ACZRtYUR43170ejf87f+Wa/XepR8T2wZ+RLQg8EV+d8PqCU3Yc4tPGg3kY63
daCpqkmL/xtYhbxkbb708OAUvmfWtvdQbSZiowI3f4/Fl1DShL/DoX3eczwB
7pH1Bnxze3f242jfrVhS+LwYQFoA0TzcyIODDjenTLKU2UakLb10XOXF9/AR
+D9K4J774pvqnIZ9ayRknc5c8iZOoxxVjdW64/NssY6dUSM6AQNJiYGtMEdL
uiZ/w6KUQ9Wf8Po3jffxb7Tc/ML2qJ2ffr7ZUTI1oOFPE3g2eInrnGW/PvAp
zrH1ba8LggPMPdTfj+9eXby4bPVowIAA/eMGq1Y91MvF1fPL6/aaeg9A1a9d
9yrMuZ3g/b/5fsSHF0B+6wKkFHZwHNmCuLZ3IFIuGvIH6WIGAkU9Xybidryf
aKCmYHj9d+pFYPM8fuVg2TS6Vhwl0JpmuLrzr9E6g5W3L1EzXtYA0HyIkhCB
6v7+3fn5NcWqx1PQqiOU0CZc0JF6zdAd1mx1wEJOxMeTbj1LYJYmSlIGTSYW
m6yUmeeLmGVMAiUnGUYHxM1sKdQUZ9GNmIGDHX9g/Tg1iuGbX6KOfU74TVzh
0hZq60c0L+J6gSJn5bIBHphTlZavRTuidJnR956xJbNTyNVFdqe+GJ7SGH77
IaV0wxHRNMrqnqFD386zWiPfG1No8tPpAxx1cHO0sAvv6RgvlbbMMX71vBk0
YjEfFhsoyFMRoSIwnhen9hlE8Fsbv4LeOhHQ9r+8WvVz1xAnVi0xh+5Qdv9B
BNzvwqd9P2Xqt2Oxhlg7JvqAWHNm7kTSVcjwE19u8dBjxW1nadQm8DeZNp4a
02rS2hNWbB9zM1FV4z6gaOlnGQ3Txf6yNN8AqsZ3D+1QxCNs7aHFNeGXXsfv
v4zwQnQfqXxTmcUP1SeIZdrufVUACNWbSQNerQsWjb5AnZoRsoJJ9UAaozb5
IXHndjhMrMdcWgcYL/xys2LX63SqFQX8zt6W6XotUURltiw+dq4X/rsoqkjW
c90RH7Ctp2jTG/20lhs1/urlylLIYqMj2iFKsSD5WLFThJWwPCV9HF29YlNX
VpDYaPBUkEIgb0ppdxBn7eyJzsLPyWUxE7xIGrAvsbquciBNW00VgoHlbuGd
Dq7C0E7cychCA0S3FBFdPPYfHT79/Bk6pGl8uUdSIbXLdUntJqkJhqDmzWcA
PDCNpgBpwi/69Y4IxcI85CC+am0eOC58b4ywH+KdcA/lqv7dQ7Xv8MMDnpHp
CKF+UWWUW7dvPBLWx4WJM3tk5vupQnWgAsg5cYKdVwClBG8RBZB4Ai2nx8Sw
zmZl5LWz0m8p9qaOJEXJ9KqV472WUPKhXXdpN+jmOg5deAVzC7Pc3ZHmZGsu
Uoo9LzK2tpHCJlboUSTZ6mNeFivS1PeYxOe1ypmYmVdqWYzroBYzdSDX/bE6
Ck311VDWQnyxVwKmDSavuXNxgLuCAboJcYWFsVaZUqN7z0nDGg8dY1dBKMw5
RtFj4gTqNM+w7D1Bo77oUNpJk6PYE+9Pap+mVWt7iNZJXghgbrv6rTpIhqj3
JLNkA59xmj29wmFH5V7df7P1zn3+WqnP1wbvnDQs6tM4W1POUtPR1TFQN+Lb
ajP0mybNNTZHKs7PgHxRtk7RlL+400gg/T2wNvFoUmLSqQoFyKRUB95gDMKx
2smMh0w4JaWNWuCVE2hqe9yQLZ36MMokjJzCoMkpFFymONGontxKEFMcvWES
rnfTJXU94FATQvFPuYSVrSw417Dy13MxXvlt28JKTXLD7+wmcAWGLc5fX18m
Z9ZYq0eiRIJ1Dof4fmjv0c3aJyTToDCus0KsUBjNWQC/YmIrCu+yef3UPS8y
PXTQ1X6z+MPF5Y9qgHNhMgyDXaAWKmZjp43djTlc+5o3HW1LiDDmasNApL76
1uyNGmSUds3bC0ah9Nr/N7O+aOvmK0ZfUtbCAoQREZRA3NBnCEk7ynC5BPqT
TRaN/orkROlyw0qX+2+8rCK4rK35xWXEXCwzCiH9+99BXectI9nDNPW/i6Cy
hZCpGvFAIglcIaKtNKGRb5Famu247Acxm6Oc02Fl0tmW2aDontfiwSSoF4vq
peh5mC289bXxqdrOb9W1Fg3o6GyEI2vOSdiVdPwB/d/YAxe9BTCfWZ2pT4Qn
2lKgjwFdkk4rJo6yY1K+8qzE3Ores7UXm4woYxKBqUSGM21vEvWW8EWCCqdN
Zb8uTN8ZvEDYIMqVO3B70KMKk4YjU2ppAWQILUdFvaw0Lwmmb29LzqRVFJtc
U1Un1Vn94lq6RrhVAloXjOUUBsWY41w3lB0TC59doCVcdiY17B0f7JE1xg0U
mIIOPpaq9GJ7tUTztTksEybn/O1AHLO05SLR7dVBLjk5Vm650RRzIegDng9o
+hrrkYcCEk7aQBGL8MTPN6aoaEiVmMwyGxTTgaWD9KZX0YrmxFC69Kxju7Y9
QL8LDgaJ00vmCi7yhu+qZwKmmtlEehMcPs8W5Fnv8otqRRNOMdqLUoxGA3JA
m1im5APpFtMZck50WPJdBURZ01FRmoUowoXKhqSSD42E+ZDAtmcJbKf5J2mK
k6DEebxTIRcpZx1YEEoJibBuzM/GuaNaIsEqOHxMDOVUtkt10fPnl5eampOK
8SUUVlYbSFivWAQdoSEkNhAi20g228yBhvcNcwbTd72t31F1F8PUQWelngJY
TNbBaL7qtcelEulI3EPMCmF57lJyvcaf9SRmzPdNY4eSIrWgR0oBdwYM6WCU
hxQFZVzrXbl75IizdTGeDziFGG5jj5QjT56ePP382ZXWi0IJrTtORDejnfrd
/iB5dHDQGwHdx0HuAAdQ0E6wrfAecPBnvC8h8SSlIuEM51hFj7P0sVuXnjuF
QZDKQl1hWVbmbHl0tpR7g5ELfPheY6d38ezEJyugGXlrqIYT4gV3LSNIHOFC
Cpyo0EQcoa1l4tzABhBRzXQf1Y2lNJl97kiydeVKpb97e7XHYbjJa7bJXDUK
qcPNU/0TIzb4hLmx4IHsct1NYsphiwBIf82pDv6MrF+qNZ0dd677Yt+IkyOF
DqO/BpdREnERe6vLrCFX+fIpVjGFPbBsipjCgPIrokaNkz2NRD7DJIdLNLhH
iW227P6WArBuCRbQpLYqqRHfOFvZGJGZ0lFVLIi/QZM+iSuaGHmo0MRFisi7
VyHqtTjv4PE46fHLPtQKr2ZDdhmikn37VeSTKOMi3DNEartUGxMvyrsqpF0l
twehIRkQjOLOyfkozX+qOYJb0sSZD1JcCIypNA200wxpSy3/nhhx5Apw9WiE
fGNAcp3ipkpnWUSr4/R1Lrk1sUuobOLUmlGyL64mK1yxVhHmggNa8NXSS8fx
H1QEtM4X+V849YUAnUY4uvzislk4iN9huMUsocZZG2ASWIl6oPLrV4Yp287Q
xwYA0VMtetB+yB7SeJYYyFSHDPhdOmQU0VBY3iJYi5sl2xSdMKp4DQSYbsE0
0gPCfadNvVL1ubnGac+ahYXV6MDiUWM8eGVNOQ8lpnkRFz3XmBthVG1wwmNI
CSJhzGI3smtEQurnbVoGuzmMwrtUTVs/9REyqPZBx1YNjGHzNMX8sK6oIR8E
J47fMkPAsgQW20I+TeIFvejLeU51GuHlpEuNf3+/Xfn4GYfkkM0HVs2RMaL3
4GDBQpwKt6hd5a6LVcTGoEPt26kKsyxGdJ1ysJ9z/RtvU+zUsui2jVyZPypM
gpYysh3gL9S/EO/Ph0LTDpprhCyHR5SOmu4vAi/nxooCpyJapIdy5GKLsTNH
c/O+eF90nXjDpVgfPyj+thZPCk1VSEQ2UU0REdIrVcHvZdRlEOv8BGGCUkN8
0RCGFa3SWfL44KhZusAVbNci4xIezTWdEeHfhew9nFHEdGzQqWS8EGMCEa8I
E5iHCpP10AInRHnRArXInR6oqIN/jzgvm3ORSoKsW1Po7tbYkUdpLBN1uMlS
agzC/PvIJsUBikKuOd9BUbbGc3iHKk5ZDCTH/nXzRl2zHfZCgT/+1kpxE6tv
Fdk6NLKkWJDD5Yp286IEkqSxmYi2EAgjB0e2jqoTSwW0TJ6Il5S8AP5Hnr/T
NBXyxrpofICBQ988HgLA7W75cq+35QV82eEt4/zowsMQjwZyIjsdJqeRWyqH
iOmGsTBSDXCvT6W2A/77HXvgAs3/6Xzw6vL6ZnB99uzyf2DCjYHcYvfp9kQg
GiA2KsqO736g7z5jWNqWnrucHrd0Fvsde7upsB/IgGigTBDHMBQLoYarh684
icNHE8wRj/QJr/TJVtEny0DfK4OGvZeF2bKqTGypca3PQlKVSu1UYNInFEMf
5FpLnMC5bYIrP1lImjr9KJV8xVUfGwWazWYSipn6oQP/ycxvNc5WaZkXlUT5
o6ihcmfoilM8UhWWa9HwHR5gG874c4DZCV1G8yDyiM2omSCezDuMu2TDAWfj
OiRRKu8bSALYmMqYRhuvc3hiU2B3CzeFxkF4ORC7idMGi6M2dg2Ih8yZKN0S
JQo5M1bil421SVczzBYtJMg5GUqI7pKwFOc5QlbB0mHgOISUxi4rpOiBOZYD
gZKjm/tMMN2JW8SZ1/iR7G1iClYWR4Ihz2E+YbtObLtEARO2q8KM7gtNQdJ1
YuwS/swzunFUok0OudVQOFXV3HTTOFYGiPOCIwBhc+c5qpIs1sTq7OCgWmKg
BH7TBEBNEEKZAo1GZ1LiAdZM6qTpIvuUS9YJ9ZbPqYYr0eB8yVQ/vpWjEnNN
dd5NyT9jHvicwEfDfeAKlZyQunoIB1j11lYePjLmYe7YgtOHhWXStZSRAl/Y
92qFfsvLCTqSsqETM3hsnxmJtJjOlcp3Vw2BuPcjl+BFVgVTvVmWE0Qbm4oT
0IsXbcgQKH4y6mXzFcorl21QdGWfvZvLF/VD8VVhGrjhwzuzNmMR3fkAnf0A
YaEjzlDQDxtDJO0oMXxCUZIL0SL5QYLyqyGacA3jRmEDVdpeWXoRSfTEkjRe
dY5Ao8wG1HrB+nQAXfSAF//UMD52w0JLP06lrBlf+1GyBPRZUjPOVNScWMLC
d0dedWVGyNp9mi7gak6C8oG76ZuysRrktIfEbYo2w2M+9RmpLDcLXT5WrlJV
SC4KibuFxSqEdjMeSpMdrL+3467B3KUaVryoeVrIdZcxkGQe5oLHpm0hhEKa
Gc7dWqF+o1RywZ0SLUonpGHES1cPdSprnmM8G7FQAGOPDj1kgNGsv3r5FtkU
aDGMNOZKc81sOnoKvjCNsyBoKmpHrNWDiadvWk9bQ6410UOdeU1szUpJ2W27
szehN87rw3hKbMfR6IIGcKU6Hrrq4SWQMXCFeK7Kh5mUqPkuoiLH9PCOC4e7
EsB8ln09SHIHnmfjD1wiAi7vfIVOenzAhFlDlkbfKa9q2JiRmCHJ2FsXES2z
WVDlR7jYxH3zOIbHREkl3gHt0RR3NPwL6Z5plWw3FOVT4WxcIoMFMsQR02Nz
UeNqf9DRrGAXRMvKxtYFTQplFRCk41Y/D2DqVrUhLz03gKcix3lc7DS7ZV8G
3mOJdMUktXhBBc9RUSrVAgs2dHaX1EjysPd6RYnugWKPKc6djgJ3GemSFYOw
+tmaZz3k0tFhptHZWxgudSO5myiAWZOA1+x3zRp4LPacVqrSwZR+wDl99MOE
FVcsmvJtcCQheKACWgQYZqVWo5FL7a2Wj0bsr+d4iHkC6WRABRk3S48eRDRm
0I2jcZ6hQrCvM0+jrdHsDCx0oPJj2wAU/c2lhfG8CH9QtC1g1W3fsAtnXVPV
bB1f/DaiWcAFojI2ph4hJaYQjBfCnugFuyLWpBmJHHEy5ENFyr+f8H+CrEfH
wEpHZeAYJelMhNcRRkftge8YLYvkKDpLpBqeQMunIXtyZirOvgRECalRjoAc
nbd20MbxxOeM2esSds/SbYemgtA16l/oADzUvHmBlws1WpTlCop0ifpvqqW2
EDG+hibNNr8TWNcImUi5aEzpWipCK3tK2047/TJd03zOyOXxUr78io1XwW4g
gh35TFb7y3SNcWWrB17/wwflGBR3Xg0B8285NlcOyDlGEA0U5kxFadIwkD3A
orsi+UB4kSVqOUwU6utaLK8XiboPbZHbGlKNbvI6JQOrO7prVgj/A2fGKuXO
85JX/01nZZpZUWr/jYf2d2+xruprtveN1de99oL+V2yzJPcQVYj2EqsL1Pe8
kthZUjo8sK8PbqkrBbya7IuefdvIWOy+bnH6ejiauoPmFXHF0ebcpDOhEV/Y
i+Am5eRcuk7QhS2czQB8udi0I0otVgfVXx6Hvq3Tmdd6S+ch3+PbZ+fJk+On
R4nV4AyfuQRIPD8yT/ReT2sSbNDggPNZtRMK1A3HTHIhK0vOiaOii/MzIQOF
mY+0LI1sLsxnn0jpm7APmGuZtNtkM/7c650rraWWnMBKODOvn2DPt37y8uxc
1FyiMYRf0iOQHbTe4X3QpVCfr969eOGPgrtVTs6nEzb8h64j4Ys+1/HBW0gT
kL+0uM9Kp+Izc54tFl4+DzcfM487hTJxHYSNESuHagnYjvdy60WiIBEWwPpe
f0oVQWGWauPW6hKWzNFw34NUmibCqAcn/P4ahjpUltU+VybtC91YD0Z53l/K
poUeyc6P0ObKj2jBocp42kTZR6f4ZgZc8nC5ragL80SlTKsEuCkr3L4SQzEy
Yc1i5476Q/O7w3iACI6JyQFs6aDCl/02YxnX1jDKPvEcr79kIVqCvYIY2wnI
r5KdRu0hUc6fR6renVDIhHX6zPRP8mq8YVc5RLpcaIyNBFutD6w24XLmrCIc
xkgWTe9etA6aEc34GTvWmE++D1ZZZbNCy/OachTVtSii1DG2NbWcbDCJACbR
NAQYEvli3GTeKBSBHK6pH2NNFZsiFCeVUS23mYwecE2oyLmUMvHq+U8prkK7
lSYDXzLVq+bILJh2jxzpUDtn8/cz5k3Z6pvhaE0HhfJRjxoWHDl7xjE2WPnF
vBo17oPhtSucVIpLfz030ultkexK+M2eirhfw+ClD7J33a5J04eZOtIK8mr/
GeT9uGrYg4tM65iX8oqV2mBIq3tOMsMksC+I8T9klEKN9Te+lCwX8CQuFds0
KmM4mtCBhzrVX6owJGCE9cOC7++h63wSmZVSlxVP54CAoasifU1b9fSzI6pN
5klUqhoYHpuqmtWkti+WPQNY0c7KG7Wb5auPxeKjq2TlQy22JARXjf28pHp5
akRGrIFT4Cpyobmm/Gy0x+pzw0cHT11hXrhZgDMwG+WdadLoBrATiTIvD5AP
0gd+8PmB66Kvuh2A1gFCbKSJpBNq79xWdqExIKbJwb5F4TgX6i8bIflwiE6K
UrYvLviLfJqN78ZyIKQFhmO1Mi+E3pqSURptsiV3+LqZkvooTLWKzsD2XQJT
SbSzJCFS6odYL0/0BBMYI9ixgpRm3zrogIAVeVyuJkVZMe5vIpFrC7olrzX1
bfF+b8171TjOmDb6jKG6PXhyWZiDPzmTACaWRJFC8PlQ3EfN2+ds+6QRRMtu
1y1lGwXH9iXPVKGPjI1UxYjvfR9r1wPhBX4HA34HZgLAYMzgPBHc6hw/YW3F
91fuqHrbgvg5zryNkh5gv1HkDVe90u7VHtaZ2sKKFSprFgwWoYzc8UnDPh+J
RA9QNWYXQ5dhUn6GlXd/Y9agc8GKeB/gTpkyG7akz6tYzriaug6a1Tvlg8A6
E2J9iPjw4ZHdotGLAIz4NL91OW+77aPe9mnMPIegbc02cROlKTHpW4w+Nkki
5MJHiHaTrKBqaXVZGND6V5IVwJ+r6NvVftNwr0DDmsCVJV71zAzZrUgu/y8f
POKfrEmIZjOvDnFL/po+Keb3LqwnHsN5u3CQK1suW0ZvMy0Lo2pJOVFQaZzy
Q8nfLI/IdhG54eMSLg7phBCv4zREVSes8I46t6glTai4JovFNukCo1knmVY4
dsveWS82sxmyqDs8a6u+RIcfPLtUPBUWPC81Y8JwS33t3aii2R50WKB3rkbq
Rsn84XAahWt2myVr9vysM40QlFJ1Lj+vM2NLDTdzXwqlfL+E6GSt3VJ4PyyC
LKuiFVC9bByqTgXhZKdEq0vqqBHGbfhiua0pbcNSTkv8dSqDZ8zV9kXG4DCm
YNC8lRo3WsjOfO5VifCgchG3y/qqYiGpmUVYuGzXPO8o5ue3gubyFRvhunx4
L9Cgd0MjBn+RC3Ylu1a3LzH0qXsWpfvO15yfTg5Z87ePJLF+sPILApCAPi7a
gy28i6Q5gN346OYZrIuEG3MbjXFNEey+dkYUm25jtN3/Im8zXHfL0ymvrFPM
iLcpV6d5Vk9Py+kY///mx4sd+PSX/7suBiMM/aHMYIPDX7uenZL++HKS10V5
mqwxoIOSB1CcC3emVwfGwrYiyLFaB7vhV8j1wah/ZVtr8tfgGBV25K/wGjXt
+2Ta/KsY68Ttg1QO1sQsQNDsouFuScakVDNJVXEPX9OBWky6P4wsI7SQbptD
++uGivuvXl/aah3UdNDwxt8Tzi/FN+Xy+ujR4z785/jJCa358vrR4dE/ecUD
NSd9g2U3RR8/HKNLyfKONEGNdxIUEbl0sAuUnb2CHPb7Jy9StHUb0LtL0sKC
WT5R6kcuntF2PKTeQKFgmADjyB5XIS86IznstybXbQrjJTe+YbIraICcaCYP
edFwUgLKroM7V27ICt32pmGsKSzroig+bNZxlTcnX11d8Png34Kgyd1VM4hg
gAdw8xvT/Vq5Z3TDLjQ1ZNjzPdr0Sy+C/VWi8tWdUSvyropOqQvWjV2YAAXf
nxHPi5IrfC9Olcy5RGdDOkRSkrDFCzE7hnARwDN1/2vyKg6wzcXhVHyM+MAk
PcNI/jRGzBVw5T5YQR44qWFyRukHIodfisVpOPoZ8HKpIqpHtGqwuuhN4zhd
WMb9afKNw8IDw9d5vci+3+mgOm3MtoPhi4GmSFCNkY+o8ofkFCC/uRGiTxdR
574xDO9q2zurHxMPXpoQcA2WJyIhWY8LKksp+Qg9SHHyBu3hYUmHRiXHT5bq
8cNqQUYdJFkuwwrxV7SoaMl5ZWJ6NulcJXXcvRF+A2KtGwqTeP93vd4gKylu
nZCMODgaHHcpP3KrJ5qvdL9SK3zit2yLnSsAbQzrU68UIN6sKrrGYUJqwqPl
YhI36YuMQsNzqWcdoWJiqzHhaAkoPdZ2NXuKFJTBTxdw4VeyVhxqy/ct3PTg
ep3F9zr5BP/YH5N+3sE/4uUCXSYDoOU7wfCr5P4bdZqgC8UxECC/wI1NyR1l
4ebORiH8btiQxdVPqSLVFUWgkcsvUSMcR7NqSxipRpnRM7xN2ac1mTnoBKWs
H4Go5ugGLCI5A9HOvsekTZhY+RgZOgXixZ02p4g6+MCYehqCJqUMYrN+rgva
N5UGpZKjDcQvKS4jxMX0evRUK6kpiRVNRyPEuV1vTWQijvJp7Cz3UYVh2zE5
jQ9UvYD6plkWLYgUZ1abh3Sud1YfMY7FBvkiTttHUhsMQFkCMP9NXHtZvfnC
tK60Rg9HhgSBmrPVEu21LuwoQhC5mm6LMpSlX1Xb6hHLXgenQokoRsCjs5Hs
ThpjSg9j2cGtV2FFcg3IGO01fuU1SKO9bF4FKqDK50TZGmU6sX8e67WXGpSK
+nDNdSC30zbTEuOjvFjtaWHWMsrkqNauPMSeh6Jdfn59yXyRJsv8E3Y/FGi3
vIqerrkErxzudPwUjdk4ex8t5pNOSox07xuHqS4QwG5QEdBT1TBynJuQB4S1
BFFMOw73+PAAuj9br4Enyz8lF32PVrMFq3dIUUmhYm4gQIVRLo8e5Wka5Mxd
MREbpwvDEY30OhxtFlINNfLgxIl6hh0h03zOfcweUvmq3oZ3DZeSFZyyLu8U
+WSHGQFxHXh6IFbvO6NVE4k5tiRg6UxESqZfUVh/axZpI9W4aG9o8yiZDZzH
zmo15P8bDlEQfrdaUAwAxU6RV7Qlr+9jVpTKlL0knby9ojm1zpIi5dxiyIjj
ZiMUwnI0UU9NBkxdRlrdHz998jhOzhEOnAKHD3fhz71ez5W6kEQbjQDZPoXB
/gAt4+daVWdYZjPYi2Tnl7PB/0wHfzkYPH0/+PV3O72ey+giXVNULvzsJ/+J
D3+QOF1uEPe2+8vB4OjXvd3d//W/hgd7f8X//HI4ePorPH7662/39n7rBsAE
Mj5JyH/igx+wHmS6HojibSAb9X2ywT0YAs57/OjR8SMN58VbQ9T4qhFBBzcH
JymBdZ+5Ko1z1FPYYg8Nu6X9cE0vQd5cWeJoEjJ6wWvcgL6KYFrSoDeTJ1BI
8mBgMlUrkQG0oTxnro0ltaiSV5ixJh9fUFhiFScZ1WjOo0bw6xC6ZJAcFCXt
dXff7Gr7ukQ4/Vv6bvTIgB4B8W8ThJDuUVO9vAGN3GZoga7QW5WrlUwKTKY+
wFAojHGDq8kyhrJcc46JS3YOh0fDo0cHw8OdPZ7ByaPD7+gaGVElmANmagfA
7YcdX2GAnG1J0VWxBTIwZalEfZAan/P1WDYKppI3GnEAQDDbqNRrSFHrPVka
P8m3kTvWSSJpEZBfEFfY40ByLPzAbGJfSeQ/Z3f6Y/CK0yCQB5kWLua8O1GW
IMrI1lFVzBNwwVut4lTqvP8z59jg1GeEaVPxp5TdpLVYIgifFRE1o8wckj+5
JIgLo4bixOZ+27zIXA5JdS4hTbFph1kZp4fJbNtKHZ+W7ahePNOsvmtE9Gpq
txCo6iNQK4ImotBeUuFpv0nvFhgozE+oo8DIZYHVRDHmvGF2Sie802xYSaNq
X1KJgo5beLT7e+z5PSzsPbB8OKk2P7yW6Yg4QD6lEvdZs7/jQnP9uhIwYQcC
Px/DuoBBywrReTX4eiJ4xPcvInjNtfjq9fKxfoeRu+Fe7QynGbmB7hChLSl+
Eu9AUbZI6tPDx48EF+jBbMirnlgj0QUJox4SojdS6VSRR7Q7ohBMzbSAgKvq
3hPDAtHKWIx0OlCt7a6OAe2Co+RljTYFUs8z0kqlNgSdqKiCZAU56Vwk6euW
5K7K5A5cgGCoOidWXPSPsDxtrpSjlHH8P2zLV7AtW7OtURKUXVJ1hlRr/JPQ
+n7yS3L0W//kV9hQ91PmROuqACEmu0+GwydP9vqSEMWePT7Z++GBiexusnwS
pkC/cAAYzf7mwZpnJEMcHgyHJyd7STzwd8Ph8TEO/EC1OujeFauT3zK2+wWj
c46akJ/GZtb7/MAI9FGRLf36+Oea6j7y33mWZfajhJtSLHswgdDwe6Rk+oBa
03aE3wMEtL7rboDZaH7oNR5YrhraoeNeo4N21htpeaJj8+T86PwkGl8e+Rm4
R/EcDh/3Wv1sncbRyQNQJJs9ByH3FtDHAPEMIImw7603dHqwz50vLKORPJS6
95xy6PdJNZ5nywwe/kY/4ieYU+hhaLDRKA1Jx/T4eWty4fGDd+GErsIDmZEw
9VRlNwfuyNGDdySpbgcoZYeJ0g3Ye+ha3bY33z3T63X7Nfv9he1OHtxvgKwB
Zn8O04Bfi4emDkRotJlh2bp64xBD9FQTULYffp8AvuA06xOpZ9v8h6qRr3g9
qFAxTJP/UktgQ5bpipW9X2hKOQMGcNH8R7CQMOmuf4zmd6TJTj85AOJj6+j+
J99oK/jo0H3kV7f9I9cKvj/y3/s1b//etYIOjn0HnTuRfJ9suzZxx51fwxAn
yUM3SZ2vAljZE7kS0W+jORjojx5ZRJ5JY8W3G32kOl/83py4Ot5gwlBMabT1
m8H2JvMsJb1k6wXwcAAKrcch7TW8+k9l0GzAGc0P+RWkobbM5nnqC9hg+4fQ
FNbf/EBfuC8QfGxXmh/oCz8CgovtROsDeeE/OHEjuD2MRxi4Lx/BB7qjrRHk
hR8geQwf8E4n7Q/oRdQ8Sb6DD8IZND6wF+6jJ7iGWZbE/3QNs6zRf5I8fRDi
N2s688DZMU++nYITsq5gIQ5jBwb+IcRNX1IJxK8e7r862/AX6P4EZGRHUn4B
XhIfCWeNpD78VFqIT95LDuW0PPWZsMN7EMpq5P7fU99StFjuGDVwqaJ9mwdJ
59+ShPsLCzfPztBZeKRsTvwEN+B31kpkm19DqyDt8D6pEMRFsPF3SzLqRw35
2Skd4W+s11ExuWNOdiv71GhMDO0PtJMdL2ALhNuinxvNrzkuqtt80vyEWN/9
jsSTX9pf5/vqttg/tV1uPpSN9o/DZref/ldtuO/5qza99YHf+O6XX9z8zkn8
jQeQNE9gIInbwkHYqvDGd7WclcVmnfyaxOfTeG35VV0LDlI9dXJJx/enNG7I
xCHPAeP82uu1H+s4/HOQT4QPhzvvMHHftTlNXHtOTo1duwfQKQacpWWO2pBq
Q05wwEO12FXXCitrPfR+Bei+3KxaTfwOkM8XoMJe9+hJoJ380KgbchfNudg/
+QYfenJ4FH+j84u+kYf2GfIYHROOvuFnYSTiMf/7a9n/n4zE8u//VxmJVX3H
yKnxT+W8tH5PrRjmDlHacwq6LV9hC89uPyJm1evXOj/jFvbh0SNkWb2+rPsz
ahGGO3qEjGunYiX6bP7/tvflzW0cSb7/96fo4OyuyF0AQnfj1KwdAYKkTFmi
JB6i7bFH0QAaJCQcNBogRct6n/3lWVV9gITGM959EY8xY5FAd51ZmVl5/PKO
vtIXw2bXfS1rs8i8Jl/xi2GLlsTVbcuXhJ6wc2sFPDfXJFE+N7nyymt08y2a
JXKvjQZX+LV9LaIrUubKWdKbyQiqyGvIX7LKX9lrLipfBV9r0nYjKyrdb7Pd
9IQdJFJJQXUvvIZP0AO6AW19zbkrlL+W2ltR2EIqcdXw8n2jJxziaiGVZK1g
pXO7wwfsdrfr/FqRrHKvZYmrjVSSV5mLr9kUKnktzMqSDVSSSZyqwGt5EZRV
X9zX4JsdX1ayjVRScnvK9SaVcuySNEl42UAK8hCfqQOI/TjGo4O8nB7gUpnf
+P9mP2GpwF88db4wAkMqBG565Rt0VOYE0wMPlwoyt/Vsv9p+QSI+9MJGKepl
KoZ+U6wiyg7rbGHRb0igkHedPqgek0/OXVBWnewHxUek4U0NZMRM+eJxFMwD
LZBwfdBF4/IUkMKfUSKTf+5bx3v6BZRn+9c3bojf05Kyq0+zhr6NylQ+6OdB
WrUzVVp15s7QzanQTPELpIAXQDIZSil/bGtCyRSWlZ0wdWZhiLnvs39jT3/j
690ODGynIs5dVqWeuYP95YFXce0L73plZGcn+1B7PPlCiyUK4EOtHBw/B02u
bFwbSeGXssOQ2fKCevYvJerc5gmd+m8EsT4Lq0RlJ+iLLGwBwp9JprAFaMwX
pmFQWAoBuJszlIrE0q7u/+pRfAYW8azk0BsNgKep4ihDqFIM6PIWYRYVYW2U
YAwcZT/PJS3XqYxGOGT5DFGL1M9hCgZhF6FhbEQNVX5TMJv13NRBohxNrc0m
6EC2CsAZ/bZxMVFr3bSgPZMDsk7XFPpCQdqFudf804RhmQmyOEk9TigyZXsl
aOca1fu5BB8JpLOD3s77oCmmngZpf5xzOQATd7WEi5fJlRFk05UWg7LIQ14m
IU4eQfgsDprD7CGn8s86AwVuotsp6eN2sphyaUFexJsFlhBIUgpy5GggqQAy
Wa0Vo47XDifjSTFuTc0lUF+h1RsqSA3ckKqnDZaLuxRjzmi5KABM+vQ0OBuT
FGGQSwK5p6VaEBShwGxIeFnsYBVw6QrKCvJkVDbyxpSDwFyRM91uSrR5bM/9
LD4QQ/JwPVAFqOblslUN5rosfEgoGWAuGPEwL4yxh3+9O1v8ia2zKy3UqyDw
AuGBtuRVcjVRsOnccWeseAeL6ma98rD/1J4MzsamtaJo03NLK4sBJwSakhHo
IpswdpuhP9wLpRh+zxPsPE3UfEr9SAFUg4jCaEWEgjC7sSULaOXtAx6iKw9h
bDCHq2VCLAlWPoukoF+ktjbxYj7FOKhBPP+IvIkOxhImuSQqxR20SN5aeGBI
lWlMGS5n6Lou9iMTp6glpDIH2ZShXOYqrniEN+4fr7LvD+4pJGvpMJH7Wm4z
XG6nSVTO47ShSixcOY/ArT1nzBRuPtY8I2dk2Y5zy+t05XFXXC0dY7q04jFz
GvyqUOrdZCDh99Ta3HP4kTvkkkFm5zi4J1sYZX7hzXYxTka5R44PHKyJeKLC
LbubNlaQiUXznQ1/41MuuLD2jIlhdTL3DFZM4TRhTHgidcYPETivhGiQXjyb
nijkUrEwJha2cDF3lq/mC0BSxZw/73aS3On5yyyFYi9oWVykMCMUpbIc8gfv
aroY0Fat51RjAQvFDJcLRMSJ5+txTCk4S46z9V+qpN4oUFWWbxKqz03lbiv2
kTFg3LKAmDiZnrCc6YLTgjTtkpjZhLMfBX1VtRUUHXlVZRrfKYLk1Xoqw7zC
sz43FRCX8TxVzgZracbFZdFxqVXsmCoABNC3pJoUFJIsPOWRwXDEumkfFhgY
EqdBxkMMWZ4Qusk4MXVHE4lOpWDJEprQE6RzcSrP5BQtyvd1yyylwnwtHx8z
/pcuhZR0T0VUZZaFyWEf4z7O0I+9kR7UdLOJHghGxth3bKBqAqswlLoIGPFP
265ajM1JNzgmqC3MuUI8pTIBHzt3FFqTY6eg1qb+Ir7tlOvhaCQnzLpE9tPc
TxHi4t5Fa6D6MrIOn/9CEBj3m6ZNddwlyFsDvF24LBwdt+DiDTM0LV5SMlBj
SR5pi9O48AWOkjfKjNY8QNyNFS7truKKZWT4XqZ4sdHHVbEAbgU3CU4flWq6
xYN6z/lV5pxqLt5kHo/g3Kw4UAcDxu/ZUW9pFrSOFaZOVKgUsx4oKUdiKsbw
nDGVGOYo1wIq67GcM25dtkIlR19T4LJkgWBs/xremy6uJvO9miKX8QJTRh9V
sdJaL9FyVGUps7JZDc78hpofVIpIIRXS3YJYUh1dh1E2YK0kDTO7xeBjTlbD
FY8lV1rJ0wDkOiOScGuHOFxAtIEtgcF8CY5ZPBUooMVycoXArIiWzDeV1XKt
qeZTZsISQipwLsKIFkueluYJ2Hnz43MGf4Uu7hhUiJTUWZJoMt/yCn4VVpfB
APiKIwHXZwPvV+BIqXwztAwoLccCzASuFysFOrmgppRh4OXqCJoSYZSJjnp9
6qbcUqIJQgAQqRG7A871CpjWggR9Hy6NiN8bhKZhQfTTe0o2pTd/c+e6JHxb
MflonnOmikIqE6HvpIz754htcrdYIsclCEVGMsoAfipPs1nZBkKYCJDSnU1K
t8FTzNYx46ocVMVd9kUoOV91zrmpUk0Gyty1YhC5DdU/rHlniAGaHSrmq8TL
zdApJgvawmZT3fc4B95tEj/NaM34XfalibLnLuAIP8PF5WesVtj7fna5c7Ml
UkLGZLFIVAfIrRIBqYgyYdblljBetDBCsQ2qgZVqZUUBKEUuj3O2yolCUeeL
jWUXMEWtTkBWVRM28ZaS2oLp8pLFbZP9OdPGAV5JYwE3HiV47aP1W63IqrVQ
gICJTQYHaiTHhhY3Ni+ZrSL7wC3WLSA2Z1RwucRygajsTT+DGIMSiS5xWuKL
ts9W2isth8KItHFqpo0QCuYRrbZwfnhIXTMf3dC3C5NmNhcBcRkOVmWXezs1
QLGCPgvqOBzL11noV7fEmwLZcek9BPIBTXU1tQQvNjeEcXqDHBO1Ryq9QtrQ
inGM4KRQvl3BSiFQ/kiHWv1ANCIEPfByj7PIoicIVslAszjI+E5TeOaQ+Xm0
gapYCO6Pe8HJKkCsaRCosHblmQmkCSxnTOqTnA+esj5ppzpxVXVPeBEppoW+
kQVK34odMYxviK2TlEc7GdsyuLogM20ErsJCB9kq2TEjvN+Urf4g8UQFdurF
46MLRUM1+7dpPp6q4XY+E7Y1KzXSygmHzjcQz+F9YGKwibsMtYtZt1xFdrxY
5pIYd+TZnb2KYGl4+etaYZTGOKX9ZIwQrOx4XL1zubjBXERbMkDKXKIjF47S
3GpsZYvpTYQxKHAAjxB0mgVZmqBflh27XHUGF32P2YVDFhZOTHJZz3MTxHP1
Srv0TpOreMl8OvfcVyxCxSusGlL8TUzKGRvn3OqclAsPfH9COYo1z1ytsvN3
9LLdHWydQlow+nnP1uCTQjF8ccnMgQlKn7TChnwjS6BJsimxUKCyZKD/eMjm
uRC7f72GU4V6+BJFEuk85F5AxsgcVK0iVgWeAbHNYF1XC0I++3SzoENURley
gtwL3SFs5RgPMezptM7garWEG5SrxdnX9NzitBX2PstdRnCAhng1sjZ+pird
SE7aFKmh1Sjx7uONgP1rNYVNLxmoLznnJBxdZGzWkHPY1x5VoUHGg1KRkvJN
EY1ShGhiJaiOrVRnd6t4sMyWu6tAoSP0pSkOkj4IZm1h1Dcp7qx1MxLLefF6
Xcnhb0+4UPKiUOrFvVPgKr1Swx8lZKvPyUMxzXhqXHUrm0vO6h0/q8Ttlkyl
JBRPCpA6jMq15fj+oaLfKsavU5PNeL/ITyK5u+gvI9gg8y0XTHBe07LfiIs4
l4sC5mp7TsUCfdeFS9bi41aPMIqs2FrwioEngq/ldMgwTS1jD9CzhqKLLgjS
FwvsDHoGIbSs59qb5kiXDNOcbI9PgGim1qSQueco1pl6QrUOFNn0qE4U7R6u
kLMmtGwwyl52W0VnMvacXbj/L1YMWoFic8e6BfU9FGtSfINuhpKAb8rR4mem
cBExPo+MD8SoTb41lz1OXWzqhaqNmb1PqHo84f7v7owWdwi7kMQz+9QO8i2G
MkNyJuBNp3qGwt8K+qs3cCscufMq2zQD7KbDRZ41v/dKxsEcZkpuriuq0+OY
ebKtGg6gEtxjznxuOOzL+B5aVHvAHhCEMaM7NXJxw4yoT26pHrlSB7AHreFA
kEnopLNXWq06LQWOSmYzsXzaZMCTwPRi57CyYigmG/MpGaJYLmbJs+hr4QNJ
Qmh3tJaq0qknmwhX0gXmptF9oGyUu+s5eWFLl0CRAoS+YL6eYjDFfqYHRj1T
c1xJR3tZ0+ymjTKHPEthuPZllGvsu6vlhMSngXb3/RPcbWgGUZwq5W+Tz89Z
dWEjVsix9BCU09XCU5pZKZoTt2VMJmXAuRLXvcE0hQEHpUWCUq4bQybd3DBx
NdxNQVbDsERUvwh51BR36epab4jcvPMGAnKsp3PSTmlmBKBvjCRz1lUmWM9n
Luj6+qXoEljGSc2kmbujapLUtbFuehywXnHsKmr0pkrYgn8lZlBTBLugUEnc
uxyOYTwXb2rOrJnX9PtcHNAtMsUBL04pmLloKFz+liE34f4F5xZUTp0wclEs
RkQrQuDb2cV1YT+cwi6Kfo7DkIQwJiCDNYwecGw5XY/HGGiBPC9TGw2pF2Go
mdLyUMqowcEi6UdV0C6r6fALKSmIJ2MsCcvE1ohCLf4udkqVFmu+GD4kRh+C
Y9YSXgZy3VqtRMMvK8nC7eCJJSg+EJNAJuJzIBkjnsABqfXspV2vqotxdcA4
yEbNlKsyw88q/FRJvQXXWGVrJ83HkyuCZ2QVyF+i+8gtmUQsfRaTVQUnkjN7
qZ06HqGGQ67ixdKWxywrwsQ2fxdhGesUot/PKo0MDFeyCfkiEmUdsLeG4lBw
xByZY+CJVynfcHNjcF6y1Z0UYKkUxKli7keON07JSVw9sWNhwDRYLrsmB8Co
OmQMU0sYicq8YBtgDVG9flEImQIOYWEMjPQwDpMsavDc4Oy3/HKccQVdu0wG
/pkqWsaAz+g/3l/8495Jr+hJmMTzuCpuBPIIagmKDHQPNs2RhbuO4X/PlpYh
HoBhY4LIVKgnwOJldgMdD6ZmsgvpzIFtTXmJXP9CoZcKzA6nU4OnavytAbSk
z184n1dE7a9ScR9E6UbIb1oN5V2e1W5q9pqYg88slEYhzypiENF3hBm1NEPk
mqfYU0lTpG2BECb3ob3HP9CY9/kzzed9/zpGvyUcqhRdE9mySGTgze4wBWKx
PQpEgy3wI5fBjcus7nui0gOZcqm7BC45adbhohhsQu07WRISCtmxksNFvVOQ
UnU9iVuDQncdMsySxP2OV9YGO7dqHgWxIEwuskwsDkPFMYwvibh+YcHJqc9O
owNa4RvJTNnps42+z9BbU7gBcR2Ys8yy6JrBRIX2Z+Lqc+4BGhKoGGW4He4o
nEHAwZd++O935BQnmNTddI870eacZti0n2kJsfN2uDJA5pjm36wYr9AL51Np
yhCMbS7rxl4VOpyXtOXROZykiqjPMljLy+TISinXmYtdBVoE1vDx4MWzAp6w
lstIWMkqm3JJxZCopGJIJBVDkmzFEDQFTwQGcCJVYnj0FNAUkzxwa4bgEGB0
cB27WQ80K97z3GIkb7hpKlqYXY14hDJWatHl6pCY3mreqZQx2Xn/PsO+3r/f
Ka1pQv6aTE8V12dHr1iSfOZjoRXjORqQCshGB43bkH3Pno5TtcKcso/MGpcx
TmZJsUAx1d3GBCvcchQVfHo12lEUHjMW9eLfIRFwLE0SL9HDQUNSGH/jY3OJ
TohhJnDPjB5oGg5boUANUgac5digZMSo75KdcwcENSXL4UqYzLkyupcANoUb
ZcMED8uy/7wUzHCn/3QO3zOQaaDrmM8cdmW/yp7XZ25mpXmR9jOom78zh+sZ
59eg7ocFZ/ChPB985h8fnh/BN+WckBopUKHn/cd8kN78NT8ndLKWTwmP/4UJ
9DtkQyM9XJgkJYJiK+YLmmPYbD00yX/53DjQsnx2Z8lsYpF8fH2yMDVJVi2b
XHvT5Gbxzb98bt9JBqv/+vCVv2kLiw8V5sdZtVnaDJudx4gT8Xv+tCm+wgTe
8hnSV/mqVZrdWzZfTQfOz7j7P0qpZqrvOC/0ke2Up8wNJVmWT1WzTHOTbW3k
PX8Oz0Fq7K3hWrIkRF0MDS2f8LFgp6em4ifHx41XtAzI+PFGDgoWNhmbJjcQ
OgmK/FqEGzd+sZj+y5fiAHO8Eah/td7AqOwacCY4FXWit2wgcNl8NTc8P99o
03zXf8aZ1qjwzSLnqhj1XTY9k8Oen1/jf5Ir4yVUywM+sptqFbaFSjnpaZMS
oZn3+fk2N+7nckIFRCajf72g1YTFVMMbN++vmlnEdkuuWfN6uQRm/ID8xDfq
Fn/GRl8QzkP5LM13RT2J0SHyMwn+R48kReb3Ma5486aJyk/wca7fGYOpTLIq
RqdQ2VLmy2ULYEEd8muwUZn689YAsxM2nFqVs+iAoMQBKhm/aYaUn5Cf4IMq
1b9ezrx83dsgYPpulF+qLhlyRR9MriYrUP5fJquVuL566B+BG2epyCEQjfzE
N2pWf46ycabaAv75AIXHJr/LKhjL9Xzu1H6RKKwyHsU4ILmptzfqWas/5fqj
03hQqTxn54FGhv0jc9+gZrY38rU/eedfKW7KhjuEfq02Xg1oNGtBISHTKSfK
PLwaFqMlvxobFc0/ZzVeOSgwG9bBeSJ/FCoSrGY8YbFJqSCnzOPr4oLQ5Jdm
o076ZxOKU3P8lEFxNh8aQc2hYBXGgENVRpty58u21qyvbNMaIeJOfnk2qrR/
zvIcC+aPf5E+qtUqPpALDwBabtlsBSgoP9nN+uw/VxGw2A8Xpyc5b8zK9cZQ
gh5/i7ag9XL+5evs6VT6dj3g0h3CTncODt9Rx2fyheOnoRQLeIIz0LJeyJ0a
qila8iyiKkne79oKVVq2ps5Hfn6HWStR0t/QEM6Qvyua/qyRpdBQthYgNpRK
S78XLG0PtFtsCAvmEhAdLHsVVkgr5eY2jtkRVcbdPzly66XcLfCxVPwwUi1L
YpQGrQaNUnzVhXJZAo9IkKJVKSWk7gwaAPxONsZngsWCiKL+N09pFfF3T3/x
v/H/PSUz6bMd7dbADLET+DzmxsuigR6gTk/9CIZ8xDdLOIFYMBRds6Xkiigb
Q0lbcGqOYUE6E1C8wZ2Q3sQYIGl86VoO2DptOY4x68I0PJBoFidMBEKFCI+p
2pKvFCMZYSVEC2+26iE8RczPJcKylZPoJqGkUTLAJXEJqewlHFmermCbXD5o
XKLo25+vCA5Nd2ATe5AkkZgYgtkuGsfI38H+3R7SnZokgClb0KyencNPcJxQ
QlFKv26K4SAmXWeYjEyIQicIuebfGXqvr9aTUTKl9DsK9qQGGdaDvLgZNm79
MHDnIU+PjZ9JNZGWxGA856SmO83R4rKlZa0u3dxSdLLPhysmO4pGdbKql4b4
qaU3VFQy/XUdr8h9NRlRMLipS8y5AteYvTVcTNezeWrOrBtD9QwPDhUKe+Y9
801dLg3b0yJipQm6mdWRmqaFemYeiTmnbWkZpr1cWY/UbaJFyjRAqbRL6am0
cprnyuLMZAhbxLpENUWDAS1MyJgppJryxhWmyNuYB16JHZ2G4nM5jNiW8qat
gNebbrE4bnyymnAsOmWLGVAK3h7YmgAL+j3n2lU4Jfk1k35vAzI4bE8du7a+
Xiac3jN1r/EbApFY31RXiyoVbDOxwXEKxyydOcPiPnGHEsHWOF5hJAseGopX
kkA4G/REjXMkwvSe4mEy45NEW88LYZIun8GZklCcJCX0r9KH+YfASGiAmh3M
wjORqFm4gpj81fnVdphFmmqCltHN0kQOmWO2FApxm55oUXMhmrHkdSPxYAaO
2xfMO8LdddP/MhPXnB6bdpIvcS/kRBWdaXwppS5S7KfnpAYU8iAyOToLhehw
wTVWwDdSybszlONmT0pSHRI8UYpawgwB4ZrkMBLKc+ZgIRq4EH0nIu84TdeY
e4ALkrHLqL+EVmi330v3Mjmd7mbovWRXgmYxQXQQDz9esZ+f0nV9coJJLJ82
YiOnE6QfOde4FXEqPCk28Yx7lKyB4RJYOZMTcTjpmU64zIOkgp0fhmvx+skm
89nIEqYboaiZmiJHYeZnpxiW3xQKWowx0vPNgrZCTlBvXkyjcXZvw5EQdAW4
x80ZwEgbvzGN+7tvFm/23KNcozhj1H5gCRLMN4tBPr3hOOh4qGdDz4XnpAtJ
6A6+eVOM28VYxqoTpE+jsWcPcVaSJRlc7fA8ivjG0E85xR/h1Eras5lxPrUO
x2HTibwHqRhzFdU04uY4GqQimru7PJ5XhX1C4sPISHMcP/9F4lIxGpLKkOrf
jFl2vbijvaHg1kwBcQcNgiSQW4UyNnUoK6XB8RgEtOaK69mClJbMYNGmyRjp
AQ1hHBpiO0eeH6cTqmiJQUg11qXM2NF6xjE5Dv4eSUuKkikJegpLgp5CCXrS
yCQtiMk6vCNJ3SJGGg1U0Rgp8q4MhVMT60h1Rma8EpOP1QkVOg7FkaAEMema
NC4NUcdRVE3wUaYKLIHDXCefGF0QcWWqrYYpx0sISbaUuyJp0YZTYw5+BLqR
VoZeONX1jLLeMdXd71mC9mxJVWiGnnDJnY4EvsLKFYuBlAK12UxntC5LS/0F
Fo/nBHLWMGjZoJUnqbHvSBVK76nVtpjtaCsrhh4wKoqODlP1/aeex2DzT30T
HwS/809Qf+ZfP2l0RuP2IGiHo3Z90IyDTjdqjuqNVj1uR6NRO3hSkQbEr21e
R5f2M4Jg0SfEE+w+ET3zwwp+tbH02FNbr0VfDNvQ8N8eAbt/7HsMLsGe+4ve
GzLiIO8ToEVZeezde6wZu/Du7Vxw8c1Dj7eS3XVScvG0prrn27VizH7oBjAp
BKmaSLccyyrnhyC/MEe6TzCvc7tWPgP97ERx2CgUbrIPPd6KH8BmBxtb2LYV
P4DB9IYzXsvXZ8UxbTWWCKdUC2ob57TVWJB8P0fFEUXQfPClsmUr+LOplfDL
L5XtWmk98z8//NC2YwnaDzS1dSv4EzaeYZmzWfJ+lSTvo1ryKdn5ula+PPjQ
Vq082MSWrTzWxhatXD/x41a93mpEUSuIwqhRH9aDetAaPPYi/DSCVtQatZph
vdloNBvwb2PcjOrwSRSFSRRs0QQ81qiHnTAOg04wbg3yTW7TBPUadEIYdlkz
20zEDJ6aCeutOAgC+H8n6LSS1jYT4f6a43aj1cR/cQVazXan1XzyyNu/PPj9
L94XMaCKHO7lBbjm0Uoi1tmlIBnV/B6VSifthqHuEGTqKbSB99h4ZuQ9vFOh
+GGXl08nKBLxCSr+jiyaZD3+YBt4J0r99Y02QtI+iLqdMOxGQWtXBf8Fm4Nk
sPA/on7Lu+UxNFdq9+asMm+WJ1T2UK0KyxXy/Cn/tNuoy19VL2Gd32UPPnPQ
LTbdKaWjLWVHZ36KfNR5c7mYJvav/JvItGWBaKsR7X2bsX15tF7PnziD0N2S
r5vGYw/9olup56IwgNazzDRrtRqRc+E5kjCZ7vjhtGxJyoTIP2U+X7wve05p
BifmDHXH/UW85Gx39ptl9XPNTcerZaq+SRt2hso+YYi7oBN0mq1JY3g9uan4
A9PNgoC1p2JDqhWGi2//4z9PaeSCTJwztZWhP+Lo7F/4dv/NBeerSBzHSlt7
fVYTXOk7hppPNT+TE1zobUaREjWYoSW/YuR/fN68zgQDzpB0sWv/Y0Q6SoDV
ydf07TcCTSbAxeTtEOvx8eKcGy6fyz9n5GJT1L4N8gbZRcgmpldOOzV+u3yC
kiBrNll8GZl5/PGRf6cmc0vgMhHnlACPQmQ9Ion7G8K34LcFijOZ306Wi7nk
SqWOm0hk8Gnv/MwnbAxM9UVTDM1bPAaM1rRSlARKbJqMiqe15oz80Xt0Ejaj
YQxjGHaTZBg24mEDPhoMB0k8brdBC1EuSZ7gjDbcbGED9aDbGTfrcWM8bg3r
zU4rGHY6rfooiOJW1Eli9yKebQFuuthAp9vohNETvPQeH6KIuDhWOEhOyzA3
bslNcC7qzS620Gx0R8NkOOwMup32sB21B41G0qiP28NW1Bwmncc0KdheBDFA
WyxSEHfCrLtius4pGWELlu9vO0EtoktXgPcawTSKl6s5WlaBqM3QOQDOmX3Y
rqtcdLWPQjftALuJas1ak7v5g2aNCMdpTGNVMXDYgdrSyLvAQvfwbdjmoBm2
mo0QtsqMlKOO4bewlZOTPSfmFQTH9WIqRi3J3XNkxmQ5XCP2Jh0qK9Z36IMd
/5lfkKsuFQkBdQfJuNPutJNBHERJOOyMW0l7OGgMgnGjFXSVAm0bLh0JCSVJ
pz5uxq3WMBgPuu1G2O124854FA+6Ub3TjR4joSwZ8XxkCVxCcsdgd1poKazV
Y6w/9gsal3KU9F/p+JOzQKCjPbLghbXOymN3sfmT7Va7FcBVD0nozeGJf5Q9
pf7jU2zU6kTFZWfFmZ0UftQbDOkzkjqAUpf4pWPktIk/+9MF2tKLpkcXnUrs
2zdOY7H/3aU/wJczU0BBv14iXkx1sJ5MBZgogyX2WiEIXdxwzqFMtQ1228+z
pldxcMzRBR0rUiia+lmeIYitO44ilp1mcZHhXnqoUv1FQSKdOSB61AbDOcX+
GETGXs1vtKUYsJqgxVXv73boC54SbFeL/6Q2MJxnbysL7ajdHXRbjdFo1Gy0
gyFc8SKQDJ3Ov1qitBphg4y3Cpl6iIiLN8sJyMkTjtN/+s9gosY27Doanj4s
L+gWiSfAxyOAoXuk6BSPwhe3yhrm/j6l/56t0J+Wse8Xab1g4OesbvJFKZAB
/p5SY0pgOVxdrmzCmCOs97IXGBXHGilybhMlDTCkSGwcv9XFcsKQvHDjGa5z
AXjYgKMeGWBYh9wnV9dVhoN+febvfvfy9dlehQ6kbUAOecz42ujeMl0dOo3v
wk10Lz8JsW9gVz1B/91Wpbcj+EM/oiEvrXKc28nCMlTYBWhIDS9k6FtCmv4P
yYLjrDi90mS8hVZqiPeK1oCvPJhrtczjcJsbhVk2u4pmCvT5kzRPDxablYJ3
4CLpCCfczQo64GQEhBAuMOyK0bjaajv+KbvQM2cFYcc5tsPZAwrPcsoI4Vec
6A/j5V2YEkKAma6uGdahIl8nLRuVukudaMzYHqZ5xo1M8YQ+OaFMJI14f6/v
bzCwaCXXDZ2CQTaiolvqxPcJmRyVE8X4K11U4O6Psvdud9BqN6LOaBA36vAL
qIHjdn0wbjfHySCoh61RM4geM6J223EYdgfjpPO/1V+HJerLXXK1rexQ10/I
TN6J2i2YSBRFsGTwe2sbk49fH9br9aDVbUStoA2vt0CzbXXRVFwftaKtDOVk
Kg/rSR22hK3cbbguQTONdhNuSo12uFUjrW4raA3DeiOA1xowjhGMqAGfwojQ
9r3ddMIt1OiHzdr0Awd0gBgjotqJ9mK9o9tszFNrDbKhveSD1we2acNHs7nE
6/fj5WAxh5v7jn1g6zYwBQnaCGrhTv6Brdvos3n0WckD27UBPzvH89EancXA
THrr1YJtfTuPtmHupcmnm7yBtAH3xxbQPahlbbo7hPUwqAb1atA8DzrPmu1n
zcZP5phO3JPNPy1pIGjXO/V8A61noPTV6z+VD7DagRNUh6vNzhg2mNRArJi9
8dHAR2fhUyPVqlUQBggw+B7Vr/wdh0f80fEDBMKIDvvwTzLFoNOhDzL0VrDG
PoFcvi8ZKrTiqLIhMtio1Wo34ci1xl1gHK1hNG4G42ajFbUH3QbcW54UZ/FU
uqJ2qjoW/gwOy5sqlqAv6/xTdbhYLGkAVeq81UxGcTMOwma7PQwHcdIJgQu1
x0kUddr1IN7mvAf1OI6jdjMJBoPmoDlKgnpnlDSi7rDeaTaD8gncOyOJcCRB
0gyTEXCdegBEMG6Pu0mjPhqNu+OoEQyi0TYjGXYHMdwg4nE7qQ/jNvwvQWvX
qF7vNEZBd5hjS3q7dq0c8oPV2ZFCHup1B7WZHSEkboFhNzIarLMNZUJWxWxn
UB+EnTZ6OqNRNG5lF+1xcWke/J8Rf1YAtqOovdULcN6bUTtqtAbtTtQREdjZ
8tUGCDSQSXDvtE7lLV9thlEYJo0GScuIpeWWrwZHJFQPrVBtdbeda4lY3fZV
I31BsD5IkfKzhWh9WLZus+MbBSvKpe0acKXqwRKLdeF54i+3b0BE6mlYOwi/
SiQ/LE+3bWCjLH20gQe3aaMbEM1lzp/4u2s+K8vhTCWwF/0+6hUshAtKMCia
A0z1Oo5fp/fEvYe1qEz4oFCLGPE50zOTNXt2yXGl8iCbCsri1OQaxGOg+xiG
i3IALHw3msRX8wUiUFJnuaBDN9xwkhYHrchtFIRwngvZF3OAayQ0AQvmkh47
V2hNosH20UCBv0vAAzkVde5O/y7kbpxqnYnYxNaJjYJv1aYjAQZJ1cSb7Zhf
QVc7LZWk2aa+OKLsAKk4y1pCNTLZuLLopsfMFXGD4Y+FFYj67hjug41ONGx3
uq2yS91D17ntLnKO2c+6kJrxyLqQ+kBUXLhR33FsjVtbGf2iEpDzdeR/dkTu
O7b5gnwuE9Ald9qt1oLfzWweL0s72jIQZauHNgalmjE8Go4qQ7Xcpey0b6dQ
PLXpF05QKpqXdDDbtYLA5YlhSXRKMbyDPtm+FffkfZ1GBDealsTORc36cFtV
A/Tg1siJUwvDEagecDGAf8fbqjpOsB1H0olpIMSGt1U/qP9GCBpLRL+B5oKm
CVSAtla62iEH4NUjjJzrRHGEsXPtoEUT3FpfbMLQm6j2jdsN+HfcNlF0wbba
VBDX643GIGp066Bt14Mm/KcObQ2isD3czr4B04kGjaAbDkbhMEJveicOu2EY
NJN40GhuZ/NBlTAYjNsxaL9J2BwGMJpGu9utN3lttt4dUEJhL2AtmvBbhL+H
SRs4Qyv6qjWpD6POILBrMgwa4aAbA5ffspEQdPjGYNAZtmGXglbciIbdbhM4
Kdxi460ukvAzgFtgt9mGC3Cz1R0M2qMhEPy42/m6NQHOTjr2CBVnoJAhUEwY
NHCa4bZkD7ewgV2NuBV3R8PReBB14CoZb0v2Y3g6aSRB0kk6rRCWozMMR4Nh
ux62G1vvTiOKu0EEx3eUdKMoGiStbbzU29wCHn3k4WC0L9Z9pcGn8zzTNuGn
qr5wLMRpFZhpFcWoE56qmgs/so/5O+qi2fF3CaV2PMFssjXHp6ZYF+V4pblk
qehhJfAtoOXvLiR+KM7VOz273FPYFl98sBLK9rUBq0DnYaP5eMhqSH5FnVoV
RZKU7yBMMMdx+UhMq1nFf1pU66PhnjbMM7s/j0Z7fn2c6hczWiWpzHijbaI2
MWRzO91n68BOJ7Jz+X6yWL1fpBTcmY/8gAZSLODl+4UGgFgaTWBFjWbJS1Ro
pfiSv/VMzE+AZHb2XW+DOfDBH1CcjVBkafd178Msc9Lxa99Xaapi8mvfz4vV
rZgm/2xjQNk2gPprCQsucVT/O60t0+FXElWnXu/+i2nqDxKV1SpYXfjaTc2r
F19NlKKOqJ7xte/n9ZL/R4iKQRhq08ngKykqjICiov/NbOof1MzMT15F+9r3
sypdY1v10vz8Q7od/2xJUY8+9XA7Tr4BWRjdgDwBh1NIFtesmIFoyWQDG/Mi
hSuuVzdrCVowNaLoMam8mIzM3dvt2RQanFGNXS4tjRbtmgzCqd9t2kVQnlRq
ZzlRKWRFU3VQykpIVApVjRQDHJX6c4NtbLCeKdumaAZcGg3HIBVMzBjIXMcD
4UezeHhGTxY1dmRzaqmk3dwU4HBiZxjLAt6aiYEWraRpcSgGOeGeq1YMF0uc
gAFjU+A9nnHN26H4KpioWzAt3dH4qQxWKOOwCDCKzJYfK04go6OrNZdYmlMn
AtjWh4+jzvcvq51Pbz8y3zLo5Y5lzSB8I/Jq0YRmX5yM8JHJxaV+RuUaUJ39
6UPQ//g+vDu6vr4//vHksPWjqMoKaFqucDuQn5bpiaaNf7Gz3KyqfcZhkGaJ
XXu9y6SzzLTAWnfi6bTo595J1xSTlM04cs65/kr//pKNwM2cXK5/RBZ0m2kk
R0zPINrkMD2QgbTUysdFFRFyq811kTZu8/S4Sqt++qH1Or81L4pb07r65hvd
ACmB8hg5OKGb8uaEnsjFuxuMbXu12OnNR+Sa6t3c+EeLxU7GLuzQB3xXg4nr
ihs5vnPG5v5DDpLzD6ljlwIwFtfdwp3wIDq7Pnx93TuLry6fx4v+x8nFh8b1
Vf385vmb64/7vaPe/uzNxffn7we9y+ffHdM3Hz78+vztz95h//l4ef/87eHR
/v7H/f3bi596b4cH8Pfh1ezVby8/HO7D798vLk8uTi8u+y+Dq6vmsPru/dl5
a/Xp9PmoH737cPGz9yZu/PBh+kP1++bbm+c335/2++87Lz5cXq1+fPsmfnt/
9/r4p6g6e/H9SfRDd/zyEwx1ns724+qr25vvTn97fVf98W7+s1dttQe3L6Yf
1sNV8lvvzUEjSFvve6v2yeDsXfTr3Yvpp+P1r8/Hd0kjSNJvdOV+MSv3cjJf
f/JlAzYuvH5fXPj1QIoNvsit+IvL88yCJ/cv6skPvcnryYvv3wVvJy/7L64H
z4f49/HFb8fByeRFtwYP3QyjV/TQy4uj+uj5u99GP3vP390fT+4m8eVR/fjD
4tPJh4tPJ78N668PfmxAM9PkO2h21gwGz+/S49lR8FP/uHU8OU6P5yfBjxP8
HZr+2bv6cNeYH726fnnz4mL95ofbV29++z54/urD9f2LX8Pbyx+ugkbQ+uH7
9Le7tzvu0c0Ez1M5PnNms7AhcFufDKl2i3xe4gKEb6vizGNPnKCbGEfvYf/g
rGcrc5aAf1BB0kJD7KxyfHSOscV1xplQdw7RZ3lu8/+41NXaBE8ihNSAy72S
1BFRRGE8uBTBpvw2rxXs+kFnV4ji+kkvqAdh68lDMA9PC5UZU3UEfP7y8IvJ
7GaFcKbFBiTOCAbQqvca/YN2d7/bahwcHGAofR9D6fsYSh9060G93qzX9b7S
7Rw14YWjo1afXFp9dGkdBFGvFXUOe/R4GHSPevL4UUgftY6a9G+7HtG/jU7Y
AqUzPIxg+nbyTqasjA5GtR8eNQ8bbYyyOmr1wnq/02sEzfZ+s92KjvqN5v5h
u6m6c7fXjChtvxm0261OPwx6R0f7nUaz12z19pvN9iG83m2rqtyrg+bcjrpB
2Ih67W6/0e40W+EBvN4KwsOwG/ZbYRi01IDQ2w+jqN1pP3lgze1UTClwXOtf
/D3fzZ3NABaWIGAKqChCsRaBlCrWn8SnJedGplwTl7qJqFkbNM1lYZWyr5Na
yoreFBMLp1o4FCOARdN00IAsdhSrweof5qK/LKGd7rDlcZKM5OxIaWBpVrNk
alwCFwtLo26sAj+Pe5f3npskGweiSmuLra7XqTIWgkEi8Vh4teadSRR04uzh
ELObmH3IgE3egEE3yi4pBxJwHwKKWVox2pZE5qJyoGdOeVTr+UqyDB4APSpt
dBVfkRG5VQ93/6ahZkeTZSqR2pZhMpSe0bTcCwd73nGl1CiMqTmIuIaVnGdY
BjxGvaZC8fQW2clJFTPQTtqCGawsoikrzflGnNxGNwJY1R239LWJ3tSi659W
WsmEGTUVabZwZAQznIms0RY+m9/oR4LNG50jZWWNVnT4pJJ5ynHpP8T/Cm85
2ULu58ZBn/tYMn8yn9U5PTPQHNDMlwRik5mO7/PaYS5Q/gv8qQatSukXGOVw
cHjUaoZHxG3bQf2ge9RotUA8tFqtw7De9ctf9P2Dg3bjqBu2e0H/sBc1w33g
843oMAAJEnV6+4dPCi/+kvnki/PXF99w/4NOdADcuAHcmcRkD5e81evABnTy
G4ZyRfg0C6xtJdWRsnf6qFlvPC6x6BMVcb2gFTEkTCcEUdUJ6w8vow6y+9ii
NTsNkHjdeh++6KgHstVuH/VaYaMXtdvNo4N2f7/fOIQHu4f9bido7R9G4VGv
0W60o2i/ftTV1/ph+2i/d3iwv9/vdlvRfre/3zzs9+tRPzqMmvtR76hf32/v
w6+NbvPgUOfWr3e77SAMD3udVvuo3t7vHDQP9yXoxijFmM6SEWhloRe2OnAV
jjNFVDy1DeRDjtL1ZEU2BsYVpKCo4o9pgLkFntC4UY+JOMYaawPEkfCWjnVL
SzwC+A2h6oQB3BqbnWanDHyo+F4RGCiPNYThD8X3HoIWsoA/Je+VIgnlYYJK
3ssBB5WjAhXfszhBXzz/lz3Pz7pdM7dxs4llEiDH+Ss+a9KlAiCTQwat3ib3
aK4jeENSikS3xwZeu85V7kxaY7drSV4uSe547hevAUYHKCG20p8tslSjJmir
jUYXVMpmA3Ytbg3H3WE9/P9ZqpSlik2UpKfy62IVcWPWHgyP0x8rAQsah4TL
f5W1n2XmP+YpuH6SNGHDm+NR2BjHg3bQaLS2DsCWn3A0anZGjWgUJ0G7k8Bx
Tb7SqTnoNsJuEHfhP/VOOB4Pw62jsOSnGdcHW3sIHrXrexvNfg9ehlS95fLX
S64uUXKlSSv+Tm89mix8Y4qRmuLPGd43db7gCwtVJhdw35UDhixdXsfOVcxe
CxxsFtKfJeSPOBFdGSTvEsfpDM92Keo/X8Hkjr5OUXB+96rX1wBiTBSC8ex8
op+d2h8xg7LlwRqlcjYpNEnlTFBoMzptDtF+9PHmh3d9NklNf/zhdDyYddc/
hhf4cHN0/rM3DM8/NhpnP7y7PJldoDXrt9Hli9UgPP3t+MNN+/jjUfDT8+nt
8dFJ8OP8pDmMTqeDs+PW5f2Lw7OL0dEFWsCOfvbSyUX9ev/luXT+8aez08vG
/bvpaRSff2wOL09OTt8d/fbj7NPq/N3R/FV4HAzCn368eN58/SrYf/HjZbP/
6vBnr3l6Hr2a/PCuDi2M7n/8YX8RX5789nDf+Z6hlfBVdPLrxbuL6G3wU/30
6PRjXD89v5heXw6Pfjo4uTh59e5ov385e/f28vL6/OXF9eLd9KfLVz9gz0F3
/LZ29GP6s9c+rZ5/f33V+9hpntz3X795Ox2snj//cPTqfTS8nl/vH75ev2r9
2l+wie2XnIJVQsxYk/JucXXc710dz95dj46660HY/PATzOi4/yI9O1u9uLxo
Hp1MX/zs/XrysTN52ZOn5++m8eVb2LHe5O3l6euz6UV9EEx/HB29u3t7tjpO
Dk5+fXs+vD09Opz0Jz18ZzII3/3srfSt+N27H0b949T5dvXjrHs7QgL57vR+
dHmRHpveTqLB7Ggl4/rZ2x9dnt4M7vffDmfdDz/9cPLbIDq+Og9eTfrz+vcu
GZYc1Ecm/dOlTPpnD6b9wKTfXcD+nb4NTt69ml9fvp2t3o2eT+ej7y6iwfML
M+mfPZyYvBWdnPfuXvXvvqfW+i9uf7oMYOJdtLxejb57Efx0dnelbw6j0frH
y2CK3/3sZYjvsHt+fHXT7V/tiE71i+WEXNHmIEHu4p+SQhJjAZW/4OdV/pzr
oPThdkuI74hXMogHWIT2XnjCMJ6i71EREghEGeT+DFiDJHybN1gnGprGFmOP
ahjVP9UDrsetSeeUIYF1CBHsnCyfiqu/uNHOFPhBKlVCY4kWFCCYBsctKi87
qP+YvoPx9MTZsHKIheJKqUSxPsBQ1wgtD8ogWlbc6phUmJecgR4yP/h/inD8
6CAFnYQgeTAXYl7lb2LFqkm5hBrmRSxjLMoBnPTqGqSIp9+TDXghtSvuMT/k
Bj6rOBWAxbm5WH6k6RLMtr+YV7wEV1AHrKUcbiejNXQ/ZYf0ejpIa3CJMtUQ
7oGl3yaefRJ9zOwnxnJvciDSitSOYSmAC5zKnsZcwN6bLQYYmnZzvZgnBqEh
RVh+UzUjYRtfajcBpM50SiOATj2qpRHU/10FIkxxOnqSultv173mnyxWovab
LfNWDHNHglTrnyBJwA0RaI8qJgwXyxEKtAmZAkfxvdaRkUeq/IgdI4WOyJZi
Hlmc3mMtkcksvkJSR2BRPBQqg9lgNEqG8QhHiU3/uo5Hm1pHaFIhG1gCWqTJ
bEJKwZ3eMqgnuqTSbnMxHT5eU8L4p3IGMEQCdqfZBPW6222mP0zehPcQro7W
9ZYA5hlJb367mGJdCG8ezxfQw2IlZYNgdvdC5xUY4i1sI/kv5jC6KYPILRBu
i4o5jLzBBCHrjgXQmix2XDeNClNoVAIcy+l9OqESOmY38YsJlYjiUFF0JSy5
VgTc+QjDldKMiGyO3/jxaLREbAoYg0e43FSexKFnOBJzrZgiO7TC40Obc691
EsxTHiF1ACfDYzvAUkwV/3aC6C+U/gaqz0f4ZH+6TlYLjNc1J1CLMUxSD8dA
Ch6GD+BOTZMZ5UVNfsODaUeNZQm83/03yeJGAkp/l/w19Jy8Yb7yuxVN+KlU
i+NqWrSpbxZLOh7OR2cS8CQ/v3u/V52f/6oWfko+qvrbPijfwEyCuj8Qmvud
qDDzQ98Xfn6nU5/7yBzZ3aD+9yDcc2ZS6KRSdzv6ik7cI0L9NPe0Exy70wl2
4XbzFZ3kzyJ11N7TQmWyY1XkM1Xj4ZCaZVI4L7ut6vbEYmVqnh+iQeBmxRSf
AgtB8Sf0vj9Zrq6B05EQR0rkskkzsV94VqgZqTuQV4DS4+kd/OtHrWaFaP2j
iY0x8veGyNewffRHbDWe3gruOR95OJ5RD0xIuw2cInvNeD0fcuHinGRmBg7H
DGUxOmWBrZkgI6t1ZBUWk+d143/jB37VT/7+ufrx7+HT3XC+98X51t+gBckD
aN05z6osVmDpQ4jF1hviarhfet8t7pCxVsxgicuSlNRYKebIwgQrfDnVKZoy
V+PpIl5RKRuqmMZFasjbDKxejVZapcqPb2PYDfIq20XBqiHMySSSiUqIwDJp
qQ0sBv1pMjP6HpaC0QqVuqG8n3QDdBYXFhW4VgjzPaJpZnXHZ+5SP7bSutBG
IeDUSPjF0vBgwtF6qFc66//GvkRaop47ZL8buaYfhJ0qNMgaM/zZDd0/w2bL
+TPLYh/imY/86T3A/fzQ/0/gKH+vBk36syN/RvxnU/5sNpmLbeZwpiH0tjgN
hd1MQ42urzx3AxezDWVHFGZH1OARmSqfxO4WN3yg3VKftAev+QvkcCegT1Uo
BFCI5vHrxXC4XooGTGCF90m8fJJ6yB8cLDmlgIrCdOXV1awKSJqMh7hTSTzS
skl8F4kzeqt5TbETkS3hEGoIM2ngrLyCWuroxaTikYbjyiHq020Pay161O0i
TfRrhXkmJ7ldtdEDS6Z2HlqCG4M+jSp4uqoOeQ3Q4jxZyTKJ6SnBAWQqSLma
JkZDThMKXAWNLLnBWlZzx6ENjOqWUp2ohRpa30SdNtBg6zm6iKnukSy5rird
HSTEFrSpCW/sEm5S0KXZ5DEV4CSlX+SEW/50gKLWFoFByEnW/YD7old8MhUT
IJcNyqyf55Kc4UP8+CDB9pH0ML/4Oisu89voxTl5am4p4oJ27qzMBVYksp76
u7sfKWF9D87YzZ791j/HifD4nVF6JXzWnRNKITqCSO+e4ZwH7jH4Cnbp//MY
5h9jmS3W3HCtU9HI/h429G/6s2H/fJBpdjAUYDEfpVa5+3uQbSrKNLWZbXb8
2WS4XGh73FSQbcr+aRmn2c6qu3cuBy2VoshK+1zUtYL7JHLSxIqrCjKHR0z1
NAxk4RBr0jSoCjGzx5z5huJfZhO4Da5nSMHaAZ85PkDzhdsOdYhODhoH3cTx
jD9wV07N9c6UwDQxGnbMhBopFczYhYc4snBht8cgZ7mKWe0iXucjr4OLXE+b
W9+MHOZmMAfh0ugBQ1xSBbbcCqGs0olVpBSbspDMY7CQXhZaMnUD87lIY5I5
NCmXTjtZUGViGNXFBWg5Xo9PlAJw2MrbwDglmdOpvb2LL+1JZfFmK/zyBYOA
UKEeEjceXi/wgqkUYRkmTndBdWixBdbDyVzBd2tDVexrxYs1DgdrlloaIzRQ
XlwP9wgXnMgEKaCSrY1YBWog6l7CsoPMYA4p1faMFkvihLVbkjhrqmN6AxtM
OQIkVqxNsGJDMLnVORoPJCGNcwYmWG+eo70QR/jNBW7L6i5J5n5Yh2sfkhgm
Tde816xRQHd6PcfvMnOABRos4yWXO/2YKMY9kaaOpOb1YVmx8CWHORmCgcmv
EHc7kexihbokcytuGIWL5peHFoRdnVgIQ6bGwmkCAuYO5f07cZc2fN7L0UKg
PrEfA8QP21i6I162S8bzhyawXjCaVG5uWP2SG58idhO12hhXXAeUVLRoFE3H
t54aG1LsgxO6E84XHn3PBqF7jPAbjVTL+CT1eiUcjgyeUywHaopbOPfcmO9i
TKzo+Upwy2/uTfgcmcbleLnmtVTulLLyRs3QWtL2kNGJmmFZeX0qTWgVnIdE
iVKEYGvb0tKhtnKz9IDEWvPosK+o+hDdGrE2uC1NnBkd893pAhEDiY6wcuTE
PRCGW25x9HwpGbmQQwgMYTRxr5SUnFM2MiX1ir1hQsNPsU51PF+PcUNIY5fy
xBZyVzjb3Kn6iMZGSkvy78h8S7ZD2nZZBCynzCIq5Nd3Dy+On77q9feIkvAS
rIDhVAd2KfyrJVFAuOs18pSgb/g0mRqcc8TkqXXqYS3onfqS9iD2OGawsGK7
8AHwV1GpJXTQKRCpdGBqoZN9ZTIXtonAToj8c0zNAJd2+wRWvcThcCEbGF3F
2ckp1XilCeManVEUpecVWmD4atxBssaSiolVwSeGnud5yGMsU4vRrP4Oj+oV
wynt4HbbmV0D++BhMyN8qb+jPQG9Gli11HifCQSLcniMKzr2M817PZdOGW+Q
XADjZI4Yw1cYBLRCh0VMyWF4lkypebiZTJJb3llST7hpinTGEuhiKZ8wBJAG
2JcNX0Jmqfgt+8nn92pENiyZSq5jpd2rRODCahxNgF55y7cJfjzzGJ8UHhwQ
yzLJlIYnRhRLiCyKT2tKQyYh1x8pE+QAO3N7bkFmm+OgQGfePkn91TLGMCkk
ddVvQK+n0qmZgZqwp1SUnDibemeKYdLtzSlzjxxN1hzJPE+PNTjAS67MhmOg
6kwYATGZktBCosKKRRWnriw50QxRbaCpmofNOUWZccy0ZxLscItime/C1gsI
eqfW9cmpZsAJr6gyO4nXCXs+pGs9ONDvysBkk/UN6JMINzXfO+8Qu6SZ2zUi
6tqe7JGbk0lChAYfI+yGRI6Anqu1lKcCW49LIyW0kE6YwpFdc5VukqkTmjyq
xliYWCjyKqFoN+ST/FhC+o9T7zo2hZGUI0rmJOuu3OMFtnaJ+4CV3L2egICb
OkLb0COOv8DccDXnT+DwvcMhkBbMbckXZpWRy5XuNCszPEx8CYb9XULlIyi0
lJeK81eLx8NhM4ZfMKPJnHCQuYuZCEk3LtAU2dajD12m7vuULQEk5pZOH15j
hgY3SS1STak0kfIDc5PzoBm6NRvoNCQDGGU+9TR7wfRF6j1ZX5CHorNrwx7z
tUJqcoijjDWGPeWC1P5kpc4DFstARWdchkOf4p53tVo8AXeayewZU50pWeX2
ZT2NFvfvA6oJMLzpaCNn5ITi1HpUY/9qsRjh1GJuiTdTL0QzkSjGwZcdxGJp
bk6sp4n4cZMOlBac9/hwfAfMTsrDMN4P1pqGKyPovbiP5RoHK63YWYWXk6vW
0Tl18yykug1ua2LbFNoQyMb80UUHjFHjC+sZl63mOYk8G4ZNR2aZ3CwTosWY
SnLK0lFLLBXF4cERbXzIuPOyXnQozOOTT1iIfkLl0fEqATPEnJN7OetpltfD
VsK3MjhhhTx7o93fJvdUv83ULpeZDCheQmrszTTHR6CVZOkkyyd/qu+0uLsI
JVuJnXkx3VqgPbEFLkz5ODZPjmF013RVVTUfb05OCpEdpK2z7rjuSbJqlxWO
IRlSSQiuSUESW1PbkedzPAPezoh2nr85g1sEp8fDmhlmZlYtTziys+UrJmtk
VX++ljntEPOjV4j64jyJIZE45ICcTFC2aOVGfJvIdkI22UwvSC1zXCBjVWZz
jY4eVggFM38J0z5bqEthqIYfHKjTsJn/NcZGztMccSiD5cNJtJ0dn8T53Fe8
ARM/sV0ykpR159AJqYP80ADjH1goEynybVeGUDowmNvlNQbwqKQkhYQrGt6T
CuZ2zuqYDU7VSxvpZqCSoVDMr4ccb6ufa1ZcTp3x4jkfkewFREOVkHPRXEgX
SnNv17zXHJKDYRPYCoZvcCUoDOqVi67Ui+TbpJimRHgPKIe4pH/hSOZujcV/
YGJL9m04lhz2o1BSmOS84XumNTfXGFrCezmpPTId9SGzNOjN/R9qzXpXy5OR
qiTCSp3NFHcnGg1cJPFvjnB2OTAFiklbmYPkOqQMd5KXDIjJjMN8oWVu4TaC
d0ClTlmX5AFR9Jk7qnS1HqOEuLtGrLRM2s56LnzAJgXKKS8Zonc85t0pfCfI
3nJRhpnwhU285KpixXM+bLI469SqOvyi6rSFKCT+eoZ6KdzU2dvkXgLzhXPM
VXCl1Vadi5uVuKzO4RisZXwlLiPVe8TDKc1JQFKMtgIlHqI8QV8RtdrqBKSP
vZE0iaHEtScImIJBHubzirN8fCL0bhkbs4vFUxHbFDND38S7TSfjJMtWaYIg
Xtg4vpBgOzK7GCloa6eClgPn4J7iOIDgz9SS7Y5mLlurLcsQjAKPY6gO74d4
nm8FcaV4MzB2ihneH9UIa5cDFx7E2QRvHXzBJaZirHTJR0aioc5xEjggWT6n
FWEVtiQqdXNHYWbMgApDQ6uU1hT7CquM3GO3vyyKtpO7k0uPmYZyPZHZAg8C
3Z/xA7oOJ05EplI9BnO6X25g1HT00b8Ey/VkxQvGw3GWcuKQ7aYZQUNP0txS
uU2kmVZMDEDqVr5F+iHyYatf/+DgJelOmtGNCRSf/4Ifv4eP38PHX5DAMOUh
wpQH2N2Ua9OlmLYxSMYYfErN4DfWV2HSw5HAuV4wX1du0BPIJa7wNeTM6nWB
R6klkcb4EY1LCx+zVZc9AuxvZ4rTesSis5FgooYkQMvkmTs5cDhpmGyGFX7+
PIlXVRIKZH6UoCMbrIm6GBWLlEsRWV7/D/ndMBxp9/Nn9s5U8Yv0y5c9nmf2
UWYNE2v8YplFrNpGOFU5wkmUCfUHkrh1AVgR+kbGNKE2xLCPqdtVNqCOqO/U
XPB4ZZaWDMlShR6yepOTWmgBrzlkC0d58vqcGDxVEb9l65z6B7PkiNvFC0sO
JdpfCVlLichdOlsmDLhA2p22bduT7BpsxPuryc6H69WUQ2/ZPDVaxuNVFW48
4yqQe1pdD4cp+n/NRn8jSR//6f/bv9mPq/yrfEN/VF9iaTe/Nk5Y19sh0Q8E
V5UkWyr9tuN/8y0arrwvnvvWNyi4EBEVXvI4T7e6WFZB1YWv6EOvpHv/6dNv
/F2YVsp9cBfYQ7YJf++Bt+GC+AfejtejP/A23EfzbzONP/TSfDD++pfMyfya
l4arSf4ldobseV5h0f0X/f/egU8xifJbr7Cq9DV8itV+v/UKy0Zfw6fwdfSt
V1gX+ho+ha8b33qFFaCv4VP4uvmtV5grDw2OesVvfesVZsU65+uTlz/+d/tb
3/+r/2E1IRi/y/NnjsGXIN6ILxM9Uo4gvfTiW+zCofwPcKvY8WyrfXyg7zww
HCyWO9BE/79fVOjLTGNPffdVD07vGXWd4jy+JaMjCfT1/I7ksdayn2NYPVp1
ieGDGjJj9y+qEtCIhJenNVT4KIpfY6c4NIJf1iB0q5XASgB386GFTiuo12DU
1ZPDs/PqWe/o0Iw/P3ucRGHCNlFbuFKPGJmaR/FywJWAY/j8jDnhIQWfovNt
uBJD2OQ31jXQnAqNGE1XoTbcZO2a3y99VyKa/1pEMqrYduZOYmWFQtj8Qaux
Xk5NkSDMJfir8csKWM1ObUcc0yyOUUVCX/dqSJmYixupiJXeg9b0iZSNMbSS
mbSJohMVLHONW3DOihERHqxi9ZWs4jfIlJFE/doyucLadDt/61V/iqu/1avd
99Vf/uvnn2uPfACkCePJ3nF0UciYRwIqdSWgA6QwHI2mOH94EVpxBBwH+s3Y
QUp3bRJlQPq1ImmowKIwEFpHoUj2W/RtciwsqKizmlXxV1oyIxRrRL+ogBli
L5GXIn9hNft2NVM8uPDneXx1BZJM1/gpfXgB2+d+7NGwM0u1El3i/StL4xIn
71KpvjnkOiOSM4VzhI5Zn5a3GD8IgWWgb69kaN/4f2nVWsEu9crfaed72A3c
nNYybupAslpso0iBsHxe2QxxNZzZpDZT8CS54/loumA/40hCpRi/fd+/jvF6
CmcRU4DSL/lQS1asqIWsK4opUUZ7nUxv0DSLdiuMlWGjwJDygFg/JCMfNjhP
7hxbhRoh5No8wqAY8uqlw3WaSsz3inPKPuLrV3DluZHb0DJZq3XN1cPECgKH
bYKiP2E3jBPKxp/fg7QfTtcpUN2UQyjdYSm5k5Y612gyscthGNty5WMQLMwG
DgGun81ceCGD6ZcNho0E8crBn5rTnXxJ/GyskfajxXA9I6MDWQmO0Y5AdyCJ
G8QOTsWL+4YAVF/TRVQyFLTU8mCJlH+1iMW4gW4pY6Vn6x+zSdcjbDIy2fA8
pTswTAEU5CmaC+UgoR5eydmCYfTJ8Hq+mC6u7nM2W9JvOVSCzBJwccb0OOvH
iZ1xajiuDqF6s17eoNJ968C9Fjy9xgdBT92ziYoT4Tg5QyOt2Jsg5lkSWHTp
gt75I/JGLObjydVa6R0bscqHls/Cq4ilFpkBtD7J75fBooX1wpOGHwhxoLU8
Taa3mLCG9EYOVX2eLbcVlnB0IgmYLC93YwnZ1HFMF2PolEbDYTcYj7SesnWE
AyyYNijUCm+G2LY4YHJc2LFFurs7T9YrIY6adwZiAfVXUnU0wjvTq3CRWK53
Zqusg6mwPhQ3QGRDrpBNq2+ycbABmjJfxcS2SfzHDIWNbjb+74xhOHGRzu3c
TnhuevNyrN8qYymUwdrY9Eard3exfi1ycYZiB3OCXW7o/ieahIn9Y2p1qnXm
G5JgQbskt+xuzXZABoPNvaQz9OklcCRGqDxt6MM8Ll3QWpFziqNFyIVNUZa1
/HpJFOkDa5ZZLxtilsxvJ8vFnBzhHD55tYxnM+xuGs+v1jF5df5YZ3AKbqhx
azyz3oC8ff3e7YUOqNhMXBWBdKPvLhWCm5l+srQWH5MUYdQ4cqaWvGJ9DfgA
xTuSNTZlGx6PnZJhDAW4jFjMJoTZw+YyhQZPnOOcETQcnDvPwiE5ZxXN4gMM
pXW0TGogwwcI6lWDV14S6Zqz9AoDZFy2qznkJJSMkxOlEa2klkXD9HLxcpsQ
4EzKG2e00PIAJ8pgGotva4Z4LcDdRmx7MtmaYkt2eEg+9EijamG2oBJVTWCO
nYfZpZhTtIvP5MgJHRA3N7yRkn7v5PXrOvCqoJDDTb8rHi6H1nGOSjrWr40+
sZQT0jn2xxwE8aRTTIoVVFOxY5qcGDMR4kGFeGyW0XY084WqVBm5YYP6pXc6
Pmvug71wmZV1zr5EzZ8mEtd8+Iks/JjHIq61FP2fOAy9kFUMQByPC9+Mp0tN
/dKoJM5O4Hz1Siayl8BHVaKSQOWw2Hh0G6P6beiStUAEyzKxFkbL5bwujROk
dZ6JnzevGcAUX4+B2NA1h5OT4dPpyLE0tqwaTQDtliWKAC/t4J7Npxoig1j+
Ei5r3I6ZO59t14TLaGBu0a2aqlNJrMrog5gCkS2WMS4PX8eXaqqXP8YbBpxy
WBOdeTpSFC0kVwuBdxUHIAdJbdSEkNGmudMmHsuCE5IH1z99afRh4A/LCbnx
qhNRd9C8JgZEIYZlwgh2BQXPcGxxsWIB4/kYQzQ1GB7nbyiEap+yAo5/PjA8
uQG8gd4wFAZjPMTaK5vLlnS6jhqzBHaF4TDzicZ8itK3MgmGqCmZPBdX5cOO
5cDdOJ2q3EhZsRGbdpazWUbmXAoyXE0h9mi5yppXxku8AZcso/GTQUfCEmGA
48Tg88arss5d3Txd3yAkbTJyGDMS3gzlEvPykgG56YoJcFR0+5NXDcXSYsB5
kOKjpg3FMB31NuD4hYLzBFPRNdZLVoY72cU2R1cC221UHZOIW//C/z65x7v9
x+R+MpK7vKnuQWYLJBC8wrHqwiU2TJQTnDoYny3Qkc2HuRHMM3HuZLaFQggr
cu3SAB40TTx9gWYMY7Xbqz0WXE9kjI5zZskcb5TpC4abudGvKK7HZnghG1Js
gfyLiqZmrCzk+xviV0i96f0MXl/yB74kPbGWy4G17KkRmwSFEpGalA6BXUrA
1QFnOPTmi/n9DGnDLQ2ze9DrwRp4p73zM7+3hDOJxk5kDuyyiqJGxuGtUDIa
xp+JqnRoG+0kKIVy8aK+RnKvUwZ0yKgFdIdfElVM42HWcyeObFt6hiLajIo2
WZFkwWUUTE824ZjVLJ5c50LLRuiFCasrtIXCZmJOQUXEKYf6oKyPU83aLSlq
Q9Nw1nzJhYCyGY0rTkOaW6VAhNFuuqdlujNLjfFJbrywUBDJ2uLzsiklUTHO
+WUVhIimUGpHVAZnFfJSajLfENVjA18r+U2RbSoG5LhhzfkzQyJCNaTsZuZn
PN34ZPEEbzif2bfpqplivvckvebb4FhodmKjMgvUipujd19zmyAVeJbEbCea
F3ZYUC4yxYx2tcmKOVOVXPJErVbbYy6QwS8bVRMMzXDoUAp+UILodEIBy1Ym
rAjNIBMOIQpsPpavuGSp1V+B713wUZdgKpVeekCXC6pEaS59nDfljLw4Ygyf
TBIHrb6Ql8AudxiYjqsK46qmQ/K+o/Eyu6mviEOnXjZUAk8C272MEsOsnHhV
kTYQDs1c6EvWGWkggRO0uKdjjjLCRAXDpPFvZAPYqaC0FHAGFDEhycjcZckB
SrORYjZcxIRk4ssMdOCmizhR+BTy63aEAatEs6ol+8eS2ZnjNcKWbChthazs
7qXGqPRED7SVlJvKQY7yWk0qT5DYvjxDZcLHJGUNwLCskl1zSDZw713J4Plx
f/fjZLTnskcFmzEhGZL/AX+3m0HzC+a3Y+vTJNY42IwVED/4yG3DUZlXST0k
kTG0JRwk5ZwinRfLLFJMxQniz0l8R27GNIGDhLCQcaeOBLbI3/3+4GiPHu6t
8YqD9E+TdVIoet8fG7lRZK9IbxypeF52CHMn/U6NQzzrJ6mzHlzigTBxYYfo
ioBrx11+x9vyRrcllZXlbz9/xj9qP8DvtQMMM5GdoMvfZTKgEj2xVUZ4c5Ra
VT/Lbz3wyE/NVcX/1FwzK8RFUHEmt1QUWfcbbzn3bKLQzHOlGqa74lqq6pY9
A+bAmb4UWgQTd8t0I8o5lsbIIlG2cxV1ALmSglyDZPEpLoZYV0bZCHBF2Frf
mNDuIsNSA7kIM6vDuQCdtE41WyLG7ztLQ5tdRgQg0Jbs6eEZEt3g2yfsdc3u
iBNLBcIz30uKhASf1fAzJSRak5QRl5VYBcNvdgN9IDenG5/tn6xHFG7npmlK
6lAmy0XeSZ0YCFtOUXu1IlCSFDhhvoxeh0ivQ6FXXUsKQNkny5d7tofiTztS
BITixiHUmhhKhZyWSdVMJiO5khyUEG00xc1ylvjUeTQVDWul3r7sgnE+ZILc
vNiLn5Ulbv8aDqdYQ8aqRVptiQpm4gbnC/dMceBRTgmbmQRyys1B90KxS4SD
z/aKn67nQvAcXD4TEztCmaJZbBJzWhCHeQBRLAbm1uHMOzWFeZwPJ2ac9kYq
MQEVQZ2kbyXgREJJJa+EXCBvFO+IyB1O1N/+vkxmQIK/OL8+o7CGBFZosXyG
5jC8HvJ3rIshDdJlGnvIahoZ/QcrcM5tYoudklNP1CAwUcBgqhCW1AThWM6r
sQgribkQFoQKMJ0q9NmLCxtPRZo4aTG4+fOVp74Fgm3t0VleJtdi3ILuYKKk
ftowWcTbpADrw/MjMtOulvHwY7J8kqqELnNww/k7Kgt+BK2kGnY8r+r3Rpwd
uFrTmpIz/R5WsVqtcib0ZLCG0YiPAdX7jyab166y8yTjHmN/vtQfMM4AT0f2
zPu/tlJoe8t5AgA= [rfced] In the html and pdf outputs, the text enclosed in <tt> is output
in fixed-width font. In the txt output, there are no changes to the font,
and the quotation marks have been removed.

Please review carefully and let us know if the output is acceptable or if any
updates are needed.
-->

<!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->

<!-- [rfced] Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.

  Claims-Set (34) vs. claims set (8)
  Claims-Sets (3) vs. claims-sets (1) vs. claims sets (11)

  Detached EAT Bundle vs. detached EAT bundle
   [Note: should all instances be capitalized to match how it
   appears in the "CBOR Tags" registry
   (https://www.iana.org/assignments/cbor-tags)?]

  EAT nonce claim vs. "eat_nonce" claim
   [Note: are these different or should they be consistent? One instance
   mentions "EAT nonce claim" but points to Section 4.1, which discusses
   the "eat_nonce" claim:
     One option to provide freshness is the EAT nonce claim (Section 4.1).

  "Nonce" claim vs. "nonce" claim vs. nonce claim
  Key ID vs. key ID vs. key identifier
  Simple TEE vs. simple TEE
  Submodule claim vs. submodule claim

b) FYI - We updated the following terms for consistency. Please let us know
if any further updates are needed.

  base-64 and base 64 -> base64
  Canonical -> canonical
  CWT Tag -> CWT tag (per RFC 8392)
  Collision Probability -> collision probability
  EAT Claims -> EAT claims
  eco-system -> ecosystem
  Simple TEE -> simple TEE
  standards-action -> Standards Action (per RFC 8126)
  Hexadecimal Representation -> hexadecimal representation (per other RFCs)

The following terms are capitalized in RFC 9334; however, they were
typically lowercased outside Section 2 of this document.

  Attester (1 instance) -> attester
  Endorser (1 instance) -> endorser
  Evidence (1 instance) -> evidence

c) Should "nested token" be "Nested-Token" in the following since the text
seems to be referring to the type, or is it correct per the context?

Current:
   This CDDL uses, but does not define, Submodule or nested tokens
   because the definition for these types varies between CBOR and JSON
   and the JC<> generic cannot be used to define it.

   The value of each entry in a submodule may be a Claims-Set, nested token,
   or Detached-Submodule-Digest.
-->

<!-- [rfced] Abbreviations

a) We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

  Company ID (CID)
  Concise Software Identification (CoSWID)
  Certificate Revocation List (CRL)
  Elliptic Curve Digital Signature Algorithm (ECDSA)
  Extended Unique Identifier (EUI)
  Global Navigation Satellite System (GNSS)
  Global System for Mobile Communications Association (GSMA)
  Hashed Message Authentication Code (HMAC)
  hardware (HW)
  Initial Device Identifier (IDevID)
  Internet of Things (IoT)
  JSON Web Encryption (JWE)
  JSON Web Signature (JWS)
  Local Device Identifier (LDevID) (per IEEE.802.1AR)
  Media Access Control (MAC)
  Not a Number (NaN)
  Organizationally Unique Identifier (OUI)
  Software Version Number (SVN)
  software (SW)
  Software Identification (SWID)

b) FYI, we updated this expansion to match use in past RFCs.

  JavaScript Object Signing and Encryption (JOSE) (this document) vs.
  JSON Object Signing and Encryption (JOSE) (in RFC 9052 and many other RFCs)
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.

For example, please consider whether the following terms should be updated:
 - whitespace
 - master
 - Native
-->

</rfc>