From be4810cdeb8d1a601016037cc85123f02da846c9 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Wed, 17 Jul 2024 15:14:54 +0000 Subject: [PATCH] Script updating gh-pages from aaf6e4e. [ci skip] --- .../draft-smith-rats-evidence-trans.html | 1521 +++++++++++++++++ .../draft-smith-rats-evidence-trans.txt | 395 +++++ class-instance-value-auth/index.html | 45 + index.html | 8 + 4 files changed, 1969 insertions(+) create mode 100644 class-instance-value-auth/draft-smith-rats-evidence-trans.html create mode 100644 class-instance-value-auth/draft-smith-rats-evidence-trans.txt create mode 100644 class-instance-value-auth/index.html diff --git a/class-instance-value-auth/draft-smith-rats-evidence-trans.html b/class-instance-value-auth/draft-smith-rats-evidence-trans.html new file mode 100644 index 0000000..f1080c9 --- /dev/null +++ b/class-instance-value-auth/draft-smith-rats-evidence-trans.html @@ -0,0 +1,1521 @@ + + + + + + +Evidence Transformations + + + + + + + + + + + + + + + + + + + + + + + + +
Internet-DraftEvidence TransformationsJuly 2024
Draper & SmithExpires 18 January 2025[Page]
+
+
+
+
Workgroup:
+
Remote ATtestation ProcedureS
+
Internet-Draft:
+
draft-smith-rats-evidence-trans-latest
+
Published:
+
+ +
+
Intended Status:
+
Standards Track
+
Expires:
+
+
Authors:
+
+
+
A. Draper
+
Intel
+
+
+
N. Smith
+
Intel
+
+
+
+
+

Evidence Transformations

+
+

Abstract

+

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.

+
+
+
+

+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 18 January 2025.

+
+
+ +
+
+ ▲

+Table of Contents +

+ +
+
+
+
+

+1. Introduction +

+

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.

+
+
+

+1.1. Terminology +

+

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.

+
+
+
+
+
+
+

+2. Verifier Reconciliation +

+

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.

+
+
+
+
+

+3. DICE / SPDM input data +

+

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.

+
+
+
+
+

+4. ACS Entries generated from DICE / SPDM input data +

+

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

+
+
+
+
+

+5. Transforming SPDM Evidence +

+

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).

+
+
+
+
+

+6. Transforming DICE Evidence +

+

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.

+
+
+
+
+

+7. Transforming Concise Evidence +

+
+
+
+
+

+8. Security and Privacy Considerations +

+

There are no security and privacy considerations.

+
+
+
+
+

+9. IANA Considerations +

+

There are no IANA considerations.

+
+
+
+

+10. References +

+
+
+

+10.1. Normative References +

+
+
[DICE.Attest]
+
+Trusted Computing Group (TCG), "DICE Attestation Architecture", Version 1.1, Revision 18 , , <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 , , <https://trustedcomputinggroup.org/wp-content/uploads/TCG-Endorsement-Architecture-for-Devices-V1-R38_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-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-rats-corim-05>.
+
+
[I-D.ietf-rats-endorsements]
+
+Thaler, D., Birkholz, H., and T. Fossati, "RATS Endorsements", Work in Progress, Internet-Draft, draft-ietf-rats-endorsements-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-rats-endorsements-02>.
+
+
[RFC2119]
+
+Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <https://www.rfc-editor.org/rfc/rfc8174>.
+
+
[RFC9334]
+
+Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, , <https://www.rfc-editor.org/rfc/rfc9334>.
+
+
[SPDM]
+
+Distributed Management Task Force, "Security Protocol and Data Model (SPDM)", Version 1.3.0 , , <https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.3.0.pdf>.
+
+
[TCG.CE]
+
+Trusted Computing Group, "TCG DICE Concise Evidence Binding for SPDM", Version 1.00, Revision 0.54 , , <https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Concise-Evidence-Binding-for-SPDM-Version-1.0-Revision-54_pub.pdf>.
+
+
[X.690]
+
+International Telecommunications Union, "Information technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, , <https://www.itu.int/rec/T-REC-X.690>.
+
+
+
+
+
+
+

+10.2. Informative References +

