S
P
E
C
I
F
I
C
A
T
I
O
N

TCG DICE Concise Evidence
Binding for SPDM
Version 1.00
Revision 0.53
June 1, 2023

Contact: admin@trustedcomputinggroup.org

Public Review

Work in ProgressThis document is an intermediate draft
for comment only and is subject tochange without notice. Readers should
not design products based on thisdocument.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | Public Review© TCG 2023

TCG DICE Concise Evidence Binding for SPDMDISCLAIMERS, NOTICES, AND LICENSE TERMS
THIS SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANYWARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR
ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE.
Without limitation, TCG disclaims all liability, including liability for infringement of any proprietary rights, relating to useof information in this specification and to the implementation of this specification, and TCG disclaims all liability forcost of procurement of substitute goods or services, lost profits, loss of use, loss of data or any incidental,
consequential, direct, indirect, or special damages, whether under contract, tort, warranty or otherwise, arising in any
way out of use or reliance upon this specification or any information herein.
This document is copyrighted by Trusted Computing Group (TCG), and no license, express or implied, is granted
herein other than as follows: You may not copy or reproduce the document or distribute it to others without written
permission from TCG, except that you may freely do so for the purposes of (a) examining or implementing TCG
specifications or (b) developing, testing, or promoting information technology standards and best practices, so longas you distribute the document with these disclaimers, notices, and license terms.
Contact the Trusted Computing Group at www.trustedcomputinggroup.org for information on specification licensing
through membership agreements.
Any marks and brands contained herein are the property of their respective owners.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 1© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

ACKNOWLEDGEMENTThe TCG wishes to thank all those who contributed to this specification. This document builds on work done invarious working groups in the TCG and the industry at large.
Name
Company
Henk Birkholz
Fraunhofer SIT
Yogesh Deshpande
ARM Holdings
Andrew Draper
Intel Corporation
Thomas Fossati
ARM Holdings
Brett Henning
Broadcom Inc.
Dennis Mattoon
Microsoft Corporation
Chandra Nelogal
Dell Technologies Inc.
Ned SmithIntel Corporation

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 2© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

CONTENTSDISCLAIMERS, NOTICES, AND LICENSE TERMS ................................................................................................... 1
ACKNOWLEDGEMENT .............................................................................................................................................. 2
1

SCOPE

5

1.1 Specification Scope...................................................................................................................................... 5
1.2 Key Words ................................................................................................................................................... 5
1.3 Statement Type ............................................................................................................................................ 5
2

REFERENCES .................................................................................................................................................... 6
2.1 References in Progress ................................................................................................................................ 7

3

INTRODUCTION ................................................................................................................................................. 8
3.1 Motivation ..................................................................................................................................................... 8
3.2 Terminology Convention .............................................................................................................................. 8
3.2.1 Notation .............................................................................................................................................. 8
3.3 Mapping Between SPDM and DICE............................................................................................................. 9
3.3.1 Terminology ........................................................................................................................................ 9
3.3.2 TCG DICE and DMTF SPDM Terminology Mapping ........................................................................ 10
3.3.3 Certificate Model Comparison ........................................................................................................... 11

4

BEHAVIORAL MODEL ...................................................................................................................................... 13
4.1 Minimum Specification Version .................................................................................................................. 13
4.2 Required Capabilities for Requesters and Responders ............................................................................. 13
4.3 Certificate Model Requirements ................................................................................................................. 135

CERTIFICATE REQUIREMENTS ..................................................................................................................... 14
5.1 Device Layering ......................................................................................................................................... 14
5.1.1 Device Layering and Identity ............................................................................................................. 14
5.1.2 Device Layering and Attestation Architecture ................................................................................... 14
5.2 Certificate Chain Construction and SPDM Certificate Slots ....................................................................... 15
5.2.1 Certificate Provisioning ..................................................................................................................... 16
5.3 Certificate Contents .................................................................................................................................... 16

6

SPDM MEASUREMENT MANIFEST ................................................................................................................ 19
6.1 Overview .................................................................................................................................................... 19
6.2 SPDM Measurement Manifest Configuration ............................................................................................. 19
6.3 SPDM Measurement Manifest Schema ..................................................................................................... 20
6.3.1 Table of Contents Schema ............................................................................................................... 20
6.3.2 Concise Evidence Schema ............................................................................................................... 20
6.4 Considerations for Conveyance of Evidence ............................................................................................. 22
6.5 Considerations when Comparing Evidence with Reference Values ........................................................... 23

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 3© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

6.5.1 Indirect Measurements ..................................................................................................................... 23
6.5.2 Appraisal of Evidence ....................................................................................................................... 26
7

CoMID SCHEMA EXTENSIONS ....................................................................................................................... 27
7.1 Indirect Measurements Extension .............................................................................................................. 27
7.2 Measurement Authorization Extension....................................................................................................... 27
7.3 CoSWID Triple Extension .......................................................................................................................... 27
7.4 Domain Membership Triple Extension ....................................................................................................... 28
7.5 Domain Dependency Triple Extension ....................................................................................................... 29
7.6 Target Environment Properties Extension .................................................................................................. 29

8

Appendix A - Use Cases and Evidence management ....................................................................................... 31

9

Appendix B – Sample Concise Evidence in CBOR Diagnostic Format .............................................................. 32
9.1 SPDM Indirect Evidence in CBOR Diagnostic Format ............................................................................... 32
9.2 Domain Dependency Evidence in CBOR Diagnostic Format ..................................................................... 33
9.3 Domain Membership Evidence in CBOR Diagnostic Format ..................................................................... 33
9.4 CoSWID Evidence in CBOR Diagnostic Format ........................................................................................ 36
9.5 Properties Flags as Endorsements in CBOR Diagnostic Format ............................................................... 37

10

11

12

Appendix C – Sample Pretty CBOR .................................................................................................................. 39
10.1

SPDM Indirect Evidence in Pretty CBOR Format ................................................................. 39

10.2

Domain Dependency Evidence in Pretty CBOR Format ....................................................... 40

10.3

Domain Membership Evidence in Pretty CBOR Format ....................................................... 41

10.4

CoSWID Evidence in Pretty CBOR Format .......................................................................... 44

10.5

Properties Flags as Endorsements in Pretty CBOR Format ................................................. 46

Appendix D – CDDL .......................................................................................................................................... 48
11.1

CoMID Schema Extensions .................................................................................................. 48

11.2

SPDM Table of Contents and Concise Evidence.................................................................. 49

Appendix E - IANA Considerations .................................................................................................................... 50

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 4© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

1 SCOPE
1.1 Specification Scope
The specification was developed in collaboration with the Secure Protocol and Data Model (SPDM) committee in theDistributed Management Task Force (DMTF) to define evidence binding for SPDM that use an SPDM Measurement
Manifest that aligns with TCG defined Evidence and Endorsement schemas, see [2], [8], and [14]. The CoMID schema[8] describes device architectures that consist of multiple environments. This specification extends the Evidence andEndorsements schemas to describe both direct and indirect measurements. This specification accommodates indirect
measurements by making them a hybrid of the SPDM Measurement Block and an SPDM Measurement Manifest
containing a concise evidence schema.
This specification defines data structures for conveying Evidence using SPDM Measurement Manifests as defined in
SPDM versions 1.1, see [19], or greater, see [1], and using certificates, see [2]. SPDM does not mandate use of
SPDM Measurement Manifests. This specification does not restrict SPDM normative requirements.
Normally, Evidence is conveyed to a remote Verifier without modification, but in the case of indirect measurements,
the SPDM Requestor endpoint may interact with a local lead Attester that then completes the measurement exchangewith a remote Verifier.
This specification anticipates that the attesting device consists of multiple Target Environments, see [9], and a Rootof Trust [4] that follows DICE layering [3] principles. Reference Values are assumed to follow the DICE Endorsement
Architecture for Devices (CoRIM) [8] schema and the schema extensions defined by this specification.
This specification defines an Evidence table of contents and an evidence binding for an SPDM Measurement Manifest.
SPDM can convey Evidence using the Measurement Block without using an SPDM Measurement Manifest or may
use an SPDM Measurement Manifest other than the manifest defined in this specification. These alternatives are outof scope for this specification.
API and protocol definition of or modification to SPDM Requesters / Responders for supporting interactions with alocal lead Attester or a remote Verifier is out of scope.

1.2 Key Words
The key words “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,”“RECOMMENDED,” “MAY,” and “OPTIONAL” in this document normative statements are to be interpreted as
described in RFC-2119, Key words for use in RFCs to Indicate Requirement Levels.

1.3 Statement Type
Please note a very important distinction between different sections of text throughout this document. There are two
distinctive kinds of text: informative comment and normative statements. Because most of the text in this specification
will be of the kind normative statements, the authors have informally defined it as the default and, as such, havespecifically called out text of the kind informative comment. They have done this by flagging the beginning and end ofeach informative comment and highlighting its text in gray. This means that unless text is specifically marked as of
the kind informative comment, it can be considered a kind of normative statement.
EXAMPLE: Start of informative comment
This is the first paragraph of 1–n paragraphs containing text of the kind informative comment ...
This is the second paragraph of text of the kind informative comment ...
This is the nth paragraph of text of the kind informative comment ...
To understand the TCG specification the user must read the specification. (This use of MUST does not require any
action).
End of informative comment

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 5© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

2 REFERENCES[1] Distributed Management Task Force, DMTF. (2022-06-23). Security Protocol and Data Model (SPDM)
Specification, Version 1.2.1. Available online: https://www.dmtf.org/dsp/DSP0274[2] Trusted Computing Group, TCG. (2021-01-11). DICE Attestation Architecture, Version 1.00, Revision 0.23.
Available online: https://trustedcomputinggroup.org/wp-content/uploads/DICE-Attestation-Architecture-r23final.pdf[3] Trusted Computing Group, TCG. (2020-07-23). DICE Layering Architecture, Version 1.0, Revision 0.19.
Available online: https://trustedcomputinggroup.org/wp-content/uploads/DICE-Layering-Architecturer19_pub.pdf[4] Trusted Computing Group, TCG. (2018-03-22). Hardware Requirements for a Device Identifier Compostion
Engine, Family 2.0, Level 00, Revision 78. Available online: https://trustedcomputinggroup.org/wpcontent/uploads/Hardware-Requirements-for-Device-Identifier-Composition-Engine-r78_For-Publication.pdf[5] Trusted Computing Group, TCG. (2017-05-11). TCG Glossary, Version 1.1, Revision 1.00, (Reference).
Available online: https://trustedcomputinggroup.org/wp-content/uploads/TCG-Glossary-V1.1-Rev-1.0.pdf[6] Trusted Computing Group, TCG. (2020-04-10). TCG Platform Certificate Profile Specification, Version 1.1,
Revision 19. Available online: https://trustedcomputinggroup.org/wpcontent/uploads/IWG_Platform_Certificate_Profile_v1p1_r19_pub_fixed.pdf[7] Trusted Computing Group, TCG. (2020-11-12). TCG Reference Integrity Manifest (RIM) Information Model,
Version 1.01, Revision 0.16. Available online: https://trustedcomputinggroup.org/wpcontent/uploads/TCG_RIM_Model_v1p01_r0p16_pub.pdf[8] Trusted Computing Group, TCG. (2022-03-28). DICE Endorsement Architecture for Devices, Version 1.0,
Revision 0.38. Available online: https://trustedcomputinggroup.org/wp-content/uploads/TCG-EndorsementArchitecture-for-Devices-V1-R38_pub.pdf[9] Internet Engineering Task Force, IETF. (2023-02-23). RFC 9334. Remote Attestation Procedures
Architecture. Available online: https://datatracker.ietf.org/doc/html/rfc9334/[10] Internet Assigned Numbers Authority, IANA. (2021-12-15). Concise Binary Object Representation (CBOR)
Tags. Available online: https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml[11] Internet Engineering Task Force, IETF. (2013-October). RFC 8949. Concise Binary Object Representation(CBOR). Available online: https://datatracker.ietf.org/doc/html/rfc8949[12] Internet Engineering Task Force, IETF. (2019-June). RFC 8610. Concise Data Definition Language(CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON
Data Structures. Available online: https://datatracker.ietf.org/doc/html/rfc8610[15] Internet Engineering Task Force, IETF. (2020-01-21). RFC 5280. Internet X.509 Public Key Infrastructure
Certificate and Certificaate Revocation List (CRL) Profile. Available online:
https://datatracker.ietf.org/doc/rfc5280/[16] NIST Computer Security Resource Center, CSRC. (2019-03-22). FIPS 140-3 Security Requirements for
Cryptographic Modules. Available online: https://csrc.nist.gov/publications/detail/fips/140/3/final[17] ISO/IEC (2022-08). 15408-1:2022 Information security, cybersecurity and privacy protection — Evaluation
criteria for IT security — Part 1: Introduction and general model. Available online:
https://www.iso.org/standard/72891.html andhttps://www.commoncriteriaportal.org/files/ccfiles/CCPART1V3.1R5.pdf
TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 6© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

