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

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.2.2) -->
<?rfc rfcedstyle="yes"?>
<?rfc tocindent="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc text-list-symbols="-o*+"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-tschofenig-rats-psa-token-24" number="9783" category="info" submissionType="independent" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.23.1 --> version="3" xml:lang="en" updates="" obsoletes="">

  <front>
    <title abbrev="PSA abbrev="Arm's PSA Attestation Token">Arm's Platform Security Architecture (PSA) Attestation Token</title>
    <seriesInfo name="Internet-Draft" value="draft-tschofenig-rats-psa-token-24"/> name="RFC" value="9783"/>
    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization/>
      <address>
        <email>Hannes.Tschofenig@gmx.net</email>
      </address>
    </author>
    <author initials="S." surname="Frost" fullname="Simon Frost">
      <organization>Arm Limited</organization>
      <address>
        <email>Simon.Frost@arm.com</email>
      </address>
    </author>
    <author initials="M." surname="Brossard" fullname="Mathias Brossard">
      <organization>Arm Limited</organization>
      <address>
        <email>Mathias.Brossard@arm.com</email>
      </address>
    </author>
    <author initials="A." surname="Shaw" fullname="Adrian Shaw">
      <organization>HP Labs</organization>
      <address>
        <email>adrianlshaw@acm.org</email>
      </address>
    </author>
    <author initials="T." surname="Fossati" fullname="Thomas Fossati">
      <organization>Linaro</organization>
      <address>
        <email>thomas.fossati@linaro.org</email>
      </address>
    </author>
    <date year="2024" month="September" day="23"/>
    <area/>
    <workgroup/>
    <keyword>Internet-Draft</keyword> year="2025" month="May"/>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <?line 162?>
<!-- [rfced] The sentence below seems to be missing a verb (such as designed,
used, etc.). May we rephrase the sentence as follows to improve
readability?

Original:
   The Arm Platform Security Architecture (PSA) is a family of hardware
   and firmware security specifications, as well as open-source
   reference implementations, to help device makers and chip
   manufacturers build best-practice security into products.

Perhaps:
   The Arm Platform Security Architecture (PSA) is a family of hardware
   and firmware security specifications, as well as open-source
   reference implementations, that is designed to help device makers and chip
   manufacturers build best-practice security into products.
-->
<t>The Arm Platform Security Architecture (PSA) is a family of hardware and firmware
security specifications, as well as open-source reference implementations, to
help device makers and chip manufacturers build best-practice security into
products.
Devices that are PSA compliant PSA-compliant can produce attestation tokens
as described in this memo, which memo. Attestation tokens are the basis for many different
protocols, including secure provisioning and network access control.  This
document specifies the PSA attestation token structure and semantics.</t>
      <t>The PSA attestation token is a profile of the Entity Attestation Token (EAT).
This specification describes what claims are used in an attestation token
generated by PSA compliant systems, how these claims get serialized to the
wire, and how they are cryptographically protected.</t>
      <t>This informational Informational document is published as an independent submission Independent Submission to improve
interoperability with Arm's architecture. It is not a standard nor
a product of the IETF.</t>
    </abstract>
  </front>
  <middle>
    <?line 181?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The Platform Security Architecture (PSA) <xref target="PSA"/> is a set of hardware and firmware
specifications,
specifications backed by reference implementations and a security
certification program <xref target="PSACertified"/>.  The security specifications have been published by Arm,
while the certification program and reference implementations are the result of
a collaborative effort by companies from multiple sectors, including evaluation
laboratories, IP semiconductor vendors vendors, and security consultancies.  The main objective of
the PSA initiative is to assist device manufacturers and chip makers in
incorporating best-practice security measures into their products.</t>
      <t>Many devices now have trusted execution environments Trusted Execution Environments (TEEs) that provide a safe
space for security-sensitive code, such as cryptography, secure boot, secure
storage, and other essential security functions.  These security
functions are typically exposed through a narrow and well-defined interface,
and can be used by operating system libraries and applications.</t>
      <t>As outlined in the RATS Remote ATtestation procedureS (RATS) Architecture
      <xref target="RFC9334"/>, an Attester produces a signed collection of
      Claims that constitutes Evidence about its target environment. Target Environment. This
      document focuses on the output provided by PSA's Initial Attestation API
      <xref target="PSA-API"/>. This output corresponds to Evidence in <xref
      target="RFC9334"/> and, as a design decision, the PSA attestation token
      is a profile of the Entity Attestation Token (EAT) <xref target="EAT"/>.
      target="RFC9711"/>. Note that there are other profiles of EAT available, such as <xref target="I-D.kdyxy-rats-tdx-eat-profile"/> and <xref target="I-D.mandyam-rats-qwestoken"/>, available
      for use with different use cases and by different attestation technologies.</t>
      technologies, such as <xref target="I-D.kdyxy-rats-tdx-eat-profile"/>
      and <xref target="I-D.mandyam-rats-qwestoken"/>.</t>
      <t>Since the PSA tokens are also consumed by services outside the device, there is an actual
need to ensure interoperability. Interoperability needs are addressed here by
describing the exact syntax and semantics of the attestation claims, and
defining the way these claims are encoded and cryptographically protected.</t>
      <t>Further details on concepts expressed below can be found in the PSA Security
Model documentation <xref target="PSA-SM"/>.</t>
      <t>As mentioned in the abstract, this memo documents a vendor extension
to the RATS architecture, architecture and is not a standard.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
<?line -6?>
        </t>

      <t>The terms Attester, Relying Party, Verifier, Attestation Result, Target Environment, Attesting Environment Environment, and Evidence
are defined in <xref target="RFC9334"/>. We use the term "receiver" to refer to Relying Parties
and Verifiers.</t>
      <t>We use the terms Evidence, "PSA attestation token", and "PSA token" interchangeably.
The terms "sender" and Attester are used interchangeably. Likewise, we use the terms
Verifier and "verification service" interchangeably.</t>
      <dl newline="true">
        <dt>RoT:</dt>
        <dd>
          <t>Root
        <dt>Root of Trust, the Trust (RoT):</dt>
        <dd>The minimal set of software, hardware hardware, and data that has to be
        implicitly trusted in the platform - platform; there is no software or hardware
        at a deeper level that can verify that the Root of Trust RoT is authentic and
        unmodified.  An example of RoT is an initial bootloader in ROM, which
        contains cryptographic functions and credentials, running on a
        specific hardware
platform.</t>
        </dd>
        <dt>SPE:</dt>
        <dd>
          <t>Secure platform.</dd>
        <dt>Secure Processing Environment, a Environment (SPE):</dt>
        <dd>A platform's processing environment for software that provides
        confidentiality and integrity for its runtime state, from software and
        hardware, outside of the SPE. Contains trusted code and trusted
        hardware.  (Equivalent to Trusted Execution Environment (TEE), a TEE, "secure world", or "secure enclave".)</t>
        </dd>
        <dt>NSPE:</dt>
        <dd>
          <t>Non
        enclave".)</dd>
        <dt>Non-Secure Processing Environment (NSPE):</dt>
<!-- [rfced] Is the Application domain specified as the security domain
outside the SPE in the definition for NSPE? Please clarify.

Original:
NSPE:
   Non Secure Processing Environment, the security domain outside of
   the SPE, the Application domain, typically containing the
   application firmware, real-time operating systems, applications
   and general hardware.

Perhaps:
Non-Secure Processing Environment (NSPE):
   The security domain (Application domain) outside of the SPE that
   typically contains the application firmware, real-time operating
   systems, applications, and general hardware.
-->
        <dd>The security domain outside of
        the SPE, the Application domain, typically containing the application
        firmware, real-time operating systems, applications, and general
        hardware.  (Equivalent to Rich Execution Environment (REE), or "normal world".)</t>
        </dd>
        world".)</dd>
      </dl>
      <t>In this document, the structure of data is specified in Concise Data Definition Language (CDDL) <xref target="RFC8610"/>.</t>
    </section>
    <section anchor="sec-psa-attester-model">
      <name>PSA Attester Model</name>
      <t><xref target="fig-psa-attester"/> outlines the structure of the PSA Attester according to
the conceptual model described in <xref section="3.1" sectionFormat="of" target="RFC9334"/>.</t>
      <figure anchor="fig-psa-attester">
        <name>PSA Attester</name>
        <artset>
          <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="496" width="560" viewBox="0 0 560 496" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
              <path d="M 8,144 L 8,432" fill="none" stroke="black"/>
              <path d="M 24,160 L 24,272" fill="none" stroke="black"/>
              <path d="M 24,304 L 24,416" fill="none" stroke="black"/>
              <path d="M 40,336 L 40,384" fill="none" stroke="black"/>
              <path d="M 96,304 L 96,336" fill="none" stroke="black"/>
              <path d="M 144,336 L 144,384" fill="none" stroke="black"/>
              <path d="M 160,192 L 160,256" fill="none" stroke="black"/>
              <path d="M 160,336 L 160,384" fill="none" stroke="black"/>
              <path d="M 208,256 L 208,336" fill="none" stroke="black"/>
              <path d="M 264,192 L 264,256" fill="none" stroke="black"/>
              <path d="M 272,336 L 272,384" fill="none" stroke="black"/>
              <path d="M 288,336 L 288,384" fill="none" stroke="black"/>
              <path d="M 304,208 L 304,240" fill="none" stroke="black"/>
              <path d="M 328,288 L 328,336" fill="none" stroke="black"/>
              <path d="M 368,208 L 368,240" fill="none" stroke="black"/>
              <path d="M 400,336 L 400,384" fill="none" stroke="black"/>
              <path d="M 408,192 L 408,256" fill="none" stroke="black"/>
              <path d="M 416,336 L 416,384" fill="none" stroke="black"/>
              <path d="M 424,32 L 424,64" fill="none" stroke="black"/>
              <path d="M 464,72 L 464,192" fill="none" stroke="black"/>
              <path d="M 464,304 L 464,336" fill="none" stroke="black"/>
              <path d="M 512,32 L 512,64" fill="none" stroke="black"/>
              <path d="M 520,192 L 520,256" fill="none" stroke="black"/>
              <path d="M 520,336 L 520,384" fill="none" stroke="black"/>
              <path d="M 536,160 L 536,272" fill="none" stroke="black"/>
              <path d="M 536,304 L 536,416" fill="none" stroke="black"/>
              <path d="M 552,144 L 552,432" fill="none" stroke="black"/>
              <path d="M 424,32 L 512,32" fill="none" stroke="black"/>
              <path d="M 424,64 L 512,64" fill="none" stroke="black"/>
              <path d="M 8,144 L 456,144" fill="none" stroke="black"/>
              <path d="M 472,144 L 552,144" fill="none" stroke="black"/>
              <path d="M 24,160 L 456,160" fill="none" stroke="black"/>
              <path d="M 472,160 L 536,160" fill="none" stroke="black"/>
              <path d="M 160,192 L 264,192" fill="none" stroke="black"/>
              <path d="M 320,192 L 352,192" fill="none" stroke="black"/>
              <path d="M 408,192 L 520,192" fill="none" stroke="black"/>
              <path d="M 264,224 L 296,224" fill="none" stroke="black"/>
              <path d="M 376,224 L 408,224" fill="none" stroke="black"/>
              <path d="M 160,256 L 264,256" fill="none" stroke="black"/>
              <path d="M 320,256 L 352,256" fill="none" stroke="black"/>
              <path d="M 408,256 L 520,256" fill="none" stroke="black"/>
              <path d="M 24,272 L 200,272" fill="none" stroke="black"/>
              <path d="M 216,272 L 536,272" fill="none" stroke="black"/>
              <path d="M 112,288 L 448,288" fill="none" stroke="black"/>
              <path d="M 24,304 L 88,304" fill="none" stroke="black"/>
              <path d="M 104,304 L 200,304" fill="none" stroke="black"/>
              <path d="M 216,304 L 320,304" fill="none" stroke="black"/>
              <path d="M 336,304 L 456,304" fill="none" stroke="black"/>
              <path d="M 472,304 L 536,304" fill="none" stroke="black"/>
              <path d="M 40,336 L 88,336" fill="none" stroke="black"/>
              <path d="M 104,336 L 144,336" fill="none" stroke="black"/>
              <path d="M 160,336 L 200,336" fill="none" stroke="black"/>
              <path d="M 216,336 L 272,336" fill="none" stroke="black"/>
              <path d="M 288,336 L 320,336" fill="none" stroke="black"/>
              <path d="M 336,336 L 400,336" fill="none" stroke="black"/>
              <path d="M 416,336 L 456,336" fill="none" stroke="black"/>
              <path d="M 472,336 L 520,336" fill="none" stroke="black"/>
              <path d="M 40,384 L 144,384" fill="none" stroke="black"/>
              <path d="M 160,384 L 272,384" fill="none" stroke="black"/>
              <path d="M 288,384 L 400,384" fill="none" stroke="black"/>
              <path d="M 416,384 L 520,384" fill="none" stroke="black"/>
              <path d="M 24,416 L 536,416" fill="none" stroke="black"/>
              <path d="M 8,432 L 552,432" fill="none" stroke="black"/>
              <path d="M 112,464 L 136,464" fill="none" stroke="black"/>
              <path d="M 216,464 L 240,464" fill="none" stroke="black"/>
              <path d="M 328,464 L 344,464" fill="none" stroke="black"/>
              <path d="M 320,192 C 311.16936,192 304,199.16936 304,208" fill="none" stroke="black"/>
              <path d="M 352,192 C 360.83064,192 368,199.16936 368,208" fill="none" stroke="black"/>
              <path d="M 320,256 C 311.16936,256 304,248.83064 304,240" fill="none" stroke="black"/>
              <path d="M 352,256 C 360.83064,256 368,248.83064 368,240" fill="none" stroke="black"/>
              <path d="M 112,288 C 103.16936,288 96,295.16936 96,304" fill="none" stroke="black"/>
              <path d="M 448,288 C 456.83064,288 464,295.16936 464,304" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="472,72 460,66.4 460,77.6" fill="black" transform="rotate(270,464,72)"/>
              <polygon class="arrowhead" points="384,224 372,218.4 372,229.6" fill="black" transform="rotate(180,376,224)"/>
              <polygon class="arrowhead" points="304,224 292,218.4 292,229.6" fill="black" transform="rotate(0,296,224)"/>
              <polygon class="arrowhead" points="248,464 236,458.4 236,469.6" fill="black" transform="rotate(0,240,464)"/>
              <polygon class="arrowhead" points="144,464 132,458.4 132,469.6" fill="black" transform="rotate(0,136,464)"/>
              <circle cx="96" cy="336" r="6" class="opendot" fill="white" stroke="black"/>
              <circle cx="208" cy="336" r="6" class="opendot" fill="white" stroke="black"/>
              <circle cx="328" cy="336" r="6" class="opendot" fill="white" stroke="black"/>
              <circle cx="352" cy="464" r="6" class="opendot" fill="white" stroke="black"/>
              <circle cx="464" cy="336" r="6" class="opendot" fill="white" stroke="black"/>
              <g class="text">
                <text x="468" y="52">Verifier</text>
                <text x="392" y="116">PSA</text>
                <text x="432" y="116">Token</text>
                <text x="72" y="180">Attesting</text>
                <text x="160" y="180">Environment</text>
                <text x="188" y="212">Main</text>
                <text x="332" y="212">Main</text>
                <text x="448" y="212">Initial</text>
                <text x="212" y="228">Bootloader</text>
                <text x="332" y="228">Boot</text>
                <text x="464" y="228">Attestation</text>
                <text x="280" y="244">W</text>
                <text x="336" y="244">State</text>
                <text x="392" y="244">R</text>
                <text x="448" y="244">Service</text>
                <text x="92" y="356">Updateable</text>
                <text x="216" y="356">Application</text>
                <text x="344" y="356">Application</text>
                <text x="440" y="356">PSA</text>
                <text x="472" y="356">RoT</text>
                <text x="64" y="372">PSA</text>
                <text x="96" y="372">RoT</text>
                <text x="184" y="372">RoT</text>
                <text x="324" y="372">Loader</text>
                <text x="468" y="372">Parameters</text>
                <text x="60" y="404">Target</text>
                <text x="136" y="404">Environment</text>
                <text x="32" y="452">Legend:</text>
                <text x="164" y="468">read</text>
                <text x="272" y="468">write</text>
                <text x="392" y="468">measure</text>
                <text x="120" y="484">R</text>
                <text x="224" y="484">W</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art"><![CDATA[
                                                    .----------.
                                                    | Verifier |
                                                    '----------'
                                                         ^
                                                         |
                                               PSA Token |
                                                         |
.--------------------------------------------------------|----------.
| .------------------------------------------------------|--------. |
| | Attesting Environment                                |        | |
| |                .------------.     .-----.     .------+------. | |
| |                | Main       |    | Main  |    | Initial     | | |
| |                | Bootloader +--->| Boot  |<---+ Attestation | | |
| |                |            | W  | State |  R | Service     | | |
| |                '-----+------'     '-----'     '-------------' | |
| '----------------------|----------------------------------------' |
|           .------------+--------------+---------------.           |
| .--------|-------------|--------------|----------------|--------. |
| |        |             |              |                |        | |
| | .------o-----. .-----o-------. .----o--------. .-----o------. | |
| | | Updateable | | Application | | Application | | PSA RoT    | | |
| | | PSA RoT    | | RoT         | | Loader      | | Parameters | | |
| | '------------' '-------------' '-------------' '------------' | |
| | Target Environment                                            | |
| '---------------------------------------------------------------' |
'-------------------------------------------------------------------'
Legend:
             ---> read    ---> write    ---o measure
              R            W
]]></artwork>
        </artset>
      </figure>
      <t>The PSA Attester is a relatively straightforward embodiment of the RATS
Attester with exactly one Attesting Environment and one or more Target Environments.</t>
<!-- [rfced] Is "them" and "it" referring to "PSA claims" in this sentence?

Original:
   The Attesting Environment is responsible for collecting the
   information to be represented in PSA claims and to assemble them into
   Evidence.  It is made of two cooperating components:

Perhaps:
   The Attesting Environment is responsible for collecting the
   information to be represented in PSA claims and assembling them into
   Evidence.  PSA claims are made of two cooperating components:
-->
      <t>The Attesting Environment is responsible for collecting the information to be
represented in PSA claims and to assemble them into Evidence. It is made of two
cooperating components:</t>
      <ul spacing="normal">
        <li>
          <t>The Main Bootloader, executing
          <t>Executing at boot-time, the Main Bootloader measures the Target Environments - i.e., (i.e., loaded software
components,
components and all the relevant PSA RoT parameters -, parameters) and stores the recorded
information in secure memory (Main Boot State). See <xref target="fig-psa-attester-boot"/>.</t>
        </li>
      </ul>

      <figure anchor="fig-psa-attester-boot">
        <name>PSA Attester Boot Phase</name>
        <artset>
          <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="224" width="352" viewBox="0 0 352 224" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
              <path d="M 8,80 L 8,192" fill="none" stroke="black"/>
              <path d="M 80,64 L 80,208" fill="none" stroke="black"/>
              <path d="M 192,64 L 192,208" fill="none" stroke="black"/>
              <path d="M 304,64 L 304,208" fill="none" stroke="black"/>
              <path d="M 344,80 L 344,192" fill="none" stroke="black"/>
              <path d="M 8,80 L 72,80" fill="none" stroke="black"/>
              <path d="M 88,80 L 184,80" fill="none" stroke="black"/>
              <path d="M 200,80 L 296,80" fill="none" stroke="black"/>
              <path d="M 312,80 L 344,80" fill="none" stroke="black"/>
              <path d="M 96,128 L 192,128" fill="none" stroke="black"/>
              <path d="M 192,176 L 296,176" fill="none" stroke="black"/>
              <path d="M 8,192 L 72,192" fill="none" stroke="black"/>
              <path d="M 88,192 L 184,192" fill="none" stroke="black"/>
              <path d="M 200,192 L 296,192" fill="none" stroke="black"/>
              <path d="M 312,192 L 344,192" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="304,176 292,170.4 292,181.6" fill="black" transform="rotate(0,296,176)"/>
              <circle cx="88" cy="128" r="6" class="opendot" fill="white" stroke="black"/>
              <g class="text">
                <text x="52" y="36">i-th</text>
                <text x="100" y="36">Target</text>
                <text x="172" y="36">Main</text>
                <text x="212" y="36">Boot</text>
                <text x="284" y="36">Main</text>
                <text x="324" y="36">Boot</text>
                <text x="80" y="52">Environment</text>
                <text x="196" y="52">Loader</text>
                <text x="304" y="52">State</text>
                <text x="36" y="100">loop</text>
                <text x="64" y="100">i</text>
                <text x="120" y="116">measure</text>
                <text x="224" y="148">write</text>
                <text x="248" y="164">measurement</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art"><![CDATA[
    i-th Target    Main Boot     Main Boot
    Environment      Loader        State
         |             |             |
.--------|-------------|-------------|----.
| loop i |             |             |    |
|        | measure     |             |    |
|        |o------------+             |    |
|        |             | write       |    |
|        |             | measurement |    |
|        |             +------------>|    |
'--------|-------------|-------------|----'
         |             |             |
]]></artwork>
        </artset>
      </figure>
      <ul spacing="normal">
        <li>
          <t>The
	</li>
        <li>The Initial Attestation Service (executing at run-time in SPE)
        answers requests coming from NSPE via the PSA attestation API <xref
        target="PSA-API"/>, collects and formats the claims from Main Boot
        State, and uses the Initial Attestation Key (IAK) to sign them and
        produce Evidence. See <xref target="fig-psa-attester-runtime"/>.</t>
        </li> target="fig-psa-attester-runtime"/>.</li>
      </ul>
      <t>The word "Initial" in "Initial Attestation Service" refers to a limited set of
