]> AMD

fabrizio.damato@amd.com

Altera

andrew.draper@altera.com

Intel Corporation

ned.smith@intel.com

Security Remote ATtestation ProcedureS Evidence, RATS, attestation, verifier, supply chain, RIM, appraisal Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester to decide if continued interaction is warrented. Evidence structures can vary making appraisals challenging for Verifiers. Verifiers need to understand Evidence encoding formats and some of the Evidence semantics to appraise it. Consequently, Evidence may require format transformation to an internal representation that preserves original semantics. This document specifies Evidence transformation methods for DiceTcbInfo, concise evidence, and SPDM measurements block structures. These Evidence structures are converted to the CoRIM internal representation and follow CoRIM defined appraisal procedures.

Introduction Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester to decide if continued interaction is warrented. Evidence structures can vary making appraisals challenging for Verifiers. Verifiers need to understand Evidence encoding formats and some of the Evidence semantics to appraise it. Consequently, Evidence may require format transformation to an internal representation that preserves original semantics. This document specifies Evidence transformation methods for DiceTcbInfo , concise evidence , and SPDM measurements block structures. These Evidence structures are converted to the CoRIM internal representation (Section 2.1 ) and follow CoRIM defined appraisal procedures (Section 8 ).

Terminology This document uses terms and concepts defined by the RATS architecture. For a complete glossary. See . Addintional RATS architecture and terminology is found in . RATS architecture terms and concepts are always referenced as proper nouns, i.e., with Capital Letters. Additional terminology from CoRIM , , CBOR , CDDL and COSE may also apply. In this document, Evidence structures are expressed in their respective "external representations". There are many possible Evidence structures including those mentioned above. The CoRIM specification defines an "internal representation" for Evidence (Section 8.2.1.3 ). This document defines mapping operations that convert from an external representation to an internal representation. The conversion steps are also known as "transformation". The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Verifier Reconciliation This document assumes the reader is familiar with Verifier reconciliation as described in . It describes how a Verifier should process the CoRIM to enable CoRIM authors to convey their intended meaning and how a Verifier reconciles its various inputs. Evidence is one of its inputs. The Verifier is expected to create an internal representation from an external representation. By using an internal representation, the Verifier processes Evidence inputs such that they can be appraised consistently. This document defines format transformations for Evidence in DICE , SPDM , and concise evidence formats that are transformed into a Verifier's internal representation. This document uses the CoMID internal representation () as the transformation target. Other internal representations are possible but out of scope for this document.

Transforming DICE Certificate Extension Evidence This section defines how Evidence from an X.509 certificate containing a DICE certificate extension is transformed into an internal representation that can be processed by Verifiers. Verifiers supporting the DICE certificate Evidence extensions SHOULD implement this transformation.

DiceTcbInfo Transformation This section defines transformation methods for DICE certificate extensions DiceTcbInfo, DiceMultiTcbInfo, and DiceMultiTcbInfoComp. These extensions are identified by the following object identifiers:

• tcg-dice-TcbInfo - "2.23.133.5.4.1"
• tcg-dice-MultiTcbInfo - "2.23.133.5.4.5"
• tcg-dice-MultiTcbInfoComp - "2.23.133.5.4.8"

Each DiceTcbInfo entry in a MultiTcbInfo is converted to a CoRIM ECT (see ) using the transformation steps in this section. Each DiceMultiTcbInfo entry is independent of the others such that each is transformed to a separate ECT entry. A list of Evidence ECTs (i.e., ae = [ + ECT]) is constructed using CoRIM attestation evidence internal representation (see ). Each DiceMultiTcbInfoComp entry is converted to a DiceMultiTcbInfo entry then processed as a DiceMultiTcbInfo. For each DiceTcbInfo (DTI) entry in a DiceMultiTcbInfo allocate an ECT structure.

1. An ae entry is allocated.
2. The cmtype of the ECT is set to evidence.
3. The DiceTcbInfo (DTI) entry populates the ae ECT.