[18] Trusted Computing Group, TCG. (2020-07-23). DICE Certificate Profiles, Version 1.0, Revision 0.01.
Available online: https://trustedcomputinggroup.org/wp-content/uploads/DICE-Certificate-Profilesr01_pub.pdf[19] Distributed Management Task Force, DMTF. (2022-04-26). Security Protocol and Data Model (SPDM)
Specification, Version 1.1.2. Available online: https://www.dmtf.org/dsp/DSP0274

2.1 References in Progress[13] Internet Engineering Task Force, IETF. (2023-02-07). RFC 9393-to-be. Concise Software Identification
Tags. Available online: https://www.rfc-editor.org/authors/rfc9393.html[14] Internet Engineering Task Force, IETF. (2023-01-11). Concise Reference Integrity Manifest. Available
online: https://datatracker.ietf.org/doc/draft-ietf-rats-corim/[20] Distributed Management Task Force, DMTF. (2023-04-05). Security Protocol and Data Model (SPDM)
Specification, Version 1.3.0x. Available online:
https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.3.0WIP99.pdf[21] Trusted Computing Group, TCG. (2023-03-22). DICE Attestation Architecture, Version 1.1, Revision 0.16.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 7© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

3 INTRODUCTION
This specification describes how the attestation capability of a DICE device integrates with the attestation capabilityof SPDM endpoints. The DICE Layering Architecture [3] defines layered attestation and the DICE Attestation
Architecture [2] defines an Evidence format for use with X.509 certificates. The DICE Certificate Profiles [18] defines
key purpose OIDs for devices with layered attestation. The SPDM protocol [1] [19], defines a payload structure forconveying attestation Evidence contained in certificates and the SPDM Measurement Block. Processing certificatescontaining Evidence implies Evidence is extracted from the certificate as part of Evidence appraisal.
This specification defines an SPDM Measurement Manifest structure consisting of a measurement table of contents
and the concise evidence schema that can be applied to Evidence collected by an SPDM Responder layer. Beginningwith SPDM v1.1, an SPDM Measurement Manifest can be included in an SPDM Measurement Block that formats
Evidence according to an Evidence schema.

3.1 Motivation
A device that supports DICE layering may encode layer-specific measurements according to Evidence andEndorsements schemas, see [2] and [8], and may wish to encode SPDM Measurement Block measurements using asimilar Evidence schema.
This specification defines the concise evidence schema that is compatible with the CoRIM schema [8] and the schema
extensions defined in §7.
Attesters that implement DICE layering typically protect layer-specific Evidence in layer-specific certificates that are
dynamically generated when a device boots. One of the layers typically implements the SPDM protocol that is used
to transport the certificates to the SPDM Requester, who may forward them to a remote Verifier. The DICE layer that
implements the SPDM protocol may also be an Attesting Environment that collects additional measurements fromone or more Target Environments that are conveyed using an SPDM Measurement Block.
The SPDM protocol conveys Evidence in several ways as described in §6.4 that may be formatted as defined in§Error! Reference source not found..
This specification defines indirect Evidence that a lead Attester converts to direct Evidence. Direct Evidence ischecked against Reference Values that comply with the CoRIM schema and its extensions. This specification does
not define ways of appraising direct Evidence.
Some of the terminology and concepts contained in SPDM and DICE specifications overlap, but have subtle
differences. This specification clarifies the subtleties, provides guidance, and where appropriate, specifies normative
behavior for implementations that support both DICE and SPDM capabilities.

3.2 Terminology Convention
This specification uses terminology that is defined by TCG specifications and by the DMTF SPDM specification. To
help the reader understand the specific term being used, this specification uses the adjective “SPDM” before terms
that should be interpreted according to the SPDM specification. Terms that should be interpreted according to TCG
specifications are presented with the adjective “TCG” or do not use an adjective.
For example, the term “SPDM Responder” is interpreted according to the SPDM specification’s term “Responder”.
For example, both the terms “TCG Attester” and “Attester” are to be interpreted according to the use of “Attester” in
TCG specifications.

3.2.1 Notation
This section contains notation used in this specification to describe data and operations related to device layering andcryptography.
LegendKNAME, KLn

Explanation
A private key (K) represents a device or component where NAME, in subscript, names the key or
Ln, in subscript, names the key by its layer. Normally, a key named by a layer (Ln) implies the key
was derived from a CDI.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 8© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

LegendPKNAME, PKLn

Explanation
A public key (PK) corresponding to a device or component where NAME, in subscript, names the
public key or Ln, in subscript, names the key by its layer. Normally, a public key named by a layer(Ln) implies the key was derived from a CDI.

TCILn

A Trusted Computing Base (TCB) Component Identifier (TCI) is a layer-specific measurement,
where Ln identifies the layer-specific TCI.

CDILn

A Compound Device Identifier (CDI) is a cryptographic measurement of a layer, derived by theprevious layer, where the subscript Ln, names the layer-specific CDI.

[m]K

A message (m) that is digitally signed using the key (K).

[PKLn+1]KLn

A digital certificate containing a subject public key (PKLn+1) in layer (n+1) is signed using an issuer
private key (KLn) from the preceding layer (n).
Table 1 Legends for notational conventions

3.3 Mapping Between SPDM and DICE
This specification uses the SPDM extension for defining an SPDM Measurement Manifest. The manifest contains
Evidence that is conveyed from an Attester to a Verifier, see Figure 1. The SPDM Responder and SPDM Requester
are not shown in Figure 1 but are located between the Attester and the Verifier.
Start of informative comment

Figure 1: Evidence message exchange between Attester and Verifier roles

The SPDM protocol is the conveyance mechanism for Evidence contained in DICE certificates and the SPDM
Measurement Block. An Attester might have other Evidence that is formatted according to other specifications. This
specification does not limit the use of alternative Evidence formats.
End of informative comment

3.3.1 Terminology
The terms and definitions in Table 2 apply to this specification, along with terms from the TCG Glossary [5] and otherreferenced documents.

1

Term

Definition

Attestation Key

An Attestation Key is a key that can be used to sign attestation Evidence.

DeviceID Key

The Key Pair associated with CDI of Layer 0 is the DeviceID Key. The expectation is that theDeviceID Key remains constant for the useful life of the Attester. Note that a DeviceID Key (or acomponent of the DeviceID Key, such as PKL0), can be relayed by any higher layer to the Verifier.

ECA Key

An Embedded Certificate Authority (ECA)1 key is an asymmetric key that is used to sign a
certificate for a subsequent layer in a device.

HW RoT

Hardware Root of Trust – A component that performs one or more security-specific functions,such as measurement, storage, reporting, verification, and/or update. It is trusted always tobehave in the expected manner, because its misbehavior cannot be detected (such as bymeasurement) under normal operation [4].

An Embedded Certificate Authority is explained in §3.3.2.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 9© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

Table 2 2: Terminology definitions

3.3.2 TCG DICE and DMTF SPDM Terminology Mapping
Terminology commonly used by TCG DICE and DMTF SPDM specifications that have similar meanings are comparedin Table 3.
DICE Term

SPDM Term

Explanation

Alias Key

Leaf Certificate Key

The key (either public or private) associated with the end entity
certificate.

Attester,lead Attester

The SPDM Responder is a protocol endpoint role, while the DICE
Attester has a role in an Attestation framework. An SPDM
Responder endpoint may also implement the Attester role, or theseroles may be performed separately.
Responder

The lead Attester role coordinates collection and conveyance ofEvidence obtained from other Attesters. The SPDM Responder
performs a lead Attester role when it collects DICE certificatescontaining Evidence and conveys them to a Verifier via an SPDM
session.

DeviceID Key

Device Certificate
Key

The key (either public or private) associated with the device
certificate that represents a hardware identity that is generated orprovisioned during device manufacturing. Typically, this key isunique per instance of the hardware, and is immutable and valid forthe useful life of the device.

DeviceID
Certificate(Device Identity
Certificate)Device Certificate CA

The device certificate that identifies the device. Typically, it is valid
for the useful life of the device. It may contain extensions that
describe immutable properties of the device.

Embedded
Certificate
Authority (ECA)

Alias Intermediate CA

An Embedded Certificate Authority is a device layer that issues
certificates to another device layer. The procedure for obtaining
certificate signing requests (CSR) from a subsequent layer isdocumented in the DICE Layering Architecture Specification [3].

ECA Certificate

Alias Intermediate CA
Certificate

An intermediate certificate in a DICE Certificate Model has a layered
ECA certificate (a.k.a., SPDM Alias Intermediate CA) certificate
path. Typically, ECA certificates contain layer identity information
and are issued by another ECA or an Intermediate CA.

Alias orEnd Entity
Certificate

Evidence

Verifier

Alias orLeaf Certificate

The final certificate in a certificate chain.

Measurement Block

The DICE specifications describe Evidence as measurements thatare to be matched to Reference Values. Typically, an ECA includes
Evidence in an X.509 certificate as a certificate extension, e.g.,
DiceTcbInfo. The SPDM specifications refer to measurements as
typed values that are written into the SPDM Measurement Block.

Requester

The SPDM Requester is a protocol endpoint, while the DICE Verifier
is an attestation role. An SPDM Requester could be a lead Attester,
Verifier or both. For example, host firmware could be a lead Attester
for a peripheral device that is an SPDM Responder.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 10© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

Table 3 SPDM to DICE Terminology Mapping

In addition to a protocol for the conveyance of Attestation Evidence, the SPDM specification defines a mechanism toestablish a session for Authenticated Encryption with Associated Data (AEAD) based secured messages. While some
operations referenced in this specification depend on the use of secured messages, policies related to the use of
secure messages are out of scope for this specification.

3.3.3 Certificate Model Comparison
SPDM v1.2 defines the SPDM Alias Certificate Model that consists of a Root CA, zero or more Intermediate CAs, a
Device Certificate CA, zero or more Alias Intermediate CAs, and an Alias Certificate, see Figure 2.
The DICE certificate model is most like the SPDM Alias Certificate Model. It consists of a Root CA, zero or moreIntermediate CAs, a DeviceID certificate or layer 0 ECA, zero or more ECAs, and an End Entity. The. final intermediate
CA issues a DeviceID certificate. The DeviceID layer 0 ECA issues an ECA certificate, and so forth. The final ECA
issues an Alias certificate.
SPDM v1.1 introduced the SPDM Device Certificate Model that is incompatible with DICE implementations.