Target Environments, namely those representing the first, first foundational stages
establishing the chain of trust of a PSA device.
Collecting measurements from Target Environments after this initial phase is outside the scope of this specification. Extensions of this specification could collect up-to-date measurements from additional Target Environments and define additional claims for use within those environments, but these are, by definition, custom.</t>
      <figure anchor="fig-psa-attester-runtime">
        <name>PSA Attester Run-time Run-Time Phase</name>
        <artset>
          <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="304" width="360" viewBox="0 0 360 304" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
              <path d="M 8,96 L 8,192" fill="none" stroke="black"/>
              <path d="M 80,80 L 80,288" fill="none" stroke="black"/>
              <path d="M 184,208 L 184,240" fill="none" stroke="black"/>
              <path d="M 216,80 L 216,288" fill="none" stroke="black"/>
              <path d="M 312,80 L 312,288" fill="none" stroke="black"/>
              <path d="M 352,96 L 352,192" fill="none" stroke="black"/>
              <path d="M 8,96 L 72,96" fill="none" stroke="black"/>
              <path d="M 88,96 L 208,96" fill="none" stroke="black"/>
              <path d="M 224,96 L 304,96" fill="none" stroke="black"/>
              <path d="M 320,96 L 352,96" fill="none" stroke="black"/>
              <path d="M 88,176 L 216,176" fill="none" stroke="black"/>
              <path d="M 8,192 L 72,192" fill="none" stroke="black"/>
              <path d="M 88,192 L 208,192" fill="none" stroke="black"/>
              <path d="M 224,192 L 304,192" fill="none" stroke="black"/>
              <path d="M 320,192 L 352,192" fill="none" stroke="black"/>
              <path d="M 184,208 L 216,208" fill="none" stroke="black"/>
              <path d="M 184,240 L 208,240" fill="none" stroke="black"/>
              <path d="M 216,272 L 304,272" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="312,272 300,266.4 300,277.6" fill="black" transform="rotate(0,304,272)"/>
              <polygon class="arrowhead" points="216,240 204,234.4 204,245.6" fill="black" transform="rotate(0,208,240)"/>
              <polygon class="arrowhead" points="96,176 84,170.4 84,181.6" fill="black" transform="rotate(180,88,176)"/>
              <g class="text">
                <text x="216" y="36">Initial</text>
                <text x="60" y="52">Main</text>
                <text x="100" y="52">Boot</text>
                <text x="216" y="52">Attestation</text>
                <text x="80" y="68">State</text>
                <text x="216" y="68">Service</text>
                <text x="316" y="68">Verifier</text>
                <text x="36" y="116">loop</text>
                <text x="64" y="116">i</text>
                <text x="108" y="116">read</text>
                <text x="136" y="132">measurement</text>
                <text x="196" y="132">of</text>
                <text x="108" y="148">i-th</text>
                <text x="156" y="148">Target</text>
                <text x="136" y="164">Environment</text>
                <text x="156" y="228">sign</text>
                <text x="240" y="260">PSA</text>
                <text x="280" y="260">Token</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art"><![CDATA[
                       Initial
     Main Boot       Attestation
       State           Service     Verifier
         |                |           |
.--------|----------------|-----------|----.
| loop i | read           |           |    |
|        | measurement of |           |    |
|        | i-th Target    |           |    |
|        | Environment    |           |    |
|        |<---------------+           |    |
'--------|----------------|-----------|----'
         |            .---+           |
         |       sign |   |           |
         |            '-->|           |
         |                | PSA Token |
         |                +---------->|
         |                |           |
]]></artwork>
        </artset>
      </figure>
      <t>The Target Environments can be of four types, some of
which may or may not be present depending on the device architecture:</t>
      <ul spacing="normal">
        <li>
          <t>(A
        <li>(A subset of) the PSA RoT parameters, including Instance and
        Implementation
IDs.</t>
        </li>
        <li>
          <t>The IDs.</li>
        <li>The updateable PSA RoT, including the Secure Partition Manager and
        all PSA RoT services.</t>
        </li>
        <li>
          <t>The services.</li>
        <li>The (optional) Application RoT, that is any application-defined
        security
service, service possibly making use of the PSA RoT services.</t>
        </li>
        <li>
          <t>The services.</li>
        <li>The loader of the application software running in NSPE.</t>
        </li> NSPE.</li>
      </ul>
      <t>A reference implementation of the PSA Attester is provided by <xref target="TF-M"/>.</t>
    </section>
    <section anchor="sec-psa-claims">
      <name>PSA Claims</name>
      <t>This section describes the claims to be used in a PSA attestation token.
A more comprehensive treatment of the EAT profile(s) profiles defined by PSA is found in <xref target="sec-profiles"/>.</t>
      <t>CDDL <xref target="RFC8610"/> along with text descriptions is used to define each claim
independent of encoding.  The following CDDL type(s) types are reused by different
claims:</t>
      <artwork><![CDATA[
      <sourcecode type="cddl"><![CDATA[
psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64
]]></artwork> 64]]></sourcecode>

      <t>Two conventions are used to encode the Right-Hand-Side (RHS) of a claim: the claim. The postfix <tt>-label</tt> is used for EAT-defined claims, claims and the postfix <tt>-key</tt> is used for PSA-originated claims.</t>
      <section anchor="caller-claims">
        <name>Caller Claims</name>
        <section anchor="sec-nonce-claim">
          <name>Nonce</name>
          <t>The Nonce claim is used to carry the challenge provided by the caller to demonstrate freshness of the generated token.</t>
          <t>The EAT <xref target="EAT"/> target="RFC9711"/> <tt>nonce</tt> (claim key 10) is used.  Since the EAT nonce claim offers flexiblity for different
attestation technologies, this specifications specification applies the following constraints
 to the <tt>nonce-type</tt>:</t>
          <ul spacing="normal">
            <li>
              <t>The
            <li>The length MUST <bcp14>MUST</bcp14> be either 32, 48, or 64 bytes.</t>
            </li>
            <li>
              <t>Only bytes.</li>
            <li>Only a single nonce value is conveyed. The array notation MUST NOT
            <bcp14>MUST NOT</bcp14> be used for encoding the nonce value.</t>
            </li> value.</li>
          </ul>
          <t>This claim MUST <bcp14>MUST</bcp14> be present in a PSA attestation token.</t>

          <artwork><![CDATA[
psa-nonce = (
    nonce-label => psa-hash-type
)
]]></artwork>
)]]></artwork>

        </section>
        <section anchor="sec-client-id">
          <name>Client ID</name>
          <t>The Client ID claim represents the security domain of the caller.</t>
          <t>In PSA, a security domain is represented by a signed
integer whereby negative values represent callers from the NSPE and where
positive IDs represent callers from the SPE. The value 0 is not permitted.</t>
          <t>For an example definition of client IDs, see the PSA Firmware Framework <xref Framework <xref target="PSA-FF"/>.</t>
          <t>It is essential that this claim is checked in the verification process to
ensure that a security domain, i.e., an attestation endpoint, cannot spoof a
report from another security domain.</t>
          <t>This claim MUST <bcp14>MUST</bcp14> be present in a PSA attestation token.</t>

          <artwork><![CDATA[
psa-client-id-nspe-type = -2147483648...0
psa-client-id-spe-type = 1..2147483647

psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-type

psa-client-id = (
    psa-client-id-key => psa-client-id-type
)
]]></artwork>
)]]></artwork>

        </section>
      </section>
      <section anchor="target-identification-claims">
        <name>Target Identification Claims</name>
        <section anchor="sec-instance-id-claim">
          <name> Instance
          <name>Instance ID</name>
          <t>The Instance ID claim represents the unique identifier of the Initial
Attestation Key (IAK). IAK.  The full definition is in <xref target="PSA-SM"/>.</t>
          <t>The EAT <tt>ueid</tt> (claim key 256) of type RAND is used.  The following constraints
apply to the <tt>ueid-type</tt>:</t>
          <ul spacing="normal">
            <li>
              <t>The
            <li>The length MUST <bcp14>MUST</bcp14> be 33 bytes.</t>
            </li>
            <li>
              <t>The bytes.</li>
            <li>The first byte MUST <bcp14>MUST</bcp14> be 0x01 (RAND) followed by
            the 32-byte unique identifier of the IAK. <xref target="PSA-API"/>
            provides implementation options for deriving the IAK unique
            identifier from the IAK itself.</t>
            </li> itself.</li>
          </ul>
          <t>This claim MUST <bcp14>MUST</bcp14> be present in a PSA attestation token.</t>

          <artwork><![CDATA[
psa-instance-id-type = bytes .size 33

psa-instance-id = (
    ueid-label => psa-instance-id-type
)
]]></artwork>
)]]></artwork>

        </section>
        <section anchor="sec-implementation-id">
          <name>Implementation ID</name>
          <t>The Implementation ID claim uniquely identifies the hardware assembly of the
immutable PSA RoT. A verification service uses this claim to locate the
details of the PSA RoT implementation from an Endorser or manufacturer.
Such details are used by a verification service to determine the security properties
or certification status of the PSA RoT implementation.</t>
          <t>The value and format of the ID is decided by
the manufacturer or a particular certification scheme. For example, the ID
could take the form of a product serial number,
database ID, or other appropriate identifier.</t>
          <t>This claim MUST <bcp14>MUST</bcp14> be present in a PSA attestation token.</t>

          <t>Note that this identifies the PSA RoT implementation, not a particular instance.
To uniquely identify an instance, see the Instance ID claim <xref target="sec-instance-id-claim"/>.</t>

          <artwork><![CDATA[
psa-implementation-id-type = bytes .size 32

psa-implementation-id = (
    psa-implementation-id-key => psa-implementation-id-type
)
]]></artwork>
)]]></artwork>

        </section>
        <section anchor="sec-certification-reference">
          <name>Certification Reference</name>
          <t>The Certification Reference claim is used to link the class of chip and PSA RoT
of the attesting device to an associated entry in the PSA Certification
database.
<!-- [rfced] May we rephrase the following sentence for clarity?

Original:
It MUST be represented as a string made of
   nineteen numeric characters: a thirteen-digit [EAN-13], followed by a
   dash "-", followed by the five-digit versioning information described
   in [PSA-Cert-Guide].

Perhaps:
It MUST be represented as a string made of
   nineteen numeric characters: a thirteen-digit [EAN-13], followed by a
   dash "-", followed by the five-digit versioning information described
   in [PSA-Cert-Guide].
-->
It <bcp14>MUST</bcp14> be represented as a string made of nineteen numeric
characters: a thirteen-digit EAN-13 <xref target="EAN-13"/>, followed by a dash "-", and followed by
the five-digit versioning information described in <xref target="PSA-Cert-Guide"/>.</t>
          <t>Linking to the PSA Certification entry can still be achieved if this claim is
not present in the token by making an association at a Verifier between the
reference value and other token claim values - values, for example, the Implementation
ID.</t>
          <t>This claim MAY <bcp14>MAY</bcp14> be present in a PSA attestation token.</t>

          <artwork><![CDATA[
psa-certification-reference-type = text .regexp "[0-9]{13}-[0-9]{5}"

psa-certification-reference = (
    ? psa-certification-reference-key =>
        psa-certification-reference-type
)
]]></artwork>
)]]></artwork>

        </section>
      </section>
      <section anchor="target-state-claims">
        <name>Target State Claims</name>
        <section anchor="sec-security-lifecycle">
          <name>Security Lifecycle</name>
          <t>The Security Lifecycle claim represents the current lifecycle state of the PSA
RoT. The state is represented by an integer that is divided to convey a major
state and a minor state. A major state is mandatory and defined by <xref target="PSA-SM"/>.
A minor state is optional and 'IMPLEMENTATION DEFINED'. The PSA security
lifecycle state and implementation state are encoded as follows:</t>
          <ul spacing="normal">
            <li>
              <t>major[15:8]
            <li>major[15:8] - PSA security lifecycle state, and</t>
            </li>
            <li>
              <t>minor[7:0] and</li>
            <li>minor[7:0] - IMPLEMENTATION DEFINED state.</t>
            </li> state.</li>
          </ul>
          <t>The PSA lifecycle states are illustrated in <xref target="fig-lifecycle-states"/>. For PSA,
a Verifier can only trust reports from the PSA RoT when it is in SECURED or
NON_PSA_ROT_DEBUG major states.</t>
          <t>This claim MUST <bcp14>MUST</bcp14> be present in a PSA attestation token.</t>
          <figure anchor="fig-lifecycle-states">
            <name>PSA Lifecycle States</name>
            <artset>
              <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="528" width="472" viewBox="0 0 472 528" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                  <path d="M 24,272 L 24,416" fill="none" stroke="black"/>
                  <path d="M 24,448 L 24,480" fill="none" stroke="black"/>
                  <path d="M 104,48 L 104,64" fill="none" stroke="black"/>
                  <path d="M 112,144 L 112,160" fill="none" stroke="black"/>
                  <path d="M 128,352 L 128,400" fill="none" stroke="black"/>
                  <path d="M 144,240 L 144,272" fill="none" stroke="black"/>
                  <path d="M 144,480 L 144,512" fill="none" stroke="black"/>
                  <path d="M 160,272 L 160,288" fill="none" stroke="black"/>
                  <path d="M 160,320 L 160,344" fill="none" stroke="black"/>
                  <path d="M 208,64 L 208,120" fill="none" stroke="black"/>
                  <path d="M 208,160 L 208,232" fill="none" stroke="black"/>
                  <path d="M 208,400 L 208,416" fill="none" stroke="black"/>
                  <path d="M 208,448 L 208,472" fill="none" stroke="black"/>
                  <path d="M 232,208 L 232,232" fill="none" stroke="black"/>
                  <path d="M 264,280 L 264,304" fill="none" stroke="black"/>
                  <path d="M 264,336 L 264,352" fill="none" stroke="black"/>
                  <path d="M 280,240 L 280,272" fill="none" stroke="black"/>
                  <path d="M 280,480 L 280,512" fill="none" stroke="black"/>
                  <path d="M 288,352 L 288,400" fill="none" stroke="black"/>
                  <path d="M 304,128 L 304,144" fill="none" stroke="black"/>
                  <path d="M 312,352 L 312,400" fill="none" stroke="black"/>
                  <path d="M 320,32 L 320,48" fill="none" stroke="black"/>
                  <path d="M 352,304 L 352,344" fill="none" stroke="black"/>
                  <path d="M 368,400 L 368,416" fill="none" stroke="black"/>
                  <path d="M 368,448 L 368,480" fill="none" stroke="black"/>
                  <path d="M 400,208 L 400,304" fill="none" stroke="black"/>
                  <path d="M 400,336 L 400,352" fill="none" stroke="black"/>
                  <path d="M 440,352 L 440,400" fill="none" stroke="black"/>
                  <path d="M 120,32 L 320,32" fill="none" stroke="black"/>
                  <path d="M 104,64 L 304,64" fill="none" stroke="black"/>
                  <path d="M 128,128 L 304,128" fill="none" stroke="black"/>
                  <path d="M 112,160 L 288,160" fill="none" stroke="black"/>
                  <path d="M 248,192 L 384,192" fill="none" stroke="black"/>
                  <path d="M 144,240 L 280,240" fill="none" stroke="black"/>
                  <path d="M 40,256 L 144,256" fill="none" stroke="black"/>
                  <path d="M 280,256 L 336,256" fill="none" stroke="black"/>
                  <path d="M 144,272 L 280,272" fill="none" stroke="black"/>
                  <path d="M 128,352 L 288,352" fill="none" stroke="black"/>
                  <path d="M 312,352 L 440,352" fill="none" stroke="black"/>
                  <path d="M 128,400 L 288,400" fill="none" stroke="black"/>
                  <path d="M 312,400 L 440,400" fill="none" stroke="black"/>
                  <path d="M 144,480 L 280,480" fill="none" stroke="black"/>
                  <path d="M 40,496 L 136,496" fill="none" stroke="black"/>
                  <path d="M 288,496 L 352,496" fill="none" stroke="black"/>
                  <path d="M 144,512 L 280,512" fill="none" stroke="black"/>
                  <path d="M 120,32 C 111.16936,32 104,39.16936 104,48" fill="none" stroke="black"/>
                  <path d="M 304,64 C 312.83064,64 320,56.83064 320,48" fill="none" stroke="black"/>
                  <path d="M 128,128 C 119.16936,128 112,135.16936 112,144" fill="none" stroke="black"/>
                  <path d="M 288,160 C 296.83064,160 304,152.83064 304,144" fill="none" stroke="black"/>
                  <path d="M 248,192 C 239.16936,192 232,199.16936 232,208" fill="none" stroke="black"/>
                  <path d="M 384,192 C 392.83064,192 400,199.16936 400,208" fill="none" stroke="black"/>
                  <path d="M 40,256 C 31.16936,256 24,263.16936 24,272" fill="none" stroke="black"/>
                  <path d="M 336,256 C 344.83064,256 352,263.16936 352,272" fill="none" stroke="black"/>
                  <path d="M 40,496 C 31.16936,496 24,488.83064 24,480" fill="none" stroke="black"/>
                  <path d="M 352,496 C 360.83064,496 368,488.83064 368,480" fill="none" stroke="black"/>
                  <polygon class="arrowhead" points="360,344 348,338.4 348,349.6" fill="black" transform="rotate(90,352,344)"/>
                  <polygon class="arrowhead" points="296,496 284,490.4 284,501.6" fill="black" transform="rotate(180,288,496)"/>
                  <polygon class="arrowhead" points="272,280 260,274.4 260,285.6" fill="black" transform="rotate(270,264,280)"/>
                  <polygon class="arrowhead" points="240,232 228,226.4 228,237.6" fill="black" transform="rotate(90,232,232)"/>
                  <polygon class="arrowhead" points="216,472 204,466.4 204,477.6" fill="black" transform="rotate(90,208,472)"/>
                  <polygon class="arrowhead" points="216,232 204,226.4 204,237.6" fill="black" transform="rotate(90,208,232)"/>
                  <polygon class="arrowhead" points="216,120 204,114.4 204,125.6" fill="black" transform="rotate(90,208,120)"/>
                  <polygon class="arrowhead" points="168,344 156,338.4 156,349.6" fill="black" transform="rotate(90,160,344)"/>
                  <polygon class="arrowhead" points="144,496 132,490.4 132,501.6" fill="black" transform="rotate(0,136,496)"/>
                  <g class="text">
                    <text x="140" y="52">Device</text>
                    <text x="204" y="52">Assembly</text>
                    <text x="256" y="52">and</text>
                    <text x="292" y="52">Test</text>
                    <text x="244" y="84">Device</text>
                    <text x="252" y="100">Lockdown</text>
                    <text x="136" y="148">PSA</text>
                    <text x="168" y="148">RoT</text>
                    <text x="236" y="148">Provisioning</text>
                    <text x="148" y="196">Provisioning</text>
                    <text x="148" y="212">Lockdown</text>
                    <text x="208" y="260">Secured</text>
                    <text x="352" y="292">Debug</text>
                    <text x="160" y="308">Debug</text>
                    <text x="272" y="324">Recoverable</text>
                    <text x="416" y="324">Recoverable</text>
                    <text x="208" y="372">(Non-Recoverable)</text>
                    <text x="368" y="372">Recoverable</text>
                    <text x="168" y="388">Non-PSA</text>
                    <text x="216" y="388">RoT</text>
                    <text x="256" y="388">Debug</text>
                    <text x="336" y="388">PSA</text>
                    <text x="368" y="388">RoT</text>
                    <text x="408" y="388">Debug</text>
                    <text x="40" y="436">Terminate</text>
                    <text x="208" y="436">Non-Recoverable</text>
                    <text x="328" y="436">PSA</text>
                    <text x="360" y="436">RoT</text>
                    <text x="424" y="436">Compromised</text>
                    <text x="212" y="500">Decommissioned</text>
                  </g>
                </svg>
              </artwork>
              <artwork type="ascii-art"><![CDATA[
             .-------------------------.
            | Device Assembly and Test |
            '------------+------------'
                         | Device
                         | Lockdown
                         v
              .----------------------.
             | PSA RoT Provisioning  |
             '-----------+----------'
                         |
            Provisioning |   .------------------.
              Lockdown   |  |                    |
                         v  v                    |
                 .----------------.              |
   .-------------+    Secured     +-------.      |
  |              '-+--------------'        |     |
  |                |            ^        Debug   |
  |              Debug          |          |     |
  |                |        Recoverable    |  Recoverable
  |                v            |          v     |
  |            .----------------+--.  .----------+----.
  |            | (Non-Recoverable) |  | Recoverable   |
  |            | Non-PSA RoT Debug |  | PSA RoT Debug |
  |            '---------+---------'  '------+--------'
  |                      |                   |
Terminate         Non-Recoverable      PSA RoT Compromised
  |                      |                   |
  |                      v                   |
  |              .----------------.          |
   '------------>| Decommissioned |<--------'
                 '----------------'
]]></artwork>
            </artset>
          </figure>
          <t>The CDDL representation is shown below.
<xref target="tab-states-map"/> provides the mappings between <xref target="fig-lifecycle-states"/> and the data model.</t>
          <artwork><![CDATA[

          <sourcecode type="cddl"><![CDATA[
psa-lifecycle-unknown-type = 0x0000..0x00ff
psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff
psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff
psa-lifecycle-secured-type = 0x3000..0x30ff
psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff
psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff
psa-lifecycle-decommissioned-type = 0x6000..0x60ff

psa-lifecycle-type =
    psa-lifecycle-unknown-type /
    psa-lifecycle-assembly-and-test-type /
    psa-lifecycle-psa-rot-provisioning-type /
    psa-lifecycle-secured-type /
    psa-lifecycle-non-psa-rot-debug-type /
    psa-lifecycle-recoverable-psa-rot-debug-type /
    psa-lifecycle-decommissioned-type

psa-lifecycle = (
    psa-lifecycle-key => psa-lifecycle-type
)
]]></artwork>
)]]></sourcecode>

          <t><tt>psa-lifecycle-unknown-type</tt> is not shown in <xref target="fig-lifecycle-states"/>; it represents an invalid state that must not occur in a system.</t>
          <table anchor="tab-states-map">
            <name>Lifecycle States Mappings</name>
            <thead>
              <tr>
                <th align="left">CDDL</th>
                <th align="left">Lifecycle States</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">
                  <tt>psa-lifecycle-unknown-type</tt></td>
                <td align="left"> </td> align="left"> </td>
              </tr>
              <tr>
                <td align="left">
                  <tt>psa-lifecycle-assembly-and-test-type</tt></td>
                <td align="left">Assembly and Test</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>psa-lifecycle-psa-rot-provisioning-type</tt></td>
                <td align="left">PSA RoT Provisioning</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>psa-lifecycle-secured-type</tt></td>
                <td align="left">Secured</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>psa-lifecycle-non-psa-rot-debug-type</tt></td>
                <td align="left">Non-Recoverable PSA RoT Debug</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>psa-lifecycle-recoverable-psa-rot-debug-type</tt></td>
                <td align="left">Recoverable PSA RoT Debug</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>psa-lifecycle-decommissioned-type</tt></td>
                <td align="left">Decommissioned</td>
              </tr>
            </tbody>
          </table>
        </section>
        <section anchor="sec-boot-seed">
          <name>Boot Seed</name>
          <t>The Boot Seed claim contains a value created at system boot time
that allows differentiation of attestation reports from different
boot sessions of a particular entity (i.e., a certain Instance ID).</t>
          <t>The EAT <tt>bootseed</tt> (claim key 268) is used.
The following constraints apply to the <tt>binary-data</tt> type:</t>
          <ul spacing="normal">
            <li>
              <t>The
            <li>The length MUST <bcp14>MUST</bcp14> be between 8 and 32 bytes.</t>
            </li> bytes.</li>
          </ul>
          <t>This claim MAY <bcp14>MAY</bcp14> be present in a PSA attestation token.</t>

          <artwork><![CDATA[
psa-boot-seed-type = bytes .size (8..32)

psa-boot-seed = (
    boot-seed-label => psa-boot-seed-type
)
]]></artwork>
)]]></artwork>

        </section>
      </section>
      <section anchor="software-inventory-claims">
        <name>Software Inventory Claims</name>
        <section anchor="sec-sw-components">
          <name>Software Components</name>
          <t>The Software Components claim is a list of software components that includes
