Internet-Draft EAT Measured Component March 2024
Frost, et al. Expires 4 September 2024 [Page]
Workgroup:
Remote ATtestation ProcedureS
Internet-Draft:
draft-fft-rats-eat-measured-component-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
S. Frost
Arm
T. Fossati
Linaro
H. Tschofenig
Siemens

EAT Measured Component

Abstract

This document defines a "measured components" format that can be used with the EAT Measurements claim.

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 4 September 2024.

Table of Contents

1. Introduction

Section 4.2.16 of [I-D.ietf-rats-eat] defines a Measurements claim that:

This claim allows for different measurement formats, each identified by a different CoAP Content-Format (Section 12.3 of [RFC7252]). Initially, the only specified format is CoSWID of type "evidence", as per Section 2.9.4 of [RFC9393].

This document introduces the "measured components" format that can be used with the EAT Measurements claim in addition or as an alternative to CoSWID.

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.

In this document, CDDL [RFC8610] [RFC9165] [I-D.ietf-cbor-cddl-modules] [I-D.ietf-cbor-cddl-more-control] is used to describe the data formats.

3. Information Model

A measured component information element includes the computed digest on the software or configuration payload, along with metadata that helps in identifying the measurement and the authorizing entity for component installation.

Table 1 describes the information model of a measured component.

Table 1: Measured Component Information Elements
IE Description Requirement Level
Component Name The name given to a measured component. It is important that this name remains consistent across different releases to allow for better tracking of the same measured item across updates. When combined with a consistent versioning scheme, it enables better signaling from the appraisal procedure to the relying parties. REQUIRED
Component Version A value representing the specific release or development version of the measured component. Using Semantic Versioning is RECOMMENDED. OPTIONAL
Digest Value Hash of the invariant part of the component that is loaded in memory at startup time. REQUIRED
Digest Algorithm Hash algorithm used to compute the Digest Value. REQUIRED
Signer A unique identifier of the entity authorizing installation of the measured component. REQUIRED
Countersigners One or more unique identifiers of further authorizing entities for component installation OPTIONAL

4. Data Model

The data model is inspired by the "PSA software component" claim (Section 4.4.1 of [I-D.tschofenig-rats-psa-token]), which has been slightly refactored to take into account the recommendations about new EAT claims design in Appendix E of [I-D.ietf-rats-eat].

The following types and semantics have been reused:

4.1. CDDL

The measured-component data item:

measured-component = [
  id:               component-id
  measurement:      corim.digest
  signer:           ckt
  ? countersigners: [ + ckt ]
]

; COSE Key Thumbprint
ckt = bytes

component-id = [
  name:      text
  ? version: version
]

;# import $version-scheme from rfc9393 as coswid

version = [
  val:      text
  ? scheme: coswid.$version-scheme
]

; eventually: ";#import digest from rfcxxxx as corim"

corim.digest = [
  alg: (int / text)
  val: bytes
]

The CDDL extending the EAT Measurements format:

$mc-cbor = bstr .cbor measured-component
$mc-json = tstr .json measured-component

EAT CBOR (`.feature "cbor"`)
$measurements-body-cbor /= $mc-cbor            ; native
$measurements-body-cbor /= tstr .b64u $mc-json ; tunnel

; EAT JSON (`.feature "json"`)
$measurements-body-json /= $mc-json            ; native
$measurements-body-json /= tstr .b64u $mc-cbor ; tunnel

4.1.1. CWT

Table 2
content-type (CoAP C-F equivalent) content-format
application/measured-component+cbor bytes .cbor measured-component
application/measured-component+json text .b64u measured-component

4.1.2. JWT

Table 3
content-type (CoAP C-F equivalent) content-format
application/measured-component+json text .json measured-component
application/measured-component+cbor text .b64u measured-component

5. Examples

(The examples are CBOR only. JSON examples will be added in a future version of this document.)

The example in Figure 1 is a measured component with all the fields populated.

[
  / id / [
    / name / "boot loader X",
    / version / [
      "1.2.3rc2",
      16384 / semver /
    ]
  ],
  / measurement / [
    / alg / "sha-256",
    / val / h'3996003d486fb91ffb056f7d03f2b2992b215b31dbe7af4b37
              3431fc7d319da3'
  ],
  / signer / h'492e9b676c21f6012b1ceeb9032feb4141a880797355f6675
              015ec59c51ca1ec',
  / countersigners / [
    h'4277bb97ba7b51577a0d38151d3e08b40bdf946753f5b5bdeb814d6ff5
      7a8a5e'
  ]
]
Figure 1: Complete Measured Component

The example in Figure 2 is the same measured component as above but used as the format of a measurements claim in a EAT claims-set.

Note that the example uses a CoAP Content-Format value from the experimental range (65000), which will change to the value assigned by IANA for the application/measured-component+cbor Content-Format.

