EAT Media Types
Internet-Draft draft-lundblade-rats-eat-media-type-00
Laurence Lundblade
Security Theory LLC
lgl@securitytheory.com
Henk Birkholz
Fraunhofer Institute for Secure Information Technology
Rheinstrasse 75
Darmstadt
64295
Germany
henk.birkholz@sit.fraunhofer.de
Thomas Fossati
arm
thomas.fossati@arm.com
26 May 2022
Security
RATS
EAT, media type
Payloads used in Remote Attestation Procedures may require an associated media type for their conveyance, for example when used in RESTful APIs.
This memo defines media types to be used for Entity Attestation Tokens (EAT).
Discussion Venues
Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/.
Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-eat-mt.
Introduction
Payloads used in Remote Attestation Procedures [RATS-Arch] may require an associated media type for their conveyance, for example when used in RESTful APIs (Figure 1).
Conveying RATS conceptual messages in REST APIs using EAT

RP

Attester

Verifier

POST

/verify

EAT(Evidence)

200

OK

EAT(Attestation

Results)

POST

/auth

EAT(Attestation

Results)

201

Created

.----.                    .----------.                .----------.
| RP |                    | Attester |                | Verifier |
'-+--'                    '----+-----'                '-----+----'
  |                            | POST /verify               |
  |                            | EAT(Evidence)              |
  |                            +--------------------------->|
  |                            |                     200 OK |
  |                            |   EAT(Attestation Results) |
  |                            |<---------------------------+
  |                 POST /auth |                            |
  |   EAT(Attestation Results) |                            |
  |<---------------------------+                            |
  | 201 Created                |                            |
  +--------------------------->|                            |
  |                            |                            |
  |                            |                            |

This memo defines media types to be used for Entity Attestation Token (EAT) [EAT] payloads independently of the RATS Conceptual Message in which they manifest themselves.
Requirements Language
This document uses the terms and concepts defined in [RATS-Arch].
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.
EAT Types
Figure 2 illustrates the six EAT wire formats and how they relate to each other. [EAT] defines four of them (CWT, JWT and DEB in its JSON and CBOR flavours), whilst [UCCS] defines the remaining two: UCCS and UJCS.
EAT Types

UJCS

UCCS

JWT

Crypto

CWT

Claims-Set

DEB-J

Bundle

Digest

DEB-C

submod

Nested-Token

Legenda:

Process

Wire

Fmt

CDDL

               .-----.
         .----+ UJCS |<-------------------------.
        |     '-----'                            |
        |                                        |
        |      .-----.                           |
        +-----+ UCCS |<-----------------------.  |
        |     '-----'                          | |
        |                                      | |
        |      .------.                        | |
        +-----+  JWT  |<------.                | |
        |     '------'      .--+---.           | |
        |                  | Crypto |<------.  | |
        |      .------.     '--+---'         | | |
        +-----+  CWT  |<------'              | | |
        |     '------'                   .---+-+-+----.
        |                                | Claims-Set +--.
        |      .------.                  '---+---+----'   |
        +-----+ DEB-J |<------.              | ^ |        v
        |     '------'      .--+---.         | | |     .------.
        |                  | Bundle |<------'  | |    | Digest |
        |      .------.     '--+---'           | v     '--+---'
        +-----+ DEB-C |<------'  ^         .---+----.     |
        |     '------'           |         | submod |<---'
        |                        |         '--------'
        v                        |             ^
.--------------.                 |             |
| Nested-Token +-----------------+------------'
'--------------'

                .-------.     .---------.   .------.
     Legenda:  | Process |   | Wire Fmt |   | CDDL |
                '-------'    '---------'    '------'

A Media Type Parameter for EAT Profiles
EAT is an open and flexible format. To improve interoperability, Section 7 of [EAT] defines the concept of EAT profiles. Profiles are used to constrain the parameters that producers and consumers of a specific EAT profile need to understand in order to interoperate. For example: the number and type of claims, which serialisation format, the supported signature schemes, etc. EATs carry an in-band profile identifier using the eat_profile claim (see Section 4.3.3 of [EAT]). The value of the eat_profile claim is either an OID or a URI.
The media types defined in this document include an optional profile parameter that can be used to mirror the eat_profile claim of the transported EAT. Exposing the EAT profile at the API layer allows API routers to dispatch payloads directly to the profile-specific processor without having to snoop into the request bodies. This design also provides a finer-grained and scalable type system that matches the inherent extensibility of EAT. The expectation being that a certain EAT profile automatically obtains a media type derived from the base (e.g., application/eat-cwt) by populating the profile parameter with the corresponding OID or URL.
Examples
The example in Figure 3 illustrates the usage of EAT media types for transporting attestation evidence.
Example REST Verification API (request)

POST /challenge-response/v1/session/1234567890 HTTP/1.1
Host: verifier.example
Accept: application/eat-cwt; profile=tag:ar4si.example,2021
Content-Type: application/eat-cwt; profile=tag:evidence.example,2022

[ CBOR-encoded EAT w/ profile=tag:evidence.example,2022 ]

The example in Figure 4 illustrates the usage of EAT media types for transporting attestation results.
Example REST Verification API (response)

HTTP/1.1 200 OK
Content-Type: application/eat-cwt; profile=tag:ar4si.example,2021

[ CBOR-encoded EAT w/ profile=tag:ar4si.example,2021 ]