1. The DTI entry populates the ae ECT environment-map

• • copy(DTI.type, ECT.environment.environment-map.class-map.class-id). The binary representation of DTI.type MUST be equivalent to the binary representation of class-id without the CBOR tag.

• • copy(DTI.vendor, ECT.environment.environment-map.class-map.vendor).

• • copy(DTI.model, ECT.environment.environment-map.class-map.model).

• • copy(DTI.layer, ECT.environment.environment-map.class-map.layer).

• • copy(DTI.index, ECT.environment.environment-map.class-map.index).

1. The DTI entry populates the ae ECT elemenet-list.

• • copy(DTI.version, ECT.element-list.element-map.measurement-values-map.version-map.version).

• • copy(DTI.svn, ECT.element-list.element-map.measurement-values-map.svn).

• • copy(DTI.vendorInfo, ECT.element-list.element-map.measurement-values-map.raw-value).

• • Foreach FWID in FWIDLIST: copy(DTI.FWID.digest, ECT.element-list.element-map.measurement-values-map.digests.digest.val).

• • Foreach FWID in FWIDLIST: copy(DTI.FWID.hashAlg, ECT.element-list.element-map.measurement-values-map.digests.digest.alg).

1. The DTI entry populates the ae ECT elemenet-list.flags. Foreach f in DTI.OperationalFlags and each m in DTI.OperationalFlagsMask:

• • If m.notConfigured = 1 AND f.notConfigured = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-configured = FALSE).

• • If m.notConfigured = 1 AND f.notConfigured = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-configured = TRUE).

• • If m.notSecure = 1 AND f.notSecure = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-secure = FALSE).

• • If m.notSecure = 1 AND f.notSecure = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-secure = TRUE).

• • If m.recovery = 1 AND f.recovery = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-recovery = FALSE).

• • If m.recovery = 1 AND f.recovery = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-recovery = TRUE).

• • If m.debug = 1 AND f.debug = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-debug = FALSE).

• • If m.debug = 1 AND f.debug = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-debug = TRUE).

• • If m.notReplayProtected = 1 AND f.notReplayProtected = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-replay-protected = FALSE).

• • If m.notReplayProtected = 1 AND f.notReplayProtected = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-replay-protected = TRUE).

• • If m.notIntegrityProtected = 1 AND f.notIntegrityProtected = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-integrity-proteccted = FALSE).

• • If m.notIntegrityProtected = 1 AND f.notIntegrityProtected = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-integrity-proteccted = TRUE).

• • If m.notRuntimeMeasured = 1 AND f.notRuntimeMeasured = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-runtime-meas = FALSE).

• • If m.notRuntimeMeasured = 1 AND f.notRuntimeMeasured = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-runtime-meas = TRUE).

• • If m.notImmutable = 1 AND f.notImmutable = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-immutable = FALSE).

• • If m.notImmutable = 1 AND f.notImmutable = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-immutable = TRUE).

• • If m.notTcb = 1 AND f.notTcb = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-tcb = FALSE).

• • If m.notTcb = 1 AND f.notTcb = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-tcb = TRUE).

1. The ECT.authority field is set up based on the signer of the certificate containing DTI as described in .

The completed ECT is added to the ae list.

DiceUeid Transformation This section defines the transformation method for the DiceUeid certificate extension. This extension is identified by the following object identifier:

• tcg-dice-Ueid - "2.23.133.5.4.4"

1. An ae entry is allocated.
2. The cmtype of the ECT is set to evidence.
3. The DiceUeid entry populates the ae ECT environment-map.instance-id.tagged-ueid-type. The CBOR tag #6.550 is prepended to the DiceUeid OCTET STRING then copied to ae.environment-map.instance-id.
4. The ECT.authority field is set up based on the signer of the certificate containing DiceUeid as described in .

The completed ECT is added to the ae list.