Figure 2: Certificate model comparison

Table 4 compares the SPDM Alias and DICE ECA certificate models as defined by [1] and [3], respectively.
SPDM Alias Certificate
Model

Device Certificate CA
Certificate

DICE ECA Certificate
Model
DeviceID or
Layer 0 ECA Certificate

Comments
The SPDM Device Certificate CA certificate or DICE
DeviceID certificate is the certificate nearest to the root CA
certificate that states the device’s manufacturer that
supplied the device's identifying information. Thiscertificate is signed by a CA that is not embedded in thedevice.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 11© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

SPDM Alias Certificate
Model

DICE ECA Certificate
Model

Comments
SPDM specifications specify that the Device Certificate CA
certificate contains instance unique hardware identity
information, while DICE specifications specify that theDeviceID certificate contains identity information for thedevice and is described as the first layer of the device. If
the first layer is immutable, then the identity information forthe device remains the same for the useful life of thedevice.

Alias Intermediate CA
Certificate

ECA Certificate

The certificate chain may contain SPDM Alias Intermediate
CA certificates, a.k.a. DICE ECA certificates. SPDM does
not provide guidance on how Alias Intermediate CA
certificates are constructed.
DICE ECA and Alias Intermediate CA certificates may
contain attestation Evidence.

Alias or

Alias orLeaf Certificate

End Entity Certificate

The SPDM Alias certificate is the certificate that is furthest,in the certificate path, from the root CA certificate. It is an
end-entity certificate.
The DICE Alias certificate is also known as the End Entity
certificate.
Alias certificates may contain attestation Evidence.

Table 4: Comparison of SPDM and DICE certificate models

This specification treats the SPDM Alias Certificate model and DICE ECA Certificate models as equivalent.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 12© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

4 BEHAVIORAL MODEL
This section describes device capabilities and behavior necessary to be conformant with this specification.

4.1 Minimum Specification Version
Conformant implementations SHALL use SPDM version 1.1 or greater.
Conformant implementations SHALL use DICE Endorsement Architecture for Devices v1.0 [8] or greater, andextensions as defined in this specification, if implementing concise-evidence-map, see §6.3.2.

4.2 Required Capabilities for Requesters and Responders
Start of informative comment
The SPDM specification defines a set of capabilities for the SPDM Requester and SPDM Responder, using the SPDM
GET_CAPABILITIES request and CAPABILITIES response messages. The SPDM specification does not specify arequired set of capabilities for conformant implementations.
End of informative comment
Compliant implementations SHALL use SDPM Capabilities as defined in Table 5 and MAY support other SPDM
defined capabilities. Support for SPDM CAPABILITIES not listed in Table 5 is implementation specific.
SPDM Capability

Requirement

CERT_CAP

This SPDM capability SHALL be set to 1.

MEAS_CAP

This SPDM capability SHALL be set to 10b.

ALIAS_CERT_CAP2

If available, this SPDM capability SHALL be set to 1.
If available, this SPDM capability SHOULD be set to 1.

SET_CERT_CAP

If SET_CERT_CAP=1, a certificate chain could be
provisioned to a certificate slot with a certificate chain
chosen by the SPDM Requester. Provisioned certificate
chains could be extended by an ECA.
If available, this SPDM capability SHOULD be set to 1.

CSR_CAP

If CSR_CAP=1, a CSR could be used to obtain acertificate for a DICE key that chains to a CA determinedby the SPDM Requester.
Table 5 SPDM Capabilities Requirements

4.3 Certificate Model Requirements
Implementations compliant with this specification SHALL use the SPDM Alias Certificate model for SPDM v1.2 orgreater, or the DICE ECA Certificate model for SPDM v1.1.
Start of informative comment
An implementation determines the certificate model. There are different extended key usage OIDs defined for therespective certificate models.
The SPDM specification does not define how to protect keys or the associated input material. Those topics are coveredin DICE specifications [3], and [4].
End of informative comment

2

ALIAS_CERT_CAP is only present in the CAPABILITIES response message.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 13© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

5 CERTIFICATE REQUIREMENTS
This section defines certificate requirements for SPDM and DICE certificate models given a layered device
architecture. It also describes certificate chain construction, examples involving multiple certificate chains, andcertificate contents requirements.

5.1 Device Layering
5.1.1 Device Layering and Identity
Start of Informative Comment
The layer containing the SPDM Responder, acting as an Attesting Environment, can measure a Target Environment(see Figure 3) that is part of the SPDM Responder layer, but not included with the previous layer's measurement of
the SPDM Responder layer. The Target Environment measurements are reported using the SPDM Measurement
Block.
The layer below Layer n collects measurements about the SPDM Responder, or alternatively, the SPDM Responder
is part of the device Root of Trust.
End of Informative Comment
The SPDM Responder SHALL be part of a DICE layer.

5.1.2 Device Layering and Attestation ArchitectureThis section defines DICE layering semantics that are preserved by SPDM. An example device shown in Figure 3
illustrates an SPDM payload containing layer-specific measurements and the key used to protect measurement
integrity.

Figure 3: Example Device Layering and Attestation via SPDM

Start of informative comment
Figure 3 illustrates a layered attestation payload that is conveyed via an SPDM protocol. DICE layer keys are used
to protect attestation Evidence and to identify the Attester device.
The Attester has a DICE hardware Root of Trust that launches layer 0 containing a device identity key, KL0, that issues
an ECA certificate to the next layer. The layer 0 certificate contains layer 0 Evidence that is signed by the device
manufacturer. See §5.2 thru §5.7 of [3] for additional detail.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 14© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

The subsequent layers' ECA keys may issue certificates containing attestation Evidence for each layer. The SPDM
Responder layer has an alias key that is used to protect the Target Environment measurements collected by the
SPDM Responder layer. The SPDM Measurement Block contains an SPDM Measurement Manifest that contains theTarget Environment Evidence collected by the Attesting Environment at the SPDM Responder layer.
End of informative comment
The following DICE layering assumptions are preserved by SPDM:•

The DeviceID Key is provisioned in a secure environment.

•

If the Layer 0 implementation of a device is implemented as mutable (even if the implementer policy is that it
will never change), then the corresponding DeviceID Key and the DeviceID certificate will change if the Layer
0 is changed.

•

If the Layer 0 implementation of a device is indeed immutable, then the corresponding DeviceID Key and theDeviceID certificate will be immutable for the useful life of the device.

•

The establishment of trust between layers is primarily implemented by an Attesting Environment layer
measuring the image of a subsequent Target Environment layer, computing a unique identifier for that layer,
and the subsequent layer generating a key that can be used to authenticate the Target Environment layer.

•

Layered trust extends to the SPDM Responder. This enables the SPDM Responder to convey the Evidence
from a preceding layer, such as Layer 0, to a Verifier. In this example, the DeviceID certificate, which
represents the Evidence of layer 0 and a unique hardware identity, is conveyed by the SPDM Responder
layer.

5.2 Certificate Chain Construction and SPDM Certificate Slots
This section describes certificate chain construction and provisioning using SPDM v1.2 certificate slots.

Figure 4: Example usage of SPDM v1.2 certificate slots

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 15© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

Start of Informative Comment
In Figure 4, a device supply chain provisions various certificate slots when the device's configuration changes. For
example, a device Manufacturer (MFG) creates the device identity key and issues a manufacturing certificate. An
Original Equipment Manufacturer (OEM) integrates the device identity key with additional components or firmware
and reissues the device identity certificate under the OEM's root CA. A Value Added Reseller (VAR) configures thedevice for a customer and reissues the device identity certificate under the VAR's root CA.
The example device in Figure 4 shows SPDM Alias Certificate Model certificate chains in SPDM certificate slots.
Multiple certificate chains are provisioned into multiple SPDM v1.2 certificate slots at different times throughout amanufacturing and deployment sequence. Provisioning a certificate chain into an SPDM v1.2 slot asserts device
ownership. If the certificate chain contains a device identity certificate, the device can be authenticated using one of
its assigned owners. In this example, at time t0, the MFG entity certifies the DeviceID Key at layer 0 (PKL0), using its
intermediate CA ("MFG_CA2") and provisions its certificate chain into slot 0. The DeviceID Key (KL0) is protected frommisuse by the device implementation.
The OEM, at time t1, issues a DeviceID certificate for the DeviceID Key at layer 0 (PKL0) so that the OEM canauthenticate the device as part of regular maintenance and device lifecycle support. The OEM provisions its certificate
chain into slot 1. The device's key protection mechanisms may prevent the OEM from overwriting slot 0.
DeviceID certificates may certify a key from a dynamic DICE layer. In this example, each entity issues a DeviceID
ertificate for the layer 0 public key (PKL0).
At time t0, layers 1 and 2 do not yet exist, the layer 0 public key PKL0 is the DeviceID Key, and the Device’s Alias
certificate is the DeviceID certificate .
At time t1, the OEM configures layer 1 and uses the layer 0 private key (KL0) to certify the layer 1 public key (PKL1).
The layer 0 public key remains the DeviceID Key, and the layer 1 certificate, ECA_L1, is now the Alias certificate.
At time t2, the VAR updates the device, configures layer 2 and issues another DeviceID certificate using the layer 0
DeviceID Key. The layer 0 public key remains the DeviceID Key, the layer 1, ECA_L1, certificate becomes an Alias
Intermediate CA certificate, and the layer 2 certificate, ECA_L2, is the Alias certificate.
In this example, the DICE ECAs dynamically issue Alias and Alias Intermediate CA certificates. If an additional layer
is configured, the certificate paths for all certificate slots terminate with the same Alias certificate. Other use cases
may exhibit different behavior.
The DICE layer 1 key is specific to the layer 1 configuration and the DICE layer 2 key is specific to the layer 2
configuration. Consequently, if the layer 1 or layer 2 configuration changes, different keys are created. A misconfigured
layer could result in the device being unable to perform the intended key operation.
End of Informative Comment

5.2.1 Certificate Provisioning
Certificate provisioning of slot 0 SHALL be done in a secure manufacturing environment.
Start of Informative Comment
The specifics of securing a manufacturing environment are outside the scope of this specification.
End of Informative Comment
Slot 0 SHALL contain a DeviceID certificate that certifies the device's DeviceID Key that is provisioned during device
manufacturing.

5.3 Certificate Contents
The SPDM specifications [1] [19] define optional and required certificate contents. This section describes DICE
conformant certificates, as defined by [2] and [18], that are compatible with SPDM v1.1 or greater.
The DICE Certificate Profiles [18] specification and the SPDM standards [1] [19] define specific requirements forextended key usage OIDs in SPDM Device CA, Alias Intermediate, and Alias Certificates.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 16© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

SPDM and DICE certificate requirements SHALL be as defined in Table 6:
SPDM
Certificate TypeDICE Certificate
Type

Requirements
The certificate SHOULD contain id-DMTF-hardwareidentity
The certificate SHOULD contain tcg-dice-kp-identityInit

DeviceID or
DeviceCertificate CA

IdevID
Certificate

If the certified key is used to issue ECA or Intermediate CA
certificates, the certificate SHOULD contain tcg-dice-kp-eca andbasicConstraints:cA SHALL be TRUE.
If the certified key is used to sign Evidence, the certificate SHOULD
contain tcg-dice-kp-attestInit.
If the certified key is used to sign attestation information other than
Evidence, the certificate SHOULD contain tcg-dice-kp-assertInit.
If the certified key is used by a mutable environment, the certificate
MAY contain id-DMTF-mutable-certificate.

