<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-tschofenig-rats-psa-token-24" number="9783" category="info" submissionType="independent" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" updates="" obsoletes="" prepTime="2025-06-13T10:28:40" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-tschofenig-rats-psa-token-24" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9783" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Arm's PSA Attestation Token">Arm's Platform Security Architecture (PSA) Attestation Token</title>
    <seriesInfo name="RFC" value="9783" stream="independent"/>
    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization abbrev="H-BRS" showOnFrontPage="true">University of Applied Sciences Bonn-Rhein-Sieg</organization>
      <address>
        <postal>
          <country>Germany</country>
        </postal>
        <email>Hannes.Tschofenig@gmx.net</email>
      </address>
    </author>
    <author initials="S." surname="Frost" fullname="Simon Frost">
      <organization showOnFrontPage="true">Arm Limited</organization>
      <address>
        <email>Simon.Frost@arm.com</email>
      </address>
    </author>
    <author initials="M." surname="Brossard" fullname="Mathias Brossard">
      <organization showOnFrontPage="true">Arm Limited</organization>
      <address>
        <email>Mathias.Brossard@arm.com</email>
      </address>
    </author>
    <author initials="A." surname="Shaw" fullname="Adrian Shaw">
      <organization showOnFrontPage="true">HP Labs</organization>
      <address>
        <email>adrianlshaw@acm.org</email>
      </address>
    </author>
    <author initials="T." surname="Fossati" fullname="Thomas Fossati">
      <organization showOnFrontPage="true">Linaro</organization>
      <address>
        <email>thomas.fossati@linaro.org</email>
      </address>
    </author>
    <date month="06" year="2025"/>
    <keyword>Remote Attestation</keyword>
    <keyword>EAT profile</keyword>
    <keyword>Evidence</keyword>
    <keyword>RATS</keyword>
    <keyword>IoT</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">Arm's Platform Security Architecture (PSA) is a family of hardware and
firmware security specifications, along with open-source reference
implementations, aimed at helping device makers and chip manufacturers
integrate best-practice security into their products. Devices that
comply with PSA can generate attestation tokens as described in this
document, which serve as the foundation for various protocols, including
secure provisioning and network access control. This document specifies
the structure and semantics of the PSA attestation token.</t>
      <t indent="0" pn="section-abstract-2">The PSA attestation token is a profile of the Entity Attestation Token
(EAT). This specification describes the claims used in an attestation
token generated by PSA-compliant systems, how these claims are
serialized for transmission, and how they are cryptographically
protected.</t>
      <t indent="0" pn="section-abstract-3">This Informational document is published as an Independent Submission to improve
interoperability with Arm's architecture. It is not a standard nor
a product of the IETF.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This is a contribution to the RFC Series, independently of any
            other RFC stream.  The RFC Editor has chosen to publish this
            document at its discretion and makes no statement about its value
            for implementation or deployment.  Documents approved for
            publication by the RFC Editor are not candidates for any level of
            Internet Standard; see Section 2 of RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9783" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-and-definitions">Conventions and Definitions</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-psa-attester-model">PSA Attester Model</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-psa-claims">PSA Claims</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-caller-claims">Caller Claims</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.1.2">
                  <li pn="section-toc.1-1.4.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.1.1"><xref derivedContent="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-nonce">Nonce</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.2.1"><xref derivedContent="4.1.2" format="counter" sectionFormat="of" target="section-4.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-client-id">Client ID</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-target-identification-claim">Target Identification Claims</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-instance-id">Instance ID</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-implementation-id">Implementation ID</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.3.1"><xref derivedContent="4.2.3" format="counter" sectionFormat="of" target="section-4.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-certification-reference">Certification Reference</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-target-state-claims">Target State Claims</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.3.2">
                  <li pn="section-toc.1-1.4.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.1.1"><xref derivedContent="4.3.1" format="counter" sectionFormat="of" target="section-4.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-lifecycle">Security Lifecycle</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.2.1"><xref derivedContent="4.3.2" format="counter" sectionFormat="of" target="section-4.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-boot-seed">Boot Seed</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-software-inventory-claims">Software Inventory Claims</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.4.2">
                  <li pn="section-toc.1-1.4.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.1.1"><xref derivedContent="4.4.1" format="counter" sectionFormat="of" target="section-4.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-software-components">Software Components</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.5">
                <t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-verification-claims">Verification Claims</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.5.2">
                  <li pn="section-toc.1-1.4.2.5.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.5.2.1.1"><xref derivedContent="4.5.1" format="counter" sectionFormat="of" target="section-4.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-verification-service-indica">Verification Service Indicator</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.5.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.5.2.2.1"><xref derivedContent="4.5.2" format="counter" sectionFormat="of" target="section-4.5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-profile-definition">Profile Definition</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.6">
                <t indent="0" pn="section-toc.1-1.4.2.6.1"><xref derivedContent="4.6" format="counter" sectionFormat="of" target="section-4.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-backwards-compatibility-con">Backwards Compatibility Considerations</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-profiles">Profiles</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-baseline-profile">Baseline Profile</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.1.2">
                  <li pn="section-toc.1-1.5.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.1.1"><xref derivedContent="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-token-encoding-and-signing">Token Encoding and Signing</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.2.1"><xref derivedContent="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-freshness-model">Freshness Model</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.3.1"><xref derivedContent="5.1.3" format="counter" sectionFormat="of" target="section-5.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-synopsis">Synopsis</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-profile-tfm">Profile TFM</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-collated-cddl">Collated CDDL</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scalability-considerations">Scalability Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-psa-token-verification">PSA Token Verification</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ar4si-trustworthiness-claim">AR4SI Trustworthiness Claims Mappings</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-endorsements-reference-valu">Endorsements, Reference Values, and Verification Key Material</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-and-privacy-consid">Security and Privacy Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cbor-web-token-claims-regis">CBOR Web Token Claims Registration</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2.1.2">
                  <li pn="section-toc.1-1.10.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.10.2.1.2.1.1"><xref derivedContent="10.1.1" format="counter" sectionFormat="of" target="section-10.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-client-id-claim">Client ID Claim</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.10.2.1.2.2.1"><xref derivedContent="10.1.2" format="counter" sectionFormat="of" target="section-10.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-lifecycle-claim">Security Lifecycle Claim</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.10.2.1.2.3.1"><xref derivedContent="10.1.3" format="counter" sectionFormat="of" target="section-10.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-implementation-id-claim">Implementation ID Claim</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.10.2.1.2.4.1"><xref derivedContent="10.1.4" format="counter" sectionFormat="of" target="section-10.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-certification-reference-cla">Certification Reference Claim</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.1.2.5">
                    <t indent="0" pn="section-toc.1-1.10.2.1.2.5.1"><xref derivedContent="10.1.5" format="counter" sectionFormat="of" target="section-10.1.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-software-components-claim">Software Components Claim</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.1.2.6">
                    <t indent="0" pn="section-toc.1-1.10.2.1.2.6.1"><xref derivedContent="10.1.6" format="counter" sectionFormat="of" target="section-10.1.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-verification-service-indicat">Verification Service Indicator Claim</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-types">Media Types</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.3">
                <t indent="0" pn="section-toc.1-1.10.2.3.1"><xref derivedContent="10.3" format="counter" sectionFormat="of" target="section-10.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-coap-content-formats-regist">CoAP Content-Formats Registration</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2.3.2">
                  <li pn="section-toc.1-1.10.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.10.2.3.2.1.1"><xref derivedContent="10.3.1" format="counter" sectionFormat="of" target="section-10.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registry-contents">Registry Contents</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-examples">Examples</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2">
              <li pn="section-toc.1-1.12.2.1">
                <t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cose-sign1-token">COSE Sign1 Token</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.2">
                <t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cose-mac0-token">COSE Mac0 Token</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The Platform Security Architecture (PSA) <xref target="PSA" format="default" sectionFormat="of" derivedContent="PSA"/> is a set of hardware and firmware
specifications backed by reference implementations and a security
certification program <xref target="PSACertified" format="default" sectionFormat="of" derivedContent="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, 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 indent="0" pn="section-1-2">Many devices now have 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 indent="0" pn="section-1-3">As outlined in the Remote ATtestation procedureS (RATS) Architecture
      <xref target="RFC9334" format="default" sectionFormat="of" derivedContent="RFC9334"/>, an Attester produces a signed collection of
      Claims that constitutes Evidence about its Target Environment. This
      document focuses on the output provided by PSA's Initial Attestation API
      <xref target="PSA-API" format="default" sectionFormat="of" derivedContent="PSA-API"/>. This output corresponds to Evidence in <xref target="RFC9334" format="default" sectionFormat="of" derivedContent="RFC9334"/> and, as a design decision, the PSA attestation token
      is a profile of the Entity Attestation Token (EAT) <xref target="RFC9711" format="default" sectionFormat="of" derivedContent="EAT"/>. Note that there are other profiles of EAT available
      for use with different use cases and by different attestation
      technologies, such as <xref target="I-D.kdyxy-rats-tdx-eat-profile" format="default" sectionFormat="of" derivedContent="RATS-TDX"/>
      and <xref target="I-D.mandyam-rats-qwestoken" format="default" sectionFormat="of" derivedContent="RATS-QWESTOKEN"/>.</t>
      <t indent="0" pn="section-1-4">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 indent="0" pn="section-1-5">Further details on concepts expressed below can be found in the PSA Security
Model documentation <xref target="PSA-SM" format="default" sectionFormat="of" derivedContent="PSA-SM"/>.</t>
      <t indent="0" pn="section-1-6">As mentioned in the abstract, this memo documents a vendor extension
to the RATS architecture and is not a standard.</t>
    </section>
    <section anchor="conventions-and-definitions" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-conventions-and-definitions">Conventions and Definitions</name>
      <t indent="0" pn="section-2-1">
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
      </t>
      <t indent="0" pn="section-2-2">The terms Attester, Relying Party, Verifier, Attestation Result, Target Environment, Attesting Environment, and Evidence
