Remote ATtestation ProcedureS J. Beaney
Internet-Draft Intel Corporation
Intended status: Informational Y. Deshpande
Expires: 5 October 2025 ARM Corporation
A. Draper
Altera Corporation
V. Scarlata
N. Smith
Intel Corporation
3 April 2025
Intel Profile for Remote Attestation
draft-cds-rats-intel-corim-profile-04
Abstract
This document is a profile of various IETF and TCG standards that
support remote attestation. The profile supports Intel-specific
adaptations and extensions for Evidence, Endorsements and Reference
Values. This profile describes apticulareplication of CoRIM, EAT,
CMW, TCG concise evidence, and TCG DICE specifications. In
particular, CoRIM is extended to define measurement types that are
unique to Intel and defines Reference Values types that support
matching Evidence based on range and subset comparison. Multiple
Evidence formats are anticipated, based on IETF and TCG
specifications. Evidence formats are mapped to Reference Values
expressions based on CoRIM and CoRIM extensions found in this
profile. The Evidence to Reference Values mappings are either
documented by industry specifications or by this profile. Reference
Value Providers and Endorsers may use this profile to author
mainifests containing Reference Values and Endorsements that require
Intel profile support from parser implementations. Parser
implementations can recognize the Intel profile by profile identifier
values contained within attestation conceptual mmessages and from
profile parameters to media types or profile specific content format
identifiers.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://nedmsmith.github.io/draft-cds-rats-intel-corim-profile/draft-
cds-rats-intel-corim-profile.html. Status information for this
document may be found at https://datatracker.ietf.org/doc/draft-cds-
rats-intel-corim-profile/.
Beaney, et al. Expires 5 October 2025 [Page 1]
Internet-Draft Intel profile April 2025
Discussion of this document takes place on the Remote ATtestation
ProcedureS Working Group mailing list (mailto:rats@ietf.org), which
is archived at https://mailarchive.ietf.org/arch/browse/rats/.
Subscribe at https://www.ietf.org/mailman/listinfo/rats/.
Source for this draft and an issue tracker can be found at
https://github.com/nedmsmith/draft-cds-rats-intel-corim-profile.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 October 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Profile Identifier . . . . . . . . . . . . . . . . . . . . . 6
4.1. Intel Profile . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Profile Specific Media and Content Types . . . . . . . . 6
5. Attester Anatomy . . . . . . . . . . . . . . . . . . . . . . 7
Beaney, et al. Expires 5 October 2025 [Page 2]
Internet-Draft Intel profile April 2025
6. Evidence Profile . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Evidence Hierarchy . . . . . . . . . . . . . . . . . . . 8
6.2. Concise Evidence . . . . . . . . . . . . . . . . . . . . 9
7. Reference Values and Endorsements Profile . . . . . . . . . . 9
7.1. Concise Module ID Tag (CoMID) . . . . . . . . . . . . . . 9
7.2. Raw Value Measurements . . . . . . . . . . . . . . . . . 10
8. CoRIM Extensions . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 10
8.1.1. Masked Values . . . . . . . . . . . . . . . . . . . . 10
8.2. Expressions . . . . . . . . . . . . . . . . . . . . . . . 11
8.2.1. Expression Operators . . . . . . . . . . . . . . . . 12
8.2.2. Numeric Expressions . . . . . . . . . . . . . . . . . 12
8.2.3. Set Expressions . . . . . . . . . . . . . . . . . . . 14
8.3. Measurement Extensions . . . . . . . . . . . . . . . . . 17
8.3.1. The tee.advisory-ids Measurement Extension . . . . . 17
8.3.2. The tee.attributes Measurement Extension . . . . . . 18
8.3.3. The tee.cryptokeys Measurement Extension . . . . . . 19
8.3.4. The tee.tcbdate Measurement Extension . . . . . . . . 19
8.3.5. The tee.mrtee and tee.mrsigner Measurement
Extension . . . . . . . . . . . . . . . . . . . . . . 20
8.3.6. The tee.instance-id Measurement Extension . . . . . . 20
8.3.7. The tee.platform-instance-id Measurement Extension . 21
8.3.8. The tee.isvprodid Measurement Extension . . . . . . . 21
8.3.9. The tee.miscselect Measurement Extension . . . . . . 22
8.3.10. The tee.model Measurement Extension . . . . . . . . . 22
8.3.11. The tee.pceid Measurement Extension . . . . . . . . . 23
8.3.12. The tee.isvsvn Measurement Extension . . . . . . . . 23
8.3.13. The tee.tcb-comp-svn Measurement Extension . . . . . 24
8.3.14. The tee.tcb-eval-num Measurement Extension . . . . . 24
8.3.15. The tee.tcb-status Measurement Extension . . . . . . 25
8.3.16. The tee.vendor Measurement Extension . . . . . . . . 25
9. Appraisal Algorithm . . . . . . . . . . . . . . . . . . . . . 26
9.1. Complex Expressions . . . . . . . . . . . . . . . . . . . 26
9.2. Comparison Algorithm for Sets . . . . . . . . . . . . . . 26
9.2.1. Comparison Algorithm for Set of Strings . . . . . . . 27
9.2.2. Comparison Algorithm for Set of Digests . . . . . . . 27
10. Reporting Attestation Results . . . . . . . . . . . . . . . . 28
11. Security Considerations . . . . . . . . . . . . . . . . . . . 28
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . 29
13.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 32
Appendix B. Full Intel Profile CDDL . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
Beaney, et al. Expires 5 October 2025 [Page 3]
Internet-Draft Intel profile April 2025
1. Introduction
This profile describes extensions and restrictions placed on
Reference Values, Endorsements, and Evidence that support attestation
capabilities of Intel products containing Intel(R) SGX(TM) or
Intel(R) TDX(TM) technology, or Intel(R) products that contain DICE
[DICE.engine] root of trust, DICE layers [DICE.layer], or modules
that implement SPDM [DMTF.SPDM].
The CoRIM specifications [DICE.CoRIM] and [I-D.ietf-rats-corim]
define a baseline schema for Reference Values and Endorsements that
form the foundation for the extensions defined in this profile.
[I-D.ietf-rats-corim] contains a foundational representation for
Attester actual state that Evidence, as specified by [DICE.Attest],
[TCG.CE], and [DMTF.SPDM], Reference Values, and Endorsements can map
to that helps ensure compatibility with a broad spectrum of Verifier
implementations. The Reference Values extensions in this profile
describe reference state that can be expressed as set membership or
value ranges. This profile defines extensions to CoRIM that support
appraisal matching that is based on set membership, masked values,
and numeric ranges.
The baseline CoRIM, as defined by [DICE.CoRIM] is a subset of the
Intel profile. Intel products that implement exclusively to the
baseline CoRIM may not rely upon this profile. The Intel profile
extensions may be generally useful. Implementations based on the
Intel profile does not necessarily imply an implementation is an
Intel product.
This profile extends CoMID measurement-values-map, as defined by
[DICE.CoRIM] (see also [I-D.ietf-rats-corim]), with measurement types
that are unique to Intel products. Some measurement types are
specific to Reference Values where multiple reference states may be
included in reference manifests. Intel profile extensions use a CBOR
tagged value that defines a comparison operator and operands that
instruct Verifiers regarding subset, range, and masked values
matching semantics. For example, a numeric operator 'greater-than'
instructs the Verifier to match a numeric Evidence value if it is
greater than a numeric range operand.
This profile follows the Verifier behavior defined by [DICE.CoRIM]
and extends Verifier behavior to include operator-operand matching.
If no operator is specified by Reference Values statements, the
Verifier defaults to baseline [DICE.CoRIM] matching semantics. If
Evidence matches Reference Values and Endorsements apply, Endorsed
Values may be added to the accetped claims set. When all Evidence
and Endorsements are processed, the Verifier's set of accepted claims
is available for Attestation Results computations. This profile
Beaney, et al. Expires 5 October 2025 [Page 4]
Internet-Draft Intel profile April 2025
doesn't define Attestation Results. Rather, an Attestation Results
profile, such as [I-D.kdyxy-rats-tdx-eat-profile] may be referenced
instead.
This profile is compatible with multiple Evidence formats, as defined
by [DICE.Attest], [TCG.CE], and [DMTF.SPDM]. It describes
considerations when mapping Evidence formats to CoRIM [DICE.CoRIM]
that a Verifier may use when performig appraisals.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The reader is assumed to be familiar with the terms defined in
Section 4 of [RFC9334] and [I-D.ietf-rats-endorsements].
3. Background
Complex platforms may contain a variety of hardware components,
several of which may contain a hardware root of trust. Each root of
trust may anchor one or more layers [DICE.layer] resulting in
multiple instances of attestation Evidence. Evidence may be
integrity protected by digital signatures, such as certificates
[DICE.Attest], tokens [RFC8392] or by a secure transport [DMTF.SPDM].
For example, a system bus may allow dynamically configured peripheral
devices that have attestation capabilities. Confidential computing
environments, such as SGX, may extend an initial boundary to include
a peripheral, or a peer enclave, that together forms a network of
trustworthy nodes that a remote attestation Verifier may need to
appraise. Multiple Evidence blocks may be combined into a composite
Evidence block [I-D.ietf-rats-msg-wrap] that is more easily conveyed.
Complex platforms may have one or more lead Attester endpoints that
communicate with a remote Verifier to convey composite Evidence. The
composition of the complex platform is partially represented in the
composite Evidence.
Beaney, et al. Expires 5 October 2025 [Page 5]
Internet-Draft Intel profile April 2025
However, composite Evidence may not fully describe platform
composition. A complex platform may consist of multiple subsystems,
such as network adapters, storage controllers, memory controllers,
special purpose processors, etc. The various sub-subsystem
components vendors may create hardware bills of material (HBOM) that
describe sub-system composition. A complex platform vendor may
assemble various sub-system components whose composition is described
by a platform HBOM. Although CoRIM may be used to create HBOMs, use
of this profile for HBOM creation is unanticipated.
Nevertheless, a complex system may contain multiple identical
instances of sub-sytem components that produce identical Evidence
blocks. Additionally, dynamic insertion or removal of a component
may result in composite Evidence blocks that reflect this dynamism.
4. Profile Identifier
This profile applies to Reference Values from a CoRIM manifest that a
Verifier uses to process Evidence.
Profile identifier structures are defined by CoRIM
[I-D.ietf-rats-corim], EAT [I-D.ietf-rats-eat] and Concise Evidence
[TCG.CE].
4.1. Intel Profile
The profile identifier for the Intel Profile is the OID:
{joint-iso-itu-t(2) country(16) us(840) organization(1) intel(113741)
(1) intel-comid(16) profile(1)}
2.16.840.1.113741.1.16.1
4.2. Profile Specific Media and Content Types
This profile uses the following media types:
* "application/eat+cwt"
* "application/eat+cwt; eat_profile=2.16.840.1.113741.1.16.1"
* "application/rim+cbor" (TBA)
* "application/rim+cbor" (TBA); profile=2.16.840.1.113741.1.16.1"
This profile uses the following content formats:
Beaney, et al. Expires 5 October 2025 [Page 6]
Internet-Draft Intel profile April 2025
+=======================================+========+=============+
| Content Type | C-F ID | TN Function |
+=======================================+========+=============+
| "application/eat+cwt" | 263 | 1668547081 |
+---------------------------------------+--------+-------------+
| "application/eat+cwt; | 10005 | 1668556861 |
| eat_profile=2.16.840.1.113741.1.16.1" | | |
+---------------------------------------+--------+-------------+
| "application/toc+cbor" | 10570 | 1668557428 |
+---------------------------------------+--------+-------------+
| "application/ce+cbor" | 10571 | 1668557429 |
+---------------------------------------+--------+-------------+
Table 1
This profile uses the following top level CBOR tags (not already
listed):
* 501, 570, 571
5. Attester Anatomy
Attesters implement DICE layering using an initial Attesting
Environment, also called a Root of Trust (RoT), that collection
claims about one or more Target Environments. A Target Environment
may become an Attesting Environment for a subsequent Target
Environment, and so forth. There may be more than one RoT in the
same Attester.
Attesting Environments generate Evidence by signing collected claims
using an Attestation Key. Environments may have other keys besides
attestation keys. Keys can be regarded as claims that are collected
and reported as Evidence. Keys can also be regarded as Target
Environments that have measurements that are specific to the key.
Confidential computing environments are Target Environments that can
dynamically request Evidence from an Attesting Environment agent.
Such Evidence may also be referred to as a 'Quote'.
Each DICE layer may produce signed Evidence. Evidence formats
include both signature and measurements formats. Signature formats
may include a mix of X.509 certificates and EAT CWTs. Evidence
measurements formats may include a mix of ASN.1 and CBOR, where ASN.1
uses DiceTcbInfo and related varients and CBOR uses concise evidence,
and CMW. Multiple Evidence blocks may be bundled using CMW
collections.
Beaney, et al. Expires 5 October 2025 [Page 7]
Internet-Draft Intel profile April 2025
Target Environments (other than cryptographic keys) are primarily
identified using OIDs from Intel's OID arc (2.16.840.1.113741). Keys
are identified using key identifiers, public key, or certificate
digests as defined by $crypto-key-type-choice [I-D.ietf-rats-corim].
6. Evidence Profile
Evidence may be integrity protected in various ways including:
certificates [RFC5280], SPDM transcript [DMTF.SPDM], and CBOR web
token (CWT) [RFC8392]. Evidence contained in a certificate may be
encoded using DiceTcbInfo and DiceTcbInfoSeq [DICE.Attest]. Evidence
contained in an SPDM payload may be encoded using the SPDM
Measurement Block [DMTF.SPDM]. Evidence may be formatted as concise-
evidence [TCG.CE] and included in an alias certificate or an SPDM
Measurement Manifest.
The DiceTcbInfo and SPDM Evidence formats can be translated to CoMID.
The concise evidence format is native to CoMID. This profile
documents evidence mapping from DiceTcbInfo and SPDM Measurement
Block to CoMID, as defined by [DICE.CoRIM].
The CoMID extensions defined by this profile Section 8.3 are applied
to concise-evidence so that Verifiers that support this profile can
consistently apply a common schema across Evidence, Reference Values,
and Endorsements.
6.1. Evidence Hierarchy
Evidence hierarchy refers to DICE layering where the platform
bootstrap components double as Attesting Environments that collect
measurements of the other bootstrap components (as Target
Environments) until the quoting agent (e.g., SGX Quoting Enclave
(QE), TDX Quoting TD (QTD)) is initialized. Tenant trusted execution
environment (TEE) components can be dynamically loaded then request
Evidence from its quoting agent. Quoting agents locally verify then
sign measurments using the QTD / QE attestation key. A hierarchy of
Evidence consisting of all the Evidence from a RoT to the tenant
environment describes the Attester.
A complex device may have multiple roots of trust, such as
[DICE.engine], each contributing an evidence hierarchy that results
in several Evidence "chains", that together, constitute a complete
Evidence hierarchy for the Attester device.
The Evidence hierarchy should form a spanning tree that contains all
Attester Evidence. All Attesting Environments within the device
produce the spanning tree. CoRIM manifests contain Reference Values
for the spanning tree so that Verifiers do not assume the spanning
Beaney, et al. Expires 5 October 2025 [Page 8]
Internet-Draft Intel profile April 2025
tree is defined by Evidence. Note that a failure or comporomise
within the Attester device could result in a portion of the spanning
tree being omitted.
Evidence examples:
* A DICE certificate chain with a DiceTcbInfo extension, a
DiceTcbInfoSeq extension, and a ConceptualMessageWrapper (CMW)
[I-D.ietf-rats-msg-wrap] extension containing a CBOR-encoded
tagged-concise-evidence.
* An SPDM alias intermediate certification chain containing a CMW
extension, and an SPDM measurement manifest containing tagged-
concise-evidence.
6.2. Concise Evidence
Concise evidence is a CDDL representation of Evidence [TCG.CE] that
uses expressions from CoMID, which are a subset of CoRIM. See
[DICE.CoRIM] and [I-D.ietf-rats-corim]. Evidence describes the
actual state of the Attester. tagged-concise-evidence uses a CBOR tag
(571) to identify concise-evidence [TCG.CE]. This profile uses
concise-evicence in conceptual message wrappers
[I-D.ietf-rats-msg-wrap] and EAT tokens [I-D.ietf-rats-eat] to encode
Evidence. This profile extends concise-evidence by extending
measurement-values-map.
7. Reference Values and Endorsements Profile
The CoRIM specifications [DICE.CoRIM] and [I-D.ietf-rats-corim]
define a baseline schema for Reference Values and Endorsements in
this profile. The profile defines extensions to CoRIM for
measurement types that are not representable by CoRIM or are more
conveniently represented. This profile doesn't require use of
extensions when base capabilities will suffice.
7.1. Concise Module ID Tag (CoMID)
This profile uses concise-mid-tag in conceptual message wrappers
[I-D.ietf-rats-msg-wrap] and CoRIMs. This profile extends concise-
mid-tag by extending measurement-values-map. Several extensions
define two forms, one for representing actual state which is used for
Endorsements and Evidence. The other form is used to represent
reference state which is used for Reference Values.
Beaney, et al. Expires 5 October 2025 [Page 9]
Internet-Draft Intel profile April 2025
7.2. Raw Value Measurements
Raw value measurements encode vendor-defined values opaquely.
However, the mkey value can add vendor-specific semantics when used
with raw-value and name measurement types. Additionally, specific
environment-map values can supply vendor-specific semantics to raw-
value and name measurement types.
Environments that project vendor-specific semantics are as follows:
+==========================================+============+===========+
| Envoronment Identifier | Value | Semantics |
+==========================================+============+===========+
| class-id:OID=2.16.840.1.113741.1.5.3.6.8 | 560(bytes) | device |
| | | type |
+------------------------------------------+------------+-----------+
Table 2
8. CoRIM Extensions
The Intel Profile extends measurement-values-map which is used by
Evidence, Reference Values, and Endorsed Values by defining code
points from the negative integer range.
Reference Values extensions define types that can have multiple
Reference Values that "match" a singleton Evidence value called "non-
exact match" matching. Reference state expressions define non-exact-
match matching semantics in terms of numeric ranges, time, sets, and
masks.
8.1. Data Types
8.1.1. Masked Values
Masked values are a string of bytes (e.g., bstr) that may have a
companion mask value. The mask indicates which bits in the value are
ignored when doing bit-wise equivalency comparisons. Verifier
matching applies the equivalency test, allowing dissimilar Evidence
and Reference values to be considered equivalent even if the two
values (Evidence and Reference) are dissimilar. Evidence typically
does not supply a mask. A Reference Value may omit the mask if bit-
wise equivalency is desired.
The $masked-value-type type choice can be either ~tagged-bytes or
$raw-value-type-choice. Evidence might be encoded as ~tagged-bytes
or tagged-bytes which omits a mask value, while Reference Values of
type tagged-masked-raw-value includes the mask value.
Beaney, et al. Expires 5 October 2025 [Page 10]
Internet-Draft Intel profile April 2025
The Verifier MUST ensure the lengths of values and mask are
equivalent. If the mask is shorter than the longest value, the mask
is appended with zeros (0) until it is the same length as the longest
value, either Evidence or Reference Value. If the mask is longer
than the longest value, the mask is truncated to the length of the
longest value. All values are evaluated from left to right (big-
endian) applying bit-wise comparisons.
The masked value data types are as follows:
$masked-value-type /= ~tagged-bytes
$masked-value-type /= $raw-value-type-choice
8.2. Expressions
Expressions are used to specify richer Reference Values measurements
that expect non-exact matching semantics. The Reference Value
expression instructs the Verifier regarding matching parameters, such
as greater-than or less-than, ranges, sets, etc. Typically, the
Evidence value is one operand of an expression and the Reference
Value contains the operator and additional operands.
The operator and remaining operands are contained in an array.
Expression arrays have an operator followed by zero or more operands.
The operator definition identifies the additional operands and their
data types. A Verifier forms an expression using Evidence as the
first operand, obtains the operator from the first entry in the
expression array, and any remaining array entries are operands.
This document describes operations using _infix_ notation where the
first operand, _operand_1_, is obtained from Evidence, followed by
the operator, followed by any remaining operands: _operand_2_,
_operand_3_, etc...
For example:
* From Evidence: operand_1, from Reference Values: [ operator,
operand_2, operand_3, ... ].
Expression records are CBOR tagged to indicate the following CBOR is
to be evaluated as an expression. Expression statements found in
Reference Values informs the Verifier that Evidence is needed to
complete the expression equation. Appraisal processing MUST evaluate
the expression.
This profile anticipates use of the CBOR tag #6.600XX to identify
expression arrays. See Section 12.
Beaney, et al. Expires 5 October 2025 [Page 11]
Internet-Draft Intel profile April 2025
For example:
* #6.600XX([ operator, operand_2, operand_3, ... ]).
8.2.1. Expression Operators
There are two classes of operators as follows:
1. *Numeric*: The numeric operand can be an integer, unsigned
integer, or floading point value.
2. *Set*: The set operand can be an set (array) of any primitive
value or a set of arrays containing any primitive value. The
position of the items in a set is unordered, while the position
of items in an array within a set is ordered.
8.2.1.1. Equivalence Operator
By default, _exact_ match rules are assumed. Consequently, no
operator artifact is needed when Evidence values are identical to
Reference Values.
8.2.2. Numeric Expressions
Numeric operators apply to values that are integers, unsigned
integers or floating point numbers. There are four numeric
operators:
1. *greater-than* (gt),
2. *greater-than-or-equal* (ge),
3. *less-than* (lt),
4. *less-than-or-equal* (le).
The equals operator is not defined because an exact match rule is the
default rule when an Evidence value is identical to a Reference
Value.
The numeric operator data type definitions are as follows:
Beaney, et al. Expires 5 October 2025 [Page 12]
Internet-Draft Intel profile April 2025
numeric-type = integer / unsigned / float
numeric-operators /= op.gt
numeric-operators /= op.ge
numeric-operators /= op.lt
numeric-operators /= op.le
numeric-expression = [ numeric-operators, numeric-type ]
tagged-numeric-expression = #6.60010(numeric-expression)
A numeric expression is an array containing a numeric operator and a
numeric operand. The operand contains a numeric Reference Value that
is matched with a numeric Evidence value.
Evidence and Reference Values MUST be the same numeric type. For
example, if a Reference Value numeric type is integer, then the
Evidence numeric value must also be integer.
This profile defines four macro numeric expressions, one for each
numeric operator:
* tagged-numeric-gt,
* tagged-numeric-ge,
* tagged-numeric-lt,
* tagged-numeric-le.
In each case, the numeric operator is used to evaluate a Reference
Value operand against an Evidence value operand that is obtained from
Evidence.
If the expression is read using _infix_ notation, the first operand
is Evidence, followed by the operator, followed by the Reference
Value operand.
Example:
* <evidence_numeric> <le> <reference_numeric>
The numeric expression definitions are as follows:
Beaney, et al. Expires 5 October 2025 [Page 13]
Internet-Draft Intel profile April 2025
tagged-numeric-gt = #6.60010( [
op.gt .within numeric-operators,
reference-value: numeric-type ] )
tagged-numeric-ge = #6.60010( [
op.ge .within numeric-operators,
reference-value: numeric-type ] )
tagged-numeric-lt = #6.60010( [
op.lt .within numeric-operators,
reference-value: numeric-type ] )
tagged-numeric-le = #6.60010( [
op.le .within numeric-operators,
reference-value: numeric-type ] )
8.2.3. Set Expressions
Set operators allow Reference Values, that are expressed as a set, to
be compared with Evidence that is expressed as either a primitive
value or a set.
Set expression statements have two forms:
1. A binary relation between a primitive object 'O' and a set 'S',
and
2. A binary relation between two sets, an Evidence set 'S1' and a
Reference Values set 'S2'.
The first form, relation between an object and a set, has two
operators:
* *member* and
* *not-member*.
The Evidence object 'O' is evaluated with the Reference Values set
'S'.
The op.member and op.not-member operators expect a Reverence Value
set as _operand_2_ and a primitive Evidence value as _operand_1_.
Evaluation tests whether _operand_1_ is a member of the set
_operand_2_.
Example:
* <evidence-value> <set-operator> <reference-set>
The set data type definitions are defined as follows:
Beaney, et al. Expires 5 October 2025 [Page 14]
Internet-Draft Intel profile April 2025
member = 6
not-member = 7
set-operators /= op.mem
set-operators /= op.nmem
set-digest-type /= [ * digest ]
set-digest-expression = [ set-operators, set-digest-type ]
tagged-set-digest-expression = #6.60020( set-digest-expression )
set-tstr-type /= [ * tstr ]
set-tstr-expression = [ set-operators, set-tstr-type ]
tagged-set-tstr-expression = #6.60021( set-tstr-expression )
A set expression array contins a set operator followed by a set of
Reference Values. The set is defined by set-type.
The set expression type definitions are as follows:
tagged-exp-digest-member = #6.60020([
op.mem .within set-operators, set-digest-type ])
tagged-exp-digest-not-member = #6.60020([
op.nmem .within set-operators, set-digest-type ])
tagged-exp-tstr-member = #6.60021([
op.mem .within set-operators, set-tstr-type ])
tagged-exp-tstr-not-member = #6.60021([
op.nmem .within set-operators, set-tstr-type ])
Examples:
* <evidence_object> <member> <reference_set>
* <evidence_object> <not-member> <reference_set>
The Evidence object MUST NOT be nil.
The Reference Values set may be the empty set.
The second form, a relation between two sets, has three operators:
* *subset*,
* *superset*,
* *disjoint*.
Beaney, et al. Expires 5 October 2025 [Page 15]
Internet-Draft Intel profile April 2025
The fist set, S1 is Evidence and set, S2 is the Reference Values set.
The subset, superset, and disjoint operators test whether an Evidence
set value satisfies a set operation, given a Reverence Value set.
Examples:
* <evidence_set> <subset> <reference_set>
* <evidence_set> <superset> <reference_set>
* <evidence_set> <disjoint> <reference_set>
The Reference Values and Evidence sets may be the empty set.
The set of sets data type definitions are as follows:
; The CDDL here needs to be fixed, Ned to work on this
subset = 8
superset = 9
disjoint = 10
set-of-set-type = [ * [ + any ]]
set-of-set-operator = subset / superset / disjoint
set-of-set-expression = [ set-of-set-operator, set-of-set-type ]
tagged-set-of-set-expression = #6.60020(set-of-set-expression)
For subset, every member in the Evidence set 'S1', MUST map to a
member in the Reference Values set 'S2'. The Evidence set, 'S1', MAY
be a proper subset of 'S2'. For example, if every member in set 'S1'
maps to every member in set 'S2' then matching is successful. A
successful result produces the set 'S1'.
For superset, every member in the Reference Values set 'S2', MUST map
to a member in the Evidence set 'S1'. A successful result produces
the set 'S1'.
For disjoint, every member in the Evidence set 'S1' MUST NOT map to
any member in the Reference Values set 'S2'. A successful result
produces the empty set.
The set of sets expression definitions are as follows:
Beaney, et al. Expires 5 October 2025 [Page 16]
Internet-Draft Intel profile April 2025
tagged-exp-subset = #6.60010([
subset .within set-of-set-operator, set-of-set-type ])
tagged-exp-superset = #6.60010([
superset .within set-of-set-operator, set-of-set-type ])
tagged-exp-disjoint = #6.60010([
disjoint .within set-of-set-operator, set-of-set-type ])
8.3. Measurement Extensions
This profile extends the CoMID measurement-values-map with additional
code point definitions, that accommodate Intel SGX and similar
architectures. Measurement extensions don't change Verifier
behavior. An extension enables the Verifier to validate the profile
compliance of the input evidence and reference values, as it defines
the acceptable data types in evidence and the expression operator
that is explicitly supplied with the Reference Values, see
Section 8.2.1.
In cases where Evidence does not exactly match Reference Values, the
operator definition determines the expected data types of the
operands. Expected Verifier behavior is defined in Section 9
The measurement extensions that follow are assumed to be appraised
according to the appriasal steps described in Section 8.1 of
[I-D.ietf-rats-corim].
8.3.1. The tee.advisory-ids Measurement Extension
The tee.advisory-ids extension enables Attesters to report known
security advisories and for Reference Values Providers (RVP) to
assert updated security advisories. It can also be used by Endorsers
to assert security advisory information through conditional
endorsement.
The $tee-advisory-ids-type is used to specify a set of security
advisories, where each identifier is represented using a string.
Evidence may report a set of advisories the Attester believes are
relevant. The set of advisories are constrained by the set-tstr-type
structure.
As a Reference Value expression, an empty set can be used to signify
that no outstanding advisories are expected. If the Evidence also
contains the empty set then the Reference corroborates the Evidence.
Beaney, et al. Expires 5 October 2025 [Page 17]
Internet-Draft Intel profile April 2025
The $tee-advisory-ids-type is a list of strings, each identifying a
single security advisory. When used with Evidence the set-tstr-type
type is used. When used with Reference Values or Endorsements the
set-tstr-type, tagged-exp-tstr-member, or tagged-exp-tstr-not-member
types can be used.
$$measurement-values-map-extension //= (
&(tee.advisory-ids: -89) => $tee-advisory-ids-type
)
$tee-advisory-ids-type /= set-tstr-type
$tee-advisory-ids-type /= tagged-exp-tstr-not-member
$tee-advisory-ids-type /= tagged-exp-tstr-member
8.3.1.1. The tee-advisory-ids-type Comparison Algorithm
The comparison algorithm for tee-advisory-ids-type is used when
Endorsement or Reference Values triples conditions are matched with
an Environment Claims Tuple (ECT) in the Verifier's Accepted Claims
Set (ACS). The triple condition containing a tee-advisory-ids-type
Claim matches an ACS ECT according to the comparison algorithm for
set of strings as defined in Section 9.2.
8.3.2. The tee.attributes Measurement Extension
The tee.attributes extension enables the Attester to report TEE
attributes and an RVP to assert a reference TEE attributes and mask.
The $tee-attributes-type is used to specify TEE attributes in 8 or 16
byte words. If Evidence uses an 8 byte mask, then the Reference
Values expression also uses an 8 byte value and mask.
The $tee-attributes-type is a singleton value omitting the mask value
when used as Endorsement or Evidence and a tuple containing the
reference and mask when used as a Reference Value.
$$measurement-values-map-extension //= (
&(tee.attributes: -82) => $tee-attributes-type
)
$tee-attributes-type /= $masked-value-type
Alternatively, the TEE attributes may be encoded using mkey where
mkey contains the non-negative tee.attributes and mval.raw-value
contains the $tee-attributes-type.mask-type value.
Beaney, et al. Expires 5 October 2025 [Page 18]
Internet-Draft Intel profile April 2025
8.3.3. The tee.cryptokeys Measurement Extension
The tee.cryptokeys extension identifies cryptographic keys associated
with a Target Environment. If multiple $crypto-key-type-choice
measurements are supplied, array position disambiguates each entry.
Appraisal compares values indexed by array position.
$$measurement-values-map-extension //= (
&(tee.cryptokeys: -91) => [ + $tee-cryptokey-type ]
)
$tee-cryptokey-type /= $crypto-key-type-choice
Alternatively, the TEE cryptokeys may be encoded using mkey where
mkey contains the non-negative tee.cryptokeys and mval.cryptokeys
contains the $tee-cryptokey-type value.
8.3.4. The tee.tcbdate Measurement Extension
The tee.tcbdate (code point -72) extension is used by Endorsers to
assert validity of a TEE component. For example, a conditional
endorsement might locate a component based on a few expected Claims,
then augment them with a tee.tcbdate Claim.
The $tee-date-type can be expressed in several ways:
* ISO 8601 strings of the form YYYY-MM-DDTHH:MM:SSZ.
* POSIX time which is the number of seconds since January 1, 1970
(midnight UTC).
* RFC9581 etime [RFC9581].
$$measurement-values-map-extension //= (
&(tee.tcbdate: -72) => $tee-date-type
)
$tee-date-type /= ~tdate
$tee-date-type /= tdate
$tee-date-type /= time
$tee-date-type /= etime ; RFC9581
~tdate strings must be converted to a numeric value (i.e.,~time)
before operations involving time are applied.
Alternatively, tee.tcbdate may be encoded using mkey where mkey
contains the non-negative code point value and where mval.name
contains the string representation $tee-date-type without the CBOR
tag (i.e., ~tdate - see Section 3.7 [RFC8610]).
Beaney, et al. Expires 5 October 2025 [Page 19]
Internet-Draft Intel profile April 2025
8.3.5. The tee.mrtee and tee.mrsigner Measurement Extension
The tee.mrtee extension enables an Attester to report digests for the
SGX enclave or TDX TD (e.g., MRENCLAVE, MRTD). The tee.mrsigner
extension enables an Attester to report the signer of the TEE digest
(e.g., MRSIGNER).
The $tee-digest-type has multiple type structures involving digest
values. A singleton digest has a hash algorithm identifier and the
digest value. When used as Evidence, either a signleton digest or a
set of digests can be reported. When used as Reference Values or
Endorsements, a set of digests can be asserted signifying equivalence
matching. Alternatively, matching may be expressed as set membership
or set difference expressions.
$$measurement-values-map-extension //= (
&(tee.mrtee: -83) => $tee-digest-type
)
$$measurement-values-map-extension //= (
&(tee.mrsigner: -84) => $tee-digest-type
)
$tee-digest-type /= digest ; see corim
$tee-digest-type /= digests-type ; see corim
$tee-digest-type /= set-digest-type
$tee-digest-type /= tagged-exp-digest-member
$tee-digest-type /= tagged-exp-digest-not-member
Alternatively, the TEE digests may be encoded using mkey where mkey
contains the non-negative tee.mrtee or tee.mrsigner and mval.digests
contains a digests-type value.
8.3.5.1. The tee-digest-type Comparison Algorithm
The comparison algorithm for tee-digest-type is used when the
condition statement in an Endorsement or Reference Values triple is
matched with an Environment Claim Tuple (ECT) from the Verifier's
Accepted Claims Set (ACS). The comparison algorithm for set of
digests is defined in Section 9.2.
8.3.6. The tee.instance-id Measurement Extension
The tee.instance-id extension enables the Attester to report the TEE
(TD or enclave) instance identifier as an Evidence value and the RVP
to assert an exact-match Reference Value.
The $tee-instance-id-type is an unsigned integer or bstr.
Beaney, et al. Expires 5 October 2025 [Page 20]
Internet-Draft Intel profile April 2025
$$measurement-values-map-extension //= (
&(tee.instance-id: -77) => $tee-instance-id-type
)
$tee-instance-id-type /= uint
$tee-instance-id-type /= bstr
Alternatively, the TEE instance ID may be encoded using mkey where
mkey contains the non-negative tee.instance-id and mval.raw-value
contains the $tee-instance-id-type value. If the $tee-instance-id-
type is an unsigned integer, the integer values is converted to a
single byte bstr.
8.3.7. The tee.platform-instance-id Measurement Extension
Platform Instance ID is a globally unique identifier generated by the
platform during Platform Establishment. This value remains
consistent across trusted computing base (TCB) recoveries, but is
regenerated during Platform Establishment due to desire to reset keys
or to add and remove hardware. See (Section 3.7 [INTEL.DCAP]).
The tee.platform-instance-id extension enables the Attester to report
the platform instance identifier as an Evidence value and the RVP to
assert an exact-match Reference Value.
The $tee-platform-instance-id-type is a bstr.
$$measurement-values-map-extension //= (
&(tee.platform-instance-id: -101) => $tee-platform-instance-id-type
)
$tee-platform-instance-id-type /= bstr
Alternatively, the platform instance ID may be encoded using mkey
where mkey contains the non-negative tee.platform-instance-id and
mval.raw-value contains the $tee-platform-instance-id-type value.
8.3.8. The tee.isvprodid Measurement Extension
The tee.isvprodid extension enables the Attester to report the ISV
product identifier Evidence value and the RVP to assert an exact-
match Reference Value.
The $tee-isvprodid-type is an unsigned integer.
The $tee-isvprodid-type is an exact match measurement.
Beaney, et al. Expires 5 October 2025 [Page 21]
Internet-Draft Intel profile April 2025
$$measurement-values-map-extension //= (
&(tee.isvprodid: -85) => $tee-isvprodid-type
)
$tee-isvprodid-type /= uint
$tee-isvprodid-type /= bstr
Alternatively, the TEE product ID may be encoded using mkey where
mkey contains the non-negative tee.isvprodid and mval.raw-value
contains the $tee-isvprodid-type value.
8.3.9. The tee.miscselect Measurement Extension
The tee.miscselect extension enables the Attester to report the
(TBD:miscselect-description) Evidence value and the RVP to assert a
Reference Value and mask.
The $tee-miscselect-type is a 4 byte value and mask.
The $tee-miscselect-type is a singleton mask-type value when used as
Endorsement or Evidence and a tagged-masked-raw-value when used a
Reference Value.
$$measurement-values-map-extension //= (
&(tee.miscselect: -81) => $tee-miscselect-type
)
$tee-miscselect-type /= $masked-value-type
Alternatively, the TEE miscselect may be encoded using mkey where
mkey contains the non-negative tee.miscselect and mval.raw-value
contains the measurement value and mval.raw-value-mask` contains the
mask value.
8.3.10. The tee.model Measurement Extension
The tee.model extension enables the Attester to report the TEE model
string as Evidence and the RVP to assert an exact-match Reference
Value.
The $tee-model-type is a string.
The $tee-model-type is an exact match measurement.
$$measurement-values-map-extension //= (
&(tee.model: -71) => $tee-model-type
)
$tee-model-type /= tstr
Beaney, et al. Expires 5 October 2025 [Page 22]
Internet-Draft Intel profile April 2025
Alternatively, the TEE model may be encoded using mkey where mkey
contains the non-negative tee.model and mval.name contains the $tee-
model-type value.
8.3.11. The tee.pceid Measurement Extension
The tee.pceid extension enables the Attester to report the PCEID as
Evidence and the RVP to assert an exact-match Reference Value.
The $tee-pceid-type is a string.
The $tee-pceid-type is an exact match measurement.
$$measurement-values-map-extension //= (
&(tee.pceid: -80) => $tee-pceid-type
)
$tee-pceid-type /= tstr
Alternatively, the PCEID may be encoded using mkey where mkey
contains the non-negative tee.pceid and mval.name contains the $tee-
pceid-type value.
8.3.12. The tee.isvsvn Measurement Extension
The tee.isvsvn extension enables the Attester to report the SVN for
the independent software vendor supplied component as Evidence and
the RVP to assert a Reference Value that is greater-than-or-equal to
the reported SVN.
The $tee-svn-type is either an unsigned integer when reported as
Evidence, or a tagged numeric expression that contains an SVN and a
numeric greater-than-or-equal operator. The Verifier ensures the
Evidence value is greater-that-or-equal to the Reference Value.
The $tee-svn-type is a svn-type when used as Endorsement or Evidence
and a tagged-numeric-expression when used as a Reference Value.
$$measurement-values-map-extension //= (
&(tee.isvsvn: -73) => $tee-svn-type
)
$tee-svn-type /= svn-type .within numeric-type
$tee-svn-type /= tagged-numeric-ge
Alternatively, the TEE isvsvn may be encoded using mkey where mkey
contains the non-negative tee.isvsvn and mval.svn contains the svn
value as svn-type.
Beaney, et al. Expires 5 October 2025 [Page 23]
Internet-Draft Intel profile April 2025
8.3.13. The tee.tcb-comp-svn Measurement Extension
The tee.tcb-comp-svn extension enables the Attester to report an
array of SVN values for the TCB when asserted as Evidence and an
array of tagged-numeric-ge entries when asserted as a Reference
Value.
The $tee-tcb-comp-svn-type is an array containing 16 SVN values when
reported as Evidence and an array of 16 expression records each
containing the numeric ge operator and a reference SVN value. The
Verifier evaluates each SVN in the Evidence array with the
corresponding reference expression, by array position. If all
Evidence values match their respective expressions, evaluation is
successful. The array of SVN Evidence is accepted.
$$measurement-values-map-extension //= (
&(tee.tcb-comp-svn: -125) => $tee-tcb-comp-svn-type
)
$tee-tcb-comp-svn-type /=
[ 16*16 svn-type .within numeric-type ]
$tee-tcb-comp-svn-type /=
[ 16*16 tagged-numeric-ge ]
8.3.14. The tee.tcb-eval-num Measurement Extension
The tee.tcb-eval-num extension enables the Attester to report a TCB
evaluation number as Evidence and the RVP to assert a Reference Value
expression that compares the tcb-eval-num Evidence with the Reference
Value using the greater-than-or-equal operator.
The $tee-tcb-eval-num-type is an unsigned integer when reported as
Evidence and a tagged numeric expression when asserted as Reference
Values.
$$measurement-values-map-extension //= (
&(tee-tcb-eval-num: -86) => $tee-tcb-eval-num-type
)
$tee-tcb-eval-num-type /= uint .within numeric-type
$tee-tcb-eval-num-type /= tagged-numeric-ge
Alternatively, the TEE tcb-eval-num Evidence may be encoded using
mkey where mkey contains the non-negative tee.tcb-eval-num and
mval.raw-value contains the tcb-eval-num encoded as 4-byte bstr
value.
Beaney, et al. Expires 5 October 2025 [Page 24]
Internet-Draft Intel profile April 2025
8.3.15. The tee.tcb-status Measurement Extension
The tee.tcb-status extension enables Attesters to report the status
of the TEE trusted computing base (TCB) and for Reference Value
Providers (RVP) to assert expected TCB status. It can also be used
by Endorsers to assert TCB status through conditional endorsement.
The tee-tcbstatus-type is used to specify TCB status as a set of
status strings or as an expression with a set membership operator.
The $tee-tcbstatus-type is a status array containing strings
describing TCB status values. When describing Evidence the set-tstr-
type type is used. When describing Reference Values or Endorsements
the set-tstr-type, tagged-exp-tstr-member, or tagged-exp-tstr-not-
member types can be used.
$$measurement-values-map-extension //= (
&(tee.tcbstatus: -88) => $tee-tcbstatus-type
)
$tee-tcbstatus-type /= set-tstr-type
$tee-tcbstatus-type /= tagged-exp-tstr-member
$tee-tcbstatus-type /= tagged-exp-tstr-not-member
8.3.15.1. The tee-tcbstatus-type Comparison Algorithm
The comparison algorithm for tee-tcbstatus-type is used when
Endorsement or Reference Values triples conditions are matched with
an Environment Claims Tuple (ECT) in the Verifier's Accepted Claims
Set (ACS). The triple condition containing a tee-tcbstatuss-type
Claim matches an ACS ECT according to the comparison algorithm for
set of strings as defined in Section 9.2.
8.3.16. The tee.vendor Measurement Extension
The tee.vendor extension enables the Attester to report the TEE
vendor name as Evidence and for the RVP to assert the TEE vendor
name.
The $tee-vendor-type is a string containing the vendor name as a
string. The vendor string in Evidence must exactly match the vendor
string in Reference Values.
The $tee-vendor-type is an exact match measurement.
$$measurement-values-map-extension //= (
&(tee.vendor: -70) => $tee-vendor-type
)
$tee-vendor-type /= tstr
Beaney, et al. Expires 5 October 2025 [Page 25]
Internet-Draft Intel profile April 2025
Alternatively, the TEE vendor may be encoded using mkey where mkey
contains the non-negative tee.vendor and mval.name contains the $tee-
vendor-type value.
9. Appraisal Algorithm
The Intel profile anticipates appraisal algorithms will be based on
the appraisal algorithm defined in [I-D.ietf-rats-corim]. This
profile extends the appraisal algorithm to recognize profile
extensions that form equations. An Evidence measurement forms one of
the operands: (evidence operand). A Reference Value forms the
operator and remaining operands:
* [expression operator, reference value operand, etc...]
For example, if a numeric Reference Value is 14, and the expressions
operator is gt the Reference Value might contain the Claim:
#6.60010([ 1, 14]). Given Evidence contains the value: 15. The in-
fix construction of the equation would be: 15 gt 14. The Verifier
evaluates whether 15 is greater-than 14.
9.1. Complex Expressions
Complex expressions can be used to assess whether the Target
Environment is in a particular state before certain Endorsement
claims can be asserted. For example, if an SGX enclave has an svn
value that is less than the prescribed minimum svn, the enclave
status may be considered "OutOfDate" or may have a known security
advisory. The CoMID conditional-endorsement-triples or conditional-
endorsement-series-triples describe complex Endorsement expressions.
This profile uses these triples with the reference measurement values
extensions described in Section 8.3.
9.2. Comparison Algorithm for Sets
The comparison algorithm for sets describes set equivalence, set
membership, and set difference (not membership). The Verifier's
Accepted Claims Set (ACS) contains a list of Environment Claims
Tuples (ECT)[I-D.ietf-rats-corim]. The condition ECTs are compared
to ACS ECTs based on this comparison algorithm.
The set comparison algorithm processes sets of strings and sets of
digests.
Beaney, et al. Expires 5 October 2025 [Page 26]
Internet-Draft Intel profile April 2025
9.2.1. Comparison Algorithm for Set of Strings
There are three string set representations: set-tstr-type, tagged-
exp-tstr-member, and tagged-exp-tstr-not-member.
* set-tstr-type - Every string in the condition set-tstr-type MUST
match a string in the ACS.ECT.element-map.element-claims.set-tstr-
type set. The string position in the array is not significant.
The ACS.ECT.element-map.element-claims.set-tstr-type set MUST be
equivalent to the condition set-tstr-type set (i.e., the two sets
have the same cardinality and the same set members).
* tagged-exp-tstr-member - The condition ECT set operator MUST equal
member and every string in the condition set-tstr-type MUST match
a string in the ACS.ECT.element-map.element-claims.set-tstr-type
set. The string position in the array is not significant. The
ACS.ECT.element-map.element-claims.set-tstr-type set MAY contain
strings not found in the condition set-tstr-type.
* tagged-exp-tstr-not-member - The condition ECT set operator MUST
equal not-member and every string in the condition set-tstr-type
MUST NOT match a string in the ACS.ECT.element-map.element-
claims.set-tstr-type set. The string position in the array is not
significant.
9.2.2. Comparison Algorithm for Set of Digests
There are five digest set representations: digest, digest-type, set-
digest-type, tagged-exp-digest-member, and tagged-exp-digest-not-
member.
* digest - The singleton digest in the condition MUST match at least
one digest in the ACS.ECT.element-map.element-claims.set-digest-
type set.
* digest-type and set-digest-type - Every digest in the condition
digest-type or set-digest-type MUST match a digest in the
ACS.ECT.element-map.element-claims.set-digest-type set. The
digest position in the array is not significant. The
ACS.ECT.element-map.element-claims.set-digest-type set MUST be
equivalent to the condition set-digest-type set (i.e., the two
sets have the same cardinality and the same set members).
Matching based on the empty set is permitted when the set-digest-
type is used.
* tagged-exp-digest-member - The condition ECT set operator MUST
equal member and every digest in the condition set-digest-type
MUST match a digest in the ACS.ECT.element-map.element-claims.set-
Beaney, et al. Expires 5 October 2025 [Page 27]
Internet-Draft Intel profile April 2025
digest-type set. The digest position in the array is not
significant. The ACS.ECT.element-map.element-claims.set-digest-
type set MAY contain digests not found in the condition set-
digest-type.
* tagged-exp-digest-not-member - The condition ECT set operator MUST
equal not-member and every digest in the condition set-digest-type
MUST NOT match a digest in the ACS.ECT.element-map.element-
claims.set-digest-type set. The digest position in the array is
not significant.
10. Reporting Attestation Results
Attestation verification can be performed by a pipeline consisting of
multiple stages where each input manifest demarks a stage. The final
stage prepares Attestation Results according to Relying Party
specifications. This profile does not define an attestation results
format. The Relying Party should specify suitable Attestation
Results formats such as [I-D.ietf-rats-ar4si] or
[I-D.kdyxy-rats-tdx-eat-profile].
The precise Attestation Results format used, if negotiated by
Verifier and Relying Party, should reference this profile to
acknowledge that the Relying Party and Verifier both support the
extensions defined in this document.
11. Security Considerations
The security of this profile depends on the security considerations
of the various normative references.
12. IANA Considerations
IANA is requested to allocate the following tags in the CBOR Tags
registry [IANA.cbor-tags], preferably with the CBOR tag value
requested.
Beaney, et al. Expires 5 October 2025 [Page 28]
Internet-Draft Intel profile April 2025
+=======+===========+=========================+===========+
| Tag | Data Item | Semantics | Reference |
+=======+===========+=========================+===========+
| 60010 | tag | Numeric Expressions, | RFCthis |
| | | see Section 8.2.2 | |
+-------+-----------+-------------------------+-----------+
| 60020 | tag | Set digest Expressions, | RFCthis |
| | | see Section 8.2.3 | |
+-------+-----------+-------------------------+-----------+
| 60021 | tag | Set tstr Expressions, | RFCthis |
| | | see Section 8.2.3 | |
+-------+-----------+-------------------------+-----------+
Table 3
13. References
13.1. Normative References
[DICE.Attest]
Trusted Computing Group (TCG), "DICE Attestation
Architecture", Version 1.1, Revision 18 , January 2024,
<https://trustedcomputinggroup.org/wp-content/uploads/
DICE-Attestation-Architecture-Version-1.1-Revision-
18_pub.pdf>.
[DICE.CoRIM]
Trusted Computing Group (TCG), "DICE Endorsement
Architecture for Devices", Version 1.0, Revision 0.38 ,
November 2022, <https://trustedcomputinggroup.org/wp-
content/uploads/TCG-Endorsement-Architecture-for-Devices-
V1-R38_pub.pdf>.
[DICE.layer]
Trusted Computing Group (TCG), "DICE Layering
Architecture", Version 1.0, Revision 0.19 , July 2020,
<https://trustedcomputinggroup.org/wp-content/uploads/
DICE-Layering-Architecture-r19_pub.pdf>.
[I-D.ietf-rats-corim]
Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and
W. Pan, "Concise Reference Integrity Manifest", Work in
Progress, Internet-Draft, draft-ietf-rats-corim-07, 3
March 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-rats-corim-07>.
Beaney, et al. Expires 5 October 2025 [Page 29]
Internet-Draft Intel profile April 2025
[I-D.ietf-rats-eat]
Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", Work in
Progress, Internet-Draft, draft-ietf-rats-eat-31, 6
September 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-eat-31>.
[I-D.ietf-rats-msg-wrap]
Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and
D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", Work
in Progress, Internet-Draft, draft-ietf-rats-msg-wrap-12,
28 February 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-msg-wrap-12>.
[IANA.cbor-tags]
IANA, "Concise Binary Object Representation (CBOR) Tags",
<https://www.iana.org/assignments/cbor-tags>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9581] Bormann, C., Gamari, B., and H. Birkholz, "Concise Binary
Object Representation (CBOR) Tags for Time, Duration, and
Period", RFC 9581, DOI 10.17487/RFC9581, August 2024,
<https://www.rfc-editor.org/rfc/rfc9581>.
[TCG.CE] Trusted Computing Group (TCG), "TCG DICE Concise Evidence
Binding for SPDM", Version 1.0, Revision 0.54 , January
2024, <https://trustedcomputinggroup.org/wp-
content/uploads/TCG-DICE-Concise-Evidence-Binding-for-
SPDM-Version-1.0-Revision-54_pub.pdf>.
13.2. Informative References
[DICE.engine]
Trusted Computing Group (TCG), "Requirements for a Device
Identifier Composition Engine", Family "2.0", Level 00
Revision 78 , March 2018,
<https://trustedcomputinggroup.org/wp-content/uploads/
Hardware-Requirements-for-Device-Identifier-Composition-
Engine-r78_For-Publication.pdf>.
Beaney, et al. Expires 5 October 2025 [Page 30]
Internet-Draft Intel profile April 2025
[DMTF.SPDM]
Distributed Managability Task Force (DMTF), "Security
Protocol and Data Mmodel (SPDM) Specification", Version
1.2.1 , May 2022,
<https://www.dmtf.org/sites/default/files/standards/
documents/DSP0274_1.2.1.pdf>.
[I-D.ietf-rats-ar4si]
Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V.
Scarlata, "Attestation Results for Secure Interactions",
Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-
08, 6 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
ar4si-08>.
[I-D.ietf-rats-endorsements]
Thaler, D., Birkholz, H., and T. Fossati, "RATS
Endorsements", Work in Progress, Internet-Draft, draft-
ietf-rats-endorsements-06, 3 March 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
endorsements-06>.
[I-D.kdyxy-rats-tdx-eat-profile]
Kostal, G., Dittakavi, S., Yeluri, R., Xia, H., and J. Yu,
"EAT profile for Intel(r) Trust Domain Extensions (TDX)
attestation result", Work in Progress, Internet-Draft,
draft-kdyxy-rats-tdx-eat-profile-02, 13 December 2024,
<https://datatracker.ietf.org/doc/html/draft-kdyxy-rats-
tdx-eat-profile-02>.
[INTEL.DCAP]
Intel Corporation, "Intel(R) Software Guard Extensions
(Intel(R) SGX) Data Center Attestation Primitives ECDSA
Quote Library API", August 2023, <https://download.01.org/
intel-sgx/latest/dcap-latest/linux/docs/
Intel_SGX_ECDSA_QuoteLibReference_DCAP_API.pdf>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.
Beaney, et al. Expires 5 October 2025 [Page 31]
Internet-Draft Intel profile April 2025
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
Appendix A. Acknowledgments
The authors wish to thank Shanwei Cen, Piotr Zmijewski, Francisco J.
Chinchilla and Dionna Amalie Glaze for their valuable contributions.
Appendix B. Full Intel Profile CDDL
tagged-numeric-gt = #6.60010( [
op.gt .within numeric-operators,
reference-value: numeric-type ] )
tagged-numeric-ge = #6.60010( [
op.ge .within numeric-operators,
reference-value: numeric-type ] )
tagged-numeric-lt = #6.60010( [
op.lt .within numeric-operators,
reference-value: numeric-type ] )
tagged-numeric-le = #6.60010( [
op.le .within numeric-operators,
reference-value: numeric-type ] )
numeric-type = integer / unsigned / float
numeric-operators /= op.gt
numeric-operators /= op.ge
numeric-operators /= op.lt
numeric-operators /= op.le
numeric-expression = [ numeric-operators, numeric-type ]
tagged-numeric-expression = #6.60010(numeric-expression)
Etime = #6.1001(etime-detailed)
etime-framework = {
uint => any ; at least one base time
* (nint/text) => any ; elective supplementary information
* uint => any ; critical supplementary information
}
etime-detailed = ({
Beaney, et al. Expires 5 October 2025 [Page 32]
Internet-Draft Intel profile April 2025
$$ETIME-BASETIME
ClockQuality-group
* $$ETIME-ELECTIVE
* $$ETIME-CRITICAL
* ((nint/text) .feature "etime-elective-extension") => any
* (uint .feature "etime-critical-extension") => any
}) .within etime-framework
$$ETIME-BASETIME //= (1: ~time)
$$ETIME-BASETIME //= (4: ~decfrac)
$$ETIME-BASETIME //= (5: ~bigfloat)
$$ETIME-ELECTIVE //= (-3: uint)
$$ETIME-ELECTIVE //= (-6: uint)
$$ETIME-ELECTIVE //= (-9: uint)
$$ETIME-ELECTIVE //= (-12: uint)
$$ETIME-ELECTIVE //= (-15: uint)
$$ETIME-ELECTIVE //= (-18: uint)
$$ETIME-ELECTIVE //= (-1 => $ETIME-TIMESCALE)
$$ETIME-ELECTIVE //= (-13 => $ETIME-TIMESCALE)
$$ETIME-CRITICAL //= (13 => $ETIME-TIMESCALE)
$ETIME-TIMESCALE /= &(etime-utc: 0)
$ETIME-TIMESCALE /= &(etime-tai: 1)
ClockQuality-group = (
? &(ClockClass: -2) => uint .size 1 ; PTP/RFC8575
? &(ClockAccuracy: -4) => uint .size 1 ; PTP/RFC8575
? &(OffsetScaledLogVariance: -5) => uint .size 2 ; PTP/RFC8575
? &(Uncertainty: -7) => ~time/~duration
? &(Guarantee: -8) => ~time/~duration
)
Duration = #6.1002(etime-detailed)
simple-Period = #6.1003([
start: ~Etime / null
end: ~Etime / null
? duration: ~Duration
])
Period = #6.1003([
(start: ~Etime,
((end: ~Etime) //
(end: null,
duration: ~Duration))) //
(start: null,
end: ~Etime,
duration: ~Duration)
])
Beaney, et al. Expires 5 October 2025 [Page 33]
Internet-Draft Intel profile April 2025
etime = #6.1001({* (int/tstr) => any})
duration = #6.1002({* (int/tstr) => any})
period = #6.1003([~etime/null, ~etime/null, ?~duration])
member = 6
not-member = 7
set-operators /= op.mem
set-operators /= op.nmem
set-digest-type /= [ * digest ]
set-digest-expression = [ set-operators, set-digest-type ]
tagged-set-digest-expression = #6.60020( set-digest-expression )
set-tstr-type /= [ * tstr ]
set-tstr-expression = [ set-operators, set-tstr-type ]
tagged-set-tstr-expression = #6.60021( set-tstr-expression )
tagged-exp-digest-member = #6.60020([
op.mem .within set-operators, set-digest-type ])
tagged-exp-digest-not-member = #6.60020([
op.nmem .within set-operators, set-digest-type ])
tagged-exp-tstr-member = #6.60021([
op.mem .within set-operators, set-tstr-type ])
tagged-exp-tstr-not-member = #6.60021([
op.nmem .within set-operators, set-tstr-type ])
subset = 8
superset = 9
disjoint = 10
set-of-set-type = [ * [ + any ]]
set-of-set-operator = subset / superset / disjoint
set-of-set-expression = [ set-of-set-operator, set-of-set-type ]
tagged-set-of-set-expression = #6.60020(set-of-set-expression)
tagged-exp-subset = #6.60010([
subset .within set-of-set-operator, set-of-set-type ])
tagged-exp-superset = #6.60010([
superset .within set-of-set-operator, set-of-set-type ])
tagged-exp-disjoint = #6.60010([
disjoint .within set-of-set-operator, set-of-set-type ])
$masked-value-type /= ~tagged-bytes
$masked-value-type /= $raw-value-type-choice
Beaney, et al. Expires 5 October 2025 [Page 34]
Internet-Draft Intel profile April 2025
$$measurement-values-map-extension //= (
&(tee.advisory-ids: -89) => $tee-advisory-ids-type
)
$tee-advisory-ids-type /= set-tstr-type
$tee-advisory-ids-type /= tagged-exp-tstr-not-member
$tee-advisory-ids-type /= tagged-exp-tstr-member
$$measurement-values-map-extension //= (
&(tee.attributes: -82) => $tee-attributes-type
)
$tee-attributes-type /= $masked-value-type
$$measurement-values-map-extension //= (
&(tee.cryptokeys: -91) => [ + $tee-cryptokey-type ]
)
$tee-cryptokey-type /= $crypto-key-type-choice
$$measurement-values-map-extension //= (
&(tee.tcbdate: -72) => $tee-date-type
)
$tee-date-type /= ~tdate
$tee-date-type /= tdate
$tee-date-type /= time
$tee-date-type /= etime ; RFC9581
$$measurement-values-map-extension //= (
&(tee.mrtee: -83) => $tee-digest-type
)
$$measurement-values-map-extension //= (
&(tee.mrsigner: -84) => $tee-digest-type
)
$tee-digest-type /= digest ; see corim
$tee-digest-type /= digests-type ; see corim
$tee-digest-type /= set-digest-type
$tee-digest-type /= tagged-exp-digest-member
$tee-digest-type /= tagged-exp-digest-not-member
$$measurement-values-map-extension //= (
&(tee.instance-id: -77) => $tee-instance-id-type
)
$tee-instance-id-type /= uint
$tee-instance-id-type /= bstr
$$measurement-values-map-extension //= (
&(tee.isvprodid: -85) => $tee-isvprodid-type
)
$tee-isvprodid-type /= uint
$tee-isvprodid-type /= bstr
Beaney, et al. Expires 5 October 2025 [Page 35]
Internet-Draft Intel profile April 2025
$$measurement-values-map-extension //= (
&(tee.miscselect: -81) => $tee-miscselect-type
)
$tee-miscselect-type /= $masked-value-type
$$measurement-values-map-extension //= (
&(tee.model: -71) => $tee-model-type
)
$tee-model-type /= tstr
op.eq=0
op.gt=1
op.ge=2
op.lt=3
op.le=4
op.mem=6
op.nmem=7
op.sub=8
op.sup=9
op.dif=10
$$measurement-values-map-extension //= (
&(tee.pceid: -80) => $tee-pceid-type
)
$tee-pceid-type /= tstr
$$measurement-values-map-extension //= (
&(tee.isvsvn: -73) => $tee-svn-type
)
$tee-svn-type /= svn-type .within numeric-type
$tee-svn-type /= tagged-numeric-ge
$$measurement-values-map-extension //= (
&(tee.tcb-comp-svn: -125) => $tee-tcb-comp-svn-type
)
$tee-tcb-comp-svn-type /=
[ 16*16 svn-type .within numeric-type ]
$tee-tcb-comp-svn-type /=
[ 16*16 tagged-numeric-ge ]
$$measurement-values-map-extension //= (
&(tee-tcb-eval-num: -86) => $tee-tcb-eval-num-type
)
$tee-tcb-eval-num-type /= uint .within numeric-type
$tee-tcb-eval-num-type /= tagged-numeric-ge
$$measurement-values-map-extension //= (
&(tee.tcbstatus: -88) => $tee-tcbstatus-type
Beaney, et al. Expires 5 October 2025 [Page 36]
Internet-Draft Intel profile April 2025
)
$tee-tcbstatus-type /= set-tstr-type
$tee-tcbstatus-type /= tagged-exp-tstr-member
$tee-tcbstatus-type /= tagged-exp-tstr-not-member
$$measurement-values-map-extension //= (
&(tee.vendor: -70) => $tee-vendor-type
)
$tee-vendor-type /= tstr
$$measurement-values-map-extension //= (
&(tee.platform-instance-id: -101) => $tee-platform-instance-id-type
)
$tee-platform-instance-id-type /= bstr
Authors' Addresses
James D. Beaney
Intel Corporation
Email: james.d.beaney@intel.com
Yogesh Deshpande
ARM Corporation
Email: yogesh.deshpande@arm.com
Andrew Draper
Altera Corporation
Email: andrew.draper@altera.com
Vincent R. Scarlata
Intel Corporation
Email: vincent.r.scarlata@intel.com
Ned Smith
Intel Corporation
Email: ned.smith@intel.com
Beaney, et al. Expires 5 October 2025 [Page 37]