DiceConceptualMessageWrapper Transformation This section defines the transformation method for the DiceConceptualMessageWrapper certificate extension. This extension is identified by the following object identifier:

• tcg-dice-Ueid - "2.23.133.5.4.9"

The DiceConceptualMessageWrapper entry OCTET STRING may contain a CBOR array, JSON array, or CBOR tagged value. If the entry contains a CBOR tag value of #6.571 or #6.1668557429, or a Content ID of 10571, or a Media Type of "application/ce+cbor", the contents are transformed according to .

Authority field in DICE/SPDM ECTs The ECT authority field is an array of $crypto-keys-type-choice values. When adding Evidence to the ACS, the Verifier SHALL add the public key representing the signer of that Evidence (for example the DICE certificate or SPDM MEASUREMENTS response) to the ECT authority field. The Verifier SHALL add the authority of the signers of each certificate in the certificate path of the end-entity signing key to the ECT authority list. Having each authority in a certificate path in the ECT authority field lets conditional endorsement conditions match multiple authorities or match an authority that is scoped more broadly than the immediate signer of the Evidence artifact. Each signer authority value MUST be represented using tagged-cose-key-type.

Transforming TCG Concise Evidence This section defines how Evidence from TCG is transformed into an internal representation that can be processed by Verifiers. Verifiers supporting the TCG Concise Evidence format SHOULD implement this transformation. Concise evidence may be recognized by any of the following registered types:

CBOR tag	C-F ID	TN Tag	Media Type
#6.571	10571	#6.1668557429	"application/ce+cbor"

A Concise Evidence entry is converted to a CoRIM ECT (see ) using the transformation steps in this section. A list of Evidence ECTs (i.e., ae = [ + ECT]) is constructed using CoRIM attestation evidence internal representation (see ). The Concise Evidence scheme uses CoRIM CDDL definitions to define several Evidence representations called triples. Cases where Concise Evidence CDDL is identical to CoRIM CDDL the transformation logic uses the structure names in common.

Transforming the ce.evidence-triples The ce.evidence-triples structure is a list of evidence-triple-record. An evidence-triple-record consists of an environment-map and a list of measurement-map. For each evidence-triple-record an ae ECT is constructed.

1. An ae ECT entry is allocated.
2. The cmtype of the ECT is set to evidence.
3. The Concise Evidence (CE) entry populates the ae ECT environment fields.

• • copy(CE.evidence-triple-record.environment-map, ECT.environment.environment-map).

1. For each ce in CE.[ + measurement-map]; and each ect in ECT.[ + element-list]:

• • copy(ce.mkey, ect.element-map.element-id)