are defined in <xref target="RFC9334" format="default" sectionFormat="of" derivedContent="RFC9334"/>. We use the term "receiver" to refer to Relying Parties
and Verifiers.</t>
      <t indent="0" pn="section-2-3">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" indent="3" spacing="normal" pn="section-2-4">
        <dt pn="section-2-4.1">Root of Trust (RoT):</dt>
        <dd pn="section-2-4.2">The minimal set of software, hardware, and data that has to be
        implicitly trusted in the platform; there is no software or hardware
        at a deeper level that can verify that the 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.</dd>
        <dt pn="section-2-4.3">Secure Processing Environment (SPE):</dt>
        <dd pn="section-2-4.4">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 a TEE, "secure world", or "secure
        enclave".)</dd>
        <dt pn="section-2-4.5">Non-Secure Processing Environment (NSPE):</dt>
        <dd pn="section-2-4.6">The security domain (Application domain) outside of the SPE that typically contains the application firmware, real-time operating systems, applications, and general hardware. (Equivalent to Rich Execution Environment (REE), or "normal
        world".)</dd>
      </dl>
      <t indent="0" pn="section-2-5">In this document, the structure of data is specified in Concise Data Definition Language (CDDL) <xref target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/>.</t>
    </section>
    <section anchor="sec-psa-attester-model" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-psa-attester-model">PSA Attester Model</name>
      <t indent="0" pn="section-3-1"><xref target="fig-psa-attester" format="default" sectionFormat="of" derivedContent="Figure 1"/> outlines the structure of the PSA Attester according to
the conceptual model described in <xref section="3.1" sectionFormat="of" target="RFC9334" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9334#section-3.1" derivedContent="RFC9334"/>.</t>
      <figure anchor="fig-psa-attester" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-psa-attester">PSA Attester</name>
        <artset pn="section-3-2.1">
          <artwork type="svg" align="left" pn="section-3-2.1.1"><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" align="left" pn="section-3-2.1.2">
                                                    .----------.
                                                    | Verifier |
                                                    '----------'
                                                         ^
                                                         |
                                               PSA Token |
                                                         |
.--------------------------------------------------------|----------.
| .------------------------------------------------------|--------. |
| | Attesting Environment                                |        | |
| |                .------------.     .-----.     .------+------. | |
| |                | Main       |    | Main  |    | Initial     | | |
| |                | Bootloader +---&gt;| Boot  |&lt;---+ Attestation | | |
| |                |            | W  | State |  R | Service     | | |
| |                '-----+------'     '-----'     '-------------' | |
| '----------------------|----------------------------------------' |
|           .------------+--------------+---------------.           |
| .--------|-------------|--------------|----------------|--------. |
| |        |             |              |                |        | |
| | .------o-----. .-----o-------. .----o--------. .-----o------. | |
| | | Updateable | | Application | | Application | | PSA RoT    | | |
| | | PSA RoT    | | RoT         | | Loader      | | Parameters | | |
| | '------------' '-------------' '-------------' '------------' | |
| | Target Environment                                            | |
| '---------------------------------------------------------------' |
'-------------------------------------------------------------------'
Legend:
             ---&gt; read    ---&gt; write    ---o measure
              R            W
</artwork>
        </artset>
      </figure>
      <t indent="0" pn="section-3-3">The PSA Attester is a relatively straightforward embodiment of the RATS
Attester with exactly one Attesting Environment and one or more Target Environments.</t>
      <t indent="0" pn="section-3-4">The Attesting Environment is responsible for collecting the
  information to be represented in PSA claims and to assemble them into
  Evidence.  The Attesting Environment is made of two cooperating
  components:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-5">
        <li pn="section-3-5.1">
          <t indent="0" pn="section-3-5.1.1">Executing at boot-time, the Main Bootloader measures the Target Environments (i.e., loaded software
components and all the relevant PSA RoT parameters) and stores the recorded
information in secure memory (Main Boot State). See <xref target="fig-psa-attester-boot" format="default" sectionFormat="of" derivedContent="Figure 2"/>.</t>
          <figure anchor="fig-psa-attester-boot" align="left" suppress-title="false" pn="figure-2">
            <name slugifiedName="name-psa-attester-boot-phase">PSA Attester Boot Phase</name>
            <artset pn="section-3-5.1.2.1">
              <artwork type="svg" align="center" pn="section-3-5.1.2.1.1"><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" align="left" pn="section-3-5.1.2.1.2">
    i-th Target    Main Boot     Main Boot
    Environment      Loader        State
         |             |             |
.--------|-------------|-------------|----.
| loop i |             |             |    |
|        | measure     |             |    |
|        |o------------+             |    |
|        |             | write       |    |
|        |             | measurement |    |
|        |             +------------&gt;|    |
'--------|-------------|-------------|----'
         |             |             |
</artwork>
            </artset>
          </figure>
        </li>
        <li pn="section-3-5.2">The Initial Attestation Service (executing at run-time in SPE)
        answers requests coming from NSPE via the PSA attestation API <xref target="PSA-API" format="default" sectionFormat="of" derivedContent="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" format="default" sectionFormat="of" derivedContent="Figure 3"/>.</li>
      </ul>
      <t indent="0" pn="section-3-6">The word "Initial" in "Initial Attestation Service" refers to a limited set of
Target Environments, namely those representing the 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" align="left" suppress-title="false" pn="figure-3">
        <name slugifiedName="name-psa-attester-run-time-phase">PSA Attester Run-Time Phase</name>
        <artset pn="section-3-7.1">
          <artwork type="svg" align="center" pn="section-3-7.1.1"><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" align="left" pn="section-3-7.1.2">
                       Initial
     Main Boot       Attestation
       State           Service     Verifier
         |                |           |
.--------|----------------|-----------|----.
| loop i | read           |           |    |
|        | measurement of |           |    |
|        | i-th Target    |           |    |
|        | Environment    |           |    |
|        |&lt;---------------+           |    |
'--------|----------------|-----------|----'
         |            .---+           |
         |       sign |   |           |
         |            '--&gt;|           |
         |                | PSA Token |
         |                +----------&gt;|
         |                |           |
</artwork>
        </artset>
      </figure>
      <t indent="0" pn="section-3-8">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" bare="false" empty="false" indent="3" pn="section-3-9">
        <li pn="section-3-9.1">(A subset of) the PSA RoT parameters, including Instance and
        Implementation IDs.</li>
        <li pn="section-3-9.2">The updateable PSA RoT, including the Secure Partition Manager and
        all PSA RoT services.</li>
        <li pn="section-3-9.3">The (optional) Application RoT, that is any application-defined
        security service possibly making use of the PSA RoT services.</li>
        <li pn="section-3-9.4">The loader of the application software running in NSPE.</li>
      </ul>
      <t indent="0" pn="section-3-10">A reference implementation of the PSA Attester is provided by <xref target="TF-M" format="default" sectionFormat="of" derivedContent="TF-M"/>.</t>
    </section>
    <section anchor="sec-psa-claims" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-psa-claims">PSA Claims</name>
      <t indent="0" pn="section-4-1">This section describes the claims to be used in a PSA attestation token.
A more comprehensive treatment of the EAT profiles defined by PSA is found in <xref target="sec-profiles" format="default" sectionFormat="of" derivedContent="Section 5"/>.</t>
      <t indent="0" pn="section-4-2">CDDL <xref target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/> along with text descriptions is used to define each claim
independent of encoding.  The following CDDL types are reused by different
claims:</t>
      <sourcecode type="cddl" markers="false" pn="section-4-3">
psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64</sourcecode>
      <t indent="0" pn="section-4-4">Two conventions are used to encode the Right-Hand-Side (RHS) of a claim. The postfix <tt>-label</tt> is used for EAT-defined claims and the postfix <tt>-key</tt> is used for PSA-originated claims.</t>
      <section anchor="caller-claims" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-caller-claims">Caller Claims</name>
        <section anchor="sec-nonce-claim" numbered="true" removeInRFC="false" toc="include" pn="section-4.1.1">
          <name slugifiedName="name-nonce">Nonce</name>
          <t indent="0" pn="section-4.1.1-1">The EAT <xref target="RFC9711" format="default" sectionFormat="of" derivedContent="EAT"/> "nonce" (claim key 10) is used to carry the challenge provided by the caller to demonstrate freshness of the generated token.</t>
          <t indent="0" pn="section-4.1.1-2">Since the EAT nonce claim offers flexibility for different
attestation technologies, this specification applies the following constraints
 to the <tt>nonce-type</tt>:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1.1-3">
            <li pn="section-4.1.1-3.1">The length <bcp14>MUST</bcp14> be either 32, 48, or 64 bytes.</li>
            <li pn="section-4.1.1-3.2">Only a single nonce value is conveyed. The array notation
            <bcp14>MUST NOT</bcp14> be used for encoding the nonce value.</li>
          </ul>
          <t indent="0" pn="section-4.1.1-4">This claim <bcp14>MUST</bcp14> be present in a PSA attestation token.</t>
          <sourcecode type="cddl" markers="false" pn="section-4.1.1-5">
psa-nonce = (
    nonce-label =&gt; psa-hash-type
)</sourcecode>
        </section>
        <section anchor="sec-client-id" numbered="true" removeInRFC="false" toc="include" pn="section-4.1.2">
          <name slugifiedName="name-client-id">Client ID</name>
          <t indent="0" pn="section-4.1.2-1">The Client ID claim represents the security domain of the caller.</t>
          <t indent="0" pn="section-4.1.2-2">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 indent="0" pn="section-4.1.2-3">For an example definition of client IDs, see the PSA Firmware Framework <xref target="PSA-FF" format="default" sectionFormat="of" derivedContent="PSA-FF"/>.</t>
          <t indent="0" pn="section-4.1.2-4">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 indent="0" pn="section-4.1.2-5">This claim <bcp14>MUST</bcp14> be present in a PSA attestation token.</t>
          <sourcecode type="cddl" markers="false" pn="section-4.1.2-6">
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 =&gt; psa-client-id-type
)</sourcecode>
        </section>
      </section>
      <section anchor="target-identification-claims" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-target-identification-claim">Target Identification Claims</name>
        <section anchor="sec-instance-id-claim" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.1">
          <name slugifiedName="name-instance-id">Instance ID</name>
          <t indent="0" pn="section-4.2.1-1">The Instance ID claim represents the unique identifier of the IAK.  The full definition is in <xref target="PSA-SM" format="default" sectionFormat="of" derivedContent="PSA-SM"/>.</t>
          <t indent="0" pn="section-4.2.1-2">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" bare="false" empty="false" indent="3" pn="section-4.2.1-3">
            <li pn="section-4.2.1-3.1">The length <bcp14>MUST</bcp14> be 33 bytes.</li>
            <li pn="section-4.2.1-3.2">The first byte <bcp14>MUST</bcp14> be 0x01 (RAND) followed by
            the 32-byte unique identifier of the IAK. <xref target="PSA-API" format="default" sectionFormat="of" derivedContent="PSA-API"/>
            provides implementation options for deriving the IAK unique
            identifier from the IAK itself.</li>
          </ul>
          <t indent="0" pn="section-4.2.1-4">This claim <bcp14>MUST</bcp14> be present in a PSA attestation token.</t>
          <sourcecode type="cddl" markers="false" pn="section-4.2.1-5">
psa-instance-id-type = bytes .size 33

psa-instance-id = (
    ueid-label =&gt; psa-instance-id-type
)</sourcecode>
        </section>
        <section anchor="sec-implementation-id" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.2">
          <name slugifiedName="name-implementation-id">Implementation ID</name>
          <t indent="0" pn="section-4.2.2-1">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 indent="0" pn="section-4.2.2-2">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 indent="0" pn="section-4.2.2-3">This claim <bcp14>MUST</bcp14> be present in a PSA attestation token.</t>
          <t indent="0" pn="section-4.2.2-4">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" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/>.</t>
          <sourcecode type="cddl" markers="false" pn="section-4.2.2-5">
psa-implementation-id-type = bytes .size 32

psa-implementation-id = (
    psa-implementation-id-key =&gt; psa-implementation-id-type
)</sourcecode>
        </section>
        <section anchor="sec-certification-reference" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.3">
          <name slugifiedName="name-certification-reference">Certification Reference</name>
          <t indent="0" pn="section-4.2.3-1">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. 
The Certification Reference claim <bcp14>MUST</bcp14> be represented as a
string made of nineteen numeric characters: a thirteen-digit EAN-13 <xref target="EAN-13" format="default" sectionFormat="of" derivedContent="EAN-13"/> followed by a dash "-" and the five-digit versioning
information described in <xref target="PSA-Cert-Guide" format="default" sectionFormat="of" derivedContent="PSA-Cert-Guide"/>.</t>
          <t indent="0" pn="section-4.2.3-2">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, for example, the Implementation
ID.</t>
          <t indent="0" pn="section-4.2.3-3">This claim <bcp14>MAY</bcp14> be present in a PSA attestation token.</t>
          <sourcecode type="cddl" markers="false" pn="section-4.2.3-4">
psa-certification-reference-type = text .regexp "[0-9]{13}-[0-9]{5}"

psa-certification-reference = (
    ? psa-certification-reference-key =&gt;
        psa-certification-reference-type
)</sourcecode>
        </section>
      </section>
      <section anchor="target-state-claims" numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-target-state-claims">Target State Claims</name>
        <section anchor="sec-security-lifecycle" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.1">
          <name slugifiedName="name-security-lifecycle">Security Lifecycle</name>
          <t indent="0" pn="section-4.3.1-1">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" format="default" sectionFormat="of" derivedContent="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" bare="false" empty="false" indent="3" pn="section-4.3.1-2">
            <li pn="section-4.3.1-2.1">major[15:8] - PSA security lifecycle state, and</li>
            <li pn="section-4.3.1-2.2">minor[7:0] - IMPLEMENTATION DEFINED state.</li>
          </ul>
          <t indent="0" pn="section-4.3.1-3">The PSA lifecycle states are illustrated in <xref target="fig-lifecycle-states" format="default" sectionFormat="of" derivedContent="Figure 4"/>. 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 indent="0" pn="section-4.3.1-4">This claim <bcp14>MUST</bcp14> be present in a PSA attestation token.</t>
          <figure anchor="fig-lifecycle-states" align="left" suppress-title="false" pn="figure-4">
            <name slugifiedName="name-psa-lifecycle-states">PSA Lifecycle States</name>
            <artset pn="section-4.3.1-5.1">
              <artwork type="svg" align="left" pn="section-4.3.1-5.1.1"><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" align="left" pn="section-4.3.1-5.1.2">
             .-------------------------.
            | 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                   |
  |              .----------------.          |
   '------------&gt;| Decommissioned |&lt;--------'
                 '----------------'
