rfc9711.original.xml   rfc9711.xml 
<?xml version='1.0' encoding='UTF-8'?> <?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; up
dated to -31 by ST 09/16/24-->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -ietf-rats-eat-31" number="0000" category="std" consensus="true" submissionType= "IETF" tocDepth="4" tocInclude="true" updates="" obsoletes="" sortRefs="true" sy mRefs="true" version="3" xml:lang="en"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -ietf-rats-eat-31" number="9711" category="std" consensus="true" submissionType= "IETF" tocDepth="4" tocInclude="true" updates="" obsoletes="" sortRefs="true" sy mRefs="true" version="3" xml:lang="en">
<front> <front>
<title abbrev="EAT">The Entity Attestation Token (EAT)</title> <title abbrev="EAT">The Entity Attestation Token (EAT)</title>
<seriesInfo name="RFC" value="0000"/> <seriesInfo name="RFC" value="9711"/>
<author initials="L." surname="Lundblade" fullname="Laurence Lundblade"> <author initials="L." surname="Lundblade" fullname="Laurence Lundblade">
<organization>Security Theory LLC</organization> <organization>Security Theory LLC</organization>
<address> <address>
<email>lgl@securitytheory.com</email> <email>lgl@securitytheory.com</email>
</address> </address>
</author> </author>
<author initials="G." surname="Mandyam" fullname="Giridhar Mandyam"> <author initials="G." surname="Mandyam" fullname="Giridhar Mandyam">
<organization>Mediatek USA</organization> <organization>Mediatek USA</organization>
<address> <address>
<email>giridhar.mandyam@gmail.com</email> <email>giridhar.mandyam@gmail.com</email>
skipping to change at line 48 skipping to change at line 46
<phone>+44 1252 363189</phone> <phone>+44 1252 363189</phone>
<email>jodonogh@qti.qualcomm.com</email> <email>jodonogh@qti.qualcomm.com</email>
</address> </address>
</author> </author>
<author initials="C." surname="Wallace" fullname="Carl Wallace"> <author initials="C." surname="Wallace" fullname="Carl Wallace">
<organization>Red Hound Software, Inc.</organization> <organization>Red Hound Software, Inc.</organization>
<address> <address>
<email>carl@redhoundsoftware.com</email> <email>carl@redhoundsoftware.com</email>
</address> </address>
</author> </author>
<date year="2024" month="September"/> <date year="2025" month="January"/>
<area>SEC</area> <area>SEC</area>
<workgroup>rats</workgroup> <workgroup>rats</workgroup>
<keyword>signing</keyword> <keyword>signing</keyword>
<keyword>attestation</keyword> <keyword>attestation</keyword>
<keyword>cbor</keyword> <keyword>cbor</keyword>
<abstract> <abstract>
<t>An Entity Attestation Token (EAT) provides an attested claims set <t>An Entity Attestation Token (EAT) provides an attested claims set
that describes state and characteristics of an entity, that describes the state and characteristics of an entity,
a device like a smartphone, IoT device, network equipment or such. a device such as a smartphone, an Internet of Things (IoT) device, network equip
This claims set is used by a relying party, server or service to determine the t ment, or such. This claims set is used by a relying party, server, or service to
ype and degree of trust placed in the entity.</t> determine the type and degree of trust placed in the entity.</t>
<t>An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with at <t>An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with
testation-oriented attestation-oriented claims.</t>
claims.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>An Entity Attestation Token (EAT) is a message made up of claims about an entity. <t>An Entity Attestation Token (EAT) is a message made up of claims about an entity.
An entity may be a device, some hardware or some software. An entity may be a device, some 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 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 or partially trust the entity. The relying party may choose to trust, not trust, or partially trust the entity.
For example, partial trust may be allowing a monetary transaction only up to a l imit.</t> For example, partial trust may be allowing a monetary transaction only up to a l imit.</t>
<t>The security model and goal for attestation are unique and are not the <t>The security model and goal for attestation are unique and are not the
same as for other security standards like those for server authentication, user same as those for other security standards such as server authentication, user a
authentication and secured messaging. uthentication, and secured messaging.
To give an example of one aspect of the difference, consider the association and To give an example of one aspect of the difference, consider the association and
life-cycle of key material. life cycle of key material.
For authentication, keys are associated with a user or service and set up by act For authentication, keys are associated with a user or service and are set up by
ions performed by a user or an operator of a service. actions performed by a user or an operator of a service.
For attestation, the keys are associated with specific devices and are configure For attestation, the keys are associated with specific devices and are configure
d by device manufacturers. d by device manufacturers. Since the reader is assumed to be familiar with the g
The reader is assumed to be familiar with the goals and security model for attes oals and security model for attestation as described in "Remote ATtestation proc
tation as described in RATS Architecture <xref target="RFC9334"/> and are not re edureS (RATS) Architecture" <xref target="RFC9334"/>, they are not repeated here
peated here.</t> .</t>
<t>This document defines some common claims that are potentially of broad use. <t>This document defines some common claims that are potentially of broad use.
EAT additionally allows proprietary claims and for further claims to be standard ized. EAT additionally allows proprietary claims and for further claims to be standard ized.
Here are some examples:</t> Here are some examples:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Make and model of manufactured consumer device</t> <t>Make and model of manufactured consumer device</t>
</li> </li>
<li> <li>
<t>Make and model of a chip or processor, particularly for a security- oriented chip</t> <t>Make and model of a chip or processor, particularly for a security- oriented chip</t>
</li> </li>
<li> <li>
<t>Identification and measurement of the software running on a device< /t> <t>Identification and measurement of the software running on a device< /t>
</li> </li>
<li> <li>
<t>Configuration and state of a device</t> <t>Configuration and state of a device</t>
</li> </li>
<li> <li>
<t>Environmental characteristics of a device like its Global Positioni ng Sytem (GPS) location</t> <t>Environmental characteristics of a device such as its Global Positi oning System (GPS) location</t>
</li> </li>
<li> <li>
<t>Formal certifications received</t> <t>Formal certifications received</t>
</li> </li>
</ul> </ul>
<t>EAT is constructed to support a wide range of use cases.</t> <t>EAT is constructed to support a wide range of use cases.</t>
<t>No single set of claims can accommodate all use cases so EAT is constru cted as a framework for defining specific attestation tokens for specific use ca ses. <t>No single set of claims can accommodate all use cases, so EAT is constr ucted as a framework for defining specific attestation tokens for specific use c ases.
In particular, EAT provides a profile mechanism to be able to clearly specify th e claims needed, the cryptographic algorithms that should be used, and other cha racteristics for a particular token and use case. In particular, EAT provides a profile mechanism to be able to clearly specify th e claims needed, the cryptographic algorithms that should be used, and other cha racteristics 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> <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 sign s them with an attestation key. <t>The entity's EAT implementation generates the claims and typically sign s them with an attestation key.
It is responsible for protecting the attestation key. It is responsible for protecting the attestation key.
Some EAT implementations will use components with very high resistance to attack like Trusted Platform Modules or Secure Elements. Some EAT implementations will use components with very high resistance to attack such as Trusted Platform Modules or Secure Elements.
Others may rely solely on simple software defenses.</t> 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>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. <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 CBOR Web Token (CWT) <xref target="RFC8392"/> and JSON Web Token (JWT) <xref target="RFC7519"/> and inherits all their characteristics and their security mechanisms. EAT is built on the CBOR Web Token (CWT) <xref target="RFC8392"/> and JSON Web T oken (JWT) <xref target="RFC7519"/> and inherits all their characteristics and t heir security mechanisms.
Like CWT and JWT, EAT does not imply any message flow.</t> Like CWT and JWT, EAT does not imply any message flow.</t>
<t>Following is a very simple example. <t>The following is a very simple example. It is presented in JSON format
It is JSON format for easy reading, but could also be CBOR. for easy reading, but it could also be CBOR.
Only the Claims-Set, the payload for the JWT, is shown.</t> Only the Claims-Set, the payload for the JWT, is shown.</t>
<artwork><![CDATA[
<sourcecode type="json"><![CDATA[
{ {
"eat_nonce": "MIDBNH28iioisjPy", "eat_nonce": "MIDBNH28iioisjPy",
"ueid": "AgAEizrK3Q", "ueid": "AgAEizrK3Q",
"oemid": 76543, "oemid": 76543,
"swname": "Acme IoT OS", "swname": "Acme IoT OS",
"swversion": "3.1.4" "swversion": "3.1.4"
} }]]></sourcecode>
]]></artwork>
<!--[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. <t>This example has a nonce for freshness.
This nonce is the base64url encoding of a 12 byte random binary byte string. This nonce is the base64url encoding of a 12-byte random binary byte strin
The ueid is effectively a serial number uniquely identifying the device. g. The ueid (Universal Entity ID) is effectively a serial number uniquely identi
This ueid is the base64url encoding of a 48-bit MAC address preceded by the type fying the device.
byte 0x02. This ueid is the base64url encoding of a 48-bit Media Access Control (MAC) addre
The oemid identifies the manufacturer using a Private Enterprise Number <xref ta ss preceded by the type byte 0x02. The oemid (Hardware OEM ID) identifies the ma
rget="PEN"/>. nufacturer using a Private Enterprise Number (PEN) <xref target="PEN"/>.
The software is identified by a simple string name and version. 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> It could be identified by a full manifest, but this is a minimal example.</t>
<section anchor="entity-overview"> <section anchor="entity-overview">
<name>Entity Overview</name> <name>Entity Overview</name>
<t>This document uses the term "entity" to refer to the target of an EAT . <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. 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 <xr ef target="RFC9334"/>.</t> An entity is equivalent to a target environment in an attester as defined in <xr ef target="RFC9334"/>.</t>
<t>Layered attestation and composite devices, as described in <xref targ et="RFC9334"/>, are supported by a submodule mechanism (see <xref target="submod s"/>). <t>Layered attestation and composite devices, as described in <xref targ et="RFC9334"/>, are supported by a submodule mechanism (see <xref target="submod s"/>).
Submodules allow nesting of EATs and of claims-sets so that such hierarchies can be modeled.</t> 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 Inte rnet Security Glossary <xref target="RFC4949"/>.</t> <t>An entity is the same as a "system component", as defined in the Inte rnet Security Glossary <xref target="RFC4949"/>.</t>
<t>Note that <xref target="RFC4949"/> defines "entity" and "system enti ty" as synonyms, and that they may be a person or organization in addition to be ing a system component. <t>Note that <xref target="RFC4949"/> defines "entity" and "system entit y" as synonyms, and that they may be a person or organization in addition to bei ng a system component.
In the EAT context, "entity" never refers to a person or organization. In the EAT context, "entity" never refers to a person or organization.
The hardware and software that implement a web site server or service may be an entity in the EAT sense, but the organization that operates, maintains or hosts the web site is not an entity.</t> The hardware and software that implement a website server or service may be an e ntity in the EAT sense, but the organization that operates, maintains, or hosts the website is not an entity.</t>
<t>Some examples of entities:</t> <t>Some examples of entities:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A Secure Element</t> <t>A Secure Element</t>
</li> </li>
<li> <li>
<t>A Trusted Execution Environment (TEE)</t> <t>A Trusted Execution Environment (TEE)</t>
</li> </li>
<li> <li>
<t>A network card in a router</t> <t>A network card in a router</t>
</li> </li>
<li> <li>
<t>A router, perhaps with each network card in the router a submodul e</t> <t>A router, perhaps with each network card in the router being a su bmodule</t>
</li> </li>
<li> <li>
<t>An Internet of Things (IoT) device</t> <t>An IoT device</t>
</li> </li>
<li> <li>
<t>An individual process</t> <t>An individual process</t>
</li> </li>
<li> <li>
<t>An app on a smartphone</t> <t>An app on a smartphone</t>
</li> </li>
<li> <li>
<t>A smartphone with many submodules for its many subsystems</t> <t>A smartphone with many submodules for its many subsystems</t>
</li> </li>
<li> <li>
<t>A subsystem in a smartphone like the modem or the camera</t> <t>A subsystem in a smartphone such as the modem or the camera</t>
</li> </li>
</ul> </ul>
<t>An entity may have strong security defenses against hardware invasive <t>An entity may have strong security defenses against hardware-invasive
attacks. attacks.
It may also have low security, having no special security defenses. It may also have low security, i.e., having no special security defenses.
There is no minimum security requirement to be an entity.</t> There is no minimum security requirement to be an entity.</t>
</section> </section>
<section anchor="eat-as-a-framework"> <section anchor="eat-as-a-framework">
<name>EAT as a Framework</name> <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 c ases, not a specific token definition. <t>EAT is a framework for defining attestation tokens for specific use c ases, not a specific token definition.
While EAT is based on and compatible with CWT and JWT, it can also be described as:</t> While EAT is based on and compatible with CWT and JWT, it can also be described as:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>An identification and type system for claims in claims-sets</t> <t>An identification and type system for claims in claims-sets</t>
</li> </li>
<li> <li>
<t>Definitions of common attestation-oriented claims</t> <t>Definitions of common attestation-oriented claims</t>
</li> </li>
<li> <li>
<t>Claims defined in CDDL and serialized using CBOR or JSON</t> <t>Claims defined in Concise Data Definition Language (CDDL) and ser ialized using CBOR or JSON</t>
</li> </li>
<li> <li>
<t>Security envelopes based on CBOR Object Signing and Encryption (C OSE) and Javascript Object Signing and Encryption (JOSE)</t> <t>Security envelopes based on CBOR Object Signing and Encryption (C OSE) and JSON Object Signing and Encryption (JOSE)</t>
</li> </li>
<li> <li>
<t>Nesting of claims sets and tokens to represent complex and compou nd devices</t> <t>The nesting of claims sets and tokens to represent complex and co mpound devices</t>
</li> </li>
<li> <li>
<t>A profile mechanism for specifying and identifying specific token s for specific use cases</t> <t>A profile mechanism for specifying and identifying specific token s for specific use cases</t>
</li> </li>
</ul> </ul>
<t>EAT uses the name/value pairs the same as CWT and JWT to identify ind
ividual claims. <t>EAT uses name/value pairs to identify individual claims the same way
<xref target="theclaims"/> defines common attestation-oriented claims that are a as CWT and JWT. <xref target="theclaims"/> defines common attestation-oriented c
dded to the CWT and JWT IANA registries. laims that have been added to the "CBOR Web Token (CWT) Claims" and "JSON Web To
As with CWT and JWT, no claims are mandatory and claims not recognized should be ken Claims" IANA registries. As with CWT and JWT, no claims are mandatory and cl
ignored.</t> aims not recognized should be ignored.</t>
<t>Unlike, but compatible with CWT and JWT, EAT defines claims using Con <t>Unlike (but compatible with) CWT and JWT, EAT defines claims using CD
cise Data Definition Language (CDDL) <xref target="RFC8610"/>. DL <xref target="RFC8610"/>.
In most cases the same CDDL definition is used for both the CBOR/CWT serializati In most cases, the same CDDL definition is used for both the CBOR/CWT serializat
on and the JSON/JWT serialization.</t> ion and the JSON/JWT serialization.</t>
<t>Like CWT and JWT, EAT uses COSE and JOSE to provide authenticity, int <t>Like CWT and JWT, EAT uses COSE and JOSE to provide authenticity, int
egrity and optionally confidentiality. egrity, and optionally confidentiality.
EAT places no new restrictions on cryptographic algorithms, retaining all the cr EAT places no new restrictions on cryptographic algorithms, retaining all the cr
yptographic flexibility of CWT, COSE, JWT and JOSE.</t> yptographic flexibility of CWT, COSE, 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. <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 enclosi ng token. Tokens with security envelopes or bare claims sets may be embedded in an enclosi ng 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> 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 f rom a security-enveloped EAT that contains a digest of the detached claims set.< /t> <t>EAT adds the ability to detach claims sets and send them separately f rom 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 identificat <t>This document registers no media or content types for the identificat
ion of the type of EAT, its serialization encoding or security envelope. ion of the EAT type, serialization encoding, or security envelope.
The definition and registration of EAT media types is addressed in <xref target= The definition and registration of EAT media types are addressed in <xref
"I-D.ietf-rats-eat-media-type"/>.</t> target="I-D.ietf-rats-eat-media-type"/>.</t>
<t>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 <!--[rfced] Sections 1.2 and 4.2.18. The term "follow-on documents"
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 o
f narrowed definitions of EATs for specific use cases in follow-on documents is
introduced.
One basic profile for constrained devices is normatively defined.</t> One basic profile for constrained devices is normatively defined.</t>
</section> </section>
<section anchor="operating-model-and-rats-architecture"> <section anchor="operating-model-and-rats-architecture">
<name>Operating Model and RATS Architecture</name> <name>Operating Model and RATS Architecture</name>
<t>EAT follows the operational model described in Figure 1 in RATS Archi tecture <xref target="RFC9334"/>. <t>EAT follows the operational model described in Figure 1 of RATS Archi tecture (<xref target="RFC9334" sectionFormat="of" section="3"/>).
To summarize, an attester generates evidence in the form of a claims set describ ing various characteristics of an entity. To summarize, an attester generates evidence in the form of a claims set describ ing various characteristics of an entity.
Evidence is usually signed by a key that proves the attester and the evidence it produces are authentic. 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 assu re freshness.</t> The claims set either includes a received nonce or uses some other means to assu re freshness.</t>
<t>A verifier confirms an EAT is valid by verifying the signature and ma y vet some claims using reference values. <t>A verifier confirms an EAT is valid by verifying the signature and ma y vet some claims using reference values.
The verifier then produces attestation results, which may also be represented as an EAT. 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 The attestation results are provided to the relying party, which is the ultimate
consumer of the Remote Attestation Procedure. consumer of the RAT.
The relying party uses the attestation results as needed for its use case, perha The relying party uses the attestation results as needed for its use case, perha
ps allowing an entity to access a network, allowing a financial transaction or s ps allowing an entity to access a network, a financial transaction, or such.
uch.
In some cases, the verifier and relying party are not distinct entities.</t> In some cases, the verifier and relying party are not distinct entities.</t>
<section anchor="relationship"> <section anchor="relationship">
<name>Relationship between Evidence and Attestation Results</name> <name>Relationship between Evidence and Attestation Results</name>
<t>Any claim defined in this document or in the IANA CWT or JWT regist <t>Any claim defined in this document or in the IANA "CBOR Web Token (
ry may be used in evidence or attestation results. The relationship of claims in CWT) Claims" or "JSON Web Token Claims" registries may be used in evidence or at
attestation results to evidence is fundamentally governed by the verifier and t testation results. The relationship of claims in attestation results to evidence
he verifier's policy.</t> 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 che <t>A common use case is for the verifier and its policy to perform che
cks, calculations and processing with evidence as the input to produce a summary cks, calculations, and processing with evidence as the input to produce a summar
result in attestation results that indicates the overall health and status of t y result in attestation results that indicates the overall health and status of
he entity. the entity.
For example, measurements in evidence may be compared to reference values the re For example, measurements in evidence may be compared to reference values, the r
sults of which are represented as a simple pass/fail in attestation results.</t> esults of which are represented as a simple pass/fail in attestation results.</t
<t>It is also possible that some claims in the Evidence will be forwar >
ded unmodified to the relying party in attestation results. <t>It is also possible that some claims in the evidence will be forwar
ded unmodified to the relying party in attestation results.
This forwarding is subject to the verifier's implementation and policy. 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 i t has performed on claims it forwards.</t> The relying party should be aware of the verifier's policy to know what checks i t has performed on claims it forwards.</t>
<t>The verifier may modify claims it forwards, for example, to impleme nt a privacy preservation functionality. It is also possible the verifier will p ut claims in the attestation results that give details about the entity that it has computed or looked up in a database. <t>The verifier may modify claims it forwards, for example, to impleme nt a privacy preservation functionality. It is also possible the verifier will p ut 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 based on a "ueid" claim (e.g., serial number) i t received in evidence.</t> For example, the verifier may be able to put an "oemid" claim in the attestation results by performing a 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 v erifier to follow, as these are a matter of local policy. <t>This specification does not establish any normative rules for the v erifier to follow, as these are a matter of local policy.
It is up to each relying party to understand the processing rules of each verifi er to know how to interpret claims in attestation results.</t> It is up to each relying party to understand the processing rules of each verifi er to know how to interpret claims in attestation results.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here. when, and only when, they appear in all capitals, as shown here.
</t> </t>
<t>In this document, the structure of data is specified in CDDL <xref targ et="RFC8610"/> <xref target="RFC9165"/>.</t> <t>In this document, the structure of data is specified in CDDL <xref targ et="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 sec tion="G" sectionFormat="of" target="RFC8610"/>.</t> <t>The examples in <xref target="examples"/> use CBOR diagnostic notation defined in <xref section="8" sectionFormat="of" target="RFC8949"/> and <xref sec tion="G" sectionFormat="of" target="RFC8610"/>.</t>
<t>This document reuses terminology from JWT <xref target="RFC7519"/> and CWT <xref target="RFC8392"/>:</t> <t>This document reuses terminology from JWT <xref target="RFC7519"/> and CWT <xref target="RFC8392"/>:</t>
<!--[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> <dl>
<dt>base64url-encoded:</dt> <dt>base64url encoded:</dt>
<dd> <dd>
<t>base64url-encoded is as described in <xref target="RFC7515"/>, i.e. , using URL- and filename-safe character set <xref target="RFC4648"/> with all t railing '=' characters omitted and without the inclusion of any line breaks, whi tespace, or other additional characters.</t> <t>As described in <xref target="RFC7515"/>, i.e., using a URL- and fi lename-safe character set <xref target="RFC4648"/> with all trailing '=' charact ers omitted and without the inclusion of any line breaks, whitespace, or other a dditional characters.</t>
</dd> </dd>
<dt>Claim:</dt> <dt>Claim:</dt>
<dd> <dd>
<t>A piece of information asserted about a subject. A claim is represe nted as a value and either a name or key to identify it.</t> <t>A piece of information asserted about a subject. A claim is represe nted as a value and either a name or a key to identify it.</t>
</dd> </dd>
<dt>Claim Name:</dt> <dt>Claim Name:</dt>
<dd> <dd>
<t>A unique text string that identifies the claim. It is used as the c laim name for JSON encoding.</t> <t>A unique text string that identifies the claim. It is used as the c laim name for JSON encoding.</t>
</dd> </dd>
<dt>Claim Key:</dt> <dt>Claim Key:</dt>
<dd> <dd>
<t>The CBOR map key used to identify a claim. (The term "Claim Key" co
mes from CWT. This document, like COSE, uses the term "label" to refer to CBOR m <!--[rfced] Section 2. We added a citation to RFC 9052 for "COSE" for easy
ap keys to avoid confusion with cryptographic keys.)</t> 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" co
mes 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> </dd>
<dt>Claim Value:</dt> <dt>Claim Value:</dt>
<dd> <dd>
<t>The value portion of the claim. A claim value can be any CBOR data item or JSON value.</t> <t>The value portion of the claim. A claim value can be any CBOR data item or JSON value.</t>
</dd> </dd>
<dt>Claims Set:</dt> <dt>Claims Set:</dt>
<dd> <dd>
<t>The CBOR map or JSON object that contains the claims conveyed by th e CWT or JWT.</t> <t>The CBOR map or JSON object that contains the claims conveyed by th e CWT or JWT.</t>
</dd> </dd>
</dl> </dl>
<t>This document reuses terminology from RATS Architecure <xref target="RF C9334"/>:</t> <t>This document reuses terminology from RATS Architecture <xref target="R FC9334"/>:</t>
<dl> <dl>
<dt>Attester:</dt> <dt>Attester:</dt>
<dd> <dd>
<t>A role performed by an entity (typically a device) whose evidence m ust be appraised in order to infer the extent to which the attester is considere d trustworthy, such as when deciding whether it is authorized to perform some op eration.</t> <t>A role performed by an entity (typically a device) whose evidence m ust be appraised in order to infer the extent to which the attester is considere d trustworthy, such as when deciding whether it is authorized to perform some op eration.</t>
</dd> </dd>
<dt>Verifier:</dt> <dt>Verifier:</dt>
<dd> <dd>
<t>A role that appraises the validity of evidence about an attester an d produces attestation results to be used by a relying party.</t> <t>A role that appraises the validity of evidence about an attester an d produces attestation results to be used by a relying party.</t>
</dd> </dd>
<dt>Relying Party:</dt> <dt>Relying Party:</dt>
<dd> <dd>
<t>A role that depends on the validity of information about an atteste r, for purposes of reliably applying application specific actions. Compare /rely ing party/ in <xref target="RFC4949"/>.</t> <t>A role that depends on the validity of information about an atteste r for purposes of reliably applying application-specific actions. For comparison , see "relying party" in <xref target="RFC4949"/>.</t>
</dd> </dd>
<dt>Evidence:</dt> <dt>Evidence:</dt>
<dd> <dd>
<t>A set of claims generated by an attester to be appraised by a verif ier. Evidence may include configuration data, measurements, telemetry, or infere nces.</t> <t>A set of claims generated by an attester to be appraised by a verif ier. Evidence may include configuration data, measurements, telemetry, or infere nces.</t>
</dd> </dd>
<dt>Attestation Results:</dt> <dt>Attestation Results:</dt>
<dd> <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> <t>The output generated by a verifier, typically including information about an attester, where the verifier vouches for the validity of the results.< /t>
</dd> </dd>
<dt>Reference Values:</dt> <dt>Reference Values:</dt>
<dd> <dd>
<t>A set of values against which values of claims can be compared as p art of applying an appraisal policy for evidence. Reference Values are sometime s referred to in other documents as known-good values, golden measurements, or n ominal values, although those terms typically assume comparison for equality, wh ereas here reference values might be more general and be used in any sort of com parison.</t> <t>A set of values against which values of claims can be compared as p art of applying an appraisal policy for evidence. Reference values are sometime s referred to in other documents as "known-good values", "golden measurements", or "nominal values", although those terms typically assume comparison for equali ty whereas reference values in this document might be more general and used in a ny sort of comparison.</t>
</dd> </dd>
<dt>Endorsement:</dt> <dt>Endorsement:</dt>
<dd> <dd>
<t>A secure statement that an Endorser vouches for the integrity of an attester's various capabilities such as claims collection and evidence signing. </t> <t>A secure statement that an endorser vouches for the integrity of an attester's various capabilities such as claims collection and evidence signing. </t>
</dd> </dd>
</dl> </dl>
<t>This document reuses terminology from CDDL <xref target="RFC8610"/>:</t > <t>This document reuses terminology from CDDL <xref target="RFC8610"/>:</t >
<dl> <dl>
<dt>Group Socket:</dt> <dt>Group Socket:</dt>
<dd> <dd>
<t>refers to the mechanism by which a CDDL definition is extended, as described in <xref target="RFC8610"/> and <xref target="RFC9165"/></t> <t>The mechanism by which a CDDL definition is extended, as described in <xref target="RFC8610"/> and <xref target="RFC9165"/>.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="top-level-token-definition"> <section anchor="top-level-token-definition">
<name>Top-Level Token Definition</name> <name>Top-Level Token Definition</name>
<t>An "EAT" is an encoded (serialized) message the purpose of which is to transfer a Claims-Set between two parties. <t>An "EAT" is an encoded (serialized) message, the purpose of which is to transfer a Claims-Set between two parties.
An EAT <bcp14>MUST</bcp14> contain a Claims-Set. An EAT <bcp14>MUST</bcp14> contain a Claims-Set.
In this document an EAT is always a CWT or JWT.</t> In this document, an EAT is always a CWT or JWT.</t>
<t>An EAT <bcp14>MUST</bcp14> have authenticity and integrity protection. <t>An EAT <bcp14>MUST</bcp14> have authenticity and integrity protection.
CWT and JWT provide that in this document.</t> CWT and JWT provide that in this document.</t>
<t>Further documents may define other encodings and security mechanims for EAT.</t> <t>Further documents may define other encodings and security mechanisms fo r EAT.</t>
<t>The identification of a protocol element as an EAT follows the general conventions used for CWTs and JWTs. <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. Identification depends on the protocol carrying the EAT.
In some cases it may be by media type (e.g., in a HTTP Content-Type field). In some cases, it may be by media type (e.g., in an HTTP Content-Type field).
In other cases it may be through use of CBOR tags. In other cases, it may be through use of CBOR tags.
There is no fixed mechanism across all use cases.</t> There is no fixed mechanism across all use cases.</t>
<t>This document also defines another message, the detached EAT bundle (se e <xref target="DEB"/>), which holds a collection of detached claims sets and an EAT that provides integrity and authenticity protection for them. <t>This document also defines another message, the detached EAT bundle (se e <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> 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 <t>The following CDDL defines the top-level <tt>$EAT-CBOR-Tagged-Token</tt
>, <tt>$EAT-CBOR-Untagged-Token</tt> and <tt>$EAT-JSON-Token-Formats</tt> socket >, <tt>$EAT-CBOR-Untagged-Token</tt>, and <tt>$EAT-JSON-Token-Formats</tt> socke
s (see <xref section="3.9" sectionFormat="of" target="RFC8610"/>), enabling futu ts (see <xref section="3.9" sectionFormat="of" target="RFC8610"/>), enabling fut
re token formats to be defined. ure token formats to be defined.
Any new format that plugs into one or more of these sockets <bcp14>MUST</bcp14> Any new format that plugs into one or more of these sockets <bcp14>MUST</bcp14>
be defined by an IETF standards action. be defined by an IETF Standards Action <xref target="RFC8126"/>.
Of particular use may be a token type that provides no direct authenticity or in Of particular use may be a token type that provides no direct authenticity or in
tegrity protection for use with transports mechanisms that do provide the necess tegrity protection for use with transport mechanisms that do provide the necessa
ary security services <xref target="I-D.ietf-rats-uccs"/>.</t> ry security services <xref target="I-D.ietf-rats-uccs"/>.</t>
<t>Nesting of EATs is allowed and defined in <xref target="Nested-Token"/> . <t>Nesting of EATs is allowed and defined in <xref target="Nested-Token"/> .
This includes the nesting of an EAT that is a different format than the enclosin g EAT, i.e., the nested EAT may be encoded using CBOR and the enclosing EAT enco ded using JSON or vice versa. This includes the nesting of an EAT that is in a different format than the enclo sing EAT, i.e., the nested EAT may be encoded using CBOR and the enclosing EAT e ncoded using JSON or vice versa.
The definition of Nested-Token references the CDDL defined in this section. 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 tok en <bcp14>MUST</bcp14> also be defined.</t> When new token formats are defined, the means for identification in a nested tok en <bcp14>MUST</bcp14> also be defined.</t>
<t>The top-level CDDL type for CBOR-encoded EATs is EAT-CBOR-Token and for JSON is EAT-JSON-Token (while CDDL and CDDL tools provide enough support for sh ared definitions of most items in this document, they do not provide enough supp ort for this sharing at the top level).</t> <t>The top-level CDDL type for CBOR-encoded EATs is EAT-CBOR-Token and for JSON-encoded EATs is EAT-JSON-Token (while CDDL and CDDL tools provide enough s upport for shared definitions of most items in this document, they do not provid e enough support for this sharing at the top level).</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
EAT-CBOR-Token = $EAT-CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token EAT-CBOR-Token = $EAT-CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token
$EAT-CBOR-Tagged-Token /= CWT-Tagged-Message $EAT-CBOR-Tagged-Token /= CWT-Tagged-Message
$EAT-CBOR-Tagged-Token /= BUNDLE-Tagged-Message $EAT-CBOR-Tagged-Token /= BUNDLE-Tagged-Message
$EAT-CBOR-Untagged-Token /= CWT-Untagged-Message $EAT-CBOR-Untagged-Token /= CWT-Untagged-Message
$EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message $EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message]]></sourcecode>
]]></sourcecode>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
EAT-JSON-Token = $EAT-JSON-Token-Formats EAT-JSON-Token = $EAT-JSON-Token-Formats
$EAT-JSON-Token-Formats /= JWT-Message $EAT-JSON-Token-Formats /= JWT-Message
$EAT-JSON-Token-Formats /= BUNDLE-Untagged-Message $EAT-JSON-Token-Formats /= BUNDLE-Untagged-Message]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="theclaims"> <section anchor="theclaims">
<name>The Claims</name> <name>The Claims</name>
<t>This section describes new claims defined for attestation that are to b <t>This section describes new claims defined for attestation that have bee
e added to the CWT <xref target="IANA.CWT.Claims"/> and JWT <xref target="IANA.J n added to the IANA "CBOR Web Token (CWT) Claims" <xref target="IANA.CWT.Claims"
WT.Claims"/> IANA registries.</t> /> and "JSON Web Token Claims" <xref target="IANA.JWT.Claims"/> registries.</t>
<t>All definitions, requirements, creation and validation procedures, secu <t>All definitions, requirements, creation and validation procedures, secu
rity considerations, IANA registrations and so on from CWT and JWT carry over to rity considerations, IANA registrations, and so on from CWT and JWT carry over t
EAT.</t> o EAT.</t>
<t>This section also describes how several extant CWT and JWT claims apply in 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 co ntext dependent and is outside the scope of this specification. <t>The set of claims that an EAT must contain to be considered valid is co ntext dependent and is outside the scope of this specification.
Specific applications of EATs will require implementations to understand and pro cess some claims in particular ways. Specific applications of EATs will require implementations to understand and pro cess 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> 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 <t>CDDL, along with a text description, is used to define each claim
independent of encoding. Each claim is defined as a CDDL group. independent of encoding. Each claim is defined as a CDDL group.
In <xref target="encoding"/> on encoding, the CDDL groups turn into CBOR map ent ries and JSON name/value pairs.</t> In <xref 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-Cl aims</tt> group socket. Claims defined by other specifications <bcp14>MUST</bcp1 4> also be added to the <tt>$$Claims-Set-Claims</tt> group socket.</t> <t>Each claim defined in this document is added to the <tt>$$Claims-Set-Cl aims</tt> group socket. Claims defined by other specifications <bcp14>MUST</bcp1 4> 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 w <t>All claims in an EAT <bcp14>MUST</bcp14> use the same encoding except w
here otherwise explicitly stated (e.g., in a CBOR-encoded token, all claims must here otherwise explicitly stated (e.g., in a CBOR-encoded token, all claims must
be CBOR-encoded).</t> be encoded with CBOR).</t>
<t>This specification includes a CDDL definition of most of what is define
d in <xref target="RFC8392"/>. <!--[rfced] Section 4. Can "of most of what is defined" be rephrased
Similarly, this specification includes CDDL for most of what is defined in <xref for clarity as shown below?
target="RFC7519"/>.
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 define
d in <xref target="RFC8392"/>. Similarly, this specification includes CDDL for m
ost of what is defined in <xref target="RFC7519"/>.
These definitions are in <xref target="CDDL_for_CWT"/> and are not normative.</t > 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 identifi es it. <t>Each claim described has a unique text string and integer that identifi es it.
CBOR-encoded tokens <bcp14>MUST</bcp14> use only the integer for claim keys. CBOR-encoded tokens <bcp14>MUST</bcp14> only use the integer for claim keys.
JSON-encoded tokens <bcp14>MUST</bcp14> use only the text string for claim names JSON-encoded tokens <bcp14>MUST</bcp14> only use the text string for claim names
.</t> .</t>
<section anchor="nonce"> <section anchor="nonce">
<name>eat_nonce (EAT Nonce) Claim</name> <name>eat_nonce (EAT Nonce) Claim</name>
<t>An EAT nonce is either a byte or text string or an array of byte or t <t>An EAT nonce is either a byte, a text string, or an array of bytes or
ext strings. text strings.
The array option supports multistage EAT verification and consumption.</t> The array option supports multistage EAT verification and consumption.</t
<t>A claim named "nonce" was defined and registered with IANA for JWT, b >
ut <bcp14>MUST NOT</bcp14> be used because it does not support multiple nonces.
No previous "nonce" claim was defined for CWT. <t>A claim named "nonce" was defined for JWT and registered with IANA in
the "JSON Web Token Claims" registry, but it <bcp14>MUST NOT</bcp14> be used be
cause 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 name d "eat_nonce" in JSON-encoded EATs. The CWT nonce defined To distinguish from the previously defined JWT "nonce" claim, this claim is name d "eat_nonce" in JSON-encoded EATs. The CWT nonce defined
here is intended for general purpose use and retains the "Nonce" claim name inst ead of an EAT-specific name.</t> here is intended for general purpose use and retains the "Nonce" claim name inst ead of an EAT-specific name.</t>
<t>An EAT nonce <bcp14>MUST</bcp14> have at least 64 bits of entropy. <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 implementati on. A maximum EAT nonce size is set to limit the memory required for an implementati on.
All receivers <bcp14>MUST</bcp14> be able to accommodate the maximum size.</t> 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 leng th. <t>In CBOR, an EAT nonce is a byte string between 8 and 64 bytes in leng th.
In JSON, an EAT nonce is a text string between 8 and 88 bytes in length.</t> In JSON, an EAT nonce is a text string between 8 and 88 bytes in length.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= $$Claims-Set-Claims //=
(nonce-label => nonce-type / [ 2* nonce-type ]) (nonce-label => nonce-type / [ 2* nonce-type ])
nonce-type = JC< tstr .size (8..88), bstr .size (8..64)> nonce-type = JC< tstr .size (8..88), bstr .size (8..64)>]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="claims-describing-the-entity"> <section anchor="claims-describing-the-entity">
<name>Claims Describing the Entity</name> <name>Claims Describing the Entity</name>
<t>The claims in this section describe the entity itself. <t>The claims in this section describe the entity itself.
They describe the entity whether they occur in evidence or occur in attestation results. They describe the entity whether they occur in evidence or occur in attestation results.
See <xref target="relationship"/> for discussion on how attestation results rela te to evidence.</t> See <xref target="relationship"/> for discussion on how attestation results rela te to evidence.</t>
<section anchor="UEID"> <section anchor="UEID">
<name>ueid (Universal Entity ID) Claim</name> <name>ueid (Universal Entity ID) Claim</name>
<t>The "ueid" claim conveys a UEID, which identifies an individual man <t>The "ueid" claim conveys a UEID, which identifies an individual man
ufactured entity like a ufactured entity such as a mobile phone, water meter, Bluetooth speaker, or netw
mobile phone, a water meter, a Bluetooth speaker or a networked orked
security camera. It may identify the entire entity or a submodule. security camera. It may identify the entire entity or a submodule.
It does not identify types, models or classes of It does not identify types, models, or classes of
entities. It is akin to a serial number, though it does not have to be entities. It is akin to a serial number, though it does not have to be
sequential.</t> sequential.</t>
<t>UEIDs <bcp14>MUST</bcp14> be universally and globally unique across manufacturers <t>UEIDs <bcp14>MUST</bcp14> be universally and globally unique across manufacturers
and countries, as described in <xref target="UEIDCreateRules"/>. UEIDs <bcp14>MU ST</bcp14> also be unique across protocols and systems, and countries, as described in <xref target="UEIDCreateRules"/>. UEIDs <bcp14>MU ST</bcp14> also be unique across protocols and systems,
as tokens are intended to be embedded in many different protocols and as tokens are intended to be embedded in many different protocols and
systems. No two products anywhere, even in completely different systems. No two products anywhere, even in completely different
industries made by two different manufacturers in two different industries made by two different manufacturers in two different
countries should have the same UEID (if they are not global and countries, should have the same UEID (if they are not global and
universal in this way, then relying parties receiving them will have universal in this way, then relying parties receiving them will have
to track other characteristics of the entity to keep entities distinct to track other characteristics of the entity to keep entities distinct
between manufacturers).</t> between manufacturers).</t>
<t>UEIDs are not designed for direct use by humans (e.g., printing on <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> the case of a device), so no such representation is defined.</t>
<t>There are privacy considerations for UEIDs. See <xref target="ueidp rivacyconsiderations"/>.</t> <t>There are privacy considerations for UEIDs. See <xref target="ueidp rivacyconsiderations"/>.</t>
<t>A Device Identifier URN is registered for UEIDs. See <xref target=" <t>A Device Identifier (DevID) URN is registered for UEIDs. See <xref
registerueidurn"/>.</t> target="registerueidurn"/>.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (ueid-label => ueid-type) $$Claims-Set-Claims //= (ueid-label => ueid-type)
ueid-type = JC<base64-url-text .size (10..44) , bstr .size (7..33)> ueid-type = JC<base64-url-text .size (10..44) , bstr .size (7..33)>]]></sourceco
]]></sourcecode> de>
<section anchor="UEIDCreateRules"> <section anchor="UEIDCreateRules">
<name>Rules for Creating UEIDs</name> <name>Rules for Creating UEIDs</name>
<t>These rules are solely for the creation of UEIDs. <t>These rules are solely for the creation of UEIDs.
The EAT consumer need not have any awareness of them.</t> The EAT consumer need not have any awareness of them.</t>
<t>A UEID is constructed of a single type byte followed by the uniqu e bytes for that type. <t>A UEID is constructed of a single type byte followed by the uniqu e bytes for that type.
The type byte assures global uniqueness of a UEID even if the unique bytes for d ifferent types are accidentally the same.</t> The type byte assures global uniqueness of a UEID even if the unique bytes for d ifferent types are accidentally the same.</t>
<t>UEIDS are variable length to accommodate the types defined here a nd future-defined types.</t> <t>UEIDS are of variable length to accommodate the types defined her e as well as future-defined types.</t>
<t>UEIDs <bcp14>SHOULD NOT</bcp14> be longer than 33 bytes. <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. If they are longer, there is no guarantee that a receiver will be able to accept them.
See <xref target="UEID-Design"/>.</t> See <xref target="UEID-Design"/>.</t>
<t>A UEID is permanent. It <bcp14>MUST NOT</bcp14> change for a give n entity.</t> <t>A UEID is permanent. It <bcp14>MUST NOT</bcp14> change for a give n entity.</t>
<t>The different types of UEIDs 1) accommodate different manufacturi <t>The different types of UEIDs 1) accommodate different manufacturi
ng processes, 2) accommodate small UEIDs, 3) provide an option that does not req ng processes, 2) accommodate small UEIDs, and 3) provide an option that does not
uire registration fees and central administration.</t> require registration fees and central administration.</t>
<t>In the unlikely event that a new UEID type is needed, it <bcp14>M <t>In the unlikely event that a new UEID type is needed, it <bcp14>M
UST</bcp14> be defined in a standards-track update to this document.</t> UST</bcp14> be defined in an update to this document on the Standards Track.</t>
<t>A manufacturer of entities <bcp14>MAY</bcp14> use different types for different products. <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 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.</ or use one type for some items of a given product and another type for others.<
t> /t>
<table anchor="ueid-types-table"> <table align="left" anchor="ueid-types-table">
<name>UEID Composition Types</name> <name>UEID Composition Types</name>
<thead> <thead>
<tr> <tr>
<th align="left">Type Byte</th> <th align="left">Type Byte</th>
<th align="left">Type Name</th> <th align="left">Type Name</th>
<th align="left">Specification</th> <th align="left">Specification</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0x01</td> <td align="left">0x01</td>
<td align="left">RAND</td> <td align="left">RAND</td>
<td align="left">This is a 128, 192 or 256-bit random number g enerated 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 feed ing the concatenation through a cryptographic hash function. It may also be a cr yptographic 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> <td align="left">This is a 128-, 192-, or 256-bit random numbe r generated once and stored in the entity. This may be constructed by concatenat ing enough identifiers to make up an equivalent number of random bits and then f eeding 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>
<tr> <tr>
<td align="left">0x02</td> <td align="left">0x02</td>
<td align="left">IEEE EUI</td> <td align="left">IEEE EUI</td>
<td align="left">This makes use of the device identification s cheme operated by the IEEE. An EUI is either an EUI-48, EUI-60 or EUI-64 and mad e up of an OUI, OUI-36 or a CID, different registered company identifiers, and s ome unique per-entity identifier. EUIs are often the same as or similar to MAC a ddresses. This type includes MAC-48, an obsolete name for EUI-48. (Note that whi le entities with multiple network interfaces may have multiple MAC addresses, th ere is only one UEID for an entity; changeable MAC addresses that do not meet th e permanence requirements in this document <bcp14>MUST NOT</bcp14> be used for t he UEID or SUEID) <xref target="IEEE.802-2001"/>, <xref target="OUI.Guide"/>.</t d> <td align="left">This makes use of the device identification s cheme operated by the IEEE. An Extended Unique Identifier (EUI) is either an EUI -48, EUI-60, or EUI-64 that is made up of an Organizationally Unique Identifier (OUI), an OUI-36, or a Company ID (CID), which are different registered company identifiers and some unique per-entity identifiers. EUIs are often the same as o r 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 t hat do not meet the permanence requirements in this document <bcp14>MUST NOT</bc p14> be used for the UEID or Semi-permanent UEID (SUEID).) See <xref target="IE EE.802-2001"/> and <xref target="OUI.Guide"/>.</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x03</td> <td align="left">0x03</td>
<td align="left">IMEI</td> <td align="left">IMEI</td>
<td align="left">This makes use of the International Mobile Eq uipment Identity (IMEI) scheme operated by the GSMA. This is a 14-digit identifi er consisting of an 8-digit Type Allocation Code (TAC) and a 6-digit serial numb er allocated by the manufacturer, which <bcp14>SHALL</bcp14> be encoded as 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 <bc p14>SHALL NOT</bcp14> include Luhn checksum or SVN information. See <xref target ="ThreeGPP.IMEI"/>.</td> <td align="left">This makes use of the International Mobile Eq uipment Identity (IMEI) scheme operated by the Global System for Mobile Communic ations Association (GSMA). This is a 14-digit identifier consisting of an 8-digi t Type Allocation Code (TAC) and a 6-digit serial number allocated by the manufa cturer, 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 encoded value <bcp14>SHALL NOT</bcp14> in clude the Luhn checksum or Software Version Number (SVN) information. See <xref target="ThreeGPP.IMEI"/>.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="rules-for-consuming-ueids"> <section anchor="rules-for-consuming-ueids">
<name>Rules for Consuming UEIDs</name> <name>Rules for Consuming UEIDs</name>
<t>For the consumer, a UEID is solely a globally unique opaque ident ifier. <t>For the consumer, a UEID is solely a globally unique opaque ident ifier.
The consumer does not and should not have any awareness of the rules and structu re used to achieve global uniqueness.</t> The consumer does not and should not have any awareness of the rules and structu re used to achieve global uniqueness.</t>
<t>All implementations <bcp14>MUST</bcp14> be able to receive UEIDs up to 33 bytes long. <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> 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 complete ly opaque string of bytes and <bcp14>MUST NOT</bcp14> make any use of its intern al structure. <t>The consumer of a UEID <bcp14>MUST</bcp14> treat it as a complete ly opaque string of bytes and <bcp14>MUST NOT</bcp14> make any use of its intern al structure.
The reasons for this are:</t> The reasons for this are:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>UEIDs types vary freely from one manufacturer to the next.</t > <t>UEID types vary freely from one manufacturer to the next.</t>
</li> </li>
<li> <li>
<t>New types of UEIDs may be defined.</t> <t>New types of UEIDs may be defined.</t>
</li> </li>
<li> <li>
<t>The manufacturer of an entity is allowed to change from one t ype of UEID to another anytime they want.</t> <t>The manufacturer of an entity is allowed to change from one t ype of UEID to another anytime they want.</t>
</li> </li>
</ul> </ul>
<t>For example, when the consumer receives a type 0x02 UEID, they sh ould not use the OUI part to identify the manufacturer of the device because the re is no guarantee all UEIDs will be type 0x02. <t>For example, when the consumer receives a type 0x02 UEID, they sh ould not use the OUI part to identify the manufacturer of the device because the re is no guarantee all UEIDs will be type 0x02.
Different manufacturers may use different types. Different manufacturers may use different types.
A manufacturer may make some of their product with one type and others with a di fferent type or even change to a different type for newer versions of their prod uct. A manufacturer may make some of their product with one type and others with a di fferent type or even change to a different type for newer versions of their prod uct.
Instead, the consumer should use the "oemid" claim.</t> Instead, the consumer should use the "oemid" claim.</t>
</section> </section>
</section> </section>
<section anchor="sueids-semi-permanent-ueids-claim-sueids"> <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> <name>sueids (Semi-permanent UEIDs) Claim (SUEIDs)</name>
<t>The "sueids" claim conveys one or more semi-permanent UEIDs (SUEIDs <t>The "sueids" claim conveys one or more semi-permanent UEIDs (SUEIDs
). An SUEID has the same format, characteristics and requirements as a UEID, but ). An SUEID has the same format, characteristics, and requirements as a UEID but
<bcp14>MAY</bcp14> change to a different value on entity life-cycle events. <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, one or the ot An entity <bcp14>MAY</bcp14> have both a UEID and SUEIDs, neither, or one or the
her.</t> other.</t>
<t>Examples of life-cycle events are change of ownership, factory rese <t>Examples of life-cycle events are change of ownership, factory rese
t and on-boarding into an IoT device management system. t, and onboarding into an IoT device management system.
It is beyond the scope of this document to specify particular types of SUEIDs an d the life-cycle events that trigger their change. It is beyond the scope of this document to specify particular types of SUEIDs an d the life-cycle events that trigger their change.
An EAT profile <bcp14>MAY</bcp14> provide this specification.</t> An EAT profile <bcp14>MAY</bcp14> provide this specification.</t>
<t>There <bcp14>MAY</bcp14> be multiple SUEIDs. <t>There <bcp14>MAY</bcp14> be multiple SUEIDs. Each has a text string
Each has a text string label the purpose of which is to distinguish it from othe label, the purpose of which is to distinguish it from others.
rs. The label <bcp14>MAY</bcp14> name the purpose, application, or type of the SUEID
The label <bcp14>MAY</bcp14> name the purpose, application or type of the SUEID. .
For example, the label for the SUEID used by XYZ Onboarding Protocol could thus For example, the label for the SUEID used by the XYZ Onboarding Protocol could t
be "XYZ". hus be "XYZ". It is beyond the scope of this document to specify any SUEID label
It is beyond the scope of this document to specify any SUEID labeling schemes. ing schemes.
They are use case specific and <bcp14>MAY</bcp14> be specified in an EAT profile .</t> 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>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 <xref tar <t>An SUEID provides functionality similar to an IEEE Local Device Ide
get="IEEE.802.1AR"/>.</t> ntifier (LDevID) <xref target="IEEE.802.1AR"/>.</t>
<t>There are privacy considerations for SUEIDs. See <xref target="ueid <t>There are privacy considerations for SUEIDs; see <xref target="ueid
privacyconsiderations"/>.</t> privacyconsiderations"/>.</t>
<t>A Device Identifier URN is registered for SUEIDs. See <xref target= <t>A DevID URN is registered for SUEIDs; see <xref target="registeruei
"registerueidurn"/>.</t> durn"/>.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (sueids-label => sueids-type) $$Claims-Set-Claims //= (sueids-label => sueids-type)
sueids-type = { sueids-type = {
+ tstr => ueid-type + tstr => ueid-type
} }]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="oemid"> <section anchor="oemid">
<name>oemid (Hardware OEM Identification) Claim</name> <name>oemid (Hardware OEM ID) Claim</name>
<t>The "oemid" claim identifies the Original Equipment Manufacturer (O EM) of the hardware. <t>The "oemid" claim identifies the Original Equipment Manufacturer (O EM) of the hardware.
Any of the three forms described below <bcp14>MAY</bcp14> be used at the conveni ence of the claim sender. Any of the three forms described below <bcp14>MAY</bcp14> be used at the conveni ence of the claim sender.
The receiver of this claim <bcp14>MUST</bcp14> be able to handle all three forms .</t> 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 "oem boot" claim in <xref target="oemboot"/> and "dbgstat" claim in <xref target="dbg stat"/> depend on this claim.</t> <t>Note that the "hwmodel" claim in <xref target="hwmodel"/>, the "oem boot" claim in <xref 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. <t>Sometimes one manufacturer will acquire or merge with another.
Depending on the situation and use case newly manfactured devices may continue t Depending on the situation and use case, newly manufactured devices may continue
o use the old OEM ID or switch to a new one. 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 ho This is left to the discretion of the manufacturers, but they should consider ho
w it affects the above-mentioned claims and the attestation eco-system for their w it affects the above-mentioned claims and the attestation ecosystem for their
devices. devices.
The considerations are the same for all three forms of this claim.</t> The considerations are the same for all three forms of this claim.</t>
<section anchor="random-number-based-oem-id"> <section anchor="random-number-based-oem-id">
<name>Random Number Based OEM ID</name> <name>Random Number-Based OEM ID</name>
<t>The random number based OEM ID <bcp14>MUST</bcp14> be 16 bytes (1 <t>The random number-based OEM ID <bcp14>MUST</bcp14> be 16 bytes (1
28 bits) long.</t> 28 bits) long.</t>
<t>The OEM may create their own ID by using a cryptographic-quality random number generator. <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 sin gle ID for said company. They would perform this only once in the life of the company to generate the sin gle ID for said company.
They would use that same ID in every entity they make. They would use that same ID in every entity they make.
This uniquely identifies the OEM on a statistical basis and is large enough shou ld there be ten billion companies.</t> This uniquely identifies the OEM on a statistical basis and is large enough shou ld there be ten billion companies.</t>
<t>In JSON-encoded tokens this <bcp14>MUST</bcp14> be base64url-enco ded.</t> <t>In JSON-encoded tokens, this <bcp14>MUST</bcp14> be base64url enc oded.</t>
</section> </section>
<section anchor="ieee-based-oem-id"> <section anchor="ieee-based-oem-id">
<name>IEEE Based OEM ID</name> <name>IEEE-Based OEM ID</name>
<t>The IEEE operates a global registry for MAC addresses and company IDs. <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 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 an IEEE CID claim may be either an IEEE MA-L, MA-M, MA-S, or CID <xref target="IEEE-RA"/>.
<xref target="IEEE-RA"/>. An MA-L, formerly known as an OUI, is a 24-bit value An MA-L (formerly known as an OUI) is a 24-bit value
used as the first half of a MAC address. MA-M similarly is a 28-bit used as the first half of a MAC address. Similarly, MA-M is a 28-bit
value uses as the first part of a MAC address, and MA-S, formerly value used as the first part of a MAC address, and MA-S (formerly
known as OUI-36, a 36-bit value. Many companies already have purchased 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 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. 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 one of these. A CID is also a 24-bit value from the same space as an
MA-L, but not for use as a MAC address. IEEE has published Guidelines 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 for Use of EUI, OUI, and CID <xref target="OUI.Guide"/> and provides a lookup
service <xref target="OUI.Lookup"/>.</t> service <xref target="OUI.Lookup"/>.</t>
<t>Companies that have more than one of these IDs or MAC address blo cks <t>Companies that have more than one of these IDs or MAC address blo cks
<bcp14>SHOULD</bcp14> select one and prefer that for all their entities.</t> <bcp14>SHOULD</bcp14> select one as preferred and use that for all their entitie
<t>Commonly, these are expressed in Hexadecimal Representation as de s.</t>
scribed in <t>Commonly, these are expressed in hexadecimal representation as de
<xref target="IEEE.802-2001"/>. It is also called the Canonical format. When thi scribed in
s claim is <xref target="IEEE.802-2001"/>. It is also called the canonical format. When thi
encoded the order of bytes in the bstr are the same as the order in the s claim is
Hexadecimal Representation. For example, an MA-L like "AC-DE-48" would encoded, the order of bytes in the bstr is the same as the order in the
be encoded in 3 bytes with values 0xAC, 0xDE, 0x48.</t> 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>This format is always 3 bytes in size in CBOR.</t>
<t>In JSON-encoded tokens, this <bcp14>MUST</bcp14> be base64url-enc oded and always 4 bytes.</t> <t>In JSON-encoded tokens, this <bcp14>MUST</bcp14> be base64url enc oded and always 4 bytes.</t>
</section> </section>
<section anchor="iana-private-enterprise-number-based-oem-id"> <section anchor="iana-private-enterprise-number-based-oem-id">
<name>IANA Private Enterprise Number Based OEM ID</name> <name>IANA Private Enterprise Number-Based OEM ID</name>
<t>IANA maintains a registry for Private Enterprise Numbers (PEN) <x
ref target="PEN"/>. A PEN is an integer that identifies an enterprise and may be <!--[rfced] Section 4.2.3.3. This sentence cites the application
used to construct an object identifier (OID) relative to the following OID arc t for PENs (https://pen.iana.org/pen/PenApplication.page), so it seems
hat is managed by IANA: iso(1) identified-organization(3) dod(6) internet(1) pr either the text or the reference should be updated. Which do you prefer?
ivate(4) enterprise(1).</t>
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 ta
rget="PEN"/>. A PEN is an integer that identifies an enterprise, and it may be
used to construct an object identifier (OID) relative to the following OID arc t
hat is managed by IANA: iso(1) identified-organization(3) dod(6) internet(1) pri
vate(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>For EAT purposes, only the integer value assigned by IANA as the PEN is relevant, not the full OID value.</t>
<t>In CBOR this value <bcp14>MUST</bcp14> be encoded as a major type 0 integer and is typically 3 bytes. <t>In CBOR, this value <bcp14>MUST</bcp14> be encoded as a major typ e 0 integer and is typically 3 bytes.
In JSON, this value <bcp14>MUST</bcp14> be encoded as a number.</t> In JSON, this value <bcp14>MUST</bcp14> be encoded as a number.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= ( $$Claims-Set-Claims //= (
oemid-label => oemid-pen / oemid-ieee / oemid-random oemid-label => oemid-pen / oemid-ieee / oemid-random
) )
oemid-pen = int oemid-pen = int
oemid-ieee = JC<oemid-ieee-json, oemid-ieee-cbor> oemid-ieee = JC<oemid-ieee-json, oemid-ieee-cbor>
oemid-ieee-cbor = bstr .size 3 oemid-ieee-cbor = bstr .size 3
oemid-ieee-json = base64-url-text .size 4 oemid-ieee-json = base64-url-text .size 4
oemid-random = JC<oemid-random-json, oemid-random-cbor> oemid-random = JC<oemid-random-json, oemid-random-cbor>
oemid-random-cbor = bstr .size 16 oemid-random-cbor = bstr .size 16
oemid-random-json = base64-url-text .size 24 oemid-random-json = base64-url-text .size 24]]></sourcecode>
]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="hwmodel"> <section anchor="hwmodel">
<name>hwmodel (Hardware Model) Claim</name> <name>hwmodel (Hardware Model) Claim</name>
<t>The "hwmodel" claim differentiates hardware models, products and va riants manufactured by a particular OEM, the one identified by OEM ID in <xref t arget="oemid"/>. <t>The "hwmodel" claim differentiates hardware models, products, and v ariants manufactured by a particular OEM, namely the one identified by the OEM I D in <xref target="oemid"/>.
It <bcp14>MUST</bcp14> be unique within a given OEM ID. It <bcp14>MUST</bcp14> be unique within a given OEM ID.
The concatenation of the OEM ID and "hwmodel" give a global identifier of a part The concatenation of the OEM ID and "hwmodel" gives a global identifier of a par
icular product. ticular product. The "hwmodel" claim <bcp14>MUST</bcp14> only be present if an "
The "hwmodel" claim <bcp14>MUST</bcp14> only be present if an "oemid" claim desc oemid" claim described in <xref target="oemid"/> is present.</t>
ribed in <xref target="oemid"/> is present.</t>
<t>The granularity of the model identification is for each OEM to deci de. <t>The granularity of the model identification is for each OEM to deci de.
It may be very granular, perhaps including some version information. It may be very granular, perhaps including some version information.
It may be very general, perhaps only indicating top-level products.</t> 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 consu mption. <t>The "hwmodel" claim is for use in protocols and not for human consu mption.
The format and encoding of this claim should not be human-readable to discourage use other than in protocols. The format and encoding of this claim should not be 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> 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. <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. The maximum length is 32 bytes.
All receivers of this claim <bcp14>MUST</bcp14> be able to receive this maximum size.</t> 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 comple tely opaque string of bytes, even if there is some apparent naming or structure. <t>The receiver of this claim <bcp14>MUST</bcp14> treat it as a comple tely 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 cl aim continues to uniquely identify its models.</t> The OEM is free to alter the internal structure of these bytes as long as the cl aim continues to uniquely identify its models.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= ( $$Claims-Set-Claims //= (
hardware-model-label => hardware-model-type hardware-model-label => hardware-model-type
) )
hardware-model-type = JC<base64-url-text .size (4..44), hardware-model-type = JC<base64-url-text .size (4..44),
bytes .size (1..32)> bytes .size (1..32)>]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="hwversion-hardware-version-claim"> <section anchor="hwversion-hardware-version-claim">
<name>hwversion (Hardware Version) Claim</name> <name>hwversion (Hardware Version) Claim</name>
<t>The "hwversion" claim is a text string the format of which is set b <t>The "hwversion" claim is a text string, of which the format is set
y each manufacturer. by each manufacturer.
The structure and sorting order of this text string can be specified using the v The structure and sorting order of this text string can be specified using the v
ersion-scheme item from CoSWID <xref target="RFC9393"/>. ersion-scheme item from Concise Software Identification (CoSWID) <xref target="R
It is useful to know how to sort versions so the newer can be distinguished from FC9393"/>.
the older. It is useful to know how to sort versions so the newer ones can be distinguished
A "hwversion" claim <bcp14>MUST</bcp14> only be present if a "hwmodel" claim des from the older ones.
cribed in <xref target="hwmodel"/> is present.</t> A "hwversion" claim <bcp14>MUST</bcp14> only be present if a "hwmodel" claim, as
described in <xref target="hwmodel"/>, is present.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= ( $$Claims-Set-Claims //= (
hardware-version-label => hardware-version-type hardware-version-label => hardware-version-type
) )
hardware-version-type = [ hardware-version-type = [
version: tstr, version: tstr,
? scheme: $version-scheme ? scheme: $version-scheme
] ]]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="swname"> <section anchor="swname">
<name>swname (Software Name) Claim</name> <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. <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. Intentionally, no general rules or structure are set.
This will make it unsuitable for use cases that wish precise naming.</t> This will make it unsuitable for use cases that wish precise naming.</t>
<t>If precise and rigourous naming of the software for the entity is n <t>If precise and rigorous naming of the software for the entity is ne
eeded, the "manifests" claim described in <xref target="manifests"/> may be used eded, the "manifests" claim, as described in <xref target="manifests"/>, may be
instead.</t> used instead.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= ( sw-name-label => tstr ) $$Claims-Set-Claims //= ( sw-name-label => tstr )]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="swversion-software-version-claim"> <section anchor="swversion-software-version-claim">
<name>swversion (Software Version) Claim</name> <name>swversion (Software Version) Claim</name>
<t>The "swversion" claim makes use of the CoSWID version-scheme define d in <xref target="RFC9393"/> to give a simple version for the software. <t>The "swversion" claim makes use of the CoSWID version-scheme define d 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 desc A "swversion" claim <bcp14>MUST</bcp14> only be present if a "swname" c
ribed in <xref target="swname"/> is present.</t> laim, as described in <xref target="swname"/>, is present.</t>
<t>The "manifests" claim <xref target="manifests"/> may be instead if
this is too simple.</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"/>) may be used inst
ead if this is too simple.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (sw-version-label => sw-version-type) $$Claims-Set-Claims //= (sw-version-label => sw-version-type)
sw-version-type = [ sw-version-type = [
version: tstr version: tstr
? scheme: $version-scheme ? scheme: $version-scheme
] ]]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="oemboot"> <section anchor="oemboot">
<name>oemboot (OEM Authorized Boot) Claim</name> <name>oemboot (OEM Authorized Boot) Claim</name>
<t>An "oemboot" claim with value of true indicates the entity booted w <t>An "oemboot" claim with a value of "true" indicates that the entity
ith software authorized by the manufacturer of the entity as indicated by the "o booted with software authorized by the manufacturer of the entity as indicated
emid" claim described in <xref target="oemid"/>. by the "oemid" claim described in <xref target="oemid"/>.
It indicates the firmware and operating system are fully under control of the OE It indicates that the firmware and operating system are fully under control of t
M and may not be replaced by the end user or even the enterprise that owns the d he OEM and may not be replaced by the end user or even the enterprise that owns
evice. the device.
The means of control may be by cryptographic authentication of the software, by The means of control may be by cryptographic authentication of the software, the
the software being in Read-Only Memory (ROM), a combination of the two or other. software being in Read-Only Memory (ROM), a combination of the two, or other.
If this claim is present the "oemid" claim <bcp14>MUST</bcp14> be present.</t> If this claim is present, the "oemid" claim <bcp14>MUST</bcp14> be present.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (oem-boot-label => bool) $$Claims-Set-Claims //= (oem-boot-label => bool)]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="dbgstat"> <section anchor="dbgstat">
<name>dbgstat (Debug Status) Claim</name> <name>dbgstat (Debug Status) Claim</name>
<t>The "dbgstat" claim applies to entity-wide or submodule-wide debug
facilities of the <t>The "dbgstat" claim applies to entity-wide or submodule-wide debug
entity like <xref target="JTAG"/> and diagnostic hardware built into facilities of the entity like <xref target="JTAG"/> and diagnostic hardware buil
t into
chips. It applies to any software debug facilities related to privileged softwar e that allows system-wide memory chips. It applies to any software debug facilities related to privileged softwar e that allows system-wide memory
inspection, tracing or modification of non-system software like user inspection, tracing, or modification of non-system software like user-mode
mode applications.</t> applications.</t>
<t>This characterization assumes that debug facilities can be enabled and <t>This characterization assumes that debug facilities can be enabled and
disabled in a dynamic way or be disabled in some permanent way, such 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 that no enabling is possible. An example of dynamic enabling is one
where some authentication is required to enable debugging. An example where some authentication is required to enable debugging. An example
of permanent disabling is blowing a hardware fuse in a chip. The specific 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 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 not matter if authentication is by a global password or by per-entity
public keys.</t> public keys.</t>
<t>As with all claims, the absence of the "dbgstat" claim means it is not reported.</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 interoperabl e description of debug status. <t>This claim is not extensible so as to provide a common interoperabl e description of debug status.
If a particular implementation considers this claim to be inadequate, it can def ine its own proprietary claim. If a particular implementation considers this claim to be inadequate, it can def ine 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> 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 that all debug disabl ing <t>The higher levels of debug disabling require that all debug disabli ng
of the levels below it be in effect. Since the lowest level requires 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 that all of the target's debug be currently disabled, all other levels
require that too.</t> require that too.</t>
<t>There is no inheritance of claims from a submodule to a superior <t>There is no inheritance of claims from a submodule to a superior
module or vice versa. There is no assumption, requirement or guarantee module or vice versa. There is no assumption, requirement, or guarantee
that the target of a superior module encompasses the targets of that the target of a superior module encompasses the targets of
submodules. Thus, every submodule must explicitly describe its own submodules. Thus, every submodule must explicitly describe its own
debug state. The receiver of an EAT <bcp14>MUST NOT</bcp14> 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 assume that debug is turned off in a submodule because there is a claim
indicating it is turned off in a superior module.</t> indicating it is turned off in a superior module.</t>
<t>An entity may have multiple debug <t>An entity may have multiple debug
facilities. The use of plural in the description of the states facilities. The use of plural in the description of the states
refers to that, not to any aggregation or inheritance.</t> refers to that, not to any aggregation or inheritance.</t>
<t>The architecture of some chips or devices may be such that a debug <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 facility operates for the whole chip or device. If the EAT for such
skipping to change at line 714 skipping to change at line 898
of the submodules since there is no inheritance.</t> of the submodules since there is no inheritance.</t>
<section anchor="enabled"> <section anchor="enabled">
<name>Enabled</name> <name>Enabled</name>
<t>If any debug facility, even manufacturer hardware diagnostics, is <t>If any debug facility, even manufacturer hardware diagnostics, is
currently enabled, then this level must be indicated.</t> currently enabled, then this level must be indicated.</t>
</section> </section>
<section anchor="disabled"> <section anchor="disabled">
<name>Disabled</name> <name>Disabled</name>
<t>This level indicates all debug facilities are currently disabled. It <t>This level indicates all debug facilities are currently disabled. It
may be possible to enable them in the future. It may also be may be possible to enable them in the future. It may also be
that they were enabled in the past, but they are currently disabled.</t> that they were enabled in the past but are currently disabled.</t>
</section> </section>
<section anchor="disabled-since-boot"> <section anchor="disabled-since-boot">
<name>Disabled Since Boot</name> <name>Disabled Since Boot</name>
<t>This level indicates all debug facilities are currently disabled and <t>This level indicates all debug facilities are currently disabled and
have been so since the entity booted/started.</t> have been so since the entity booted/started.</t>
</section> </section>
<section anchor="disabled-permanently"> <section anchor="disabled-permanently">
<name>Disabled Permanently</name> <name>Disabled Permanently</name>
<t>This level indicates all non-manufacturer facilities are permanen tly <t>This level indicates all non-manufacturer facilities are permanen tly
disabled such that no end user or developer can enable them. Only disabled such that no end user or developer can enable them. Only
skipping to change at line 733 skipping to change at line 917
<t>This level indicates all non-manufacturer facilities are permanen tly <t>This level indicates all non-manufacturer facilities are permanen tly
disabled such that no end user or developer can enable them. Only disabled such that no end user or developer can enable them. Only
the manufacturer indicated in the "oemid" claim can enable them. This the manufacturer indicated in the "oemid" claim can enable them. This
also indicates that all debug facilities are currently disabled and also indicates that all debug facilities are currently disabled and
have been so since boot/start. have been so since boot/start.
If this debug state is reported, the "oemid" claim <bcp14>MUST</bcp14> be prese nt.</t> If this debug state is reported, the "oemid" claim <bcp14>MUST</bcp14> be prese nt.</t>
</section> </section>
<section anchor="disabled-fully-and-permanently"> <section anchor="disabled-fully-and-permanently">
<name>Disabled Fully and Permanently</name> <name>Disabled Fully and Permanently</name>
<t>This level indicates that all debug facilities for the entity are permanently disabled.</t> <t>This level indicates that all debug facilities for the entity are permanently disabled.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= ( debug-status-label => debug-status-type ) $$Claims-Set-Claims //= ( debug-status-label => debug-status-type )
debug-status-type = ds-enabled / debug-status-type = ds-enabled /
disabled / disabled /
disabled-since-boot / disabled-since-boot /
disabled-permanently / disabled-permanently /
disabled-fully-and-permanently disabled-fully-and-permanently
ds-enabled = JC< "enabled", 0 > ds-enabled = JC< "enabled", 0 >
disabled = JC< "disabled", 1 > disabled = JC< "disabled", 1 >
disabled-since-boot = JC< "disabled-since-boot", 2 > disabled-since-boot = JC< "disabled-since-boot", 2 >
disabled-permanently = JC< "disabled-permanently", 3 > disabled-permanently = JC< "disabled-permanently", 3 >
disabled-fully-and-permanently = disabled-fully-and-permanently =
JC< "disabled-fully-and-permanently", 4 > JC< "disabled-fully-and-permanently", 4 >]]></sourcecode>
]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="location"> <section anchor="location">
<name>location (Location) Claim</name> <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 fr om which the attestation originates. <t>The "location" claim gives the geographic position of the entity fr om which the attestation originates.
Latitude, longitude, altitude, accuracy, altitude-accuracy, heading and speed <b Latitude, longitude, altitude, accuracy, altitude-accuracy, heading, and speed <
cp14>MUST</bcp14> be as defined in the W3C Geolocation API <xref target="W3C.Geo bcp14>MUST</bcp14> be as defined in the W3C Geolocation API <xref target="W3C.Ge
Loc"/> oLoc"/>
(which, in turn, is based on <xref target="WGS84"/>). (which, in turn, is based on <xref target="WGS84"/>). If the entity is stationar
If the entity is stationary, the heading is NaN (floating-point not-a-number). y, the heading is Not a Number (NaN) (i.e., a floating-point NaN). Latitude and
Latitude and longitude <bcp14>MUST</bcp14> be provided. longitude <bcp14>MUST</bcp14> be provided.
If any other of these values are unknown, they are omitted.</t> 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 <t>The location may have been cached for a period of time before token
creation. For example, it might have been minutes or hours or more creation. For example, it might have been minutes, hours, or more
since the last contact with a GNSS satellite. Either the timestamp or since the last contact with a Global Navigation Satellite System (GNSS) satellit
age data item can be used to quantify the cached period. The timestamp e. Either the timestamp or the age data item can be used to quantify the cached
data item is preferred as it a non-relative time. 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 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 the time interval between the acquisition of the location and the token creation, th
age may be reported instead. e age may be reported instead.
The age is in seconds.</t> The age is in seconds.</t>
<t>See location-related privacy considerations in <xref target="locati onprivacyconsiderations"/>.</t> <t>See location-related privacy considerations in <xref target="locati onprivacyconsiderations"/>.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (location-label => location-type) $$Claims-Set-Claims //= (location-label => location-type)
location-type = { location-type = {
latitude => number, latitude => number,
longitude => number, longitude => number,
? altitude => number, ? altitude => number,
? accuracy => number, ? accuracy => number,
? altitude-accuracy => number, ? altitude-accuracy => number,
? heading => number, ? heading => number,
skipping to change at line 790 skipping to change at line 1001
} }
latitude = JC< "latitude", 1 > latitude = JC< "latitude", 1 >
longitude = JC< "longitude", 2 > longitude = JC< "longitude", 2 >
altitude = JC< "altitude", 3 > altitude = JC< "altitude", 3 >
accuracy = JC< "accuracy", 4 > accuracy = JC< "accuracy", 4 >
altitude-accuracy = JC< "altitude-accuracy", 5 > altitude-accuracy = JC< "altitude-accuracy", 5 >
heading = JC< "heading", 6 > heading = JC< "heading", 6 >
speed = JC< "speed", 7 > speed = JC< "speed", 7 >
timestamp = JC< "timestamp", 8 > timestamp = JC< "timestamp", 8 >
age = JC< "age", 9 > age = JC< "age", 9 >]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="uptime-uptime-claim"> <section anchor="uptime-uptime-claim">
<name>uptime (Uptime) Claim</name> <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> <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[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (uptime-label => uint) $$Claims-Set-Claims //= (uptime-label => uint)]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="bootcount-boot-count-claim"> <section anchor="bootcount-boot-count-claim">
<name>bootcount (Boot Count) Claim</name> <name>bootcount (Boot Count) Claim</name>
<t>The "bootcount" claim contains a count of the number <t>The "bootcount" claim contains a count of the number
times the entity or submodule has been booted. Support for this claim of times the entity or submodule has been booted. Support for this claim
requires a persistent storage on the device.</t> requires a persistent storage on the device.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (boot-count-label => uint) $$Claims-Set-Claims //= (boot-count-label => uint)]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="bootseed-boot-seed-claim"> <section anchor="bootseed-boot-seed-claim">
<name>bootseed (Boot Seed) Claim</name> <name>bootseed (Boot Seed) Claim</name>
<t>The "bootseed" claim contains a value created at system boot time t hat allows differentiation of attestation reports from different boot sessions o f a particular entity (e.g., a certain UEID).</t> <t>The "bootseed" claim contains a value created at system boot time t hat allows differentiation of attestation reports from different boot sessions o f a particular entity (e.g., a certain UEID).</t>
<t>This value is usually public. <t>This value is usually public.
It is not a secret and <bcp14>MUST NOT</bcp14> be used for any purpose that a se It is not a secret and <bcp14>MUST NOT</bcp14> be used for any purpose where a s
cret seed is needed, such as seeding a random number generator.</t> ecret seed is needed, such as seeding a random number generator.</t>
<t>There are privacy considerations for this claim. See <xref target=" <t>There are privacy considerations for this claim; see <xref target="
bootseedprivacyconsiderations"/>.</t> bootseedprivacyconsiderations"/>.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (boot-seed-label => binary-data) $$Claims-Set-Claims //= (boot-seed-label => binary-data)]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="dloas"> <section anchor="dloas">
<name>dloas (Digital Letters of Approval) Claim</name> <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 certificatio n that an entity has received. <t>The "dloas" claim conveys one or more Digital Letters of Approval ( DLOAs). A DLOA <xref target="DLOA"/> is a document that describes a certificatio n that an entity has received.
Examples of certifications represented by a DLOA include those issued by Global Platform <xref target="GP-Example"/> and those based on Common Criteria <xref ta rget="CC-Example"/>. Examples of certifications represented by a DLOA include those issued by GlobalP latform <xref target="GP-Example"/> and those based on Common Criteria <xref tar get="CC-Example"/>.
The DLOA is unspecific to any particular certification type or those issued by a ny particular organization.</t> The DLOA is unspecific to any particular certification type or those issued by a ny particular organization.</t>
<t>This claim is typically issued by a verifier, not an attester. <t>This claim is typically issued by a verifier, not an attester.
Verifiers <bcp14>MUST NOT</bcp14> issue this claim unless the entity has receive d the certification indicated by the DLOA.</t> Verifiers <bcp14>MUST NOT</bcp14> issue this claim unless the entity has receive d the certification indicated by the DLOA.</t>
<t>This claim <bcp14>MAY</bcp14> contain more than one DLOA. <t>This claim <bcp14>MAY</bcp14> contain more than one DLOA.
If multiple DLOAs are present, verifiers <bcp14>MUST NOT</bcp14> issue this clai m unless the entity has received all of the certifications.</t> If multiple DLOAs are present, verifiers <bcp14>MUST NOT</bcp14> issue this clai m unless the entity has received all of the certifications.</t>
<t>DLOA documents are always fetched from a registrar that stores them . <t>DLOA documents are always fetched from a registrar that stores them .
This claim contains several data items used to construct a Uniform Resource Loca tor (URL) for fetching the DLOA from the particular registrar.</t> This claim contains several data items used to construct a Uniform Resource Loca tor (URL) for fetching the DLOA from the particular registrar.</t>
<t>This claim <bcp14>MUST</bcp14> be encoded as an array with either t <t>This claim <bcp14>MUST</bcp14> be encoded as an array with either t
wo or three elements. wo or three elements. The first element <bcp14>MUST</bcp14> be the URL for the r
The first element <bcp14>MUST</bcp14> be the URL for the registrar. egistrar.
The second element <bcp14>MUST</bcp14> be a platform label indicating which plat form was certified. The second element <bcp14>MUST</bcp14> be a platform label indicating which plat form was certified.
If the DLOA applies to an application, then the third element is added which <bc If the DLOA applies to an application, then the third element is added, which <b
p14>MUST</bcp14> be an application label. cp14>MUST</bcp14> be an application label.
The method of constructing the registrar URL, platform label and possibly applic The method of constructing the registrar URL, platform label, and possibly appli
ation label is specified in <xref target="DLOA"/>.</t> cation label is specified in <xref target="DLOA"/>.</t>
<t>The retriever of a DLOA <bcp14>MUST</bcp14> follow the recommendati <t>The retriever of a DLOA <bcp14>MUST</bcp14> follow the recommendati
on in <xref target="DLOA"/> and use TLS or some other means to be sure the DLOA on in <xref target="DLOA"/> and use Transport Layer Security (TLS) or some other
registrar they are accessing is authentic. 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 t he entity.</t> The platform and application labels in the claim indicate the correct DLOA for t he entity.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= ( $$Claims-Set-Claims //= (
dloas-label => [ + dloa-type ] dloas-label => [ + dloa-type ]
) )
dloa-type = [ dloa-type = [
dloa_registrar: general-uri dloa_registrar: general-uri
dloa_platform_label: text dloa_platform_label: text
? dloa_application_label: text ? dloa_application_label: text
] ]]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="manifests"> <section anchor="manifests">
<name>manifests (Software Manifests) Claim</name> <name>manifests (Software Manifests) Claim</name>
<t>The "manifests" claim contains descriptions of software present on the entity. <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 ar e created as part of the installation process. These manifests are installed on the entity when the software is installed or ar e created as part of the installation process.
Installation is anything that adds software to the entity, possibly factory inst allation, the user installing elective applications and so on. Installation is anything that adds software to the entity, possibly factory inst allation, the user installing elective applications, and so on.
The defining characteristic of a manifest is that it is created by the software manufacturer. 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 p ossibly to the relying party.</t> The purpose of this claim is to relay unmodified manifests to the verifier and p ossibly to the relying party.</t>
<t>Some manifests are signed by their software manufacturer independen tly, and some are not either because they do not support signing or the manufact urer chose not to sign them. <t>Some manifests are signed by their software manufacturer independen tly, and some are not because either they do not support signing or the manufact urer chose not to sign them.
For example, a CoSWID might be signed independently before it is included in an EAT. 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>S HOULD</bcp14> be included even though an EAT's signature will also cover the man ifest. When signed manifests are put into an EAT, the manufacturer's signature <bcp14>S HOULD</bcp14> be included even though an EAT's signature will also cover the man ifest.
This allows the receiver to directly verify the manufacturer-originated manifest .</t> This allows the receiver to directly verify the manufacturer-originated manifest .</t>
<t>This claim allows multiple manifest formats. <t>This claim allows multiple manifest formats.
For example, the manifest may be a CBOR-encoded CoSWID, an XML-encoded SWID or o
ther. <!--[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 Pr otocol (CoAP) Content-Format integer <xref target="RFC7252"/>. Identification of the type of manifest is always by a Constrained Application Pr otocol (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> 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 . <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. Each manifest in the claim <bcp14>MUST</bcp14> be an array of two. The
The first item in the array of two <bcp14>MUST</bcp14> be an integer CoAP Conten first item in the array of two <bcp14>MUST</bcp14> be an integer CoAP Content-Fo
t-Format identifier. rmat identifier.
The second item is <bcp14>MUST</bcp14> be the actual manifest.</t> The second item is <bcp14>MUST</bcp14> be the actual manifest.</t>
<t>In JSON-encoded tokens the manifest, whatever encoding it is, <bcp1 <t>In JSON-encoded tokens, the manifest, whatever encoding it is, <bcp
4>MUST</bcp14> be placed in a text string. 14>MUST</bcp14> be placed in a text string.
When a non-text encoded manifest like a CBOR-encoded CoSWID is put in a JSON-enc When a non-text encoded manifest such as a CBOR-encoded CoSWID is put in a JSON-
oded token, the manifest <bcp14>MUST</bcp14> be base-64 encoded.</t> encoded token, the manifest <bcp14>MUST</bcp14> be base64 encoded.</t>
<t>This claim allows for multiple manifests in one token since multipl e software packages are likely to be present. <t>This claim allows for multiple manifests in one token since multipl e software packages are likely to be present.
The multiple manifests <bcp14>MAY</bcp14> be of different encodings. The multiple manifests <bcp14>MAY</bcp14> be of different encodings.
In some cases EAT submodules may be used instead of the array structure in this claim for multiple manifests.</t> In some 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 e vidence CoSWID. <t>A CoSWID manifest <bcp14>MUST</bcp14> be a payload CoSWID, not an e vidence CoSWID.
These are defined in <xref target="RFC9393"/>.</t> These are defined in <xref target="RFC9393"/>.</t>
<t>This claim is extensible for use of manifest formats beyond those m entioned in this document. <t>This claim is extensible for use of manifest formats beyond those m entioned in this document.
No particular manifest format is preferred. No particular manifest format is preferred.
For manifest interoperability, an EAT profile as defined in <xref target="profil For manifest interoperability, an EAT profile, as defined in <xref target="profi
es"/>, should be used to specify which manifest format(s) are allowed.</t> les"/>, should be used to specify which manifest format(s) is allowed.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= ( $$Claims-Set-Claims //= (
manifests-label => manifests-type manifests-label => manifests-type
) )
manifests-type = [+ manifest-format] manifests-type = [+ manifest-format]
manifest-format = [ manifest-format = [
content-type: coap-content-format, content-type: coap-content-format,
content-format: JC< $manifest-body-json, content-format: JC< $manifest-body-json,
$manifest-body-cbor > $manifest-body-cbor >
] ]
$manifest-body-cbor /= bytes .cbor untagged-coswid $manifest-body-cbor /= bytes .cbor untagged-coswid
$manifest-body-json /= base64-url-text $manifest-body-json /= base64-url-text]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="measurements"> <section anchor="measurements">
<name>measurements (Measurements) Claim</name> <name>measurements (Measurements) Claim</name>
<t>The "measurements" claim contains descriptions, lists, evidence or <t>The "measurements" claim contains descriptions, lists, evidence, or
measurements of the software that exists on the entity or any other measurable measurements of the software that exists on the entity or on any other measurab
subsystem of the entity (e.g. hash of sections of a file system or non-volatile le
memory). subsystem of the entity (e.g., hash of sections of a file system or non-volatile
The defining characteristic of this claim is that its contents are created by pr memory).
ocesses on the entity that inventory, measure or otherwise characterize the soft The defining characteristic of this claim is that its contents are created by pr
ware on the entity. ocesses on the entity that inventory, measure, or otherwise characterize the sof
The contents of this claim do not originate from the manufacturer of the measura tware on the entity.
ble subsystem (e.g. developer of a software library).</t> The contents of this claim do not originate from the manufacturer of th
e measurable subsystem (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"/>. <t>This claim can be a <xref target="RFC9393"/>.
When the CoSWID format is used, it <bcp14>MUST</bcp14> be an evidence CoSWID, no t a payload CoSWID.</t> When the CoSWID format is used, it <bcp14>MUST</bcp14> be an evidence CoSWID, no t a payload CoSWID.</t>
<t>Formats other than CoSWID <bcp14>MAY</bcp14> be used. <t>Formats other than CoSWID <bcp14>MAY</bcp14> be used. The identification of f
The identification of format is by CoAP Content Format, the same as the "manifes ormat is by CoAP Content-Format, the same as the "manifests" claim in <xref targ
ts" claim in <xref target="manifests"/>.</t> et="manifests"/>.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= ( $$Claims-Set-Claims //= (
measurements-label => measurements-type measurements-label => measurements-type
) )
measurements-type = [+ measurements-format] measurements-type = [+ measurements-format]
measurements-format = [ measurements-format = [
content-type: coap-content-format, content-type: coap-content-format,
content-format: JC< $measurements-body-json, content-format: JC< $measurements-body-json,
$measurements-body-cbor > $measurements-body-cbor >
] ]
$measurements-body-cbor /= bytes .cbor untagged-coswid $measurements-body-cbor /= bytes .cbor untagged-coswid
$measurements-body-json /= base64-url-text $measurements-body-json /= base64-url-text]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="measurementresults"> <section anchor="measurementresults">
<name>measres (Software Measurement Results) Claim</name> <name>measres (Software Measurement Results) Claim</name>
<t>The "measres" claim is a general-purpose structure for reporting co <t>The "measres" claim is a general-purpose structure for reporting th
mparison of measurements to expected reference values. e 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 a s success, failure, fail to run, and absence.</t> This claim provides a simple standard way to report the result of a comparison a s success, failure, fail to run, and absence.</t>
<t>It is the nature of measurement systems that they are specific to t <t>It is the nature of measurement systems to be specific to the opera
he operating system, software and hardware of the entity that is being measured. ting system, 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 It is not possible to standardize what is measured and how it is measured across
platforms, OS's, software and hardware. platforms, OSes, software, and hardware.
The recipient must obtain the information about what was measured and what it in dicates for the characterization of the security of the entity from the provider of the measurement system. The recipient must obtain the information about what was measured and what it in dicates 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. What this claim provides is a standard way to report basic success or failure of the measurement.
In some use cases it is valuable to know if measurements succeeded or failed in a general way even if the details of what was measured is not characterized.</t> In some use cases, it is valuable to know if measurements succeeded or failed in a general way even if the details of what was measured are not characterized.</ t>
<t>This claim <bcp14>MAY</bcp14> be generated by the verifier and sent to the relying party. <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 t he "measurements" claim, <xref target="measurements"/>, to reference values.</t> For example, it could be the results of the verifier comparing the contents of t he "measurements" claim (<xref target="measurements"/>) to reference values.</t >
<t>This claim <bcp14>MAY</bcp14> also be generated on the entity if th e entity has the ability for one subsystem to measure and evaluate another subsy stem. <t>This claim <bcp14>MAY</bcp14> also be generated on the entity if th e entity has the ability for one subsystem to measure and evaluate another subsy stem.
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> 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 or submodule, multiple results <t>Within an entity, attestation target, or submodule, multiple result
can be reported. s can be reported.
For example, it may be desirable to report the results for measurements of the f For example, it may be desirable to report the results for measurements of the f
ile system, chip configuration, installed software, running software and so on.< ile system, chip configuration, installed software, running software, and so on.
/t> </t>
<t>Note that this claim is not for reporting the overall result of a v erifier. <t>Note that this claim is not for reporting the overall result of a v erifier.
It is solely for reporting the result of comparison to reference values.</t> It is solely for reporting the result of comparison to reference values.</t>
<t>An individual measurement result (individual-result) is an array co nsisting of two elements, an identifier of the measurement (result-id) and an en umerated type of the result (result). <t>An individual measurement result (individual-result) is an array co nsisting of two elements, an identifier of the measurement (result-id), and an e numerated type of the result (result).
Different measurement systems will measure different things and perhaps measure the same thing in different ways. 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 me asurements it reports.</t> It is up to each measurement system to define identifiers (result-id) for the me asurements it reports.</t>
<t>Each individual measurement result is part of a group that may cont ain many individual results. <t>Each individual measurement result is part of a group that may cont ain many individual results.
Each group has a text string that names it, typically the name of the measuremen t scheme or system.</t> Each group has a text string that names it, typically the name of the measuremen t scheme or system.</t>
<t>The claim itself consists of one or more groups.</t> <t>The claim itself consists of one or more groups.</t>
<t>The values for the results enumerated type are as follows:</t> <t>The values for the results enumerated type are as follows:</t>
<dl> <dl>
<dt>1 -- comparison successful:</dt> <dt>1 -- comparison successful:</dt><dd> The comparison to reference
<dd> values was successful.</dd>
<t>Indicates successful comparison to reference values.</t> <dt>2 -- comparison fail:</dt><dd> The comparison was completed but
</dd> did not compare correctly to the reference values.</dd>
<dt>2 -- comparison fail:</dt>
<dd> <dt>3 -- comparison not run:</dt><dd> The comparison was not run. Th
<t>The comparison was completed and did not compare correctly to t is includes error conditions such as running out of memory.</dd>
he reference values.</t>
</dd> <dt>4 -- measurement absent:</dt><dd> The particular measurement was
<dt>3 -- comparison not run:</dt> not available for comparison.</dd>
<dd>
<t>The comparison was not run. This includes error conditions such
as running out of memory.</t>
</dd>
<dt>4 -- measurement absent:</dt>
<dd>
<t>The particular measurement was not available for comparison.</t
>
</dd>
</dl> </dl>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= ( $$Claims-Set-Claims //= (
measurement-results-label => measurement-results-label =>
[ + measurement-results-group ] ) [ + measurement-results-group ] )
measurement-results-group = [ measurement-results-group = [
measurement-system: tstr, measurement-system: tstr,
measurement-results: [ + individual-result ] measurement-results: [ + individual-result ]
] ]
skipping to change at line 989 skipping to change at line 1289
] ]
result-type = comparison-successful / result-type = comparison-successful /
comparison-fail / comparison-fail /
comparison-not-run / comparison-not-run /
measurement-absent measurement-absent
comparison-successful = JC< "success", 1 > comparison-successful = JC< "success", 1 >
comparison-fail = JC< "fail", 2 > comparison-fail = JC< "fail", 2 >
comparison-not-run = JC< "not-run", 3 > comparison-not-run = JC< "not-run", 3 >
measurement-absent = JC< "absent", 4 > measurement-absent = JC< "absent", 4 >]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="submods"> <section anchor="submods">
<name>submods (Submodules)</name> <name>submods (Submodules)</name>
<t>Some devices are complex and have many subsystems. A mobile phone <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 ce is a good example. It may have subsystems for communications (e.g., Wi-Fi and ce
llular), low-power audio and video playback, and multiple llular), low-power audio and video playback, and multiple security-oriented subs
security-oriented subsystems like a TEE and a Secure Element. The claims for a s ystems such as a TEE and a Secure Element. The claims for a subsystem can be gro
ubsystem can be grouped together in a submodule.</t> uped together in a submodule.</t>
<t>Submodules may be used in either evidence or attestation results.</ 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 ev idence or in attestation results. <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 ev idence or in attestation results.
Profiles, <xref target="profiles"/>, may wish to impose requirements. 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. 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 doc ument the semantics it associates with the submodules for the relying party.</t> Likewise, a verifier that outputs attestation results with submodules should doc ument 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. <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. 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 or Deta ched-Submodule-Digest. The value of each entry in a submodule may be a Claims-Set, nested token, or Det ached-Submodule-Digest.
This allows for the submodule to serve as its own attester or not and allows for claims 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> 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. <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 e xplicitly include all claims. However, submodules do not inherit anything from the containing token and must e xplicitly include all claims.
Submodules may contain claims that are present in any surrounding token or submo dule. Submodules may contain claims that are present in any surrounding token or submo dule.
For example, the top-level of the token may have a UEID, a submodule may have a For example, the top level of the token may have a UEID, a submodule may have a
different UEID and a further subordinate submodule may also have a UEID.</t> different UEID, and a further subordinate submodule may also have a UEID.</t>
<t>The following sub-sections define the three types for representing <t>The following subsections define the three types for representing s
submodules:</t> ubmodules:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A submodule Claims-Set</t> <t>A submodule Claims-Set</t>
</li> </li>
<li> <li>
<t>The digest of a detached Claims-Set</t> <t>The digest of a detached Claims-Set</t>
</li> </li>
<li> <li>
<t>A nested token, which can be any EAT</t> <t>A nested token, which can be any EAT</t>
</li> </li>
</ul> </ul>
<t>The Submodule type definition and Nested-Token type definition vary <t>The Submodule type and Nested-Token type definitions vary with the
with the type of encoding. The definitions for CBOR-encoded EATs are as follows type of encoding. The definitions for CBOR-encoded EATs are as follows:</t>
:</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
Nested-Token = CBOR-Nested-Token Nested-Token = CBOR-Nested-Token
CBOR-Nested-Token = CBOR-Nested-Token =
JSON-Token-Inside-CBOR-Token / JSON-Token-Inside-CBOR-Token /
CBOR-Token-Inside-CBOR-Token CBOR-Token-Inside-CBOR-Token
CBOR-Token-Inside-CBOR-Token = bstr .cbor $EAT-CBOR-Tagged-Token CBOR-Token-Inside-CBOR-Token = bstr .cbor $EAT-CBOR-Tagged-Token
JSON-Token-Inside-CBOR-Token = tstr JSON-Token-Inside-CBOR-Token = tstr
$$Claims-Set-Claims //= (submods-label => { + text => Submodule }) $$Claims-Set-Claims //= (submods-label => { + text => Submodule })
Submodule = Claims-Set / CBOR-Nested-Token / Submodule = Claims-Set / CBOR-Nested-Token /
Detached-Submodule-Digest Detached-Submodule-Digest]]></sourcecode>
]]></sourcecode>
<t>The Submodule and Nested-Token definitions for JSON-encoded EATs is <t>The Submodule and Nested-Token definitions for JSON-encoded EATs ar
as below. This difference in definitions versus CBOR is necessary because JSON e as below. The definitions are necessarily different than CBOR because JSON has
has no tag mechanism and no byte string type to help indicate the nested token i no tag mechanism and no byte-string type to help indicate that the nested token
s CBOR.</t> is CBOR.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
Nested-Token = JSON-Selector Nested-Token = JSON-Selector
JSON-Selector = $JSON-Selector JSON-Selector = $JSON-Selector
$JSON-Selector /= [type: "JWT", nested-token: JWT-Message] $JSON-Selector /= [type: "JWT", nested-token: JWT-Message]
$JSON-Selector /= [type: "CBOR", nested-token: $JSON-Selector /= [type: "CBOR", nested-token:
CBOR-Token-Inside-JSON-Token] CBOR-Token-Inside-JSON-Token]
$JSON-Selector /= [type: "BUNDLE", nested-token: Detached-EAT-Bundle] $JSON-Selector /= [type: "BUNDLE", nested-token: Detached-EAT-Bundle]
$JSON-Selector /= [type: "DIGEST", nested-token: $JSON-Selector /= [type: "DIGEST", nested-token:
Detached-Submodule-Digest] Detached-Submodule-Digest]
CBOR-Token-Inside-JSON-Token = base64-url-text CBOR-Token-Inside-JSON-Token = base64-url-text
$$Claims-Set-Claims //= (submods-label => { + text => Submodule }) $$Claims-Set-Claims //= (submods-label => { + text => Submodule })
Submodule = Claims-Set / JSON-Selector Submodule = Claims-Set / JSON-Selector]]></sourcecode>
]]></sourcecode>
<t>The Detached-Submodule-Digest type is defined as follows:</t> <t>The Detached-Submodule-Digest type is defined as follows:</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
Detached-Submodule-Digest = [ Detached-Submodule-Digest = [
hash-algorithm : text / int, hash-algorithm : text / int,
digest : binary-data 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"/>). <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 v ice versa.</t> Nested tokens are the only mechanism by which JSON can be embedded in CBOR and v ice versa.</t>
<t>The addition of further types is accomplished by augmenting the $EA T-CBOR-Tagged-Token socket or the $JSON-Selector socket.</t> <t>The addition of further types is accomplished by augmenting the $EA T-CBOR-Tagged-Token socket or the $JSON-Selector socket.</t>
<t>When decoding a JSON-encoded EAT, the type of submodule is determin ed as follows. <t>When decoding a JSON-encoded EAT, the type of submodule is determin ed as follows.
A JSON object indicates the submodule is a Claims-Set. 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 tha In all other cases, it is a JSON-Selector, which is an array of two elements tha
t indicates whether the submodule is a nested token or a Detached-Submodule-Dige t indicates whether the submodule is a nested token or a Detached-Submodule-Dige
st.The first element in the array indicates the type present in the second eleme st. The first element in the array indicates the type present in the second elem
nt. ent.
If the value is "JWT", "CBOR", "BUNDLE" or a future-standardized token types, e. If the value is "JWT", "CBOR", "BUNDLE", or future-standardized token types, e.g
g., <xref target="I-D.ietf-rats-uccs"/>, the submodule is a nested token of the ., see <xref target="I-D.ietf-rats-uccs"/>, the submodule is a nested token of t
indicated type, i.e., JWT-Message, CBOR-Token-Inside-JSON-Token, Detached-EAT-Bu he indicated type, i.e., JWT-Message, CBOR-Token-Inside-JSON-Token, Detached-EAT
ndle, or a future type. -Bundle, or a future type.
If the value is "DIGEST", the submodule is a Detached-Submodule-Digest. If the value is "DIGEST", the submodule is a Detached-Submodule-Digest.
Any other value indicates a standardized extension to this specification.</t> 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. <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. A map indicates a CBOR-encoded submodule Claims-Set.
An array indicates a CBOR-encoded Detached-Submodule-Digest. An array indicates a CBOR-encoded Detached-Submodule-Digest.
A byte string indicates a CBOR-encoded CBOR-Nested-Token. A byte string indicates a CBOR-encoded CBOR-Nested-Token.
A text string indicates a JSON-encoded JSON-Selector. Where JSON-Selector is use d in a CBOR-encoded EAT, the "DIGEST" type and corresponding Detached-Submodule- Digest type <bcp14>MUST NOT</bcp14> be used.</t> A text string indicates a JSON-encoded JSON-Selector. Where JSON-Selector is use d 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 <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-encode CBOR tag encountered after the byte string wrapping is removed in a CBOR-encode
d enclosing token or after the base64 wrapping is removed in JSON-encoded enclos d enclosing token or after the base64 wrapping is removed in a JSON-encoded encl
ing token.</t> osing token.</t>
<t>The type of a JSON-encoded nested token is always determined by the <t>The type of JSON-encoded nested token is always determined by the s
string name in JSON-Selector and is always "JWT", "BUNDLE" or a new name standa tring name in JSON-Selector and is always "JWT", "BUNDLE", or a new name standar
rdized outside this document for a further type (e.g., "UCCS"). dized 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 This string name may also be "CBOR" to indicate the nested token is CBOR encoded
.</t> .</t>
<dl> <dl spacing="normal">
<dt>"JWT":</dt> <dt>"JWT":</dt><dd> The second array item <bcp14>MUST</bcp14> be a J
<dd> WT formatted according to <xref target="RFC7519"/>.</dd>
<t>The second array item <bcp14>MUST</bcp14> be a JWT formatted ac <dt>"CBOR":</dt><dd> The second array item <bcp14>MUST</bcp14> be so
cording to <xref target="RFC7519"/></t> me
</dd> base64url-encoded CBOR that is a tag, typically a CWT or
<dt>"CBOR":</dt> CBOR-encoded detached EAT bundle.</dd>
<dd> <dt>"BUNDLE":</dt><dd> The second array item <bcp14>MUST</bcp14> be a
<t>The second array item <bcp14>MUST</bcp14> be some base64url-enc JSON-encoded Detached EAT Bundle as defined in this document.</dd>
oded CBOR that is a tag, typically a CWT or CBOR-encoded detached EAT bundle</t> <dt>"DIGEST":</dt><dd> The second array item <bcp14>MUST</bcp14> be a
</dd> JSON-encoded Detached-Submodule-Digest as defined in this
<dt>"BUNDLE":</dt> document.</dd>
<dd>
<t>The second array item <bcp14>MUST</bcp14> be a JSON-encoded Det
ached EAT Bundle as defined in this document.</t>
</dd>
<dt>"DIGEST":</dt>
<dd>
<t>The second array item <bcp14>MUST</bcp14> be a JSON-encoded Det
ached-Submodule-Digest as defined in this document.</t>
</dd>
</dl> </dl>
<t>As noted elsewhere, additional EAT types may be defined by a standa rds action. New type specifications <bcp14>MUST</bcp14> address the integration of the new type into the Submodule claim type for submodules.</t> <t>As noted elsewhere, additional EAT types may be defined by a Standa rds 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"> <section anchor="submodule-claims-set">
<name>Submodule Claims-Set</name> <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, <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 wa y are secured by the same 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 wa y are secured by the same
mechanism as the enclosing token (e.g., it is signed by the same attestation key ).</t> 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 the surrounding EAT, e.g., all submodule Claims-Sets in a CBOR-encoded token must be CBOR-encoded.</t> <t>The encoding of a submodule Claims-Set <bcp14>MUST</bcp14> be the same as the encoding of the surrounding EAT, e.g., all submodule Claims-Sets in a CBOR-encoded token must be CBOR encoded.</t>
</section> </section>
<section anchor="Detached-Submodule-Digest"> <section anchor="Detached-Submodule-Digest">
<name>Detached Submodule Digest</name> <name>Detached Submodule Digest</name>
<t>The Detached-Submodule-Digest type is similar to a submodule Clai ms-Set, except a digest of the Claims-Set is included in the claim with the Clai ms-Set contents conveyed separately. <t>The Detached-Submodule-Digest type is similar to a submodule Clai ms-Set, except a digest of the Claims-Set is included in the claim with the Clai ms-Set contents conveyed separately.
The separately-conveyed Claims-Set is called a detached claims set. The separately conveyed Claims-Set is called a "detached claims set".
The input to the digest algorithm is directly the CBOR or JSON-encoded Claims-Se
t for the submodule. <!--[rfced] Section 4.2.18.2. We updated this sentence to clarify
There is no byte-string wrapping or base 64 encoding.</t> "is directly". If it changes the intended meaning, please let us know.
<t>The data type for this type of submodule is an array consisting o
f two data items: an algorithm identifier and a byte string containing the diges Original:
t. The hash algorithm identifier is always from the COSE Algorithm registry, <xr The input to the digest algorithm is directly the CBOR or
ef target="IANA.COSE.Algorithms"/>. Either the integer or string identifier may JSON-encoded Claims-Set for the submodule.
be used. The hash algorithm identifier is never from the JOSE Algorithm registry
.</t> Current:
<t>A detached EAT bundle, described in <xref target="DEB"/>, may be The direct input to the digest algorithm is either the
used to convey detached claims sets and the EAT containing the corresponding det CBOR-encoded or the JSON-encoded Claims-Set for the
ached digests. submodule.
EAT, however, does not require use of a detached EAT bundle. -->
Any other protocols may be used to convey detached claims sets and the EAT conta
ining the corresponding detached digests. The direct input to the digest algorithm is either the CBOR-encoded or the JSON-
If detached Claims-Sets are modified in transit then validation can fail.</t> encoded Claims-Set for the submodule.
There is no byte string wrapping or base64 encoding.</t>
<t>The data type for this type of submodule is an array consisting of two data i
tems: an algorithm identifier and a byte string containing the digest. The hash
algorithm identifier is always from the "COSE Algorithms" registry <xref target=
"IANA.COSE.Algorithms"/>. Either the integer or the string identifier may be use
d. 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. 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 con
taining the corresponding detached digests.
If detached Claims-Sets are modified in transit, then validation can fail.</t>
</section> </section>
<section anchor="Nested-Token"> <section anchor="Nested-Token">
<name>Nested Tokens</name> <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, <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. Cl aims are represented in a signed EAT token.</t> i.e., it has keys distinct from the attester producing the surrounding token. Cl aims 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. <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 suc h binding and attackers could substitute a good attestation from another device for the attestation of an errant subsystem.</t> If it was conveyed in parallel with the surrounding token, there would be no suc h 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 to ken. <t>A nested token need not use the same encoding as the enclosing to ken.
This enables composite devices to be built without regards to the encoding used by components. 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> Thus, a CBOR-encoded EAT can have a JSON-encoded EAT as a nested token and vice versa.</t>
skipping to change at line 1148 skipping to change at line 1481
<name>iat (Timestamp) Claim</name> <name>iat (Timestamp) Claim</name>
<t>The "iat" claim defined in CWT and JWT is used to indicate the <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 date-of-creation of the token, the time at which the claims are
collected and the token is composed and signed.</t> collected and the token is composed and signed.</t>
<t>The data for some claims may be held or cached for some period of <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 time before the token is created. This period may be long, even
days. Examples are measurements taken at boot or a geographic days. Examples are measurements taken at boot or a geographic
position fix taken the last time a satellite signal was received. position fix taken the last time a satellite signal was received.
There are individual timestamps associated with these claims to There are individual timestamps associated with these claims to
indicate their age is older than the "iat" timestamp.</t> indicate their age is older than the "iat" timestamp.</t>
<t>CWT allows the use of floating-point for this claim. EAT disallows <t>CWT allows the use of floating-point for this claim, whereas EAT di sallows
the use of floating-point. An EAT token <bcp14>MUST NOT</bcp14> contain an "iat" claim in 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 floating-point format. Any recipient of a token with a floating-point
format "iat" claim <bcp14>MUST</bcp14> consider it an error.</t> format "iat" claim <bcp14>MUST</bcp14> consider it an error.</t>
<t>A 64-bit integer representation of the CBOR epoch-based time <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 <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 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> have precession greater than one second. This is not needed for EAT.</t>
</section> </section>
<section anchor="profile-claim"> <section anchor="profile-claim">
<name>eat_profile (EAT Profile) Claim</name> <name>eat_profile (EAT Profile) Claim</name>
<t>See <xref target="profiles"/> for the detailed description of an EA T profile.</t> <t>See <xref target="profiles"/> for the detailed description of an EA T profile.</t>
<t>The "eat_profile" claim identifies an EAT profile by either a Unifo rm Resource Identifier (URI) or an Object Identifier (OID). <t>The "eat_profile" claim identifies an EAT profile by either a Unifo rm Resource Identifier (URI) or an OID.
Typically, the URI will reference a document describing the profile. Typically, the URI will reference a document describing the profile.
An OID is just a unique identifier for the profile. An OID is just a unique identifier for the profile.
It may exist anywhere in the OID tree. It may exist anywhere in the OID tree.
There is no requirement that the named document be publicly accessible. There is no requirement that the named document be publicly accessible.
The primary purpose of the "eat_profile" claim is to uniquely identify the profi le even if it is a private profile.</t> The primary purpose of the "eat_profile" claim is to uniquely identify the profi le even if it is a private profile.</t>
<t>The OID is always absolute and never relative.</t> <t>The OID is always absolute and never relative.</t>
<t>See <xref target="common-types"/> for OID and URI encoding.</t> <t>See <xref target="common-types"/> for OID and URI encoding.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= (profile-label => general-uri / general-oid) $$Claims-Set-Claims //= (profile-label => general-uri / general-oid)]]></sourcec
]]></sourcecode> ode>
</section> </section>
<section anchor="intuse-intended-use-claim"> <section anchor="intuse-intended-use-claim">
<name>intuse (Intended Use) Claim</name> <name>intuse (Intended Use) Claim</name>
<t>EATs may be employed in the context of several different applicatio ns. <t>EATs may be employed in the context of several different applicatio ns.
The "intuse" claim provides an indication to an EAT consumer about the intended usage of the token. 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 disti This claim can be used as a way for an application using EAT to internally disti
nguish between different ways it utilizes EAT. nguish between different ways it utilizes EAT. The possible values are in the "E
The possible values are in the EAT Intended Use Registry defined in <xref target ntity Attestation Token (EAT) Intended Uses" registry defined in <xref target="i
="int-use-registry"/>.</t> nt-use-registry"/>.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
$$Claims-Set-Claims //= ( intended-use-label => intended-use-type ) $$Claims-Set-Claims //= ( intended-use-label => intended-use-type )
intended-use-type = JC< text, int> intended-use-type = JC< text, int>]]></sourcecode>
]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="DEB"> <section anchor="DEB">
<name>Detached EAT Bundles</name> <name>Detached EAT Bundles</name>
<t>A detached EAT bundle is a message to convey an EAT plus detached claim s sets secured by that EAT. <t>A detached EAT bundle is a message to convey an EAT plus detached claim s sets secured by that EAT.
It is a top-level message like a CWT or JWT. 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 as a submodule n It can occur in any place that a CWT or JWT occurs, for example, as a submodule
ested token as defined in <xref target="Nested-Token"/>.</t> nested token as defined in <xref target="Nested-Token"/>.</t>
<t>A detached EAT bundle may be either CBOR or JSON-encoded.</t> <t>A detached EAT bundle may be either CBOR or JSON encoded.</t>
<t>A detached EAT bundle consists of two parts.</t> <t>A detached EAT bundle consists of two parts.</t>
<t>The first part is an encoded EAT as follows:</t> <t>The first part is an encoded EAT that:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <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> <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>
<li> <li>
<t><bcp14>MAY</bcp14> be either CBOR or JSON-encoded and does not have to the the same as the encoding of the bundle</t> <t><bcp14>MAY</bcp14> be either CBOR or JSON encoded and does not have to be the same as the encoding of the bundle</t>
</li> </li>
<li> <li>
<t><bcp14>MAY</bcp14> be a CWT, or JWT or some future-defined token ty pe, but <bcp14>MUST NOT</bcp14> be a detached EAT bundle</t> <t><bcp14>MAY</bcp14> be a CWT, JWT, or some future-defined token type , but it <bcp14>MUST NOT</bcp14> be a detached EAT bundle</t>
</li> </li>
<li> <li>
<t><bcp14>MUST</bcp14> be authenticity and integrity protected</t> <t><bcp14>MUST</bcp14> be authenticity and integrity protected</t>
</li> </li>
</ul> </ul>
<t>The same mechanism for distinguishing the type for nested token submodu les is employed here.</t> <t>The same mechanism for distinguishing the type for nested token submodu les is employed here.</t>
<t>The second part is a map/object as follows:</t> <t>The second part is a map/object that:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t><bcp14>MUST</bcp14> be a Claims-Set</t> <t><bcp14>MUST</bcp14> be a Claims-Set</t>
</li> </li>
<li> <li>
<t><bcp14>MUST</bcp14> use the same encoding as the bundle</t> <t><bcp14>MUST</bcp14> use the same encoding as the bundle</t>
</li> </li>
<li> <li>
<t><bcp14>MUST</bcp14> be wrapped in a byte string when the encoding i s CBOR and be base64url-encoded when the encoding is JSON</t> <t><bcp14>MUST</bcp14> be wrapped in a byte string when the encoding i s CBOR and be base64url encoded when the encoding is JSON</t>
</li> </li>
</ul> </ul>
<t>For CBOR-encoded detached EAT bundles, tag 602 can be used to identify
it. <t>For a CBOR-encoded detached EAT bundle, tag 602 can be used to identify
it.
The standard rules apply for use or non-use of a tag. 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 fro m the other types of nested tokens.</t> When it is sent as a submodule, it is always sent as a tag to distinguish it fro m the other types of nested tokens.</t>
<t>The digests of the detached claims sets are associated with detached Cl aims-Sets by label/name. <t>The digests of the detached claims sets are associated with detached Cl aims-Sets by label/name.
It is up to the constructor of the detached EAT bundle to ensure the names uniqu ely identify the detached claims sets. 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> Since the names are used only in the detached EAT bundle, they can be very short , perhaps one byte.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
BUNDLE-Messages = BUNDLE-Tagged-Message / BUNDLE-Untagged-Message BUNDLE-Messages = BUNDLE-Tagged-Message / BUNDLE-Untagged-Message
BUNDLE-Tagged-Message = #6.602(BUNDLE-Untagged-Message) BUNDLE-Tagged-Message = #6.602(BUNDLE-Untagged-Message)
BUNDLE-Untagged-Message = Detached-EAT-Bundle BUNDLE-Untagged-Message = Detached-EAT-Bundle
Detached-EAT-Bundle = [ Detached-EAT-Bundle = [
main-token : Nested-Token, main-token : Nested-Token,
detached-claims-sets: { detached-claims-sets: {
+ tstr => JC-NEST-SAFE<json-wrapped-claims-set, + tstr => JC-NEST-SAFE<json-wrapped-claims-set,
cbor-wrapped-claims-set> cbor-wrapped-claims-set>
} }
] ]
json-wrapped-claims-set = base64-url-text json-wrapped-claims-set = base64-url-text
cbor-wrapped-claims-set = bstr .cbor Claims-Set cbor-wrapped-claims-set = bstr .cbor Claims-Set]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="profiles"> <section anchor="profiles">
<name>Profiles</name> <name>Profiles</name>
<t>EAT makes normative use of CBOR, JSON, COSE, JOSE, CWT and JWT. <t>EAT makes normative use of CBOR, JSON, COSE, JOSE, CWT, and JWT.
Most of these have implementation options to accommodate a range of use cases.</ t> 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 al <t>For example, COSE does not require a particular set of cryptographic al
gorithms so as to accommodate different usage scenarios and evolution of algorit gorithms so as to accommodate different usage scenarios and evolution of algorit
hms over time. hms over time. <xref target="RFC9052" sectionFormat="of" section="10"/> describe
Section 10 of <xref target="RFC9052"/> describes the profiling considerations fo s the profiling considerations for COSE.</t>
r COSE.</t>
<t>The use of encryption is optional for both CWT and JWT. <t>The use of encryption is optional for both CWT and JWT.
Section 8 of <xref target="RFC7519"/> describes implementation requirement and r <xref target="RFC7519" sectionFormat="of" section="8"/> describes implementation
ecommendations for JWT.</t> requirements and recommendations for JWT.</t>
<t>Similarly, CBOR provides indefinite length encoding, which is not commo <t>Similarly, CBOR provides indefinite-length encoding, which is not commo
nly used, but valuable for very constrained devices. nly used but is valuable for very constrained devices.
For EAT itself, in a particular use case some claims will be used and others wil l not. For EAT itself, in a particular use case some claims will be used and others wil l not.
Section 4 of <xref target="RFC8949"/> describes serialization considerations for <xref target="RFC8949" sectionFormat="of" section="4"/> describes serialization
CBOR.</t> considerations for CBOR.</t>
<t>For example a mobile phone use case may require the device make and mod <t>For example, a mobile phone use case may require the device make and mo
el, and prohibit UEID and location for privacy reasons. del 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> 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 gu arantee interoperability. <t>It is necessary to explicitly narrow these implementation options to gu arantee interoperability.
EAT chooses one general and explicit mechanism, the profile, to indicate the cho ices made for these implementation options for all aspects of the token.</t> EAT chooses one general and explicit mechanism, the profile, to indicate the cho ices 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 pro file.</t> <t>Below is a list of the various issues that should be addressed by a pro file.</t>
<t>The "eat_profile" claim in <xref target="profile-claim"/> provides a un ique identifier for the profile a particular token uses.</t> <t>The "eat_profile" claim in <xref target="profile-claim"/> provides a un ique identifier for the profile a particular token uses.</t>
<t>A profile can apply to evidence or to attestation results or both.</t> <t>A profile can apply to evidence results, attestation results, or both.< /t>
<section anchor="format-of-a-profile-document"> <section anchor="format-of-a-profile-document">
<name>Format of a Profile Document</name> <name>Format of a Profile Document</name>
<t>A profile document does not have to be in any particular format. It m <t>A profile document does not have to be in any particular format. It m
ay be simple text, something more formal or a combination.</t> ay be simple text, something more formal, or a combination of both.</t>
<t>A profile may define, and possibly register, one or more new claims i <t>A profile may define, and possibly register, one or more new claims i
f needed. A profile may also reuse one or more already defined claims, either as f needed. A profile may also reuse one or more already defined claims either as
-is or with values constrained to a subset or subrange.</t> is or with values constrained to a subset or subrange.</t>
</section> </section>
<section anchor="full-and-partial-profiles"> <section anchor="full-and-partial-profiles">
<name>Full and Partial Profiles</name> <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. <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> 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 t he sender that the receiver is not required to support is a partial profile. <t>For example, a profile that allows the use of signing algorithms by t he 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> 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 r <t>Full profiles <bcp14>MUST</bcp14> be complete such that a complying r
eceiver can decode, verify and check for freshness every EAT created by a comply eceiver can decode, verify, and check for freshness for every EAT created by a c
ing sender. omplying sender.
Full profiles do not need to require the receiver fully handle every claim in an Full profiles do not need to require the receiver to fully handle every claim in
EAT from a complying sender. an EAT from a complying sender.
Profile specifications may assume the receiver has access to the necessary verif ication keys or may go into specific detail on the means to access verification keys.</t> Profile specifications may assume the receiver has access to the necessary verif ication 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 p artial profiles.</t> <t>The "eat_profile" claim <bcp14>MUST NOT</bcp14> be used to identify p artial profiles.</t>
<t>While fewer profiles are preferrable, sometimes several may be needed for a use case. <t>While fewer profiles are preferable, sometimes several may be needed for a use case.
One approach to handling variation in devices might be to define several full pr ofiles that are variants of each other. One approach to handling variation in devices might be to define several full pr ofiles that are variants of each other.
It is relatively easy and inexpensive to define profiles as they do not have to be standards track and do not have to be registered anywhere. It is relatively easy and inexpensive to define profiles as they do not have to be 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. 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 curren t use. First, define a full profile for a set of non-post-quantum algorithms for curren t use.
Then, when post-quantum algorithms are settled, define another full profile deri ved from the first.</t> Then, when post-quantum algorithms are settled, define another full profile deri ved from the first.</t>
</section> </section>
<section anchor="list-of-profile-issues"> <section anchor="list-of-profile-issues">
<name>List of Profile Issues</name> <name>List of Profile Issues</name>
<t>The following is a list of EAT, CWT, JWT, COSE, JOSE and CBOR options that a profile should address.</t> <t>The following is a list of EAT, CWT, JWT, COSE, JOSE, and CBOR option s that a profile should address.</t>
<section anchor="use-of-json-cbor-or-both"> <section anchor="use-of-json-cbor-or-both">
<name>Use of JSON, CBOR or both</name> <name>Use of JSON, CBOR, or Both</name>
<t>A profile should specify whether CBOR, JSON or both may be sent. <t>A profile should specify whether CBOR, JSON, or both may be sent.
A profile should specify that the receiver can accept all encodings that the sen der is allowed to send.</t> A profile should specify that the receiver can accept all encodings that the sen der is allowed to send.</t>
<t>This should be specified for the top-level and all nested tokens. <t>This should be specified for the top level and all nested tokens.
For example, a profile might require all nested tokens to be of the same encodin For example, a profile might require all nested tokens to be of the same encodin
g of the top level token.</t> g of the top-level token.</t>
</section> </section>
<section anchor="cbor-map-and-array-encoding"> <section anchor="cbor-map-and-array-encoding">
<name>CBOR Map and Array Encoding</name> <name>CBOR Map and Array Encoding</name>
<t>A profile should specify whether definite-length arrays/maps, indef <t>A profile should specify whether definite-length arrays/maps, indef
inite-length arrays/maps or both may be sent. inite-length arrays/maps, or both may be sent.
A profile should specify that the receiver be able to accept all length encoding A profile should specify that the receiver accepts all length encodings that the
s that the sender is allowed to send.</t> sender is allowed to send.</t>
<t>This applies to individual EAT claims, CWT and COSE parts of the im <t>This applies to individual EAT claims, CWT, and COSE parts of the i
plementation.</t> mplementation.</t>
<t>For most use cases, specifying that only definite-length arrays/map s may be sent is suitable.</t> <t>For most use cases, specifying that only definite-length arrays/map s may be sent is suitable.</t>
</section> </section>
<section anchor="cbor-string-encoding"> <section anchor="cbor-string-encoding">
<name>CBOR String Encoding</name> <name>CBOR String Encoding</name>
<t>A profile should specify whether definite-length strings, indefinit <t>A profile should specify whether definite-length strings, indefinit
e-length strings or both may be sent. e-length strings, or both may be sent.
A profile should specify that the receiver be able to accept all types of string A profile should specify that the receiver accepts all types of string encodings
encodings that the sender is allowed to send.</t> that the sender is allowed to send.</t>
<t>For most use cases, specifying that only definite-length strings ma y be sent is suitable.</t> <t>For most use cases, specifying that only definite-length strings ma y be sent is suitable.</t>
</section> </section>
<section anchor="cbor-preferred-serialization"> <section anchor="cbor-preferred-serialization">
<name>CBOR Preferred Serialization</name> <name>CBOR Preferred Serialization</name>
<t>A profile should specify whether or not CBOR preferred serializatio n must be sent or not. <t>A profile should specify whether or not CBOR preferred serializatio n must be sent or not.
A profile should specify the receiver be able to accept preferred and/or non-pre ferred serialization so it will be able to accept anything sent by the sender.</ t> A profile should specify that the receiver accepts preferred and/or non-preferre d serialization, so it will be able to accept anything sent by the sender.</t>
</section> </section>
<section anchor="cbor-tags"> <section anchor="cbor-tags">
<name>CBOR Tags</name> <name>CBOR Tags</name>
<t>The profile should specify whether the token should be a CWT Tag or not.</t> <t>The profile should specify whether the token should be a CWT tag or not.</t>
<t>When COSE protection is used, the profile should specify whether CO SE tags are used or not. <t>When COSE protection is used, the profile should specify whether CO SE tags are used or not.
Note that RFC 8392 requires COSE tags be used in a CWT tag.</t> Note that RFC 8392 requires COSE tags be used in a CWT tag.</t>
<t>Often a tag is unnecessary because the surrounding or carrying prot ocol identifies the object as an EAT.</t> <t>Often, a tag is unnecessary because the surrounding or carrying pro tocol identifies the object as an EAT.</t>
</section> </section>
<section anchor="message-type"> <section anchor="message-type">
<name>COSE/JOSE Protection</name> <name>COSE/JOSE Protection</name>
<t>COSE and JOSE have several options for signed, MACed and encrypted messages. <t>COSE and JOSE have several options for signed, MACed, and encrypted messages.
JWT may use the JOSE NULL protection option. JWT may use the JOSE NULL protection option.
It is possible to implement no protection, sign only, MAC only, sign then encryp t and so on. It is possible to implement no protection, sign only, MAC only, sign then encryp t, and so on.
All combinations allowed by COSE, JOSE, JWT, and CWT are allowed by EAT.</t> All combinations allowed by COSE, JOSE, JWT, and CWT are allowed by EAT.</t>
<t>A profile should specify all signing, encryption and MAC message fo rmats that may be sent. <t>A profile should specify all signing, encryption, and MAC message f ormats that may be sent.
For example, a profile might allow only COSE_Sign1 to be sent. For example, a profile might allow only COSE_Sign1 to be sent.
For another example, a profile might allow COSE_Sign and COSE_Encrypt to be sent 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 encryptio to carry multiple signatures for post quantum cryptography and to use encryption
n to provide confidentiality.</t> to provide confidentiality.</t>
<t>A profile should specify the receiver accepts all message formats t <t>A profile should specify that the receiver accepts all message form
hat are allowed to be sent.</t> ats that are allowed to be sent.</t>
<t>When both signing and encryption are allowed, a profile should spec ify which is applied first.</t> <t>When both signing and encryption are allowed, a profile should spec ify which is applied first.</t>
</section> </section>
<section anchor="cosejose-algorithms"> <section anchor="cosejose-algorithms">
<name>COSE/JOSE Algorithms</name> <name>COSE/JOSE Algorithms</name>
<t>See the section on "Application Profiling Considerations" in <xref target="RFC9052"/> for a discussion on selection of cryptographic algorithms and related issues.</t> <t>See "Application Profiling Considerations" (<xref target="RFC9052" sectionFormat="of" section="10"/>) for a discussion on the selection of cryptogr aphic 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>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 ea ch COSE and JOSE message type allowed by the profile per <xref target="message-t ype"/>. <t>If not, the profile document should list a set of algorithms for ea ch COSE and JOSE message type allowed by the profile per <xref target="message-t ype"/>.
The verifier should implement all of them. The verifier should implement all of them.
The attester may implement any of them it wishes, possibly just one for each mes sage type.</t> The attester may implement any of them it wishes, possibly just one for each mes sage type.</t>
<t>If detached submodule digests are used the profile should address t he determination of the hash algorithm(s) for the digests.</t> <t>If detached submodule digests are used, the profile should address the determination of the hash algorithm(s) for the digests.</t>
</section> </section>
<section anchor="detached-eat-bundle-support"> <section anchor="detached-eat-bundle-support">
<name>Detached EAT Bundle Support</name> <name>Detached EAT Bundle Support</name>
<t>A profile should specify whether or not a detached EAT bundle (<xre f target="DEB"/>) can be sent. <t>A profile should specify whether or not a detached EAT bundle (<xre f target="DEB"/>) can be sent.
A profile should specify that a receiver be able to accept a detached EAT bundle if the sender is allowed to send it.</t> A profile should specify that a receiver accepts a detached EAT bundle if the se nder is allowed to send it.</t>
</section> </section>
<section anchor="key-identification"> <section anchor="key-identification">
<name>Key Identification</name> <name>Key Identification</name>
<t>A profile should specify what must be sent to identify the verifica <t>A profile should specify what must be sent to identify the verifica
tion, decryption or MAC key or keys. tion, decryption, or MAC key(s).
If multiple methods of key identification may be sent, a profile should require If multiple methods of key identification may be sent, a profile should require
the receiver support them all.</t> the receiver to support them all.</t>
<t><xref target="keyid"/> describes a number of methods for identifyin g verification keys. <t><xref target="keyid"/> describes a number of methods for identifyin g verification keys.
When encryption is used, there are further considerations. When encryption is used, there are further considerations.
In some cases key identification may be very simple and in others involve multip In some cases, key identification may be very simple, and in other case
le components. s, multiple components may be involved. For example, it may be simple through th
For example, it may be simple through use of COSE key ID or it may be complex th e use of a COSE key ID, or it may be complex through the use of an X.509 certifi
rough use of an X.509 certificate hierarchy.</t> cate hierarchy.</t>
<t>While not always possible, a profile should specify or make referen
ce to, a full end-end specification for key identification. <!--[rfced] Section 6.3.9. FYI, "end-end" has been updated to "end-to-end".
For example, a profile should specify in full detail how COSE key IDs are to be (This is similar to a change that was made in version 31 of the original.)
created, their lifecycle and such rather than just specifying that a COSE key ID
be used. Original:
For example, a profile should specify the full details of an X.509 hierarchy inc While not always possible, a profile should specify or make reference
luding extension processing, algorithms allowed and so on rather than just sayin to, a full end-end specification for key identification.
g X.509 certificates are used.</t>
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 refere
nce 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 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 inc
luding extension processing, algorithms allowed, and so on rather than just sayi
ng X.509 certificates are used.</t>
</section> </section>
<section anchor="endorsement-identification"> <section anchor="endorsement-identification">
<name>Endorsement Identification</name> <name>Endorsement Identification</name>
<t>Similar to, or perhaps the same as verification key identification,
the profile may wish to specify how endorsements are to be identified. <t>Similar to, or perhaps the same as, verification key identification
However note that endorsement identification is optional, whereas key identifica , the profile may wish to specify how endorsements are to be identified.
tion is not.</t> However, note that endorsement identification is optional, whereas key identific
ation is not.</t>
</section> </section>
<section anchor="freshness"> <section anchor="freshness">
<name>Freshness</name> <name>Freshness</name>
<t>Security considerations, see <xref target="sec-con-freshness"/>, re <t>Security considerations (see <xref target="sec-con-freshness"/>) re
quire a mechanism to provide freshness. quire a mechanism to provide freshness. This may be the EAT nonce claim in <xref
This may be the EAT nonce claim in <xref target="nonce"/>, or some claim or mech target="nonce"/> or some claim or mechanism defined outside this document. Seve
anism defined outside this document. ral options are described in "Freshness" (<xref target="RFC9334" sectionFormat="
The section on freshness in <xref target="RFC9334"/> describes several options. of" section="10"/>).
A profile should specify which freshness mechanism or mechanisms can be used.</t > 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 mu ltiple nonces may be sent. <t>If the EAT nonce claim is used, a profile should specify whether mu ltiple nonces may be sent.
If a profile allows multiple nonces to be sent, it should require the receiver t o process multiple nonces.</t> If a profile allows multiple nonces to be sent, it should require the receiver t o process multiple nonces.</t>
</section> </section>
<section anchor="claims-requirements"> <section anchor="claims-requirements">
<name>Claims Requirements</name> <name>Claims Requirements</name>
<t>A profile may define new claims that are not defined in this docume nt.</t> <t>A profile may define new claims that are not defined in this docume nt.</t>
<t>This document requires an EAT receiver must accept tokens with clai ms it does not understand. <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 rejec t tokens with claims it does not understand. A profile for a specific use case may reverse this and allow a receiver to rejec t tokens with claims it does not understand.
A profile for a specific use case may specify that specific claims are prohibite d.</t> A profile for a specific use case may specify that specific claims are prohibite d.</t>
<t>A profile for a specific use case may modify this and specify that some claims are required.</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 i n this document or elsewhere. <t>A profile may constrain the definition of claims that are defined i n this document or elsewhere.
For example, a profile may require the EAT nonce be a certain length or the "loc For example, a profile may require the EAT nonce to be a certain length or the "
ation" claim always include the altitude.</t> location" claim to always include the altitude.</t>
<t>Some claims are "pluggable" in that they allow different formats fo <t>Some claims are "pluggable" in that they allow different formats for their co
r their content. ntent.
<!--[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 an d "measurements" (<xref target="measurements"/>) claims are examples of this, al lowing the use of CoSWID and other formats. The "manifests" claim (<xref target="manifests"/>) along with the measurement an d "measurements" (<xref target="measurements"/>) claims are examples of this, al lowing the use of CoSWID and other formats.
A profile should specify which formats are allowed to be sent, with the assumpti on that the corresponding CoAP content types have been registered. A profile should specify which formats are allowed to be sent, with the assumpti on 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> 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 <t>Further, if there is variation within a format that is allowed, the profile s
profile should specify which variations can be sent. hould specify which variations can be sent.
For example, there are variations in the CoSWID format.
A profile that require the receiver to accept all variations that are allowed to <!--[rfced] Section 6.3.12. FYI - We updated the following text as the
be sent.</t> 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> </section>
<section anchor="the-constrained-device-standard-profile"> <section anchor="the-constrained-device-standard-profile">
<name>The Constrained Device Standard Profile</name> <name>The Constrained Device Standard Profile</name>
<t>It is anticipated that there will be many profiles defined for EAT fo r many different use cases. <t>It is anticipated that there will be many profiles defined for EAT fo r many different use cases.
This section gives a normative definition of one profile that is good for many c This section gives a normative definition of one profile that is good for
onstrained device use cases.</t> many constrained device use cases.</t>
<t>The identifier for this profile is "urn:ietf:rfc:rfcTBD".</t> <t>The identifier for this profile is "urn:ietf:rfc:rfc9711".</t>
<t><cref anchor="to-be-removed-1">RFC Editor: please replace rfcTBD with
this RFC number and remove this note.</cref></t> <table align="left" anchor="constrained-profile">
<table anchor="constrained-profile">
<name>Constrained Device Profile Definition</name> <name>Constrained Device Profile Definition</name>
<thead> <thead>
<tr> <tr>
<th align="left">Issue</th> <th align="left">Issue</th>
<th align="left">Profile Definition</th> <th align="left">Profile Definition</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">CBOR/JSON</td> <td align="left">CBOR/JSON</td>
<td align="left">CBOR <bcp14>MUST</bcp14> be used</td> <td align="left">CBOR <bcp14>MUST</bcp14> be used.</td>
</tr> </tr>
<tr> <tr>
<td align="left">CBOR Encoding</td> <td align="left">CBOR Encoding</td>
<td align="left">Definite length maps and arrays <bcp14>MUST</bcp1 4> be used</td> <td align="left">Definite-length maps and arrays <bcp14>MUST</bcp1 4> be used.</td>
</tr> </tr>
<tr> <tr>
<td align="left">CBOR Encoding</td> <td align="left">CBOR Encoding</td>
<td align="left">Definite length strings <bcp14>MUST</bcp14> be us ed</td> <td align="left">Definite-length strings <bcp14>MUST</bcp14> be us ed.</td>
</tr> </tr>
<tr> <tr>
<td align="left">CBOR Serialization</td> <td align="left">CBOR Serialization</td>
<td align="left">Preferred serialization <bcp14>MUST</bcp14> be us ed</td> <td align="left">Preferred serialization <bcp14>MUST</bcp14> be us ed.</td>
</tr> </tr>
<tr> <tr>
<td align="left">COSE Protection</td> <td align="left">COSE Protection</td>
<td align="left">COSE_Sign1 <bcp14>MUST</bcp14> be used</td> <td align="left">COSE_Sign1 <bcp14>MUST</bcp14> be used.</td>
</tr> </tr>
<tr> <tr>
<td align="left">Algorithms</td> <td align="left">Algorithms</td>
<td align="left">The receiver <bcp14>MUST</bcp14> accept ES256, ES 384 and ES512; the sender <bcp14>MUST</bcp14> send one of these</td> <td align="left">The receiver <bcp14>MUST</bcp14> accept ES256, ES 384, and ES512; the sender <bcp14>MUST</bcp14> send one of these.</td>
</tr> </tr>
<tr> <tr>
<td align="left">Detached EAT Bundle Usage</td> <td align="left">Detached EAT Bundle Usage</td>
<td align="left">Detached EAT bundles <bcp14>MUST NOT</bcp14> be s ent with this profile</td> <td align="left">Detached EAT bundles <bcp14>MUST NOT</bcp14> be s ent with this profile.</td>
</tr> </tr>
<tr> <tr>
<td align="left">Verification Key Identification</td> <td align="left">Verification Key Identification</td>
<td align="left">Either the COSE kid or the UEID <bcp14>MUST</bcp1 4> 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 veri fication keys which allows lookup of the verification key ID; the key format and means of distribution are beyond the scope of this profile)</td> <td align="left">Either the COSE key identifier (kid) or the UEID <bcp14>MUST</bcp14> be used to identify the verification key. If both are presen t, the kid takes precedence. (It is assumed the receiver has access to a databas e of trusted verification 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>
</tr> </tr>
<tr> <tr>
<td align="left">Endorsements</td> <td align="left">Endorsements</td>
<td align="left">This profile contains no endorsement identifier</ td> <td align="left">This profile contains no endorsement identifier.< /td>
</tr> </tr>
<tr> <tr>
<td align="left">Freshness</td> <td align="left">Freshness</td>
<td align="left">A new single unique nonce <bcp14>MUST</bcp14> be used for every token request</td> <td align="left">A new single unique nonce <bcp14>MUST</bcp14> be used for every token request.</td>
</tr> </tr>
<tr> <tr>
<td align="left">Claims</td> <td align="left">Claims</td>
<td align="left">No requirement is made on the presence or absence of claims other than requiring an EAT nonce. As per general EAT rules, the rece iver <bcp14>MUST NOT</bcp14> error out on claims it does not understand.</td> <td align="left">No requirement is made for the presence or absenc e of claims other than requiring an EAT nonce. As per general EAT rules, the rec eiver <bcp14>MUST NOT</bcp14> error out on claims it does not understand.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Any profile with different requirements than those above <bcp14>MUST< /bcp14> have a different profile identifier.</t> <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 pr ofile, even claims not defined in this document. <t>Note that many claims can be present for tokens conforming to this pr ofile, 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. 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 identificatio n, it is not in conformance with this profile. For example, if a kid (key identifier) or UEID is not used for key identificatio n, it is not in conformance with this profile.
For another example, requiring the presence of some claim is also not in conform ance and requires another profile.</t> As another example, requiring the presence of some claim is also not in conforma nce and requires another profile.</t>
<t>Derivations of this profile are encouraged. <t>Derivations of this profile are encouraged.
For example another profile may be simply defined as The Constrained Device Stan dard Profile plus the requirement for the presence of claim xxxx and claim yyyy. </t> For example, another profile may be simply defined as "The Constrained Device St andard Profile" plus the requirement for the presence of claim xxxx and claim yy yy.</t>
</section> </section>
</section> </section>
<section anchor="encoding"> <section anchor="encoding">
<name>Encoding and Collected CDDL</name> <name>Encoding and Collected CDDL</name>
<t>An EAT is fundamentally defined using CDDL. <t>An EAT is fundamentally defined using CDDL.
This document specifies how to encode the CDDL in CBOR or JSON. 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 exp ressed differently (e.g., labels) there is some CDDL that is specific to the enc oding.</t> Since CBOR can express some things that JSON cannot (e.g., tags) or that are exp ressed differently (e.g., labels), there is some CDDL that is specific to the en coding.</t>
<section anchor="claims-set-and-cddl-for-cwt-and-jwt"> <section anchor="claims-set-and-cddl-for-cwt-and-jwt">
<name>Claims-Set and CDDL for CWT and JWT</name> <name>Claims-Set and CDDL for CWT and JWT</name>
<t>CDDL was not used to define CWT or JWT. <t>CDDL was not used to define CWT or JWT.
It was not available at the time.</t> It was not available at the time.</t>
<t>This document defines CDDL for both CWT and JWT. <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> 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 and JWT. <t>A Claims-Set is the central data structure for EAT, CWT, and JWT.
It holds all the claims and is the structure that is secured by signing or other means. 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. 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 and JWT.</t> The CDDL definition of Claims-Set here is applicable to EAT, CWT, and JWT.</t>
<t>This document specifies how to encode a Claims-Set in CBOR or JSON.</ 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 <t>With the exception of nested tokens and some other externally
defined structures (e.g., SWIDs) an entire Claims-Set must be encoded defined structures (e.g., SWIDs), an entire Claims-Set must be encoded
in either CBOR or JSON, never a mixture.</t> 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 <xr ef target="RFC7519"/> is included here.</t> <t>CDDL for the seven claims defined by <xref target="RFC8392"/> and <xr ef target="RFC7519"/> is included here.</t>
</section> </section>
<section anchor="encoding-data-types"> <section anchor="encoding-data-types">
<name>Encoding Data Types</name> <name>Encoding Data Types</name>
<t>This makes use of the types defined in <xref target="RFC8610"/> Appen
dix D, Standard Prelude.</t> <!--[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 "Standard Prelude" (<xref targ
et="RFC8610" sectionFormat="of" section="D"/>).</t>
<section anchor="common-types"> <section anchor="common-types">
<name>Common Data Types</name> <name>Common Data Types</name>
<t>time-int is identical to the epoch-based time, but disallows <t>time-int is identical to the epoch-based time but disallows
floating-point representation.</t> floating-point representation.</t>
<t>For CBOR-encoded tokens, OIDs are specified using the CDDL type nam e "oid" from <xref target="RFC9090"/>. <t>For CBOR-encoded tokens, OIDs are specified using the CDDL type nam e "oid" from <xref target="RFC9090"/>.
They are encoded without the tag number. They are encoded without the tag number.
For JSON-encoded tokens, OIDs are a text string in the common form of "nn.nn.nn. For JSON-encoded tokens, OIDs are text strings in the common form of "nn.nn.nn..
..".</t> .".</t>
<t>Unless expliclity indicated, URIs are not the URI tag defined in <x <t>Unless explicitly indicated, URIs are not the URI tag defined in <x
ref target="RFC8949"/>. ref target="RFC8949"/>.
They are just text strings that contain a URI conforming to the format defined i n <xref target="RFC3986"/>.</t> They are just text strings that contain a URI conforming to the format defined i n <xref target="RFC3986"/>.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
time-int = #6.1(int) time-int = #6.1(int)
binary-data = JC< base64-url-text, bstr> binary-data = JC< base64-url-text, bstr>
base64-url-text = tstr .regexp "[A-Za-z0-9_-]+" base64-url-text = tstr .regexp "[A-Za-z0-9_-]+"
general-oid = JC< json-oid, ~oid > general-oid = JC< json-oid, ~oid >
json-oid = tstr .regexp "([0-2])((\\.0)|(\\.[1-9][0-9]*))*" json-oid = tstr .regexp "([0-2])((\\.0)|(\\.[1-9][0-9]*))*"
general-uri = JC< text, ~uri > general-uri = JC< text, ~uri >
coap-content-format = uint .le 65535 coap-content-format = uint .le 65535]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="jsoninterop"> <section anchor="jsoninterop">
<name>JSON Interoperability</name> <name>JSON Interoperability</name>
<t>JSON should be encoded per <xref target="RFC8610"/>, Appendix E. In
addition, the <t>JSON should be encoded per <xref target="RFC8610" sectionFormat="of
following CDDL types are encoded in JSON as follows:</t> " section="E"/>. In addition, the following CDDL types are encoded in JSON as fo
llows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>bstr -- <bcp14>MUST</bcp14> be base64url-encoded</t> <t>bstr -- <bcp14>MUST</bcp14> be base64url encoded.</t>
</li> </li>
<li> <li>
<t>time -- <bcp14>MUST</bcp14> be encoded as NumericDate as descri bed in Section 2 of <xref target="RFC7519"/>.</t> <t>time -- <bcp14>MUST</bcp14> be encoded as NumericDate as descri bed in <xref target="RFC7519" sectionFormat="of" section="2"/>.</t>
</li> </li>
<li> <li>
<t>string-or-uri -- <bcp14>MUST</bcp14> be encoded as StringOrURI as described in Section 2 of <xref target="RFC7519"/>.</t> <t>string-or-uri -- <bcp14>MUST</bcp14> be encoded as StringOrURI as described in <xref target="RFC7519" sectionFormat="of" section="2"/>.</t>
</li> </li>
<li> <li>
<t>uri -- <bcp14>MUST</bcp14> be a URI <xref target="RFC3986"/>.</ t> <t>uri -- <bcp14>MUST</bcp14> be a URI <xref target="RFC3986"/>.</ t>
</li> </li>
<li> <li>
<t>oid -- <bcp14>MUST</bcp14> be encoded as a string using the wel l established dotted-decimal notation (e.g., the text "1.2.250.1") <xref target= "RFC4517"/>.</t> <t>oid -- <bcp14>MUST</bcp14> be encoded as a string using the wel l-established dotted-decimal notation (e.g., the text "1.2.250.1") <xref target= "RFC4517"/>.</t>
</li> </li>
</ul> </ul>
<t>The CDDL generic "JC&lt;&gt;" is used in most places where there is a variance between CBOR and JSON. <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 and the second is CDDL for CBOR.</t> The first argument is the CDDL for JSON, and the second is CDDL for CBOR.</t>
</section> </section>
<section anchor="labels"> <section anchor="labels">
<name>Labels</name> <name>Labels</name>
<t>Most map labels, Claims-Keys, Claim-Names and enumerated-type value <t>Most map labels, Claims-Keys, Claim-Names, and enumerated-type valu
s are integers for CBOR-encoded tokens and strings for JSON-encoded tokens. es are integers for CBOR-encoded tokens and strings for JSON-encoded tokens.
When this is the case the "JC&lt;&gt;" CDDL construct is used to give both the i When this is the case, the JC&lt;&gt; CDDL construct is used to give both the in
nteger and string values.</t> teger and string values.</t>
</section> </section>
<section anchor="cbor-interoperability"> <section anchor="cbor-interoperability">
<name>CBOR Interoperability</name> <name>CBOR Interoperability</name>
<t>CBOR allows data items to be serialized in more than one form to ac commodate a variety of use cases. <t>CBOR allows data items to be serialized in more than one form to ac commodate a variety of use cases.
This is addressed in <xref target="profiles"/>.</t> This is addressed in <xref target="profiles"/>.</t>
</section> </section>
</section> </section>
<section anchor="collected-cddl"> <section anchor="collected-cddl">
<name>Collected CDDL</name> <name>Collected CDDL</name>
<section anchor="payload-cddl"> <section anchor="payload-cddl">
<name>Payload CDDL</name> <name>Payload CDDL</name>
<t>This CDDL defines all the EAT Claims that are added to the main def <t>The payload CDDL defines all the EAT claims that are added to the m
inition of a Claim-Set in <xref target="CDDL_for_CWT"/>. ain definition of a Claims-Set in <xref target="CDDL_for_CWT"/>.
Claims-Set is the payload for CWT, JWT and potentially other token types. Claims-Set is the payload for CWT, JWT, and potentially other token types.
This is for both CBOR and JSON. 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 defin ed in <xref target="CDDL_for_CWT"/>. When there is variation between CBOR and JSON, the JC&lt;&gt; CDDL generic defin ed in <xref target="CDDL_for_CWT"/>.
Note that the JC&lt;&gt; generic uses the CDDL ".feature" control operator defin ed in <xref target="RFC9165"/>.</t> Note that the JC&lt;&gt; generic uses the CDDL ".feature" control operator defin ed in <xref target="RFC9165"/>.</t>
<t>This CDDL uses, but does not define Submodule or nested tokens beca use the definition for these types varies between CBOR and JSON and the JC&lt;&g t; generic cannot be used to define it. <t>This CDDL uses, but does not define, Submodule or nested tokens bec ause 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 J SON token and vice versa. The submodule claim is the one place where a CBOR token can be nested inside a J SON token and vice versa.
Encoding-specific definitions are provided in the following sections.</t> Encoding-specific definitions are provided in the following sections.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
time-int = #6.1(int) time-int = #6.1(int)
binary-data = JC< base64-url-text, bstr> binary-data = JC< base64-url-text, bstr>
base64-url-text = tstr .regexp "[A-Za-z0-9_-]+" base64-url-text = tstr .regexp "[A-Za-z0-9_-]+"
general-oid = JC< json-oid, ~oid > general-oid = JC< json-oid, ~oid >
json-oid = tstr .regexp "([0-2])((\\.0)|(\\.[1-9][0-9]*))*" json-oid = tstr .regexp "([0-2])((\\.0)|(\\.[1-9][0-9]*))*"
skipping to change at line 1787 skipping to change at line 2214
profile-label = JC< "eat_profile", 265 > profile-label = JC< "eat_profile", 265 >
submods-label = JC< "submods", 266 > submods-label = JC< "submods", 266 >
boot-count-label = JC< "bootcount", 267 > boot-count-label = JC< "bootcount", 267 >
boot-seed-label = JC< "bootseed", 268 > boot-seed-label = JC< "bootseed", 268 >
dloas-label = JC< "dloas", 269 > dloas-label = JC< "dloas", 269 >
sw-name-label = JC< "swname", 270 > sw-name-label = JC< "swname", 270 >
sw-version-label = JC< "swversion", 271 > sw-version-label = JC< "swversion", 271 >
manifests-label = JC< "manifests", 272 > manifests-label = JC< "manifests", 272 >
measurements-label = JC< "measurements", 273 > measurements-label = JC< "measurements", 273 >
measurement-results-label = JC< "measres" , 274 > measurement-results-label = JC< "measres" , 274 >
intended-use-label = JC< "intuse", 275 > intended-use-label = JC< "intuse", 275 >]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="cbor-specific-cddl"> <section anchor="cbor-specific-cddl">
<name>CBOR-Specific CDDL</name> <name>CBOR-Specific CDDL</name>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
EAT-CBOR-Token = $EAT-CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token EAT-CBOR-Token = $EAT-CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token
$EAT-CBOR-Tagged-Token /= CWT-Tagged-Message $EAT-CBOR-Tagged-Token /= CWT-Tagged-Message
$EAT-CBOR-Tagged-Token /= BUNDLE-Tagged-Message $EAT-CBOR-Tagged-Token /= BUNDLE-Tagged-Message
$EAT-CBOR-Untagged-Token /= CWT-Untagged-Message $EAT-CBOR-Untagged-Token /= CWT-Untagged-Message
$EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message $EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message
Nested-Token = CBOR-Nested-Token Nested-Token = CBOR-Nested-Token
skipping to change at line 1815 skipping to change at line 2242
JSON-Token-Inside-CBOR-Token / JSON-Token-Inside-CBOR-Token /
CBOR-Token-Inside-CBOR-Token CBOR-Token-Inside-CBOR-Token
CBOR-Token-Inside-CBOR-Token = bstr .cbor $EAT-CBOR-Tagged-Token CBOR-Token-Inside-CBOR-Token = bstr .cbor $EAT-CBOR-Tagged-Token
JSON-Token-Inside-CBOR-Token = tstr JSON-Token-Inside-CBOR-Token = tstr
$$Claims-Set-Claims //= (submods-label => { + text => Submodule }) $$Claims-Set-Claims //= (submods-label => { + text => Submodule })
Submodule = Claims-Set / CBOR-Nested-Token / Submodule = Claims-Set / CBOR-Nested-Token /
Detached-Submodule-Digest Detached-Submodule-Digest]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="json-specific-cddl"> <section anchor="json-specific-cddl">
<name>JSON-Specific CDDL</name> <name>JSON-Specific CDDL</name>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
EAT-JSON-Token = $EAT-JSON-Token-Formats EAT-JSON-Token = $EAT-JSON-Token-Formats
$EAT-JSON-Token-Formats /= JWT-Message $EAT-JSON-Token-Formats /= JWT-Message
$EAT-JSON-Token-Formats /= BUNDLE-Untagged-Message $EAT-JSON-Token-Formats /= BUNDLE-Untagged-Message
Nested-Token = JSON-Selector Nested-Token = JSON-Selector
JSON-Selector = $JSON-Selector JSON-Selector = $JSON-Selector
skipping to change at line 1842 skipping to change at line 2269
$JSON-Selector /= [type: "CBOR", nested-token: $JSON-Selector /= [type: "CBOR", nested-token:
CBOR-Token-Inside-JSON-Token] CBOR-Token-Inside-JSON-Token]
$JSON-Selector /= [type: "BUNDLE", nested-token: Detached-EAT-Bundle] $JSON-Selector /= [type: "BUNDLE", nested-token: Detached-EAT-Bundle]
$JSON-Selector /= [type: "DIGEST", nested-token: $JSON-Selector /= [type: "DIGEST", nested-token:
Detached-Submodule-Digest] Detached-Submodule-Digest]
CBOR-Token-Inside-JSON-Token = base64-url-text CBOR-Token-Inside-JSON-Token = base64-url-text
$$Claims-Set-Claims //= (submods-label => { + text => Submodule }) $$Claims-Set-Claims //= (submods-label => { + text => Submodule })
Submodule = Claims-Set / JSON-Selector Submodule = Claims-Set / JSON-Selector]]></sourcecode>
]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="privacyconsiderations"> <section anchor="privacyconsiderations">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>Certain EAT claims can be used to track the owner of an entity; <t>Certain EAT claims can be used to track the owner of an entity;
therefore, implementations should consider privacy-preserving therefore, implementations should consider privacy-preserving
options dependent on the usage of the EAT. options dependent on the usage of the EAT.
For example, the location claim might be suppressed in EATs sent to unauthentica ted consumers.</t> For example, the location claim might be suppressed in EATs sent to unauthentica ted consumers.</t>
<section anchor="ueidprivacyconsiderations"> <section anchor="ueidprivacyconsiderations">
<name>UEID and SUEID Privacy Considerations</name> <name>UEID and SUEID Privacy Considerations</name>
<t>A UEID is usually not privacy-preserving. Relying parties <t>A UEID is usually not privacy-preserving. Relying parties
receiving tokens from a particular entity will be receiving tokens from a particular entity will be
able to know the tokens are from the same entity and be able to able to know that the tokens are from the same entity and identify the entity is
identify the entity issuing those tokens.</t> suing those tokens.</t>
<t>Thus the use of the claim may violate privacy policies. In other usag <t>Thus, the use of the claim may violate privacy policies. In other usa
e situations a UEID will ge situations, a UEID will
not be allowed for certain products like browsers that give privacy not be allowed for certain products such as browsers that give privacy
for the end user. It will often be the case that tokens will not have for the end user. It will often be the case that tokens will not have
a UEID for these reasons.</t> a UEID for these reasons.</t>
<t>An SUEID is also usually not privacy-preserving. In some cases it ma <t>An SUEID is also usually not privacy-preserving. In some cases, it m
y ay
have fewer privacy issues than a UEID depending on when and how and have fewer privacy issues than a UEID depending on when and how it is generated.
when it is generated.</t> </t>
<t>There are several strategies that can be used to still be able to put <t>There are several strategies that can be used to still be able to put
UEIDs and SUEIDs in tokens:</t> UEIDs and SUEIDs in tokens:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The entity obtains explicit permission from the user of the entit y <t>The entity obtains explicit permission from the user of the entit y
to use the UEID/SUEID. This may be through a prompt. It may also be through to use the UEID/SUEID; this may be through a prompt or through
a license agreement. For example, agreements for some online banking a license agreement. For example, agreements for some online banking
and brokerage services might already cover use of a UEID/SUEID.</t> and brokerage services might already cover use of a UEID/SUEID.</t>
</li> </li>
<li> <li>
<t>The UEID/SUEID is used only in a particular context or particular use <t>The UEID/SUEID is used only in a particular context or use
case. It is used only by one relying party.</t> case. It is used only by one relying party.</t>
</li> </li>
<li> <li>
<t>The entity authenticates the relying party and generates a derive <t>The entity authenticates the relying party and generates a derive
d d UEID/SUEID just for that particular relying party. For example, the relying
UEID/SUEID just for that particular relying party. For example, the relying
party could prove their identity cryptographically to the entity, then party could prove their identity cryptographically to the entity, then
the entity generates a UEID just for that relying party by hashing a the entity generates a UEID just for that relying party by hashing a
proofed relying party ID with the main entity UEID/SUEID.</t> proofed relying party ID with the main entity UEID/SUEID.</t>
</li> </li>
</ul> </ul>
<t>Note that some of these privacy preservation strategies result in <t>Note that some of these privacy preservation strategies result in
multiple UEIDs and SUEIDs per entity. Each UEID/SUEID is used in a multiple UEIDs and SUEIDs per entity. Each UEID/SUEID is used in a
different context, use case or system on the entity. However, from the different context, use case, or system on the entity. However, from the
view of the relying party, there is just one UEID and it is still view of the relying party, there is just one UEID and it is still
globally universal across manufacturers.</t> globally universal across manufacturers.</t>
</section> </section>
<section anchor="locationprivacyconsiderations"> <section anchor="locationprivacyconsiderations">
<name>Location Privacy Considerations</name> <name>Location Privacy Considerations</name>
<t>Geographic location is most always considered personally identifiable <t>Geographic location is almost always considered personally identifiab
information. le information.
Implementers should consider laws and regulations governing the transmission of Implementors should consider laws and regulations governing the transmission of
location data from end user devices to servers and services. location data from end-user devices to servers and services.
Implementers should consider using location management facilities offered by the Implementors should consider using location management facilities offered by the
operating system on the entity generating the attestation. operating system on the entity generating the attestation.
For example, many mobile phones prompt the user for permission before sending lo cation data.</t> For example, many mobile phones prompt the user for permission before sending lo cation data.</t>
</section> </section>
<section anchor="bootseedprivacyconsiderations"> <section anchor="bootseedprivacyconsiderations">
<name>Boot Seed Privacy Considerations</name> <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 schem es that are privacy-preserving.</t> <t>The "bootseed" claim is effectively a stable entity identifier within a given boot epoch. Therefore, it is not suitable for use in attestation schem es that are privacy-preserving.</t>
</section> </section>
<section anchor="replayprivacyconsiderations"> <section anchor="replayprivacyconsiderations">
<name>Replay Protection and Privacy</name> <name>Replay Protection and Privacy</name>
<t>EAT defines the EAT nonce claim for replay protection and token fresh ness. <t>EAT defines the EAT nonce claim for replay protection and token fresh ness.
The nonce claim is based on a value usually derived remotely (outside of the ent ity). The nonce claim is based on a value usually derived remotely (outside of the ent ity).
This claim might be used to extract and convey personally identifying informatio n either inadvertently or by intention. This claim might be used to extract and convey personally identifying informatio n either inadvertently or by intention.
For instance, an implementor may choose a nonce equivalent to a username associa ted with the device (e.g., account login). For instance, an implementor may choose a nonce equivalent to a username associa ted with the device (e.g., account login).
If the token is inspected by a 3rd-party then this information could be used to identify the source of the token or an account associated with the token. If the token is inspected by a 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 sh ould be derived using a salt that originates from a true and reliable random num ber generator or any other source of randomness that would still meet the target system requirements for replay protection and token freshness.</t> To avoid the conveyance of privacy-related information in the nonce claim, it sh ould be derived using a salt that originates from a true and reliable random num ber 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> </section>
<section anchor="securitycons"> <section anchor="securitycons">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The security considerations provided in Section 8 of <xref target="RFC8 <t>The security considerations provided in <xref target="RFC8392" sectionF
392"/> and Section 11 ormat="of" section="8"/> and of <xref target="RFC7519" sectionFormat="of" sectio
of <xref target="RFC7519"/> apply to EAT in its CWT and JWT form, respectively. n="11"/> apply to EAT in its CWT and JWT form, respectively. Moreover, <xref ta
Moreover, Chapter 12 rget="RFC9334" sectionFormat="of" section="12"/> is also applicable to implement
of <xref target="RFC9334"/> is also applicable to implementations of EAT. In ad ations of EAT. In addition,
dition, implementors should consider the information in the following subsections.</t>
implementors should consider the following.</t>
<section anchor="claim-trustworthiness"> <section anchor="claim-trustworthiness">
<name>Claim Trustworthiness</name> <name>Claim Trustworthiness</name>
<t>This specification defines semantics for each claim. <t>This specification defines semantics for each claim.
It does not require any particular level of security in the implementation of th It does not require any particular level of security in the implementation of th
e claims or even the attester itself. e claims or even for the attester itself.
Such specification is far beyond the scope of this document which is about a mes Such specification is far beyond the scope of this document, which is about a me
sage format not the security level of an implementation.</t> ssage format not the security level of an implementation.</t>
<t>The receiver of an EAT comes to know the trustworthiness of the claim <t>The receiver of an EAT knows the trustworthiness of the claims in it by under
s in it by understanding the implementation made by the attester vendor and/or u standing the implementation made by the attester vendor and/or understanding the
nderstanding the checks and processing performed by the verifier.</t> 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>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. <t>The degree of security will vary from use case to use case.
In some cases the receiver may only need to know something of the implementation In some cases, the receiver may only need to know something of the implementatio
such as that it was implemented in a TEE. n such as that it was implemented in a TEE.
In other cases the receiver may require the attester be certified by a particula In other cases, the receiver may require the attester to be certified by a parti
r certification program. cular certification program.
Or perhaps the receiver is content with very little security.</t> Or perhaps the receiver is content with very little security.</t>
</section> </section>
<section anchor="key-provisioning"> <section anchor="key-provisioning">
<name>Key Provisioning</name> <name>Key Provisioning</name>
<t>Private key material can be used to sign and/or encrypt the EAT, or <t>Private key material can be used to sign and/or encrypt the EAT or
can be used to derive the keys used for signing and/or encryption. In to derive the keys used for signing and/or encryption. In
some instances, the manufacturer of the entity may create the key some instances, the manufacturer of the entity may create the key
material separately and provision the key material in the entity material separately and provision the key material in the entity
itself. The manufacturer of any entity that is capable of producing itself. The manufacturer of any entity that is capable of producing
an EAT should take care to ensure that any private key material be an EAT should take care to ensure that any private key material be
suitably protected prior to provisioning the key material in the suitably protected prior to provisioning the key material in the
entity itself. This can require creation of key material in an entity itself. This can require creation of key material in an
enclave (see <xref target="RFC4949"/> for definition of "enclave"), secure enclave (see <xref target="RFC4949"/> for definition of "enclave"), secure
transmission of the key material from the enclave to the entity using transmission of the key material from the enclave to the entity using
an appropriate protocol, and persistence of the private key material an appropriate protocol, and persistence of the private key material
in some form of secure storage to which (preferably) only the entity in some form of secure storage to which (preferably) only the entity
has access.</t> has access.</t>
<section anchor="transmission-of-key-material"> <section anchor="transmission-of-key-material">
<name>Transmission of Key Material</name> <name>Transmission of Key Material</name>
<t>Regarding transmission of key material from the enclave to the enti ty, <t>Regarding transmission of key material from the enclave to the enti ty,
the key material may pass through one or more intermediaries. the key material may pass through one or more intermediaries.
Therefore some form of protection ("key wrapping") may be necessary. Therefore, some form of protection (e.g., key wrapping) may be necessary.
The transmission itself may be performed electronically, but can also The transmission itself may be performed electronically, but it can also
be done by human courier. In the latter case, there should be minimal 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. encrypted to no exposure of the key material to the human (e.g., encrypted
portable memory). Moreover, the human should transport the key portable memory). Moreover, the human should transport the key
material directly from the secure enclave where it was created to a material directly from the secure enclave where it was created to a
destination secure enclave where it can be provisioned.</t> destination secure enclave where it can be provisioned.</t>
</section> </section>
</section> </section>
<section anchor="sec-con-freshness"> <section anchor="sec-con-freshness">
<name>Freshness</name> <name>Freshness</name>
<t>All EAT use <bcp14>MUST</bcp14> provide a freshness mechanism to prev <t>All EAT use <bcp14>MUST</bcp14> provide a freshness mechanism to prev
ent replay and related attacks. ent replay and related attacks. The extensive discussions in <xref target="RFC93
The extensive discussions on freshness in <xref target="RFC9334"/> including sec 34"/> on freshness, as well as the security considerations, apply here. One opti
urity considerations apply here. on to provide freshness is the EAT nonce claim (<xref target="nonce"/>).</t>
The EAT nonce claim, in <xref target="nonce"/>, is one option to provide freshne
ss.</t>
</section> </section>
<section anchor="multiple-eat-consumers"> <section anchor="multiple-eat-consumers">
<name>Multiple EAT Consumers</name> <name>Multiple EAT Consumers</name>
<t>In many cases, more than one EAT consumer may be required to fully <t>In many cases, more than one EAT consumer may be required to fully
verify the entity attestation. Examples include individual consumers verify the entity attestation. Examples include individual consumers
for nested EATs, or consumers for individual claims with an EAT. When for nested EATs or consumers for individual claims with an EAT. When
multiple consumers are required for verification of an EAT, it is multiple consumers are required for verification of an EAT, it is
important to minimize information exposure to each consumer. In important to minimize information exposure to each consumer. In
addition, the communication between multiple consumers should be addition, the communication between multiple consumers should be
secure.</t> secure.</t>
<t>For instance, consider the example of an encrypted and signed EAT wit h <t>For instance, consider the example of an encrypted and signed EAT wit h
multiple claims. A consumer may receive the EAT (denoted as the multiple claims. A consumer may receive the EAT (denoted as the
"receiving consumer"), decrypt its payload, verify its signature, but "receiving consumer"), decrypt its payload, and verify its signature but
then pass specific subsets of claims to other consumers for evaluation then pass specific subsets of claims to other consumers for evaluation
("downstream consumers"). Since any COSE encryption will be removed ("downstream consumers"). Since any COSE encryption will be removed
by the receiving consumer, the communication of claim subsets to any by the receiving consumer, the communication of claim subsets to any
downstream consumer <bcp14>MUST</bcp14> leverage an equivalent communication sec urity protocol downstream consumer <bcp14>MUST</bcp14> leverage an equivalent communication sec urity protocol
(e.g. Transport Layer Security).</t> (e.g., TLS).</t>
<t>However, assume the EAT of the previous example is hierarchical and <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 each claim subset for a downstream consumer is created in the form of
a nested EAT. Then the nested EAT is itself encrypted and cryptographically ver a nested EAT. Then, the nested EAT itself is encrypted and cryptographically ve
ifiable (due to its rifiable (due to its COSE envelope) by a downstream consumer (unlike the previou
COSE envelope) s example where a claims set
by a downstream consumer (unlike the previous example where a claims set without a COSE envelope is sent to a downstream consumer). Therefore, TLS betwe
without a COSE envelope is sent to a downstream consumer). Therefore, Transport en the receiving and downstream consumers is not strictly required. Nevertheles
Layer Security between the receiving and s,
downstream consumers is not strictly required. Nevertheless,
downstream consumers of a nested EAT should provide a nonce unique to downstream consumers of a nested EAT should provide a nonce unique to
the EAT they are consuming.</t> the EAT they are consuming.</t>
</section> </section>
<section anchor="detached-eat-bundle-digest-security-considerations"> <section anchor="detached-eat-bundle-digest-security-considerations">
<name>Detached EAT Bundle Digest Security Considerations</name> <name>Detached EAT Bundle Digest Security Considerations</name>
<t>A detached EAT bundle is composed of a nested EAT and <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 v ulnerable to a claims set as per <xref target="DEB"/>. Although the attached claims set is v ulnerable to
modification in transit, any modification can be detected by the receiver throug modification in transit, any modification can be detected by the receiver throug
h the associated h the associated digest, which is a claim fully contained within an EAT. Moreov
digest, which is a claim fully contained within an EAT. Moreover, the digest it er, the digest itself can only be derived using
self can only be derived using
an appropriate COSE hash algorithm, implying that an attacker cannot induce fals e detection an appropriate COSE hash algorithm, implying that an attacker cannot induce fals e detection
of modified detached claims because the algorithms in the COSE registry are assu med to be of modified detached claims because the algorithms in the COSE registry are assu med to be
of sufficient cryptographic strength.</t> of sufficient cryptographic strength.</t>
</section> </section>
<section anchor="verfication-key-sc"> <section anchor="verfication-key-sc">
<name>Verification Keys</name> <name>Verification Keys</name>
<t>In all cases there must be some way that the verification key is itse <t>In all cases, there must be some way that the verification key itself
lf verified or determined to be trustworthy. is verified or determined to be trustworthy. The key identification itself is n
The key identification itself is never enough. ever enough.
This will always be by some out-of-band mechanism that is not described here. 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> For example, the verifier may be configured with a root certificate or a master key by the verifier system administrator.</t>
<t>Often an X.509 certificate or an endorsement carries more than just t he verification key. <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 endor sement might have reference values. For example, an X.509 certificate might have key usage constraints, and an endor sement might have reference values.
When this is the case, the key identifier must be either a protected header or i n the payload, such that it is cryptographically bound to the EAT. When this is the case, the key identifier must be either a protected header or i n 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 JSON Web Signature <xref target="RFC7515"/>.</t> This is in line with the requirements in "Key Identification" of JSON Web Signat ure (<xref target="RFC7515" sectionFormat="of" section="6"/>).</t>
</section> </section>
</section> </section>
<section anchor="iana-cons"> <section anchor="iana-cons">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="reuse-of-cbor-and-json-web-token-cwt-and-jwt-claims-regis tries"> <section anchor="reuse-of-cbor-and-json-web-token-cwt-and-jwt-claims-regis tries">
<name>Reuse of CBOR and JSON Web Token (CWT and JWT) Claims Registries</ name> <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 <t>Claims defined for EAT are compatible with those of CWT and JWT,
so the CWT and JWT Claims Registries, <xref target="IANA.CWT.Claims"/> and <xref so the CWT and JWT Claims registries, <xref target="IANA.CWT.Claims"/> and <xref
target="IANA.JWT.Claims"/>, are re-used. No new IANA registry target="IANA.JWT.Claims"/>, are reused. No new IANA registry
is created.</t> is created.</t>
<t>All EAT claims defined in this document are placed in both registries . <t>All EAT claims defined in this document have been placed in both regi stries.
All new EAT claims defined subsequently should be placed in both registries.</t> 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> <t><xref target="Claim_Characteristics"/> describes some considerations when defining new claims.</t>
</section> </section>
<section anchor="cwt-and-jwt-claims-registered-by-this-document"> <section anchor="cwt-and-jwt-claims-registered-by-this-document">
<name>CWT and JWT Claims Registered by This Document</name> <name>CWT and JWT Claims Registered by This Document</name>
<t>This specification adds the following values to the "JSON Web Token <t>Per this specification, the following values have been added to the "
Claims" registry established by <xref target="RFC7519"/> and the "CBOR Web Token JSON Web Token
Claims Registry" Claims" registry established by <xref target="RFC7519"/> and the "CBOR Web Token
established by <xref target="RFC8392"/>. (CWT) Claims" registry established by <xref target="RFC8392"/>.
Each entry below is an addition to both registries.</t> Each entry below has been added to both registries.</t>
<t>The "Claim Description", "Change Controller" and "Specification Docum <t>The "Claim Description", "Change Controller", and "Reference" fields are comm
ents" are common and equivalent for the JWT and CWT registries. on and equivalent for the JWT and CWT registries. The "Claim Key" and "Claim Val
The "Claim Key" and "Claim Value Types(s)" are for the CWT registry only. ue Type" fields are for the CWT registry only.
The "Claim Name" is as defined for the CWT registry, not the JWT registry. The "Claim Name" field is as defined for the CWT registry, not the JWT registry.
The "JWT Claim Name" is equivalent to the "Claim Name" in the JWT registry.</t> The "JWT Claim Name" field is equivalent to the "Claim Name" field in the JWT re
<t>IANA is requested to register the following claims. gistry.</t>
The "Claim Value Type(s)" here all name CDDL definitions and are only for the CW <t>IANA has registered the following claims. Here,
T registry.</t> the "Claim Value Type" fields name CDDL definitions and are only for the CWT reg
<t><cref anchor="to-be-removed-3">RFC editor: please see instructions in istry.</t>
followg paragraph and remove for final publication</cref></t>
<t>RFC Editor: Please make the following adjustments and remove this par <!--[rfced] Section 10.2. Is this sentence necessary?
agraph.
Replace "<strong>this document</strong>" with this RFC number. Original:
In the following, the claims with "Claim Key: TBD" need to be assigned a value i The "Claim Value
n the Specification Required Range, preferably starting around 267. Type(s)" here all name CDDL definitions and are only for the CWT
Those below already with a Claim Key number were given early assignment. registry.
No change is requested for them except for Claim Key 262.
Claim 262 should be renamed from "secboot" to "oemboot" in the JWT registry and It seems redundant with this text in the preceding paragraph:
its description changed in both the CWT and JWT registries.</t>
<ul spacing="normal"> The "Claim Key" and "Claim Value Types(s)" are for the CWT registry
<li> only.
<t>Claim Name: Nonce</t> -->
</li>
<li> <!--[rfced] Below are questions about the IANA-related text.
<t>Claim Description: Nonce</t> In addition to responding to these questions, please review
</li> all of the IANA-related updates carefully and let us know
<li> if any further updates are needed.
<t>JWT Claim Name: "eat_nonce"</t>
</li> a) Section 4.2.18.2. Please clarify which IANA registry is
<li> being referred to in the last sentence (i.e., the "JOSE Algorithm
<t>Claim Key: 10</t> registry"). Is it the "JSON Web Signature and Encryption
</li> Algorithms" registry <https://www.iana.org/assignments/jose/>?
<li>
<t>Claim Value Type(s): bstr or array</t> Original:
</li> The hash algorithm identifier is always from the COSE
<li> Algorithm registry, [IANA.COSE.Algorithms]. Either the integer or
<t>Change Controller: IETF</t> string identifier may be used. The hash algorithm identifier is
</li> never from the JOSE Algorithm registry.
<li>
<t>Specification Document(s): <strong>this document</strong></t> Perhaps:
</li> The hash algorithm identifier is always from the "COSE Algorithms"
</ul> registry [IANA.COSE.Algorithms]. Either the integer or
<t> </t> the string identifier may be used. The hash algorithm identifier is
<ul spacing="normal"> never from the "JSON Web Signature and Encryption Algorithms" registry.
<li>
<t>Claim Name: UEID</t> b) Section 10.2. May we remove all quote marks from the JWT Claim Name
</li> fields? We note that quote marks are not used in the "CBOR Web Token
<li> (CWT) Claims" registry <https://www.iana.org/assignments/cwt>.
<t>Claim Description: The Universal Entity ID</t> For example:
</li> OLD: JWT Claim Name: "eat_nonce"
<li> NEW: JWT Claim Name: eat_nonce
<t>JWT Claim Name: "ueid"</t>
</li> c) Section 10.2. In the "CBOR Web Token (CWT) Claims" registry
<li> for eat_nonce (Claim Key 10), the Reference field includes "OpenID
<t>CWT Claim Key: 256</t> Connect Core 1.0" (https://openid.net/specs/openid-connect-core-1_0.html),
</li> but the Reference field in the draft did not. FYI, this document
<li> has been updated to match the registry, and "OpenID Connect Core 1.0"
<t>Claim Value Type(s): bstr</t> has been added as an informative reference.
</li>
<li> In the JWT Claims registry, should "eat_nonce" have a matching
<t>Change Controller: IETF</t> Reference field? (This document states the Reference fields are
</li> "common and equivalent".) If so, we will ask IANA to update the registry
<li> as follows.
<t>Specification Document(s): <strong>this document</strong></t>
</li> Old: eat_nonce Nonce [IETF] [RFC-ietf-rats-eat-30]
</ul> New: eat_nonce Nonce [IETF] [OpenID Connect Core 1.0][RFC-ietf-rats-eat-30]
<t> </t>
<ul spacing="normal"> d) Section 10.2. Regarding "Claim Description" (in both the CWT and JWT
<li> Claims registries), would you like to update these to remove 'Indicates'
<t>Claim Name: SUEIDs</t> so they are similar to other descriptions? If so, we will ask IANA to
</li> update the registries accordingly with any changes made.
<li>
<t>Claim Description: Semi-permanent UEIDs</t> Original:
</li> ueid The Universal Entity ID
<li>
<t>JWT Claim Name: "sueids"</t> sueids Semi-permanent UEIDs
</li>
<li> hwmodel Model identifier for hardware
<t>CWT Claim Key: 257</t>
</li> dbgstat Indicates status of debug facilities
<li>
<t>Claim Value Type(s): map</t> eat_profile Indicates the EAT profile followed
</li>
<li> intuse Indicates intended use of the EAT
<t>Change Controller: IETF</t>
</li> Perhaps:
<li> ueid Universal Entity ID
<t>Specification Document(s): <strong>this document</strong></t>
</li> sueids Semipermanent UEIDs
</ul>
<t> </t> hwmodel Model identifier for hardware
<ul spacing="normal">
<li> dbgstat The status of debug facilities
<t>Claim Name: Hardware OEM ID</t>
</li> eat_profile The EAT profile followed
<li>
<t>Claim Description: Hardware OEM ID</t> intuse The intended use of the EAT
</li>
<li> e) Section 10.3. In the "DEV URN Subtypes" registry, may we
<t>JWT Claim Name: "oemid"</t> update the descriptions as follows?
</li> - change "Identifier" to "ID" to match the "JSON Web Token Claims"
<li> registry, "CBOR Web Token (CWT) Claims" registry, and the running text in
<t>Claim Key: 258</t> this document.
</li> - change "Semi-permanent" to "Semipermanent" per Merriam-Webster
<li> (throughout this document and in the two other registries).
<t>Claim Value Type(s): bstr or int</t>
</li> Original:
<li> ueid Universal Entity Identifier
<t>Change Controller: IETF</t> sueid Semi-permanent Universal Entity Identifier
</li>
<li> Perhaps:
<t>Specification Document(s): <strong>this document</strong></t> ueid Universal Entity ID
</li> sueid Semipermanent Universal Entity ID
</ul>
<t> </t> f) Section 10.4. FYI - In the "CBOR Tags" registry at
<ul spacing="normal"> https://www.iana.org/assignments/cbor-tags/, the reference to Section 5
<li> of this document is included under the Semantics column. We will ask
<t>Claim Name: Hardware Model</t> IANA to update the registry so that "RFC 9711, Section 5" is only
</li> in the Reference column.
<li>
<t>Claim Description: Model identifier for hardware</t> Original:
</li> +=====+============+===============================+
<li> | Tag | Data Items | Semantics |
<t>JWT Claim Name: "hwmodel"</t> +=====+============+===============================+
</li> | 602 | array | Detached EAT Bundle Section 5 |
<li>
<t>Claim Key: 259</t> Current:
</li> +=====+===========+=====================+=====================+
<li> | Tag | Data Item | Semantics | Reference |
<t>Claim Value Type(s): bstr</t> +=====+===========+=====================+=====================+
</li> | 602 | array | Detached EAT Bundle | RFC 9711, Section 5 |
<li>
<t>Change Controller: IETF</t> g) Section 10.5. The columns for the "Entity Attestation Token
</li> (EAT) Intended Uses" registry are "Integer", "Name", and
<li> "Description" in this document, but "Value", "Description", and
<t>Specification Document(s): <strong>this document</strong></t> "Reference" in the IANA registry <https://www.iana.org/assignments/rats>.
</li> Which one is correct? If the IANA registry is correct, please provide
</ul> updated text for Section 10.5 where it describes the three columns.
<t> </t> -->
<ul spacing="normal">
<li> <dl spacing="compact" newline="false">
<t>Claim Name: Hardware Version</t> <dt>Claim Name:</dt><dd>Nonce</dd>
</li> <dt>Claim Description:</dt><dd>Nonce</dd>
<li> <dt>JWT Claim Name:</dt><dd>"eat_nonce"</dd>
<t>Claim Description: Hardware Version Identifier</t> <dt>Claim Key:</dt><dd>10</dd>
</li> <dt>Claim Value Type:</dt><dd>bstr or array</dd>
<li> <dt>Change Controller:</dt><dd>IETF</dd>
<t>JWT Claim Name: "hwversion"</t> <dt>Reference:</dt><dd><xref target="OIDCC"/>, RFC 9711</dd>
</li> </dl>
<li>
<t>Claim Key: 260</t> <dl spacing="compact" newline="false">
</li> <dt>Claim Name:</dt><dd>UEID</dd>
<li> <dt>Claim Description:</dt><dd>The Universal Entity ID</dd>
<t>Claim Value Type(s): array</t> <dt>JWT Claim Name:</dt><dd>"ueid"</dd>
</li> <dt>CWT Claim Key:</dt><dd>256</dd>
<li> <dt>Claim Value Type:</dt><dd>bstr</dd>
<t>Change Controller: IETF</t> <dt>Change Controller:</dt><dd>IETF</dd>
</li> <dt>Reference:</dt><dd>RFC 9711</dd>
<li> </dl>
<t>Specification Document(s): <strong>this document</strong></t>
</li> <dl spacing="compact" newline="false">
</ul> <dt>Claim Name:</dt><dd>SUEIDs</dd>
<t> </t> <dt>Claim Description:</dt><dd>Semi-permanent UEIDs</dd>
<ul spacing="normal"> <dt>JWT Claim Name:</dt><dd>"sueids"</dd>
<li> <dt>CWT Claim Key:</dt><dd>257</dd>
<t>Claim Name: OEM Authorized Boot</t> <dt>Claim Value Type:</dt><dd>map</dd>
</li> <dt>Change Controller:</dt><dd>IETF</dd>
<li> <dt>Reference:</dt><dd>RFC 9711</dd>
<t>Claim Description: Indicates whether the software booted was OEM </dl>
authorized</t>
</li> <dl spacing="compact" newline="false">
<li> <dt>Claim Name:</dt><dd>Hardware OEM ID</dd>
<t>JWT Claim Name: "oemboot"</t> <dt>Claim Description:</dt><dd>Hardware OEM ID</dd>
</li> <dt>JWT Claim Name:</dt><dd>"oemid"</dd>
<li> <dt>Claim Key:</dt><dd>258</dd>
<t>Claim Key: 262</t> <dt>Claim Value Type:</dt><dd>bstr or int</dd>
</li> <dt>Change Controller:</dt><dd>IETF</dd>
<li> <dt>Reference:</dt><dd>RFC 9711</dd>
<t>Claim Value Type(s): bool</t> </dl>
</li>
<li> <dl spacing="compact" newline="false">
<t>Change Controller: IETF</t> <dt>Claim Name:</dt><dd>Hardware Model</dd>
</li> <dt>Claim Description:</dt><dd>Model identifier for hardware</dd>
<li> <dt>JWT Claim Name:</dt><dd>"hwmodel"</dd>
<t>Specification Document(s): <strong>this document</strong></t> <dt>Claim Key:</dt><dd>259</dd>
</li> <dt>Claim Value Type:</dt><dd>bstr</dd>
</ul> <dt>Change Controller:</dt><dd>IETF</dd>
<t> </t> <dt>Reference:</dt><dd>RFC 9711</dd>
<ul spacing="normal"> </dl>
<li>
<t>Claim Name: Debug Status</t> <dl spacing="compact" newline="false">
</li> <dt>Claim Name:</dt><dd>Hardware Version</dd>
<li> <dt>Claim Description:</dt><dd>Hardware Version Identifier</dd>
<t>Claim Description: Indicates status of debug facilities</t> <dt>JWT Claim Name:</dt><dd>"hwversion"</dd>
</li> <dt>Claim Key:</dt><dd>260</dd>
<li> <dt>Claim Value Type:</dt><dd>array</dd>
<t>JWT Claim Name: "dbgstat"</t> <dt>Change Controller:</dt><dd>IETF</dd>
</li> <dt>Reference:</dt><dd>RFC 9711</dd>
<li> </dl>
<t>Claim Key: 263</t>
</li> <dl spacing="compact" newline="false">
<li> <dt>Claim Name:</dt><dd>Uptime</dd>
<t>Claim Value Type(s): uint</t> <dt>Claim Description:</dt><dd>Uptime</dd>
</li> <dt>JWT Claim Name:</dt><dd>"uptime"</dd>
<li> <dt>Claim Key:</dt><dd>261</dd>
<t>Change Controller: IETF</t> <dt>Claim Value Type:</dt><dd>uint</dd>
</li> <dt>Change Controller:</dt><dd>IETF</dd>
<li> <dt>Reference:</dt><dd>RFC 9711</dd>
<t>Specification Document(s): <strong>this document</strong></t> </dl>
</li>
</ul> <dl spacing="compact" newline="false">
<t> </t> <dt>Claim Name:</dt><dd>OEM Authorized Boot</dd>
<ul spacing="normal"> <dt>Claim Description:</dt><dd>Indicates whether the software booted
<li> was OEM authorized</dd>
<t>Claim Name: Location</t> <dt>JWT Claim Name:</dt><dd>"oemboot"</dd>
</li> <dt>Claim Key:</dt><dd>262</dd>
<li> <dt>Claim Value Type:</dt><dd>bool</dd>
<t>Claim Description: The geographic location</t> <dt>Change Controller:</dt><dd>IETF</dd>
</li> <dt>Reference:</dt><dd>RFC 9711</dd>
<li> </dl>
<t>JWT Claim Name: "location"</t>
</li> <dl spacing="compact" newline="false">
<li> <dt>Claim Name:</dt><dd>Debug Status</dd>
<t>Claim Key: 264</t> <dt>Claim Description:</dt><dd>Indicates status of debug facilities<
</li> /dd>
<li> <dt>JWT Claim Name:</dt><dd>"dbgstat"</dd>
<t>Claim Value Type(s): map</t> <dt>Claim Key:</dt><dd>263</dd>
</li> <dt>Claim Value Type:</dt><dd>uint</dd>
<li> <dt>Change Controller:</dt><dd>IETF</dd>
<t>Change Controller: IETF</t> <dt>Reference:</dt><dd>RFC 9711</dd>
</li> </dl>
<li>
<t>Specification Document(s): <strong>this document</strong></t> <dl spacing="compact" newline="false">
</li> <dt>Claim Name:</dt><dd>Location</dd>
</ul> <dt>Claim Description:</dt><dd>The geographic location</dd>
<t> </t> <dt>JWT Claim Name:</dt><dd>"location"</dd>
<ul spacing="normal"> <dt>Claim Key:</dt><dd>264</dd>
<li> <dt>Claim Value Type:</dt><dd>map</dd>
<t>Claim Name: EAT Profile</t> <dt>Change Controller:</dt><dd>IETF</dd>
</li> <dt>Reference:</dt><dd>RFC 9711</dd>
<li> </dl>
<t>Claim Description: Indicates the EAT profile followed</t>
</li> <dl spacing="compact" newline="false">
<li> <dt>Claim Name:</dt><dd>EAT Profile</dd>
<t>JWT Claim Name: "eat_profile"</t> <dt>Claim Description:</dt><dd>Indicates the EAT profile followed</d
</li> d>
<li> <dt>JWT Claim Name:</dt><dd>"eat_profile"</dd>
<t>Claim Key: 265</t> <dt>Claim Key:</dt><dd>265</dd>
</li> <dt>Claim Value Type:</dt><dd>uri or oid</dd>
<li> <dt>Change Controller:</dt><dd>IETF</dd>
<t>Claim Value Type(s): uri or oid</t> <dt>Reference:</dt><dd>RFC 9711</dd>
</li> </dl>
<li>
<t>Change Controller: IETF</t> <dl spacing="compact" newline="false">
</li> <dt>Claim Name:</dt><dd>Submodules Section</dd>
<li> <dt>Claim Description:</dt><dd>The section containing submodules</dd
<t>Specification Document(s): <strong>this document</strong></t> >
</li> <dt>JWT Claim Name:</dt><dd>"submods"</dd>
</ul> <dt>Claim Key:</dt><dd>266</dd>
<t> </t> <dt>Claim Value Type:</dt><dd>map</dd>
<ul spacing="normal"> <dt>Change Controller:</dt><dd>IETF</dd>
<li> <dt>Reference:</dt><dd>RFC 9711</dd>
<t>Claim Name: Submodules Section</t> </dl>
</li>
<li> <dl spacing="compact" newline="false">
<t>Claim Description: The section containing submodules</t> <dt>Claim Name:</dt><dd>Boot Count</dd>
</li> <dt>Claim Description:</dt><dd>The number of times the entity or sub
<li> module has been booted</dd>
<t>JWT Claim Name: "submods"</t> <dt>JWT Claim Name:</dt><dd>"bootcount"</dd>
</li> <dt>Claim Key:</dt><dd>267</dd>
<li> <dt>Claim Value Type:</dt><dd>uint</dd>
<t>Claim Key: 266</t> <dt>Change Controller:</dt><dd>IETF</dd>
</li> <dt>Reference:</dt><dd>RFC 9711</dd>
<li> </dl>
<t>Claim Value Type(s): map</t>
</li> <dl spacing="compact" newline="false">
<li> <dt>Claim Name:</dt><dd>Boot Seed</dd>
<t>Change Controller: IETF</t> <dt>Claim Description:</dt><dd>Identifies a boot cycle</dd>
</li> <dt>JWT Claim Name:</dt><dd>"bootseed"</dd>
<li> <dt>Claim Key:</dt><dd>268</dd>
<t>Specification Document(s): <strong>this document</strong></t> <dt>Claim Value Type:</dt><dd>bstr</dd>
</li> <dt>Change Controller:</dt><dd>IETF</dd>
</ul> <dt>Reference:</dt><dd>RFC 9711</dd>
<t> </t> </dl>
<ul spacing="normal">
<li> <dl spacing="compact" newline="false">
<t>Claim Name: Uptime</t> <dt>Claim Name:</dt><dd>DLOAs</dd>
</li> <dt>Claim Description:</dt><dd>Certifications received as Digital Le
<li> tters of Approval</dd>
<t>Claim Description: Uptime</t> <dt>JWT Claim Name:</dt><dd>"dloas"</dd>
</li> <dt>Claim Key:</dt><dd>269</dd>
<li> <dt>Claim Value Type:</dt><dd>array</dd>
<t>JWT Claim Name: "uptime"</t> <dt>Change Controller:</dt><dd>IETF</dd>
</li> <dt>Reference:</dt><dd>RFC 9711</dd>
<li> </dl>
<t>Claim Key: 261</t>
</li> <dl spacing="compact" newline="false">
<li> <dt>Claim Name:</dt><dd>Software Name</dd>
<t>Claim Value Type(s): uint</t> <dt>Claim Description:</dt><dd>The name of the software running in t
</li> he entity</dd>
<li> <dt>JWT Claim Name:</dt><dd>"swname"</dd>
<t>Change Controller: IETF</t> <dt>Claim Key:</dt><dd>270</dd>
</li> <dt>Claim Value Type:</dt><dd>tstr</dd>
<li> <dt>Change Controller:</dt><dd>IETF</dd>
<t>Specification Document(s): <strong>this document</strong></t> <dt>Reference:</dt><dd>RFC 9711</dd>
</li> </dl>
</ul>
<t> </t> <dl spacing="compact" newline="false">
<ul spacing="normal"> <dt>Claim Name:</dt><dd>Software Version</dd>
<li> <dt>Claim Description:</dt><dd>The version of software running in th
<t>Claim Name: Boot Count</t> e entity</dd>
</li> <dt>JWT Claim Name:</dt><dd>"swversion"</dd>
<li> <dt>Claim Key:</dt><dd>271</dd>
<t>Claim Description: The number times the entity or submodule has b <dt>Claim Value Type:</dt><dd>array</dd>
een booted</t> <dt>Change Controller:</dt><dd>IETF</dd>
</li> <dt>Reference:</dt><dd>RFC 9711</dd>
<li> </dl>
<t>JWT Claim Name: "bootcount"</t>
</li> <dl spacing="compact" newline="false">
<li> <dt>Claim Name:</dt><dd>Software Manifests</dd>
<t>Claim Key: 267</t> <dt>Claim Description:</dt><dd>Manifests describing the software ins
</li> talled on the entity</dd>
<li> <dt>JWT Claim Name:</dt><dd>"manifests"</dd>
<t>Claim Value Type(s): uint</t> <dt>Claim Key:</dt><dd>272</dd>
</li> <dt>Claim Value Type:</dt><dd>array</dd>
<li> <dt>Change Controller:</dt><dd>IETF</dd>
<t>Change Controller: IETF</t> <dt>Reference:</dt><dd>RFC 9711</dd>
</li> </dl>
<li>
<t>Specification Document(s): <strong>this document</strong></t> <dl spacing="compact" newline="false">
</li> <dt>Claim Name:</dt><dd>Measurements</dd>
</ul> <dt>Claim Description:</dt><dd>Measurements of the software, memory
<t> </t> configuration, and such on the entity</dd>
<ul spacing="normal"> <dt>JWT Claim Name:</dt><dd>"measurements"</dd>
<li> <dt>Claim Key:</dt><dd>273</dd>
<t>Claim Name: Boot Seed</t> <dt>Claim Value Type:</dt><dd>array</dd>
</li> <dt>Change Controller:</dt><dd>IETF</dd>
<li> <dt>Reference:</dt><dd>RFC 9711</dd>
<t>Claim Description: Identifies a boot cycle</t> </dl>
</li>
<li> <dl spacing="compact" newline="false">
<t>JWT Claim Name: "bootseed"</t> <dt>Claim Name:</dt><dd>Software Measurement Results</dd>
</li> <dt>Claim Description:</dt><dd>The results of comparing software mea
<li> surements to reference values</dd>
<t>Claim Key: 268</t> <dt>JWT Claim Name:</dt><dd>"measres"</dd>
</li> <dt>Claim Key:</dt><dd>274</dd>
<li> <dt>Claim Value Type:</dt><dd>array</dd>
<t>Claim Value Type(s): bstr</t> <dt>Change Controller:</dt><dd>IETF</dd>
</li> <dt>Reference:</dt><dd>RFC 9711</dd>
<li> </dl>
<t>Change Controller: IETF</t>
</li> <dl spacing="compact" newline="false">
<li> <dt>Claim Name:</dt><dd>Intended Use</dd>
<t>Specification Document(s): <strong>this document</strong></t> <dt>Claim Description:</dt><dd>Indicates intended use of the EAT</dd
</li> >
</ul> <dt>JWT Claim Name:</dt><dd>"intuse"</dd>
<t> </t> <dt>Claim Key:</dt><dd>275</dd>
<ul spacing="normal"> <dt>Claim Value Type:</dt><dd>uint</dd>
<li> <dt>Change Controller:</dt><dd>IETF</dd>
<t>Claim Name: DLOAs</t> <dt>Reference:</dt><dd>RFC 9711</dd>
</li> </dl>
<li>
<t>Claim Description: Certifications received as Digital Letters of
Approval</t>
</li>
<li>
<t>JWT Claim Name: "dloas"</t>
</li>
<li>
<t>Claim Key: 269</t>
</li>
<li>
<t>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 name of the software running in the entity
</t>
</li>
<li>
<t>JWT Claim Name: "swname"</t>
</li>
<li>
<t>Claim Key: 270</t>
</li>
<li>
<t>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 version of software running in the entity<
/t>
</li>
<li>
<t>JWT Claim Name: "swversion"</t>
</li>
<li>
<t>Claim Key: 271</t>
</li>
<li>
<t>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 describing the software installed on
the entity</t>
</li>
<li>
<t>JWT Claim Name: "manifests"</t>
</li>
<li>
<t>Claim Key: 272</t>
</li>
<li>
<t>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 of the software, memory configura
tion and such on the entity</t>
</li>
<li>
<t>JWT Claim Name: "measurements"</t>
</li>
<li>
<t>Claim Key: 273</t>
</li>
<li>
<t>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 Measurement Results</t>
</li>
<li>
<t>Claim Description: The results of comparing software measurements
to reference values</t>
</li>
<li>
<t>JWT Claim Name: "measres"</t>
</li>
<li>
<t>Claim Key: 274</t>
</li>
<li>
<t>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 intended use of the EAT</t>
</li>
<li>
<t>JWT Claim Name: "intuse"</t>
</li>
<li>
<t>Claim Key: 275</t>
</li>
<li>
<t>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>
</section> </section>
<section anchor="registerueidurn"> <section anchor="registerueidurn">
<name>UEID URN Registered by this Document</name> <name>UEID URNs Registered by This Document</name>
<t>IANA is requested to register the following new subtypes in the "DEV <t>IANA has registered the following new subtypes in the "DEV URN Subtyp
URN Subtypes" registry under "Device Identification". See <xref target="RFC9039" es" registry <xref target="IANA.DEV-URNs"/> under the "Device Identification" re
/>.</t> gistry group; see <xref target="RFC9039"/>.</t>
<table anchor="ueid-urn-reg"> <table align="left" anchor="ueid-urn-reg">
<name>UEID URN Registration</name> <name>UEID URN Registration</name>
<thead> <thead>
<tr> <tr>
<th align="left">Subtype</th> <th align="left">Subtype</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">ueid</td> <td align="left">ueid</td>
<td align="left">Universal Entity Identifier</td> <td align="left">Universal Entity Identifier</td>
<td align="left">This document</td> <td align="left">RFC 9711</td>
</tr> </tr>
<tr> <tr>
<td align="left">sueid</td> <td align="left">sueid</td>
<td align="left">Semi-permanent Universal Entity Identifier</td> <td align="left">Semi-permanent Universal Entity Identifier</td>
<td align="left">This document</td> <td align="left">RFC 9711</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>ABNF for these two URNs is as follows where b64ueid is the base64url-
encoded binary byte-string for the UEID or SUEID:</t> <!-- [rfced] FYI, a normative reference to RFC 5234 has been added because
<artwork><![CDATA[ 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,
where b64ueid is the base64url-encoded binary 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 strin
g for the UEID or SUEID:</t>
<sourcecode type="abnf"><![CDATA[
body =/ ueidbody body =/ ueidbody
ueidbody = %s"ueid:" b64ueid ueidbody = %s"ueid:" b64ueid
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="cbor-tag-for-detached-eat-bundle-registered-by-this-docum ent"> <section anchor="cbor-tag-for-detached-eat-bundle-registered-by-this-docum ent">
<name>CBOR Tag for Detached EAT Bundle Registered by this Document</name <name>CBOR Tag for Detached EAT Bundle Registered by This Document</name
> >
<t>In the registry <xref target="IANA.cbor-tags"/>, IANA is requested to <t>In the "CBOR Tags" registry <xref target="IANA.cbor-tags"/>, IANA has
allocate the allocated the
following tag from the Specification Required space, with the present document a following tag from the Specification Required range, with the present document a
s the s the reference.</t>
specification reference.</t> <table align="left" anchor="deb-tag-reg">
<table anchor="deb-tag-reg">
<name>Detached EAT Bundle Tag Registration</name> <name>Detached EAT Bundle Tag Registration</name>
<thead> <thead>
<tr> <tr>
<th align="left">Tag</th> <th align="left">Tag</th>
<th align="left">Data Items</th> <th align="left">Data Item</th>
<th align="left">Semantics</th> <th align="left">Semantics</th>
<th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">602</td> <td align="left">602</td>
<td align="left">array</td> <td align="left">array</td>
<td align="left">Detached EAT Bundle <xref target="DEB"/></td> <td align="left">Detached EAT Bundle</td>
<td align="left">RFC 9711, <xref target="DEB"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="int-use-registry"> <section anchor="int-use-registry">
<name>Intended Use Registry</name> <name>Intended Use Registry</name>
<t>IANA is requested to create a new registry titled "Entity <t>IANA has created a new registry titled "Entity
Attestation Token (EAT) Intended Uses" in a new registry group called Attestation Token (EAT) Intended Uses" under the
"Remote Attestation Procedures (RATS)." The registry uses the "Expert new "Remote Attestation Procedures (RATS)" registry group. The registry
Review" registration procedure <xref target="RFC8126"/>.</t> uses the Expert
Review registration procedure <xref target="RFC8126"/>.</t>
<t>Guidelines for experts:</t> <t>Guidelines for designated experts:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Each intended use should be clearly described so a user of it can know what it means.</t> <t>Each intended use should be clearly described so a user knows wha t it means.</t>
</li> </li>
<li> <li>
<t>Each intended use should be distinct from others that are registe red.</t> <t>Each intended use should be distinct from others that are register ed.</t>
</li> </li>
<li> <li>
<t>Point squatting is discouraged.</t> <t>Point squatting is discouraged.</t>
</li> </li>
</ul> </ul>
<t>The three columns for the registry are:</t> <t>The three columns for the registry are:</t>
<dl> <ol spacing="normal" type="1">
<dt>Integer:</dt> <li>Integer: This is a unique integer that is used to identify the
<dd> intended use in CBOR-encoded tokens.</li>
<t>This is a unique integer used to identify the intended use in CBO <li>Name: This is unique short descriptive string that is used to
R-encoded tokens.</t> identify the use in JSON-encoded tokens.</li>
</dd> <li>Description: This is one or more text paragraphs that
<dt>Name:</dt> sufficiently define what the intended use means. It may also be a
<dd> reference to another document.</li>
<t>This is unique short descriptive string that is used to identify </ol>
the use in JSON-encoded tokens.</t>
</dd>
<dt>Description:</dt>
<dd>
<t>This is a text paragraph or more that sufficiently defines what t
he intended use means. It may also be a reference to another document.</t>
</dd>
</dl>
<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 CB OR value for assignment is 255.</t> <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 CB OR value for assignment is 255.</t>
<dl> <dl spacing="normal">
<dt>1 -- Generic:</dt> <dt>1 -- Generic:</dt><dd> Generic attestation describes an applicatio
<dd> n
<t>Generic attestation describes an application where the EAT consum where the EAT consumer requires the most up-to-date security
er assessment of the attesting entity. It is expected that this is the
requires the most up-to-date security assessment of the attesting entity. It most commonly used application of EAT.</dd>
is expected that this is the most commonly-used application of EAT.</t> <dt>2 -- Registration:</dt><dd> Entities that are registering for a ne
</dd> w
<dt>2-- Registration:</dt> service may be expected to provide an attestation as part of the
<dd> registration process. This "intuse" setting indicates that the
<t>Entities that are registering for a new service may be expected t attestation is not intended for any use but registration.</dd>
o <dt>3 -- Provisioning:</dt><dd> Entities may be provisioned with diffe
provide an attestation as part of the registration process. This "intuse" rent
setting indicates that the attestation is not intended for any use but registrat values or settings by an EAT consumer. Examples include key
ion.</t> material or device management trees. The consumer may require an
</dd> EAT to assess entity security state of the entity prior to
<dt>3 -- Provisioning:</dt> provisioning.</dd>
<dd> <dt>4 -- Certificate Issuance:</dt><dd> Certification Authorities (CAs
<t>Entities may be provisioned with different values or settings by )
an EAT may require attestation results (which in a background check model
consumer. Examples include key material or device management trees. The consum might require receiving evidence to be passed to a verifier) to make
er decisions about the issuance of certificates. An EAT may be used as
may require an EAT to assess entity security state of the entity prior to provis part of the certificate signing request (CSR).</dd>
ioning.</t> <dt>5 -- Proof of Possession:</dt><dd> An EAT consumer may require an
</dd> attestation as part of an accompanying proof-of-possession (PoP)
<dt>4 -- Certificate Issuance:</dt> application. More precisely, a PoP transaction is intended to
<dd> provide the recipient with cryptographically verifiable proof that the
<t>Certification Authorities (CAs) may require attestation results ( sender has possession of a key. This kind of attestation may be
which in a background check model might require receiving evidence to be passed necessary to verify the security state of the entity storing the
to a verifier) to make decisions about the issuance of certificates. private key used in a PoP application.</dd>
An EAT may be used as part of the certificate signing request (CSR).</t>
</dd>
<dt>5 -- Proof-of-Possession:</dt>
<dd>
<t>An EAT consumer may require an attestation as part of an accompan
ying
proof-of-possession (PoP) application. More precisely, a PoP transaction is inte
nded
to provide to the recipient cryptographically-verifiable proof that the sender h
as 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>
</dl> </dl>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-cose-cbor-encoded-cert" to="CBOR.Cert.Draft"/ > <displayreference target="I-D.ietf-cose-cbor-encoded-cert" to="CBOR.Certs"/>
<displayreference target="I-D.ietf-rats-uccs" to="UCCS"/> <displayreference target="I-D.ietf-rats-uccs" to="UCCS"/>
<displayreference target="I-D.ietf-rats-eat-media-type" to="EAT.media-types"/> <displayreference target="I-D.ietf-rats-eat-media-type" to="EAT.media-types"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
34.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.74
05.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 515.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 515.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 949.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 949.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 252.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 252.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 519.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 519.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 259.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 259.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 392.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 392.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 610.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 610.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 792.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 792.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 986.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 052.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 052.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 090.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 090.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 165.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 165.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 648.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 648.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 517.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 517.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 393.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 393.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 334.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 334.xml"/>
<!-- [rfced] [WGS84] Please review title, but URL seems correct --> <!--[rfced] FYI, we updated the URL for this reference because it
<reference anchor="WGS84" target="https://earth-info.nga.mil/php/downloa was a direct download of the PDF file. The updated URL points to
d.php?file=coord-wgs84"> 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://nsgreg.nga.mil/doc/view?i=4085
">
<front> <front>
<title>WORLD GEODETIC SYSTEM 1984, NGA.STND.0036_1.0.0_WGS84</title> <title>Department of Defense World Geodetic System 1984: Its Definit ion and Relationships with Local Geodetic Systems</title>
<author> <author>
<organization>National Geospatial-Intelligence Agency (NGA)</organ ization> <organization>National Geospatial-Intelligence Agency (NGA)</organ ization>
</author> </author>
<date year="2014" month="July" day="08"/> <date year="2014" month="July"/>
</front> </front>
<refcontent>NGA.STND.0036_1.0.0_WGS84</refcontent>
</reference> </reference>
<!-- [rfced] [IANA.CWT.Claims] URL seems correct --> <!-- [IANA.CWT.Claims] -->
<reference anchor="IANA.CWT.Claims" target="https://www.iana.org/assignm ents/cwt"> <reference anchor="IANA.CWT.Claims" target="https://www.iana.org/assignm ents/cwt">
<front> <front>
<title>CBOR Web Token (CWT) Claims</title> <title>CBOR Web Token (CWT) Claims</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
</front> </front>
</reference> </reference>
<!-- [rfced] [IANA.JWT.Claims] URL seems correct--> <!-- [IANA.JWT.Claims] -->
<reference anchor="IANA.JWT.Claims" target="https://www.iana.org/assignm ents/jwt"> <reference anchor="IANA.JWT.Claims" target="https://www.iana.org/assignm ents/jwt">
<front> <front>
<title>JSON Web Token (JWT)</title> <title>JSON Web Token Claims</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
</front> </front>
</reference> </reference>
<!-- [rfced] [IANA.COSE.Algorithms] URL seems correct--> <!-- [IANA.COSE.Algorithms]-->
<reference anchor="IANA.COSE.Algorithms" target="https://www.iana.org/as signments/cose"> <reference anchor="IANA.COSE.Algorithms" target="https://www.iana.org/as signments/cose">
<front> <front>
<title>CBOR Object Signing and Encryption (COSE)</title> <title>COSE Algorithms</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
</front> </front>
</reference> </reference>
<!-- [rfced] [ThreeGPP.IMEI] Please review title, URL seems correct--> <!--[rfced] FYI, we updated this reference to reflect the most current
version (September 2024). Please 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/deskto pmodules/Specifications/SpecificationDetails.aspx?specificationId=729"> <reference anchor="ThreeGPP.IMEI" target="https://portal.3gpp.org/deskto pmodules/Specifications/SpecificationDetails.aspx?specificationId=729">
<front> <front>
<title>3rd Generation Partnership Project; Technical Specification G roup Core Network and Terminals; Numbering, addressing and identification</title > <title>Numbering, addressing and identification</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date year="2019"/> <date month="September" year="2024"/>
</front> </front>
<seriesInfo name="3GPP TS" value="23.003, Version 19"/>
</reference> </reference>
<!-- [rfced] [DLOA] URL seems correct-->
<reference anchor="DLOA" target="https://globalplatform.org/wp-content/u ploads/2015/12/GPC_DigitalLetterOfApproval_v1.0.pdf"> <reference anchor="DLOA" target="https://globalplatform.org/wp-content/u ploads/2015/12/GPC_DigitalLetterOfApproval_v1.0.pdf">
<front> <front>
<title>Digital Letter of Approval</title> <title>GlobalPlatform Card: Digital Letter of Approval</title>
<author> <author>
<organization/> <organization>GlobalPlatform</organization>
</author> </author>
<date year="2015" month="November"/> <date year="2015" month="November"/>
</front> </front>
<refcontent>Public Release Version 1.0</refcontent>
<refcontent>Document Reference: GPC_SPE_095</refcontent>
</reference> </reference>
<!-- [rfced] [PEN] Please review title, URL seems correct-->
<reference anchor="PEN" target="https://pen.iana.org/pen/PenApplication. page"> <reference anchor="PEN" target="https://pen.iana.org/pen/PenApplication. page">
<front> <front>
<title>Private Enterprise Number (PEN) Request</title> <title>Application for a Private Enterprise Number</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<!-- [rfced] [IANA.cbor-tags] URL seems correct-->
<reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignme nts/cbor-tags"> <reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignme nts/cbor-tags">
<front> <front>
<title>Concise Binary Object Representation (CBOR) Tags</title> <title>CBOR Tags</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<reference anchor="IANA.DEV-URNs" target="https://www.iana.org/assignmen
ts/device-identification">
<front>
<title>DEV URN Subtypes</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
</front> </front>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/>
</references> </references>
skipping to change at line 2792 skipping to change at line 3109
</author> </author>
</front> </front>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 562.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 562.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 949.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 949.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 039.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 039.xml"/>
<!-- [rfced] [BirthdayAttack] URL contains extra period on the end that leads to <reference anchor="OIDCC"
an error - otherwise seemingly correct--> target="https://openid.net/specs/openid-connect-core-1_0.html">
<reference anchor="BirthdayAttack" target="https://en.wikipedia.org/wiki <front>
/Birthday_attack."> <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/w/in
dex.php?title=Birthday_attack&amp;oldid=1249270346">
<front> <front>
<title>Birthday attack</title> <title>Birthday attack</title>
<author> <author>
<organization/> <organization>Wikipedia</organization>
</author> </author>
<date/> <date month="October" year="2024"/>
</front> </front>
</reference> </reference>
<!-- [rfced] [IEEE.802.1AR] DOI seems correct--> <reference anchor="IEEE.802.1AR" target="https://ieeexplore.ieee.org/doc
<reference anchor="IEEE.802.1AR"> ument/8423794">
<front> <front>
<title>IEEE Standard for Local and Metropolitan Area Networks - Secu re Device Identity</title> <title>IEEE Standard for Local and Metropolitan Area Networks - Secu re Device Identity</title>
<author> <author>
<organization/> <organization>IEEE</organization>
</author> </author>
<date month="July" year="2018"/> <date month="August" year="2018"/>
</front> </front>
<seriesInfo name="IEEE" value="standard"/> <seriesInfo name="IEEE Std" value="802.1AR-2018"/>
<seriesInfo name="DOI" value="10.1109/ieeestd.2018.8423794"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8423794"/>
</reference> </reference>
<!-- [rfced] [W3C.GeoLoc] URL seems correct though yields an outdated warning--> <!--[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/>.
-->
<!-- [W3C.GeoLoc]
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-ge olocation-API-20131024/"> <reference anchor="W3C.GeoLoc" target="https://www.w3.org/TR/2013/REC-ge olocation-API-20131024/">
<front> <front>
<title>Geolocation API Specification</title> <title>Geolocation API Specification</title>
<author fullname="Andrei Popescu" role="editor"/> <author fullname="Andrei Popescu" role="editor"/>
<date day="24" month="October" year="2013"/> <date day="24" month="October" year="2013"/>
</front> </front>
<seriesInfo name="W3C REC" value="REC-geolocation-API-20131024"/> <refcontent>W3C Recommendation</refcontent>
<seriesInfo name="W3C" value="REC-geolocation-API-20131024"/>
</reference> </reference>
<!-- [rfced] [OUI.Guide] URL seems correct --> <!-- [OUI.Guide] -->
<reference anchor="OUI.Guide" target="https://standards.ieee.org/content /dam/ieee-standards/standards/web/documents/tutorials/eui.pdf"> <reference anchor="OUI.Guide" target="https://standards.ieee.org/content /dam/ieee-standards/standards/web/documents/tutorials/eui.pdf">
<front> <front>
<title>Guidelines for Use of Extended Unique Identifier (EUI), Organ izationally Unique Identifier (OUI), and Company ID (CID)</title> <title>Guidelines for Use of Extended Unique Identifier (EUI), Organ izationally Unique Identifier (OUI), and Company ID (CID)</title>
<author> <author>
<organization/> <organization>IEEE</organization>
</author> </author>
<date year="2017" month="August"/> <date year="2017" month="August"/>
</front> </front>
</reference> </reference>
<!-- [rfced] [OUI.Lookup] URL seems correct--> <!-- [OUI.Lookup] -->
<reference anchor="OUI.Lookup" target="https://regauth.standards.ieee.or g/standards-ra-web/pub/view.html#registries"> <reference anchor="OUI.Lookup" target="https://regauth.standards.ieee.or g/standards-ra-web/pub/view.html#registries">
<front> <front>
<title>IEEE Registration Authority Assignments</title> <title>IEEE Registration Authority: Assignments</title>
<author> <author>
<organization/> <organization>IEEE</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<!-- [rfced] [IEEE-RA] URL seems correct --> <!-- [IEEE-RA] -->
<reference anchor="IEEE-RA" target="https://standards.ieee.org/products- services/regauth/index.html"> <reference anchor="IEEE-RA" target="https://standards.ieee.org/products- services/regauth/index.html">
<front> <front>
<title>IEEE Registration Authority</title> <title>IEEE Registration Authority</title>
<author> <author>
<organization/> <organization>IEEE</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<!-- [rfced] [IEEE.802-2001] URL seems correct--> <!-- [IEEE.802-2001]-->
<reference anchor="IEEE.802-2001"> <reference anchor="IEEE.802-2001" target="https://ieeexplore.ieee.org/do
cument/6847097">
<front> <front>
<title>IEEE Standard for Local and Metropolitan Area Networks: Overv iew and Architecture</title> <title>IEEE Standard for Local and Metropolitan Area Networks: Overv iew and Architecture</title>
<author> <author>
<organization/> <organization>IEEE</organization>
</author> </author>
<date month="July" year="2014"/> <date month="June" year="2014"/>
</front> </front>
<seriesInfo name="IEEE" value="standard"/> <seriesInfo name="IEEE Std" value="802-2014"/>
<seriesInfo name="DOI" value="10.1109/ieeestd.2014.6847097"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6847097"/>
</reference> </reference>
<!-- [rfced] [I-D.ietf-cose-x509] Published as RFC 9360 --> <!-- [I-D.ietf-cose-x509] Published as RFC 9360 -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 360.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 360.xml"/>
<!-- [rfced] [I-D.ietf-cose-cbor-encoded-cert] IESG state: I-D Exists as of 08/1 3/24--> <!-- [I-D.ietf-cose-cbor-encoded-cert] IESG state: I-D Exists as of 11/27/24-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-co se-cbor-encoded-cert.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-co se-cbor-encoded-cert.xml"/>
<!-- [rfced] [I-D.ietf-rats-uccs] IESG state: AD Evaluation::AD Followup as of 0 8/13/24--> <!-- [I-D.ietf-rats-uccs] in EDIT state as of 11/27/24-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ra ts-uccs.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ra ts-uccs.xml"/>
<!-- [rfced] [JTAG] URl seems correct; DOI: 10.1109/IEEESTD.2010.5412866--> <!-- [JTAG] -->
<reference anchor="JTAG" target="https://ieeexplore.ieee.org/document/54 12866"> <reference anchor="JTAG" target="https://ieeexplore.ieee.org/document/54 12866">
<front> <front>
<title>IEEE Standard for Reduced-Pin and Enhanced-Functionality Test Access Port and Boundary-Scan Architecture</title> <title>IEEE Standard for Reduced-Pin and Enhanced-Functionality Test Access Port and Boundary-Scan Architecture</title>
<author> <author>
<organization/> <organization>IEEE</organization>
</author> </author>
<date year="2010" month="February"/> <date year="2010" month="February"/>
</front> </front>
<seriesInfo name="IEEE Std" value="1149.7-2009"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2010.5412866"/>
</reference> </reference>
<!-- [rfced] [I-D.ietf-rats-eat-media-type] IESG state: Publication Requested as of 08/13/24 --> <!-- [I-D.ietf-rats-eat-media-type] in EDIT*R state as of 11/27/24 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ra ts-eat-media-type.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ra ts-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"> <reference anchor="CC-Example" target="https://commoncriteriaportal.org/ nfs/ccpfiles/files/ppfiles/pp0117V2b_pdf.pdf">
<front> <front>
<title>Secure Sub-System in System-on-Chip (3S in SoC) Protection Pr ofile</title> <title>Secure Sub-System in System-on-Chip (3S in SoC) Protection Pr ofile</title>
<author> <author>
<organization/> <organization>Eurosmart</organization>
</author> </author>
<date/> <date month="October" year="2023"/>
</front> </front>
<refcontent>Version 1.8</refcontent>
</reference> </reference>
<!-- [rfced] [GP-Example] URL seems correct--> <!-- [GP-Example] -->
<reference anchor="GP-Example" target="https://globalplatform.org/wp-con tent/uploads/2021/01/GP_TEECertificationProcess_v2.0_PublicRelease.pdf"> <reference anchor="GP-Example" target="https://globalplatform.org/wp-con tent/uploads/2021/01/GP_TEECertificationProcess_v2.0_PublicRelease.pdf">
<front> <front>
<title>GlobalPlatform Technology TEE Certification Process</title> <title>GlobalPlatform Technology: TEE Certification Process</title>
<author> <author>
<organization/> <organization>GlobalPlatform</organization>
</author> </author>
<date/> <date month="January" year="2021"/>
</front> </front>
<refcontent>Public Release Version 2.0</refcontent>
<refcontent>Document Reference: GP_PRO_023</refcontent>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="examples"> <section anchor="examples">
<name>Examples</name> <name>Examples</name>
<t>Most examples are shown as just a Claims-Set that would be a payload fo <t>Most examples are shown as a Claims-Set that would be a payload for a C
r a CWT, JWT, detached EAT bundle or future token types. WT, a JWT, a detached EAT bundle, or future token types. The signing is left off
The signing is left off so the Claims-Set is easier to see. so the Claims-Set is easier to see. Some examples of signed tokens are also giv
Some examples of signed tokens are also given.</t> en.</t>
<t><cref anchor="to-be-removed-2">RFC Editor: When the IANA values are per
manently assigned, please contact the authors so the examples can be regenerated <!--[rfced] Appendix A. Please review this note and let us know if
. Regeneration is required because IANA-assigned values are inside hex and based there are any outstanding actions regarding regenerating the examples.
-64 encoded data and some of these are signed.</cref></t>
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.
-->
<section anchor="claims-set-examples"> <section anchor="claims-set-examples">
<name>Claims Set Examples</name> <name>Claims Set Examples</name>
<section anchor="simple-tee-attestation"> <section anchor="simple-tee-attestation">
<name>Simple TEE Attestation</name> <name>Simple TEE Attestation</name>
<t>This is a simple attestation of a TEE that includes a manifest that
is a payload CoSWID to describe the TEE's software.</t> <t>This is a simple attestation of a TEE; it includes a manifest that
<artwork><![CDATA[ is a payload CoSWID to describe the TEE's software.</t>
<!--[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. / / This is an EAT payload that describes a simple TEE. /
{ {
/ eat_nonce / 10: h'48df7b172d70b5a18935d0460a73dd71', / eat_nonce / 10: h'48df7b172d70b5a18935d0460a73dd71',
/ oemboot / 262: true, / oemboot / 262: true,
/ dbgstat / 263: 2, / disabled-since-boot / / dbgstat / 263: 2, / disabled-since-boot /
/ manifests / 272: [ / manifests / 272: [
[ [
258, / CoAP Content ID for CoSWID / 258, / CoAP Content ID for CoSWID /
/ This is byte-string wrapped / / This is a byte-string-wrapped /
/ payload CoSWID. It gives the TEE / / payload CoSWID. It gives the TEE /
/ software name, the version and / / software name, the version, and /
/ the name of the file it is in. / / the name of the file it is in. /
/ {0: "3a24", / / {0: "3a24", /
/ 12: 1, / / 12: 1, /
/ 1: "Acme TEE OS", / / 1: "Acme TEE OS", /
/ 13: "3.1.4", / / 13: "3.1.4", /
/ 2: [{31: "Acme TEE OS", 33: 1}, / / 2: [{31: "Acme TEE OS", 33: 1}, /
/ {31: "Acme TEE OS", 33: 2}], / / {31: "Acme TEE OS", 33: 2}], /
/ 6: { / / 6: { /
/ 17: { / / 17: { /
/ 24: "acme_tee_3.exe" / / 24: "acme_tee_3.exe" /
skipping to change at line 2972 skipping to change at line 3413
/ } / / } /
/ } / / } /
h' a60064336132340c01016b h' a60064336132340c01016b
41636d6520544545204f530d65332e31 41636d6520544545204f530d65332e31
2e340282a2181f6b41636d6520544545 2e340282a2181f6b41636d6520544545
204f53182101a2181f6b41636d652054 204f53182101a2181f6b41636d652054
4545204f5318210206a111a118186e61 4545204f5318210206a111a118186e61
636d655f7465655f332e657865' 636d655f7465655f332e657865'
] ]
] ]
} }]]></sourcecode>
]]></artwork>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
/ A payload CoSWID created by the SW vendor. All this really does / / This is a payload CoSWID created by the software (SW) vendor. All /
/ is name the TEE SW, its version and lists the one file that / / this does is name the TEE SW, name its version, and list the one /
/ makes up the TEE. / / file that makes up the TEE. /
1398229316({ 1398229316({
/ Unique CoSWID ID / 0: "3a24", / Unique CoSWID ID / 0: "3a24",
/ tag-version / 12: 1, / tag-version / 12: 1,
/ software-name / 1: "Acme TEE OS", / software-name / 1: "Acme TEE OS",
/ software-version / 13: "3.1.4", / software-version / 13: "3.1.4",
/ entity / 2: [ / entity / 2: [
{ {
/ entity-name / 31: "Acme TEE OS", / entity-name / 31: "Acme TEE OS",
/ role / 33: 1 / tag-creator / / role / 33: 1 / tag-creator /
skipping to change at line 2999 skipping to change at line 3440
{ {
/ entity-name / 31: "Acme TEE OS", / entity-name / 31: "Acme TEE OS",
/ role / 33: 2 / software-creator / / role / 33: 2 / software-creator /
} }
], ],
/ payload / 6: { / payload / 6: {
/ ...file / 17: { / ...file / 17: {
/ ...fs-name / 24: "acme_tee_3.exe" / ...fs-name / 24: "acme_tee_3.exe"
} }
} }
}) })]]></sourcecode>
]]></artwork>
</section> </section>
<section anchor="submodules-for-board-and-device"> <section anchor="submodules-for-board-and-device">
<name>Submodules for Board and Device</name> <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 / / This example shows use of submodules to give information /
/ about the chip, board and overall device. / / about the chip, board, and overall device. /
/ / / /
/ The main attestation is associated with the chip with the / / The main attestation is associated with the chip /
/ CPU and running the main OS. It is what has the keys and / / containing the CPU and running the main OS. It is what /
/ produces the token. / / has the keys and produces the token. /
/ / / /
/ The board is made by a different vendor than the chip. / / The board is made by a different vendor than the chip; /
/ Perhaps it is some generic IoT board. / / perhaps it is some generic IoT board. /
/ / / /
/ The device is some specific appliance that is made by a / / The device is some specific appliance that is made by a /
/ different vendor than either the chip or the board. / / different vendor than either the chip or the board. /
/ / / /
/ Here the board and device submodules aren't the typical / / Here, the board and device submodules aren't the typical /
/ target environments as described by the RATS architecture / / target environments as described by RATS Architecture /
/ document, but they are a valid use of submodules. / / (RFC 9334), but they are a valid use of submodules. /
{ {
/ eat_nonce / 10: h'e253cabedc9eec24ac4e25bcbeaf7765', / eat_nonce / 10: h'e253cabedc9eec24ac4e25bcbeaf7765',
/ ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea', / ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea',
/ oemid / 258: h'894823', / IEEE OUI format OEM ID / / oemid / 258: h'894823', / IEEE OUI format OEM ID /
/ hwmodel / 259: h'549dcecc8b987c737b44e40f7c635ce8' / hwmodel / 259: h'549dcecc8b987c737b44e40f7c635ce8'
/ Hash of chip model name /, / Hash of chip model name /,
/ hwversion / 260: ["1.3.4", 1], / Multipartnumeric / / hwversion / 260: ["1.3.4", 1], / Multipartnumeric /
/ swname / 270: "Acme OS", / swname / 270: "Acme OS",
/ swversion / 271: ["3.5.5", 1], / swversion / 271: ["3.5.5", 1],
skipping to change at line 3049 skipping to change at line 3503
/ Hash of board module name /, / Hash of board module name /,
/ hwversion / 260: ["2.0a", 2] / multipartnumeric+sfx / / hwversion / 260: ["2.0a", 2] / multipartnumeric+sfx /
}, },
/ A submodule to hold claims about the overall device / / A submodule to hold claims about the overall device /
"device" : { "device" : {
/ oemid / 258: 61234, / PEN Format OEM ID / / oemid / 258: 61234, / PEN Format OEM ID /
/ hwversion / 260: ["4.0", 1] / Multipartnumeric / / hwversion / 260: ["4.0", 1] / Multipartnumeric /
} }
} }
} }]]></sourcecode>
]]></artwork>
</section> </section>
<section anchor="eat-produced-by-attestation-hardware-block"> <section anchor="eat-produced-by-attestation-hardware-block">
<name>EAT Produced by Attestation Hardware Block</name> <name>EAT Produced by an Attestation Hardware Block</name>
<artwork><![CDATA[
/ This is an example of a token produced by a HW block / <!--[rfced] Appendix A.1.3. Is the intention to say that 47 bytes are
/ purpose-built for attestation. Only the nonce claim changes / encoded in CBOR "including" an 8-byte nonce and 16-byte UEID as
/ from one attestation to the next as the rest either come / shown below? Please let us know how we may update for clarity.
/ directly from the hardware or from one-time-programmable memory /
/ (e.g. a fuse). 47 bytes encoded in CBOR (8 byte nonce, 16 byte / Original:
/ UEID). / 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 hardware block /
/ purposely built for attestation. Only the nonce claim changes /
/ from one attestation to the next as the rest come from either /
/ the hardware directly or from one-time-programmable memory /
/ (e.g., a fuse). 47 bytes are encoded in CBOR (8-byte nonce, /
/ 16-byte UEID). /
{ {
/ eat_nonce / 10: h'd79b964ddd5471c1393c8888', / eat_nonce / 10: h'd79b964ddd5471c1393c8888',
/ ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea', / ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea',
/ oemid / 258: 64242, / Private Enterprise Number / / oemid / 258: 64242, / Private Enterprise Number /
/ oemboot / 262: true, / oemboot / 262: true,
/ dbgstat / 263: 3, / disabled-permanently / / dbgstat / 263: 3, / disabled-permanently /
/ hwversion / 260: [ "3.1", 1 ] / Type is multipartnumeric / / hwversion / 260: [ "3.1", 1 ] / Type is multipartnumeric /
} }]]></sourcecode>
]]></artwork>
</section> </section>
<section anchor="key-key-store-attestation"> <section anchor="key-key-store-attestation">
<name>Key / Key Store Attestation</name> <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 / / This is an attestation of a public key and the key store /
/ implementation that protects and manages it. The key store / / implementation that protects and manages it. The key store /
/ implementation is in a security-oriented execution / / implementation is in a security-oriented execution /
/ environment separate from the high-level OS (HLOS), for / / environment separate from the high-level OS (HLOS), for /
/ example a Trusted Execution Environment (TEE). The key store / / example, a Trusted Execution Environment (TEE). The key /
/ is the Attester. / / store is the attester. /
/ / / /
/ There is some attestation of the high-level OS, just version / / There is some attestation of the HLOS, just version and /
/ and boot & debug status. It is a Claims-Set submodule because/ / boot and debug status. It is a Claims-Set submodule because /
/ it has lower security level than the key store. The key / / it has a lower security level than the key store. The key /
/ store's implementation has access to info about the HLOS, so / / store's implementation has access to info about the HLOS, so /
/ it is able to include it. / / it is able to include it. /
/ / / /
/ A key and an indication of the user authentication given to / / A key and an indication of the user authentication given to /
/ allow access to the key is given. The labels for these are / / allow access to the key is given. The labels for these are /
/ in the private space since this is just a hypothetical / / in the private space as this is a hypothetical example, /
/ example, not part of a standard protocol. / / not part of a standard protocol. /
{ {
/ eat_nonce / 10: h'99b67438dba40743266f70bf75feb1026d5134 / eat_nonce / 10: h'99b67438dba40743266f70bf75feb1026d5134
97a229bfe8', 97a229bfe8',
/ oemboot / 262: true, / oemboot / 262: true,
/ dbgstat / 263: 2, / disabled-since-boot / / dbgstat / 263: 2, / disabled-since-boot /
/ manifests / 272: [ / manifests / 272: [
[ 258, / CoAP Content ID. / [ 258, / CoAP Content ID. /
h'a600683762623334383766 h'a600683762623334383766
0c000169436172626f6e6974650d6331 0c000169436172626f6e6974650d6331
skipping to change at line 3150 skipping to change at line 3629
] ]
/ Above is an encoded CoSWID / / Above is an encoded CoSWID /
/ with the following data: / / with the following data: /
/ SW Name: "Droid OS" / / SW Name: "Droid OS" /
/ SW Vers: "R2.D2" / / SW Vers: "R2.D2" /
/ SW Creator: / / SW Creator: /
/ "Industrial Automation"/ / "Industrial Automation"/
] ]
} }
} }
} }]]></sourcecode>
]]></artwork>
</section> </section>
<section anchor="software-measurements-of-an-iot-device"> <section anchor="software-measurements-of-an-iot-device">
<name>Software Measurements of an IoT Device</name> <name>Software Measurements of an IoT Device</name>
<t>This is a simple token that might be for an IoT device. <t>This is a simple token that might be for an IoT device.
It includes CoSWID format measurments of the SW. It includes CoSWID format measurements of the SW. The CoSWID is byte string wrap
The CoSWID is in byte-string wrapped in the token and also shown in diagnostic f ped in the token and is also shown in diagnostic form.</t>
orm.</t> <sourcecode type=""><![CDATA[
<artwork><![CDATA[
/ This EAT payload is for an IoT device with a TEE. The attestation / / 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 / / 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 / / 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 / / submodule contains claims for the IoT OS. The TEE also measures /
/ the IoT OS and puts the measurements in the submodule. / / the IoT OS and puts the measurements in the submodule. /
{ {
/ eat_nonce / 10: h'5e19fba4483c7896', / eat_nonce / 10: h'5e19fba4483c7896',
/ oemboot / 262: true, / oemboot / 262: true,
/ dbgstat / 263: 2, / disabled-since-boot / / dbgstat / 263: 2, / disabled-since-boot /
/ oemid / 258: h'8945ad', / IEEE CID based / / oemid / 258: h'8945ad', / IEEE CID based /
/ ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea', / ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea',
/ submods / 266: { / submods / 266: {
"OS" : { "OS" : {
/ oemboot / 262: true, / oemboot / 262: true,
/ dbgstat / 263: 2, / disabled-since-boot / / dbgstat / 263: 2, / disabled-since-boot /
/ measurements / 273: [ / measurements / 273: [
[ [
258, / CoAP Content ID / 258, / CoAP Content ID /
/ This is a byte-string wrapped / / This is a byte-string-wrapped /
/ evidence CoSWID. It has / / evidence CoSWID. It has /
/ hashes of the main files of / / hashes of the main files of /
/ the IoT OS. / / the IoT OS. /
h'a600663463613234350c h'a600663463613234350c
17016d41636d6520522d496f542d4f 17016d41636d6520522d496f542d4f
530d65332e312e3402a2181f724163 530d65332e312e3402a2181f724163
6d6520426173652041747465737465 6d6520426173652041747465737465
7218210103a11183a318187161636d 7218210103a11183a318187161636d
655f725f696f745f6f732e65786514 655f725f696f745f6f732e65786514
1a0044b349078201582005f6b327c1 1a0044b349078201582005f6b327c1
skipping to change at line 3205 skipping to change at line 3682
280c4bb8c75f716a43c99526694caa 280c4bb8c75f716a43c99526694caa
be529571f5569bb7dc542f98a31818 be529571f5569bb7dc542f98a31818
6a636f6d6d6f6e2e6c6962141a0023 6a636f6d6d6f6e2e6c6962141a0023
3d3b0782015820a6a9dcdfb3884da5 3d3b0782015820a6a9dcdfb3884da5
f884e4e1e8e8629958c2dbc7027414 f884e4e1e8e8629958c2dbc7027414
43a913e34de9333be6' 43a913e34de9333be6'
] ]
] ]
} }
} }
} }]]></sourcecode>
]]></artwork> <sourcecode type=""><![CDATA[
<artwork><![CDATA[ / This is an evidence CoSWID created for the "Acme R-IoT-OS" /
/ An evidence CoSWID created for the "Acme R-IoT-OS" created by / / that is created by the "Acme Base Attester" (both fictitious /
/ the "Acme Base Attester" (both fictious names). It provides / / names). It provides measurements of the SW (other than the /
/ measurements of the SW (other than the attester SW) on the / / attester SW) on the device. /
/ device. /
1398229316({ 1398229316({
/ Unique CoSWID ID / 0: "4ca245", / Unique CoSWID ID / 0: "4ca245",
/ tag-version / 12: 23, / Attester-maintained counter / / tag-version / 12: 23, / Attester-maintained counter /
/ software-name / 1: "Acme R-IoT-OS", / software-name / 1: "Acme R-IoT-OS",
/ software-version / 13: "3.1.4", / software-version / 13: "3.1.4",
/ entity / 2: { / entity / 2: {
/ entity-name / 31: "Acme Base Attester", / entity-name / 31: "Acme Base Attester",
/ role / 33: 1 / tag-creator / / role / 33: 1 / tag-creator /
}, },
skipping to change at line 3260 skipping to change at line 3736
/ ...hash / 7: [ / ...hash / 7: [
1, / SHA-256 / 1, / SHA-256 /
h'a6a9dcdfb3884da5 h'a6a9dcdfb3884da5
f884e4e1e8e86299 f884e4e1e8e86299
58c2dbc702741443 58c2dbc702741443
a913e34de9333be6' a913e34de9333be6'
] ]
} }
] ]
} }
}) })]]></sourcecode>
]]></artwork>
</section> </section>
<section anchor="attestation-results-in-json"> <section anchor="attestation-results-in-json">
<name>Attestation Results in JSON</name> <name>Attestation Results in JSON</name>
<t>This is a JSON-encoded payload that might be the output of a verifi er that evaluated the IoT Attestation example immediately above.</t> <t>This is a JSON-encoded payload that might be the output of a verifi er 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 debug status directly through to the relying party. <t>This particular verifier knows enough about the TEE attester to be able to pass claims such as debug status directly through to the relying party.
The verifier also knows the reference values for the measured software component s and is able to check them. The verifier also knows the reference values for the measured software component s and is able to check them.
It informs the relying party that they were correct in the "measres" claim. It informs the relying party that they were correct in the "measres" claim.
"Trustus Verifications" is the name of the services that verifies the software c
omponent measurements.</t> <!--[rfced] Appendix A.1.6. We believe "Trustus Verifications" is a
<artwork><![CDATA[ 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 co
mponent measurements.</t>
<sourcecode type=""><![CDATA[
{ {
"eat_nonce": "jkd8KL-8xQk", "eat_nonce": "jkd8KL-8xQk",
"oemboot": true, "oemboot": true,
"dbgstat": "disabled-since-boot", "dbgstat": "disabled-since-boot",
"oemid": "iUWt", "oemid": "iUWt",
"ueid": "AZj1Ck_2wFhhyIYNE6Y4", "ueid": "AZj1Ck_2wFhhyIYNE6Y4",
"swname": "Acme R-IoT-OS", "swname": "Acme R-IoT-OS",
"swversion": [ "swversion": [
"3.1.4" "3.1.4"
], ],
skipping to change at line 3292 skipping to change at line 3784
[ [
"Trustus Measurements", "Trustus Measurements",
[ [
[ [
"all", "all",
"success" "success"
] ]
] ]
] ]
] ]
} }]]></sourcecode>
]]></artwork>
</section> </section>
<section anchor="json-encoded-token-with-submodules"> <section anchor="json-encoded-token-with-submodules">
<name>JSON-encoded Token with Submodules</name> <name>JSON-Encoded Token with Submodules</name>
<t>This example has its lines wrapped per <xref target="RFC8792"/>.</t <t>The lines in this example are wrapped per <xref target="RFC8792"/>.
> </t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
{ {
"eat_nonce": "lI-IYNE6Rj6O", "eat_nonce": "lI-IYNE6Rj6O",
"ueid": "AJj1Ck_2wFhhyIYNE6Y46g==", "ueid": "AJj1Ck_2wFhhyIYNE6Y46g==",
"secboot": true, "secboot": true,
"dbgstat": "disabled-permanently", "dbgstat": "disabled-permanently",
"iat": 1526542894, "iat": 1526542894,
"submods": { "submods": {
"Android App Foo": { "Android App Foo": {
"swname": "Foo.app" "swname": "Foo.app"
}, },
skipping to change at line 3326 skipping to change at line 3818
"Linux Android": { "Linux Android": {
"swname": "Android" "swname": "Android"
}, },
"Subsystem J": [ "Subsystem J": [
"JWT", "JWT",
"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJKLUF0dGVzd\ "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJKLUF0dGVzd\
GVyIiwiaWF0IjoxNjUxNzc0ODY4LCJleHAiOm51bGwsImF1ZCI6IiIsInN1YiI6IiJ9.\ GVyIiwiaWF0IjoxNjUxNzc0ODY4LCJleHAiOm51bGwsImF1ZCI6IiIsInN1YiI6IiJ9.\
gjw4nFMhLpJUuPXvMPzK1GMjhyJq2vWXg1416XKszwQ" gjw4nFMhLpJUuPXvMPzK1GMjhyJq2vWXg1416XKszwQ"
] ]
} }
} }]]></sourcecode>
]]></artwork>
</section> </section>
</section> </section>
<section anchor="signed-token-examples"> <section anchor="signed-token-examples">
<name>Signed Token Examples</name> <name>Signed Token Examples</name>
<section anchor="basic-cwt-example"> <section anchor="basic-cwt-example">
<name>Basic CWT Example</name> <name>Basic CWT Example</name>
<t>This is a simple CWT-format token signed with the ECDSA algorithm.< <t>This is a simple CWT-format token signed with the Elliptic Curve Di
/t> gital Signature Algorithm (ECDSA).</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
/ This is a full CWT-format token. The payload is the / / This is a full CWT-format token. The payload is the /
/ attestation hardware block above. The main structure / / attestation hardware block above. The visible main /
/ visible is that of the COSE_Sign1. / / structure is that of the COSE_Sign1. /
61( 18( [ 61( 18( [
h'A10126', / protected headers / h'A10126', / protected headers /
{}, / empty unprotected headers / {}, / empty unprotected headers /
h'A60A4CD79B964DDD5471C1393C88881901005001 h'A60A4CD79B964DDD5471C1393C88881901005001
98F50A4FF6C05861C8860D13A638EA19010219FA 98F50A4FF6C05861C8860D13A638EA19010219FA
F2190106F5190107031901048263332E3101', / payload / F2190106F5190107031901048263332E3101', / payload /
h'9B9B2F5E470000F6A20C8A4157B5763FC45BE759 h'9B9B2F5E470000F6A20C8A4157B5763FC45BE759
9A5334028517768C21AFFB845A56AB557E0C8973 9A5334028517768C21AFFB845A56AB557E0C8973
A07417391243A79C478562D285612E292C622162 A07417391243A79C478562D285612E292C622162
AB233787' / signature / AB233787' / signature /
] ) ) ] ) )]]></sourcecode>
]]></artwork>
</section> </section>
<section anchor="cbor-encoded-detached-eat-bundle"> <section anchor="cbor-encoded-detached-eat-bundle">
<name>CBOR-encoded Detached EAT Bundle</name> <name>CBOR-Encoded Detached EAT Bundle</name>
<t>In this detached EAT bundle, the main token is produced by a HW att <t>In this detached EAT bundle, the main token is produced by a hardwa
estation block. re (HW) attestation block.
The detached Claims-Set is produced by a TEE and is largely identical to the Sim The detached Claims-Set is produced by a TEE and is largely identical to the sim
ple TEE examples above. ple TEE examples above. The TEE digests its Claims-Set and feeds that digest to
The TEE digests its Claims-Set and feeds that digest to the HW block.</t> the HW block.</t>
<t>In a better example the attestation produced by the HW block would <t>In a better example, the attestation produced by the HW block would
be a CWT and thus signed and secured by the HW block. be a CWT and thus signed and secured by the HW block.
Since the signature covers the digest from the TEE that Claims-Set is also secur Since the signature covers the digest from the TEE, that Claims-Set is also secu
ed.</t> red.</t>
<t>The detached EAT bundle itself can be assembled by untrusted softwa re.</t> <t>The detached EAT bundle itself can be assembled by untrusted softwa re.</t>
<artwork><![CDATA[
<sourcecode type=""><![CDATA[
/ This is a detached EAT bundle tag. / / This is a detached EAT bundle tag. /
602([ 602([
/ First part is a full EAT token with claims like nonce and / / The first part is a full EAT token with claims like nonce /
/ UEID. Most importantly, it includes a submodule that is a / / and UEID. Most importantly, it includes a submodule that /
/ detached digest which is the hash of the "TEE" claims set / / is a detached digest, which is the hash of the "TEE" /
/ in the next section. The COSE payload follows: / / claims set in the next section. The COSE payload is as /
/ follows: /
/ { / / { /
/ 10: h'948F8860D13A463E', / / 10: h'948F8860D13A463E', /
/ 256: h'0198F50A4FF6C05861C8860D13A638EA', / / 256: h'0198F50A4FF6C05861C8860D13A638EA', /
/ 258: 64242, / / 258: 64242, /
/ 262: true, / / 262: true, /
/ 263: 3, / / 263: 3, /
/ 260: ["3.1", 1], / / 260: ["3.1", 1], /
/ 266: { / / 266: { /
/ "TEE": [ / / "TEE": [ /
/ -16, / / -16, /
skipping to change at line 3394 skipping to change at line 3887
/ } / / } /
h'D83DD28443A10126A05866A80A48948F8860D13A463E1901 h'D83DD28443A10126A05866A80A48948F8860D13A463E1901
00500198F50A4FF6C05861C8860D13A638EA19010219FAF2 00500198F50A4FF6C05861C8860D13A638EA19010219FAF2
19010504190106F5190107031901048263332E310119010A 19010504190106F5190107031901048263332E310119010A
A163544545822F58208DEF652F47000710D9F466A4C666E2 A163544545822F58208DEF652F47000710D9F466A4C666E2
09DD74F927A1CEA352B03143E188838ABE5840F690CB0388 09DD74F927A1CEA352B03143E188838ABE5840F690CB0388
677FA624A3775FD7CBC4E8409EC9816BE32FA474733B0F98 677FA624A3775FD7CBC4E8409EC9816BE32FA474733B0F98
C27FBAEDBBC9963B9CB5ECC03C3E35B3AFC0B7B35B495DEA C27FBAEDBBC9963B9CB5ECC03C3E35B3AFC0B7B35B495DEA
C0997122EA867F07B8D5EB', C0997122EA867F07B8D5EB',
{ {
/ A CBOR-encoded byte-string wrapped EAT claims-set. It / / A CBOR-encoded byte-string-wrapped EAT claims-set. It /
/ contains claims suitable for a TEE. / / contains claims suitable for a TEE. /
"TEE" : h'a40a48948f8860d13a463e190106f519010702 "TEE" : h'a40a48948f8860d13a463e190106f519010702
190111818218795858a60064336132340c0101 190111818218795858a60064336132340c0101
6b41636d6520544545204f530d65332e312e34 6b41636d6520544545204f530d65332e312e34
0282a2181f6b41636d6520544545204f531821 0282a2181f6b41636d6520544545204f531821
01a2181f6b41636d6520544545204f53182102 01a2181f6b41636d6520544545204f53182102
06a111a118186e61636d655f7465655f332e65 06a111a118186e61636d655f7465655f332e65
7865' 7865'
} }
]) ])]]></sourcecode>
]]></artwork> <sourcecode type=""><![CDATA[
<artwork><![CDATA[ / This example contains a submodule that is a detached digest, /
/ This example contains submodule that is a detached digest, / / which is the hash of a Claims-Set conveyed outside this /
/ which is the hash of a Claims-Set convey outside this token. / / token. Additionally, there is an example of a token from an /
/ Other than that is is the other example of a token from an /
/ attestation HW block. / / attestation HW block. /
{ {
/ eat_nonce / 10: h'3515744961254b41a6cf9c02', / eat_nonce / 10: h'3515744961254b41a6cf9c02',
/ ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea', / ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea',
/ oemid / 258: 64242, / Private Enterprise Number / / oemid / 258: 64242, / Private Enterprise Number /
/ oemboot / 262: true, / oemboot / 262: true,
/ dbgstat / 263: 3, / disabled-permanently / / dbgstat / 263: 3, / disabled-permanently /
/ hwversion / 260: [ "3.1", 1 ], / multipartnumeric / / hwversion / 260: [ "3.1", 1 ], / multipartnumeric /
/ submods/ 266: { / submods/ 266: {
"TEE": [ / detached digest submod / "TEE": [ / detached digest submod /
-16, / SHA-256 / -16, / SHA-256 /
h'e5cf95fd24fab7144674 h'e5cf95fd24fab7144674
2dd58d43dae178e55fe2 2dd58d43dae178e55fe2
b94291a9291082ffc263 b94291a9291082ffc263
5a0b' 5a0b'
] ]
} }
} }]]></sourcecode>
]]></artwork>
</section> </section>
<section anchor="json-encoded-detached-eat-bundle"> <section anchor="json-encoded-detached-eat-bundle">
<name>JSON-encoded Detached EAT Bundle</name> <name>JSON-Encoded Detached EAT Bundle</name>
<t>In this bundle there are two detached Claims-Sets, "Audio Subsystem <t>In this bundle, there are two detached Claims-Sets: "Audio Subsyste
" and "Graphics Subsystem". m" 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 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 with a key of "xxxxxx".</t> The JWT itself is protected using the Hashed Message Authentication Code (HMAC)
<t>This example has its lines wrapped per <xref target="RFC8792"/>.</t with a key of "xxxxxx".</t>
> <t>The lines in this example are wrapped per <xref target="RFC8792"/>.
<artwork><![CDATA[ </t>
<sourcecode type=""><![CDATA[
[ [
[ [
"JWT", "JWT",
"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlYXRfbm9uY2UiOiJ5dT\ "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlYXRfbm9uY2UiOiJ5dT\
c2Tk44SXVWNmUiLCJzdWJtb2RzIjp7IkF1ZGlvIFN1YnN5c3RlbSI6WyJESUdFU1QiLF\ c2Tk44SXVWNmUiLCJzdWJtb2RzIjp7IkF1ZGlvIFN1YnN5c3RlbSI6WyJESUdFU1QiLF\
siU0hBLTI1NiIsIkZSRW4yVlR3aTk5cWNNRVFzYmxtTVFnM2I1b2ZYUG5OM1BJYW5CME\ siU0hBLTI1NiIsIkZSRW4yVlR3aTk5cWNNRVFzYmxtTVFnM2I1b2ZYUG5OM1BJYW5CME\
5RT3MiXV0sIkdyYXBoaWNzIFN1YnN5c3RlbSI6WyJESUdFU1QiLFsiU0hBLTI1NiIsIk\ 5RT3MiXV0sIkdyYXBoaWNzIFN1YnN5c3RlbSI6WyJESUdFU1QiLFsiU0hBLTI1NiIsIk\
52M3NqUVU3Q1Z0RFRka0RTUlhWcFZDNUNMVFBCWmVQWWhTLUhoVlZWMXMiXV19fQ.FYs\ 52M3NqUVU3Q1Z0RFRka0RTUlhWcFZDNUNMVFBCWmVQWWhTLUhoVlZWMXMiXV19fQ.FYs\
7R-TKhgAk85NyCOPQlbtGGjFM_3chnhBEOuM6qCo" 7R-TKhgAk85NyCOPQlbtGGjFM_3chnhBEOuM6qCo"
], ],
{ {
"Audio Subsystem" : "ewogICAgImVhdF9ub25jZSI6ICJsSStJWU5FNlJ\ "Audio Subsystem" : "ewogICAgImVhdF9ub25jZSI6ICJsSStJWU5FNlJ\
qNk8iLAogICAgInVlaWQiOiAiQWROSlU0b1lYdFVwQStIeDNqQTcvRFEiCiAgICAib2V\ qNk8iLAogICAgInVlaWQiOiAiQWROSlU0b1lYdFVwQStIeDNqQTcvRFEiCiAgICAib2V\
taWQiOiAiaVVXdCIsCiAgICAib2VtYm9vdCI6IHRydWUsIAogICAgInN3bmFtZSI6ICJ\ taWQiOiAiaVVXdCIsCiAgICAib2VtYm9vdCI6IHRydWUsIAogICAgInN3bmFtZSI6ICJ\
BdWRpbyBQcm9jZXNzb3IgT1MiCn0K", BdWRpbyBQcm9jZXNzb3IgT1MiCn0K",
"Graphics Subsystem" : "ewogICAgImVhdF9ub25jZSI6ICJZWStJWU5F\ "Graphics Subsystem" : "ewogICAgImVhdF9ub25jZSI6ICJZWStJWU5F\
NlJqNk8iLAogICAgInVlaWQiOiAiQWVUTUlRQ1NVMnhWQmtVdGlndHU3bGUiCiAgICAi\ NlJqNk8iLAogICAgInVlaWQiOiAiQWVUTUlRQ1NVMnhWQmtVdGlndHU3bGUiCiAgICAi\
b2VtaWQiOiA3NTAwMCwKICAgICJvZW1ib290IjogdHJ1ZSwgCiAgICAic3duYW1lIjog\ b2VtaWQiOiA3NTAwMCwKICAgICJvZW1ib290IjogdHJ1ZSwgCiAgICAic3duYW1lIjog\
IkdyYXBoaWNzIE9TIgp9Cg" IkdyYXBoaWNzIE9TIgp9Cg"
} }
] ]]]></sourcecode>
]]></artwork>
</section> </section>
</section> </section>
</section> </section>
<section anchor="UEID-Design"> <section anchor="UEID-Design">
<name>UEID Design Rationale</name> <name>UEID Design Rationale</name>
<section anchor="collision-probability"> <section anchor="collision-probability">
<name>Collision Probability</name> <name>Collision Probability</name>
<t>This calculation is to determine the probability of a collision of <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 type 0x01 UEIDs given the total possible entity population and the number of
entities in a particular entity management database.</t> entities in a particular entity management database.</t>
<t>Three different sized databases are considered. The number of devices <t>Three different-sized databases are considered. The number of devices
per person roughly models non-personal devices such as traffic lights, per person roughly models non-personal devices such as traffic lights,
devices in stores they shop in, facilities they work in and so on, devices in stores they shop in, facilities they work in, and so on,
even considering individual light bulbs. A device may have even considering individual light bulbs. A device may have
individually attested subsystems, for example parts of a car or a individually attested subsystems, for example, parts of a car or a
mobile phone. It is assumed that the largest database will have at mobile phone. It is assumed that the largest database will have at
most 10% of the world's population of devices. Note that databases most 10% of the world's population of devices. Note that databases
that handle more than a trillion records exist today.</t> that handle more than a trillion records exist today.</t>
<t>The trillion-record database size models an easy-to-imagine reality <t>The trillion-record database size models an easy-to-imagine reality
over the next decades. The quadrillion-record database is roughly at over the next decades. The quadrillion-record database is roughly at
the limit of what is imaginable and should probably be accommodated. the limit of what is imaginable and should probably be accommodated.
The 100 quadrillion database is highly speculative perhaps involving The 100 quadrillion database is highly speculative perhaps involving
nanorobots for every person, livestock animal and domesticated nanorobots for every person, livestock animals, and domesticated
bird. It is included to round out the analysis.</t> birds. It is included to round out the analysis.</t>
<t>Note that the items counted here certainly do not have IP address and <t>Note that the items counted here certainly do not have IP addresses a
nd
are not individually connected to the network. They may be connected are not individually connected to the network. They may be connected
to internal buses, via serial links, Bluetooth and so on. This is to internal buses, via serial links, via Bluetooth, and so on. This is
not the same problem as sizing IP addresses.</t> not the same problem as sizing IP addresses.</t>
<table anchor="database-size-examples"> <table align="left" anchor="database-size-examples">
<name>Entity Database Size Examples</name> <name>Entity Database Size Examples</name>
<thead> <thead>
<tr> <tr>
<th align="left">People</th> <th align="left">People</th>
<th align="left">Devices / Person</th> <th align="left">Devices/ Person</th>
<th align="left">Subsystems / Device</th> <th align="left">Subsystems/ Device</th>
<th align="left">Database Portion</th> <th align="left">Database Portion</th>
<th align="left">Database Size</th> <th align="left">Database Size</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">10 billion</td> <td align="left">10 billion</td>
<td align="left">100</td> <td align="left">100</td>
<td align="left">10</td> <td align="left">10</td>
<td align="left">10%</td> <td align="left">10%</td>
<td align="left">trillion (10^12)</td> <td align="left">trillion (10<sup>12</sup>)</td>
</tr> </tr>
<tr> <tr>
<td align="left">10 billion</td> <td align="left">10 billion</td>
<td align="left">100,000</td> <td align="left">100,000</td>
<td align="left">10</td> <td align="left">10</td>
<td align="left">10%</td> <td align="left">10%</td>
<td align="left">quadrillion (10^15)</td> <td align="left">quadrillion (10<sup>15</sup>)</td>
</tr> </tr>
<tr> <tr>
<td align="left">100 billion</td> <td align="left">100 billion</td>
<td align="left">1,000,000</td> <td align="left">1,000,000</td>
<td align="left">10</td> <td align="left">10</td>
<td align="left">10%</td> <td align="left">10%</td>
<td align="left">100 quadrillion (10^17)</td> <td align="left">100 quadrillion (10<sup>17</sup>)</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>This is conceptually similar to the Birthday Problem where m is the <t>This is conceptually similar to the Birthday Problem where m is the
number of possible birthdays, always 365, and k is the number of number of possible birthdays (always 365) and k is the number of
people. It is also conceptually similar to the Birthday Attack where people. It is also conceptually similar to the Birthday Attack where
collisions of the output of hash functions are considered.</t> collisions of the output of hash functions are considered.</t>
<t>The proper formula for the collision calculation is</t> <t>The proper formula for the collision calculation is:</t>
<artwork><![CDATA[ <artwork><![CDATA[
p = 1 - e^{-k^2/(2n)} p = 1 - 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</dd>
<dt>k:</dt> <dd>Actual population</dd>
</dl>
<t>However, for the very large values involved here, this formula
requires floating-point precision higher than commonly available in
calculators and software, so this simple approximation is used. See
<xref target="BirthdayAttack"/>.</t>
p Collision Probability
n Total possible population
k Actual population
]]></artwork>
<t>However, for the very large values involved here, this formula requir
es floating
point precision higher than commonly available in calculators and software so th
is
simple approximation is used. See <xref target="BirthdayAttack"/>.</t>
<artwork><![CDATA[ <artwork><![CDATA[
p = k^2 / 2n p = k^2 / 2n]]></artwork>
]]></artwork>
<t>For this calculation:</t> <t>For this calculation:</t>
<artwork><![CDATA[ <dl newline="false" spacing="compact">
p Collision Probability <dt>p:</dt> <dd>Collision probability</dd>
n Total population based on number of bits in UEID <dt>n:</dt> <dd>Total population based on number of bits in UEID</dd>
k Population in a database <dt>k:</dt> <dd>Population in a database</dd>
]]></artwork> </dl>
<table anchor="ueid-size-options"> <table align="left" anchor="ueid-size-options">
<name>UEID Size Options</name> <name>UEID Size Options</name>
<thead> <thead>
<tr> <tr>
<th align="left">Database Size</th> <th align="left">Database Size</th>
<th align="left">128-bit UEID</th> <th align="left">128-bit UEID</th>
<th align="left">192-bit UEID</th> <th align="left">192-bit UEID</th>
<th align="left">256-bit UEID</th> <th align="left">256-bit UEID</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">trillion (10^12)</td> <td align="left">trillion (10<sup>12</sup>)</td>
<td align="left">2 * 10^-15</td> <td align="left">2 * 10<sup>-15</sup></td>
<td align="left">8 * 10^-35</td> <td align="left">8 * 10<sup>-35</sup></td>
<td align="left">5 * 10^-55</td> <td align="left">5 * 10<sup>-55</sup></td>
</tr> </tr>
<tr> <tr>
<td align="left">quadrillion (10^15)</td> <td align="left">quadrillion (10<sup>15</sup>)</td>
<td align="left">2 * 10^-09</td> <td align="left">2 * 10<sup>-09</sup></td>
<td align="left">8 * 10^-29</td> <td align="left">8 * 10<sup>-29</sup></td>
<td align="left">5 * 10^-49</td> <td align="left">5 * 10<sup>-49</sup></td>
</tr> </tr>
<tr> <tr>
<td align="left">100 quadrillion (10^17)</td> <td align="left">100 quadrillion (10<sup>17</sup>)</td>
<td align="left">2 * 10^-05</td> <td align="left">2 * 10<sup>-05</sup></td>
<td align="left">8 * 10^-25</td> <td align="left">8 * 10<sup>-25</sup></td>
<td align="left">5 * 10^-45</td> <td align="left">5 * 10<sup>-45</sup></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Next, to calculate the probability of a collision occurring in one ye ar's <t>Next, to calculate the probability of a collision occurring in one ye ar's
operation of a database, it is assumed that the database size is in 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 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 a trillion record database would have 100 billion states per year. Each
of those states has the above calculated probability of a collision.</t> of those states has the above calculated probability of a collision.</t>
<t>This assumption is a worst-case since it assumes that each <t>This assumption is a worst-case scenario since it assumes that each
state of the database is completely independent from the previous state. state of the database is completely independent from the previous state.
In reality this is unlikely as state changes will be the addition or In reality, this is unlikely as state changes will be the addition or
deletion of a few records.</t> deletion of a few records.</t>
<t>The following tables gives the time interval until there is a probabi <t>The following table gives the time interval until there is a probabil
lity of ity of
a collision based on there being one tenth the number of states per year a 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> as the number of records in the database.</t>
<artwork><![CDATA[ <artwork><![CDATA[
t = 1 / ((k / 10) * p) t = 1 / ((k / 10) * p)]]></artwork>
<t>For this calculation:</t>
<dl newline="false" spacing="compact">
<dt>t:</dt> <dd>Time until a collision</dd>
<dt>p:</dt> <dd>Collision probability for UEID size</dd>
<dt>k:</dt> <dd>Database size</dd>
</dl>
t Time until a collision <table align="left" anchor="ueid-collision-probability">
p Collision probability for UEID size
k Database size
]]></artwork>
<table anchor="ueid-collision-probability">
<name>UEID Collision Probability</name> <name>UEID Collision Probability</name>
<thead> <thead>
<tr> <tr>
<th align="left">Database Size</th> <th align="left">Database Size</th>
<th align="left">128-bit UEID</th> <th align="left">128-bit UEID</th>
<th align="left">192-bit UEID</th> <th align="left">192-bit UEID</th>
<th align="left">256-bit UEID</th> <th align="left">256-bit UEID</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">trillion (10^12)</td> <td align="left">trillion (10<sup>12</sup>)</td>
<td align="left">60,000 years</td> <td align="left">60,000 years</td>
<td align="left">10^24 years</td> <td align="left">10<sup>24</sup> years</td>
<td align="left">10^44 years</td> <td align="left">10<sup>44</sup> years</td>
</tr> </tr>
<tr> <tr>
<td align="left">quadrillion (10^15)</td> <td align="left">quadrillion (10<sup>15</sup>)</td>
<td align="left">8 seconds</td> <td align="left">8 seconds</td>
<td align="left">10^14 years</td> <td align="left">10<sup>14</sup> years</td>
<td align="left">10^34 years</td> <td align="left">10<sup>34</sup> years</td>
</tr> </tr>
<tr> <tr>
<td align="left">100 quadrillion (10^17)</td> <td align="left">100 quadrillion (10<sup>17</sup>)</td>
<td align="left">8 microseconds</td> <td align="left">8 microseconds</td>
<td align="left">10^11 years</td> <td align="left">10<sup>11</sup> years</td>
<td align="left">10^31 years</td> <td align="left">10<sup>31</sup> years</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Clearly, 128 bits is enough for the near future thus the requirement <t>Clearly, 128 bits is enough for the near future, thus the requirement
that type 0x01 UEIDs be a minimum of 128 bits.</t> that type 0x01 UEIDs be a minimum of 128 bits.</t>
<t>There is no requirement for 256 bits today as quadrillion-record data bases <t>There is no requirement for 256 bits today as quadrillion-record data bases
are not expected in the near future and because this time-to-collision are not expected in the near future and because this time-to-collision
calculation is a very worst case. A future update of the standard may calculation is a very worst-case scenario. A future update of the standard may
increase the requirement to 256 bits, so there is a requirement that increase the requirement to 256 bits, so there is a requirement that
implementations be able to receive 256-bit UEIDs.</t> implementations be able to receive 256-bit UEIDs.</t>
</section> </section>
<section anchor="no-use-of-uuid"> <section anchor="no-use-of-uuid">
<name>No Use of UUID</name> <name>No Use of UUID</name>
<t>A UEID is not a Universally Unique Identifier (UUID) <xref target="RF C9562"/> by conscious choice for the following reasons.</t> <t>A UEID is not a Universally Unique Identifier (UUID) <xref target="RF C9562"/> by conscious choice for the following reasons.</t>
<t>UUIDs are limited to 128 bits which may not be enough for some future <t>UUIDs are limited to 128 bits, which may not be enough for some futur e
use cases.</t> use cases.</t>
<t>Today, cryptographic-quality random numbers are available from common computing platforms. <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. In particular, hardware randomness sources were introduced in CPUs between 2010 and 2015.
Operating systems and cryptographic libraries make use of this hardware. Operating systems and cryptographic libraries make use of this hardware.
Consequently, there is little need for protocols to construct random numbers fro m multiple sources on their own.</t> Consequently, there is little need for protocols to construct random numbers fro m multiple sources on their own.</t>
<t>Version 4 UUIDs do allow for use of such cryptographic-quality <t>Version 4 UUIDs do allow for the use of such cryptographic-quality
random numbers, but do so by mapping into the overall UUID random numbers, but they do so by mapping into the overall UUID
structure of time and clock values. This structure is of no structure of time and clock values. This structure is of no
value here yet adds complexity. It also slightly reduces the value here yet adds complexity. It also slightly reduces the
number of actual bits with entropy.</t> number of actual bits with entropy.</t>
<t>The design of UUID accommodates the construction of a unique identifi <t>The design of UUID accommodates the construction of a unique identifier by th
er by combination of several identifiers that separately do not provide sufficie e combination of several identifiers that separately do not provide sufficient u
nt uniqueness. niqueness.
<!--[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,
and/or manufacturing processes implement UEID in a simple and
direct way.
-->
UEID takes the view that this construction is no longer needed, in particular be cause cryptographic-quality random number generators are readily available. UEID takes the view that this construction is no longer needed, in particular be cause cryptographic-quality random number generators are readily available.
It takes the view that hardware, software and/or manufacturing process implement It takes the view that hardware, software, and/or manufacturing processes implem
UEID in a simple and direct way.</t> ent UEID in a simple and direct way.</t>
<t>Note also that that a type 2 UEID (EUI/MAC) is only 7 bytes compared <t>Note also that a type 2 UEID (EUI/MAC) is only 7 bytes whereas a UUID
to 16 for a UUID.</t> is 16.</t>
</section> </section>
</section> </section>
<section anchor="eat-relation-to-ieee8021ar-secure-device-identity-devid"> <section anchor="eat-relation-to-ieee8021ar-secure-device-identity-devid">
<name>EAT Relation to IEEE.802.1AR Secure Device Identity (DevID)</name> <name>EAT Relation to IEEE.802.1AR Secure Device Identity (DevID)</name>
<t>This section describes several distinct ways in which an IEEE IDevID <x <t>This section describes several distinct ways in which an IEEE Initial D
ref target="IEEE.802.1AR"/> relates to EAT, particularly to UEID and SUEID.</t> evice Identifier (IDevID) <xref target="IEEE.802.1AR"/> relates to EAT, particul
<t><xref target="IEEE.802.1AR"/> orients around the definition of an imple arly to UEID and SUEID.</t>
mentation called a "DevID Module." <t><xref target="IEEE.802.1AR"/> orients around the definition of an imple
It describes how IDevIDs and LDevIDs are stored, protected and accessed using a mentation called a "DevID Module".
DevID Module. It describes how IDevIDs and LDevIDs are stored, protected, and accessed using a
A particular level of defense against attack that should be achieved to be a Dev DevID Module.
ID is defined. A particular level of defense against attack that should be achieved to be a Dev
ID is defined here.
The intent is that IDevIDs and LDevIDs can be used with any network protocol or message format. The intent is that IDevIDs and LDevIDs can be used with any network protocol or message format.
In these protocols and message formats the DevID secret is used to sign a nonce or similar to prove the association of the DevID certificates with the device.</ t> In these protocols and message 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 relyin g party, the very thing that is not defined in <xref target="IEEE.802.1AR"/>. <t>By contrast, EAT standardizes a message format that is sent to a relyin g party, the very thing that is not defined in <xref target="IEEE.802.1AR"/>.
Nor does EAT give details on how keys, data and such are stored, protected and a ccessed. Nor does EAT give details on how keys, data, and such are stored, protected, and accessed.
EAT is intended to work with a variety of different on-device implementations ra nging from minimal protection of assets to the highest levels of asset protectio n. EAT is intended to work with a variety of different on-device implementations ra nging from minimal protection of assets to the highest levels of asset protectio n.
It does not define any particular level of defense against attack, instead provi ding a set of security considerations.</t> It does not define any particular level of defense against attack; instead, it p rovides a set of security considerations.</t>
<t>EAT and DevID can be viewed as complimentary when used together or as c ompeting to provide a device identity service.</t> <t>EAT and DevID can be viewed as complimentary when used together or as c ompeting to provide a device identity service.</t>
<section anchor="devid-used-with-eat"> <section anchor="devid-used-with-eat">
<name>DevID Used With EAT</name> <name>DevID Used with EAT</name>
<t>As just described, EAT standardizes a message format and <xref target <t>As described above, EAT standardizes a message format, but <xref targ
="IEEE.802.1AR"/> does not. et="IEEE.802.1AR"/> does not.
Vice versa, EAT does not define a device implementation, but DevID does.</t> 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. <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 DevID secret becomes the attestation key used to sign EATs, and the DevID an
The DevID and its certificate chain become the endorsement sent to the verifier. d its certificate chain become the endorsement sent to the verifier.</t>
</t> <t>In this case, the EAT and the DevID are likely to both provide a devi
<t>In this case, the EAT and the DevID are likely to both provide a devi ce identifier (e.g., a serial number).
ce identifier (e.g. a serial number). In the EAT, it is the UEID (or SUEID). In the DevID (used as an endorsement), it
In the EAT it is the UEID (or SUEID). is a device serial number included in the subject field of the DevID certificat
In the DevID (used as an endorsement), it is a device serial number included in e. For this use, it is a good idea for the serial numbers to be the same or for
the subject field of the DevID certificate. the UEID to be a hash of the DevID serial number.</t>
It is probably a good idea in this use for them to be the same serial number or
for the UEID to be a hash of the DevID serial number.</t>
</section> </section>
<section anchor="how-eat-provides-an-equivalent-secure-device-identity"> <section anchor="how-eat-provides-an-equivalent-secure-device-identity">
<name>How EAT Provides an Equivalent Secure Device Identity</name> <name>How EAT Provides an Equivalent Secure Device Identity</name>
<t>The UEID, SUEID and other claims like OEM ID are equivalent to the se cure device identity put into the subject field of a DevID certificate. <t>The UEID, SUEID, and other claims such as OEM ID are equivalent to th e secure device identity that is put into the subject field of a DevID certifica te.
These EAT claims can represent all the same fields and values that can be put in a DevID certificate subject. 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> EAT explicitly and carefully defines a variety of useful claims.</t>
<t>EAT secures the conveyance of these claims by having them signed on t he device by the attestation key when the EAT is generated. <t>EAT secures the conveyance of these claims by having them signed on t he device by the attestation key when the EAT is generated.
EAT also signs the nonce that gives freshness at this time. EAT also signs the nonce that gives freshness at this time.
Since these claims are signed for every EAT generated, they can include things t Since these claims are signed for every EAT generated, they can include things t
hat vary over time like GPS location.</t> hat vary over time such as GPS location.</t>
<t>DevID secures the device identity fields by having them signed by the <t>DevID secures the device identity fields when they are signed by the
manufacturer of the device into a certificate. manufacturer of the device into a certificate.
That certificate is created once during the manufacturing of the device and neve That certificate is created once during the manufacturing of the device and neve
r changes so the fields cannot change.</t> r changes, so the fields cannot change.</t>
<t>So in one case the signing of the identity happens on the device and <t>So in one case, the signing of the identity happens on the device, an
the other in a manufacturing facility, d in the other case, it happens in a manufacturing facility. However, in both ca
but in both cases the signing of the nonce that proves the binding to the actual ses, the signing of the nonce that proves the binding to the actual device happe
device happens on the device.</t> ns on the device.</t>
<t>While EAT does not specify how the signing keys, signature process an <t>While EAT does not specify how the signing keys, signature process, a
d storage of the identity values should be secured against attack, nd storage of the identity values should be secured against attack,
an EAT implementation may have equal defenses 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 impleme ntation can be constructed entirely in hardware. One reason EAT uses CBOR is because it is simple enough that a basic EAT impleme ntation can be constructed entirely in hardware.
This allows EAT to be implemented with the strongest defenses possible.</t> This allows EAT to be implemented with the strongest defenses possible.</t>
</section> </section>
<section anchor="an-x509-format-eat"> <section anchor="an-x509-format-eat">
<name>An X.509 Format EAT</name> <name>An X.509 Format EAT</name>
<t>It is possible to define a way to encode EAT claims in an X.509 certi ficate. <t>It is possible to define a way to encode EAT claims in an X.509 certi ficate.
For example, the EAT claims might be mapped to X.509 v3 extensions. 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 X.50 It is even possible to stuff a whole CBOR-encoded unsigned EAT token into an X.5
9 certificate.</t> 09 certificate.</t>
<t>If that X.509 certificate is an IDevID or LDevID, this becomes anothe <t>If that X.509 certificate is an IDevID or LDevID, it becomes another
r way to use EAT and DevID together.</t> way to use EAT and DevID together.</t>
<t>Note that the DevID must still be used with an authentication protoco l that has a nonce or equivalent. <t>Note that the DevID must still be used with an authentication protoco l that has a nonce or equivalent.
The EAT here is not being used as the protocol to interact with the relying part y.</t> The EAT here is not being used as the protocol to interact with the relying part y.</t>
</section> </section>
<section anchor="device-identifier-permanence"> <section anchor="device-identifier-permanence">
<name>Device Identifier Permanence</name> <name>Device Identifier Permanence</name>
<t>In terms of permanence, an IDevID is similar to a UEID in that they d o not change over the life of the device. <t>In terms of permanence, an IDevID is similar to a UEID in that they d o not change over the life of the device.
They cease to exist only when the device is destroyed.</t> They cease to exist only when the device is destroyed.</t>
<t>An SUEID is similar to an LDevID. <t>An SUEID is similar to an LDevID.
They change on device life-cycle events.</t> They change on device life-cycle events.</t>
<t><xref target="IEEE.802.1AR"/> describes much of this permanence as re sistant to attacks that seek to change the ID. <t><xref target="IEEE.802.1AR"/> describes much of this permanence as re sistant 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> 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 o <t>EAT is not defined around a particular implementation and must work on a rang
n a range of devices that have a range of defenses against attack. e 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.
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 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> EAT's definition of permanence is in terms of operations and device life cycle.< /t>
</section> </section>
</section> </section>
<section anchor="CDDL_for_CWT"> <section anchor="CDDL_for_CWT">
<name>CDDL for CWT and JWT</name> <name>CDDL for CWT and JWT</name>
<t><xref target="RFC8392"/> was published before CDDL was available and th us is specified in prose, not CDDL. <t><xref target="RFC8392"/> was published before CDDL was available and th us is specified in prose, not CDDL.
Following is CDDL specifying CWT as it is needed to complete this specification. In the following example, CDDL specifies CWT as it is needed to complete this sp ecification.
This CDDL also covers the Claims-Set for JWT.</t> This CDDL also covers the Claims-Set for JWT.</t>
<t>Note that <xref target="iat-claim"/> requires that the iat claim be the type ~time-int (<xref target="common-types"/>), not the type ~time when it is u sed in an EAT as floating-point values are not allowed for the "iat" claim in EA T.</t> <t>Note that <xref target="iat-claim"/> requires that the "iat" claim be t he 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="RFC905 2"/>.</t> <t>The COSE-related types in this CDDL are defined in <xref target="RFC905 2"/>.</t>
<t>This however is NOT a normative or standard definition of CWT or JWT in <t>This, however, is NOT a normative or standard definition of CWT or JWT
CDDL. in CDDL.
The prose in CWT and JWT remain the normative definition.</t> The prose in CWT and JWT remains the normative definition.</t>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
; This is replicated from draft-ietf-rats-uccs ; This is replicated from draft-ietf-rats-uccs.
Claims-Set = { Claims-Set = {
* $$Claims-Set-Claims * $$Claims-Set-Claims
* Claim-Label .feature "extended-claims-label" => any * Claim-Label .feature "extended-claims-label" => any
} }
Claim-Label = int / text Claim-Label = int / text
string-or-uri = text string-or-uri = text
$$Claims-Set-Claims //= ( iss-claim-label => string-or-uri ) $$Claims-Set-Claims //= ( iss-claim-label => string-or-uri )
$$Claims-Set-Claims //= ( sub-claim-label => string-or-uri ) $$Claims-Set-Claims //= ( sub-claim-label => string-or-uri )
skipping to change at line 3766 skipping to change at line 4288
cti-claim-label = CBOR-ONLY<7> ; jti in JWT: different name and text cti-claim-label = CBOR-ONLY<7> ; jti in JWT: different name and text
JSON-ONLY<J> = J .feature "json" JSON-ONLY<J> = J .feature "json"
CBOR-ONLY<C> = C .feature "cbor" CBOR-ONLY<C> = C .feature "cbor"
JC<J,C> = JSON-ONLY<J> / CBOR-ONLY<C> JC<J,C> = JSON-ONLY<J> / CBOR-ONLY<C>
; Same as JC<> but with unwound generic nesting as it seems to cause ; Same as JC<> but with unwound generic nesting as it seems to cause
; problems. Perhaps this is the nesting problem described in RFC ; problems. Perhaps this is the nesting problem described in RFC
; 8610. ; 8610.
JC-NEST-SAFE<J,C> = J .feature "json" / C .feature "cbor" JC-NEST-SAFE<J,C> = J .feature "json" / C .feature "cbor"]]></sourcecode>
]]></sourcecode>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
; A JWT message is either a JWS or JWE in compact serialization form ; A JWT message is either a JSON Web Signature (JWS) or a JSON Web
; with the payload a Claims-Set. Compact serialization is the ; Encryption (JWE) in compact serialization form with the payload
; protected headers, payload and signature, each b64url encoded and ; as a Claims-Set. Compact serialization is the protected headers,
; separated by a ".". This CDDL simply matches top-level syntax of of ; payload, and signature that are each b64url-encoded and separated
; a JWS or JWE since it is not possible to do more in CDDL. ; by a ".". This CDDL simply matches the top-level syntax of a JWS
; or JWE as it is not possible to do more in CDDL.
JWT-Message = JWT-Message =
text .regexp "[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+" 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 ; Note that the payload of a JWT is defined in claims-set.cddl. That
; definition is common to CBOR and JSON. ; definition is common to CBOR and JSON.]]></sourcecode>
]]></sourcecode>
<sourcecode type="CDDL"><![CDATA[ <sourcecode type="CDDL"><![CDATA[
; This is some CDDL describing a CWT at the top level This is ; This is some CDDL describing a CWT at the top level. This is
; not normative. RFC 8392 is the normative definition of CWT. ; not normative. RFC 8392 is the normative definition of CWT.
CWT-Messages = CWT-Tagged-Message / CWT-Untagged-Message CWT-Messages = CWT-Tagged-Message / CWT-Untagged-Message
; The payload of the COSE_Message is always a Claims-Set ; The payload of the COSE_Message is always a Claims-Set.
; The contents of a CWT Tag must always be a COSE tag ; The contents of a CWT tag must always be a COSE tag.
CWT-Tagged-Message = #6.61(COSE_Tagged_Message) CWT-Tagged-Message = #6.61(COSE_Tagged_Message)
; An untagged CWT may be a COSE tag or not ; An untagged CWT may be a COSE tag or not.
CWT-Untagged-Message = COSE_Messages CWT-Untagged-Message = COSE_Messages]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="Claim_Characteristics"> <section anchor="Claim_Characteristics">
<name>New Claim Design Considerations</name> <name>New Claim Design Considerations</name>
<t>The following are design considerations that may be helpful to take int <t>The following are design considerations that may be helpful to take int
o account when creating new EAT claims. o account when creating new EAT claims. This is the product of discussion in the
It is the product of discussion in the working group.</t> RAT Working Group.</t>
<t>EAT reuses the CWT and JWT claims registries. <t>EAT reuses the CWT and JWT claims registries.
There is no registry exclusively for EAT claims. There is no registry exclusively for EAT claims.
This is not an update to the expert review criteria for the JWT and CWT claims r egistries as that would be an overreach for this document.</t> This is not an update to the expert review criteria for the JWT and CWT claims r egistries as that would be an overreach for this document.</t>
<section anchor="interoperability-and-relying-party-orientation"> <section anchor="interoperability-and-relying-party-orientation">
<name>Interoperability and Relying Party Orientation</name> <name>Interoperability and Relying Party Orientation</name>
<t>It is a broad goal that EATs can be processed by relying parties in a <t>It is a broad goal that EATs can be processed by relying parties in a
general way regardless of the type, manufacturer or technology of the device fr general way regardless of the type, manufacturer, or technology of the device f
om which they originate. rom which they originate. It is a goal that there be general-purpose verificatio
It is a goal that there be general-purpose verification implementations that can n implementations that can verify tokens for large numbers of use cases with spe
verify tokens for large numbers of use cases with special cases and configurati cial cases and configurations for different device types. This is a goal of inte
ons for different device types. roperability of the semantics of claims themselves, not just of the signing, enc
This is a goal of interoperability of the semantics of claims themselves, not ju oding, and serialization formats.</t>
st of the signing, encoding and serialization formats.</t> <t>This is a lofty goal and difficult to achieve broadly as it requires
<t>This is a lofty goal and difficult to achieve broadly requiring caref careful definition of claims in a technology-neutral way.
ul definition of claims in a technology-neutral way.
Sometimes it will be difficult to design a claim that can represent the semantic s of data from very different device types. Sometimes it will be difficult to design a claim that can represent the semantic s of data from very different device types.
However, the goal remains even when difficult.</t> However, the goal remains even when difficult.</t>
</section> </section>
<section anchor="operating-system-and-technology-neutral"> <section anchor="operating-system-and-technology-neutral">
<name>Operating System and Technology Neutral</name> <name>Operating System and Technology Neutral</name>
<t>Claims should be defined such that they are not specific to an operat ing system. <t>Claims should be defined such that they are not specific to an operat ing system.
They should be applicable to multiple large high-level operating systems from di They should be applicable to multiple large high-level operating systems from di
fferent vendors. fferent vendors as well as
They should also be applicable to multiple small embedded operating systems from to multiple small embedded operating systems from multiple vendors and everythi
multiple vendors and everything in between.</t> ng in between.</t>
<t>Claims should not be defined such that they are specific to a softwar e environment or programming language.</t> <t>Claims should not be defined such that they are specific to a softwar e environment or programming language.</t>
<t>Claims should not be defined such that they are specific to a chip or particular hardware. <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 c hip of a different manufacturer.</t> 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 c hip 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> <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>
<section anchor="security-level-neutral"> <section anchor="security-level-neutral">
<name>Security Level Neutral</name> <name>Security Level Neutral</name>
<t>Many use cases will have EATs generated by some of the most secure ha <t>Many use cases will have EATs generated by some of the most secure ha
rdware and software that exists. rdware and software that exists. Secure Elements and smart cards are examples of
Secure Elements and smart cards are examples of this. 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-secu rity use case. However, EAT is intended for use in low-security use cases the same as high-secu rity use case.
For example, an app on a mobile device may generate EATs on its own.</t> For example, an app on a mobile device may generate EATs on its own.</t>
<t>Claims should be defined and registered on the basis of whether they <t>Claims should be defined and registered based on whether they are use
are useful and interoperable, not based on security level. ful and interoperable, not based on security level.
In particular, there should be no exclusion of claims because they are just used In particular, there should be no exclusion of claims because they are only used
only in low-security environments.</t> in low-security environments.</t>
</section> </section>
<section anchor="reuse-of-extant-data-formats"> <section anchor="reuse-of-extant-data-formats">
<name>Reuse of Extant Data Formats</name> <name>Reuse of Extant Data Formats</name>
<t>Where possible, claims should use already standardized data items, id <t>Where possible, claims should use data items, identifiers, and format
entifiers and formats. s that are already standardized. This takes advantage of the expertise put into
This takes advantage of the expertise put into creating those formats and improv creating those formats and improves interoperability.</t>
es interoperability.</t> <t>Often, extant claims will not be defined in an encoding or serializat
<t>Often extant claims will not be defined in an encoding or serializati ion format used by EAT.
on format used by EAT.
It is preferred to define a CBOR and JSON encoding for them so that EAT implemen tations do not require a plethora of encoders and decoders for serialization for mats.</t> It is preferred to define a CBOR and JSON encoding for them so that EAT implemen tations do not require a plethora of encoders and decoders for serialization for mats.</t>
<t>In some cases, it may be better to use the encoding and serialization as is. <t>In some cases, it may be better to use the encoding and serialization as is.
For example, signed X.509 certificates and CRLs can be carried as-is in a byte s tring. For example, signed X.509 certificates and Certificate Revocation Lists (CRLs) c an be carried as is in a byte string.
This retains interoperability with the extensive infrastructure for creating and processing X.509 certificates and CRLs.</t> This retains interoperability with the extensive infrastructure for creating and processing X.509 certificates and CRLs.</t>
</section> </section>
<section anchor="proprietary-claims"> <section anchor="proprietary-claims">
<name>Proprietary Claims</name> <name>Proprietary Claims</name>
<t>It is not always possible or convenient to achieve the above goals, s o the definition and use of proprietary claims is an option.</t> <t>It is not always possible or convenient to achieve the above goals, s o the definition and use of proprietary claims is an option.</t>
<t>For example, a device manufacturer may generate a token with propriet ary claims intended only for verification by a service offered by that device ma nufacturer. <t>For example, a device manufacturer may generate a token with propriet ary claims intended only for verification by a service offered by that device ma nufacturer.
This is a supported use case.</t> This is a supported use case.</t>
<t>In many cases proprietary claims will be the easiest and most obvious way to proceed, however for better interoperability, use of general standardize d claims is preferred.</t> <t>In many cases, proprietary claims will be the easiest and most obviou s way to proceed; however, for better interoperability, use of general standardi zed claims is preferred.</t>
</section> </section>
</section> </section>
<section anchor="keyid"> <section anchor="keyid">
<name>Endorsements and Verification Keys</name> <name>Endorsements and Verification Keys</name>
<t>The verifier must possess the correct key when it performs the cryptogr aphic part of an EAT verification (e.g., verifying the COSE/JOSE signature). <t>The verifier must possess the correct key when it performs the cryptogr aphic part of an EAT verification (e.g., verifying the COSE/JOSE signature).
This section describes several ways to identify the verification key. This section describes several ways to identify the verification key.
There is not one standard method.</t> There is not one standard method.</t>
<t>The verification key itself may be a public key, a symmetric key or som ething complicated in the case of a scheme like Direct Anonymous Attestation (DA A).</t> <t>The verification key itself may be a public key, a symmetric key, or so mething complicated in the case of a scheme such as Direct Anonymous Attestation (DAA).</t>
<t>RATS Architecture <xref target="RFC9334"/> describes what is called an endorsement. <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 i n an EAT and the attester that generated it. This is an input to the verifier that is usually the basis of the trust placed i n an EAT and the attester that generated it.
It may contain the public key for verification of the signature on the EAT. It may contain the public key for verification of the signature on the EAT, and
It may contain implied claims, those that are passed on to the relying party in it may contain implied claims, i.e., those that are passed on to the relying par
attestation results.</t> ty in attestation results.</t>
<t>There is not yet any standard format(s) for an endorsement. <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. One format that may be used for an endorsement is an X.509 certificate.
Endorsement data like reference values and implied claims can be carried in X.50 9 v3 extensions. Endorsement data 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 ke y, so identification of the endorsement is also identification of the verificati on key.</t> In this use, the public key in the X.509 certificate becomes the verification ke y, so identification of the endorsement is also identification of the verificati on key.</t>
<t>The verification key identification and establishment of trust in the E AT and the attester may also be by some other means than an endorsement.</t> <t>The verification key identification and establishment of trust in the E AT and the attester may also be by some other means than an endorsement.</t>
<t>For the components (attester, verifier, relying party,...) of a particu <t>For the components (attester, verifier, relying party, etc.) of a parti
lar end-to-end attestation system to reliably interoperate, its definition shoul cular end-to-end attestation system to reliably interoperate, its definition sho
d specify how the verification key is identified. uld specify how the verification key is identified.
Usually, this will be in the profile document for a particular attestation syste Usually, this will be in the profile document for a particular attestation
m.</t> system.</t>
<t>See also security consideration in <xref target="verfication-key-sc"/>.
</t> <t>See also the security considerations in <xref target="verfication-key-s
c"/>.</t>
<section anchor="identification-methods"> <section anchor="identification-methods">
<name>Identification Methods</name> <name>Identification Methods</name>
<t>Following is a list of possible methods of key identification. A spec ific attestation system may employ any one of these or one not listed here.</t> <t>Following is a list of possible methods of key identification. A spec ific attestation system may employ any one of these or one not listed here.</t>
<t>The following assumes endorsements are X.509 certificates or equivale nt 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> <t>The following assumes endorsements are X.509 certificates or equivale nt 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"> <section anchor="cosejws-key-id">
<name>COSE/JWS Key ID</name> <name>COSE/JWS Key ID</name>
<t>The COSE standard header parameter for Key ID (kid) may be used. Se e <xref target="RFC9052"/> and <xref target="RFC7515"/></t> <t>The COSE standard header parameter for Key ID (kid) may be used; se e <xref target="RFC9052"/> and <xref target="RFC7515"/>.</t>
<t>COSE leaves the semantics of the key ID open-ended. <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 or other. 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, or other.
The profile document should specify what the key ID's semantics are.</t> The profile document should specify what the key ID's semantics are.</t>
</section> </section>
<section anchor="jws-and-cose-x509-header-parameters"> <section anchor="jws-and-cose-x509-header-parameters">
<name>JWS and COSE X.509 Header Parameters</name> <name>JWS and COSE X.509 Header Parameters</name>
<t>COSE X.509 <xref target="RFC9360"/> and JSON Web Signature <xref ta <t>COSE X.509 <xref target="RFC9360"/> and JSON Web Signature <xref ta
rget="RFC7515"/> define several header parameters (x5t, x5u,...) for referencing rget="RFC7515"/> define several header parameters (x5t, x5u,...) for referencing
or carrying X.509 certificates any of which may be used.</t> or carrying X.509 certificates, any of which may be used.</t>
<t>The X.509 certificate may be an endorsement and thus carrying addit <t>The X.509 certificate may be an endorsement and thus carrying addit
ional input to the verifier. It may be just an X.509 certificate, not an endorse ional input to the verifier. It may be just an X.509 certificate, not an endorse
ment. The same header parameters are used in both cases. It is up to the attesta ment. The same header parameters are used in both cases, and it is up to the att
tion system design and the verifier to determine which.</t> estation system design and the verifier to determine which.</t>
</section> </section>
<section anchor="cbor-certificate-cose-header-parameters"> <section anchor="cbor-certificate-cose-header-parameters">
<name>CBOR Certificate COSE Header Parameters</name> <name>CBOR Certificate COSE Header Parameters</name>
<t>Compressed X.509 and CBOR Native certificates are defined by CBOR C ertificates <xref target="I-D.ietf-cose-cbor-encoded-cert"/>. These are semantic ally compatible with X.509 and therefore can be used as an equivalent to X.509 a s described above.</t> <t>Compressed X.509 and CBOR Native certificates are defined by CBOR C ertificates <xref target="I-D.ietf-cose-cbor-encoded-cert"/>. These are semantic ally compatible with X.509 and therefore can be used as an equivalent to X.509 a s described above.</t>
<t>These are identified by their own header parameters (c5t, c5u,...). </t> <t>These are identified by their own header parameters (c5t, c5u, etc. ).</t>
</section> </section>
<section anchor="claim-based-key-identification"> <section anchor="claim-based-key-identification">
<name>Claim-Based Key Identification</name> <name>Claim-Based Key Identification</name>
<t>For some attestation systems, a claim may be re-used as a key ident <t>For some attestation systems, a claim may be reused as a key identi
ifier. For example, the UEID uniquely identifies the entity and therefore can wo fier. For example, the UEID uniquely identifies the entity and therefore can wor
rk well as a key identifier or endorsement identifier.</t> k well as a key identifier or endorsement identifier.</t>
<t>This has the advantage that key identification requires no addition <t>An advantage of this is that key identification requires no additio
al bytes in the EAT and makes the EAT smaller.</t> nal bytes in the EAT and makes the EAT smaller.</t>
<t>This has the disadvantage that the unverified EAT must be substanti <t>A disadvantage of this is that the unverified EAT must be substanti
ally decoded to obtain the identifier since the identifier is in the COSE/JOSE p ally decoded to obtain the identifier since the identifier is in the COSE/JOSE p
ayload, not in the headers.</t> ayload, not in the headers.</t>
</section> </section>
</section> </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 rec
ord 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="f alse"> <section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse">
<name>Contributors</name> <name>Contributors</name>
<t>Many thanks to the following contributors to draft versions of this <t>Many thanks to the following for their contributions to earlier draft v ersions of this
document:</t> document:</t>
<contact initials="H." surname="Birkholz" fullname="Henk Birkholz"> <contact initials="H." surname="Birkholz" fullname="Henk Birkholz">
<organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization> <organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
<address> <address>
<email>henk.birkholz@sit.fraunhofer.de</email> <email>henk.birkholz@sit.fraunhofer.de</email>
</address> </address>
</contact> </contact>
<contact initials="T." surname="Fossati" fullname="Thomas Fossati"> <contact initials="T." surname="Fossati" fullname="Thomas Fossati">
<organization>Arm Limited</organization> <organization>Arm Limited</organization>
<address> <address>
skipping to change at line 3962 skipping to change at line 4479
<email>hannes.tschofenig@arm.com</email> <email>hannes.tschofenig@arm.com</email>
</address> </address>
</contact> </contact>
<contact initials="P." surname="Crowley" fullname="Paul Crowley"> <contact initials="P." surname="Crowley" fullname="Paul Crowley">
<organization/> <organization/>
<address> <address>
</address> </address>
</contact> </contact>
</section> </section>
</back> </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> </rfc>
 End of changes. 494 change blocks. 
2866 lines changed or deleted 2420 lines changed or added

This html diff was produced by rfcdiff 1.48.