all the software (both code and configuration) loaded by the PSA RoT.  This
claim MUST <bcp14>MUST</bcp14> be included in attestation tokens produced by an implementation
conformant with <xref target="PSA-SM"/>.</t>
          <t>Each entry in the Software Components list describes one software component
using the attributes described in the following subsections.  Unless explicitly
stated, the presence of an attribute is OPTIONAL.</t> <bcp14>OPTIONAL</bcp14>.</t>
          <t>Note that, as described in <xref target="RFC9334"/>, that a relying party Relying Party will typically see the
result of the appraisal process from the Verifier in form of an Attestation
Result,
Result rather than the PSA token from the attesting endpoint. endpoint as described in <xref target="RFC9334"/>.
Therefore, a relying party Relying Party is not expected to understand the Software
Components claim.  Instead, it is for the Verifier to check this claim against
the available Reference Values and provide an answer in form of an "high level" a "high-level"
Attestation Result, which may or may not include the original Software
Components claim.</t>

          <artwork><![CDATA[
psa-software-component = {
  ? &(measurement-type: 1) => text
    &(measurement-value: 2) => psa-hash-type
  ? &(version: 4) => text
    &(signer-id: 5) => psa-hash-type
  ? &(measurement-desc: 6) => text
}

psa-software-components = (
    psa-software-components-key => [ + psa-software-component ]
)
]]></artwork>
)]]></artwork>

          <section anchor="measurement-type">
            <name>Measurement Type</name>
            <t>The Measurement Type attribute (key=1) is a short string representing the role of
this software component.</t>
            <t>The following measurement types MAY <bcp14>MAY</bcp14> be used for code measurements:</t>
            <ul spacing="normal">
              <li>
                <t>"BL": a
            <dl spacing="normal" newline="false">
              <dt>"BL":</dt><dd>a Boot Loader</t>
              </li>
              <li>
                <t>"PRoT": a Loader</dd>
              <dt>"PRoT":</dt><dd>a component of the PSA Root of Trust</t>
              </li>
              <li>
                <t>"ARoT": a Trust</dd>
              <dt>"ARoT":</dt><dd>a component of the Application Root of Trust</t>
              </li>
              <li>
                <t>"App": a Trust</dd>
              <dt>"App":</dt><dd>a component of the NSPE application</t>
              </li>
              <li>
                <t>"TS": a application</dd>
              <dt>"TS":</dt><dd>a component of a Trusted Subsystem</t>
              </li>
            </ul> Subsystem</dd>
            </dl>
            <t>The same labels with a "_CONFIG" postfix (e.g., "PRoT_CONFIG") MAY <bcp14>MAY</bcp14> be used for
configuration measurements.</t>
            <t>This attribute SHOULD <bcp14>SHOULD</bcp14> be present in a PSA software component unless
there is a very good reason to leave it out - out, for example example, in networks
with severely constrained bandwidth, bandwidth where sparing a few bytes really
makes a difference.</t>
          </section>
          <section anchor="measurement-value">
            <name> Measurement
            <name>Measurement Value</name>
            <t>The Measurement Value attribute (key=2) represents a hash of the invariant
software component in memory at startup time. The value MUST <bcp14>MUST</bcp14> be a cryptographic
hash of 256 bits or stronger.</t>
            <t>This attribute MUST <bcp14>MUST</bcp14> be present in a PSA software component.</t>
          </section>
          <section anchor="version">
            <name>Version</name>
            <t>The Version attribute (key=4) is the issued software version in the form of a
text string. The value of this attribute will correspond to the entry in the
original signed manifest of the component.</t>
          </section>
          <section anchor="signer-id">
            <name>Signer ID</name>
            <t>The Signer ID attribute (key=5) uniquely identifies the signer of the software component. The identification is typically accomplished by hashing the signer's public key.
The value of this attribute will correspond to the
entry in the original manifest for the component. This can be used by a
Verifier to ensure the components were signed by an expected trusted source.</t>
            <t>This attribute MUST <bcp14>MUST</bcp14> be present in a PSA software component to be compliant with
<xref target="PSA-SM"/>.</t>
          </section>
          <section anchor="measurement-description">
            <name>Measurement Description</name>
            <t>The Measurement Description attribute (key=6) contains a string identifying the
hash algorithm used to compute the corresponding Measurement Value.  The string
SHOULD
<bcp14>SHOULD</bcp14> be encoded according to "Hash Name String" in the "Named Information Hash Algorithm Registry" <xref target="IANA.named-information"/>.</t> target="NAMED-INFO"/>.</t>
          </section>
        </section>
      </section>
      <section anchor="verification-claims">
        <name>Verification Claims</name>
        <t>The
<!-- [rfced] We have updated the following sentence for clarity. Please review
and let us know any objections.

Original:
   The following claims are part of the PSA token (and therefore still
   Evidence) but aim to help receivers, including relying parties, with
   the processing of the received attestation Evidence.

Current:
   The following claims are part of the PSA token (and are therefore still
   Evidence). However, they aim to help receivers, including Relying
   parties, with the processing of the received attestation Evidence.
-->
        <t>The following claims are part of the PSA token (and are therefore still Evidence). However, they aim to help receivers, including Relying Parties, with the
processing of the received attestation Evidence.</t>
        <section anchor="sec-verification-service-indicator">
          <name>Verification Service Indicator</name>
          <t>The Verification Service Indicator claim is a hint used by a relying party Relying Party to
locate a verification service for the token. The value is a text string that
can be used to locate the service (typically, a URL specifying the address of
the verification service API). A Relying Party may choose to ignore this claim
in favor of other information.</t>

          <artwork><![CDATA[
psa-verification-service-indicator-type = text

psa-verification-service-indicator = (
    ? psa-verification-service-indicator-key =>
        psa-verification-service-indicator-type
)
]]></artwork>
)]]></artwork>

          <t>It is assumed that the relying party Relying Party is pre-configured with a list of trusted
verification services and that the contents of this hint can be used to look
up the correct one. Under no circumstances must the relying party Relying Party be tricked
into contacting an unknown and untrusted verification service since the
returned Attestation Result cannot be relied on.</t>
<!-- [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).
-->
          <t>Note: This hint requires the relying party Relying Party to parse the content of the
PSA token. Since the relying party Relying Party may not be in possession of a trust
anchor to verify the digital signature, it uses the hint in the same way
as it would treat any other information provided by an external party,
which includes attacker-provided data.</t>
        </section>
        <section anchor="sec-profile-definition-claim">
          <name>Profile Definition</name>
          <t>The Profile Definition claim encodes the unique identifier that corresponds to
the EAT profile described by this document.  This allows a receiver to assign
the intended semantics to the rest of the claims found in the token.</t>
          <t>The EAT <tt>eat_profile</tt> (claim key 265) is used.</t>
          <t>The URI encoding MUST <bcp14>MUST</bcp14> be used.</t>
          <t>The value MUST <bcp14>MUST</bcp14> be <tt>tag:psacertified.org,2023:psa#tfm</tt> for the profile defined in <xref target="sec-tfm-profile"/>.</t>
          <t>Future profiles derived from the baseline PSA profile SHALL <bcp14>SHALL</bcp14> create their unique value, value as described in <xref target="sec-profile-uri-structure"/>.</t>
          <t>This claim MUST <bcp14>MUST</bcp14> be present in a PSA attestation token.</t>
          <t>See <xref target="sec-backwards-compat"/>, target="sec-backwards-compat"/> for considerations about backwards compatibility
with previous versions of the PSA attestation token format.</t>

          <artwork><![CDATA[
psa-profile-type = "tag:psacertified.org,2023:psa#tfm"

psa-profile = (
    profile-label => psa-profile-type
)
]]></artwork>
)]]></artwork>

          <section anchor="sec-profile-uri-structure">
            <name>URI Structure for the Derived Profile Identifiers</name>
            <t>A new profile is associated with a unique string.</t>
            <t>The string MUST <bcp14>MUST</bcp14> use the URI fragment syntax defined in <xref section="3.5" sectionFormat="of" target="RFC3986"/>.</t>
            <t>The string SHOULD <bcp14>SHOULD</bcp14> be short to avoid unnecessary overhead.</t>
            <t>To avoid collisions, profile authors SHOULD <bcp14>SHOULD</bcp14> communicate upfront their intent upfront to use a certain string using that uses the enquiry inquiry form on the website <xref target="PSACertified"/> website.</t> target="PSACertified"/>.</t>
            <t>To derive the value to be used for the <tt>eat_profile</tt> claim, the string is added as a fragment to the <tt>tag:psacertified.org,2023:psa</tt> tag URI <xref target="RFC4151"/>.</t>
            <t>For example, an a hypothetical profile using only COSE_Mac0 with the AES Message Authentication Code (AES-MAC) may decide to use the string "aes-mac".  The <tt>eat_profile</tt> value would then be: be <tt>tag:psacertified.org,2023:psa#aes-mac</tt>.</t>
          </section>
        </section>
      </section>
      <section anchor="sec-backwards-compat">
        <name>Backwards Compatibility Considerations</name>
        <t>A previous version
        <t>An earlier draft of this specification document <xref target="PSA-OLD"/>, target="I-D.tschofenig-rats-psa-token"/> identified by the <tt>PSA_IOT_PROFILE_1</tt>
profile, used claim key values from the "private use range" of the CWT Claims
registry.  These claim keys have now been deprecated.</t>
        <t><xref target="tab-claim-map"/> provides the mappings between the deprecated and new claim
keys.</t>
        <table anchor="tab-claim-map">
          <name>Claim Key Mappings</name>
          <thead>
            <tr>
              <th align="left"> </th> align="left"> </th>
              <th align="left">PSA_IOT_PROFILE_1</th>
              <th align="left">tag:psacertified.org,2023:psa#tfm</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Nonce</td>
              <td align="left">-75008</td>
              <td align="left">10 (EAT nonce)</td>
            </tr>
            <tr>
              <td align="left">Instance ID</td>
              <td align="left">-75009</td>
              <td align="left">256 (EAT euid)</td>
            </tr>
            <tr>
              <td align="left">Profile Definition</td>
              <td align="left">-75000</td>
              <td align="left">265 (EAT eat_profile)</td>
            </tr>
            <tr>
              <td align="left">Client ID</td>
              <td align="left">-75001</td>
              <td align="left">2394</td>
            </tr>
            <tr>
              <td align="left">Security Lifecycle</td>
              <td align="left">-75002</td>
              <td align="left">2395</td>
            </tr>
            <tr>
              <td align="left">Implementation ID</td>
              <td align="left">-75003</td>
              <td align="left">2396</td>
            </tr>
            <tr>
              <td align="left">Boot Seed</td>
              <td align="left">-75004</td>
              <td align="left">268 (EAT bootseed)</td>
            </tr>
            <tr>
              <td align="left">Certification Reference</td>
              <td align="left">-75005</td>
              <td align="left">2398</td>
            </tr>
            <tr>
              <td align="left">Software Components</td>
              <td align="left">-75006</td>
              <td align="left">2399</td>
            </tr>
            <tr>
              <td align="left">Verification Service Indicator</td>
              <td align="left">-75010</td>
              <td align="left">2400</td>
            </tr>
          </tbody>
        </table>
        <t>The new profile introduces three further changes:</t>
        <ul spacing="normal">
          <li>
            <t>the
          <li>The "Boot Seed" claim is now optional and of variable length
          (see <xref target="sec-boot-seed"/>),</t>
          </li>
          <li>
            <t>the target="sec-boot-seed"/>).</li>
          <li>The "No Software Measurements" claim has been retired,</t>
          </li>
          <li>
            <t>the retired.</li>
          <li>The "Certification Reference" claim syntax changed from EAN-13
          to EAN-13+5 (see <xref target="sec-certification-reference"/>).</t>
          </li> target="sec-certification-reference"/>).</li>
        </ul>

        <t>To simplify the transition to the token format described in this
document
document, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that Verifiers
accept tokens encoded according to the old profile (<tt>PSA_IOT_PROFILE_1</tt>) as well as
to the profile defined in this document (<tt>tag:psacertified.org,2023:psa#tfm</tt>), at least for the time needed to
their devices to upgrade.</t>
      </section>
    </section>
    <section anchor="sec-profiles">
      <name>Profiles</name>
      <t>This document defines a baseline with common requirements that all PSA profiles must satisfy.
(Note that this does not apply to <xref target="PSA-OLD"/>.)</t> target="I-D.tschofenig-rats-psa-token"/>.)</t>
      <t>This document also defines a "TFM" profile (<xref target="sec-tfm-profile"/>) that builds on the baseline while constraining the use of COSE algorithms to improve interoperability between Attesters and Verifiers.</t>
      <t>Baseline and TFM are what the EAT calls a "partial" and "full" profile, respectively. See <xref section="6.2" sectionFormat="of" target="EAT"/> target="RFC9711"/> for further details regarding profiles.</t>
      <section anchor="baseline-profile">
        <name>Baseline Profile</name>
        <section anchor="sec-token-encoding-and-signing">
          <name> Token
          <name>Token Encoding and Signing</name>
          <t>The PSA attestation token is encoded in CBOR <xref target="STD94"/> format.
The CBOR representation of a PSA token MUST <bcp14>MUST</bcp14> be "valid" according to the definition in Section <xref section="1.2" sectionFormat="of" sectionFormat="bare" target="RFC8949"/> of RFC 8949 <xref target="STD94"/>.
Besides, only definite-length string, arrays, and maps are allowed.
Given that a PSA Attester is typically found in a constrained device, it MAY <bcp14>MAY</bcp14>
NOT emit CBOR preferred serializations (<xref (Section <xref section="4.1" sectionFormat="of" sectionFormat="bare" target="RFC8949"/> of RFC 8949 <xref target="STD94"/>).
Therefore, the Verifier MUST <bcp14>MUST</bcp14> be a variation-tolerant CBOR decoder.</t>
          <t>Cryptographic protection is obtained by wrapping the <tt>psa-token</tt> claims-set in a COSE
Web Token (CWT) <xref target="RFC8392"/>.  For asymmetric key algorithms, the signature
structure MUST <bcp14>MUST</bcp14> be a tagged (18) COSE_Sign1.  For symmetric key algorithms, the signature
structure MUST <bcp14>MUST</bcp14> be a tagged (17) COSE_Mac0.</t>
          <t>Acknowledging the variety of markets, regulations regulations, and use cases in which the
PSA attestation token can be used, the baseline profile does not impose any
strong requirement on the cryptographic algorithms that need to be supported by
Attesters and Verifiers.  The flexibility provided by the COSE format should be
sufficient to deal with the level of cryptographic agility needed to adapt to
specific use cases.  It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that commonly adopted algorithms are
used, such as those discussed in <xref target="COSE-ALGS"/>. target="RFC9053"/>.  It is expected that receivers
will accept a wider range of algorithms, algorithms while Attesters would produce PSA tokens
using only one such algorithm.</t>
          <t>The CWT CBOR tag (61) is not used.  An application that needs to exchange PSA
attestation tokens can wrap the serialised serialized COSE_Sign1 or COSE_Mac0 in the media
type defined in <xref target="sec-iana-media-types"/> or the CoAP Content-Format defined in
<xref target="sec-iana-coap-content-format"/>.</t>
          <t>A PSA token is always directly signed by the PSA RoT.  Therefore, a PSA
claims-set (<xref target="sec-psa-claims"/>) is never carried in a Detached EAT bundle
(<xref section="5" sectionFormat="of" target="EAT"/>).</t> target="RFC9711"/>).</t>
        </section>
        <section anchor="freshness-model">
          <name>Freshness Model</name>
          <t>The PSA token supports the freshness models for attestation Evidence based on
nonces and epoch handles (Section <xref target="RFC9334" section="10.2" sectionFormat="bare"/> and Section <xref target="RFC9334" section="10.3" sectionFormat="bare"/> of <xref target="RFC9334"/>) using
the <tt>nonce</tt> claim to convey the nonce or epoch handle supplied by the Verifier.
No further assumption on the specific remote attestation protocol is made.</t>
          <t>Note that use of epoch handles is constrained by the type restrictions imposed by the <tt>eat_nonce</tt> syntax.