</artwork>
            </artset>
          </figure>
          <t indent="0" pn="section-4.3.1-6">The CDDL representation is shown below.
<xref target="tab-states-map" format="default" sectionFormat="of" derivedContent="Table 1"/> provides the mappings between <xref target="fig-lifecycle-states" format="default" sectionFormat="of" derivedContent="Figure 4"/> and the data model.</t>
          <sourcecode type="cddl" markers="false" pn="section-4.3.1-7">
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 =&gt; psa-lifecycle-type
)</sourcecode>
          <t indent="0" pn="section-4.3.1-8"><tt>psa-lifecycle-unknown-type</tt> is not shown in <xref target="fig-lifecycle-states" format="default" sectionFormat="of" derivedContent="Figure 4"/>; it represents an invalid state that must not occur in a system.</t>
          <table anchor="tab-states-map" align="center" pn="table-1">
            <name slugifiedName="name-lifecycle-states-mappings">Lifecycle States Mappings</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">CDDL</th>
                <th align="left" colspan="1" rowspan="1">Lifecycle States</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">
                  <tt>psa-lifecycle-unknown-type</tt></td>
                <td align="left" colspan="1" rowspan="1"> </td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">
                  <tt>psa-lifecycle-assembly-and-test-type</tt></td>
                <td align="left" colspan="1" rowspan="1">Assembly and Test</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">
                  <tt>psa-lifecycle-psa-rot-provisioning-type</tt></td>
                <td align="left" colspan="1" rowspan="1">PSA RoT Provisioning</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">
                  <tt>psa-lifecycle-secured-type</tt></td>
                <td align="left" colspan="1" rowspan="1">Secured</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">
                  <tt>psa-lifecycle-non-psa-rot-debug-type</tt></td>
                <td align="left" colspan="1" rowspan="1">Non-Recoverable PSA RoT Debug</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">
                  <tt>psa-lifecycle-recoverable-psa-rot-debug-type</tt></td>
                <td align="left" colspan="1" rowspan="1">Recoverable PSA RoT Debug</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">
                  <tt>psa-lifecycle-decommissioned-type</tt></td>
                <td align="left" colspan="1" rowspan="1">Decommissioned</td>
              </tr>
            </tbody>
          </table>
        </section>
        <section anchor="sec-boot-seed" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.2">
          <name slugifiedName="name-boot-seed">Boot Seed</name>
          <t indent="0" pn="section-4.3.2-1">The "bootseed" claim contains a value created at system boot time
that allows differentiation of attestation reports from different
boot sessions of a particular entity (i.e., a certain Instance ID).</t>
          <t indent="0" pn="section-4.3.2-2">The EAT "bootseed" (claim key 268) is used.
The following constraints apply to the <tt>binary-data</tt> type:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3.2-3">
            <li pn="section-4.3.2-3.1">The length <bcp14>MUST</bcp14> be between 8 and 32 bytes.</li>
          </ul>
          <t indent="0" pn="section-4.3.2-4">This claim <bcp14>MAY</bcp14> be present in a PSA attestation token.</t>
          <sourcecode type="cddl" markers="false" pn="section-4.3.2-5">
psa-boot-seed-type = bytes .size (8..32)

psa-boot-seed = (
    boot-seed-label =&gt; psa-boot-seed-type
)</sourcecode>
        </section>
      </section>
      <section anchor="software-inventory-claims" numbered="true" removeInRFC="false" toc="include" pn="section-4.4">
        <name slugifiedName="name-software-inventory-claims">Software Inventory Claims</name>
        <section anchor="sec-sw-components" numbered="true" removeInRFC="false" toc="include" pn="section-4.4.1">
          <name slugifiedName="name-software-components">Software Components</name>
          <t indent="0" pn="section-4.4.1-1">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 <bcp14>MUST</bcp14> be included in attestation tokens produced by an implementation
conformant with <xref target="PSA-SM" format="default" sectionFormat="of" derivedContent="PSA-SM"/>.</t>
          <t indent="0" pn="section-4.4.1-2">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 <bcp14>OPTIONAL</bcp14>.</t>
          <t indent="0" pn="section-4.4.1-3">Note that a Relying Party will typically see the
result of the appraisal process from the Verifier in form of an Attestation
Result rather than the PSA token from the attesting endpoint as described in <xref target="RFC9334" format="default" sectionFormat="of" derivedContent="RFC9334"/>.
Therefore, a 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 a "high-level"
Attestation Result, which may or may not include the original Software
Components claim.</t>
          <sourcecode type="cddl" markers="false" pn="section-4.4.1-4">
psa-software-component = {
  ? &amp;(measurement-type: 1) =&gt; text
    &amp;(measurement-value: 2) =&gt; psa-hash-type
  ? &amp;(version: 4) =&gt; text
    &amp;(signer-id: 5) =&gt; psa-hash-type
  ? &amp;(measurement-desc: 6) =&gt; text
}

psa-software-components = (
    psa-software-components-key =&gt; [ + psa-software-component ]
)</sourcecode>
          <section anchor="measurement-type" numbered="true" removeInRFC="false" toc="exclude" pn="section-4.4.1.1">
            <name slugifiedName="name-measurement-type">Measurement Type</name>
            <t indent="0" pn="section-4.4.1.1-1">The Measurement Type attribute (key=1) is a short string representing the role of
this software component.</t>
            <t indent="0" pn="section-4.4.1.1-2">The following measurement types <bcp14>MAY</bcp14> be used for code measurements:</t>
            <dl spacing="normal" newline="false" indent="3" pn="section-4.4.1.1-3">
              <dt pn="section-4.4.1.1-3.1">"BL":</dt>
              <dd pn="section-4.4.1.1-3.2">a Boot Loader</dd>
              <dt pn="section-4.4.1.1-3.3">"PRoT":</dt>
              <dd pn="section-4.4.1.1-3.4">a component of the PSA Root of Trust</dd>
              <dt pn="section-4.4.1.1-3.5">"ARoT":</dt>
              <dd pn="section-4.4.1.1-3.6">a component of the Application Root of Trust</dd>
              <dt pn="section-4.4.1.1-3.7">"App":</dt>
              <dd pn="section-4.4.1.1-3.8">a component of the NSPE application</dd>
              <dt pn="section-4.4.1.1-3.9">"TS":</dt>
              <dd pn="section-4.4.1.1-3.10">a component of a Trusted Subsystem</dd>
            </dl>
            <t indent="0" pn="section-4.4.1.1-4">The same labels with a "_CONFIG" postfix (e.g., "PRoT_CONFIG") <bcp14>MAY</bcp14> be used for
configuration measurements.</t>
            <t indent="0" pn="section-4.4.1.1-5">This attribute <bcp14>SHOULD</bcp14> be present in a PSA software component unless
there is a very good reason to leave it out, for example, in networks
with severely constrained bandwidth where sparing a few bytes really
makes a difference.</t>
          </section>
          <section anchor="measurement-value" numbered="true" removeInRFC="false" toc="exclude" pn="section-4.4.1.2">
            <name slugifiedName="name-measurement-value">Measurement Value</name>
            <t indent="0" pn="section-4.4.1.2-1">The Measurement Value attribute (key=2) represents a hash of the invariant
software component in memory at startup time. The value <bcp14>MUST</bcp14> be a cryptographic
hash of 256 bits or stronger.</t>
            <t indent="0" pn="section-4.4.1.2-2">This attribute <bcp14>MUST</bcp14> be present in a PSA software component.</t>
          </section>
          <section anchor="version" numbered="true" removeInRFC="false" toc="exclude" pn="section-4.4.1.3">
            <name slugifiedName="name-version">Version</name>
            <t indent="0" pn="section-4.4.1.3-1">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" numbered="true" removeInRFC="false" toc="exclude" pn="section-4.4.1.4">
            <name slugifiedName="name-signer-id">Signer ID</name>
            <t indent="0" pn="section-4.4.1.4-1">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 indent="0" pn="section-4.4.1.4-2">This attribute <bcp14>MUST</bcp14> be present in a PSA software component to be compliant with
<xref target="PSA-SM" format="default" sectionFormat="of" derivedContent="PSA-SM"/>.</t>
          </section>
          <section anchor="measurement-description" numbered="true" removeInRFC="false" toc="exclude" pn="section-4.4.1.5">
            <name slugifiedName="name-measurement-description">Measurement Description</name>
            <t indent="0" pn="section-4.4.1.5-1">The Measurement Description attribute (key=6) contains a string identifying the
hash algorithm used to compute the corresponding Measurement Value.  The string
<bcp14>SHOULD</bcp14> be encoded according to "Hash Name String" in the "Named Information Hash Algorithm Registry" <xref target="NAMED-INFO" format="default" sectionFormat="of" derivedContent="NAMED-INFO"/>.</t>
          </section>
        </section>
      </section>
      <section anchor="verification-claims" numbered="true" removeInRFC="false" toc="include" pn="section-4.5">
        <name slugifiedName="name-verification-claims">Verification Claims</name>
        <t indent="0" pn="section-4.5-1">  The following claims, although part of Evidence, do not reflect the
  internal state of the Attester. Instead, they aim to help receivers,
  including Relying Parties, in processing the received attestation
  Evidence.</t>
        <section anchor="sec-verification-service-indicator" numbered="true" removeInRFC="false" toc="include" pn="section-4.5.1">
          <name slugifiedName="name-verification-service-indica">Verification Service Indicator</name>
          <t indent="0" pn="section-4.5.1-1">The Verification Service Indicator claim is a hint used by a 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>
          <sourcecode type="cddl" markers="false" pn="section-4.5.1-2">
psa-verification-service-indicator-type = text

psa-verification-service-indicator = (
    ? psa-verification-service-indicator-key =&gt;
        psa-verification-service-indicator-type
)</sourcecode>
          <t indent="0" pn="section-4.5.1-3">It is assumed that the 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 be tricked
into contacting an unknown and untrusted verification service since the
returned Attestation Result cannot be relied on.</t>
          <t indent="0" pn="section-4.5.1-4">Note: This hint requires the Relying Party to parse the content of the
PSA token. Since the 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" numbered="true" removeInRFC="false" toc="include" pn="section-4.5.2">
          <name slugifiedName="name-profile-definition">Profile Definition</name>
          <t indent="0" pn="section-4.5.2-1">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 indent="0" pn="section-4.5.2-2">The EAT <tt>eat_profile</tt> (claim key 265) is used.</t>
          <t indent="0" pn="section-4.5.2-3">The URI encoding <bcp14>MUST</bcp14> be used.</t>
          <t indent="0" pn="section-4.5.2-4">The value <bcp14>MUST</bcp14> be <tt>tag:psacertified.org,2023:psa#tfm</tt> for the profile defined in <xref target="sec-tfm-profile" format="default" sectionFormat="of" derivedContent="Section 5.2"/>.</t>
          <t indent="0" pn="section-4.5.2-5">Future profiles derived from the baseline PSA profile <bcp14>SHALL</bcp14> create their unique value as described in <xref target="sec-profile-uri-structure" format="default" sectionFormat="of" derivedContent="Section 4.5.2.1"/>.</t>
          <t indent="0" pn="section-4.5.2-6">This claim <bcp14>MUST</bcp14> be present in a PSA attestation token.</t>
          <t indent="0" pn="section-4.5.2-7">See <xref target="sec-backwards-compat" format="default" sectionFormat="of" derivedContent="Section 4.6"/> for considerations about backwards compatibility