+
+
[DICE.Layer]
+
+Trusted Computing Group, "DICE Layering Architecture", Version 1.0, Revision 0.19 , , <https://trustedcomputinggroup.org/wp-content/uploads/DICE-Layering-Architecture-r19_pub.pdf>.
+
+
[I-D.fdb-rats-psa-endorsements]
+
+Fossati, T., Deshpande, Y., and H. Birkholz, "Arm's Platform Security Architecture (PSA) Attestation Verifier Endorsements", Work in Progress, Internet-Draft, draft-fdb-rats-psa-endorsements-04, , <https://datatracker.ietf.org/doc/html/draft-fdb-rats-psa-endorsements-04>.
+
+
[I-D.ietf-rats-concise-ta-stores]
+
+Wallace, C., Housley, R., Fossati, T., and Y. Deshpande, "Concise TA Stores (CoTS)", Work in Progress, Internet-Draft, draft-ietf-rats-concise-ta-stores-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-rats-concise-ta-stores-02>.
+
+
[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-29, , <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-29>.
+
+
[I-D.tschofenig-rats-psa-token]
+
+Tschofenig, H., Frost, S., Brossard, M., Shaw, A. L., and T. Fossati, "Arm's Platform Security Architecture (PSA) Attestation Token", Work in Progress, Internet-Draft, draft-tschofenig-rats-psa-token-23, , <https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-23>.
+
+
[IANA.coswid]
+
+IANA, "Concise Software Identifier (CoSWID)", , <https://www.iana.org/assignments/coswid>.
+
+
[RFC4122]
+
+Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, , <https://www.rfc-editor.org/rfc/rfc4122>.
+
+
[RFC7468]
+
+Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, , <https://www.rfc-editor.org/rfc/rfc7468>.
+
+
[RFC7942]
+
+Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, , <https://www.rfc-editor.org/rfc/rfc7942>.
+
+
[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, , <https://www.rfc-editor.org/rfc/rfc8610>.
+
+
[RFC9090]
+
+Bormann, C., "Concise Binary Object Representation (CBOR) Tags for Object Identifiers", RFC 9090, DOI 10.17487/RFC9090, , <https://www.rfc-editor.org/rfc/rfc9090>.
+
+
[RFC9393]
+
+Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Waltermire, "Concise Software Identification Tags", RFC 9393, DOI 10.17487/RFC9393, , <https://www.rfc-editor.org/rfc/rfc9393>.
+
+
[STD66]
+
+Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, , <https://www.rfc-editor.org/rfc/rfc3986>.
+
+
[STD94]
+
+Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <https://www.rfc-editor.org/rfc/rfc8949>.
+
+
[STD96]
+
+Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, , <https://www.rfc-editor.org/rfc/rfc9052>.
+
+
+
+
+
+
+
+

+Contributors +

+

The authors would like to thank the following people for their valuable contributions to the specification.

+

Henk Birkholz

+

Email: henk.birkholz@ietf.contact

+

Yogesh Deshpande

+

Email: yogesh.deshpande@arm.com

+

Thomas Fossati

+

Email: Thomas.Fossati@linaro.org

+

Dionna Glaze

+

Email: dionnaglaze@google.com

+
+
+
+
+

+Acknowledgments +

+
+
+
+
+

+Authors' Addresses +

+
+
Andrew Draper
+
Intel
+ +
+
+
Ned Smith
+
Intel
+ +
+
+
+ + + diff --git a/class-instance-value-auth/draft-smith-rats-evidence-trans.txt b/class-instance-value-auth/draft-smith-rats-evidence-trans.txt new file mode 100644 index 0000000..4843106 --- /dev/null +++ b/class-instance-value-auth/draft-smith-rats-evidence-trans.txt @@ -0,0 +1,395 @@ + + + + +Remote ATtestation ProcedureS A. Draper +Internet-Draft N. Smith +Intended status: Standards Track Intel +Expires: 28 December 2024 26 June 2024 + + + Evidence Transformations + draft-smith-rats-evidence-trans-latest + +Abstract + + 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. + +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 28 December 2024. + +Copyright Notice + + 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. + +Table of Contents + + 1. Introduction + 1.1. Terminology and Requirements Language + 2. Verifier Reconciliation + 3. Transforming SPDM Evidence + 4. Transforming DICE Evidence + 5. Transforming Concise Evidence + 6. Security and Privacy Considerations + 7. IANA Considerations + 8. References + 8.1. Normative References + 8.2. Informative References + Contributors + Acknowledgments + Authors' Addresses + +1. Introduction + + 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. + +1.1. Terminology and Requirements Language + + 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. + +2. Verifier Reconciliation + + 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. + +3. Transforming SPDM Evidence + + 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). + +4. Transforming DICE Evidence + + 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. + +5. Transforming Concise Evidence + +6. Security and Privacy Considerations + + There are no security and privacy considerations. + +7. IANA Considerations + + There are no IANA considerations. + +8. References + +8.1. Normative References + + [DICE.Attest] + Trusted Computing Group (TCG), "DICE Attestation + Architecture", Version 1.1, Revision 18 , January 2024, + . + + [DICE.CoRIM] + Trusted Computing Group (TCG), "DICE Endorsement + Architecture for Devices", Version 1.0, Revision 0.38 , + November 2022, . + + [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-04, 4 + March 2024, . + + [I-D.ietf-rats-endorsements] + Thaler, D., Birkholz, H., and T. Fossati, "RATS + Endorsements", Work in Progress, Internet-Draft, draft- + ietf-rats-endorsements-01, 12 June 2024, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [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, . + + [SPDM] Distributed Management Task Force, "Security Protocol and + Data Model (SPDM)", Version 1.3.0 , May 2023, + . + + [TCG.CE] Trusted Computing Group, "TCG DICE Concise Evidence + Binding for SPDM", Version 1.00, Revision 0.54 , January + 2024, . + + [X.690] International Telecommunications Union, "Information + technology — ASN.1 encoding rules: Specification of Basic + Encoding Rules (BER), Canonical Encoding Rules (CER) and + Distinguished Encoding Rules (DER)", ITU-T Recommendation + X.690, August 2015, . + +8.2. Informative References + + [DICE.Layer] + Trusted Computing Group, "DICE Layering Architecture", + Version 1.0, Revision 0.19 , July 2020, + . + + [I-D.fdb-rats-psa-endorsements] + Fossati, T., Deshpande, Y., and H. Birkholz, "Arm's + Platform Security Architecture (PSA) Attestation Verifier + Endorsements", Work in Progress, Internet-Draft, draft- + fdb-rats-psa-endorsements-04, 4 March 2024, + . + + [I-D.ietf-rats-concise-ta-stores] + Wallace, C., Housley, R., Fossati, T., and Y. Deshpande, + "Concise TA Stores (CoTS)", Work in Progress, Internet- + Draft, draft-ietf-rats-concise-ta-stores-02, 5 December + 2023, . + + [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-28, 25 June + 2024, . + + [I-D.tschofenig-rats-psa-token] + Tschofenig, H., Frost, S., Brossard, M., Shaw, A. L., and + T. Fossati, "Arm's Platform Security Architecture (PSA) + Attestation Token", Work in Progress, Internet-Draft, + draft-tschofenig-rats-psa-token-23, 24 June 2024, + . + + [IANA.coswid] + IANA, "Concise Software Identifier (CoSWID)", + . + + [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally + Unique IDentifier (UUID) URN Namespace", RFC 4122, + DOI 10.17487/RFC4122, July 2005, + . + + [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, + PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, + April 2015, . + + [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running + Code: The Implementation Status Section", BCP 205, + RFC 7942, DOI 10.17487/RFC7942, July 2016, + . + + [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, . + + [RFC9090] Bormann, C., "Concise Binary Object Representation (CBOR) + Tags for Object Identifiers", RFC 9090, + DOI 10.17487/RFC9090, July 2021, + . + + [RFC9393] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. + Waltermire, "Concise Software Identification Tags", + RFC 9393, DOI 10.17487/RFC9393, June 2023, + . + + [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + . + + [STD94] Bormann, C. and P. Hoffman, "Concise Binary Object + Representation (CBOR)", STD 94, RFC 8949, + DOI 10.17487/RFC8949, December 2020, + . + + [STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE): + Structures and Process", STD 96, RFC 9052, + DOI 10.17487/RFC9052, August 2022, + . + +Contributors + + The authors would like to thank the following people for their + valuable contributions to the specification. + + Henk Birkholz + + Email: henk.birkholz@ietf.contact + + Yogesh Deshpande + + Email: yogesh.deshpande@arm.com + + Thomas Fossati + + Email: Thomas.Fossati@linaro.org + + Dionna Glaze + + Email: dionnaglaze@google.com + +Acknowledgments + +Authors' Addresses + + Andrew Draper + Intel + Email: andrew.draper@intel.com + + + Ned Smith + Intel + Email: ned.smith@intel.com diff --git a/class-instance-value-auth/index.html b/class-instance-value-auth/index.html new file mode 100644 index 0000000..377b00f --- /dev/null +++ b/class-instance-value-auth/index.html @@ -0,0 +1,45 @@ + + + + ietf-rats-wg/draft-smith-rats-evidence-trans class-instance-value-auth preview + + + + +

Editor's drafts for class-instance-value-auth branch of ietf-rats-wg/draft-smith-rats-evidence-trans

+ + + + + + +
Evidence Transformationsplain textsame as main
+ + + diff --git a/index.html b/index.html index 1d4e671..cf30564 100644 --- a/index.html +++ b/index.html @@ -24,6 +24,14 @@

Editor's drafts for main branch of class-instance-value-auth

+ + + + + + +
Evidence Transformationsplain textsame as main