For use in PSA tokens, it must be possible to encode the epoch handle as an opaque binary string between 8 and 64 octets.</t>
        </section>
        <section anchor="synopsis">
          <name>Synopsis</name>
          <t><xref target="tbl-baseline-profile"/> presents a concise view of the requirements described in the preceding sections.</t>
          <table anchor="tbl-baseline-profile">
            <name>Baseline Profile</name>
            <thead>
              <tr>
                <th align="left">Issue</th>
                <th align="left">Profile Definition</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">CBOR/JSON</td>
                <td align="left">CBOR MUST <bcp14>MUST</bcp14> be used</td> used.</td>
              </tr>
              <tr>
                <td align="left">CBOR Encoding</td>
                <td align="left">Definite length maps and arrays MUST <bcp14>MUST</bcp14> be used</td> used.</td>
              </tr>
              <tr>
                <td align="left">CBOR Encoding</td>
                <td align="left">Definite length strings MUST <bcp14>MUST</bcp14> be used</td> used.</td>
              </tr>
              <tr>
                <td align="left">CBOR Serialization</td>
                <td align="left">Variant serialization MAY <bcp14>MAY</bcp14> be used</td> used.</td>
              </tr>
              <tr>
                <td align="left">COSE Protection</td>
                <td align="left">COSE_Sign1 and/or COSE_Mac0 MUST <bcp14>MUST</bcp14> be used</td> used.</td>
              </tr>
              <tr>
                <td align="left">Algorithms</td>
                <td align="left">
                  <xref target="COSE-ALGS"/> SHOULD target="RFC9053"/> <bcp14>SHOULD</bcp14> be used</td> used.</td>
              </tr>
              <tr>
                <td align="left">Detached EAT Bundle Usage</td>
                <td align="left">Detached EAT bundles MUST NOT <bcp14>MUST NOT</bcp14> be sent</td> sent.</td>
              </tr>
              <tr>
                <td align="left">Verification Key Identification</td>
                <td align="left">Any identification method listed in <xref section="F.1" sectionFormat="of" target="EAT"/></td> target="RFC9711"/>.</td>
              </tr>
              <tr>
                <td align="left">Endorsements</td>
                <td align="left">See <xref target="sec-psa-endorsements"/></td> target="sec-psa-endorsements"/>.</td>
              </tr>
              <tr>
                <td align="left">Freshness</td>
                <td align="left">nonce align="left">Nonce or epoch ID based</td> ID-based.</td>
              </tr>
              <tr>
                <td align="left">Claims</td>
                <td align="left">Those defined in <xref target="sec-psa-claims"/>. As per general EAT rules, the receiver MUST NOT <bcp14>MUST NOT</bcp14> error out on claims it does not understand.</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
      <section anchor="sec-tfm-profile">
        <name>Profile TFM</name>
        <t>This
        <t>The TFM profile is appropriate for the code base implemented in <xref target="TF-M"/> and should apply for most derivative implementations. If an implementation changes the requirements described below then, to ensure interoperability, below, then a different profile value should be used (<xref target="sec-profile-uri-structure"/>). target="sec-profile-uri-structure"/>) to ensure interoperability. This includes a restriction of the profile to a subset of the COSE Protection scheme requirements.</t>
        <t><xref target="tbl-tfm-profile"/> presents a concise view of the requirements.</t>
        <t>The value of the <tt>eat_profile</tt> MUST <bcp14>MUST</bcp14> be <tt>tag:psacertified.org,2023:psa#tfm</tt>.</t>
        <table anchor="tbl-tfm-profile">
          <name>TF-M Profile</name>
          <thead>
            <tr>
              <th align="left">Issue</th>
              <th align="left">Profile Definition</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">CBOR/JSON</td>
              <td align="left">See <xref target="baseline-profile"/></td> target="baseline-profile"/>.</td>
            </tr>
            <tr>
              <td align="left">CBOR Encoding</td>
              <td align="left">See <xref target="baseline-profile"/></td> target="baseline-profile"/>.</td>
            </tr>
            <tr>
              <td align="left">CBOR Encoding</td>
              <td align="left">See <xref target="baseline-profile"/></td> target="baseline-profile"/>.</td>
            </tr>
            <tr>
              <td align="left">CBOR Serialization</td>
              <td align="left">See <xref target="baseline-profile"/></td> target="baseline-profile"/>.</td>
            </tr>
            <tr>
              <td align="left">COSE Protection</td>
              <td align="left">COSE_Sign1 or COSE_Mac0 MUST <bcp14>MUST</bcp14> be used</td> used.</td>
            </tr>
            <tr>
              <td align="left">Algorithms</td>
              <td align="left">The receiver MUST <bcp14>MUST</bcp14> accept ES256, ES384 ES384, and ES512 with COSE_Sign1 and HMAC256/256, HMAC384/384 HMAC384/384, and HMAC512/512 with COSE_Mac0; the sender MUST <bcp14>MUST</bcp14> send one of these</td> these.</td>
            </tr>
            <tr>
              <td align="left">Detached EAT Bundle Usage</td>
              <td align="left">See <xref target="baseline-profile"/></td> target="baseline-profile"/>.</td>
            </tr>
            <tr>
              <td align="left">Verification Key Identification</td>
              <td align="left">Claim-Based Key Identification (<xref section="F.1.4" sectionFormat="of" target="EAT"/>) target="RFC9711"/>) using Instance ID</td> ID.</td>
            </tr>
            <tr>
              <td align="left">Endorsements</td>
              <td align="left">See <xref target="sec-psa-endorsements"/></td> target="sec-psa-endorsements"/>.</td>
            </tr>
            <tr>
              <td align="left">Freshness</td>
              <td align="left">See <xref target="baseline-profile"/></td> target="baseline-profile"/>.</td>
            </tr>
            <tr>
              <td align="left">Claims</td>
              <td align="left">See <xref target="baseline-profile"/></td> target="baseline-profile"/>.</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="collated-cddl">
      <name>Collated CDDL</name>
      <artwork><![CDATA[

      <sourcecode type="cddl"><![CDATA[
psa-token = {
    psa-nonce
    psa-instance-id
    psa-verification-service-indicator
    psa-profile
    psa-implementation-id
    psa-client-id
    psa-lifecycle
    psa-certification-reference
    ? psa-boot-seed
    psa-software-components
}

psa-client-id-key = 2394
psa-lifecycle-key = 2395
psa-implementation-id-key = 2396
psa-certification-reference-key = 2398
psa-software-components-key = 2399
psa-verification-service-indicator-key = 2400

nonce-label = 10
ueid-label = 256
boot-seed-label = 268
profile-label = 265

psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64

psa-boot-seed-type = bytes .size (8..32)

psa-boot-seed = (
    boot-seed-label => psa-boot-seed-type
)

psa-client-id-nspe-type = -2147483648...0
psa-client-id-spe-type = 1..2147483647

psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-type

psa-client-id = (
    psa-client-id-key => psa-client-id-type
)

psa-certification-reference-type = text .regexp "[0-9]{13}-[0-9]{5}"

psa-certification-reference = (
    ? psa-certification-reference-key =>
        psa-certification-reference-type
)

psa-implementation-id-type = bytes .size 32

psa-implementation-id = (
    psa-implementation-id-key => psa-implementation-id-type
)

psa-instance-id-type = bytes .size 33

psa-instance-id = (
    ueid-label => psa-instance-id-type
)

psa-nonce = (
    nonce-label => psa-hash-type
)

psa-profile-type = "tag:psacertified.org,2023:psa#tfm"

psa-profile = (
    profile-label => psa-profile-type
)

psa-lifecycle-unknown-type = 0x0000..0x00ff
psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff
psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff
psa-lifecycle-secured-type = 0x3000..0x30ff
psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff
psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff
psa-lifecycle-decommissioned-type = 0x6000..0x60ff

psa-lifecycle-type =
    psa-lifecycle-unknown-type /
    psa-lifecycle-assembly-and-test-type /
    psa-lifecycle-psa-rot-provisioning-type /
    psa-lifecycle-secured-type /
    psa-lifecycle-non-psa-rot-debug-type /
    psa-lifecycle-recoverable-psa-rot-debug-type /
    psa-lifecycle-decommissioned-type

psa-lifecycle = (
    psa-lifecycle-key => psa-lifecycle-type
)

psa-software-component = {
  ? &(measurement-type: 1) => text
    &(measurement-value: 2) => psa-hash-type
  ? &(version: 4) => text
    &(signer-id: 5) => psa-hash-type
  ? &(measurement-desc: 6) => text
}

psa-software-components = (
    psa-software-components-key => [ + psa-software-component ]
)

psa-verification-service-indicator-type = text

psa-verification-service-indicator = (
    ? psa-verification-service-indicator-key =>
        psa-verification-service-indicator-type
)

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

    </section>
    <section anchor="sec-scalability">
      <name>Scalability Considerations</name>
      <t>IAKs (see <xref target="sec-psa-attester-model"/>) can be either raw public keys or certified public keys.</t>
      <t>Certified
<!-- [rfced] We have updated "certs" in the sentence below to "certifications"
for consistency. The use of "certs" has also been updated throughout the
rest of the document. Please let us know any objections.

Original:
   Certified public keys require the manufacturer to run the
   certification authority (CA) that issues X.509 certs for the IAKs.

Current:
   Certified public keys require the manufacturer to run the
   certification authority (CA) that issues X.509 certifications for the IAKs.
-->
      <t>Certified public keys require the manufacturer to run the certification
authority (CA) that issues X.509 certifications for the IAKs.  (Note that operating a CA
is a complex and expensive task that may be unaffordable to certain
manufacturers.)</t>
      <t>Using certified public keys offers better scalability properties when compared to using raw public keys, namely:</t>
      <ul spacing="normal">
        <li>
          <t>storage
        <li>Storage requirements for the Verifier are minimised - minimized; the same
        manufacturer's trust anchor is used for any number of devices,</t>
        </li>
        <li>
          <t>the devices.</li>
	<li>The provisioning model is simpler and more robust since there is no
	need to notify the Verifier about each newly manufactured device,</t>
        </li> device.</li>
      </ul>

      <t>Furthermore, existing and well-understood revocation mechanisms can be readily used.</t>
      <t>The IAK's X.509 cert certification can be inlined in the PSA token using the <tt>x5chain</tt> COSE
header parameter <xref target="COSE-X509"/> target="RFC9360"/> at the cost of an increase in the PSA token
size.  <xref section="4.4" sectionFormat="of" target="TLS12-IoT"/> target="RFC7925"/> and <xref section="15" sectionFormat="of" target="TLS13-IoT"/> target="I-D.ietf-uta-tls13-iot-profile"/> provide
guidance for profiling X.509 certs certifications used in IoT deployments.
Note that the exact split between pre-provisioned and inlined certs certifcations may vary
depending on the specific deployment.  In that respect, <tt>x5chain</tt> is quite
flexible: it
flexible. It can contain the end-entity end entity (EE) cert certification only, the EE and a partial
chain, or the EE and the full chain up to the trust anchor (see <xref section="2" sectionFormat="of" target="COSE-X509"/> target="RFC9360"/> for the details).
Constraints around network bandwidth and computing resources available to endpoints, such as network buffers, may dictate a reasonable split point.</t>
    </section>
    <section anchor="psa-token-verification">
      <name>PSA Token Verification</name>
      <t>To verify the token, the primary need is to check correct encoding and signing
as detailed in <xref target="sec-token-encoding-and-signing"/>.
The key used for verification is either supplied to the Verifier by an
authorized Endorser along with the corresponding Attester's Instance ID or
inlined in the token using the <tt>x5chain</tt> header parameter as described in
<xref target="sec-scalability"/>.
If the IAK is a raw public key, key and the Instance ID claim is
used to assist in
locating the key used to verify the signature covering the CWT token.
If the IAK is a certified public key, X.509 path construction and validation
(<xref section="6" sectionFormat="of" target="X509"/>) target="RFC5280"/>) up to a trusted CA MUST <bcp14>MUST</bcp14> be successful before the key is
used to verify the token signature.  This also includes revocation checking.</t>
<!-- [rfced] To clarify, are the reference values described below registered
with the Verifier? Or are the claims in this profile compared to
reference values in addition to being registered with the Verifier?

Original:
   In addition, the Verifier will typically operate a policy where
   values of some of the claims in this profile can be compared to
   reference values, registered with the Verifier for a given
   deployment, in order to confirm that the device is endorsed by the
   manufacturer supply chain.

Perhaps:
   In addition, the Verifier will typically operate a policy where
   values of some of the claims in this profile can be compared to
   reference values and registered with the Verifier for a given
   deployment in order to confirm that the device is endorsed by the
   manufacturer supply chain.

Or:
   In addition, the Verifier will typically operate a policy where
   values of some of the claims in this profile can be compared to
   reference values that are registered with the Verifier for a given
   deployment in order to confirm that the device is endorsed by the
   manufacturer supply chain.
-->
      <t>In addition, the Verifier will typically operate a policy where values of some
of the claims in this profile can be compared to reference values, registered
with the Verifier for a given deployment, in order to confirm that the device
is endorsed by the manufacturer supply chain.  The policy may require that the
relevant claims must have a match to a registered reference value.  All claims
may be worthy of additional appraisal.  It is likely that most deployments
would include a policy with appraisal for the following claims:</t>
      <ul spacing="normal">
        <li>
          <t>Implementation ID - the
        <li>Implementation ID: The value of the Implementation ID can be used
        to identify the verification requirements of the deployment.</t>
        </li>
        <li>
          <t>Software deployment.</li>
        <li>Software Component, Measurement Value - this Value: This value can uniquely
        identify a firmware release from the supply chain. In some cases, a
        Verifier may maintain a record for a series of firmware releases, releases
        being patches to an original baseline release. A verification policy
        may then allow this value to match any point on that release sequence
        or expect some minimum level of maturity related to the sequence.</t>
        </li>
        <li>
          <t>Software sequence.</li>
        <li>Software Component, Signer ID - where ID: Where present in a deployment, this
        could allow a Verifier to operate a more general policy than that for
        Measurement Value as above, above by allowing a token to contain any
        firmware entries signed by a known Signer ID, ID without checking for a
        uniquely registered version.</t>
        </li>
        <li>
          <t>Certification Reference - if version.</li>
        <li>Certification Reference: If present, this value could be used as a
        hint to locate security certification information associated with the
        attesting device. An example could be a reference to a <xref
        target="PSACertified"/> certificate.</t>
        </li> certificate.</li>
      </ul>
      <section anchor="ar4si-trustworthiness-claims-mappings">
        <name> AR4SI
        <name>AR4SI Trustworthiness Claims Mappings</name>
        <t><xref target="RATS-AR4SI"/> target="I-D.ietf-rats-ar4si"/> defines an information model that Verifiers can employ to
produce Attestation Results.
AR4SI provides a set of standardized appraisal categories and tiers that
greatly simplifies the task of writing Relying Party policies in multi-attester Multi-Attester
environments.</t>
        <t>The contents of <xref target="tab-ar4si-map"/> are intended as guidance for implementing a
PSA Verifier that computes its results using AR4SI.
The table describes which PSA Evidence claims (if any) are related to which
AR4SI trustworthiness claim, and therefore what the Verifier must consider when
deciding if and how to appraise a certain feature associated with the PSA
Attester.</t>
        <table anchor="tab-ar4si-map">
          <name>AR4SI Claims mappings</name>
          <thead>
            <tr>
              <th align="left">Trustworthiness Vector claims</th>
              <th align="left">Related PSA claims</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">
                <tt>configuration</tt></td>
              <td align="left">Software Components (<xref target="sec-sw-components"/>)</td>
            </tr>
            <tr>
              <td align="left">
                <tt>executables</tt></td>
              <td align="left">ditto</td>
            </tr>
            <tr>
              <td align="left">
                <tt>file-system</tt></td>
              <td align="left">N/A</td>
            </tr>
            <tr>
              <td align="left">
                <tt>hardware</tt></td>
              <td align="left">Implementation ID (<xref target="sec-implementation-id"/>)</td>
            </tr>
            <tr>
              <td align="left">
                <tt>instance-identity</tt></td>
              <td align="left">Instance ID (<xref target="sec-instance-id-claim"/>).  The Security Lifecycle (<xref target="sec-security-lifecycle"/>) can also impact the derived identity.</td>
            </tr>
            <tr>
              <td align="left">
                <tt>runtime-opaque</tt></td>
              <td align="left">Indirectly derived from <tt>executables</tt>, <tt>hardware</tt>, and <tt>instance-identity</tt>.  The Security Lifecycle (<xref target="sec-security-lifecycle"/>) can also be relevant: for example, relevant, e.g., any debug state will expose otherwise protected memory.</td>
            </tr>
            <tr>
              <td align="left">
                <tt>sourced-data</tt></td>
              <td align="left">N/A</td>
            </tr>
            <tr>
              <td align="left">
                <tt>storage-opaque</tt></td>
              <td align="left">Indirectly derived from <tt>executables</tt>, <tt>hardware</tt>, and <tt>instance-identity</tt>.</td>
            </tr>
          </tbody>
        </table>
        <t>This document does not prescribe what value must be chosen based on each
possible situation: when situation. When assigning specific Trustworthiness Claim values, an
implementation is expected to follow the algorithm described in <xref section="2.3.3" sectionFormat="of" target="RATS-AR4SI"/>.</t> target="I-D.ietf-rats-ar4si"/>.</t>
      </section>
      <section anchor="sec-psa-endorsements">
        <name>Endorsements, Reference Values Values, and Verification Key Material</name>
        <t><xref target="PSA-Endorsements"/>
<!-- [rfced] Should "verification key material to the Verifier" be rewritten
as follows for clarity?

Original:
   [PSA-Endorsements] defines a protocol based on the <xref target="RATS-CoRIM"/> [RATS-CoRIM] data
   model that can be used to convey PSA Endorsements, Reference Values
   and verification key material to the Verifier.</t>
      </section>
    </section>
    <section anchor="implementation-status">
      <name>Implementation Status</name>
      <t><cref anchor="rfc-ed-note">RFC Editor:</cref> please remove this section before pubblication.</t>
      <t>Implementations of this specification are provided by Verifier.

Perhaps:
   [PSA-Endorsements] defines a protocol based on the Trusted
Firmware-M project <xref target="TF-M"/>, <xref target="IAT-VERIFIER"/>, data model
   described in [RATS-CoRIM] that can be used to convey PSA Endorsements and
   Reference Values, and to verify key material to the Verifier.
-->
        <t><xref target="I-D.fdb-rats-psa-endorsements"/> defines a protocol based on the Veraison project <xref target="Veraison"/>, target="I-D.ietf-rats-corim"/> data model
that can be used to convey PSA Endorsements, Reference Values, and verification
key material to the Xclaim
<xref target="Xclaim"/> library.  All four implementations are released as open-source software.</t> Verifier.</t>
      </section>
    </section>
    <section anchor="security-and-privacy-considerations">
      <name>Security and Privacy Considerations</name>
      <t>This specification re-uses reuses the EAT specification and therefore the CWT specification.
Hence, the security and privacy considerations of those specifications apply here as well.</t>
      <t>Since CWTs offer different ways to protect the token, this specification
profiles those options and allows signatures using public key cryptography as
well as message authentication codes (MACs). COSE_Sign1 is used for digital
signatures and COSE_Mac0 for MACs, MACs as defined in the COSE specification <xref target="STD96"/>.
Note, however, that the use of MAC authentication is NOT RECOMMENDED <bcp14>NOT RECOMMENDED</bcp14> due to the associated
infrastructure costs for key management and protocol complexities.</t>
      <t>A PSA Attester MUST NOT <bcp14>MUST NOT</bcp14> provide Evidence to an untrusted
challenger, as it may allow attackers to interpose and trick the Verifier into
believing the attacker is a legitimate Attester.
This is especially relevant to protocols that use PSA attestation tokens to authenticate the attester to a relying party.</t> Relying Party.</t>
      <t>Attestation tokens contain information that may be unique to a device and
therefore device. Therefore, they may allow to single out an individual device for tracking
purposes.  Deployments that have privacy requirements must take appropriate
measures to ensure that the token is only used to provision anonymous/pseudonym
keys.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="cbor-web-token-claims-registration">
        <name>CBOR Web Token Claims Registration</name>
        <t>IANA is requested to make permanent has registered the following claims that have been
assigned via early allocation
in the "CBOR Web Token (CWT) Claims" registry
<xref target="IANA-CWT"/>.</t> target="CWT"/>.</t>
        <section anchor="client-id-claim">
          <name> Client
          <name>Client ID Claim</name>
          <ul spacing="normal">
            <li>
              <t>Claim Name: psa-client-id</t>
            </li>
            <li>
              <t>Claim Description: PSA
          <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>psa-client-id</dd>
            <dt>Claim Description:</dt><dd>PSA Client ID</t>
            </li>
            <li>
              <t>JWT ID</dd>
            <dt>JWT Claim Name: N/A</t>
            </li>
            <li>
              <t>Claim Key: 2394</t>
            </li>
            <li>
              <t>Claim Name:</dt><dd>N/A</dd>
            <dt>Claim Key:</dt><dd>2394</dd>
            <dt>Claim Value Type(s): signed integer</t>
            </li>
            <li>
              <t>Change Controller: Hannes Tschofenig</t>
            </li>
            <li>
              <t>Specification Document(s): <xref Type(s):</dt><dd>signed integer</dd>
            <dt>Change Controller:</dt><dd>Hannes Tschofenig</dd>
            <dt>Specification Document(s):</dt><dd><xref target="sec-client-id"/> of RFCthis</t>
            </li>
          </ul> RFC 9783</dd>
          </dl>
        </section>
        <section anchor="security-lifecycle-claim">
          <name> Security
          <name>Security Lifecycle Claim</name>
          <ul spacing="normal">
            <li>
              <t>Claim Name: psa-security-lifecycle</t>
            </li>
            <li>
              <t>Claim Description: PSA
          <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>psa-security-lifecycle</dd>
            <dt>Claim Description:</dt><dd>PSA Security Lifecycle</t>
            </li>
            <li>
              <t>JWT Lifecycle</dd>
            <dt>JWT Claim Name: N/A</t>
            </li>
            <li>
              <t>Claim Key: 2395</t>
            </li>
            <li>
              <t>Claim Name:</dt><dd>N/A</dd>
            <dt>Claim Key:</dt><dd>2395</dd>
            <dt>Claim Value Type(s): unsigned integer</t>
            </li>
            <li>
              <t>Change Controller: Hannes Tschofenig</t>
            </li>
            <li>
              <t>Specification Document(s): <xref Type(s):</dt><dd>unsigned integer</dd>
            <dt>Change Controller:</dt><dd>Hannes Tschofenig</dd>
            <dt>Specification Document(s):</dt><dd><xref target="sec-security-lifecycle"/> of RFCthis</t>
            </li>
          </ul> RFC 9783</dd>
          </dl>
        </section>
        <section anchor="implementation-id-claim">
          <name> Implementation
          <name>Implementation ID Claim</name>
          <ul spacing="normal">
            <li>
              <t>Claim Name: psa-implementation-id</t>
            </li>
            <li>
              <t>Claim Description: PSA
	  <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>psa-implementation-id</dd>
            <dt>Claim Description:</dt><dd>PSA Implementation ID</t>
            </li>
            <li>
              <t>JWT ID</dd>
            <dt>JWT Claim Name: N/A</t>
            </li>
            <li>
              <t>Claim Key: 2396</t>
            </li>
            <li>
              <t>Claim Name:</dt><dd>N/A</dd>
            <dt>Claim Key:</dt><dd>2396</dd>
            <dt>Claim Value Type(s): byte string</t>
            </li>
            <li>
              <t>Change Controller: Hannes Tschofenig</t>
            </li>
            <li>
              <t>Specification Document(s): <xref Type(s):</dt><dd>byte string</dd>
            <dt>Change Controller:</dt><dd>Hannes Tschofenig</dd>
            <dt>Specification Document(s):</dt><dd><xref target="sec-implementation-id"/> of RFCthis</t>
            </li>
          </ul> RFC 9783</dd>
          </dl>
        </section>
        <section anchor="certification-reference-claim">
          <name> Certification
          <name>Certification Reference Claim</name>
          <ul spacing="normal">
            <li>
              <t>Claim Name: psa-certification-reference</t>
            </li>
            <li>
              <t>Claim Description: PSA
	  <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>psa-certification-reference</dd>
            <dt>Claim Description:</dt><dd>PSA Certification Reference</t>
            </li>
            <li>
              <t>JWT Reference</dd>
            <dt>JWT Claim Name: N/A</t>
            </li>
            <li>
              <t>Claim Key: 2398</t>
            </li>
            <li>
              <t>Claim Name:</dt><dd>N/A</dd>
            <dt>Claim Key:</dt><dd>2398</dd>
            <dt>Claim Value Type(s): text string</t>
            </li>
            <li>
              <t>Change Controller: Hannes Tschofenig</t>
            </li>
            <li>
              <t>Specification Document(s): <xref Type(s):</dt><dd>text string</dd>
            <dt>Change Controller:</dt><dd>Hannes Tschofenig</dd>
            <dt>Specification Document(s):</dt><dd><xref target="sec-certification-reference"/> of RFCthis</t>
            </li>
          </ul> RFC 9783</dd>
          </dl>
        </section>
        <section anchor="software-components-claim">
          <name> Software
          <name>Software Components Claim</name>
          <ul spacing="normal">
            <li>
              <t>Claim Name: psa-software-components</t>
            </li>
            <li>
              <t>Claim Description: PSA
	  <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>psa-software-components</dd>
            <dt>Claim Description:</dt><dd>PSA Software Components</t>
            </li>
            <li>
              <t>JWT Components</dd>
            <dt>JWT Claim Name: N/A</t>
            </li>
            <li>
              <t>Claim Key: 2399</t>
            </li>
            <li>
              <t>Claim Name:</dt><dd>N/A</dd>
            <dt>Claim Key:</dt><dd>2399</dd>
            <dt>Claim Value Type(s): array</t>
            </li>
            <li>
              <t>Change Controller: Hannes Tschofenig</t>
            </li>
            <li>
              <t>Specification Document(s): <xref Type(s):</dt><dd>array</dd>
            <dt>Change Controller:</dt><dd>Hannes Tschofenig</dd>
            <dt>Specification Document(s):</dt><dd><xref target="sec-sw-components"/> of RFCthis</t>
            </li>
          </ul> RFC 9783</dd>
          </dl>
        </section>
        <section anchor="verification-service-indicator-claim">
          <name> Verification
          <name>Verification Service Indicator Claim</name>
          <ul spacing="normal">
            <li>
              <t>Claim Name: psa-verification-service-indicator</t>
            </li>
            <li>
              <t>Claim Description: PSA
	  <dl spacing="compact" newline="false">
            <dt>Claim Name:</dt><dd>psa-verification-service-indicator</dd>
            <dt>Claim Description:</dt><dd>PSA Verification Service Indicator</t>
            </li>
            <li>
              <t>JWT Indicator</dd>
            <dt>JWT Claim Name: N/A</t>
            </li>
            <li>
              <t>Claim Key: 2400</t>
            </li>
            <li>
              <t>Claim Name:</dt><dd>N/A</dd>
            <dt>Claim Key:</dt><dd>2400</dd>
            <dt>Claim Value Type(s): text string</t>
            </li>
            <li>
              <t>Change Controller: Hannes Tschofenig</t>
            </li>
            <li>
              <t>Specification Document(s): <xref Type(s):</dt><dd>text string</dd>
            <dt>Change Controller:</dt><dd>Hannes Tschofenig</dd>
            <dt>Specification Document(s):</dt><dd><xref target="sec-verification-service-indicator"/> of RFCthis</t>
            </li>
          </ul> RFC 9783</dd>
          </dl>
        </section>
      </section>
      <section anchor="sec-iana-media-types">
        <name>Media Types</name>
        <t>No
        <t>This document does not register any new media type registration is requested. types.
To indicate that the transmitted content is a PSA attestation token,
applications can use the <tt>application/eat+cwt</tt> media type defined in
<xref target="EAT-MEDIATYPES"/> target="RFC9782"/> with the <tt>eat_profile</tt> parameter set to
<tt>tag:psacertified.org,2023:psa#tfm</tt> (or <tt>tag:psacertified.org,2019:psa#legacy</tt> if the token is encoded
according to the old profile, profile; see <xref target="sec-backwards-compat"/>).</t>
      </section>
      <section anchor="sec-iana-coap-content-format">
        <name>CoAP Content-Formats Registration</name>

        <t>IANA is requested to register has registered two CoAP Content-Format IDs in the First Come First Served range of the "CoAP
Content-Formats" registry <xref target="IANA-CoAP-Content-Formats"/>:</t> target="Content-Formats"/>:</t>
        <ul spacing="normal">
          <li>
            <t>One
          <li>One for the <tt>application/eat+cwt</tt> media type with the <tt>eat_profile</tt> parameter
	  equal to <tt>tag:psacertified.org,2023:psa#tfm</tt></t>
          </li>
          <li>
            <t>Another <tt>tag:psacertified.org,2023:psa#tfm</tt>.</li>
          <li>Another for the <tt>application/eat+cwt</tt> media type with the <tt>eat_profile</tt>
	  parameter equal to <tt>tag:psacertified.org,2019:psa#legacy</tt></t>
          </li> <tt>tag:psacertified.org,2019:psa#legacy</tt>.</li>
        </ul>
        <t>The Content-Formats should be allocated from the First Come First Served range (10000-64999).</t>

        <section anchor="registry-contents">
          <name>Registry Contents</name>
          <ul spacing="normal">
            <li>
              <t>Media Type: <tt>application/eat+cwt; eat_profile="tag:psacertified.org,2023:psa#tfm"</tt></t>
            </li>
            <li>
              <t>Encoding: -</t>
            </li>
            <li>
              <t>Id: [[To-be-assigned by IANA]]</t>
            </li>
            <li>
              <t>Reference: RFCthis</t>
            </li>
            <li>
              <t>Media Type: <tt>application/eat+cwt; eat_profile="tag:psacertified.org,2019:psa#legacy"</tt></t>
            </li>
            <li>
              <t>Encoding: -</t>
            </li>
            <li>
              <t>Id: [[To-be-assigned by IANA]]</t>
            </li>
            <li>
              <t>Reference: RFCthis</t>
            </li>
          </ul>

	  <dl spacing="compact" newline="false">
            <dt>Media Type:</dt><dd><tt>application/eat+cwt; eat_profile="tag:psacertified.org,2023:psa#tfm"</tt></dd>
            <dt>Encoding:</dt><dd>-</dd>
            <dt>ID:</dt><dd>10003</dd>
            <dt>Reference:</dt><dd>RFC 9783</dd>
	  </dl>
<dl spacing="compact" newline="false">
            <dt>Media Type:</dt><dd><tt>application/eat+cwt; eat_profile="tag:psacertified.org,2019:psa#legacy"</tt></dd>
            <dt>Encoding:</dt><dd>-</dd>
            <dt>ID:</dt><dd>10004</dd>
            <dt>Reference:</dt><dd>RFC 9783</dd>
          </dl>
        </section>
      </section>
    </section>
  </middle>
<back>

<!-- [rfced] Reference-related questions:

a) The following reference appears to be a code repository that was last updated in August 2023.  "iat-verifier" only appears on the page as a link; is the goal to point readers to the iat-verifier tree?  Please review.

Currently, we have updated the document as described below to follow the RFC style guidance (see https://www.rfc-editor.org/styleguide/part2/#ref_repo).  We may make more updates depending on the answer to the question above.

Original:
   [IAT-VERIFIER]
              Linaro, "iat-verifier", 2023,
              <https://git.trustedfirmware.org/TF-M/tf-m-tools.git/tree/
              iat-verifier>.

Current:
[IAT-VERIFIER]
    Trusted Firmware, "iat-verifier", commit: 0b49b00195b7733d6fe74e8f42ed4d7b81242801, 18 August 2023, <https://git.trustedfirmware.org/TF-M/tf-m-tools.git/tree/iat-verifier>.

b) Please review the following reference. The URL provided for [PSA] redirects
to the following link: https://www.arm.com/architecture/security-features. We
found
https://developer.arm.com/documentation/101892/0100/Security-Platform-Security-Architecture?lang=en
(please note that the actual URL contains three hyphens between "/Security"
and "Platform", but XML comments break when more than two hyphens appear
consecutively in a URL). If there are no objections, we will update the reference as follows.

Original:
   [PSA]      Arm, "Platform Security Architecture Resources", 2022,
              <https://developer.arm.com/architectures/security-
              architectures/platform-security-architecture/
              documentation>.

Perhaps:
   [PSA]      Arm, "Security - Platform Security Architecture",
              <https://developer.arm.com/architectures/security-
              architectures/platform-security-architecture/
              documentation>.

c) Note that we have updated the title of the following reference, as the
title of the webpage appears to have changed since 2022.  If another page is preferred, please let us know.