with previous versions of the PSA attestation token format.</t>
          <sourcecode type="cddl" markers="false" pn="section-4.5.2-8">
psa-profile-type = "tag:psacertified.org,2023:psa#tfm"

psa-profile = (
    profile-label =&gt; psa-profile-type
)</sourcecode>
          <section anchor="sec-profile-uri-structure" numbered="true" removeInRFC="false" toc="exclude" pn="section-4.5.2.1">
            <name slugifiedName="name-uri-structure-for-the-deriv">URI Structure for the Derived Profile Identifiers</name>
            <t indent="0" pn="section-4.5.2.1-1">A new profile is associated with a unique string.</t>
            <t indent="0" pn="section-4.5.2.1-2">The string <bcp14>MUST</bcp14> use the URI fragment syntax defined in <xref section="3.5" sectionFormat="of" target="RFC3986" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3986#section-3.5" derivedContent="RFC3986"/>.</t>
            <t indent="0" pn="section-4.5.2.1-3">The string <bcp14>SHOULD</bcp14> be short to avoid unnecessary overhead.</t>
            <t indent="0" pn="section-4.5.2.1-4">To avoid collisions, profile authors <bcp14>SHOULD</bcp14> communicate their intent upfront to use a certain string that uses the inquiry form on the website <xref target="PSACertified" format="default" sectionFormat="of" derivedContent="PSACertified"/>.</t>
            <t indent="0" pn="section-4.5.2.1-5">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" format="default" sectionFormat="of" derivedContent="RFC4151"/>.</t>
            <t indent="0" pn="section-4.5.2.1-6">For example, 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 <tt>tag:psacertified.org,2023:psa#aes-mac</tt>.</t>
          </section>
        </section>
      </section>
      <section anchor="sec-backwards-compat" numbered="true" removeInRFC="false" toc="include" pn="section-4.6">
        <name slugifiedName="name-backwards-compatibility-con">Backwards Compatibility Considerations</name>
        <t indent="0" pn="section-4.6-1">An earlier draft of this document <xref target="I-D.tschofenig-rats-psa-token" format="default" sectionFormat="of" derivedContent="PSA-OLD"/> 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 indent="0" pn="section-4.6-2"><xref target="tab-claim-map" format="default" sectionFormat="of" derivedContent="Table 2"/> provides the mappings between the deprecated and new claim
keys.</t>
        <table anchor="tab-claim-map" align="center" pn="table-2">
          <name slugifiedName="name-claim-key-mappings">Claim Key Mappings</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1"> </th>
              <th align="left" colspan="1" rowspan="1">PSA_IOT_PROFILE_1</th>
              <th align="left" colspan="1" rowspan="1">tag:psacertified.org,2023:psa#tfm</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">Nonce</td>
              <td align="left" colspan="1" rowspan="1">-75008</td>
              <td align="left" colspan="1" rowspan="1">10 (EAT nonce)</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Instance ID</td>
              <td align="left" colspan="1" rowspan="1">-75009</td>
              <td align="left" colspan="1" rowspan="1">256 (EAT euid)</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Profile Definition</td>
              <td align="left" colspan="1" rowspan="1">-75000</td>
              <td align="left" colspan="1" rowspan="1">265 (EAT eat_profile)</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Client ID</td>
              <td align="left" colspan="1" rowspan="1">-75001</td>
              <td align="left" colspan="1" rowspan="1">2394</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Security Lifecycle</td>
              <td align="left" colspan="1" rowspan="1">-75002</td>
              <td align="left" colspan="1" rowspan="1">2395</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Implementation ID</td>
              <td align="left" colspan="1" rowspan="1">-75003</td>
              <td align="left" colspan="1" rowspan="1">2396</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Boot Seed</td>
              <td align="left" colspan="1" rowspan="1">-75004</td>
              <td align="left" colspan="1" rowspan="1">268 (EAT bootseed)</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Certification Reference</td>
              <td align="left" colspan="1" rowspan="1">-75005</td>
              <td align="left" colspan="1" rowspan="1">2398</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Software Components</td>
              <td align="left" colspan="1" rowspan="1">-75006</td>
              <td align="left" colspan="1" rowspan="1">2399</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Verification Service Indicator</td>
              <td align="left" colspan="1" rowspan="1">-75010</td>
              <td align="left" colspan="1" rowspan="1">2400</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-4.6-4">The new profile introduces three further changes:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.6-5">
          <li pn="section-4.6-5.1">The "bootseed" claim is now optional and of variable length
          (see <xref target="sec-boot-seed" format="default" sectionFormat="of" derivedContent="Section 4.3.2"/>).</li>
          <li pn="section-4.6-5.2">The "No Software Measurements" claim has been retired.</li>
          <li pn="section-4.6-5.3">The "Certification Reference" claim syntax changed from EAN-13
          to EAN-13+5 (see <xref target="sec-certification-reference" format="default" sectionFormat="of" derivedContent="Section 4.2.3"/>).</li>
        </ul>
        <t indent="0" pn="section-4.6-6">To simplify the transition to the token format described in this
document, it is <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" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-profiles">Profiles</name>
      <t indent="0" pn="section-5-1">This document defines a baseline with common requirements that all PSA profiles must satisfy.
(Note that this does not apply to <xref target="I-D.tschofenig-rats-psa-token" format="default" sectionFormat="of" derivedContent="PSA-OLD"/>.)</t>
      <t indent="0" pn="section-5-2">This document also defines a "TFM" profile (<xref target="sec-tfm-profile" format="default" sectionFormat="of" derivedContent="Section 5.2"/>) that builds on the baseline while constraining the use of COSE algorithms to improve interoperability between Attesters and Verifiers.</t>
      <t indent="0" pn="section-5-3">Baseline and TFM are what the EAT calls a "partial" and "full" profile, respectively. See <xref section="6.2" sectionFormat="of" target="RFC9711" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9711#section-6.2" derivedContent="EAT"/> for further details regarding profiles.</t>
      <section anchor="baseline-profile" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-baseline-profile">Baseline Profile</name>
        <section anchor="sec-token-encoding-and-signing" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.1">
          <name slugifiedName="name-token-encoding-and-signing">Token Encoding and Signing</name>
          <t indent="0" pn="section-5.1.1-1">The PSA attestation token is encoded in CBOR <xref target="STD94" format="default" sectionFormat="of" derivedContent="STD94"/> format.