Note also that the array contains only one measured component, but additional entries could be added if the measured TCB is made of multiple, individually measured components.

{
  273: [
    [
      65000, / using a CoAP C-F from the experimental range /
      <<
        [
          / id / [
            / name / "boot loader X",
            / version / [
              "1.2.3rc2",
              16384 / semver /
            ]
          ],
          / measurement / [
            / alg / "sha-256",
            / val / h'3996003d486fb91ffb056f7d03f2b2992b215b31db
                      e7af4b373431fc7d319da3'
          ],
          / signer / h'492e9b676c21f6012b1ceeb9032feb4141a880797
                      355f6675015ec59c51ca1ec',
          / countersigners / [
            h'4277bb97ba7b51577a0d38151d3e08b40bdf946753f5b5bdeb
              814d6ff57a8a5e'
          ]
        ]
      >>
    ]
  ]
}
Figure 2: EAT Measurements Claim using a Measured Component

6. Security Considerations

TODO

7. IANA Considerations

RFC Editor: replace "RFCthis" with the RFC number assigned to this document.

7.1. Media Types Registrations

IANA is requested to add the following media types to the "Media Types" registry [IANA.media-types].

Table 4: Measured Component Media Types
Name Template Reference
mc+cbor application/measured-component+cbor RFCthis
mc+json application/measured-component+json RFCthis

7.1.1. application/measured-component+cbor

Type name:

application

Subtype name:

measured-component+cbor

Required parameters:

n/a

Optional parameters:

n/a

Encoding considerations:

binary (CBOR)

Security considerations:

Section 6 of RFCthis

Interoperability considerations:

n/a

Published specification:

RFCthis

Applications that use this media type:

Attesters, Verifiers and Relying Parties

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/cbor". (No fragment identification syntax is currently defined for "application/cbor".)

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

7.1.2. application/measured-component+json

Type name:

application

Subtype name:

measured-component+json

Required parameters:

n/a

Optional parameters:

n/a

Encoding considerations:

binary (JSON is UTF-8-encoded text)

Security considerations:

Section 6 of RFCthis

Interoperability considerations:

n/a

Published specification:

RFCthis

Applications that use this media type:

Attesters, Verifiers and Relying Parties

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/json". (No fragment identification syntax is currently defined for "application/json".)

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

7.2. Measured Component Content-Format Registrations

IANA is requested to register two Content-Format numbers in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" Registry [IANA.core-parameters], as follows:

Table 5
Content-Type Content Coding ID Reference
application/measured-component+cbor - TBD1 RFCthis
application/measured-component+json - TBD2 RFCthis

8. References

8.1. Normative References

[I-D.ietf-cbor-cddl-modules]
Bormann, C., "CDDL Module Structure", Work in Progress, Internet-Draft, draft-ietf-cbor-cddl-modules-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-cbor-cddl-modules-01>.
[I-D.ietf-cbor-cddl-more-control]
Bormann, C., "More Control Operators for CDDL", Work in Progress, Internet-Draft, draft-ietf-cbor-cddl-more-control-03, , <https://datatracker.ietf.org/doc/html/draft-ietf-cbor-cddl-more-control-03>.
[I-D.ietf-cose-key-thumbprint]
Isobe, K., Tschofenig, H., and O. Steele, "CBOR Object Signing and Encryption (COSE) Key Thumbprint", Work in Progress, Internet-Draft, draft-ietf-cose-key-thumbprint-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-cose-key-thumbprint-04>.
[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-03, , <https://datatracker.ietf.org/doc/html/draft-ietf-rats-corim-03>.
[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-25, , <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-25>.
[IANA.core-parameters]
IANA, "Constrained RESTful Environments (CoRE) Parameters", <https://www.iana.org/assignments/core-parameters>.
[IANA.media-types]
IANA, "Media Types", <https://www.iana.org/assignments/media-types>.
[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>.
[RFC7252]
Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, , <https://www.rfc-editor.org/rfc/rfc7252>.
[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>.
[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>.
[RFC9165]
Bormann, C., "Additional Control Operators for the Concise Data Definition Language (CDDL)", RFC 9165, DOI 10.17487/RFC9165, , <https://www.rfc-editor.org/rfc/rfc9165>.
[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>.

8.2. Informative References

[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-22, , <https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-22>.

Appendix A. Collected CDDL

TODO

Appendix B. Open Issues

The list of currently open issues for this documents can be found at https://github.com/thomas-fossati/draft-fft-rats-eat-measured-component/issues.

Note to RFC Editor: please remove before publication.

Acknowledgments

The authors would like to thank TBD for their comments, reviews and suggestions.

Authors' Addresses

Simon Frost
Arm
Thomas Fossati
Linaro
Hannes Tschofenig
Siemens