Original:
   [PSACertified]
              PSA Certified, "PSA Certified IoT Security Framework",
              2022, <https://psacertified.org>.

Current:
   [PSACertified]
              PSA Certified, "Expert IoT Security Framework and Certification",
              <https://psacertified.org>.

d) It appears as though the goal is to refer to the most recent I-D prior to deprecation of the "private use range" values.  As such, we have updated the reference to refer to version -08.  Please review and let us know if any updates are needed.

Original:
   [PSA-OLD]  Tschofenig, H., Frost, S., Brossard, M., Shaw, A. L., and
              T. Fossati, "Arm's Platform Security Architecture (PSA)
              Attestation Token", Work in Progress, Internet-Draft,
              draft-tschofenig-rats-psa-token-07, 1 February 2021,
              <https://datatracker.ietf.org/doc/html/draft-tschofenig-
              rats-psa-token-07>.
-->

    <displayreference target="I-D.fdb-rats-psa-endorsements" to="PSA-Endorsements"/>
    <displayreference target="I-D.ietf-rats-ar4si" to="RATS-AR4SI"/>
    <displayreference target="I-D.ietf-rats-corim" to="RATS-CoRIM"/>
    <displayreference target="I-D.ietf-uta-tls13-iot-profile" to="TLS13-IoT"/>
    <displayreference target="I-D.tschofenig-rats-psa-token" to="PSA-OLD"/>
    <displayreference target="RFC5280" to="X509"/>
    <displayreference target="RFC7925" to="TLS12-IoT"/>
    <displayreference target="RFC9053" to="COSE-ALGS"/>
    <displayreference target="RFC9360" to="COSE-X509"/>
<displayreference target="RFC9711" to="EAT"/>
<displayreference target="RFC9782" to="EAT-MEDIATYPES"/>
<displayreference target="I-D.mandyam-rats-qwestoken" to="RATS-QWESTOKEN"/>
<displayreference target="I-D.kdyxy-rats-tdx-eat-profile" to="RATS-TDX"/>

    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>

        <reference anchor="PSA-SM" target="https://www.psacertified.org/app/uploads/2021/12/JSADEN014_PSA_Certified_SM_V1.1_BET0.pdf">
          <front>
            <title>Platform Security Model 1.1</title>
            <author>
              <organization>Arm</organization>
            </author>
            <date year="2021" month="December"/>
          </front>
        </reference>

        <reference anchor="EAN-13" target="https://www.gs1.org/standards/barcodes/ean-upc">
          <front>
            <title>International Article Number - EAN/UPC
            <title>EAN/UPC barcodes</title>
            <author>
              <organization>GS1</organization>
            </author>
            <date year="2019"/>
          </front>
        </reference>

        <reference anchor="PSA-FF" target="https://developer.arm.com/documentation/den0063/a">
          <front>
            <title>Platform Security Architecture
            <title>Arm PSA Firmware Framework 1.0 (PSA-FF)</title> 1.0</title>
            <author>
              <organization>Arm</organization>
            </author>
            <date year="2019" month="February"/>
          </front>
        </reference>

        <reference anchor="PSA-Cert-Guide" target="https://www.psacertified.org/app/uploads/2020/07/JSADEN011-PSA_Certified_Level_2_Step-by-Step-1.1-20200403.pdf">
          <front>
            <title>PSA Certified Level 2 Step by Step Guide Version 1.1</title>
            <author>
              <organization>PSA Certified</organization>
            </author>
            <date month="April" year="2020"/>
          </front>
        </reference>
        <reference anchor="STD94">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="December" year="2020"/>
            <abstract>
              <t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.094.xml"/>

<!-- [rfced] We have updated the possibility reference for [STD96] to include entries for both of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
              <t>This document obsoletes RFC 7049, providing editorial improvements, new details, RFCs (9052 and errata fixes while keeping full compatibility with 9338) that comprise the interchange format of STD.  Please review consider whether the text should specifically refer to RFC 7049. It does not create a new version of 9052 only or if the format.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="94"/>
          <seriesInfo name="RFC" value="8949"/>
          <seriesInfo name="DOI" value="10.17487/RFC8949"/>
        </reference>
        <reference anchor="STD96">
          <front>
            <title>CBOR current update is acceptable.

Original:
   COSE_Sign1 is used for digital signatures and COSE_Mac0 for
   MACs, as defined in the COSE specification [STD96].

   [STD96]    Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>Concise Binary Object Representation (CBOR) Process", STD 96, RFC 9052,
              DOI 10.17487/RFC9052, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9052>.

Current:
   COSE_Sign1 is a data format designed used for small code size digital signatures and small message size. There is a need to be able to define basic security services COSE_Mac0 for
   MACs as defined in the COSE specification [STD96].

   [STD96]    Internet Standard 96,
              <https://www.rfc-editor.org/info/std96>.
              At the time of writing, this data format. This document defines STD comprises the CBOR following:

              Schaad, J., "CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, (COSE):
              Structures and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.</t>
              <t>This document, along with RFC 9053, obsoletes Process", STD 96, RFC 8152.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="96"/>
          <seriesInfo name="RFC" value="9052"/>
          <seriesInfo name="DOI" value="10.17487/RFC9052"/>
        </reference>
        <reference anchor="COSE-ALGS">
          <front>
            <title>CBOR 9052,
              DOI 10.17487/RFC9052, August 2022,
              <https://www.rfc-editor.org/info/rfc9052>.

              Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>Concise Binary Object Representation (CBOR)
              Countersignatures", STD 96, RFC 9338,
              DOI 10.17487/RFC9338, December 2022,
              <https://www.rfc-editor.org/info/rfc9338>.

Perhaps:
   COSE_Sign1 is a data format designed used for small code size digital signatures and small message size. There is a need to be able to define basic security services COSE_Mac0 for this data format. This document defines a set of algorithms that can be used with
   MACs as defined in the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052).</t>
              <t>This document, along with RFC 9052, obsoletes RFC 8152.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9053"/>
          <seriesInfo name="DOI" value="10.17487/RFC9053"/>
        </reference> COSE specification [RFC9052].
-->

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.096.xml"/>

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

        <reference anchor="IANA-CWT" target="https://www.iana.org/assignments/cwt/cwt.xhtml#claims-registry"> anchor="CWT" target="https://www.iana.org/assignments/cwt">
          <front>
            <title>CBOR Web Token (CWT) Claims</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date year="2022"/>
          </front>
        </reference>

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

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

<reference anchor="X509"> anchor="RFC9782" target="https://www.rfc-editor.org/info/rfc9782">

     <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper"/>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <date month="May" year="2008"/>
            <abstract>
              <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="EAT">
          <front>
            <title>The Entity Attestation Token (EAT)</title>
            <author fullname="Laurence Lundblade" initials="L." surname="Lundblade">
              <organization>Security Theory LLC</organization>
            </author>
            <author fullname="Giridhar Mandyam" initials="G." surname="Mandyam">
              <organization>Mediatek USA</organization>
            </author>
            <author fullname="Jeremy O'Donoghue" initials="J." surname="O'Donoghue">
              <organization>Qualcomm Technologies Inc.</organization>
            </author>
            <author fullname="Carl Wallace" initials="C." surname="Wallace">
              <organization>Red Hound Software, Inc.</organization>
            </author>
            <date day="6" month="September" year="2024"/>
            <abstract>
              <t>   An Entity
       <title>Entity Attestation Token (EAT) provides an attested claims set
   that describes state and characteristics of an entity, a device like
   a smartphone, IoT device, network equipment or such.  This claims set
   is used by a relying party, server or service to determine the type
   and degree of trust placed in the entity.

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

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-rats-eat-31"/>
        </reference>
        <reference anchor="EAT-MEDIATYPES">
          <front>
            <title>EAT Media Types</title>

       <author initials="L" surname="Lundblade" fullname="Laurence Lundblade" initials="L." surname="Lundblade">
              <organization>Security Theory LLC</organization> Lundblade">
         <organization />
       </author>
       <author initials="H" surname="Birkholz" fullname="Henk Birkholz" initials="H." surname="Birkholz">
              <organization>Fraunhofer Institute for Secure Information Technology</organization> Birkholz">
         <organization />
       </author>
       <author initials="T" surname="Fossati" fullname="Thomas Fossati" initials="T." surname="Fossati">
              <organization>Linaro</organization> Fossati">
         <organization />
       </author>

       <date day="21" month="August" year="2024"/>
            <abstract>
              <t>   Payloads used in Remote Attestation Procedures may require an
   associated media type for their conveyance, for example when used in
   RESTful APIs.

   This memo defines media types to be used for Entity Attestation
   Tokens (EAT).

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-rats-eat-media-type-09"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8610">
          <front>
            <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
            <author fullname="C. Vigano" initials="C." surname="Vigano"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="June" year="2019"/>
            <abstract>
              <t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
            </abstract> year="2025" />
     </front>
     <seriesInfo name="RFC" value="8610"/> value="9782" />
     <seriesInfo name="DOI" value="10.17487/RFC8610"/> value="10.17487/RFC9782"/>

   </reference>

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

        <reference anchor="IANA.named-information" anchor="NAMED-INFO" target="https://www.iana.org/assignments/named-information">
          <front>
            <title>Named Information</title> Information Hash Algorithm Registry</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="RFC3986">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <date month="January" year="2005"/>
            <abstract>
              <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </reference>
        <reference anchor="RFC4151">
          <front>
            <title>The 'tag' URI Scheme</title>
            <author fullname="T. Kindberg" initials="T." surname="Kindberg"/>
            <author fullname="S. Hawke" initials="S." surname="Hawke"/>
            <date month="October" year="2005"/>
            <abstract>
              <t>This document describes the "tag" Uniform Resource Identifier (URI) scheme. Tag URIs (also known as "tags") are designed to be unique across space and time while being tractable to humans. They are distinct from most other URIs in that they have no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4151"/>
          <seriesInfo name="DOI" value="10.17487/RFC4151"/>
        </reference>
        <reference anchor="RFC8392">
          <front>
            <title>CBOR Web Token (CWT)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/>
            <author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <date month="May" year="2018"/>
            <abstract>
              <t>CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8392"/>
          <seriesInfo name="DOI" value="10.17487/RFC8392"/>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4151.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8392.xml"/>
      </references>
      <references anchor="sec-informative-references">

        <name>Informative References</name>
        <reference anchor="I-D.kdyxy-rats-tdx-eat-profile">
          <front>
            <title>EAT profile for Intel® Trust Domain Extensions (TDX) attestation result</title>
            <author fullname="Greg Kostal" initials="G." surname="Kostal">
              <organization>Microsoft</organization>
            </author>
            <author fullname="Sindhuri Dittakavi" initials="S." surname="Dittakavi">
              <organization>Microsoft</organization>
            </author>
            <author fullname="Raghuram Yeluri" initials="R." surname="Yeluri">
              <organization>Intel</organization>
            </author>
            <author fullname="Haidong Xia" initials="H." surname="Xia">
              <organization>Intel</organization>
            </author>
            <author fullname="Jerry Yu" initials="J." surname="Yu">
              <organization>Intel</organization>
            </author>
            <date day="23" month="April" year="2024"/>
            <abstract>
              <t>   Intel® Trust Domain Extensions (TDX) introduce architectural elements
   designed for the deployment of hardware-isolated virtual machines
   (VMs) known

<!-- [I-D.kdyxy-rats-tdx-eat-profile] IESG State: I-D Exists as trust domains (TDs).  TDX is designed to provide a
   secure and isolated environment for running sensitive workloads or
   applications.  This Entity Attestation Token (EAT) profile outlines
   claims for an Intel TDX attestation result which facilitate the
   establishment of trust between a relying party and the environment.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-kdyxy-rats-tdx-eat-profile-01"/>
        </reference>
        <reference anchor="I-D.mandyam-rats-qwestoken">
          <front>
            <title>The Qualcomm Wireless Edge Services (QWES) Attestation Token</title>
            <author fullname="Giridhar Mandyam" initials="G." surname="Mandyam">
              <organization>Qualcomm Technologies Inc.</organization>
            </author>
            <author fullname="Vivek Sekhar" initials="V." surname="Sekhar">
              <organization>Qualcomm Technologies Inc.</organization>
            </author>
            <author fullname="Shahid Mohammed" initials="S." surname="Mohammed">
              <organization>Qualcomm Technologies Inc.</organization>
            </author>
            <date day="1" month="November" year="2019"/>
            <abstract>
              <t>   An attestation format based on the Entity Attestation Token (EAT) is
   described.  The Qualcomm Wireless Edge Services (QWES) token is used
   in the context of device onboarding and authentication.  It is
   verified in the same manner 01/22/25 -->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.kdyxy-rats-tdx-eat-profile.xml"/>
<!-- [I-D.mandyam-rats-qwestoken] IESG State: Expired as any CBOR Web Token (CWT).

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-mandyam-rats-qwestoken-00"/>
        </reference>
        <reference anchor="TLS12-IoT">
          <front>
            <title>Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things</title>
            <author fullname="H. Tschofenig" initials="H." role="editor" surname="Tschofenig"/>
            <author fullname="T. Fossati" initials="T." surname="Fossati"/>
            <date month="July" year="2016"/>
            <abstract>
              <t>A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.</t>
              <t>This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7925"/>
          <seriesInfo name="DOI" value="10.17487/RFC7925"/>
        </reference>
        <reference anchor="TLS13-IoT">
          <front>
            <title>TLS/DTLS 1.3 Profiles for the Internet of Things</title>
            <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
         </author>
            <author fullname="Thomas Fossati" initials="T." surname="Fossati">
              <organization>Linaro</organization>
            </author>
            <author fullname="Michael Richardson" initials="M." surname="Richardson">
              <organization>Sandelman Software Works</organization>
            </author>
            <date day="3" month="March" year="2024"/>
            <abstract>
              <t>   This document is a companion to RFC 7925 and defines TLS/DTLS 1.3
   profiles for Internet of Things devices.  It also updates RFC 7925
   with regards to the X.509 certificate profile.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/thomas-fossati/draft-tls13-iot.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-uta-tls13-iot-profile-09"/>
        </reference>
        <reference anchor="COSE-X509">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="February" year="2023"/>
            <abstract>
              <t>The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys 01/22/25 -->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.mandyam-rats-qwestoken.xml"/>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7925.xml"/>
<!-- [TLS13-IoT] draft-ietf-uta-tls13-iot-profile-12; IESG State: I-D Exists as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9360"/>
          <seriesInfo name="DOI" value="10.17487/RFC9360"/>
        </reference>
        <reference anchor="RFC9334">
          <front>
            <title>Remote ATtestation procedureS (RATS) Architecture</title>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
            <author fullname="D. Thaler" initials="D." surname="Thaler"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="N. Smith" initials="N." surname="Smith"/>
            <author fullname="W. Pan" initials="W." surname="Pan"/>
            <date month="January" year="2023"/>
            <abstract>
              <t>In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9334"/>
          <seriesInfo name="DOI" value="10.17487/RFC9334"/>
        </reference> 01/22/25 -->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-uta-tls13-iot-profile.xml"/>

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

        <reference anchor="IANA-CoAP-Content-Formats" anchor="Content-Formats" target="https://www.iana.org/assignments/core-parameters">
          <front>
            <title>CoAP Content-Formats</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date year="2022"/>
          </front>
        </reference>

        <reference anchor="TF-M" target="https://www.trustedfirmware.org/projects/tf-m/">
          <front>
            <title>Trusted Firmware-M</title>
            <author>
              <organization>Linaro</organization>
              <organization>Trusted Firmware</organization>
            </author>
            <date year="2022"/>
          </front>
        </reference>

        <reference anchor="IAT-VERIFIER" target="https://git.trustedfirmware.org/TF-M/tf-m-tools.git/tree/iat-verifier">
          <front>
            <title>iat-verifier</title>
            <author>
              <organization>Linaro</organization>
            </author>
            <date year="2023"/>
          </front>
        </reference>
        <reference anchor="Veraison" target="https://github.com/veraison/psatoken">
          <front>
            <title>Veraison psatoken package</title>
            <author>
              <organization>The Veraison Project</organization>
            </author>
            <date year="2022"/>
          </front>
        </reference>
        <reference anchor="Xclaim" target="https://github.com/laurencelundblade/xclaim">
          <front>
            <title>Xclaim</title>
            <author initials="L." surname="Lundblade" fullname="Laurence Lundblade">
              <organization/>
              <organization>Trusted Firmware</organization>
            </author>
<date year="2022"/> year="2023" month="August" day="18"/>
          </front>
<refcontent>commit: 0b49b00195b7733d6fe74e8f42ed4d7b81242801</refcontent>
        </reference>

        <reference anchor="PSA" target="https://developer.arm.com/architectures/security-architectures/platform-security-architecture/documentation">
          <front>
            <title>Platform Security Architecture Resources</title>
            <author>
              <organization>Arm</organization>
            </author>
            <date year="2022"/>
          </front>
        </reference>

        <reference anchor="PSACertified" target="https://psacertified.org">
          <front>
            <title>PSA Certified IoT Security Framework</title>
            <author>
              <organization>PSA Certified</organization>
            </author>
            <date year="2022"/>
          </front>
        </reference>

        <reference anchor="PSA-API" target="https://arm-software.github.io/psa-api/attestation/1.0/IHI0085-PSA_Certified_Attestation_API-1.0.3.pdf">
          <front>
            <title>PSA Certified Attestation API 1.0.3</title> 1.0</title>
            <author>
              <organization>Arm</organization>
            </author>
            <date month="October" year="2022"/>
          </front>
        </reference>
<!-- [PSA-Endorsements] draft-fdb-rats-psa-endorsements-05 -->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.fdb-rats-psa-endorsements.xml"/>
<!-- [RATS-CoRIM] draft-ietf-rats-corim-06; IESG State: I-D Exists -->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rats-corim.xml"/>
<!-- [RATS-AR4SI] draft-ietf-rats-ar4si-07; IESG State: I-D Exists -->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rats-ar4si.xml"/>

<!--	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.tschofenig-rats-psa-token.xml"/
>-->