Alias
Intermediate
Certificate

If the certified key is used to issue ECA or Intermediate Alias
Certificates, the certificate SHOULD contain tcg-dice-kp-eca andbasicConstraints:cA SHALL be TRUE.
ECA Certificate

If the certified key is used to sign a device identity challenge, thecertificate SHOULD contain tcg-dice-kp-identityLoc.
If the certified key is used to sign Evidence, the certificate SHOULD
contain the tcg-dice-kp-attestLoc.
If the certified key is used to sign attestation information other than
Evidence, the certificate SHOULD contain tcg-dice-kp-assertLoc.
If the certified key is used to sign SPDM response messages, thenthe certificate SHOULD contain id-DMTF-ekuresponder-auth.

Alias or

Alias or

Leaf

End Entity

Certificate

Certificate

If the certified key is used by a mutable environment, the certificate
MAY contain id-DMTF-mutable-certificate.
If the certified key is used to sign a device identity challenge, thecertificate SHOULD contain tcg-dice-kp-identityLoc.
If the certified key is used to sign Evidence, the certificate SHOULD
contain tcg-dice-kp-attestLoc.
If the certified key is used to sign attestation information other than
Evidence, the certificate SHOULD contain tcg-dice-kp-assertLoc.
Table 6 Certificate constraints and key usage

Start of Informative Comment
The validity of the DeviceID (a.k.a., SPDM Device Certificate CA) certificate is either set to never expire or set to avalue that aligns with the planned life of the device.
The same certificate can have multiple key purpose OIDs enabling the same key to be used for multiple purposes.
Implementations should ensure that certificate authorities certify the intended Target Environment. To ensure that thelayer requesting the certificate is authentic, an ECA can check the image of the layer making the request before
issuing a certificate containing a digest of that image, see §9.2 of [3].

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 17© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

Implementations should certify a Target Environment once per boot or once per firmware activation, to avoid
unnecessary or nuisance certifications.
The DICE layering architecture does not require a DICE layer N to authenticate the next layer (layer N+1) before
creating CDIN+1 or issuing a certificate with PKN+1 as subject key. Instead, the ECA within layer N includes
measurements of layer N+1 in that certificate (within a DiceTcbInfo or DiceMultiTcbInfo extension). The extension ismarked critical so a Verifier that does not understand the extension will fail certificate verification.
The measurements taken by layer N+1 can be trusted only if layer N is in a known good state. A Verifier that is relying
on layer N+1 measurements, (reported via DICE, SPDM or other protocols) is expected to check appropriate
measurements of layer N (reported in the certificate with PKN as subject key).
The validity of a layer Intermediate ECA certificate [2] is either set to the value indicating no specific expiry date or set
to the value that aligns to the useful life of the product.
End of Informative Comment

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 18© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

6 SPDM MEASUREMENT MANIFEST
6.1 Overview
This section defines concise evidence schema and a table of contents structure used by an SPDM Measurement
Manifest. The concise evidence schema builds on the CoMID schema. CoMID schema extensions are also defined
here. The measurement manifest table of contents supports manifest extensibility and attester context information.
Schemas are defined using Common Data Definition Language (CDDL) [12] because a CBOR encoding is easily
realized. CDDL may also be useful for realizing other encodings.

6.2 SPDM Measurement Manifest Configuration
Figure 5 illustrates an SPDM Measurement Block containing a measurement at index location 0xFD. The
DMTFSpecMeasurementValueType at byte location 7 contains the value 1b, indicating the measurement is a raw bit
stream. The Measurement payload contains a tagged-spdm-toc table of contents as the SPDM Measurement
Manifest. Within the table of contents structure there is a tagged-concise-evidence structure.
Figure 5 also illustrates an SPDM Measurement Block containing a measurement at index location 0xFD. The
DMTFSpecMeasurementValueType at byte location 7 contains the value 0b, indicating the measurement is a digestof an SPDM Measurement Manifest.
Start of Informative Comment
SPDM Requesters may request measurements in their native raw bit stream format or a digest. The digested form isa performance optimization if values do not change from previous SPDM request messages.
End of Informative Comment

Figure 5: SPDM Measurement Block configured with Measurement Manifest.

The SPDM v1.2 Measurement Block can support Evidence encoded as a raw bit stream SPDM Measurement
Manifest. If used, the SPDM Measurement Block index with value 0xFD contains the manifest.
If using SPDM v1.2, the MeasurementSpecification bit SHALL be set to 01h and the
DMTFSpecMeasurementValueType at bit position [6:0] SHALL be set to 04h.
If using SPDM v1.3 [20], the MeasurementSpecification bit SHALL be set to 01h and the
DMTFSpecMeasurementValueType at bit position [6:0] SHALL be set to 0Ah.
If the DMTFSpecMeasurementValueType at bit position [7] has the value 1b, the contents SHALL be a raw bit stream
containing a measurement manifest consisting of a CBOR tag, followed by a manifest table of contents, that SHOULD
include tagged-concise-evidence, see §6.3.
Compliant implementations SHALL support the SPDM raw bit stream option.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 19© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

If the DMTFSpecMeasurementValueType at bit position [7] has the value 0b, the contents SHALL be a cryptographic
digest of the CBOR tag, followed by a manifest table of contents containing $tagged-evidence-type-choice
entries.
Compliant implementations SHOULD support the SPDM cryptographic digest option.

6.3 SPDM Measurement Manifest Schema
6.3.1 Table of Contents Schema
The SPDM Evidence Manifest table of contents, tagged-spdm-toc, supports multiple Evidence formats and multiple
Evidence instances can be supplied.
Start of Informative Comment
If the Attester developer knows the Reference Values manifest location, the rim-locator is a hint that a Verifier
might use to find reference manifests or other information needed by a Verifier.
The first 3 bytes in an SPDM Measurement Manifest table of contents are a CBOR tag, tagged-spdm-toc, that is
assigned by the Internet Assigned Numbers Authority (IANA) CBOR registry (see [10]) that can indicate any table ofcontents structure. This specification defines the spdm-toc-map. As a registered CBOR tag, parsers can easily
determine which parsing rules to apply. If a different manifest table of contents is desired, a different CBOR tag canbe used.
The table of contents, spdm-toc-map, may contain a profile that describes implementation specific conventions,see [8]. A profile identifier indicates whether the Evidence adheres to a profile. A lead Attester or Verifier may use theprofile to assist in processing indirect Evidence.
End of Informative Comment
The SPDM Evidence Manifest table of contents schema, a.k.a., tagged-spdm-toc SHALL be defined as follows:
tagged-spdm-toc = #6.IANA-TBA(spdm-toc-map)
spdm-toc = spdm-toc-map
spdm-toc-map = {&(tagged-evidence: 0) => [ + $tagged-evidence-type-choice]? &(rim-locators: 1) => [ + corim-locator-map ] ;see corim? &(profile: 2) => profile-type-choice ; see corim* $$spdm-toc-map-extension}$tagged-evidence-type-choice /= tagged-concise-evidence

The tagged-spdm-toc SHALL support CBOR [11] encoding and SHALL start with CBOR tag #6.IANATBA(spdm-toc-map) (see §12).
The spdm-toc-map SHALL contain a tagged-evidence list, an optional rim-locators list, and an optional
profile identifier. The spdm-toc-map SHALL be extensible.
The tagged-evidence list SHALL support one or more entries of $tagged-evidence-type-choice where atleast one supported Evidence type SHALL be tagged-concise-evidence.
The spdm-toc-map SHALL support a Reference Values locator corim-locator-map as defined by CoRIM.
The spdm-toc-map SHALL support a profile identifier profile-type-choice as defined by CoRIM.

6.3.2 Concise Evidence SchemaThis section defines the concise evidence schema, tagged-concise-evidence. A CBOR tag is used to indicatethat a concise-evidence-map encoding follows the CBOR tag value.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 20© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

The concise-evidence-map contains an ev-triples-map, which is an extensible, non-empty map of Evidence
triples.
The tagged-concise-evidence statement SHALL be defined as follows:
tagged-concise-evidence = #6.IANA-TBA(concise-evidence-map)
concise-evidence = concise-evidence-map
concise-evidence-map = {&(ce.ev-triples: 0) => ev-triples-map? &(ce.evidence-id: 1) => $evidence-id-type-choice* $$concise-evidence-map-extension}$evidence-id-type-choice /= tagged-uuid-type
ev-triples-map = non-empty<{? &(ce.evidence-triples: 0) => [ + reference-triple-record ]? &(ce.identity-triples: 1) => [ + identity-triple-record ]? &(ce.dependency-triples: 2) =>[ + domain-dependency-triple-record ]? &(ce.membership-triples: 3) =>[ + domain-membership-triple-record ]? &(ce.coswid-triples: 4) => [ + ev-coswid-triple-record ]? &(ce.attest-key-triples: 5) => [ + attest-key-triple-record ]* $$ev-triples-map-extension}>
ev-coswid-triple-record = [environment-map,[ + ev-coswid-evidence-map ]]ev-coswid-evidence-map = {? &(ce.coswid-tag-id: 0) => concise-swid-tag-id&(ce.coswid-evidence: 1) => evidence-entry ; see coswid? &(ce.authorized-by: 2) => [ + $crypto-key-type-choice ]}If the $tagged-evidence-type-choice in spdm-toc-map is used, it will normally contain Evidence as definedby tagged-concise-evidence.
The tagged-concise-evidence element SHALL support CBOR [11] encoding and SHALL start with CBOR tag#6.IANA-TBA(concise-evidence-map)(see §12).
Concise Evidence is an ev-triples-map, which is a map of Evidence triples records. The concise-evidencemap SHALL contain Evidence triple statements as defined by ev-triples-map.
The concise-evidence-map SHOULD contain an Evidence identifier as defined by $evidence-id-typechoice, that SHALL include, as a minimum, a CBOR tag tagged-uuid-type as defined by CoRIM.
The concise-evidence-map SHALL be extensible.
The ev-triples-map SHALL contain at least one triple record.
The ev-triples-map SHALL contain any of the following triples:•ce.evidence-triples as an array of reference-triple-record, as defined by CoMID.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 21© TCG 2023

TCG DICE Concise Evidence Binding for SPDM•

ce.identity-triples as an array of identity-triple-record, as defined by CoMID.

•

ce.attest-key-triples as an array of attest-key-triple-record , as defined by CoMID.

•

ce.coswid-triples as an array of ev-coswid-triple-record, as defined by §7.3.

•

ce.dependency-triples as an array of domain-membership-triple-record, as defined by §7.4.

•

ce.dependency-triples – as an array of domain-dependency-triple-record, as defined by §7.5