The CBOR representation of a PSA token <bcp14>MUST</bcp14> be "valid" according to the definition in Section <xref section="1.2" sectionFormat="bare" target="RFC8949" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-1.2" derivedContent="RFC8949"/> of RFC 8949 <xref target="STD94" format="default" sectionFormat="of" derivedContent="STD94"/>.
Besides, only definite-length string, arrays, and maps are allowed.
Given that a PSA Attester is typically found in a constrained device, it <bcp14>MAY</bcp14>
NOT emit CBOR preferred serializations (Section <xref section="4.1" sectionFormat="bare" target="RFC8949" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-4.1" derivedContent="RFC8949"/> of RFC 8949 <xref target="STD94" format="default" sectionFormat="of" derivedContent="STD94"/>).
Therefore, the Verifier <bcp14>MUST</bcp14> be a variation-tolerant CBOR decoder.</t>
          <t indent="0" pn="section-5.1.1-2">Cryptographic protection is obtained by wrapping the <tt>psa-token</tt> claims set in a COSE
Web Token (CWT) <xref target="RFC8392" format="default" sectionFormat="of" derivedContent="RFC8392"/>.  For asymmetric key algorithms, the signature
structure <bcp14>MUST</bcp14> be a tagged (18) COSE_Sign1.  For symmetric key algorithms, the signature
structure <bcp14>MUST</bcp14> be a tagged (17) COSE_Mac0.</t>
          <t indent="0" pn="section-5.1.1-3">Acknowledging the variety of markets, 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 <bcp14>RECOMMENDED</bcp14> that commonly adopted algorithms are
used, such as those discussed in <xref target="RFC9053" format="default" sectionFormat="of" derivedContent="COSE-ALGS"/>.  It is expected that receivers
will accept a wider range of algorithms while Attesters would produce PSA tokens
using only one such algorithm.</t>
          <t indent="0" pn="section-5.1.1-4">The CWT CBOR tag (61) is not used.  An application that needs to exchange PSA
attestation tokens can wrap the serialized COSE_Sign1 or COSE_Mac0 in the media
type defined in <xref target="sec-iana-media-types" format="default" sectionFormat="of" derivedContent="Section 10.2"/> or the CoAP Content-Format defined in
<xref target="sec-iana-coap-content-format" format="default" sectionFormat="of" derivedContent="Section 10.3"/>.</t>
          <t indent="0" pn="section-5.1.1-5">A PSA token is always directly signed by the PSA RoT.  Therefore,
          a PSA-token claims set (<xref target="sec-psa-claims" format="default" sectionFormat="of" derivedContent="Section 4"/>) is never
          carried in a Detached EAT bundle (<xref section="5" sectionFormat="of" target="RFC9711" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9711#section-5" derivedContent="EAT"/>).</t>
        </section>
        <section anchor="freshness-model" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.2">
          <name slugifiedName="name-freshness-model">Freshness Model</name>
          <t indent="0" pn="section-5.1.2-1">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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9334#section-10.2" derivedContent="RFC9334"/> and Section <xref target="RFC9334" section="10.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9334#section-10.3" derivedContent="RFC9334"/> of <xref target="RFC9334" format="default" sectionFormat="of" derivedContent="RFC9334"/>) using
the "nonce" 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 indent="0" pn="section-5.1.2-2">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" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.3">
          <name slugifiedName="name-synopsis">Synopsis</name>
          <t indent="0" pn="section-5.1.3-1"><xref target="tbl-baseline-profile" format="default" sectionFormat="of" derivedContent="Table 3"/> presents a concise view of the requirements described in the preceding sections.</t>
          <table anchor="tbl-baseline-profile" align="center" pn="table-3">
            <name slugifiedName="name-baseline-profile-2">Baseline Profile</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">Issue</th>
                <th align="left" colspan="1" rowspan="1">Profile Definition</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">CBOR/JSON</td>
                <td align="left" colspan="1" rowspan="1">CBOR <bcp14>MUST</bcp14> be used.</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">CBOR Encoding</td>
                <td align="left" colspan="1" rowspan="1">Definite length maps and arrays <bcp14>MUST</bcp14> be used.</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">CBOR Encoding</td>
                <td align="left" colspan="1" rowspan="1">Definite length strings <bcp14>MUST</bcp14> be used.</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">CBOR Serialization</td>
                <td align="left" colspan="1" rowspan="1">Variant serialization <bcp14>MAY</bcp14> be used.</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">COSE Protection</td>
                <td align="left" colspan="1" rowspan="1">COSE_Sign1 and/or COSE_Mac0 <bcp14>MUST</bcp14> be used.</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Algorithms</td>
                <td align="left" colspan="1" rowspan="1">
                  <xref target="RFC9053" format="default" sectionFormat="of" derivedContent="COSE-ALGS"/> <bcp14>SHOULD</bcp14> be used.</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Detached EAT Bundle Usage</td>
                <td align="left" colspan="1" rowspan="1">Detached EAT bundles <bcp14>MUST NOT</bcp14> be sent.</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Verification Key Identification</td>
                <td align="left" colspan="1" rowspan="1">Any identification method listed in <xref section="F.1" sectionFormat="of" target="RFC9711" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9711#appendix-F.1" derivedContent="EAT"/>.</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Endorsements</td>
                <td align="left" colspan="1" rowspan="1">See <xref target="sec-psa-endorsements" format="default" sectionFormat="of" derivedContent="Section 8.2"/>.</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Freshness</td>
                <td align="left" colspan="1" rowspan="1">Nonce or epoch ID-based.</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Claims</td>
                <td align="left" colspan="1" rowspan="1">Those defined in <xref target="sec-psa-claims" format="default" sectionFormat="of" derivedContent="Section 4"/>. As per general EAT rules, the receiver <bcp14>MUST NOT</bcp14> error out on claims it does not understand.</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
      <section anchor="sec-tfm-profile" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-profile-tfm">Profile TFM</name>
        <t indent="0" pn="section-5.2-1">The TFM profile is appropriate for the code base implemented in <xref target="TF-M" format="default" sectionFormat="of" derivedContent="TF-M"/> and should apply for most derivative implementations. If an implementation changes the requirements described below, then a different profile value should be used (<xref target="sec-profile-uri-structure" format="default" sectionFormat="of" derivedContent="Section 4.5.2.1"/>) to ensure interoperability. This includes a restriction of the profile to a subset of the COSE Protection scheme requirements.</t>
        <t indent="0" pn="section-5.2-2"><xref target="tbl-tfm-profile" format="default" sectionFormat="of" derivedContent="Table 4"/> presents a concise view of the requirements.</t>
        <t indent="0" pn="section-5.2-3">The value of the <tt>eat_profile</tt> <bcp14>MUST</bcp14> be <tt>tag:psacertified.org,2023:psa#tfm</tt>.</t>
        <table anchor="tbl-tfm-profile" align="center" pn="table-4">
          <name slugifiedName="name-tf-m-profile">TF-M Profile</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Issue</th>
              <th align="left" colspan="1" rowspan="1">Profile Definition</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">CBOR/JSON</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="baseline-profile" format="default" sectionFormat="of" derivedContent="Section 5.1"/>.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">CBOR Encoding</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="baseline-profile" format="default" sectionFormat="of" derivedContent="Section 5.1"/>.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">CBOR Encoding</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="baseline-profile" format="default" sectionFormat="of" derivedContent="Section 5.1"/>.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">CBOR Serialization</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="baseline-profile" format="default" sectionFormat="of" derivedContent="Section 5.1"/>.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">COSE Protection</td>
              <td align="left" colspan="1" rowspan="1">COSE_Sign1 or COSE_Mac0 <bcp14>MUST</bcp14> be used.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Algorithms</td>
              <td align="left" colspan="1" rowspan="1">The receiver <bcp14>MUST</bcp14> accept ES256, ES384, and ES512 with COSE_Sign1 and HMAC256/256, HMAC384/384, and HMAC512/512 with COSE_Mac0; the sender <bcp14>MUST</bcp14> send one of these.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Detached EAT Bundle Usage</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="baseline-profile" format="default" sectionFormat="of" derivedContent="Section 5.1"/>.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Verification Key Identification</td>
              <td align="left" colspan="1" rowspan="1">Claim-Based Key Identification (<xref section="F.1.4" sectionFormat="of" target="RFC9711" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9711#appendix-F.1.4" derivedContent="EAT"/>) using Instance ID.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Endorsements</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="sec-psa-endorsements" format="default" sectionFormat="of" derivedContent="Section 8.2"/>.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Freshness</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="baseline-profile" format="default" sectionFormat="of" derivedContent="Section 5.1"/>.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Claims</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="baseline-profile" format="default" sectionFormat="of" derivedContent="Section 5.1"/>.</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="collated-cddl" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-collated-cddl">Collated CDDL</name>
      <sourcecode type="cddl" markers="false" pn="section-6-1">
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 =&gt; 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 =&gt; psa-client-id-type
)

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

psa-certification-reference = (
    ? psa-certification-reference-key =&gt;
        psa-certification-reference-type
)

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

psa-implementation-id = (
    psa-implementation-id-key =&gt; psa-implementation-id-type
)

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

psa-instance-id = (
    ueid-label =&gt; psa-instance-id-type
)

psa-nonce = (
    nonce-label =&gt; psa-hash-type
)

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

psa-profile = (
    profile-label =&gt; 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 =&gt; psa-lifecycle-type
)

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

psa-software-components = (
    psa-software-components-key =&gt; [ + psa-software-component ]
)

psa-verification-service-indicator-type = text

psa-verification-service-indicator = (
    ? psa-verification-service-indicator-key =&gt;
        psa-verification-service-indicator-type
)</sourcecode>
    </section>
    <section anchor="sec-scalability" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-scalability-considerations">Scalability Considerations</name>
      <t indent="0" pn="section-7-1">IAKs (see <xref target="sec-psa-attester-model" format="default" sectionFormat="of" derivedContent="Section 3"/>) can be either raw public keys or certified public keys.</t>
      <t indent="0" pn="section-7-2">Certified public keys require the manufacturer to run the certification
authority (CA) that issues X.509 certificates for the IAKs.  (Note that operating a CA
is a complex and expensive task that may be unaffordable to certain
manufacturers.)</t>
      <t indent="0" pn="section-7-3">Using certified public keys offers better scalability properties when compared to using raw public keys, namely:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-4">
        <li pn="section-7-4.1">Storage requirements for the Verifier are minimized; the same
        manufacturer's trust anchor is used for any number of devices.</li>
        <li pn="section-7-4.2">The provisioning model is simpler and more robust since there is no
	need to notify the Verifier about each newly manufactured device.</li>
      </ul>
      <t indent="0" pn="section-7-5">Furthermore, existing and well-understood revocation mechanisms can be readily used.</t>
      <t indent="0" pn="section-7-6">The IAK's X.509 certificates can be inlined in the PSA token using the <tt>x5chain</tt> COSE
header parameter <xref target="RFC9360" format="default" sectionFormat="of" derivedContent="COSE-X509"/> at the cost of an increase in the PSA token
size.  <xref section="4.4" sectionFormat="of" target="RFC7925" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7925#section-4.4" derivedContent="TLS12-IoT"/> and <xref section="15" sectionFormat="of" target="I-D.ietf-uta-tls13-iot-profile" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-uta-tls13-iot-profile-14#section-15" derivedContent="TLS13-IoT"/> provide
guidance for profiling X.509 certificates used in IoT deployments.
Note that the exact split between pre-provisioned and inlined certificates may vary
depending on the specific deployment.  In that respect, <tt>x5chain</tt> is quite
flexible. It can contain the end entity (EE) 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="RFC9360" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9360#section-2" derivedContent="COSE-X509"/> 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" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-psa-token-verification">PSA Token Verification</name>
      <t indent="0" pn="section-8-1">To verify the token, the primary need is to check correct encoding and signing
as detailed in <xref target="sec-token-encoding-and-signing" format="default" sectionFormat="of" derivedContent="Section 5.1.1"/>.
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" format="default" sectionFormat="of" derivedContent="Section 7"/>.
If the IAK is a raw public 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="RFC5280" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5280#section-6" derivedContent="X509"/>) up to a trusted CA <bcp14>MUST</bcp14> be successful before the key is
used to verify the token signature.  This also includes revocation checking.</t>
      <t indent="0" pn="section-8-2">The Verifier typically has a policy where it compares some claims in
  this profile to reference values registered with it for a given
  deployment.  This verification process serves 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" bare="false" empty="false" indent="3" pn="section-8-3">
        <li pn="section-8-3.1">Implementation ID: The value of the Implementation ID can be used
        to identify the verification requirements of the deployment.</li>
        <li pn="section-8-3.2">Software Component, Measurement 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
        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.</li>
        <li pn="section-8-3.3">Software Component, Signer ID: Where present in a deployment, this
        could allow a Verifier to operate a more general policy than that for
        Measurement Value as above by allowing a token to contain any
        firmware entries signed by a known Signer ID without checking for a
        uniquely registered version.</li>
        <li pn="section-8-3.4">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" format="default" sectionFormat="of" derivedContent="PSACertified"/> certificate.</li>
      </ul>
      <section anchor="ar4si-trustworthiness-claims-mappings" numbered="true" removeInRFC="false" toc="include" pn="section-8.1">
        <name slugifiedName="name-ar4si-trustworthiness-claim">AR4SI Trustworthiness Claims Mappings</name>
        <t indent="0" pn="section-8.1-1"><xref target="I-D.ietf-rats-ar4si" format="default" sectionFormat="of" derivedContent="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
environments.</t>
        <t indent="0" pn="section-8.1-2">The contents of <xref target="tab-ar4si-map" format="default" sectionFormat="of" derivedContent="Table 5"/> 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" align="center" pn="table-5">
          <name slugifiedName="name-ar4si-claims-mappings">AR4SI Claims mappings</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Trustworthiness Vector claims</th>
              <th align="left" colspan="1" rowspan="1">Related PSA claims</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                "configuration"</td>
              <td align="left" colspan="1" rowspan="1">Software Components (<xref target="sec-sw-components" format="default" sectionFormat="of" derivedContent="Section 4.4.1"/>)</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                "executables"</td>
              <td align="left" colspan="1" rowspan="1">ditto</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                "file-system"</td>
              <td align="left" colspan="1" rowspan="1">N/A</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                "hardware"</td>
              <td align="left" colspan="1" rowspan="1">Implementation ID (<xref target="sec-implementation-id" format="default" sectionFormat="of" derivedContent="Section 4.2.2"/>)</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                "instance-identity"</td>
              <td align="left" colspan="1" rowspan="1">Instance ID (<xref target="sec-instance-id-claim" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/>).  The Security Lifecycle (<xref target="sec-security-lifecycle" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>) can also impact the derived identity.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                "runtime-opaque"</td>
              <td align="left" colspan="1" rowspan="1">Indirectly derived from "executables", "hardware", and "instance-identity".  The Security Lifecycle (<xref target="sec-security-lifecycle" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>) can also be relevant, e.g., any debug state will expose otherwise protected memory.</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                "sourced-data"</td>
              <td align="left" colspan="1" rowspan="1">N/A</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                "storage-opaque"</td>
              <td align="left" colspan="1" rowspan="1">Indirectly derived from "executables", "hardware", and "instance-identity".</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-8.1-4">This document does not prescribe what value must be chosen based on each
possible 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="I-D.ietf-rats-ar4si" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-rats-ar4si-08#section-2.3.3" derivedContent="RATS-AR4SI"/>.</t>
      </section>
      <section anchor="sec-psa-endorsements" numbered="true" removeInRFC="false" toc="include" pn="section-8.2">
        <name slugifiedName="name-endorsements-reference-valu">Endorsements, Reference Values, and Verification Key Material</name>
        <t indent="0" pn="section-8.2-1"><xref target="I-D.fdb-rats-psa-endorsements" format="default" sectionFormat="of" derivedContent="PSA-Endorsements"/> defines a protocol based on the <xref target="I-D.ietf-rats-corim" format="default" sectionFormat="of" derivedContent="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="security-and-privacy-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-9">
      <name slugifiedName="name-security-and-privacy-consid">Security and Privacy Considerations</name>
      <t indent="0" pn="section-9-1">This specification reuses the EAT specification and therefore the CWT specification.
Hence, the security and privacy considerations of those specifications apply here as well.</t>
      <t indent="0" pn="section-9-2">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 as defined in the COSE specification <xref target="STD96" format="default" sectionFormat="of" derivedContent="STD96"/>.
Note, however, that the use of MAC authentication is <bcp14>NOT RECOMMENDED</bcp14> due to the associated
infrastructure costs for key management and protocol complexities.</t>
      <t indent="0" pn="section-9-3">A PSA Attester <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>
      <t indent="0" pn="section-9-4">Attestation tokens contain information that may be unique to a 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" numbered="true" removeInRFC="false" toc="include" pn="section-10">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="cbor-web-token-claims-registration" numbered="true" removeInRFC="false" toc="include" pn="section-10.1">
        <name slugifiedName="name-cbor-web-token-claims-regis">CBOR Web Token Claims Registration</name>
        <t indent="0" pn="section-10.1-1">IANA has registered the following claims 
in the "CBOR Web Token (CWT) Claims" registry
<xref target="CWT" format="default" sectionFormat="of" derivedContent="CWT"/>.</t>
        <section anchor="client-id-claim" numbered="true" removeInRFC="false" toc="include" pn="section-10.1.1">
          <name slugifiedName="name-client-id-claim">Client ID Claim</name>
          <dl spacing="compact" newline="false" indent="3" pn="section-10.1.1-1">
            <dt pn="section-10.1.1-1.1">Claim Name:</dt>
            <dd pn="section-10.1.1-1.2">psa-client-id</dd>
            <dt pn="section-10.1.1-1.3">Claim Description:</dt>
            <dd pn="section-10.1.1-1.4">PSA Client ID</dd>
            <dt pn="section-10.1.1-1.5">JWT Claim Name:</dt>
            <dd pn="section-10.1.1-1.6">N/A</dd>
            <dt pn="section-10.1.1-1.7">Claim Key:</dt>
            <dd pn="section-10.1.1-1.8">2394</dd>
            <dt pn="section-10.1.1-1.9">Claim Value Type(s):</dt>
            <dd pn="section-10.1.1-1.10">signed integer</dd>
            <dt pn="section-10.1.1-1.11">Change Controller:</dt>
            <dd pn="section-10.1.1-1.12">Hannes Tschofenig</dd>
            <dt pn="section-10.1.1-1.13">Specification Document(s):</dt>
            <dd pn="section-10.1.1-1.14">
              <xref target="sec-client-id" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/> of RFC 9783</dd>
          </dl>
        </section>
        <section anchor="security-lifecycle-claim" numbered="true" removeInRFC="false" toc="include" pn="section-10.1.2">
          <name slugifiedName="name-security-lifecycle-claim">Security Lifecycle Claim</name>
          <dl spacing="compact" newline="false" indent="3" pn="section-10.1.2-1">
            <dt pn="section-10.1.2-1.1">Claim Name:</dt>
            <dd pn="section-10.1.2-1.2">psa-security-lifecycle</dd>
            <dt pn="section-10.1.2-1.3">Claim Description:</dt>
            <dd pn="section-10.1.2-1.4">PSA Security Lifecycle</dd>
            <dt pn="section-10.1.2-1.5">JWT Claim Name:</dt>
            <dd pn="section-10.1.2-1.6">N/A</dd>
            <dt pn="section-10.1.2-1.7">Claim Key:</dt>
            <dd pn="section-10.1.2-1.8">2395</dd>
            <dt pn="section-10.1.2-1.9">Claim Value Type(s):</dt>
            <dd pn="section-10.1.2-1.10">unsigned integer</dd>
            <dt pn="section-10.1.2-1.11">Change Controller:</dt>
            <dd pn="section-10.1.2-1.12">Hannes Tschofenig</dd>
            <dt pn="section-10.1.2-1.13">Specification Document(s):</dt>
            <dd pn="section-10.1.2-1.14">
              <xref target="sec-security-lifecycle" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/> of RFC 9783</dd>
          </dl>
        </section>
        <section anchor="implementation-id-claim" numbered="true" removeInRFC="false" toc="include" pn="section-10.1.3">
          <name slugifiedName="name-implementation-id-claim">Implementation ID Claim</name>
          <dl spacing="compact" newline="false" indent="3" pn="section-10.1.3-1">
            <dt pn="section-10.1.3-1.1">Claim Name:</dt>
            <dd pn="section-10.1.3-1.2">psa-implementation-id</dd>
            <dt pn="section-10.1.3-1.3">Claim Description:</dt>
            <dd pn="section-10.1.3-1.4">PSA Implementation ID</dd>
            <dt pn="section-10.1.3-1.5">JWT Claim Name:</dt>
            <dd pn="section-10.1.3-1.6">N/A</dd>
            <dt pn="section-10.1.3-1.7">Claim Key:</dt>
            <dd pn="section-10.1.3-1.8">2396</dd>
            <dt pn="section-10.1.3-1.9">Claim Value Type(s):</dt>
            <dd pn="section-10.1.3-1.10">byte string</dd>
            <dt pn="section-10.1.3-1.11">Change Controller:</dt>
            <dd pn="section-10.1.3-1.12">Hannes Tschofenig</dd>
            <dt pn="section-10.1.3-1.13">Specification Document(s):</dt>
            <dd pn="section-10.1.3-1.14">
              <xref target="sec-implementation-id" format="default" sectionFormat="of" derivedContent="Section 4.2.2"/> of RFC 9783</dd>
          </dl>
        </section>
        <section anchor="certification-reference-claim" numbered="true" removeInRFC="false" toc="include" pn="section-10.1.4">
          <name slugifiedName="name-certification-reference-cla">Certification Reference Claim</name>
          <dl spacing="compact" newline="false" indent="3" pn="section-10.1.4-1">
            <dt pn="section-10.1.4-1.1">Claim Name:</dt>
            <dd pn="section-10.1.4-1.2">psa-certification-reference</dd>
            <dt pn="section-10.1.4-1.3">Claim Description:</dt>
            <dd pn="section-10.1.4-1.4">PSA Certification Reference</dd>
            <dt pn="section-10.1.4-1.5">JWT Claim Name:</dt>
            <dd pn="section-10.1.4-1.6">N/A</dd>
            <dt pn="section-10.1.4-1.7">Claim Key:</dt>
            <dd pn="section-10.1.4-1.8">2398</dd>
            <dt pn="section-10.1.4-1.9">Claim Value Type(s):</dt>
            <dd pn="section-10.1.4-1.10">text string</dd>
            <dt pn="section-10.1.4-1.11">Change Controller:</dt>
            <dd pn="section-10.1.4-1.12">Hannes Tschofenig</dd>
            <dt pn="section-10.1.4-1.13">Specification Document(s):</dt>
            <dd pn="section-10.1.4-1.14">
              <xref target="sec-certification-reference" format="default" sectionFormat="of" derivedContent="Section 4.2.3"/> of RFC 9783</dd>
          </dl>
        </section>
        <section anchor="software-components-claim" numbered="true" removeInRFC="false" toc="include" pn="section-10.1.5">
          <name slugifiedName="name-software-components-claim">Software Components Claim</name>
          <dl spacing="compact" newline="false" indent="3" pn="section-10.1.5-1">
            <dt pn="section-10.1.5-1.1">Claim Name:</dt>
            <dd pn="section-10.1.5-1.2">psa-software-components</dd>
            <dt pn="section-10.1.5-1.3">Claim Description:</dt>
            <dd pn="section-10.1.5-1.4">PSA Software Components</dd>
            <dt pn="section-10.1.5-1.5">JWT Claim Name:</dt>
            <dd pn="section-10.1.5-1.6">N/A</dd>
            <dt pn="section-10.1.5-1.7">Claim Key:</dt>
            <dd pn="section-10.1.5-1.8">2399</dd>
            <dt pn="section-10.1.5-1.9">Claim Value Type(s):</dt>
            <dd pn="section-10.1.5-1.10">array</dd>
            <dt pn="section-10.1.5-1.11">Change Controller:</dt>
            <dd pn="section-10.1.5-1.12">Hannes Tschofenig</dd>
            <dt pn="section-10.1.5-1.13">Specification Document(s):</dt>
            <dd pn="section-10.1.5-1.14">
              <xref target="sec-sw-components" format="default" sectionFormat="of" derivedContent="Section 4.4.1"/> of RFC 9783</dd>
          </dl>
        </section>
        <section anchor="verification-service-indicator-claim" numbered="true" removeInRFC="false" toc="include" pn="section-10.1.6">
          <name slugifiedName="name-verification-service-indicat">Verification Service Indicator Claim</name>
          <dl spacing="compact" newline="false" indent="3" pn="section-10.1.6-1">
            <dt pn="section-10.1.6-1.1">Claim Name:</dt>
            <dd pn="section-10.1.6-1.2">psa-verification-service-indicator</dd>
            <dt pn="section-10.1.6-1.3">Claim Description:</dt>
            <dd pn="section-10.1.6-1.4">PSA Verification Service Indicator</dd>
            <dt pn="section-10.1.6-1.5">JWT Claim Name:</dt>
            <dd pn="section-10.1.6-1.6">N/A</dd>
            <dt pn="section-10.1.6-1.7">Claim Key:</dt>
            <dd pn="section-10.1.6-1.8">2400</dd>
            <dt pn="section-10.1.6-1.9">Claim Value Type(s):</dt>
            <dd pn="section-10.1.6-1.10">text string</dd>
            <dt pn="section-10.1.6-1.11">Change Controller:</dt>
            <dd pn="section-10.1.6-1.12">Hannes Tschofenig</dd>
            <dt pn="section-10.1.6-1.13">Specification Document(s):</dt>
            <dd pn="section-10.1.6-1.14">
              <xref target="sec-verification-service-indicator" format="default" sectionFormat="of" derivedContent="Section 4.5.1"/> of RFC 9783</dd>
          </dl>
        </section>
      </section>
      <section anchor="sec-iana-media-types" numbered="true" removeInRFC="false" toc="include" pn="section-10.2">
        <name slugifiedName="name-media-types">Media Types</name>
        <t indent="0" pn="section-10.2-1">This document does not register any new media 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="RFC9782" format="default" sectionFormat="of" derivedContent="EAT-MEDIATYPES"/> 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; see <xref target="sec-backwards-compat" format="default" sectionFormat="of" derivedContent="Section 4.6"/>).</t>
      </section>
      <section anchor="sec-iana-coap-content-format" numbered="true" removeInRFC="false" toc="include" pn="section-10.3">
        <name slugifiedName="name-coap-content-formats-regist">CoAP Content-Formats Registration</name>
        <t indent="0" pn="section-10.3-1">IANA has registered two CoAP Content-Format IDs in the First Come First Served range of the "CoAP
Content-Formats" registry <xref target="Content-Formats" format="default" sectionFormat="of" derivedContent="Content-Formats"/>:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-10.3-2">
          <li pn="section-10.3-2.1">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>.</li>
          <li pn="section-10.3-2.2">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>.</li>
        </ul>
        <section anchor="registry-contents" numbered="true" removeInRFC="false" toc="include" pn="section-10.3.1">
          <name slugifiedName="name-registry-contents">Registry Contents</name>
          <dl spacing="compact" newline="false" indent="3" pn="section-10.3.1-1">
            <dt pn="section-10.3.1-1.1">Media Type:</dt>
            <dd pn="section-10.3.1-1.2">
              <tt>application/eat+cwt; eat_profile="tag:psacertified.org,2023:psa#tfm"</tt></dd>
            <dt pn="section-10.3.1-1.3">Encoding:</dt>
            <dd pn="section-10.3.1-1.4">-</dd>
            <dt pn="section-10.3.1-1.5">ID:</dt>
            <dd pn="section-10.3.1-1.6">10003</dd>
            <dt pn="section-10.3.1-1.7">Reference:</dt>
            <dd pn="section-10.3.1-1.8">RFC 9783</dd>
          </dl>
          <dl spacing="compact" newline="false" indent="3" pn="section-10.3.1-2">
            <dt pn="section-10.3.1-2.1">Media Type:</dt>
            <dd pn="section-10.3.1-2.2">
              <tt>application/eat+cwt; eat_profile="tag:psacertified.org,2019:psa#legacy"</tt></dd>
            <dt pn="section-10.3.1-2.3">Encoding:</dt>
            <dd pn="section-10.3.1-2.4">-</dd>
            <dt pn="section-10.3.1-2.5">ID:</dt>
            <dd pn="section-10.3.1-2.6">10004</dd>
            <dt pn="section-10.3.1-2.7">Reference:</dt>
            <dd pn="section-10.3.1-2.8">RFC 9783</dd>
          </dl>
        </section>
      </section>
    </section>
  </middle>
  <back>
    <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" pn="section-11">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-11.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC9053" target="https://www.rfc-editor.org/info/rfc9053" quoteTitle="true" derivedAnchor="COSE-ALGS">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Initial Algorithms</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052).</t>
              <t indent="0">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>
        <reference anchor="CWT" target="https://www.iana.org/assignments/cwt" quoteTitle="true" derivedAnchor="CWT">
          <front>
            <title>CBOR Web Token (CWT) Claims</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="EAN-13" target="https://www.gs1.org/standards/barcodes/ean-upc" quoteTitle="true" derivedAnchor="EAN-13">
          <front>
            <title>EAN/UPC barcodes</title>
            <author>
              <organization showOnFrontPage="true">GS1</organization>
            </author>
          </front>
        </reference>
        <reference anchor="RFC9711" target="https://www.rfc-editor.org/info/rfc9711" quoteTitle="true" derivedAnchor="EAT">
          <front>
            <title>The Entity Attestation Token (EAT)</title>
            <author fullname="L. Lundblade" initials="L." surname="Lundblade"/>
            <author fullname="G. Mandyam" initials="G." surname="Mandyam"/>
            <author fullname="J. O'Donoghue" initials="J." surname="O'Donoghue"/>
            <author fullname="C. Wallace" initials="C." surname="Wallace"/>
            <date month="April" year="2025"/>
            <abstract>
              <t indent="0">An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (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.</t>
              <t indent="0">An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9711"/>
          <seriesInfo name="DOI" value="10.17487/RFC9711"/>
        </reference>
        <reference anchor="RFC9782" target="https://www.rfc-editor.org/info/rfc9782" quoteTitle="true" derivedAnchor="EAT-MEDIATYPES">
          <front>
            <title>Entity Attestation Token (EAT) Media Types</title>
            <author fullname="L. Lundblade" initials="L." surname="Lundblade"/>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
            <author fullname="T. Fossati" initials="T." surname="Fossati"/>
            <date month="May" year="2025"/>
            <abstract>
              <t indent="0">The payloads used in Remote ATtestation procedureS (RATS) may require an associated media type for their conveyance, for example, when the payloads are used in RESTful APIs.</t>
              <t indent="0">This memo defines media types to be used for Entity Attestation Tokens (EATs).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9782"/>
          <seriesInfo name="DOI" value="10.17487/RFC9782"/>
        </reference>
        <reference anchor="NAMED-INFO" target="https://www.iana.org/assignments/named-information" quoteTitle="true" derivedAnchor="NAMED-INFO">
          <front>
            <title>Named Information Hash Algorithm Registry</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </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" quoteTitle="true" derivedAnchor="PSA-Cert-Guide">
          <front>
            <title>PSA Certified Level 2 Step by Step Guide Version 1.1</title>
            <author>
              <organization showOnFrontPage="true">PSA Certified</organization>
            </author>
            <date month="April" year="2020"/>
          </front>
        </reference>
        <reference anchor="PSA-FF" target="https://developer.arm.com/documentation/den0063/a" quoteTitle="true" derivedAnchor="PSA-FF">
          <front>
            <title>Arm PSA Firmware Framework 1.0</title>
            <author>
              <organization showOnFrontPage="true">Arm</organization>
            </author>
          </front>
        </reference>
        <reference anchor="PSA-SM" target="https://www.psacertified.org/app/uploads/2021/12/JSADEN014_PSA_Certified_SM_V1.1_BET0.pdf" quoteTitle="true" derivedAnchor="PSA-SM">
          <front>
            <title>Platform Security Model 1.1</title>
            <author>
              <organization showOnFrontPage="true">Arm</organization>
            </author>
            <date year="2021" month="December"/>
          </front>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC3986" target="https://www.rfc-editor.org/info/rfc3986" quoteTitle="true" derivedAnchor="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 indent="0">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" target="https://www.rfc-editor.org/info/rfc4151" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC8392" target="https://www.rfc-editor.org/info/rfc8392" quoteTitle="true" derivedAnchor="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 indent="0">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>
        <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8610" quoteTitle="true" derivedAnchor="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 indent="0">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>
          </front>
          <seriesInfo name="RFC" value="8610"/>
          <seriesInfo name="DOI" value="10.17487/RFC8610"/>
        </reference>
        <referencegroup anchor="STD94" target="https://www.rfc-editor.org/info/std94" derivedAnchor="STD94">
          <reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949" quoteTitle="true">
            <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 indent="0">The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility 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 indent="0">This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.</t>
              </abstract>
            </front>
            <seriesInfo name="STD" value="94"/>
            <seriesInfo name="RFC" value="8949"/>
            <seriesInfo name="DOI" value="10.17487/RFC8949"/>
          </reference>
        </referencegroup>
        <referencegroup anchor="STD96" target="https://www.rfc-editor.org/info/std96" derivedAnchor="STD96">
          <reference anchor="RFC9052" target="https://www.rfc-editor.org/info/rfc9052" quoteTitle="true">
            <front>
              <title>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 indent="0">Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.</t>
                <t indent="0">This document, along with RFC 9053, obsoletes 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="RFC9338" target="https://www.rfc-editor.org/info/rfc9338" quoteTitle="true">
            <front>
              <title>CBOR Object Signing and Encryption (COSE): Countersignatures</title>
              <author fullname="J. Schaad" initials="J." surname="Schaad"/>
              <date month="December" year="2022"/>
              <abstract>
                <t indent="0">Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. This document updates RFC 9052.</t>
              </abstract>
            </front>
            <seriesInfo name="STD" value="96"/>
            <seriesInfo name="RFC" value="9338"/>
            <seriesInfo name="DOI" value="10.17487/RFC9338"/>
          </reference>
        </referencegroup>
        <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" quoteTitle="true" derivedAnchor="X509">
          <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 indent="0">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>
      </references>
      <references anchor="sec-informative-references" pn="section-11.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="Content-Formats" target="https://www.iana.org/assignments/core-parameters" quoteTitle="true" derivedAnchor="Content-Formats">
          <front>
            <title>CoAP Content-Formats</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="RFC9360" target="https://www.rfc-editor.org/info/rfc9360" quoteTitle="true" derivedAnchor="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 indent="0">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 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="IAT-VERIFIER" target="https://git.trustedfirmware.org/plugins/gitiles/TF-M/tf-m-tools/+/refs/heads/main/iat-verifier/" quoteTitle="true" derivedAnchor="IAT-VERIFIER">
          <front>
            <title>iat-verifier</title>
            <author>
              <organization showOnFrontPage="true">Trusted Firmware</organization>
            </author>
            <date year="2023" month="August" day="18"/>
          </front>
          <refcontent>commit: 0b49b00195b7733d6fe74e8f42ed4d7b81242801</refcontent>
        </reference>
        <reference anchor="PSA" target="https://developer.arm.com/documentation/101892/0100/Security---Platform-Security-Architecture?lang=en" quoteTitle="true" derivedAnchor="PSA">
          <front>
            <title>Security - Platform Security Architecture</title>
            <author>
              <organization showOnFrontPage="true">Arm</organization>
            </author>
          </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" quoteTitle="true" derivedAnchor="PSA-API">
          <front>
            <title>PSA Certified Attestation API 1.0</title>
            <author>
              <organization showOnFrontPage="true">Arm</organization>
            </author>
            <date month="October" year="2022"/>
          </front>
        </reference>
        <reference anchor="I-D.fdb-rats-psa-endorsements" target="https://datatracker.ietf.org/doc/html/draft-fdb-rats-psa-endorsements-06" quoteTitle="true" derivedAnchor="PSA-Endorsements">
          <front>
            <title>A CoRIM Profile for Arm's Platform Security Architecture (PSA)</title>
            <author fullname="Thomas Fossati" initials="T." surname="Fossati">
              <organization showOnFrontPage="true">Arm Ltd</organization>
            </author>
            <author fullname="Yogesh Deshpande" initials="Y." surname="Deshpande">
              <organization showOnFrontPage="true">Arm Ltd</organization>
            </author>
            <author fullname="Henk Birkholz" initials="H." surname="Birkholz">
              <organization showOnFrontPage="true">Fraunhofer SIT</organization>
            </author>
            <date day="3" month="March" year="2025"/>
            <abstract>
              <t indent="0">PSA Endorsements include reference values, endorsed values, cryptographic key material and certification status information that a Verifier may need in order to appraise attestation Evidence produced by a PSA device. This memo defines PSA Endorsements as a profile of the CoRIM data model.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-fdb-rats-psa-endorsements-06"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.tschofenig-rats-psa-token" target="https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-07" quoteTitle="true" derivedAnchor="PSA-OLD">
          <front>
            <title>Arm's Platform Security Architecture (PSA) Attestation Token</title>
            <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig"/>
            <author fullname="Simon Frost" initials="S." surname="Frost"/>
            <author fullname="Mathias Brossard" initials="M." surname="Brossard"/>
            <author fullname="Adrian L. Shaw" initials="A. L." surname="Shaw"/>
            <author fullname="Thomas Fossati" initials="T." surname="Fossati"/>
            <date day="1" month="February" year="2021"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-tschofenig-rats-psa-token-07"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="PSACertified" target="https://psacertified.org" quoteTitle="true" derivedAnchor="PSACertified">
          <front>
            <title>PSA Certified: IoT Security Framework and Certification</title>
            <author>
              <organization showOnFrontPage="true">PSA Certified</organization>
            </author>
          </front>
        </reference>
        <reference anchor="I-D.ietf-rats-ar4si" target="https://datatracker.ietf.org/doc/html/draft-ietf-rats-ar4si-08" quoteTitle="true" derivedAnchor="RATS-AR4SI">
          <front>
            <title>Attestation Results for Secure Interactions</title>
            <author fullname="Eric Voit" initials="E." surname="Voit">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author fullname="Henk Birkholz" initials="H." surname="Birkholz">
              <organization showOnFrontPage="true">Fraunhofer SIT</organization>
            </author>
            <author fullname="Thomas Hardjono" initials="T." surname="Hardjono">
              <organization showOnFrontPage="true">MIT</organization>
            </author>
            <author fullname="Thomas Fossati" initials="T." surname="Fossati">
              <organization showOnFrontPage="true">Linaro</organization>
            </author>
            <author fullname="Vincent Scarlata" initials="V." surname="Scarlata">
              <organization showOnFrontPage="true">Intel</organization>
            </author>
            <date day="6" month="February" year="2025"/>
            <abstract>
              <t indent="0">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. This document also defines two serialisations of the proposed information model, utilising CBOR and JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-rats-ar4si-08"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-rats-corim" target="https://datatracker.ietf.org/doc/html/draft-ietf-rats-corim-07" quoteTitle="true" derivedAnchor="RATS-CoRIM">
          <front>
            <title>Concise Reference Integrity Manifest</title>
            <author fullname="Henk Birkholz" initials="H." surname="Birkholz">
              <organization showOnFrontPage="true">Fraunhofer SIT</organization>
            </author>
            <author fullname="Thomas Fossati" initials="T." surname="Fossati">
              <organization showOnFrontPage="true">Linaro</organization>
            </author>
            <author fullname="Yogesh Deshpande" initials="Y." surname="Deshpande">
              <organization showOnFrontPage="true">arm</organization>
            </author>
            <author fullname="Ned Smith" initials="N." surname="Smith">
              <organization showOnFrontPage="true">Intel</organization>
            </author>
            <author fullname="Wei Pan" initials="W." surname="Pan">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <date day="3" month="March" year="2025"/>
            <abstract>
              <t indent="0">Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-rats-corim-07"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.mandyam-rats-qwestoken" target="https://datatracker.ietf.org/doc/html/draft-mandyam-rats-qwestoken-00" quoteTitle="true" derivedAnchor="RATS-QWESTOKEN">
          <front>
            <title>The Qualcomm Wireless Edge Services (QWES) Attestation Token</title>
            <author fullname="Giridhar Mandyam" initials="G." surname="Mandyam">
              <organization showOnFrontPage="true">Qualcomm Technologies Inc.</organization>
            </author>
            <author fullname="Vivek Sekhar" initials="V." surname="Sekhar">
              <organization showOnFrontPage="true">Qualcomm Technologies Inc.</organization>
            </author>
            <author fullname="Shahid Mohammed" initials="S." surname="Mohammed">
              <organization showOnFrontPage="true">Qualcomm Technologies Inc.</organization>
            </author>
            <date day="1" month="November" year="2019"/>
            <abstract>
              <t indent="0">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 as any CBOR Web Token (CWT).</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-mandyam-rats-qwestoken-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.kdyxy-rats-tdx-eat-profile" target="https://datatracker.ietf.org/doc/html/draft-kdyxy-rats-tdx-eat-profile-02" quoteTitle="true" derivedAnchor="RATS-TDX">
          <front>
            <title>EAT profile for Intel(r) Trust Domain Extensions (TDX) attestation result</title>
            <author fullname="Greg Kostal" initials="G." surname="Kostal">
              <organization showOnFrontPage="true">Microsoft</organization>
            </author>
            <author fullname="Sindhuri Dittakavi" initials="S." surname="Dittakavi">
              <organization showOnFrontPage="true">Microsoft</organization>
            </author>
            <author fullname="Raghuram Yeluri" initials="R." surname="Yeluri">
              <organization showOnFrontPage="true">Intel</organization>
            </author>
            <author fullname="Haidong Xia" initials="H." surname="Xia">
              <organization showOnFrontPage="true">Intel</organization>
            </author>
            <author fullname="Jerry Yu" initials="J." surname="Yu">
              <organization showOnFrontPage="true">Intel</organization>
            </author>
            <date day="13" month="December" year="2024"/>
            <abstract>
              <t indent="0">Intel® Trust Domain Extensions (TDX) introduce architectural elements designed for the deployment of hardware-isolated virtual machines (VMs) known 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-02"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC9334" target="https://www.rfc-editor.org/info/rfc9334" quoteTitle="true" derivedAnchor="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 indent="0">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>
        <reference anchor="TF-M" target="https://www.trustedfirmware.org/projects/tf-m/" quoteTitle="true" derivedAnchor="TF-M">
          <front>
            <title>Trusted Firmware-M</title>
            <author>
              <organization showOnFrontPage="true">Trusted Firmware</organization>
            </author>
          </front>
        </reference>
        <reference anchor="RFC7925" target="https://www.rfc-editor.org/info/rfc7925" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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="I-D.ietf-uta-tls13-iot-profile" target="https://datatracker.ietf.org/doc/html/draft-ietf-uta-tls13-iot-profile-14" quoteTitle="true" derivedAnchor="TLS13-IoT">
          <front>
            <title>TLS/DTLS 1.3 Profiles for the Internet of Things</title>
            <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
              <organization showOnFrontPage="true">University of Applied Sciences Bonn-Rhein-Sieg</organization>
            </author>
            <author fullname="Thomas Fossati" initials="T." surname="Fossati">
              <organization showOnFrontPage="true">Linaro</organization>
            </author>
            <author fullname="Michael Richardson" initials="M." surname="Richardson">
              <organization showOnFrontPage="true">Sandelman Software Works</organization>
            </author>
            <date day="5" month="May" year="2025"/>
            <abstract>
              <t indent="0">RFC 7925 offers guidance to developers on using TLS/DTLS 1.2 for Internet of Things (IoT) devices with resource constraints. This document is a companion to RFC 7925, defining TLS/DTLS 1.3 profiles for IoT devices. Additionally, it updates RFC 7925 with respect to the X.509 certificate profile and ciphersuite requirements. 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-14"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="examples" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-examples">Examples</name>
      <t indent="0" pn="section-appendix.a-1">The following examples show PSA attestation tokens for a hypothetical system
comprising a single measured software component.
The attesting device is in a lifecycle state (<xref target="sec-security-lifecycle" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>) of
SECURED.  The attestation has been requested from a client residing in the
SPE.</t>
      <t indent="0" pn="section-appendix.a-2">The example in <xref target="ex-sign1" format="default" sectionFormat="of" derivedContent="Appendix A.1"/> illustrates the case where the IAK is an asymmetric key.  A COSE Sign1 envelope is used to wrap the PSA-token claims set.</t>
      <t indent="0" pn="section-appendix.a-3"><xref target="ex-mac0" format="default" sectionFormat="of" derivedContent="Appendix A.2"/> illustrates the case where the IAK is a symmetric key and a COSE Mac0 envelope is used instead.</t>
      <t indent="0" pn="section-appendix.a-4">The claims sets are identical, except for the Instance ID which is synthesized from the key material.</t>
      <t indent="0" pn="section-appendix.a-5">The examples have been created using the <tt>iat-verifier</tt> tool <xref target="IAT-VERIFIER" format="default" sectionFormat="of" derivedContent="IAT-VERIFIER"/>.</t>
      <section anchor="ex-sign1" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.1">
        <name slugifiedName="name-cose-sign1-token">COSE Sign1 Token</name>
        <sourcecode markers="false" pn="section-appendix.a.1-1">
{
  / 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"
    }
  ]
}</sourcecode>
        <t indent="0" pn="section-appendix.a.1-2">The JWK representation of the IAK used for creating the COSE Sign1 signature