• • copy(ce.mval, ect.element-map.element-claims`)

1. The signer of the envelope containing CE is copied to the ECT.authority field as described in . For example, a CE may be wrapped by an EAT token or DICE certificate . The signer identity MUST be expressed using $crypto-key-type-choice. A profile or other arrangement is used to coordinate which $crypto-key-type-choice is used for both Evidence and Reference Values.
2. If CE has a profile, the profile is converted to a $profile-type-choice then copied to the ECT.profile` field.

The completed ECT is added to the ae list.

Transforming the ce.identity-triples The ce.identity-triples structure is a list of ev-identity-triple-record. An ev-identity-triple-record consists of an environment-map and a list of $crypto-key-type-choice. For each ev-identity-triple-record an ae ECT is constructed where the $crypto-key-type-choice values are copied as ECT Evidence measurement values. The ECT internal representation accommodates keys as a type of measurement. In order for the $crypto-key-type-choice keys to be verified a CoRIM identity-triples claim MUST be asserted.

1. An ae ECT entry is allocated.
2. The cmtype of the ECT is set to evidence.
3. The Concise Evidence (CE) entry populates the ae ECT environment fields.

• • copy(CE.ce-identity-triple-record.environment-map, ECT.environment.environment-map).

• • copy(null, ECT.element-list.element-map.element-id).

1. For each cek in CE.[ + $crypto-key-type-choice ]; and each ect in ECT.element-list.element-map.element-claims.intrep-keys.[ + typed-crypto-key ]:

• • copy(cek, ect.key)

• • set( &(identity-key: 1), ect.key-type)

1. The signer of the envelope containing CE is copied to the ECT.authority field. For example, a CE may be wrapped by an EAT token or DICE certificate . The signer identity MUST be expressed using $crypto-key-type-choice. A profile or other arrangement is used to coordinate which $crypto-key-type-choice is used for both Evidence and Reference Values.
2. If CE has a profile, the profile is converted to a $profile-type-choice then copied to the ECT.profile` field.

The completed ECT is added to the ae list.

Transforming the ce.attest-key-triples The ce.attest-key-triples structure is a list of ev-attest-key-triple-record. An ev-attest-key-triple-record consists of an environment-map and a list of $crypto-key-type-choice. For each ev-attest-key-triple-record an ae ECT is constructed where the $crypto-key-type-choice values are copied as ECT Evidence measurement values. The ECT internal representation accommodates keys as a type of measurement. In order for the $crypto-key-type-choice keys to be verified a CoRIM attest-key-triples claim MUST be asserted.

1. An ae ECT entry is allocated.
2. The cmtype of the ECT is set to evidence.
3. The Concise Evidence (CE) entry populates the ae ECT environment fields.

• • copy(CE.ce-attest-key-triple-record.environment-map, ECT.environment.environment-map).

• • copy(null, ECT.element-list.element-map.element-id).

1. For each cek in CE.[ + $crypto-key-type-choice ]; and each ect in ECT.element-list.element-map.element-claims.intrep-keys.[ + typed-crypto-key ]:

• • copy(cek, ect.key)

• • set( &(attest-key: 0), ect.key-type)

1. The signer of the envelope containing CE is copied to the ECT.authority field. For example, a CE may be wrapped by an EAT token or DICE certificate . The signer identity MUST be expressed using $crypto-key-type-choice. A profile or other arrangement is used to coordinate which $crypto-key-type-choice is used for both Evidence and Reference Values.
2. If CE has a profile, the profile is converted to a $profile-type-choice then copied to the ECT.profile` field.

The completed ECT is added to the ae list.

DMTF SPDM Structure Definitons This section defines how a Verifier shall parse a DMTF Measurement Block. DMTF Measurement Block Definition:

• Byte Offset 0: DMTFSpecMeasurementValueType
  • Bit 7 = 0b Digest / 1b Raw bit stream
  • Bit [6:0] = Indicate what is measured
    • 0x0 Immutable Rom
    • 0x1 Mutable FW
    • 0x2 HW Config
    • 0x3 FW config
    • 0x4 Freeform Manifest
    • 0x5 Structured Representation of debug and device mode
    • 0x6 Mutable FW Version Number
    • 0x7 Mutable FW Secure Version Number
    • 0x8 Hash-Extend Measurement (new in SPDM 1.3)
    • 0x9 Informational (new in SPDM 1.3)
    • 0xA Structured Measurement Manifest (new in SPDM 1.3)
• Byte Offset 1: DMTFSpecMeasurementValueSize
• Byte Offset 3: DMTFSpecMeasurementValue

Structured Manifest Block Definition (only for >=SPDM 1.3):

• Byte Offset 0: Standard Body or Vendor Defined Header (SVH)
• Byte Offset 2 + VendorIdLen: Manifest

Standard Body or Vendor Defined Header (SVH) Definition (only for >=SPDM 1.3):

• Byte Offset 0: ID
• Byte Offset 1: VendorIdLen
• Byte Offset 2: VendorId

DMTF Header for Concise Evidence Manifest Block: If SPDM Version 1.2:

• DMTFSpecMeasurementValueType = 0x84 (Raw Bit / Freeform Manifest)
• DMTFSpecMeasurementValueSize = Size of tagged-spdm-toc CBOR Tag
• DMTFSpecMeasurementValue = tagged-spdm-toc CBOR Tag

if SPDM >=Version 1.3:

• DMTFSpecMeasurementValueType = 0x8A (Raw Bit / Structured Manifest)
• DMTFSpecMeasurementValueSize = Size of Structured Manifest
• DMTFSpecMeasurementValue = Structured Manifest

SVH for Concise Evidence Manifest Block:

• ID = 0xA (IANA CBOR)
• VendorIdLen = 2
• VendorId = 0x570 #6.570(spdm-toc-map)

Structured Manifest Block Definition for Concise Evidence:

• SVH = SVH for Concise Evidence Manifest Block
• Manifest = tagged-spdm-toc CBOR Tag Payload

DMTF Header for CBor Web Token (CWT): If SPDM Version 1.2:

• DMTFSpecMeasurementValueType = 0x84 (Raw Bit / Freeform Manifest)
• DMTFSpecMeasurementValueSize = Size of CWT
• DMTFSpecMeasurementValue = CWT # COSE_Sign1

if SPDM = Version 1.3:

• DMTFSpecMeasurementValueType = 0x8A (Raw Bit / Structured Manifest)
• DMTFSpecMeasurementValueSize = Size of Structured Manifest
• DMTFSpecMeasurementValue = Structured Manifest

SVH for CBor Web Token (CWT):

• ID = 0xA (IANA CBOR)
• VendorIdLen = 2
• VendorId = 0x18 #6.18

Structured Manifest Block Definition for CBor Web Token (CWT):

• SVH = SVH for CBor Web Token (CWT)
• Manifest = COSE_Sign1 Payload

Transforming SPDM Measurement Block Digest

1. if DMTFSpecMeasurementValueType is in range [0x80 - 0x83]:
   • copy(SPDM.MeasurementBlock.DMTFSpecMeasurementValue , ECT.environment.measurement-map.mval.digests).
2. if DMTFSpecMeasurementValueType is in range [0x88]:
   • copy(SPDM.MeasurementBlock.DMTFSpecMeasurementValue , ECT.environment.measurement-map.mval.integrity-registers).

Transforming SPDM Measurement Block Raw Value

1. if DMTFSpecMeasurementValueType is in range [0x7]:
   • copy(SPDM.MeasurementBlock.DMTFSpecMeasurementValue , ECT.environment.measurement-map.mval.svn).

Transforming SPDM RATS EAT CWT The RATS EAT CWT shall be reported in any of the assigned Measurement Blocks range [0xF0 - 0xFC] The Concise Evidence CBOR Tag is serialized inside eat-measurements (273) claim ($measurements-body-cbor /= bytes .cbor concise-evidence-map) Subsequently the transformation steps defined in .

Transforming SPDM Evidence This section defines how Evidence from SPDM is transformed into an internal representation that can be processed by Verifiers. Verifiers supporting the SPDM Evidence format SHOULD implement this transformation. SPDM Responders SHALL support a minimum version of 1.2 Theory of Operations:

• The SPDM Requestor SHALL retrieve the measurement Manifest at Block 0xFD (Manifest Block) and send its payload to the Verifier
  • The Verifier SHALL decode the payload as a tagged-spdm-toc CBOR tag.
  • The Verifier SHALL extract the tagged-concise-evidence CBOR TAG from the tagged-spdm-toc CBOR tag

Theconcise-evidence has a format that is similar to CoRIM triples-map (their semantics follows the matching rules described above).

• For every spdm-indirect measurement the Verifier shall ask the SPDM Requestor to retrieve the measurement block indicated by the index
  • if the index is in range [0x1 - 0xEF] (refer to #Transforming SPDM Measurement Block Digest)
  • if the index is in range [0xF0 - 0xFC] (refer to #Transforming SPDM RATS EAT CWT] )

The TCG DICE Concise Evidence Binding for SPDM specification describes a process for converting the SPDM Measurement Block to Concise Evidence. Subsequently the transformation steps defined in . The keys provided in the ECT.authority field SHOULD include the key which signed the SPDM MEASUREMENTS response carrying the Evidence and keys which authorized that key as described in .```

Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalogue of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as Evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

Security and Privacy Considerations Evidence appraisal is at the core of any RATS protocol flow, mediating all interactions between Attesters and their Relying Parties. The Verifier is effectively part of the Attesters' and Relying Parties' trusted computing base (TCB). Any mistake in the appraisal process could have security implications. For instance, it could lead to the subversion of an access control function, which creates a chance for privilege escalation. Therefore, the Verifier’s code and configuration, especially those of the CoRIM processor, are primary security assets that must be built and maintained as securely as possible. The protection of both the Attester and Verifier systems should be considered throughout their entire lifecycle, from design to operation. This includes the following aspects:

• Minimizing implementation complexity (see also );
• Using memory-safe programming languages;
• Using secure defaults;
• Minimizing the attack surface by avoiding unnecessary features that could be exploited by attackers;
• Applying the principle of least privilege to the system's users;
• Minimizing the potential impact of security breaches by implementing separation of duties in both the software and operational architecture;
• Conducting regular, automated audits and reviews of the system, such as ensuring that users' privileges are correctly configured and that any new code has been audited and approved by independent parties;
• Failing securely in the event of errors to avoid compromising the security of the system.

The appraisal process should be auditable and reproducible. The integrity of the code and data during execution should be made an explicit objective, for example ensuring that the appraisal functions are computed in an attestable trusted execution environment (TEE). The integrity of public and private key material and the secrecy of private key material must be ensured at all times. This includes key material carried in attestation key triples and key material used to assert or verify the authority of triples (such as public keys that identify trusted supply chain actors). For more detailed information on protecting Trust Anchors, refer to . The Verifier should use cryptographically protected, mutually authenticated secure channels to all its trusted input sources (i.e., Attesters, Endorsers, RVPs, Verifier Owners). The Attester should use cryptographically protected, mutually authenticated secure channels to all its trusted input sources (i.e., Verifiers, Relying Parties). These links must reach as deep as possible - possibly terminating within the Attesting Environment of an Attester or within the appraisal session context of a Verifier - to avoid man-in-the-middle attacks. Also consider minimizing the use of intermediaries: each intermediary becomes another party that needs to be trusted and therefore factored in the Attesters and Relying Parties' TCBs. Refer to for information on Conceptual Messages protection.

IANA Considerations There are no IANA considerations.

References Normative References Fraunhofer SIT Linaro arm Intel Huawei Technologies 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. Trusted Computing Group (TCG) Trusted Computing Group (TCG) 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. Distributed Management Task Force Trusted Computing Group Armidale Consulting Fraunhofer SIT Linaro In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and, using Appraisal Policy typically with additional input from Endorsements and Reference Values, generates Attestation Results in formats that are useful for Relying Parties. This document illustrates the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements in the scope of the RATS architecture. This document does not aim to define a conceptual message format for Endorsements and Reference Values. Instead, it extends RFC9334 to provide further details on Reference Values and Endorsements, as these topics were outside the scope of the RATS charter when RFC9334 was developed. 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. 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. Informative References 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. 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. This document, along with RFC 9053, obsoletes RFC 8152. 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. 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. Security Theory LLC Mediatek USA Qualcomm Technologies Inc. Red Hound Software, Inc. An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. 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] This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

Contributors The authors would like to thank the following people for their valuable contributions to the specification. Henk Birkholz Email: henk.birkholz@ietf.contact Yogesh Deshpande Email: yogesh.deshpande@arm.com Thomas Fossati Email: Thomas.Fossati@linaro.org Dionna Glaze Email: dionnaglaze@google.com

Acknowledgments The authors would like to thank James D. Beaney, Francisco J. Chinchilla, Vincent R. Scarlata, and Piotr Zmijewski for review feedback.