If a domain-dependency-triple-record or a domain-membership-triple-record is contained inEndorsements, identical triple statements in Evidence SHOULD be omitted.
The ev-triples-map SHALL support an extensible set of Evidence triple statements.
The measurement-values-map in reference-triple-record SHALL be extended to support indirect
Evidence as defined by §7.1.
The ev-coswid-triple-record SHALL have a subject that consists of an environment-map and an object thatconsists of one or more ev-coswid-evidence-map.
The ev-coswid-evidence-map SHALL contain a CoSWID evidence-entry.
The ev-coswid-evidence-map MAY contain a concise-swid-tag-id and zero or more $crypto-key-typechoice values that identify entities authorized to provide Reference Measurements.
If CoSWID ev-coswid-triples is populated, then CoSWID Evidence SHALL be contained in evidence-entry.
If CoSWID ev-coswid-triples is populated, then concise-swid-tag-id SHOULD identify a SWID tag with
Reference Values contained in payload-entry.
The authorized-by item SHOULD be included in Evidence if Reference Values are supplied by an entity other than
the supplier of the Attester.
Start of Informative Comment
The concise evidence schema relates software, as defined by CoSWID [13], to a Target Environment, as defined by
CoMID.
The environment-map value in each Evidence record identifies which Reference Values measurements are to bematched.
The CoSWID tag identifiers (concise-swid-tag-id) assist Verifiers in locating the CoSWID tags containing
Reference Values.
The CoSWID schema distinguishes between Evidence and Reference Values. The evidence-entry map contains
Evidence, while payload-entry contains Reference Values.
A layered Attesting Environment may depend on another layer's Attesting Environment for correct behavior. Evidence
may capture dependency, such as a certificate chain. Alternatively, expected dependencies can be defined inEndorsements. The domain-dependency-triple-record, see §7.4, can be used in both Endorsements andEvidence. Verifiers ensure that dependencies found in Evidence match dependencies found in Endorsements.
End of Informative Comment

6.4 Considerations for Conveyance of Evidence
Start of Informative Comment
SPDM can convey Evidence in two ways: (a) inside certificates using Evidence extensions or, (b) inside the SPDM
Measurement Manifest. When Evidence is conveyed using the SPDM Measurement Manifest, the measurement blockindex will have the value 0xFD and the SPDM MeasurementSpecification defines how to interpret themeasurement block contents.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 22© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

Implementations may use indirect measurements in a statically configured SPDM Measurement Block for encoding
efficiency purposes, see §6.5.1.
End of Informative Comment
If spdm-toc-map is conveyed, the rim-locators field in spdm-toc-map SHOULD identify locations where
Endorsements useful to a Verifier may be retrieved.

6.5 Considerations when Comparing Evidence with Reference Values
Start of Informative Comment
A DICE device that implements SPDM can convey Evidence in two ways: certificates, and the SPDM Measurement
Block. When using SPDM Measurement Block, the optional SPDM measurement manifest can be used to format
Evidence aligned with the CoRIM schema and other DICE Evidence contained in certificates. The evaluation of bothtypes of Evidence is essential to obtaining a complete understanding of the state of the Attester device.
Endorsement information about an Attester is conveyed to a Verifier from various entities. Endorsements may contain
three types of information:
Reference Values – Claims containing measurement values that are known to be good or expected by theEndorser to match Attester supplied Evidence values. Claims contain measurement values that the Verifier canuse to determine whether a set of Endorsements is appropriate for a device.
Endorsed Values – Claims that augment Evidence claims. They may describe quality properties, such as
Common Criteria [17] and FIPS 140-3 [16] evaluation results. Endorsed Values claims may vouch for the integrityof the Attester that a Verifier may use to satisfy an appraisal policy, or to derive an appropriate Attestation Result.
Authenticated Values – Credentials that assist the Verifier in authenticating the Attester or an endpoint within
the Attester. Authenticated Values might also be used during key exchange protocols to negotiate keys used for
integrity and confidentiality protections.

Implementation of the Attesting Environment that collects and formats Evidence claims may rely on the Reference
Values Claims (or vice versa) to ensure these values are easily compared by the Verifier.
The CoMID schema [8] and the extensions defined in §7 are a common schema for relating Evidence, Reference
Values, Endorsed Values, and Authenticated Values.
End of informative comment
If an SPDM Measurement Manifest containing tagged-concise-evidence is used (see §6.3.2), an Attester device
SHALL construct Evidence using concise-evidence-map such that Evidence can be matched with Reference
Values using concise-mid-tag, see [8].

6.5.1 Indirect Measurements
Attestation primarily involves two workflows: (a) conveyance of Evidence from the Attester to the Verifier and (b)conveyance of Endorsements from the Endorser to the Verifier.
Measurements contained in an SPDM Measurement Manifest are referred to, in this specification, as direct
measurements. Measurements contained in the SPDM Measurement Block at locations other than the manifest
location (0xFD), when an SPDM Measurement Manifest is used, are referred to as indirect measurements. Indirect
measurement values are copied into direct measurements according to a measurement manifest schema (e.g.,concise-evidence-map).
If an spdm-indirect measurement is used, an indirect measurement value SHALL be placed in the SPDM
Measurement Block by the implementation at an index location and the SPDM Measurement Manifest SHALL containan spdm-indirect index value with the index location.
Start of Informative Comment

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 23© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

An SPDM Responder may put measurements in the SPDM Measurement Block at various indexed locations. If an
SPDM Measurement Manifest is used, it is possible that duplicate measurements could exist in both the SPDM
Measurement Manifest and in SPDM Measurement Block locations other than 0xFD.
An SPDM Responder uses the spdm-indirect-map to identify indirect measurements rather than duplicate themin the SPDM Measurement Manifest.
Figure 6 shows a lead Attester translating indirect measurements to direct measurements. Measurements that areformatted according to the SPDM Measurement Manifest schema are already in a direct measurement format.
Indirect measurements are normally integrity protected by an SPDM transcript. The transcript may be included withtranslated indirect measurements or the lead Attester may protect them with a lead Attester key.
A lead Attester may check the CBOR tag (first 3 bytes) of the measurement manifest to determine whether it is capableof indirect measurement translation. If not, the lead Attester may identify a different lead Attester.
End of Informative Comment

Figure 6: Indirect measurement translation

If a lead Attester supports tagged-concise-evidence and an spdm-indirect measurement is used, a lead
Attester SHOULD translate indirect measurements to direct measurements.
Start of Informative Comment
If a profile is supplied, the mapping convention may differ from what is described in Table 7.
If indirect measurements are supplied, the authentication status of the original attester contained in the SPDM
transcript may be replaced by the authentication status of the lead Attester for direct measurements.
The spdm-indirect measurement need only appear in Evidence as this measurement type is meaningless whencontained in Reference Values.
To process indirect measurements, a lead Attester replaces the spdm-indirect measurements obtained from the
SPDM Measurement Block with measurements that comply with concise-evidence schema such that a Verifier
using CoRIM formatted Reference Values can appraise direct measurements. The SPDM
DMTFSpecMeasurementValueType field helps determine the CoMID measurement-values-map keys.
In cases where indirect measurements are in little-endian byte order, they are converted to the endian convention
used by the SPDM Measurement Manifest. CBOR encoding is big-endian.
End of Informative Comment
If a lead Attester supports tagged-concise-evidence and an spdm-indirect measurement is used, theDMTFMeasurementValueType to CoMID measurement mapping SHOULD be applied according to Table 7.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 24© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

DMTFSpecMeasurementValueType

CoMID MEASUREMENTVALUES-MAP Type

Comments

raw-value

The raw-value direct measurement SHALL be set such thatthe $raw-value-type-choice CBOR tag is 560(bytes),
and bytes contains the SPDM debug mode measurement in
big-endian format.

0x86

versionThe version-map direct measurement SHALL be set suchthat ver contains the SPDM version bit stream. If the SPDM
raw version is UTF-8 formatted characters, then the ver entry
SHALL be UTF-8 formatted characters.

0x87

svn

The svn-type-choice direct measurement SHALL be set
such that the tagged-svn contains the CBOR tag 552(svn),
and svn contains the SPDM svn measurement3.

0..0x7F

digests

The digest record alg: SHALL be set to the hash typenegotiated in the SPDM ALGORITHMS response message andthe digest record val: contains the SPDM digest
measurement.

0x80, 0xFF

raw-value

If the SPDM measurement is not a debug mode, version, svn,
or digest, then the $raw-value-type-choice CBOR tag is560(bytes), and bytes contains the SPDM measurement.

0x85

Table 7: DMTFMeasurementValueType to CoMID measurement mapping

Start of Informative Comment
If there are multiple measurements that map to the same type (e.g., digest, bit stream), disparate measurements
can be disambiguated using CoMID by assigning distinct measurement identifiers. For example, if the firstmeasurement uses a class-id measurement identifier OID, “2.1.123.1.15.4.99.1”, as its class identifier, then asecond measurement might use the OID, “2.1.123.1.15.4.99.2”, as its class identifier.
End of Informative Comment
If a lead Attester supports tagged-concise-evidence and the spdm-indirect measurement is used,and no SPDM Measurement Block measurement is found at an spdm-indirect-map index location then the spdmindirect-map entry SHOULD be invalidated by the lead Attester.
If a lead Attester supports tagged-concise-evidence and the spdm-indirect measurement is used, and two
or more spdm-indirect-map index entries point to the same SPDM Measurement Block measurement, hen the
spdm-indirect-map entry SHOULD be invalidated by the lead Attester.
If a lead Attester supports tagged-concise-evidence and the spdm-indirect measurement is used, and two
or more SPDM Measurement Block measurements collide with the same measurement-values-map key, then the
spdm-indirect-map entry SHOULD be invalidated by the lead Attester.
If a lead Attester supports tagged-concise-evidence and the spdm-indirect measurement is used, a lead
Attester MAY use profile from spdm-toc-map to apply a profile defined convention for mapping indirect
measurements.

3

Note that the SPDM Measurement field holds a little endian SVN, while CBOR integers are big endian.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 25© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

6.5.2 Appraisal of Evidence
Start of Informative Comment
An SPDM Responder may convey Evidence in two ways: (a) as extensions in a certificate and (b) as measurements
in an SPDM measurement block. A Verifier collects the available Evidence from both sources to arrive at a complete
set of Evidence. If Evidence contains duplicate measurements, redundant measurements are ignored.
The SPDM Responder may report runtime measurements over a dynamic Target Environment, in which case, use of
SPDM v1.2 MEAS_CAP may be helpful.
If the rim-locators field or the tcg-dice-endorsement-manifest-uri certificate extension are present,
the Verifier may use these URIs to locate Reference Values.
An appraisal process for Evidence is summarized in the DICE Endorsement Architecture for Devices [8] (see also [9],[14]).
SPDM v1.2 defines Device Mode Evidence. Use of Device Mode is fully compatible with concise evidence, see §6.3.2
and DICE certificate extensions, see [2].
End of Informative Comment
Evidence measurements SHOULD NOT be redundantly supplied in an SPDM Measurement Block or in certificates.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 26© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

7 CoMID SCHEMA EXTENSIONSThis section defines extensions to the CoMID schema [8] that support concise evidence schema definition.

7.1 Indirect Measurements Extension
The CoMID measurement-values-map SHALL be extended to define the spdm-indirect-map as follows:$$measurement-values-map-extension //= (&(spdm-indirect: 12) => spdm-indirect-map)
spdm-indirect-map = {? &(index: 0) => [ + uint ]* $$spdm-indirect-map-extension}
The spdm-indirect-map contains an array of unsigned integers corresponding to the SPDM Measurement Blockindexes containing indirect measurement values.
The spdm-indirect measurement type SHOULD NOT be used as Reference Values.

7.2 Measurement Authorization Extension
The CoMID schema measurement-map is extended to include the authorized-by entry that identifies the entity
authorized to supply reference values. The authorized-by entry applies to the measurement values found inmeasurement-map.
The authorized-by entry contains a public key identifier of the entity authorized to provide Reference Values.
Normally, the supplier that produces the device is authorized to supply the Endorsements.
The authorized-by field can be included in Evidence to assert, to a Verifier, which Endorser is expected to supply
Reference Values.
The authorized-by entry contains the public key identifier from a root or intermediate certificate in the certification
path of the certificate that issues the DeviceID Key4.
Start of Informative Comment
The consequence of not checking for authorization is that a Verifier might accept values that are incorrect.
End of Informative Comment
The CoMID measurement-map structure SHALL be extended with authorized-by as follows:$$measurement-map-extension //= (? &(authorized-by: 2) => [ + $crypto-key-type-choice ])The $crypto-key-type-choice SHALL identify the entity authorized to supply Reference Values.
If authorized-by is not specified, the manifest signer SHALL identity the entity authorized to supply Reference
Values.