over the PSA token is:</t>
        <sourcecode markers="false" pn="section-appendix.a.1-3">
{
  "kty": "EC",
  "crv": "P-256",
  "alg": "ES256",
  "x": "Tl4iCZ47zrRbRG0TVf0dw7VFlHtv18HInYhnmMNybo8",
  "y": "gNcLhAslaqw0pi7eEEM2TwRAlfADR0uR4Bggkq-xPy4",
  "d": "Q__-y5X4CFp8QOHT6nkL7063jN131YUDpkwWAPkbM-c"
}</sourcecode>
        <t indent="0" pn="section-appendix.a.1-4">The resulting COSE object is:</t>
        <sourcecode markers="false" pn="section-appendix.a.1-5">
18([
  h'A10126',
  {},
  h'A81901005821010202020202020202020202020202020202020202020202
02020202020202020219095C5820000000000000000000000000000000000000
00000000000000000000000000000A5820010101010101010101010101010101
010101010101010101010101010101010119095A1A7FFFFFFF19095B19300019
010978217461673A7073616365727469666965642E6F72672C323032333A7073
612374666D19010C48000000000000000019095F81A305582004040404040404
0404040404040404040404040404040404040404040404040402582003030303
0303030303030303030303030303030303030303030303030303030301645052
6F54',
  h'786E937A4C42667AF3847399319CA95C7E7DBABDC9B50FDB8DE3F6BFF4AB
82FF80C42140E2A488000219E3E10663193DA69C75F52B798EA10B2F7041A90E
8E5A'
])</sourcecode>
        <t indent="0" pn="section-appendix.a.1-6">which has the following base16 encoding:</t>
        <sourcecode markers="false" pn="section-appendix.a.1-7">