<reference anchor="PSA-Endorsements">
          <front>
            <title>Arm's Platform Security Architecture (PSA) Attestation Verifier Endorsements</title>
            <author fullname="Thomas Fossati" initials="T." surname="Fossati">
              <organization>Linaro</organization>
            </author>
            <author fullname="Yogesh Deshpande" initials="Y." surname="Deshpande">
              <organization>Arm Ltd</organization>
            </author>
            <author fullname="Henk Birkholz" initials="H." surname="Birkholz">
              <organization>Fraunhofer SIT</organization>
            </author>
            <date day="30" month="August" year="2024"/>
            <abstract>
              <t>   PSA Endorsements include reference values, cryptographic key material
   and certification status information that a Verifier needs in order
   to appraise attestation Evidence produced by a PSA device.  This memo
   defines such PSA Endorsements as a profile of the CoRIM data model.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-fdb-rats-psa-endorsements-05"/>
        </reference>
        <reference anchor="RATS-CoRIM">
          <front>
            <title>Concise Reference Integrity Manifest</title>
            <author fullname="Henk Birkholz" initials="H." surname="Birkholz">
              <organization>Fraunhofer SIT</organization>
            </author>
            <author fullname="Thomas Fossati" initials="T." surname="Fossati">
              <organization>Linaro</organization>
            </author>
            <author fullname="Yogesh Deshpande" initials="Y." surname="Deshpande">
              <organization>arm</organization>
            </author>
            <author fullname="Ned Smith" initials="N." surname="Smith">
              <organization>Intel</organization>
            </author>
            <author fullname="Wei Pan" initials="W." surname="Pan">
              <organization>Huawei Technologies</organization>
            </author>
            <date day="8" month="July" year="2024"/>
            <abstract>
              <t>   Remote Attestation Procedures (RATS) enable Relying Parties to assess
   the trustworthiness of a remote Attester and therefore to decide
   whether to engage in secure interactions with it - or not.  Evidence
   about trustworthiness can be rather complex and it is deemed
   unrealistic that every Relying Party is capable of the appraisal of
   Evidence.  Therefore that burden is typically offloaded to a
   Verifier.  In order to conduct Evidence appraisal, a Verifier
   requires not only fresh Evidence from an Attester, but also trusted
   Endorsements and Reference Values from Endorsers and Reference Value
   Providers, such as manufacturers, distributors, or device owners.
   This document specifies the information elements for representing
   Endorsements and Reference Values in CBOR format.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-rats-corim-05"/>
        </reference>
        <reference anchor="RATS-AR4SI">
          <front>
            <title>Attestation Results for Secure Interactions</title>
            <author fullname="Eric Voit" initials="E." surname="Voit">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Henk Birkholz" initials="H." surname="Birkholz">
              <organization>Fraunhofer SIT</organization>
            </author>
            <author fullname="Thomas Hardjono" initials="T." surname="Hardjono">
              <organization>MIT</organization>
            </author>
            <author fullname="Thomas Fossati" initials="T." surname="Fossati">
              <organization>Linaro</organization>
            </author>
            <author fullname="Vincent Scarlata" initials="V." surname="Scarlata">
              <organization>Intel</organization>
            </author>
            <date day="2" month="September" year="2024"/>
            <abstract>
              <t>   This document defines reusable Attestation Result information
   elements.  When these elements are offered to Relying Parties as
   Evidence, different aspects of Attester trustworthiness can be
   evaluated.  Additionally, where the Relying Party is interfacing with
   a heterogeneous mix of Attesting Environment and Verifier types,
   consistent policies can be applied to subsequent information exchange
   between each Attester and the Relying Party.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-rats-ar4si-07"/>
        </reference>
        <reference anchor="PSA-OLD"> anchor="I-D.tschofenig-rats-psa-token" target="https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-08">
<front>
            <title>Arm's
<title>
Arm's Platform Security Architecture (PSA) Attestation Token</title> Token
</title>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
              <organization>Arm Limited</organization>
            </author> surname="Tschofenig"/>
<author fullname="Simon Frost" initials="S." surname="Frost">
              <organization>Arm Limited</organization>
            </author> surname="Frost"/>
<author fullname="Mathias Brossard" initials="M." surname="Brossard">
              <organization>Arm Limited</organization>
            </author> surname="Brossard"/>
<author fullname="Adrian L. Shaw" initials="A. L." surname="Shaw">
              <organization>Arm Limited</organization>
            </author> surname="Shaw" />
<author fullname="Thomas Fossati" initials="T." surname="Fossati">
              <organization>Arm Limited</organization>
            </author> surname="Fossati" />
<date day="1" month="February" year="2021"/>
            <abstract>
              <t>   The Platform Security Architecture (PSA) is a family of hardware and
   firmware security specifications, as well as open-source reference
   implementations, to help device makers and chip manufacturers build
   best-practice security into products.  Devices that are PSA compliant
   are able to produce attestation tokens as described in this memo,
   which are the basis for a number of different protocols, including
   secure provisioning and network access control.  This document
   specifies the PSA attestation token structure and semantics.

   At its core, the CWT (COSE Web Token) format is used and populated
   with a set of claims in a way similar to EAT (Entity Attestation
   Token).  This specification describes what claims are used by PSA
   compliant systems.

              </t>
            </abstract>
          </front> day="24" month="March" year="2021"/></front>
<seriesInfo name="Internet-Draft" value="draft-tschofenig-rats-psa-token-07"/> value="draft-tschofenig-rats-psa-token-08"/>
</reference>

      </references>
    </references>
    <?line 1297?>

<section anchor="examples">
      <name>Examples</name>
      <t>The following examples show PSA attestation tokens for an hypothetical system
comprising a single measured software component.
The attesting device is in a lifecycle state (<xref target="sec-security-lifecycle"/>) of
SECURED.  The attestation has been requested from a client residing in the
SPE.</t>
      <t>The example in <xref target="ex-sign1"/> illustrates the case where the IAK is an asymmetric key.  A COSE Sign1 envelope is used to wrap the PSA claims-set.</t>
      <t><xref target="ex-mac0"/> illustrates the case where the IAK is a symmetric key and a COSE Mac0 envelope is used instead.</t>
      <t>The claims sets are identical, except for the Instance ID which is synthesized from the key material.</t>
      <t>The examples have been created using the <tt>iat-verifier</tt> tool <xref target="IAT-VERIFIER"/>.</t>
      <section anchor="ex-sign1">
        <name>COSE Sign1 Token</name>

        <artwork><![CDATA[
{
  / ueid /                     256: h'01020202020202020202020202
0202020202020202020202020202020202020202',
  / psa-implementation-id /   2396: h'00000000000000000000000000
00000000000000000000000000000000000000',
  / eat_nonce /                 10: h'01010101010101010101010101
01010101010101010101010101010101010101',
  / psa-client-id /           2394: 2147483647,
  / psa-security-lifecycle /  2395: 12288,
  / eat_profile /              265: "tag:psacertified.org,2023:psa#tfm",
  / bootseed /                 268: h'0000000000000000',
  / psa-software-components / 2399: [
    {
      / signer ID /         5: h'0404040404040404040404040404040
404040404040404040404040404040404',
      / measurement value / 2: h'0303030303030303030303030303030
303030303030303030303030303030303',
      / measurement type /  1: "PRoT"
    }
  ]
}
]]></artwork>
}]]></artwork>

        <t>The JWK representation of the IAK used for creating the COSE Sign1 signature
over the PSA token is:</t>

        <artwork><![CDATA[
{
  "kty": "EC",
  "crv": "P-256",
  "alg": "ES256",
  "x": "Tl4iCZ47zrRbRG0TVf0dw7VFlHtv18HInYhnmMNybo8",
  "y": "gNcLhAslaqw0pi7eEEM2TwRAlfADR0uR4Bggkq-xPy4",
  "d": "Q__-y5X4CFp8QOHT6nkL7063jN131YUDpkwWAPkbM-c"
}
]]></artwork>
}]]></artwork>

        <t>The resulting COSE object is:</t>
        <artwork><![CDATA[
18([
  h'A10126',
  {},
  h'A81901005821010202020202020202020202020202020202020202020202
02020202020202020219095C5820000000000000000000000000000000000000
00000000000000000000000000000A5820010101010101010101010101010101
010101010101010101010101010101010119095A1A7FFFFFFF19095B19300019
010978217461673A7073616365727469666965642E6F72672C323032333A7073
612374666D19010C48000000000000000019095F81A305582004040404040404
0404040404040404040404040404040404040404040404040402582003030303
0303030303030303030303030303030303030303030303030303030301645052
6F54',
  h'786E937A4C42667AF3847399319CA95C7E7DBABDC9B50FDB8DE3F6BFF4AB
82FF80C42140E2A488000219E3E10663193DA69C75F52B798EA10B2F7041A90E
8E5A'
])
]]></artwork>
])]]></artwork>

        <t>which has the following base16 encoding:</t>

        <artwork><![CDATA[
d28443a10126a0590100a819010058210102020202020202020202020202
0202020202020202020202020202020202020219095c5820000000000000
00000000000000000000000000000000000000000000000000000a582001
010101010101010101010101010101010101010101010101010101010101
0119095a1a7fffffff19095b19300019010978217461673a707361636572
7469666965642e6f72672c323032333a7073612374666d19010c48000000
000000000019095f81a30558200404040404040404040404040404040404
040404040404040404040404040404025820030303030303030303030303
0303030303030303030303030303030303030303016450526f545840786e
937a4c42667af3847399319ca95c7e7dbabdc9b50fdb8de3f6bff4ab82ff
80c42140e2a488000219e3e10663193da69c75f52b798ea10b2f7041a90e
8e5a
]]></artwork>
8e5a]]></artwork>

      </section>
      <section anchor="ex-mac0">
        <name>COSE Mac0 Token</name>

        <artwork><![CDATA[
{
  / ueid /                     256: h'01C557BD4FADC83F756FCA2CD5
EA2DCC8B82159BB4E7453D6A744D4EECD6D0AC60',
  / psa-implementation-id /   2396: h'00000000000000000000000000
00000000000000000000000000000000000000',
  / eat_nonce /                 10: h'01010101010101010101010101
01010101010101010101010101010101010101',
  / psa-client-id /           2394: 2147483647,
  / psa-security-lifecycle /  2395: 12288,
  / eat_profile /              265: "tag:psacertified.org,2023:psa#tfm",
  / psa-boot-seed /            268: h'0000000000000000',
  / psa-software-components / 2399: [
    {
      / signer ID /         5: h'0404040404040404040404040404040
404040404040404040404040404040404',
      / measurement value / 2: h'0303030303030303030303030303030
303030303030303030303030303030303',
      / measurement type /  1: "PRoT"
    }
  ]
}
]]></artwork>
}]]></artwork>

        <t>The JWK representation of the IAK used for creating the COSE Mac0 signature
over the PSA token is:</t>

        <artwork><![CDATA[
========== NOTE: '\\' line wrapping per RFC 8792 ==========

{
  "kty": "oct",
  "alg": "HS256",
  "k": "3gOLNKyhJXaMXjNXq40Gs2e5qw1-i-Ek7cpH_gM6W7epPTB_8imqNv8k\
       \bBKVlk-s9xq3qm7E_WECt7OYMlWtkg"
}
]]></artwork>
}]]></artwork>

        <t>The resulting COSE object is:</t>

        <artwork><![CDATA[
17([
  h'A10105',
  {},
  h'A8190100582101C557BD4FADC83F756FCA2CD5EA2DCC8B82159BB4E7453D
6A744D4EECD6D0AC6019095C5820000000000000000000000000000000000000
00000000000000000000000000000A5820010101010101010101010101010101
010101010101010101010101010101010119095A1A7FFFFFFF19095B19300019
010978217461673A7073616365727469666965642E6F72672C323032333A7073
612374666D19010C48000000000000000019095F81A305582004040404040404
0404040404040404040404040404040404040404040404040402582003030303
0303030303030303030303030303030303030303030303030303030301645052
6F54',
  h'CF88D330E7A5366A95CF744A4DBF0D50304D405EDD8B2530E243EDDBD317
7820'
])
]]></artwork>
])]]></artwork>

        <t>which has the following base16 encoding:</t>
        <artwork><![CDATA[
d18443a10105a0590100a8190100582101c557bd4fadc83f756fca2cd5ea
2dcc8b82159bb4e7453d6a744d4eecd6d0ac6019095c5820000000000000
00000000000000000000000000000000000000000000000000000a582001
010101010101010101010101010101010101010101010101010101010101
0119095a1a7fffffff19095b19300019010978217461673a707361636572
7469666965642e6f72672c323032333a7073612374666d19010c48000000
000000000019095f81a30558200404040404040404040404040404040404
040404040404040404040404040404025820030303030303030303030303
0303030303030303030303030303030303030303016450526f545820cf88
d330e7a5366a95cf744a4dbf0d50304d405edd8b2530e243eddbd3177820
]]></artwork>
d330e7a5366a95cf744a4dbf0d50304d405edd8b2530e243eddbd3177820]]></artwork>

      </section>
    </section>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Thank you Carsten Bormann <contact fullname="Carsten Bormann"/> for help with the
      CDDL.  Thanks to
Nicholas Wood,
Eliot Lear,
Yaron Sheffer,
Kathleen Moriarty <contact fullname="Nicholas Wood"/>, <contact
      fullname="Eliot Lear"/>, <contact fullname="Yaron Sheffer"/>, <contact
      fullname="Kathleen Moriarty"/>, and
Ned Smith <contact fullname="Ned Smith"/> for
      ideas, comments comments, and suggestions.</t>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
      <name>Contributors</name>
      <contact initials="L." surname="Lundblade" fullname="Laurence Lundblade">
        <organization>Security Theory LLC</organization>
        <address>
          <email>lgl@securitytheory.com</email>
        </address>
      </contact>
      <contact initials="T." surname="Ban" fullname="Tamas Ban">
        <organization>Arm Limited</organization>
        <address>
          <email>Tamas.Ban@arm.com</email>
        </address>
      </contact>
      <contact initials="S." surname="Trofimov" fullname="Sergei Trofimov">
        <organization>Arm Limited</organization>
        <address>
          <email>Sergei.Trofimov@arm.com</email>
        </address>
      </contact>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA+19a1vjRpbwd/0KveR5FpjYxncuu8mOAZNmAjQL5PYm2Ua2