7.3 CoSWID Triple Extension
The CoMID schema triples-map is extended with triples that associate a Target Environment with one or more
CoSWID [13] tags.
4

Note that the DeviceID Key and keys derived from subsequent DICE layers are device specific, so there is no point in including thesekeys in the authorized-by entry.
TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 27© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

Start of Informative Comment
Reference Values used to match ev-coswid-triple-record Evidence require an extension to the CoMID schema
so that matching Reference Values can be included in the manifest.
End of Informative Comment
The CoMID triples-map structure SHALL be extended to include coswid-triples as follows:$$triples-map-extension //= (&(coswid-triples: 6) => [ + coswid-triple-record ])coswid-triple-record = [environment-map,[ + concise-swid-tag-id ]]concise-swid-tag-id = text / bstr .size 16 ; see CoSWID schema
The triple subject Target Environment SHALL be associated with one or more triple object CoSWID tags.
The coswid-triple-record is a record containing two elements: environment-map, and an array of conciseswid-tag-id. The environment map identifies which Target Environment is suitable for installing and loading thesoftware. The array of concise-swid-tag-id identifies CoSWID tags.
Start of Informative Comment
Typically, CoSWID tags are found in a CoRIM identified by concise-swid-tag-id.
End of Informative Comment
The coswid-triple-record differs from the ev-coswid-triple-record in that Reference Values are foundin a CoSWID tag instead of the CoSWID triple record.

7.4 Domain Membership Triple Extension
The CoMID schema triples-map extension point is used to define domain membership triples that associates adomain with one or more Target Environments.
The CoMID triples-map structure SHALL be extended to include membership-triples as follows:$$triples-map-extension //= (? &(membership-triples: 5) =>[ + domain-membership-triple-record ])domain-membership-triple-record = [$domain-type-choice,[ + $environment-type-choice ]]$environment-type-choice /= environment-map
The domain members, as defined by $environment-type-choice, are indivisibly grouped by the target domain,as defined by $domain-type-choice.
The triple subject domain SHALL support having one or more members.
Member environment type is extensible, as defined by $environment-type-choice, and supports at least
environment-map.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 28© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

7.5 Domain Dependency Triple Extension
The CoMID schema triples-map extension point is used to define domain dependency triples that associate adomain with one or more dependent domains.
Start of Informative Comment
Dependency means the subject domain’s correctness properties rely on the object domain(s). For example, theprotection of a child domain's key is a prerequisite to a trustworthiness assertion made by the parent domain.
End of Informative Comment
The CoMID triples-map structure SHALL be extended to include dependency-triples as follows:$$triples-map-extension //= (? &(dependency-triples: 4) =>[ + domain-dependency-triple-record ])domain-dependency-triple-record = [$domain-type-choice,[ + $domain-type-choice ]]$domain-type-choice /= uint
$domain-type-choice /= tstr
$domain-type-choice /= tagged-uuid-type$domain-type-choice /= tagged-oid-type
The consistency of the triple subject domain, as defined by $domain-type-choice, depends on the consistency of
the triple object subordinate domains, as defined by $domain-type-choice.
The triple subject domain SHALL support having one or more dependent domains.
Dependent domain type is extensible, as defined by $domain-type-choice, and supports at least uint, tstr,
tagged-uuid-type, and tagged-oid-type.

7.6 Target Environment Properties Extension
The Target Environments have properties that may be indicators of trust worthiness.
Target Environment properties can be expressed in the CoMID schema using flags-map.
The CoMID schema SHALL be extended as follows:$$flags-map-extension //= (? &(runtime-meas: 6) => bool
? &(immutable: 7) => bool
? &(tcb: 8) => bool)
Target Environments properties MAY be TRUE, FALSE, or not specified.
Target Environments MAY have the following properties:•

runtime-meas: This property, if set to TRUE, indicates that the Target Environment is measured after being
loaded into memory.

•

immutable: This property, if set to TRUE, indicates that the measured Target Environment is immutable.

•

tcb: This property, if set to TRUE, indicates that the Target Environment measurements are measurementsof a Trusted Computing Base (TCB).

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 29© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

If a property is asserted for a Target Environment that is composed of a subordinate or nested Target Environment,
the property SHALL NOT apply to the subordinate.
The flags-map properties MAY be asserted in Endorsed Values, Reference Values, or Evidence.
Start of Informative Comment
The DiceTcbInfo OperationalFlags is an Evidence format that is matches with Reference Values as defined byflags-map.
When flags-map is an Endorsed Value, it is not asserted until the Target Environment has been successfully
appraised.
If a flags-map property is a Reference Value that matches its analog in Evidence, it is accepted. If the property has
previously been accepted and it is accepted again, it can be ignored since acceptance of like Claims is idempotent.
When a flags-map property is asserted only in Evidence, (i.e., it is not asserted in either Endorsed Values orReference Values) the property is asserted after all other Evidence Claims have been accepted.
End of Informative Comment

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 30© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

8 Appendix A - Use Cases and Evidence management
Table 8 summarizes some of the SPDM use cases. The table describes the use case, the type of Evidence conveyed,
and the attestation roles that process the Evidence.
Use Case

Evidence

Verifier(requester)Attestor(responder)

Asset Tracking

DeviceID
Certificate

RequestCertificate

ProvideCertificate

FirmwareMeasurement

Measurement
Manifest

RequestMeasurement(s)ProvideMeasurement(s)On Boarding

Alias
Certificate

Provision
Certificate

Add a Certificate
Chain or add
CertificatesFirmware Update

Alias
Certificate

RequestCertificate

Provide a
Certificate

Reprovision, Reonboarding

Alias
Certificate

Provision theCertificate Chain

Verify and store

Remanufacturing

Device andAlias
Certificates

Provision theCertificate chain

Verify and store

Decommissioning

Device andAlias
Certificates

Provision

UpdateNotes
When tracking hardware identity,
a DeviceID Certificate could bepart of the certificate chain
containing the Alias Certificate oran end entity certificate. The
DeviceID Key can be used as an
instance specific hardware
identity.
An Alias Certificate can be used
for change detection.
This is used to provision a newcertificate chain5 or add an Alias
Certificate to an existingcertificate chain that contains a
DeviceID Certificate.
Adding an Alias Certificate to acertificate chain containing a
DeviceID Certificate, requires
enabling an Embedded
Certificate Authority on thedevice.
This is used for firmware orsoftware change detection.
Performed in a secureenvironment or at least with asecure session.
This is performed in a secureenvironment. The device identity
will change, leading to a new
DeviceID Key, and reissuance of
the ECA and Alias certificates.
This changes the DeviceID Key,
thus invalidating any stored andgenerated certificates tied to theprevious DeviceID Key, including
DeviceID Certificate, ECA, andAlias certificates.

Table 8 Use Cases and Evidence Mapping

5

The SPDM specification v1.2 requires that all SPDM certificate slots chain to the same Alias certificate.

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 31© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

