| Internet-Draft | +Evidence Transformations | +July 2024 | +
| Draper & Smith | +Expires 18 January 2025 | +[Page] | +
Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether to engage in secure interactions with it - or not. +Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. +Therefore that burden is typically offloaded to a Verifier. +In order to conduct Evidence appraisal, a Verifier requires fresh Evidence from an Attester. +Before a Verifier can appraise Evidence it may require transformation to an internal representation. +This document specifies Evidence transformation methods for DICE and SPDM formats to the CoRIM internal representation.¶
++ 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 18 January 2025.¶
++ Copyright (c) 2024 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.¶
+Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether to engage in secure interactions with it - or not. +Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. +Therefore that burden is typically offloaded to a Verifier. +In order to conduct Evidence appraisal, a Verifier requires fresh Evidence from an Attester. +Before a Verifier can appraise Evidence it may require transformation to an internal representation. +This document specifies Evidence transformation methods for DICE and SPDM formats to the CoRIM internal representation.¶
+This document uses terms and concepts defined by the RATS architecture. +For a complete glossary see Section 4 of [RFC9334]. +Addintional RATS architecture is found in [I-D.ietf-rats-endorsements]. +RATS architecture terms and concepts are always referenced as proper nouns, i.e., with Capital Letters.¶
+In this document, an Evidence structure describes an external representation. +There are many possible Evidence structures including [I-D.ietf-rats-eat] +The bytes composing the CoRIM data structure are the same either way.¶
+The terminology from CoRIM [I-D.ietf-rats-corim], CBOR [STD94], CDDL [RFC8610] and COSE [STD96] applies.¶
+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.¶
+This specification assumes the reader is familiar with Verifier Reconsiliation as described in [I-D.ietf-rats-corim]. +It describes how a Verifier should process the CoRIM to enable CoRIM authors to convey their intended meaning and how a Verifier reconciles its various inputs. +Evidence is one of its inputs. +The Verifier is expected to create an internal representation from an external representation. +By using an internal representation, the Verifier processes Evidence inputs such that they can be appraised consistently.¶
+This specification describes how Evidence in DICE [DICE.Attest], SPDM [SPDM], and concise evidence [TCG.CE] formats are transformed into the CoRIM [I-D.ietf-rats-corim] internal representation. +If other internal representations exist, a similar specification may be required that transforms Evidence to some other internal representation.¶
+An SPDM Requester sends commands to the Attestation Environment which is part of the SPDM Responder. +The responses to those commands include a certificate chain containing DICE measurements and SPDM MEASUREMENTS RESPONSE, which contains SPDM measurements.¶
+DICE/SPDM evidence is transformed into one or more ACS entries, each of which is created from upto four separate components: +- Environment class provides a unique name, which is the same for all instances of the Target Environment +- Environment instance provides an identifier which differes for each instance of the TE +- Fields in measurement map provide measurements of parts of the TE named in environment +- Authorized-by indicates the root key used to authorize the key chain leading to SPDM signatures¶
+The sections below describe how these fields are filled in for different types of measurements¶
+This section defines how Evidence from SPDM [SPDM] is transformed into a format where it can be added to an appraisal claims set. +A Verifier supporting SPDM format Evidence should implement this section.¶
+The TCG DICE Concise Evidence Binding for SPDM specification [TCG.CE] describes the process by which measurements in an SPDM Measurement Block are converted to Evidence suitable for matching using the rules below.
+The SPDM measurements are converted to concise-evidence which has a format that is similar to CoRIM triples-map (their semantics follows the matching rules described above).¶
This section defines how Evidence from DICE [DICE.Attest] is transformed into a format where it can be added to an appraisal claims set. +A Verifier supporting DICE format Evidence should implement this section.¶
+DICE Evidence appears in certificates in the TcbInfo or MultiTcbInfo extension.
+Each TcbInfo, and each entry in the MultiTcbInfo, is converted to an endorsed-triple-record using the rules in this section.
+In a MultiTcbInfo each entry in the sequence is treated as independent and translated into a separate Evidence object.¶
The Verifier SHALL translate each field in the TcbInfo into a field in the created endorsed-triple-record¶
+The TcbInfo type field SHALL be copied to the field named environment-map / class / class-id and tagged with tag #6.111¶
The TcbInfo vendor field SHALL be copied to the field named environment-map / class / vendor¶
The TcbInfo model field SHALL be copied to the field named environment-map / class / model¶
The TcbInfo layer field SHALL be copied to the field named environment-map / class / layer¶
The TcbInfo index field SHALL be copied to the field named environment-map / class / index¶
The TcbInfo version field SHALL be translated to the field named measurement-map / mval / version / version¶
The TcbInfo svn field SHALL be copied to the field named measurement-map / mval / svn¶
The TcbInfo fwids field SHALL be translated to the field named measurement-map / mval / digests¶
Each digest within fwids is translated to a CoMID digest object, with an appropriate algorithm identifier¶
+The TcbInfo flags field SHALL be translated to the field named measurement-map / mval / flags¶
Each flag is translated independently¶
+The TcbInfo vendorInfo SHALL shall be copied to the field named measurement-map / mval / raw-value¶
If there are multiple endorsed-triple-records with the same environment-map then they MUST be merged into a single entry.
+If the measurement-values-map fields in Evidence triples have conflicting values then the Verifier MUST fail validation.¶
There are no security and privacy considerations.¶
+There are no IANA considerations.¶
+The authors would like to thank the following people for their valuable contributions to the specification.¶
+Henk Birkholz¶
+Email: henk.birkholz@ietf.contact¶
+Yogesh Deshpande¶
+Email: yogesh.deshpande@arm.com¶
+Thomas Fossati¶
+Email: Thomas.Fossati@linaro.org¶
+Dionna Glaze¶
+Email: dionnaglaze@google.com¶
+| Evidence Transformations | +plain text | +same as main | +
| Evidence Transformations | +plain text | +same as main | +