Internet-Draft RATS CMW October 2022
Birkolz, et al. Expires 15 April 2023 [Page]
Remote ATtestation ProcedureS
Intended Status:
Standards Track
H. Birkolz
Fraunhofer SIT
N. Smith
T. Fossati
H. Tschofenig

RATS Conceptual Messages Wrapper


This document defines two encapsulation formats for RATS conceptual messages (e.g., evidence, attestation results, endorsements and reference values.)

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (, which is archived at

Source for this draft and an issue tracker can be found at

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

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 15 April 2023.

1. Introduction

The RATS architecture defines a handful of conceptual messages (Section 8 of [I-D.ietf-rats-architecture]). Each conceptual message can have multiple serialization formats (Section 9 of [I-D.ietf-rats-architecture]). The same serialized message may have to be transported via different protocols - for example, EAT [I-D.ietf-rats-eat] evidence in a "background check" topological arrangement, AR4SI [I-D.ietf-rats-ar4si] attestation results in "passport" mode.

In order to minimize the cost associated with registration and maximize interoperability, it is desirable to reuse their typing information across such boundaries.

This document defines two encapsulation formats for RATS conceptual messages that aim to achieve the goals stated above.

These encapsulation formats are designed to be:

  • Self-describing - which removes the dependency on the framing provided by the embedding protocol (or the storage system) to convey exact typing information.
  • Based on media types - which allows amortising their registration cost across many different usage scenarios.

A protocol designer could use these formats, for example, to convey evidence, endorsements or reference values in certificates and CRLs extensions ([DICE-arch]), to embed attesation results or evidence as first class authentication credentials in TLS handshake messages [I-D.fossati-tls-attestation], to transport attestation-related payloads in RESTful APIs, or for stable storage of attestation results in form of file system objects.

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] is used to describe the data formats.

The reader is assumed to be familiar with the vocabulary and concepts defined in [I-D.ietf-rats-architecture].

3. Conceptual Message Wrapper Encodings

Two types of RATS Conceptual Message Wrapper (CMW) are specified in this document:

  1. a CMW using a CBOR or a JSON array (Section 3.1)
  2. a CMW based on CBOR tags (Section 3.2).

3.1. CMW Array

The CMW array illustrated in Figure 1 is composed of two members:

  • type: ether a text string representing a media-type [RFC6838] or an unsigned integer corresponding to a CoAP Content-Format [RFC7252]
  • value: the RATS conceptual message serialized according to the value defined in the type member.

A CMW array can be encoded as CBOR [STD94] or JSON [RFC8259].

When using JSON, the value field is encoded as Base64 using the URL and filename safe alphabet (Section 5 of [RFC4648]) without padding.

When using CBOR, the value field is serialized as a CBOR bytes string.

cmw = [ type, value ]

type = coap-content-format / media-type

coap-content-format = uint .size 2
media-type = text .abnf ("media-type" .cat RFC6838)

value = cbor-bytes / base64-string

cbor-bytes = bytes
base64-string = text .regexp "[A-Za-z0-9_-]+"

RFC6838 = '
media-type = type-name "/" subtype-name *1("+" suffix) parameters

type-name = restricted-name
subtype-name = restricted-name

; see
suffix = "xml" / "json" / "ber" / "cbor" / "der" / "fastinfoset" /
         "wbxml" / "zip" / "tlv" / "json-seq" / "sqlite3" / "jwt" /
         "gzip" / "cbor-seq" / "zstd"

parameters = *(";" parameter-name "=" parameter-value)

parameter-name = restricted-name
parameter-value = *VCHAR

restricted-name = restricted-name-first *126restricted-name-chars
restricted-name-first  = ALPHA / DIGIT
restricted-name-chars  = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "-" /
                         "^" / "_"
restricted-name-chars =/ "." ; Characters before first dot always
                             ; specify a facet name
restricted-name-chars =/ "+" ; Characters after last plus always
                             ; specify a structured syntax suffix

VCHAR = %x21-7E            ; Visible (printing) characters
ALPHA = %x41-5A / %x61-7A  ; A-Z / a-z
DIGIT = %x30-39            ; 0-9
Figure 1: CDDL definition

3.2. CMW CBOR Tags

CBOR Tags used as CMW are derived from CoAP Content Format values. If a CoAP Content Format exists for a RATS conceptual message, the TN() transform defined in Appendix B of [RFC9277] can be used to derive a CBOR tag in range [1668546817, 1668612095].

4. Examples

The (equivalent) examples below assume the media-type application/vnd.example.rats-conceptual-msg has been registered alongside a corresponding CoAP content format 30001. The CBOR tag 1668576818 is derived applying the TN transform as described in Section 3.2.

Figure 2: CBOR encoding
Figure 3: JSON encoding
Figure 4: CBOR tag

6. IANA Considerations

When registering a new media type for evidence, in addition to its syntactical description, the author SHOULD provide a public and stable description of the signing and appraisal procedures associated with the data format.

7. References

7.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, , <>.
Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, , <>.
Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <>.
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, , <>.
Bormann, C., "Additional Control Operators for the Concise Data Definition Language (CDDL)", RFC 9165, DOI 10.17487/RFC9165, , <>.
Richardson, M. and C. Bormann, "On Stable Storage for Items in Concise Binary Object Representation (CBOR)", RFC 9277, DOI 10.17487/RFC9277, , <>.
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <>.

7.2. Informative References

Trusted Computing Group, "DICE Attestation Architecture", , <>.
Tschofenig, H., Fossati, T., Howard, P., Mihalcea, I., and Y. Deshpande, "Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Work in Progress, Internet-Draft, draft-fossati-tls-attestation-01, , <>.
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-03, , <>.
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote Attestation Procedures Architecture", Work in Progress, Internet-Draft, draft-ietf-rats-architecture-22, , <>.
Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", Work in Progress, Internet-Draft, draft-ietf-rats-eat-16, , <>.


TODO acknowledge.

Authors' Addresses

Henk Birkolz
Fraunhofer SIT
Ned Smith
Thomas Fossati
Hannes Tschofenig