9 Appendix B – Sample Concise Evidence in CBOR Diagnostic Format
9.1 SPDM Indirect Evidence in CBOR Diagnostic Format
The following pseudocode is an example of spdm-indirect and authorized-by in measurement-map.
/ spdm-toc / 570( {/ tagged-evidence / 0 : [571( {/ ce.ev-triples / 0 : {/ ce.evidence-triples / 0 : [[ /** uses reference-triple-record schema **// environment-map / {/ class / 0 : {/ class-id / 0 :/ tagged-oid-type / 111(h'6086480186F84D010F046301'), /2.16.840.1.113741.1.15.4.99.1 // vendor / 1 : "xyzinc.example"}},[/ measurement-map / {/ mval / 1 : {/ spdm-indirect / 12 : / extends measurement-values-map /{/ index / 0 : [ 1, 2, 3, 4, 5 ]},/ digests / 2 : [ [ 1,h'FFFEFDFCFBFAF9F8F7F6F5F4F3F2F1F0'] ],/ raw-value / 4 : 560(h'0123456789')},/ authorized-by / 2 : [/ tagged-pkix-base64-key-type / 554("base64_key_X")
]
}
]
]
]
}
} )
],
/ rim-locators / 1 : [/ corim-locator-map / {/ ** link to reference manifest ** // href / 0 : 32("https://refs.example.com/path/to/reference.corim")},/ corim-locator-map / {/ ** link to manifest revocation list ** // href / 0 : 32("https://rimrevoke.example.com/path/to/revocation.xcorim")}]} )TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 32© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

9.2 Domain Dependency Evidence in CBOR Diagnostic Format
The following pseudocode shows a hypothetical case where the SPDM Responder is aware of multiple layers and thetrust dependencies between various modules. A real-world case might include only the layer or module that the SPDM
Responder describes using SPDM indirect evidence.
/ spdm-toc / 570( {/ tagged-evidence / 0 : [571( {/ ce.ev-triples / 0 : {/ ce.dependency-triples / 2 : [[ 3, [ 2 ] ],[ 2, [ 1, "L1-extension" ] ],[ "L1-extension", [ "XYZ_Root-of-trust" ]],[ 1, [ "XYZ_Root-of-trust" ]]
]
}
} )
],
/ spdm-rim-locators / 1 : [/ corim-locator-map / {/ ** link to reference manifest ** // href / 0 :32("https://refs.example.com/path/to/reference.corim")},/ corim-locator-map / {/ ** link to manifest revocation list ** // href / 0 : 32("https://rimrevoke.example.com/path/to/revocation.xcorim")}]} )9.3 Domain Membership Evidence in CBOR Diagnostic Format
The following pseudocode shows a hypothetical case where the SPDM Responder is aware of multiple layers anddomain dependencies. The various measurements, as described by environment-map, are listed for each domain.
/ spdm-toc / 570( {/ tagged-evidence / 0 : [571( {/ ce.ev-triples / 0 : {/ ce.membership-triples / 3 : [[ / domain / "XYZ_Root-of-trust",[/ environment-map / {/ ** A Root of Trust module ** // class / 0 : {/ class-id / 0 :/ tagged-oid-type / 111(h'0607517B010F6201'),/ 2.1.123.1.15.98.1 // vendor / 1 : "XYZ.example"}}]
TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 33© TCG 2023

TCG DICE Concise Evidence Binding for SPDM],
[ / domain / 1,[
/ environment-map / {/ ** Layer 1 loader module 1 ** // class / 0 : {/ class-id / 0 :/ tagged-oid-type / 111(h'0607517B010F0801'),/ 2.1.123.1.15.8.1 // vendor / 1 : "LoadInc.example",/ layer / 3 : 1}},/ environment-map / {/ ** Layer 1 loader module 2 ** // class / 0 : {/ class-id / 0 :/ tagged-oid-type / 111(h'0607517B010F0802'), /2.1.123.1.15.8.2 // vendor / 1 : "LoadInc.example",/ layer / 3 : 1}}]],[ / domain / "L1-extension",[/ environment-map / {/ ** L1 Extension module 1 ** // class / 0 : {/ class-id / 0 :/ tagged-oid-type / 111(h'0607517B010F0903'), /2.1.123.1.15.9.3 // vendor / 1 : "LoadInc.example",/ layer / 3 : 1}}]],[ / domain / 2,[
/ environment-map / {/ ** Layer 2 design module 1 ** // class / 0 : {/ class-id / 0 :/ tagged-oid-type / 111(h'0607517B010F0401'),/ 2.1.123.1.15.4.1 // vendor / 1 : "FPGAsRuS.example",/ layer / 3 : 2}},/ environment-map / {/ ** Layer 2 design module 2 ** // class / 0 : {/ class-id / 0 :TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 34© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

/ tagged-oid-type / 111(h'0607517B010F0402'), /2.1.123.1.15.4.2 // vendor / 1 : "FPGAsRuS.example",/ layer / 3 : 2}},/ environment-map / {/ ** Layer 2 design module 3 ** // class / 0 : {/ class-id / 0 :/ tagged-oid-type / 111(h'0607517B010F0403'), /2.1.123.1.15.4.3 // vendor / 1 : "FPGAsRuS.example",/ layer / 3 : 2}}]],[ / domain / 3,[
/ environment-map / {/ ** ISV App module 1 ** // class / 0 : {/ class-id / 0 :/ tagged-oid-type / 111(h'0607517B010F046301'),/ 2.1.123.1.15.4.99.1 // vendor / 1 : "ISV-App.example"}},/ environment-map / {/ ** ISV App module 2 ** // class / 0 : {/ class-id / 0 :/ tagged-oid-type / 111(h'0607517B010F046302'),/ 2.1.123.1.15.4.99.2 // vendor / 1 : "ISV-App.example"
}
}
]
]
]
}
} )
],
/ spdm-rim-locators / 1 : [/ corim-locator-map / {/ ** link to reference manifest ** // href / 0 :32("https://refs.example.com/path/to/reference.corim")},/ corim-locator-map / {/ ** link to manifest revocation list ** // href / 0 : 32("https://rimrevoke.example.com/path/to/revocation.xcorim")}
TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 35© TCG 2023

TCG DICE Concise Evidence Binding for SPDM]})

9.4 CoSWID Evidence in CBOR Diagnostic Format
The following pseudocode is an example where Evidence is represented using the CoSWID schema. A fictitious
software measurement is described using the CoSWID schema.
/ spdm-toc / 570( {/ tagged-evidence / 0 : [571( {/ ce.ev-triples / 0 : {/ ce.coswid-triples / 4 : [[ /** ev-coswid-triple-record **// environment-map / {/ class / 0 : {/ class-id / 0 :/ tagged-oid-type / 111(h'0607517B010F046308'), /2.1.123.1.15.4.99.8 // vendor / 1 : "xyzinc.example"}},[/ ev-coswid-evidence-map / {/ ce.coswid-tag-id / 0 : "com.acme.rrd2013-ce-sp1v4-1-5-0",/ ce.coswid-evidence / 1 : { /evidence-entry // directory / 16: {/ fs-name / 24: "rrdetector",/ root / 25: "%programdata%",/ path-elements / 26: {/ file / 17: {/ fs-name / 24: "rrdetector.exe",/ size / 20: 532712,/ hash / 7: [/ hash-alg-id / 1,
/ hash-value /h'A314FC2DC663AE7A6B6BC6787594057396E6B3F569CD50FD5DDB4D1BBAFD2B6A'
]
}
}
}
},
/ ce.authorized-by / 2 : [/ tagged-pkix-base64-key-type/554("base64_key_X")
]
}
]
]
}
} )
],
/ rim-locators / 1 : [/ corim-locator-map / {TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 36© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

/ ** link to reference coswids ** // href / 0 : 32("https://refsw.example.com/path/to/reference.corim")},/ corim-locator-map / {/ ** link to reference manifest ** // href / 0 : 32("https://refhw.example.com/path/to/reference.corim")},/ corim-locator-map / {/ ** link to manifest revocation list ** // href / 0 : 32("https://rimrevoke.example.com/path/to/revocation.xcorim")}]} )9.5 Properties Flags as Endorsements in CBOR Diagnostic Format
The following pseudocode is an example of properties flags represented as Endorsed Values.
/ concise-mid-tag / {/ tag-identity / 1 : {/ tag-id / 0 : h'1EACD596F4A34FB699BFAEB58E0A4E49'},/ entities / 2 : [ {/ entity-name / 0 : "OEM-A",/ reg-id / 1 : 32("https://oem-a.example"),/ role / 2 : [ 0 ] / tag-creator /} ],/ linked-tags / 3 : [/ linked-tag-map / {/ linked-tag-id / 0 : h'1EACD596F4A34FB699BFAEB58E0A4E47',/ tag-rel / 1 : / supplements / 0},/ linked-tag-map / {/ linked-tag-id / 0 : h'AF1CD895BE784ADBB7E9ADD44A65ABF3',/ tag-rel / 1 : / supplements / 0}],/ triples / 4 : {/ endorsed-triples / 1 : [[/ environment-map / {/ class / 0 : {/ ** Firmware is valid (example) ** // class-id / 0 :/ tagged-oid-type / 111(h'6086480186F84D010F046301'),/ 2.16.840.1.113741.1.15.4.99.1 // vendor / 1 : "fwmfginc.example"}},[/ measurement-map / {/ mval / 1 : {TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 37© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

/ flags / 3 : {/ secure / 0 : true,/ runtime-meas / 6 : false,/ immutable / 7 : true,/ tcb / 8 : true}},/ authorized-by / 2 : [/ tagged-pkix-base64-key-type / 554("base64_key_X")
]
}
]
]
]
}
}

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 38© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

10 Appendix C – Sample Pretty CBOR
10.1 SPDM Indirect Evidence in Pretty CBOR Format
d9 023aa2
00
81# tag(570)# map(2)# unsigned(0)# array(1)d9 023b# tag(571)a1# map(1)00# unsigned(0)a1# map(1)00# unsigned(0)81# array(1)82# array(2)a1# map(1)00# unsigned(0)a2# map(2)00# unsigned(0)d8 6f# tag(111)4c# bytes(12)6086480186f84d010f046301 #"`\x86H\x01\x86\xF8M\x01\x0F\x04c\x01"
01# unsigned(1)6e# text(14)78797a696e632e6578616d706c65 #"xyzinc.example"
81# array(1)a2# map(2)01# unsigned(1)a1# map(1)0c# unsigned(12)85# array(5)01 # unsigned(1)02 # unsigned(2)03 # unsigned(3)04 # unsigned(4)05 # unsigned(5)02# unsigned(2)81# array(1)d9 022a # tag(554)
6c # text(12)6261736536345f6b65795f58 #"base64_key_X"01# unsigned(1)82# array(2)a1# map(1)00# unsigned(0)d8 20# tag(32)78 30# text(48)68747470733a2f2f726566732e6578616d706c652e636f6d2f706174682f746f2f7
265666572656e63652e636f72696d #"https://refs.example.com/path/to/reference.corim"

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 39© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

a1
00
d8 20
78 38

# map(1)# unsigned(0)# tag(32)# text(56)68747470733a2f2f72696d2d7265766f6b652e6578616d706c652e636f6d2f70617
4682f746f2f7265766f636174696f6e2e78636f72696d # https://rimrevoke.example.com/path/to/revocation.xcorim

10.2 Domain Dependency Evidence in Pretty CBOR Format
d9 023aa2
00
81# tag(570)# map(2)# unsigned(0)# array(1)d9 023b# tag(571)a1# map(1)00# unsigned(0)a1# map(1)00# unsigned(0)81# array(1)82# array(2)a1# map(1)00# unsigned(0)a2# map(2)00# unsigned(0)d8 6f# tag(111)4c# bytes(12)6086480186f84d010f046301 #"`\x86H\u0001\x86\xF8M\u0001\u000F\u0004c\u0001"
01# unsigned(1)6e# text(14)78797a696e632e6578616d706c65 #"xyzinc.example"
81# array(1)a2# map(2)01# unsigned(1)a3# map(3)0c# unsigned(12)a1# map(1)00 # unsigned(0)85 # array(5)01 # unsigned(1)02 # unsigned(2)03 # unsigned(3)04 # unsigned(4)05 # unsigned(5)02# unsigned(2)81# array(1)82 # array(2)01 # unsigned(1)50 # bytes(16)TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 40© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0 #"\xFF\xFE\xFD\xFC\xFB\xFA\xF9\xF8\xF7\xF6\xF5\xF4\xF3\xF2\xF1\xF0"
04# unsigned(4)d9 0230 # tag(560)
45 # bytes(5)0123456789 # "\u0001#Eg\x89"02# unsigned(2)81# array(1)d9 022a # tag(554)
6c # text(12)6261736536345f6b65795f58 #"base64_key_X"01# unsigned(1)82# array(2)a1# map(1)00# unsigned(0)d8 20# tag(32)78 30# text(48)68747470733a2f2f726566732e6578616d706c652e636f6d2f706174682f746f2f7
265666572656e63652e636f72696d #"https://refs.example.com/path/to/reference.corim"
a1# map(1)00# unsigned(0)d8 20# tag(32)78 38# text(56)68747470733a2f2f72696d2d7265766f6b652e6578616d706c652e636f6d2f70617
4682f746f2f7265766f636174696f6e2e78636f72696d # "https://rimrevoke.example.com/path/to/revocation.xcorim"

10.3 Domain Membership Evidence in Pretty CBOR Format
d9 023aa2
00
81# tag(570)# map(2)# unsigned(0)# array(1)d9 023b# tag(571)a1# map(1)00# unsigned(0)a1# map(1)03# unsigned(3)85# array(5)82# array(2)71# text(17)58595a5f526f6f742d6f662d7472757374 #"XYZ_Root-of-trust"81# array(1)a1# map(1)00# unsigned(0)a2# map(2)00# unsigned(0)d8 6f # tag(111)

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 41© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

48

# bytes(8)0607517b010f6201 #"\x06\x06Q{\x01\x0Fb\x01"
01
6b# unsigned(1)# text(11)58595a2e6578616d706c65 #"XYZ.example"
82
01
82

# array(2)# unsigned(1)# array(2)a1# map(1)00# unsigned(0)a3# map(3)00# unsigned(0)d8 6f # tag(111)
48 # bytes(8)0607517b010f0801 #"\x06\x06Q{\x01\x0F\b\x01"
01
6f# unsigned(1)# text(15)4c6f6164496e632e6578616d706c65# "LoadInc.example"
03
01# unsigned(3)# unsigned(1)a1# map(1)00# unsigned(0)a3# map(3)00# unsigned(0)d8 6f # tag(111)
48 # bytes(8)0607517b010f0802 #"\x06\x06Q{\x01\x0F\b\x02"
01
6f# unsigned(1)# text(15)4c6f6164496e632e6578616d706c65# "LoadInc.example"
03
01# unsigned(3)# unsigned(1)82# array(2)6c# text(12)4c312d657874656e73696f6e # "L1extension"81
a1# array(1)# map(1)00# unsigned(0)a3# map(3)00# unsigned(0)d8 6f # tag(111)
48 # bytes(8)0607517b010f0903 #"\x06\x06Q{\x01\x0F\t\x03"
01
6f# unsigned(1)# text(15)4c6f6164496e632e6578616d706c65# "LoadInc.example"
TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 42© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

03
01

# unsigned(3)# unsigned(1)82# array(2)02# unsigned(2)83# array(3)a1# map(1)00# unsigned(0)a3# map(3)00# unsigned(0)d8 6f # tag(111)
48 # bytes(8)0607517b010f0401 #"\x06\x06Q{\x01\x0F\x04\x01"
01# unsigned(1)70# text(16)46504741735275532e6578616d706c65 # "FPGAsRuS.example"
03# unsigned(3)02# unsigned(2)a1# map(1)00# unsigned(0)a3# map(3)00# unsigned(0)d8 6f # tag(111)
48 # bytes(8)0607517b010f0402 #"\x06\x06Q{\x01\x0F\x04\x02"01# unsigned(1)70# text(16)46504741735275532e6578616d706c65 # "FPGAsRuS.example"
03# unsigned(3)02# unsigned(2)a1# map(1)00# unsigned(0)a3# map(3)00# unsigned(0)d8 6f # tag(111)
48 # bytes(8)0607517b010f0403 #"\x06\x06Q{\x01\x0F\x04\x03"
01# unsigned(1)70# text(16)46504741735275532e6578616d706c65 # "FPGAsRuS.example"
03# unsigned(3)02# unsigned(2)82# array(2)03# unsigned(3)82# array(2)a1# map(1)00# unsigned(0)a2# map(2)00# unsigned(0)d8 6f # tag(111)
TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 43© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

49

# bytes(9)0607517b010f046301 #"\x06\x06Q{\x01\x0F\x04c\x01"
01
6f# unsigned(1)# text(15)4953562d4170702e6578616d706c65# "ISV-App.example"
a1
00
a2

# map(1)# unsigned(0)# map(2)00# unsigned(0)d8 6f # tag(111)
49 # bytes(9)0607517b010f046302 #"\x06\x06Q{\x01\x0F\x04c\x02"
01
6f# unsigned(1)# text(15)4953562d4170702e6578616d706c65# "ISV-App.example"
01
82
a1
00
d8 20
78 30

# unsigned(1)# array(2)# map(1)# unsigned(0)# tag(32)# text(48)68747470733a2f2f726566732e6578616d706c652e636f6d2f706174682f746f2f7
265666572656e63652e636f72696d #"https://refs.example.com/path/to/reference.corim"
a1# map(1)00# unsigned(0)d8 20# tag(32)78 38# text(56)68747470733a2f2f72696d2d7265766f6b652e6578616d706c652e636f6d2f70617
4682f746f2f7265766f636174696f6e2e78636f72696d # https://rimrevoke.example.com/path/to/revocation.xcorim

10.4 CoSWID Evidence in Pretty CBOR Format
d9 023aa200
81
d9 023b
a1
00
a1
04
81
82
a1
00
a2

# tag(570)# map(2)# unsigned(0)# array(1)# tag(571)# map(1)# unsigned(0)# map(1)# unsigned(4)# array(1)# array(2)# map(1)# unsigned(0)# map(2)

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 44© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

00
d8 6f
49

# unsigned(0)# tag(111)# bytes(9)0607517b010f046308 #"\u0006\u0007Q{\u0001\u000f\u0004c\b"01# unsigned(1)6e# text(14)78797a696e632e6578616d706c65 #"xyzinc.example"
81# array(1)a3# map(3)00# unsigned(0)78 20# text(32)636f6d2e61636d652e727264323031332d63652d7370312d76342d312d352d30 #"com.acme.rrd2013-ce-sp1-v4-1-5-0"
01# unsigned(1)a1# map(1)10# unsigned(16)a3# map(3)18 18 # unsigned(24)6a # text(10)72726465746563746f72 #"rrdetector"
18 19 # unsigned(25)6d # text(13)2570726f6772616d6461746125 #"%programdata%"
18 1a # unsigned(26)a1 # map(1)11 # unsigned(17)a3 # map(3)18 18 # unsigned(24)6e # text(14)72726465746563746f722e657865 # "rrdetector.exe"
14 # unsigned(20)1a 000820e8 #unsigned(532712)
07 # unsigned(7)82 # array(2)01 # unsigned(1)58 20 # bytes(32)a314fc2dc663ae7a6b6bc6787594057396e6b3f569cd50fd5ddb4d1bbafd2b6a #"\xA3\u0014\xFC\xC6c\xAEzkk\xC6xu\x94\u0005s\x96\xE6\xB3\xF5i\xCDP\xFD]\xDBM\e\xBA\xFD+j"02# unsigned(2)81# array(1)d9 022a # tag(554)
6c # text(12)6261736536345f6b65795f58 #"base64_key_X"01# unsigned(1)TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 45© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

83
a1
00
d8 20
78 32

# array(3)# map(1)# unsigned(0)# tag(32)# text(50)68747470733a2f2f7265662d73772e6578616d706c652e636f6d2f706174682f746
f2f7265666572656e63652e636f72696d # "https://refsw.example.com/path/to/reference.corim"
a1# map(1)00# unsigned(0)d8 20# tag(32)78 32# text(50)68747470733a2f2f7265662d68772e6578616d706c652e636f6d2f706174682f746
f2f7265666572656e63652e636f72696d # "https://refhw.example.com/path/to/reference.corim"
a1# map(1)00# unsigned(0)d8 20# tag(32)78 38# text(56)68747470733a2f2f72696d2d7265766f6b652e6578616d706c652e636f6d2f70617
4682f746f2f7265766f636174696f6e2e78636f72696d # "https://rimrevoke.example.com/path/to/revocation.xcorim"

10.5 Properties Flags as Endorsements in Pretty CBOR Formata4# map(4)# unsigned(1)# map(1)00# unsigned(0)50# bytes(16)1eacd596f4a34fb699bfaeb58e0a4e49 #"\x1E\xAC\xD5\x96\xF4\xA3O\xB6\x99\xBF\xAE\xB5\x8E\nNI"
02# unsigned(2)81# array(1)a3# map(3)00# unsigned(0)65# text(5)4f454d2d41# "OEM-A"
01# unsigned(1)d8 20# tag(32)75# text(21)68747470733a2f2f6f656d2d612e6578616d706c65 #"https://oem-a.example"
02# unsigned(2)81# array(1)00# unsigned(0)03# unsigned(3)82# array(2)a2# map(2)00# unsigned(0)50# bytes(16)01
a1

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 46© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

1eacd596f4a34fb699bfaeb58e0a4e47 #"\x1E\xAC\xD5\x96\xF4\xA3O\xB6\x99\xBF\xAE\xB5\x8E\nNG"
01# unsigned(1)00# unsigned(0)a2# map(2)00# unsigned(0)50# bytes(16)af1cd895be784adbb7e9add44a65abf3 #"\xAF\x1C\xD8\x95\xBExJ\xDB\xB7\xE9\xAD\xD4Je\xAB\xF3"
01# unsigned(1)00# unsigned(0)04# unsigned(4)a1# map(1)01# unsigned(1)81# array(1)82# array(2)a1# map(1)00# unsigned(0)a2# map(2)00# unsigned(0)d8 6f# tag(111)4c# bytes(12)6086480186f84d010f046301 #"`\x86H\x01\x86\xF8M\x01\x0F\x04c\x01"
01# unsigned(1)70# text(16)66776d6667696e632e6578616d706c65 #"fwmfginc.example"
81# array(1)a2# map(2)01# unsigned(1)a1# map(1)03# unsigned(3)a4# map(4)00# unsigned(0)f5# primitive(21)06# unsigned(6)f4# primitive(20)07# unsigned(7)f5# primitive(21)08# unsigned(8)f5# primitive(21)02# unsigned(2)81# array(1)d9 022a# tag(554)6c# text(12)6261736536345f6b65795f58 #"base64_key_X"

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 47© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

11 Appendix D – CDDLThis section contains Concise Data Definition Language (CDDL) [12] expressions of the CDDL normative containedin §Error! Reference source not found..

11.1 CoMID Schema Extensions
This section contains extensions to the CoMID schema that support the concise-evidence schema.
$$measurement-values-map-extension //= (? &(spdm-indirect: 12) => spdm-indirect-map)
spdm-indirect-map = {&(index: 0) => [ + uint ]* $$spdm-indirect-map-extension}$$measurement-map-extension //= (? &(authorized-by: 2) => [ + $crypto-key-type-choice ])$$triples-map-extension //= (? &(dependency-triples: 4) =>[ + domain-dependency-triple-record ])domain-dependency-triple-record = [$domain-type-choice,[ + $domain-type-choice ]]$domain-type-choice /= uint
$domain-type-choice /= tstr
$domain-type-choice /= tagged-uuid-type$domain-type-choice /= tagged-oid-type$$triples-map-extension //= (? &(membership-triples: 5) =>[ + domain-membership-triple-record ])domain-membership-triple-record = [$domain-type-choice,[ + $environment-type-choice ]]$environment-type-choice /= environment-map$$triples-map-extension //= (? &(coswid-triples: 6) => [ + coswid-triple-record ])coswid-triple-record = [environment-map,[ + concise-swid-tag-id ]]concise-swid-tag-id = text / bstr .size 16 ; see coswid$$flags-map-extension //= (? &(runtime-meas: 6) => bool
? &(immutable: 7) => bool
TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 48© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

? &(tcb: 8) => bool)

11.2 SPDM Table of Contents and Concise EvidenceThis section contains the complete spdm-toc and concise-evidence cddl.
tagged-spdm-toc = #6.IANA-TBA(spdm-toc-map)
spdm-toc = spdm-toc-map
spdm-toc-map = {&(tagged-evidence: 0) => [ + $tagged-evidence-type-choice]? &(rim-locators: 1) => [ + corim-locator-map ] ;see comid? &(profile: 2) => profile-type-choice ; see corim* $$toc-map-extension}$tagged-evidence-type-choice /= tagged-concise-evidence
tagged-concise-evidence = #6.IANA-TBA(concise-evidence-map)
concise-evidence = concise-evidence-map
concise-evidence-map = {&(ce.ev-triples: 0) => ev-triples-map? &(ce.evidence-id: 1) => $evidence-id-type-choice* $$concise-evidence-map-extension}$evidence-id-type-choice /= tagged-uuid-type
ev-triples-map = non-empty<{? &(ce.evidence-triples: 0) => [ + reference-triple-record ]? &(ce.identity-triples: 1) => [ + identity-triple-record ]? &(ce.dependency-triples: 2) =>[ + domain-dependency-triple-record ]? &(ce.membership-triples: 3) =>[ + domain-membership-triple-record ]? &(ce.coswid-triples: 4) => [ + ev-coswid-triple-record ]? &(ce.attest-key-triples: 5) => [ + attest-key-triple-record ]* $$ev-triples-map-extension}>
ev-coswid-triple-record = [environment-map,[ + ev-coswid-evidence-map ]]ev-coswid-evidence-map = {? &(ce.coswid-tag-id: 0) => concise-swid-tag-id,&(ce.coswid-evidence: 1) => evidence-entry ; see coswid? &(ce.authorized-by: 2) => [ + $crypto-key-type-choice ]}TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 49© TCG 2023

TCG DICE Concise Evidence Binding for SPDM

12 Appendix E - IANA Considerations
THIS SECTION TO BE REMOVED AFTER IANA ASSIGNMENTS ARE COMPLETED
The specification requests reservation of the following CBOR tags from the CBOR Tags Registry [10]:Requested tag: 570
Data item: map
Semantics: a CBOR encoded map - spdm-toc-map
Point of contact: ned.smith&intel.com
Description of semantics: <this specification>
Requested tag: 571
Data item: map
Semantics: a CBOR encoded map - concise-evidence-map
Point of contact: ned.smith&intel.com
Description of semantics: <this specification>

TCG DICE Concise Evidence Binding for SPDM | Version 1.00 | Revision 0.53 | 6/1/2023 | <Public Review >Page 50© TCG 2023