ZdC0LTmSDO3p7v0t81vml73nVjdJBjrJzr6zz8BMGstVpapTp879nKrX697D
gd/xvDzKZ+GBvzFI55uZfzkL8mmSzv3rcLxMo3zlD9LxfZSH43yZhv7W5fVg
2x/keZjlQR4lsX+TvA3jDS8YjdIQBtyABlXfT5JxHMzhPZM0mOb1PBvfJ9Mw
ju7qaZBn9UUW1HNsWYf3Q19vDP/cJenqwI/iaeJly9E8yjIY8Ga1CPHhJFyE
8J8497xokR74ebrM8nazud9se0EaBjCVDe8xSd/epclyQZ/ehit4MDnwT+M8
TOMwrx/jZDwP5hpP3gSzJIahV2HmeYvowPP9dDoOJ1m+mslj38+TsfVnRBNQ
D7IkzdNwmunPq7nzMU+jsW48TuZz6Ku/zcN3eX0WZXkduo2SGXxRT/7wuecF
y/w+SWE2dd9nCL4K4jjM/BsNQuju+0l6F8TRXwjoB/QknAfRTDVvmOZ/vJu/
a8DqrSGvozls1UmaAORLgwEGzP2zaA5IMLEHpk4N6vTHIJ03YEnWkOdBfh8F
mX8I32dBOnn5uNKzoXpWDD6YpFEQ+9f3wWPFuK8u/bNglNljBtRhlkGHPwbj
eQM6WMPd3CdzmOoJvi+PKkY8i+IgTewBc+rSmHKXP86oAQ3rjZMYtnq0zN1t
OwvgAMXj0D9bxpPRLJiEFS/Sp+7mPgTs98/Ojuy3zu5mf8ykSU4tCoC5CXAh
h0H8cnBTlwZ0qYDzdZjehZF/kyZT2OyHT8AN6thQHfXQXgy0Bbo+hIijQCvq
1+eMrRrPfXkJjU0fhUKVSdN5MglnfqvR4mYBvBMO2H2eL7KDnZ3Hx8cG0JVx
mObRNAonuDs7wWKxs1zMkmCS7bSb7dZOq73zp+vB8fCi2eq+gQm9OVLt31yf
v/kWBn9zOLxpNhaTKb1lAoTpwG+2Gv5xOG74OAY8Hw4u6q3O2pV8dd2yV8L0
hyAYzGCZeTSehf7Fcj4KUwA+DLbzzeWRPwrSMawwW7u6u6xFiyL6BScl21Fd
dsIgri8XY2vK7WZrX2B+cvLrYe6wg5MonT8G+EcK+ILUFnajSVwCXrJdOfFJ
+BDOkkWYNgQpdoA3LJEYEkDg+7jZ7Hd2AmfuDf8kHDXsReA+1b9aRpNw7WKQ
F+ntdJZlf+Gf4Yz8tn+dhwt/tOJ/aWT/2zBFpvObcKy509zVONaquzhG737T
foPvrI9WdfoX3lbHjs1us1NAPHwMH69vjve7vNb6gT8eJSn9/cWBf3VytLff
3Zc2fdMmyUKrzX6z14aPR6+vh/XB2VfX6mEHHp4OLgC8392shSs2sMF5dPj6
yv8uHDGz97eg77Z/NAui+XrcBXIcMLSArd/FxAx3xo85/r/x7j6fzz4b0wj1
NLwDvpiuXCjg7L/vNfdp4r32XpNO4Q1Mrn7ciMJ8yoJFGOT8Rf18eHw6uPnh
cnhd0aY+DycRiCAgXHggUMRTm0xh67eT1bsVN88n76jLAonbTLeYwxlcBXNu
88sjCDEIDPz25uy61a6fJjc01939dk8edvgh9maxiOa0zGEiswy+jRL9FrVX
esn7nT4umf7qECrwtiWDS/gPEJg4r5/QKrKX7yN09gudP3EDkzSsLwKkBkDi
svKW3ZzU1xN8i83KjG5QqoMjqghN/XztfHJuOpWWNDUA3p+BVGU7ANb5Tnk2
gBD1b4dXpyenw6tPmFUEu/8QpniC08r53EV55Xxw9TQXEHZBxmtAux2QGcOd
0oh6mngggQoFUabkuoopgrSgG/mXvGh7wvo7oFWElv4iGL8N7sJ1s79fjog0
P0jHHdWx4hDSMa2aWhSDFHvWKAg8z8hDMmMe9bnpzWSMmRpi553p58wSqO7v
xPOuwixZpuM1bLnM3QKrc7ajpLe6+3gh76xXfu9yyMrFaY7yW5khUCSzcM3W
K9daZHyVE6sPLk9fDPmC7ghdUZ5odCpfHyC4kmlOp0uQIkpwVvVgEe0EZqAd
GGTn9NVps7nXK/Bf63Vv4HV1el2Z56rFDONJkmahqG5IuKeTkVFhQ+trJM6D
m2sgxlen50WWA3SSsJRaDK6616fFFkHazSJ56+uzY/56vdrc3PU8eCtsGgL4
enh2AiovMAdQpbINz6vX6z6oRHkaAGHwkFyg4P4iZT/K/MCfBvNotvKTqX8P
ciaJfMDufEXcPIW2frYIxwDZMUE0q/mgjTyGsxn+C6cirvPZ8UExDvn0R/PF
LNS4DT3yxLsPZwsfTlIE38+Dt8BI6G0wtQV8jpfTgCYIj0fLaDbxR7CFwCjh
KfbQc4liGAtYwGQJLADldRwwA9UtyH1cAaIbnNDFDFhZ7o9BoeTGsDYLCQm+
mQcLALl6DIodHJIIHgNg/Xk4T2r+4300vqcRQScDqT2DbwCsONWVP4mmtNQc
Z5InYyD7Neg/ni0nUXzHkw3xxQ8RSpr4DNcK+jmJ08EYppz5pFMmswYwUHiv
p+iBAjetihdUmjoaHpa8oTgwYCesNhpnDcaD6j606SJ64K7j6ENCr7Jxx98C
8Wq74eHM3P3XEAMkQKCzQEeQWmYMRgB66e3eXRgD30G+D9K4u0vZCpjqHEB4
nzzirLJQjQq0ARYHav4s+gv0zBP82nuM0rBGC5cOK3r9OF0t8uQuDRawd8EM
UBt3B/AeKJnHK9FCIClpGuLwzWI5mkXZPbwkQMS0jVG+MVThDAC5YWNDEChB
GkKuEIyiGQLxEciVzxY3m9A3/FN6Q5wAhvpKrYOPqRcIcuZqO06HNycNPtnz
aDIBEdH7DDVLboV8gvf3JWf8/Xv45+NH3vYszJ846IXzPQI5gvdp7ZGmAQJ9
LD3hGYIisCrYhjlPQdPljx8J1a3D7L4YZvcARy1ESUbvxgjXNq95cB5nfBar
X4XzeWK2co6BLS9nCAkAPZzaWQBKFqkEfjgFgOb4OsTLIMbjN02TuT+HDhGM
hrPOgRHYBz18CGZL5t8yFLCAEJqcXuKZjOCE474B2XhgLiKnVZYPX+N0gngM
nQQ28wAOUDJCYQ+nBTNVRCCKozziycKWAiKijJ7lhqbaNNQirURqoxjwFRjU
gtYLU19DXudhkKHwQnQWQRalvqa2nndO1E9obgyHj7ZMpGI/fAfD0K6E8UOU
Jqw/MG0mYgjKN+BMMEWUAzGDCKoWjjKgyBEtD60dNTh1SIAz+1ivaoq2jpIk
Vx880MpSkHuZJCQw6dQH+oqcEw65Xtp0GdMREkhnZtWe/ooRZbUQ+hG+WyRI
0/L7NFnewWxAzE1TWDa+CFlgfRJOo5ioHhADAH9Y8wj0QEFGQhABpYhKENiZ
1PmzaJQGiCp8jhZACOUQAJAHwFaX+UzGJbxFkcI94+/fi5b48SOuWyh4qHYr
pEMPKhyMgYgeMvUAEsAqPG8KIiDQ/yV09Ye4PXh2AJGXQLBw40g4szezQazK
EM4p/JGB1JzwNKHjYqn3WlF6oIenhLuzkiBIBAKlSaQNNDQP4QGqAhYu4PwQ
quvJATyslSP0SBwJkCvBauGfMbHc2nre6X06H4R3wj84xwtgKAw7RLOQ8IUx
TgbMEMbQ2A8eggiIwszC5Pfvn7Y68IKkWbXpAXbbw1MDUGd+o0URejQOMsGp
kSWluDAIx/dxMkvukOZ43nWEYFXAYrmIVhXMsoQp1Jx3Evgwn3vYogyPMnZi
WlATaETEOpEIBTMvDpljw4CIsEV22WCLqc1AsYe8fDJJ8QgDh8dxRytPpA48
Q/je8B28BU4TUPh3rgikdtReM0sTRB88OrFqmMdg5Qoc+HJAtASxlw7ykzLF
yTKlvZ+EOWw2vDpGiI3DBRweoB2yhBEoj4+KJEwTUGvVsUaQKxbuseHb0Qrl
fFyfA+oRXcBv4LkhDEr+rxnZVQ+BaM58ByaTI3UFCsBUnQmKLaUw8SyJKQ0U
QI6S+IFfzLh1TCCkzyyPvAUJDL1wmb9x/s31zUaN//UvXtPfV8P/+Ob0aniM
f1+/Gpyd6T88aXH96vU3Z8fmL9Pz6PX5+fDimDvDU9955G2cD37Y4LlvvL68
OX19MTjb0KK8plNE1hOEP6Eh7ExOkp7niP+HR5d/+2urC1D/P0Bi2q3WPpxI
/rDX2kV683gfxsJmYsAF/ogCqAc0PAxSkn5BMxqDspoHM9aVMpBSY0Lkhvdv
/4503a/3//1Lj2EH0wG8U+S75l+FsxWi52WQ5sDvvhUDUs2hTVckx9T8G6bQ
Q0OhVTscwnpMc1ZUFH2pvuFcNkVt+N8R2yIkwan5G2k4DoErpxsIQRKx8A97
mkBJiOupuSJdKQxj+EuN3cklsqx2UZOhDd6r8X0Q34VASFcNC14bGcrmMCfs
o3mfpYS4Pf2z6G34GGXw9sfCxDw1a349G+xEuBSSVzET7/2B/0BCzBcbzY2P
3lVyc+Ad+FcgliABIhMn86A5HJU5ySH0jTJu1FxZfBLkAfOV+yBjVPVQiI3G
UQ6IpiQsOfXKsuTXDeGNEz22DyfejA57D2gOykzqz8gpwqwfyBGtdaXZmTt7
IuZLeIxUlSjnMp4nEzYM+f4gRhqMYjb2gOUL8Y+E06OAht6SkM7E1etzpVKj
1gsybuY5pNW3RDAiu+GE5Tc4QukyJoINGxJolUEv0FPAQGZ2OcRduGYZ8TJN
UM8unIQaMn/pApLJwjSy5ByUTD0NTluAJbV9GsnskGsR3QT8uGMpE2CPshNM
Oo/mIRLSHIRCUiX0gKS6yvxrmp8K44JFNMhgj1DSO48siXZBPVD9YS+2hr8s
I1BFcOKAOsq+PtTiuE0Itm6Gw20gnCJIA9meTeDswbTVIzilMxDrNxrbnnch
IL2AUZ4Ba25rdpOEFZnS0mqkzwyMxCtNa5bYLSiimLQlHmudtealYTCrE4iL
0jVSXUuiJmiz9WH2BNSuEDk1yDwHZFcIMgIRubpnAjUE0GmB1QgctHkGVk5n
25hR+BjDBoOkGvrH+KVhqP4Z0JglKDP+1tHx8dm2Yj/9VpNkgM8seyocLZIZ
kBZ9BpAny2EgX9XnJE58BEr1fhrdOd8BIxMFIyvPVsklhqiOQRgndTdPaPNE
xAEZz+eXOEz0/ftrVjb8TqNFtEHzFs/7r//6Lz8Isoc7MRh/2k+jrn8av2qA
D5pF+R9+1QCbZgabv2oA+vnPX9/1k6eNW8mazK9bsbzVAv2n/Xyw9+yD/yvH
0aM0YC4fYB+rhZznlmH+4FEKP87kGtYj++/653om1aN88M+R9FmvVE/kg1KG
ZSbrRjk0HBRf+SU/gW/+DSfhiINPjOJ8+A7/c40cCb+5wg8s4Tw9l0173ZvW
I/tv9bMpo7hPyzv53M8mjbJmcz532xY+yn7Jqm2sc99emEtpaiWsq4JqEVzr
90BBV2aTyNAN65P+nNTdz+qBwboP/jcLdGWhiYE+2jy16jNSApTTnJ0uPZY/
NUKcMQbqz5c6DsAaxdnrzRJCPPl5U49SVmaKoHzq50mse/EPYt1vHYPG8c5C
kDkmBy7RhW++BB0qmOgPjyAuhfIpUebXAqW+sj98h0yUWH6RrbPH9YsNm3tv
oARwU2TpZAFLwxlZk0HgQhtCdHePMvEj+ibC+QgkfdoBkQjQXuDp/mR5IhMM
+g9Bn12vc+K36DZLQLoob7ByWFX3h2myETCLEMlRtFa2TBENLX+OKE1piGYX
6M3SCDmaxLQTT8RqDstjX8KczdxKNVWemnkgIutj4o0TI16iZwDWg25iz/sD
meuJsBtKXVM2cPT45aQEkYxaM4Z1nHYFIECVixpho+bTQBOtK3BYsbyWVWQ0
MLAzA/Q59J+pI2xidPw6N0XLuLwT1HgQ4yhKwIZaFCuTOtqO0pW/pZfEnGK7
AUwC7c1FdKvj6iqkuqgOyCErhB8znPOJmpaOuk1tfH6/OQtPkV1LQnmKxtMn
lENmsK1+9PSQPK5FvmUPX9I2sd/6+TPjut9qivCCtjIjAuDTbR0W+aW03XTg
8hTMNl+6DeuIE2ELDlJBpBg9Lu+DLNzAJqBX38VfbIzxFDMF48NW5UVQAsyW
c/BA+2bdELANlM5tOAzZI8eupeEvS+iNevwcW5Nmjmqu/xAFlV6DgqOipogQ
jkZ+VA6qY+ck0xoatHCQ+ESiu4RdveXFwHhfh3ACTwdfbyOpIo8GkSnsqeIY
DLVacy7F9EBHE8GGlll/Q95HxtGNJyC5wTY+9jD6Mw4DF+uVV0G4ahT6hTaq
+yRDMiP0V5Fo0NjRFEZ2b+V4h1fehZmHryY/r2o7viejwZStHvhHQLvBXoaG
d2Sov4X5Au4qohpMiS+y65+XvEA08yPXjZGNgcozryvGOzT8oTKeZ9UtAB+W
M+1m85eLep7UUTSrmGQwmUQChMr5oimQDLN2S4VUlt+HDIEI79DZitEyF38G
WZbQCaRNC4C3ANRk/hI1XPCDv3YpuF/AWPphncL82GrFt3YIZAXNKDxYS8kL
D8qkXMlVVYPyyGVarmScpxsXWNrTjQtM7cnG/1ZY4OflxmtodBU01hHpRnHk
cjsiNR+K010z3qbiIM+04weVFohSO4s/ffn0ePZ713IboYHrGM6V4g9PMZ2b
NZKaePIAa4CopWi3xJCPLJlTuAZbuefBisRe+AcdaiOMBiOy6HNYkdizjQvV
ccaReLk1wMAjJrzbmjG5cp4djHIao9NuzNblUycABqOij1HWZj66NIqjDGmP
Q4ZaMfWic4dI3HkQA8lOtfwJ/TDSESaj3MJ69K1kwXRr21FB6S1kSSdHwcq2
0eowCh2R4atxa/4iyVD+X2EoC84PSaBlp6ycg9hNlCvYmoa2wSuvAtA25P7o
X10bQFRpF40yJ9Dh/XsMBLeMtJIrYRtnhZB/lGi0TAylJqLOEiHYXalD6qpj
GRowaVKtUEdIw3vkUxSQEwa5rb5hQIIEGWxl29r3J5F4FNoobun372myEsxA
y0FDtGOH9jGr8o61QMxxlAUs2NwOo9GsYQHCysIA/T4Uw22H1cHcyNUOuyDB
T1Ngockj7gq9E08WTpe2K1TBNCb4kiF1QPzMQ/jCYb6nfA//C2iJUS2NLPpL
6Hfa/o7zoLtXeNDv0iDezSMFPRh3t/IoUiADOWFIHUZtuf4KTkP9GmWIratX
19ssr3DkPLvpkiyfRu/82/osGIWzWw0a5OSYvqL2wYpPKHR8G65uqTmKn0ka
3UUxxVByD8S1z/wjOJCAj4Jv8OQzdNeMQ416MX5i5BOyRt/zIPZ+jYM0XSlJ
DAaN70IHx+kbfhvt7hzjhzCoE4SbMLuPMapVMM6Eewqi0nsRDyWWxr+lad36
WzwNjCFoNbfVdAAjTGgKdoutKSdTklCns/AdUAbldjOIsS7epVYhvWVMHuTw
GQwc89oiivqWqAmeMmHYrTYBIJjgIFDAA5zYMKKQkE67BlhGTqN+l1GtAR1e
Y9gARmbFd0B9eU0YREgSKSHeCteO48JeMPfgdaiACk0VcMnq/NDsrNEanpAY
hpeam+JBTxEUfZh4uC/8LeLGvHLCY/+LL33ntHnbfHgQ844AlPCG02ONfWN6
Uo8mgnu6hUxOawxZtQtxaqFdgxxuMPOaFXyqWpK5yFh/RisdAkexusi+HtFb
PsJIozuOpCRoWf3kPSKt44tJNaR4P+zrwdHkIEVgqE91Iy8uLpd3t6lCaxZh
ChqVhA8lyFC1H92I6rjosQITyhahCdEqp2f+7a+snZ6cELlmG5YJgBT3vkYG
/OM+pAhfCSdwYh7EIY7OPonc4tj6IrhrYq8qBHsDbV8kEfpBQUzCBWeLBOki
GuYwwJa1oJhj5gpDNn470mpkq8dwyhUvqLdb3d3uXqff3Ws0Gs1CS6thq9HQ
TXe9Qjtps+41O371sIVh9IlyWyP5k3PlvtEcLiWMnlLwgd4wi+7/7a9aCLQO
YCTPcESbCVhtq4/iMo5+Qcok7zMClVIPbfOBtlwoXr6czWyUJhXcDWhTHOF2
GUYThxG0e31ipwTYq8HFscUWbtaSaSTkK02rcdCnSXWnYwjzjTJV0CPdpPmu
2QLuDjPYlpcaTthp16ntejANvm7YliMTQ1IUL0V0Ii4Gh/FBkXQYoWJ4TWTw
6yjPwtn0dzg6NppUyVAdr9hMozKB2uENxcFsFuHqJg6mOt8YllHqIetk0MCe
a+Aw4prgJzb2r2RHvGg+X+a24tPwB35VyJey02mQAlbNEixgQuPogE9XDyls
q9A6XxLMUtYITZh+w7vGyGA1mJY1iXNVzoqkLgxbQ7Ha4ZYLiqSlUDx0kzg5
Erjjy2cmK8eRuZWxampUphOI0dUsClIgiL0WXFuAmmkejZezoDQFYDnzsOGf
UDAq8buaDOyx+SwP3oYigqVzFqVVcgxnAPkx1VKoeRhPM0Ij3ukxyVfMS+Dw
AwigYW6fld9wLuxQbyReLopVQ7Em4bMWHNRJaHg3SQlhVxwyxy0Mny9TZlbL
ypT8o32Ai6enWhXyqhs7fKk8lMWfqt/jCIHO3l8prdqIhPb3da11KwGxundZ
XZlF8VulMrPmQSkviL2yPZ4TDI5UVawtaNyOkTwk44i0FFhOurLjsp1ZaJwj
F6FCI1vapCQELAeEtmnxH8ZwSnNMZwLMBRQee6BVYbA2CIoHPvoaohS/rk9A
rctJL8KCI+hhsFlN4E9A0PY36hvOc4+N6w+hdH/gqhZs0jD+vUJslltkg9Dn
DKDI0V3VaxfQoNULQAhMHVYOCn0UPuCgU1e09EjGNceLwmzJ+DfSBhwL8Dg8
CZc6LmsU5o8IMqSyxhxjyBIfdh6SXyoifJ0VIoe2uEaw0+MCNRj88OnyZTXm
qpNG1pBGCrrGu4W/8WOzvv/ze9jROv/V+7jhPTWKPoL/7j/1LjmK2kj63LzK
EiSb622DgU4kPIum4Xg1npnDqhO0ZuorZRwtd6qWI6EVpaGYASgq1mJIHrHi
m3v1TYUqF/tKiVNGxEnEholcTDZ4VObBnzFylwbhFEVglZhlhk+Q2VMD8xbM
ssGsvZXlehFznhFUB/Yg5DoSCyd12jw9vzwbng8vbgaYf+AfD09OL4bHm7we
RCht1SwCgEKHXZlBvrDTUDI59hx1QAv46cdW72Dvp58B6+0XFCHMGS9/4On/
9OPuQZO6VE9YYGTCRQqDsYACBGDJNh+hKGh61y3r3BLzCE7YaFXzrMONNIQS
J9i/xyqhpTQrpop5FSDYis5wPTz65grmBxt78fqC6jldvb55czw8/OYrez+z
3yYEV3nE1ocrugGoHyQR3R8ogRO39gZeUwi7dGKLHJ/8E/GkavSnWpwl47eT
5DFe3+ah8NWatRUia02A2KWdzl6MJrXXZS3rqUU5XzmDf6ieXTHmVy2ZZln2
FJVf4oKD/veiLqW5NCq6uI3I3cZeFPZJfu52xS6FGW8Wwxg39fjruhQe/Kf6
4zgcLe+qu6ivyv1f8parcJxg+RjUoPi59aSq50PlMOp56WUlSH9OEGs4DxgT
CqGtWxfA96zJbDNOuBMuve8DWsLrCsMZNh9spJdHxX6b7nzUdm0Wnm1WgaQE
C/PMuyHVzvalF5bFD9XsjtDrk8yjjMK6PulNa5tXHYqK5k+dCToPDqX7EkkY
lsfkMgpwJozru4JGlCIwNx1Pb5Hd2C5eI4qQkJNpTy55lLRQESibFCfnUYpm
w3v/HqR8GbQ+Dxa2yYYV3sUCCFSmpdR17E97cij3g7IkLCHStF/Gb2N4vxIf
m++a8NNo4L/TaaGtsmXU0euEHMz0akmvVrkXfkq55JgmsKZjWzq2yx05KnBi
2nakbafcNgYkVS+a4IkxvbrSq1vulRq0Xte7J7175d4TB59Ml7506WOXQh9p
pNXcNRuxU9FgDfSrmq4HeVVrB85VDdYAt6rpMxCt6lIBxgLUHMOA6WgZBFwA
K3Xjdj2Eb5U3hE/fE3Lkv6IYaKkTpAaAxhdNRFImZWCO0iSOl4wBmCzpcS4Y
nLoPfPQ/lEgDRuIwealISsAonSdXUEVoKzpV482t1alSZiyNsxapbvU4lYJa
xVA2xlWvQ0suFb2r0dFZUJFnFZlpacyn8fa2IGc8P14FUt8WVlhkR8RcXOqv
2EoJb86FDWx8ZOWZYzxDYMJKZ6bA7wwLIAj30U1EOVFZsGjoJdvGGEM2UNtT
5ZAoeNynICZ2wJEKaJzckY5MsfUZR6UyDnEaKwszHcXomCi5xpi/JQ49Mt2i
Q9UyQ27b7hocDRfnumz6e8Z576110viuk2aEdRhXGC0Z3JK3Z52vRnHcPTol
nbby3PxWg47eqSpj6dZeo9Fpb3tuS00QTV/H9+EOaVlfrlXs0SkFmKDVwbHB
qK+PdMC/McI81k0agLa/lDsYIynG7mZOyrmVSCA2FIr5wuR9ySjQLbdGSX6v
c4455flumRIIt1WKgrjBtCeFy5i5yre8gmOYSgXYVEyztvC4Bjt8LRoyYS8p
1shxHg4xqMix2laBY8YVklR8FWajlMHhLTOda5xzme+wVBnOxmeKy9PFhL6J
Z+gwD9+pdH22P03YCMnYOCZrF/vK+QW4R6pihe1toJIRBautXeoH0z6o8gIe
YCw6hnunU6fFg+DpQlcqAA5LfmL0s3j3tclF22bgRdrzEjsxvqrYBGz/PZvf
jJWcDbF6NGNnV3EARArSEIYOy5MXKQAgRxVVkCossawDVR9x9tQronjDJ/IU
BgBmthSh+ddZEdoFMdDBtlAHd0h1czKe6wo9lo/hWzYmS7w9V6yKJXugAKKN
++junksqbDiecAWvykhQORA0U4nnmj2xSkOoFNoaOgB06L2HxuJ/2bKimYno
HPitbSRHaI8mUuU2IZZz4Le3y6E8PJ44Ew78bnEYCqhJ69HkwO+t7W6/C1H5
wO+bcT56a9aTOZJmxfdK5vzR/3xNE/9nyw31mX9uBXnfkGRLOVuFp9aZ3II3
fNGS+pggnKa58umU8hrSZCbl2VCLLNEU4ZeGZtgB5xQyrNiVDuYicmunDBAv
3Dg820BvEUkQnB+FTy+B5NJzs3bHv2tV8sDmg7XN3RjdYrfForoXR0WZrtj4
5rrcNtDVKK6BZpJgw4DJgjnweGSbGRP3wN94c/T64uT0qw0d/7gVNu4aNV6s
+nK7CDfP4U4OAJV4YDZYygtVSQnlPQRihJQdiYUUt0Iv28q/SxIsNhhknHU4
C7EIHhAhrJvmuKFwcCn6mXm0ygzIBdJAIxIh8wNy8xhN8vsaB5n5GZBH8pT5
0/BRJBKsdwGsBev5Ub0zke3QsUzI/re/2nhNdKyM7t+yH83FdyADtoaFFWju
1T6jsoW3bOReBXiiWCUNotSaA0lfLkhitSPflCQQuLW0PPWWdq/vj7BiCpnx
0yS+M157M9G1xvzKk0eHX8r8MxBUzf/C0rt01GmhWba00i6VO9XwfqH7Hrn4
mCjYy1SZQeYFxJlNHTsl8toii6c5gJTqA1kHlI1MH7PSoq6J/GLUBEuA6mNx
YUCb1wXHMAVXb6iAH60qcoPMEEpayMCKIFibSBXoxK1UZJFH35SCqmNUDRre
p4PJcyQ7DSYNH8XsnVlHWbHwYuDZ0oCOZ3RE4Uc6cQx/FkONPCK0iwsc/yas
lHh+U/QWyYHnSLQllnVswurLR9n6srj5wGwt/VIYmIo4kY3i8xfM7gC2+f3c
hIDDBJe5ApLaFexUoiOqmiuN7xnKqh2XVuEYf+MVvu8Cqf41ddhQm7uBDycg
zZmgBWo70HO7kssiNjALAe83aGDK4aRuxTkIAEX4K0RGFpRRU+kPpVCbbbI0
uyXCJ0utEvSgsi63Pcyxk4gwqmmt6qM5yTi2nEuB55wsAXC3Ck7Jm2WAiaMg
6SxP1g2ddansulPYmDF6r7WaaAeN1SVoDMAkzT5qWvjEWLYGCac6t0LSXOE9
TzyJiFsTrKbOKKvcFq2ksS06SnqPZx9dJ9pOD7ilSRCqEt9cnUkk/0prb1w2
UlXNrZzV4PJ0GwMBnDp7JJ6P7xPMqMQSz3dxQoRC6Q0eiv7BQ0Jkk0NQLOSz
pPSnN8AOE/Fe0L4QEPLM4CwdO2EhL5iOEpg5bDzIuN6nrglXUtgWJG+zxAUN
RXZTtgahmF4V6KUEgxp5zHeSmKRawrYSFiRvPZQqFDnCWtkxkJ5vUE/Eonfj
KB0v52yoytgSXJ73CHOiIox596jiA5FHTiSG94lhl/OzY0X0K7EnUzkpoGHn
yxR5Rln1U6HvFCI2w4JfiQooPGA2RUvFTPTIlGdwzxb+kYU2oFQMqyZUDStD
xu1upR0C4mICHZv+WCKnBXoAr/uE2KIuAxj6FEom4kjAZUGj3OSs07SFbJMA
/xissIg+tHnkIE60YlJ2X+mQOIlExGTpvqwZT7kmeZPKJIW0EKuQp3XdDW2E
Qg0vpXivqZtm0uz4q7qJPHdi3ss9hd4x01oX9y7Vku2axERhrLw6y2ZDhjGr
JpyYxpQJN9AsQ1Xxvos9FrZzTI2zi9mK0JjaMqHKBrcKyRZzrG5hG97IxApW
2p5lpaX231ydmjwiJdFY37ti/G0e3B0ULwmp4Z02+PSzfDq/1YTfQMYqNYqb
BK1MzWOqo5vLhQmUdcgx8KjdKbsShl5S4VREfjUsVZAVwzm2ilK1czTlKkOa
jSHLNKrryneSj/Drgoe4DgPZ/QFnsYJORiaJIOdYzpS0PUCnVGWcUYlt3ZhL
zucRl0FmRRFe/BAly0wpIk74dvluBz5mFiNSqxSOs/HstkloogKuNsXIOI6F
2x7cMbggLl3raoIKD45lO9XhO9UHKyudW3dXMCk3BhVYzYo5lIrZFd4jmy46
mZgXWLCgbVTlXnFy0zS440s2uHS0g5qmcGEPoY0Jr539vb7OVZFBjaTLFiI8
xA9JhLwjDlG2C0BzQWfVfRjQIVLfY4UIcsyBPKhWxBfoZGpQdErBekj0WS4A
/+NcUDtiJoAm0iy0nDQyKWPCDmNkKytRWZk+FC9iAKVnlEUc7ZfIceNUMDrs
Vu6x2kOXotAh0aUuSb3IUPpSgdAazMrP8yT63frwNW0PZxl3W70W0wU7ohd4
xv1qgXwlRyFQQ5BXTmGFeJvam/Ng3NTitj8YXoPmAntyB3+rcraiHqC9bQsa
1M8HR9vENDnBQQHZWt5GQD7B8YYoPS44GGrCAjF2cQSM/hlKKQPest5yqGnB
kU0LsEyoRTiMf7FIZ/CgFEnGmmolrHO+PjtG4qR5nHbn3GJ85enrmzeXV69P
Ts+Gb1q3niy0xihhuImEXmsyvbEARCLUxUowWC15Q5Gto+9ulD6m7v7T9zDo
AeUKELxYgq4BmaBZCs8CHiMOzqG2L4rNIXlGDyAX8DyKPI8vo9gACvVy1wvP
nqWWFDtQVcvwifqG6KjmxOsPfn2312zuwR+tJl0xwPm12+TMtrM/pOU+/IGG
MmoaLqMJt6yQZqRDEzv0e9LB4Cr3Mym40hzX3O7sd+nbirBuadbmZj2eZikp
S1p1uFWfWhnHt3zbpZnt8cyUJ1mmtSbxQ3r2eNw9nmSFs0/a9bndPrV7Rtnl
Li0CVxehpuMANKKpMADCXkpztP3/SAwcDiWX9RBWpiHmQfIdAVw9nG36dFY0
ZDaMyo2Y7wSXw+khAyx6qcQjvgUAA9YsAofyNX/8uF1TI18kBjyW1SZTL8IS
43S+QIcBBWSiO67ZANVPeCavRKQzzlmhOzror8977gTXpfp83Gbek1GVc1E/
cqAZWaSq+WnBVuWile7qMndmsQvQuhuARXZdkd7DO7cWufI7V5qoyNI4m+it
3KoghdvW5WfqLoUKMde9fWDrBULzdg2N6DPYLWPcpAo1eCkG6cIeywHq9h3k
UYu7NJiEXHFEXT9SEKgyVWxEz4aniVxaS9XELVH0oAgS0kqtq3uk3osRz0nJ
xiuys+mq4W0VEuUmSSi3SKhID4vjYMlsdzp0z4iZ08bNyfmG2YIKfWGb30W3
xGVKwDFLoXuitHdFCUVSNAYFBGP0zKzrvEr3k2g+ogq+sPnCvuPgUL2UArdO
zsmmSJeiIW1DQxWtiGyAWHmNLhjAvGi9wBoVuOS7nvCaAtYklBzab7R9vk0G
mB0ixbRw3whw0oDRV+2NkiaUuiQXzXJyOFdhGipdD6eDDgS03iqs4YsHlTpI
QWsZN7HqiFZeLaeOFNY2x6uDYRl4nzHPnHQT7E5fFaJwdZk3HkupXhsU5rdR
PqN2UrkttrcYXPLahncYougEsjbJhtILNBkmoyzY1bjMhtReAWqvLr+hNLuG
9xVsTCzHoFT+x3hEtDIeOI49dTsOUKfzwQ942YkfzuEDQWFBxDAldZ9vuBPt
cMssqcsl1GVJ204whRPrYLxsxC6I2ObJDLA5ltdhTNyEXGtHzsULcp+NOHmS
UR6oFKjHlPkci4X6WkqR/rM6lqaiJeOp8opXRUvBoM5+m+59o1oX2Wo+D9EQ
R9KjOYc17Toio5NnCtKbdQEJRaaz1drbZjkfUbclI/8uA+9uGwUCy0GN0So4
Cyd3CgYI2jCnZPJ5kL4NseIeHMHlzLpowNzCBKBhm5Yy2pWPjWXsrLlkTPMU
RUyBTKFxOogxugi9pDahVlTQvVLDpnOIwOpCJlRclwuME+RE0nUETkotUJEd
JonFWkBEToU5gy68pGs7vWw5BYYfifo3CfG+BKWO8Q0kmKnrTvXO3ADFkwwm
AbFrfTmhgSyG/lSze2Zh6KGcgBSF/N2AAMNrGNDqOi4uoDiJsvEyy5QNQF+e
TlgrtVS0PxBfov09HrkuRbAIYI1okSath0iahYTMlAycWVNUBT3NxVuepctS
qBrNVA0kVgjSpPBEo9K81edoFUQRqY8xiJ2CZ3rriduF71h6o6TLioA8xEg8
98rvgnQJYWNOHPrpjZ4t9ke6ad0jW1PJ2Id3iltXsWN2hMg3FVeTW909q/s4
CRZ1sYPXGeH4SiyLb5CB9RFoOWwp+gkwGk57dU1gDAcqWiFpCAmLoonIYcq1
ocSBEMbIDaqQFamSbMfAhsfoAydVBjgAcFqLePc0894Wu/WJrpLFF3dojiqX
uvKplEpUui2lj3B8W5WHkIgGuhg80iH5FIeLBFAHtnqCAps1qVYTuCRxfvOg
41zTsc0WFbJIqxpdugaGJNrid1wfCi001rtoDTPLnKDIScMDrUTJL+RlYte1
UC59yoGgoThpL1TdsatKczu1GUSwc9fLtbRMfI1oF4ieaEkHPiGl6uZ8v6My
faCiLCtmXadBJih8h9QS52NCHJ2k4FGo6hOGhRJxDlT4TtlkEaChkmOelWXJ
DWzud/0ESE2eCcZcr+JkkYGmg+aP0ayuGIR1ZaAVuTOWS2UeItBItXfZkudL
Ma1oHgnVpcUc0IpWkVOMhvGrDQyoqAP52fnT9esLn/923Aa+bmJEzQ9qBK3F
sqiFGdokf7kjvGQABt+6jte2SAW9v+UoJlfUciLJqCvys0sjEH2w6R5Mdseh
faU3Dwy3+eCyEstmrFs71OOQqIf/DdkpP1RRlsypAEdOiZJ9A40ThepQMKt4
VYzmAVnpPpmQ01ZR6sGCypK+809Y5GSlA99gX4/uf/CNs6N4Obq0N0TuQ5FG
nB4LsWIjFPmxPgA1Jj5c5Bs2BW74gwxLp+l7nBAu6XIWioSnHWoaRiBZo7d+
SbKRuMzg0Gp5ysQZN5TRp+J4KdtPUaHizA99PED3MxqUpauKrmt7L6wqNSaG
acJE3MS/KzhwSVEu5c/yFSvVdBN5QqHtZHGlS4HdO48b/um0HFOvzFBPkQa+
rzLnuw3X3t9Zs4IQc71EtoRrWZCxfetJx9u2hG4Z169NpBUZ0xuCVcl1XVwj
hVqnlmsNOatrKPrpWBI+hXQ6zlD53nUCfIKH9FNpLJ+5CtpfRSh/58ZFSvp0
j6cI6CcQz5vSmRYxe3jd7vVr8E9nr8t3Wl73Wm3WL1xa7b86HxxB4x3qgB+g
y47qhp+h447bGWf2ryL6UnwJvRr/5ntMaNsBSZ4j30/C6HmKTZSxfkiUsqLB
lkutG10jZ4ozzPEg/EYS/vR+Kxr+RCtFW62jp8gqkjeHpPpY4Z/cNZizabzZ
LB9zvgNHNhFnMfWqTGEs72WxT7qZTGl96atyscZyNqxpU23utoK4tMX+qUwH
lSRRqA9JPppCTrP+oremCJhu0H+ygpFutrcuPcM02X9JrJu07jabnudUjwWV
w7MrBqJnyyvl0qGTSDkerWc977dXev67Jf797y1J+o9cDOv/j2J5f5eam59e
yPnvHjz0z4oY/6yI8b+/IsY/Uzg/KYXzHzeWXoIh/etxMAueDuLKTBMA6Ong
64xCJyzR3L3MGeV78RjJJQNp8GjlWVEKnabR9hfo9Kt6rjRcCaCyqvmCmp0u
xankFELleEUqF3E0EFc85c5l/veNXnOfmptkbFwV3rVtDLbmOsXAPxp4USYp
o7PwHVuu3y3ULSZB9pb7YGge6opxMIWBJ4FYWyUE0rNnnmGEwTekBVWCQt0d
MQpz9OJae2CVUOYChBRal0paOo1YgLe6+oxievCqRdT+HKNKKScdnctzUPOp
Zpdf15H0gGn2Kjbl4ndfovTti0Mwup5LIdPl4hwOokJ4bAort3NjACBJIXx7
D10XkyYjiuFQ+QOc3honykfooZyQq7AcM3uKW6brXOLwka7k0XPW3m4M5yYz
/5wcLOG7KMtVuAFGztTF9MZJtA+JtkmiaSrK5jqJD+/ziuAlViw6oNOmjWiq
aRTPTOiN7VIxYbG373p0vdwtu6sxNhdWpK9SUvba72FotLipHBW5hg5DDTDS
nD0Bzjs8FNUavm977Uklvzm7brXrp8mNWPAsJ0xPfd+R78Wz6t0towlp7rjT
LCnhAuyjpa4Ego4Y3zhLVmKgsuNwQr6e1c8WgNrax4C5OxpDJCZSgY4Hx5P2
EKQrr3RNlfbQmHdSDQblFKUwlpoFZkAoOAl56Mk1LcCtIt4wSU6UaOVJXdWf
GQ63eVfRAcqG3eFQyrhKEI1Hg9eUB1G+Jn8Z3jfAFwhivpCEj9mHSIir2gQM
FvHsPVeHVaJrtvG+QatuTUoxHpLObXK2pUAKZk1y4h8ni2ZWeQkyonI5jMy4
n/VIS6JINQ5AjsZcAFbyy6k/b6KU05DbpTjUwrYlUTidlctDyKlqkERzdDnR
6Y4yUxlDpVSFdkyQBPx4lD6BoHBSN9YHCH3kEB9knZpYOUlU6EpnxqW9hLJP
pvwz5gYpJvMXtK6p2vn2nVOl3FTlWgfiYNu+ktQrUIb1VKFEEArZI+KOtpk2
LPhU3/Qglyo7HELKUJequUeZpxLcMP0nwzgaTqZU89JAdPOzdCSLT2Ktao0h
AZKMUpxQFROsCT1ZBBT2F7MxnhKJYfsp7IoxyvIb95Fi8UHZlgMW6Pzoo4G2
5wJ2YwoEnEb4NE1EtsDlWIsuYqlZl0mVyhLjEbDYBOEt53kA7VGXZBaioQpF
cVjkwEO1SAAEK6myINHrVCEJOLCbXqWCOJVKK4zGlgkK5ck5GAhdavC9pxFV
T4p4t39HAWWGhmLSsI8XM6fiXp9G6dxQceapHsXX0UHQzmpHXKPztGLyJ3E7
slQkKkbK41E9fXO0LJZc2RR6jxW0c4xZSogEqeUU14phJjN1Makn4hlQs/ye
oqOsu0t16SEdTTOL3vJ1sSjYsQ9LMzGPI2NUkRyzYZTpo6sYKUpdTOomQawc
l163UlvUfRblG0WcxFO8JVtd0UCdbTrmiHgyoMUVYQ7l6PRaRR2OOqOYFICj
RNTS9RAwkam68Qm3DSUQnW/hbvtpzJdQUpBUzS6qDxtEAmbEfDeQy8AFJdEn
zueg+Ca8UTbktFJACg46DrDEtC7IoAPWpEfpPhULDSkzhiIr7XUTrBnpULIl
LucnWqzgFWd4abNyJVM0Fi+VROnlXIeV8VCcvUD32xsWo4ZYtz2mlEZd6IOT
+2efWM4LR0zFG6BpQYFTdsoQHJK2ldNaYCEFtAIO9LbQAkaTAi2UIvjAN/gG
CscDIZYqfxnnBRDTm4YlM3AjddQTzs7n1Ga9Oq5EgGK8oqSCBRr3rFMvNgQE
2brcjDpeASGQqjn47LiAA11OgPZbkvt13Xr3shg7a7iY7odbqauMwUhyNTRG
vamiO/rNgUW2iKCV0uDMe7nQwt/+OrjqXp9y0SKiZxG5wcTPpRI/0Jt8Nbi5
rlNrGEfHr7uTZwXMzUSggx7OEZsQFioIsJxFDhI9T0anOQVyDbdPcQsY+Y0S
kiGLuAx0oqpMe3od1Va4wyRZCoijbAtVCoY0bBgPr5xHTHBrIhC6RhzJOocJ
Rdoe4dm3TotqZqfzc6pWkHazSFK1gtRKbwZkcPQcbSMnLKdYWXOaJK5zQTX5
sE4Ql7bLRIgjELHgyRc7mWJ/HH2Lo+lQOeF3WxGqdCt1s6imE9RDoJ4XUEBS
Ht3aII+KTxtSi6xUpfuSHcGjpELKkZxS93skgInaNzuXcxqycFeF9BimqMRc
BHlhet8CTVTFOzIqfM6rwuULm5bsNO/WKZiF1VWrkqkkaMMpPAmyn3cbvoNT
S7DOsC9wekDjWzLpc4EvfHqxM/Bu1TVc+KDMcOUF5Tu/8CWWL4O1QxrDEqS3
1t6IpC6gq0hjU2sq3WiiTGssdoKIN1biF2cuq1k0vFu5WbrOwXw8LR1w6iSu
O5ACzViDg7GoYo2/deZccIJEuwP3OhxkFGT3lrLJJCEDJ8XIKyrV8IiYKLkA
WIiK6nrBclmbnUiFVtlYsXX998BAZ+Bp+qHCBfhgCi2eO0l4ToKTivFCtkS0
gM8p8yUVtjnGqLNYB8+SVcvTsZxZlC8JIQ/YFshVGihOUtlBKnmEVgVATCpE
XjmB5InIrszPdKWjQrkCbapodBodVFBspsOpPnZoR626kGUp4OQcMACDepy7
qZ0wEE8qUw3d2BCTpqVjcjX8ckozpwkeJVenGLZmit9zCeNCbReJJSYC/fwq
bKkS03dR0ON74Qo2BDKRFMjNNd2A53k//mc6HdcBnQE9wp/9BUuXGHP8IOV+
1J3coryC0jxSofSocroxdmsyrIO0fG2ylEH01PWt9XNs8meUZFWYXw3+Oh3c
1L8dXp2enA6v8IksDPgEB0JLB/WIKsKKAex7zmx+//57IYSgaY3SgPKsUVmj
y+oLQYK+JewTXwbJNa7zmddFzAigmibR7WoYdDguOTbkVnMHFrBSXT4GI6UK
kHK4qTJlOG0a3quQLsdjId6axUJmUSiuQXuCdK3imueVT5K95HBi6Q6ygMNL
xTFghTRSKgEW4mGi6NrUiutUkSoqq0Td6EnGSy77om0cSnQxBhk7G2aFmaWS
YQpkmCsXBG7lAi5Vs3U+OMqA21lxb7afQGr5eNZ7cTYmBI+0DxhCCqVMbTsZ
BfIV6wZgGhpVw0BLcw3lGMyJqBlrhQTjw6DFGcPEMCrXztiZcKEJIoBa3vFA
fE4Dk6aFBnh2o/CRjwEanDbKFXqZCIn/KELfjc4K0Zl6OiZYVfTV4iDfAqhL
Pnn61vOUYBKx50k0PClIxEmjGAwrCVkTLi3lioFYZcobYfEnfZerGkCKc4OW
BXIE8mIj1XEcLF7ejJAn25U21Qgm4nozk/pQmVfGerrZgNDSmqTokFswCmFW
kQskSqat0bjuOKq7QsPJtYp43ZhznlcWBPNE3XuO6iepSnSF2zKYqf5k2EkD
0ku9xZJAjP7DY2Mi4imQsUoRAMcewxXA8DJRK9baE3d25pSBDKxDTcmP8cxY
XbWfBG+rjlfzZJntLLJwOcEPqn4EMJrBxaBEB/EKTIydNTmRIrRIJUOx11Pf
iL2wYSZyARZ4pVvCAy4bWWHmskCAafweCyeor0cByDHpjCGutWkaZKMwI87S
5Hlt+Komh4cs6GJQhy9VTcq//dWUi6DmaGRjYQcrNx4UYiPVd1Z9ygO+VFLf
DP8H/0+qGogMgVKl6ggSygEHOqonbBTBUs1b2faBsm/IdYDYilPaMJMsTfAe
9gP/VRCjoHKTgZg3DePoDq0+Djk7FnGRhpRaBfqm+o+sxf7L9fDs5ONHAUOF
WL4WHmVBfT1gKu5efBmEeusgtIz/22BUpYFUAaus762FVTnidi2oyldHvwxS
/XWQogu8pYLp7wekCp22CkbrbGrrT9ma6OL1Z27NRbwvg9reOqhZtTt/z+O3
rlRI5WGsMFmsP40VEdbrj2PFNRwvg9f+OnhRjtvveQhdo0wVfJ6pe7MWVM9E
za+F2jMFal8CQIwU/7si3DPVcstw9c8xjZmmZcK4SvnNmJ5KNYHooUo7NYzf
Yfl0Lbi805ZJsBLOPMpRKFD1P0lurBT4ap6V8c0WZlW/7Nb6ZicM8s/Hj/mt
PTMn4Ro0tPr58Bi00B8uh5i3qM2Pbq6T8ZKjRRrtfy8oC7kFeLeuXWuf2oFU
DALdLV8rbUlmUlzEe6peD1+fvq4OI6dgV6WcF6QyZ1ur8s7XyG3KbeLnj0ll
ZvvpcWZkMfjeK0zDCGG+EsKgVb3Q6uNHcnK+jk3+4LNb/Nwmer4PK2FLygs2
El4/iLm+62+cArzYYNKzU3BxRIohFLbSZB6KBGxXET2JUtANjtBxyH8inULn
NpGTLYwZb9b73f39fZWwryqPq/dkCHuLChxUrvxf7YprX7wgeh5BqrPyDvw6
fjydHPg//niT1EcUaq0rGSBm/PwzttDs/MCmUr/b/Bxw/65TrNfrVPwU9ach
W6hLVdrFcs0XdK5Tczkc0i0LKZeM4LlPo4z9pqJ2ihI4qbw04sZ2LCp9lC+g
Dko3lz9pjk+mnlxZLfZ8e+ZW7TVFPAg/A5+1D3RvibeIr4i4vhyKh826VOT9
+/AdxV21gEabK7nlunW0abIL2w4Figv1d9AsyHYeth2F8UM4SxahNiKhQ0yV
AjFuJCySQem0MIN5MG6+fALFKj0U10cTIHNU6f0R3++k/Ius+sLb5SLyCVs3
ZhhiSrmhOubYchNJVemM6jnchxl5TDVBsM3ILpAzo17rq/msqLEoyEV6CNNb
AFQyK9luhd8Y+LLa/f4zvXMcK47x/zuUzQP/VP20e/0D/36z2Wq2q3+9dV8U
fzdr9K7qjCZ8OWpK9K61P976r+wfeZOup1GxtFZTVrXm11v/lf1rrcnks9lv
Q0sCCJc6hc60L59e7Ih69YHfarf39swiVBRYYRntPjR9AX3ngVSxywpgtPt7
VXC3FleVa7FDSgfQYMpTeC/ZCjvqhhdAf/OmHo3fffLXe/pr+KUJ8Uvs+6zY
swbToZd0nvz1nv4afte8RDIa/daB3H5FrT7Cf3/2PnLaBR7gP333dUWBOUWH
zGVbeKh1/KQ5paZWWEIF2p1o8ggjzNSh3XibrzZgLsMj2t+NcfqAHy/rcGD5
STC7owbX+sk7/Hwz60ZH/7e7+5f0anT1VfPm22lz8rj77cnsVf7Q2nt1Gv9w
H8/PL1ajZI970WvuLsZn94NsFvzy2FxEu+FweN6+ebwazKaD46vm8qp7eHf3
9pf6u8tVl3tNsNd/vHlTX/W+7x6dLPb+4/Wrm3789my32e/8+aLVaf3wzfHi
7eN3g8u3o/P6eMOGIgdZIHwINsmIHE96/a29LUS6+80BHMF2n3bs/ccaP9pr
7cPJbPb22q31ROvFpAwG2+8dwWAvIjxP06cBDfMkPXkB2aEZDVqD3RP+oc+H
rX1MB2zt4wD7u7D23W6/1d/tDHabux34q9Pv7bbh2X6/D//v9bvtYf9kt93f
bR912oD17U6H23r9VrsDDfv9YwLkUXevuA5648lea9Bp9mhJziH1njvFFb9t
GkYOoPfcCV372+p3e81e2+uf9JhW3G/u7vWH+53dQfeo2+73dwcnnb3uLpCt
Tmv/aAA7uzvcPT4cHB4f7R/2mifHh3vHw85J//DkpDs49PbaJyd7AAEg381h
e9DdQ1AASgw7w1az34cxOseD/v7Rbu+k1z7c3d8bAkIetk92m93WYL859PaG
vcGm97PUqGdp4D7ICmZ1dGK3+joKXpB80t7rdjsBYXjQ7BFSBy9E7hfyZNrI
cRG5X8hkCz8BI/cL+eZa7KcpBa1gd8o/9HmksLuA3IGN3J6D3WF/Stg91tgt
jQW5JzTYWCG3tWZ643SvFVRid9XvcxjvYHfx9+XYLtjdn/a6vb1uEzA79AC1
g+6YUDuYGtQeB7Cvu+HuZBSMJuP9Ua85nYz2JmFn2h9Np91gtNeeTr09WD+i
dtgONGqHnVCh9iTo7493e9NeewSoHQImjtpTRO1gvxl6e2Ev0FcLGzHaEjNJ
PP9UKfOo19s9PO6eDI6P9jonu73+ydGgfXTc84aD9vHR0d4h7H5v//CwO9zt
9jrH/cFut3vcHQ6PjvvHzcFRv/lPKfN/VMp0K1bsuAP9U8r8n5Yy6Yy+TMj8
Qv9g9MLwwN/86adNn6tcq9K8WBPt6uTI39vdb/umg+dIqMk4dwTSV0YgfYuf
O3evzy6+Xt3/6fvg/Ps/X3z/S7f5VdYOe788tupRffh2d7x49ebuvP/dbri4
vDl8sxfNf7l42Hv7k8qP/ml0+PW3s7f1bP/dL51f5rvDN98Nj/Ld1z+cz77L
3959kmS5a0mWzd4TkuU6QlVNp7wyofqnZPmPLVkeneztHXc6zeHuoNfp91GY
PIE9HnSPD0+axz3oBPvd7A2Pj/cO2z1o1+524MPhcae16wEcm79aMGwpwbDZ
qxYMx4Cbo0l3GkzGe50p4OZ0HLTHk14YeO3JeLw3IuQcjbohIuekH8C8J90w
HE/6k2YwFtz8p2DY/AcUDNvN8XRvz5sAZoa7AWImyoJT2OGgOxmBrk+YOQHM
DCeTvRFiZgiYCR9GE8BMRExVRMKUIOfsuPcHnPgfTr7YmAazLOTg5yB+66+S
pX8UpFkOHOQQnSExXZvBV5Rq7wtWVWtwD7rD7gLQPpkB2n+XJJOaN5xFeMl4
GKQ174cgRU/ufYjxkDXv6yC/n6E19DxJI0oPwVivC+Bz13O8yZbyOCbASGtU
hZurKmIy8fLuDm3qXFnWjb89INY1nER5kh54/w9G08wgvuAAAA== [rfced] Please review each artwork element and let us know if any should
be marked as sourcecode (or another element) instead.