d28443a10126a0590100a819010058210102020202020202020202020202
0202020202020202020202020202020202020219095c5820000000000000
00000000000000000000000000000000000000000000000000000a582001
010101010101010101010101010101010101010101010101010101010101
0119095a1a7fffffff19095b19300019010978217461673a707361636572
7469666965642e6f72672c323032333a7073612374666d19010c48000000
000000000019095f81a30558200404040404040404040404040404040404
040404040404040404040404040404025820030303030303030303030303
0303030303030303030303030303030303030303016450526f545840786e
937a4c42667af3847399319ca95c7e7dbabdc9b50fdb8de3f6bff4ab82ff
80c42140e2a488000219e3e10663193da69c75f52b798ea10b2f7041a90e
8e5a</sourcecode>
      </section>
      <section anchor="ex-mac0" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.2">
        <name slugifiedName="name-cose-mac0-token">COSE Mac0 Token</name>
        <sourcecode markers="false" pn="section-appendix.a.2-1">
{
  / 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"
    }
  ]
}</sourcecode>
        <t indent="0" pn="section-appendix.a.2-2">The JWK representation of the IAK used for creating the COSE Mac0 signature
over the PSA token is:</t>
        <sourcecode markers="false" pn="section-appendix.a.2-3">
========== NOTE: '\\' line wrapping per RFC 8792 ==========