In both cases the profile is carried as an explicit parameter.
Security Considerations
The security consideration of [EAT] and [UCCS] apply in full.
IANA Considerations
RFC Editor: please replace RFCthis with this RFC number and remove this note.
Media Types
IANA is requested to add the following media types to the "Media Types" registry [IANA.media-types].
New Media Types
Name | Template | Reference
EAT CWT | application/eat-cwt | RFCthis, Section 6.2
EAT JWT | application/eat-jwt | RFCthis, Section 6.3
EAT CBOR DEB | application/eat-deb+cbor | RFCthis, Section 6.4
EAT JSON DEB | application/eat-deb+json | RFCthis, Section 6.5
EAT UCCS | application/eat-ucs+cbor | RFCthis, Section 6.6
EAT UJCS | application/eat-ucs+json | RFCthis, Section 6.7
application/eat-cwt Registration
Type name:
application
Subtype name:
eat-cwt
Required parameters:
n/a
Optional parameters:
"profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)
Encoding considerations:
binary
Security considerations:
Section 5 of RFCthis
Interoperability considerations:
n/a
Published specification:
Section 6.1 of RFCthis
Applications that use this media type:
Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Fragment identifier considerations:
n/a
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:
maybe
application/eat-jwt Registration
Type name:
application
Subtype name:
eat-jwt
Required parameters:
n/a
Optional parameters:
"profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)
Encoding considerations:
8bit
Security considerations:
Section 5 of RFCthis
Interoperability considerations:
n/a
Published specification:
Section 6.1 of RFCthis
Applications that use this media type
Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Fragment identifier considerations:
n/a
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:
maybe
application/eat-deb+cbor Registration
Type name:
application
Subtype name:
eat-deb+cbor
Required parameters:
n/a
Optional parameters:
"profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)
Encoding considerations:
binary
Security considerations:
Section 5 of RFCthis
Interoperability considerations:
n/a
Published specification:
Section 6.1 of RFCthis
Applications that use this media type:
Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Fragment identifier considerations:
n/a
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:
maybe
application/eat-deb+json Registration
Type name:
application
Subtype name:
eat-deb+json
Required parameters:
n/a
Optional parameters:
"profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)
Encoding considerations:
Same as [RFC7159]
Security considerations:
Section 5 of RFCthis
Interoperability considerations:
n/a
Published specification:
Section 6.1 of RFCthis
Applications that use this media type
Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Fragment identifier considerations:
n/a
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:
maybe
application/eat-ucs+cbor Registration
Type name:
application
Subtype name:
eat-ucs+cbor
Required parameters:
n/a
Optional parameters:
"profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)
Encoding considerations:
binary
Security considerations:
Section 5 of RFCthis
Interoperability considerations:
n/a
Published specification:
Section 6.1 of RFCthis
Applications that use this media type:
Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Fragment identifier considerations:
n/a
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:
maybe
application/eat-ucs+json Registration
Type name:
application
Subtype name:
eat-ucs+json
Required parameters:
n/a
Optional parameters:
"profile" (EAT profile in string format. OIDs MUST use the dotted-decimal notation. The parameter value is case-insensitive.)
Encoding considerations:
Same as [RFC7159]
Security considerations:
Section 5 of RFCthis
Interoperability considerations:
n/a
Published specification:
Section 6.1 of RFCthis
Applications that use this media type
Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Fragment identifier considerations:
n/a
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:
maybe
Content-Format
(Issue: need a way to pass the profile information when using content formats. A new CoAP option?)
IANA is requested to register a Content-Format number in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" Registry [IANA.core-parameters], as follows:
New Content-Formats
Content-Type | Content Coding | ID | Reference
application/eat-cwt | - | TBD1 | RFCthis
application/eat-jwt | - | TBD2 | RFCthis
application/eat-deb+cbor | - | TBD3 | RFCthis
application/eat-deb+json | - | TBD4 | RFCthis
application/eat-ucs+cbor | - | TBD5 | RFCthis
application/eat-ucs+json | - | TBD6 | RFCthis
TBD1..6 are to be assigned from the space 256..999.
In the registry as defined by Section 12.3 of [CoAP] at the time of writing, the column "Content-Type" is called "Media type" and the column "Content Coding" is called "Encoding". RFC editor: please remove this paragraph.
References
Normative References
[EAT]

The Entity Attestation Token (EAT)
Laurence Lundblade
Security Theory LLC
Giridhar Mandyam
Qualcomm Technologies Inc.
Jeremy O'Donoghue
Qualcomm Technologies Inc.
20 May 2022
Internet-Draft draft-ietf-rats-eat-13
[UCCS]

A CBOR Tag for Unprotected CWT Claims Sets
Henk Birkholz
Fraunhofer SIT
Jeremy O'Donoghue
Qualcomm Technologies Inc.
Nancy Cam-Winget
Cisco Systems
Carsten Bormann
Universität Bremen TZI
12 January 2022
Internet-Draft draft-ietf-rats-uccs-02
[CoAP]

The Constrained Application Protocol (CoAP)
Z. Shelby
K. Hartke
C. Bormann
June 2014
RFC 7252
DOI 10.17487/RFC7252
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[IANA.media-types]

Media Types
IANA
[RFC7159]

The JavaScript Object Notation (JSON) Data Interchange Format
T. Bray, Ed.
March 2014
RFC 7159
DOI 10.17487/RFC7159
[IANA.core-parameters]

Constrained RESTful Environments (CoRE) Parameters
IANA
Informative References
[RATS-Arch]

Remote Attestation Procedures Architecture
Henk Birkholz
Fraunhofer SIT
Dave Thaler
Microsoft
Michael Richardson
Sandelman Software Works
Ned Smith
Intel Corporation
Wei Pan
Huawei Technologies
24 May 2022
Internet-Draft draft-ietf-rats-architecture-16
Acknowledgments
TODO