RATS Conceptual Messages Wrapper

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 17 December 2023.¶

Copyright Notice

Copyright (c) 2023 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

The RATS architecture defines a handful of conceptual messages (see Section 8 of [RFC9334]), such as evidence and attestation results. Each conceptual message can have multiple claims encoding and serialization formats (Section 9 of [RFC9334]). Throughout their lifetime, RATS conceptual messages are typically transported over different protocols. For example, EAT [I-D.ietf-rats-eat] evidence in a "background check" topological arrangement first flows from Attester to Relying Party, and then from Relying Party to Verifier, over separate protocol legs. Attestation Results for Secure Interactions (AR4SI) [I-D.ietf-rats-ar4si] payloads in "passport" mode would go first from Verifier to Attester and then, at a later point in time and over a different channel, from Attester to Relying Party.¶

It is desirable to reuse any typing information associated with the messages across such protocol boundaries in order to minimize the cost associated with type registrations and maximize interoperability.¶

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 [RFC6838] - 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 attestation 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 [RFC9334].¶

This document reuses the terms defined in Section 2 of [RFC9193] (e.g., "Content-Type").¶

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 JSON array (Section 3.1);¶
2. A CMW based on CBOR tags (Section 3.2).¶

cmw-array = [
  type: coap-content-format / media-type
  value: JC<base64-string, bytes>
  ? ind: uint .bits cm-type
]

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

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

cm-type = &(
  reference-values: 0
  endorsements: 1
  evidence: 2
  attestation-results: 3
)

cmw-cbor-tag<bytes> = #6.<cbor-tag-numbers>(bytes)

cbor-tag-numbers = 0..18446744073709551615

func CMWTypeSniff(b []byte) (CMW, error) {
  if len(b) == 0 {
    return Unknown
  }

  if b[0] == 0x82 || b[0] == 0x83 {
    return CBORArray
  } else if b[0] >= 0xc0 && b[0] <= 0xdb {
    return CBORTag
  } else if b[0] == 0x5b {
    return JSONArray
  }

  return Unknown
}

4. Examples

The (equivalent) examples in Section 4.1, Section 4.2, and Section 4.3 assume that the Media-Type-Name application/vnd.example.rats-conceptual-msg has been registered alongside a corresponding CoAP Content-Format number 30001. The CBOR tag 1668576818 is derived applying the TN() transform as described in Section 3.2.¶

The example in Section 4.4 is a signed CoRIM payload with an explicit CM indicator 0b0000_0011 (3), meaning that the wrapped message contains both Reference Values and Endorsements.¶

[
  "application/vnd.example.rats-conceptual-msg",
  "q82rzQ"
]

[
  30001,
  h'abcdabcd'
]

82             # array(2)
   19 7531     # unsigned(30001)
   44          # bytes(4)
      abcdabcd # "\xABͫ\xCD"

[
  "application/vnd.example.rats-conceptual-msg",
  h'abcdabcd'
]

1668576818(h'abcdabcd')

da 63747632    # tag(1668576818)
   44          # bytes(4)
      abcdabcd # "\xABͫ\xCD"

[
  "application/signed-corim+cbor",
  h'd28443a10126a1',
  3
]

83                                    # array(3)
   78 1d                              # text(29)
      6170706c69636174696f6e2f7369676e65642d636f72696d2b63626f72
                                      # "application/signed-corim+cbor"
   47                                 # bytes(7)
      d28443a10126a1                  # "҄C\xA1\u0001&\xA1"
   03                                 # unsigned(3)

5. Registering a Media Type for Evidence

Note: Not sure whether this advice should go.¶

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

6. Implementation Status

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶

According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶

7. Security Considerations

This document defines two encapsulation formats for RATS conceptual messages. The messages themselves and their encoding ensure security protection. For this reason there are no further security requirements raised by the introduction of this encapsulation.¶

Changing the encapsulation of a payload by an adversary will result in incorrect processing of the encapsulated messages and this will subsequently lead to a processing error.¶

8. IANA Considerations

This document does not make any requests to IANA.¶

Appendix A. RFC9193 Content-Type ABNF

; from RFC9193
Content-Type-ABNF = '

Content-Type   = Media-Type-Name *( *SP ";" *SP parameter )
parameter      = token "=" ( token / quoted-string )

token          = 1*tchar
tchar          = "!" / "#" / "$" / "%" / "&" / "\'" / "*"
               / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
               / DIGIT / ALPHA
quoted-string  = %x22 *( qdtext / quoted-pair ) %x22
qdtext         = SP / %x21 / %x23-5B / %x5D-7E
quoted-pair    = "\" ( SP / VCHAR )

Media-Type-Name = type-name "/" subtype-name

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

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

DIGIT     =  %x30-39           ; 0 - 9
POS-DIGIT =  %x31-39           ; 1 - 9
ALPHA     =  %x41-5A / %x61-7A ; A - Z / a - z
SP        =  %x20
VCHAR     =  %x21-7E           ; printable ASCII (no SP)
'

Appendix B. Registering and Using CMWs

Figure 3 describes the registration preconditions for using CMWs in either array or CBOR tag forms.¶

Appendix C. Open Issues

The list of currently open issues for this documents can be found at https://github.com/thomas-fossati/draft-ftbs-rats-msg-wrap/issues.¶

Note to RFC Editor: please remove before publication.¶

Acknowledgments

The authors would like to thank Carl Wallace and Carsten Bormann for their reviews and suggestions.¶

Authors' Addresses