In addition, review the updates to sourcecode with type="cddl".  If <sourcecode> is used elsewhere in the document, please consider whether the type should be set.  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.
-->

<!-- [rfced] Terminology

a) We note that <tt> tags are used with a few terms
throughout the document. We also note that these terms also appear
without <tt> tags. Please consider whether updates are needed for consistency.
The pattern of use is unclear to us.

<tt>bootseed</tt> vs. bootseed
<tt>configuration</tt> vs. configuration
<tt>eat_profile</tt> vs. eat_profile
<tt>hardware</tt> vs. hardware
<tt>nonce</tt> vs. nonce

b) Please let us know how we should update the following terms for consistency
throughout the document.

EAT nonce claim vs. nonce claim vs. Nonce claim
Arm's Platform Security Architecture vs. The Arm Platform Security Architecture
Boot Seed vs. bootseed
claims-set vs. claims sets (Appendix A)
PSA-token claims-set vs. PSA claims-set (Appendix A)
-->

<!-- [rfced] FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). The abbreviated form of
each term is used thereafter. Please review each expansion in the
document carefully to ensure correctness.
-->

<!-- [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.  Updates of this nature typically
result in more precise language, which is helpful for readers. Note that
our script did not flag any words in particular, but this should still be
reviewed as a best practice. -->
</rfc>