{
  "kty": "oct",
  "alg": "HS256",
  "k": "3gOLNKyhJXaMXjNXq40Gs2e5qw1-i-Ek7cpH_gM6W7epPTB_8imqNv8k\
       \bBKVlk-s9xq3qm7E_WECt7OYMlWtkg"
}</sourcecode>
        <t indent="0" pn="section-appendix.a.2-4">The resulting COSE object is:</t>
        <sourcecode markers="false" pn="section-appendix.a.2-5">
17([
  h'A10105',
  {},
  h'A8190100582101C557BD4FADC83F756FCA2CD5EA2DCC8B82159BB4E7453D
6A744D4EECD6D0AC6019095C5820000000000000000000000000000000000000
00000000000000000000000000000A5820010101010101010101010101010101
010101010101010101010101010101010119095A1A7FFFFFFF19095B19300019
010978217461673A7073616365727469666965642E6F72672C323032333A7073
612374666D19010C48000000000000000019095F81A305582004040404040404
0404040404040404040404040404040404040404040404040402582003030303
0303030303030303030303030303030303030303030303030303030301645052
6F54',
  h'CF88D330E7A5366A95CF744A4DBF0D50304D405EDD8B2530E243EDDBD317
7820'
])</sourcecode>
        <t indent="0" pn="section-appendix.a.2-6">which has the following base16 encoding:</t>
        <sourcecode markers="false" pn="section-appendix.a.2-7">
d18443a10105a0590100a8190100582101c557bd4fadc83f756fca2cd5ea
2dcc8b82159bb4e7453d6a744d4eecd6d0ac6019095c5820000000000000
00000000000000000000000000000000000000000000000000000a582001
010101010101010101010101010101010101010101010101010101010101
0119095a1a7fffffff19095b19300019010978217461673a707361636572
7469666965642e6f72672c323032333a7073612374666d19010c48000000
000000000019095f81a30558200404040404040404040404040404040404
040404040404040404040404040404025820030303030303030303030303
0303030303030303030303030303030303030303016450526f545820cf88
d330e7a5366a95cf744a4dbf0d50304d405edd8b2530e243eddbd3177820</sourcecode>
      </section>
    </section>
    <section numbered="false" anchor="acknowledgments" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.b-1">Thank you <contact fullname="Carsten Bormann"/> for help with the
      CDDL.  Thanks to <contact fullname="Nicholas Wood"/>, <contact fullname="Eliot Lear"/>, <contact fullname="Yaron Sheffer"/>, <contact fullname="Kathleen Moriarty"/>, and <contact fullname="Ned Smith"/> for
      ideas, comments, and suggestions.</t>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.c">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact initials="L." surname="Lundblade" fullname="Laurence Lundblade">
        <organization showOnFrontPage="true">Security Theory LLC</organization>
        <address>
          <email>lgl@securitytheory.com</email>
        </address>
      </contact>
      <contact initials="T." surname="Ban" fullname="Tamas Ban">
        <organization showOnFrontPage="true">Arm Limited</organization>
        <address>
          <email>Tamas.Ban@arm.com</email>
        </address>
      </contact>
      <contact initials="S." surname="Trofimov" fullname="Sergei Trofimov">
        <organization showOnFrontPage="true">Arm Limited</organization>
        <address>
          <email>Sergei.Trofimov@arm.com</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
        <organization abbrev="H-BRS" showOnFrontPage="true">University of Applied Sciences Bonn-Rhein-Sieg</organization>
        <address>
          <postal>
            <country>Germany</country>
          </postal>
          <email>Hannes.Tschofenig@gmx.net</email>
        </address>
      </author>
      <author initials="S." surname="Frost" fullname="Simon Frost">
        <organization showOnFrontPage="true">Arm Limited</organization>
        <address>
          <email>Simon.Frost@arm.com</email>
        </address>
      </author>
      <author initials="M." surname="Brossard" fullname="Mathias Brossard">
        <organization showOnFrontPage="true">Arm Limited</organization>
        <address>
          <email>Mathias.Brossard@arm.com</email>
        </address>
      </author>
      <author initials="A." surname="Shaw" fullname="Adrian Shaw">
        <organization showOnFrontPage="true">HP Labs</organization>
        <address>
          <email>adrianlshaw@acm.org</email>
        </address>
      </author>
      <author initials="T." surname="Fossati" fullname="Thomas Fossati">
        <organization showOnFrontPage="true">Linaro</organization>
        <address>
          <email>thomas.fossati@linaro.org</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
