Internet DRAFT - draft-ietf-rats-msg-wrap
draft-ietf-rats-msg-wrap
Remote ATtestation ProcedureS H. Birkholz
Internet-Draft Fraunhofer SIT
Intended status: Standards Track N. Smith
Expires: 30 August 2024 Intel
T. Fossati
Linaro
H. Tschofenig
27 February 2024
RATS Conceptual Messages Wrapper (CMW)
draft-ietf-rats-msg-wrap-04
Abstract
This document defines the RATS conceptual message wrapper (CMW)
format, a type of encapsulation format that can be used for any RATS
messages, such as Evidence, Attestation Results, Endorsements, and
Reference Values. Additionally, the document describes a collection
type that enables the aggregation of one or more CMWs into a single
message.
This document also defines corresponding CBOR tag, JSON Web Tokens
(JWT) and CBOR Web Tokens (CWT) claims, as well as an X.509
extension. These allow embedding the wrapped conceptual messages
into CBOR-based protocols, web APIs, and PKIX protocols.
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 (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-ftbs-rats-msg-wrap.
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/.
Birkholz, et al. Expires 30 August 2024 [Page 1]
Internet-Draft RATS CMW February 2024
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 30 August 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Conceptual Message Wrapper Encodings . . . . . . . . . . . . 5
3.1. CMW Record . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. CMW CBOR Tags . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Use of Pre-existing CBOR Tags . . . . . . . . . . . . 6
3.3. CMW Collections . . . . . . . . . . . . . . . . . . . . . 7
3.4. CMW Tunnel . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1. CBOR-to-JSON . . . . . . . . . . . . . . . . . . . . 8
3.4.2. JSON-to-CBOR . . . . . . . . . . . . . . . . . . . . 8
3.5. Decapsulation Algorithm . . . . . . . . . . . . . . . . . 8
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. JSON Record . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. CBOR Record . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. CBOR Tag . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. CBOR Record with explicit CM indicator . . . . . . . . . 10
4.5. CBOR Collection . . . . . . . . . . . . . . . . . . . . . 11
4.6. JSON Collection . . . . . . . . . . . . . . . . . . . . . 12
4.7. Use in JWT . . . . . . . . . . . . . . . . . . . . . . . 13
5. Transporting CMW in X.509 Messages . . . . . . . . . . . . . 14
5.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Compatibility with DICE ConceptualMessageWrapper . . . . 15
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 16
6.1. Project Veraison . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
Birkholz, et al. Expires 30 August 2024 [Page 2]
Internet-Draft RATS CMW February 2024
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.1. CWT cmw Claim Registration . . . . . . . . . . . . . . . 17
8.2. JWT cmw Claim Registration . . . . . . . . . . . . . . . 17
8.3. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 18
8.4. RATS Conceptual Message Wrapper (CMW) Indicators
Registry . . . . . . . . . . . . . . . . . . . . . . . . 18
8.4.1. Instructions for the Designated Expert . . . . . . . 18
8.4.2. Structure of Entries . . . . . . . . . . . . . . . . 18
8.5. Media Types . . . . . . . . . . . . . . . . . . . . . . . 19
8.5.1. application/cmw+cbor . . . . . . . . . . . . . . . . 19
8.5.2. application/cmw+json . . . . . . . . . . . . . . . . 20
8.6. New SMI Numbers Registrations . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Collected CDDL . . . . . . . . . . . . . . . . . . . 24
Appendix B. Registering and Using CMWs . . . . . . . . . . . . . 26
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 be sent by
the Verifier to the Attester and then, at a later point in time
and over a different channel, from the Attester to the Relying
Party.
It is desirable to reuse any typing information associated with the
messages across such protocol boundaries to minimize the cost
associated with type registrations and maximize interoperability.
With the CMW format described in this document, protocol designers do
not need to update protocol specifications to support different
conceptual messages. This approach reduces the implementation effort
for developers to support different attestation technologies. For
Birkholz, et al. Expires 30 August 2024 [Page 3]
Internet-Draft RATS CMW February 2024
example, an implementer of a Relying Party application does not need
to parse attestation-related conceptual messages, such as different
Evidence formats, but can instead utilize the CMW format to be
agnostic to the attestation technology.
This document defines two encapsulation formats for RATS conceptual
messages that aim to achieve the goals stated above.
These encapsulation formats have been specifically designed to
possess the following characteristics:
* They are self-describing, which means that they can convey precise
typing information without relying on the framing provided by the
embedding protocol or the storage system.
* They are based on media types [RFC6838], which allows the cost of
their registration to be spread across numerous usage scenarios.
A protocol designer could use these formats, for example, to convey
Evidence, Endorsements and 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 the form of file system objects.
This document also defines corresponding CBOR tag, JSON Web Tokens
(JWT) and CBOR Web Tokens (CWT) claims, as well as an X.509
extension. These allow embedding the wrapped conceptual messages
into CBOR-based protocols, web APIs, and PKIX protocols.
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").
Birkholz, et al. Expires 30 August 2024 [Page 4]
Internet-Draft RATS CMW February 2024
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 record (Section 3.1);
2. A CMW based on CBOR tags (Section 3.2).
A further CMW "collection" type that holds together multiple CMW
items is defined in Section 3.3.
A CMW "tunnel" type is also defined in Section 3.4 to allow
transporting CBOR CMWs in JSON collections and vice-versa.
The collected CDDL is in Appendix A.
3.1. CMW Record
The format of the CMW record is shown in Figure 1. The JSON [STD90]
and CBOR [STD94] representations are provided separately. Both the
json-record and cbor-record have the same fields except for slight
differences in the types discussed below.
json-record = [
type: media-type
value: base64-string
? ind: uint .bits cm-type
]
cbor-record = [
type: coap-content-format-type / media-type
value: bytes
? ind: uint .bits cm-type
]
Figure 1: CDDL definition of the Record format
Each contains two or three members:
type:
Either a text string representing a Content-Type (e.g., an EAT
media type [I-D.ietf-rats-eat-media-type]) or an unsigned integer
corresponding to a CoAP Content-Format number (Section 12.3 of
[RFC7252]). The latter MUST NOT be used in the JSON
serialization.
value:
Birkholz, et al. Expires 30 August 2024 [Page 5]
Internet-Draft RATS CMW February 2024
The RATS conceptual message serialized according to the value
defined in the type member. When using JSON, the value field MUST
be encoded as Base64 using the URL and filename safe alphabet
(Section 5 of [RFC4648]) without padding. This always applies,
even if the conceptual message format is already textual (e.g., a
JWT EAT). When using CBOR, the value field MUST be encoded as a
CBOR byte string.
ind:
An optional bitmap that indicates which conceptual message types
are carried in the value field. Any combination (i.e., any value
between 1 and 15, included) is allowed. This is useful only if
the type is potentially ambiguous and there is no further context
available to the CMW consumer to decide. For example, this might
be the case if the base media type is not profiled (e.g.,
application/eat+cwt), if the value field contains multiple
conceptual messages with different types (e.g., both Reference
Values and Endorsements within the same application/signed-
corim+cbor), or if the same profile identifier is shared by
different conceptual messages. Future specifications may add new
values to the ind field; see Section 8.4.
3.2. CMW CBOR Tags
CBOR Tags used as CMW may be derived from CoAP Content-Format
numbers. 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 corresponding CBOR tag in range [1668546817,
1668612095].
The RATS conceptual message is first serialized according to the
Content-Format number associated with the CBOR tag and then encoded
as a CBOR byte string, to which the tag is prepended.
The CMW CBOR Tag is defined in Figure 2.
cbor-tag = #6.<0..18446744073709551615>(bytes)
Figure 2: CDDL definition of the CBOR Tag format
3.2.1. Use of Pre-existing CBOR Tags
If a CBOR tag has been registered in association with a certain RATS
conceptual message independently of a CoAP content format (i.e., it
is not obtained by applying the TN() transform), it can be readily
used as an encapsulation without the extra processing described in
Section 3.2.
Birkholz, et al. Expires 30 August 2024 [Page 6]
Internet-Draft RATS CMW February 2024
A consumer can always distinguish tags that have been derived via
TN(), which all fall in the [1668546817, 1668612095] range, from tags
that are not, and therefore apply the right decapsulation on receive.
3.3. CMW Collections
Layered Attesters and composite devices (Sections 3.2 and 3.3 of
[RFC9334]) generate Evidence that consists of multiple parts.
For example, in data center servers, it is not uncommon for separate
attesting environments (AE) to serve a subsection of the entire
machine. One AE might measure and attest to what was booted on the
main CPU, while another AE might measure and attest to what was
booted on a SmartNIC plugged into a PCIe slot, and a third AE might
measure and attest to what was booted on the machine's GPU.
To address the composite Attester use case, this document defines a
CMW "collection" as a container that holds several CMW items, each
with a label that is unique within the scope of the collection.
The CMW collection (Figure 3) is defined as a CBOR map or JSON object
with CMW values, either native or "tunnelled" (Section 3.4). The
position of a cmw entry in the cmw-collection is not significant.
Instead, the labels identify a conceptual message that, in the case
of a composite Attester, should typically correspond to a component
of a system. Labels can be strings (or integers in the CBOR
serialization) that serve as a mnemonic for different conceptual
messages in the collection. The "__cmwc_t" key is reserved for
associating an optional type to the overall collection and MUST NOT
be used for a label. The collection type is either a Uniform
Resource Identifier (URI) or an object identifier (OID). The OID is
always absolute and never relative.
Since the collection type is recursive, implementations may limit the
allowed depth of nesting.
json-collection = {
? "__cmwc_t": ~uri / oid
+ text => json-CMW / c2j-tunnel
}
cbor-collection = {
? "__cmwc_t": ~uri / oid
+ (int / text) => cbor-CMW / j2c-tunnel
}
Figure 3: CDDL definition of the CMW collection format
Birkholz, et al. Expires 30 August 2024 [Page 7]
Internet-Draft RATS CMW February 2024
Although initially designed for the composite Attester use case, the
CMW collection can be repurposed for other use cases requiring CMW
aggregation.
3.4. CMW Tunnel
The CMW tunnel type (Figure 4) allows for moving a CMW in one
serialization format, either JSON or CBOR, into a collection that
uses the opposite serialization format.
Both tunnel types are arrays with two elements. The first element, a
fixed text string starting with a #, acts as a sentinel value. The
#, which is not an acceptable start symbol for the Content-Type
production (Appendix A), makes it possible to disambiguate a CMW
tunnel from a CMW record.
c2j-tunnel = [ "#cmw-c2j-tunnel", base64-string ]
j2c-tunnel = [ "#cmw-j2c-tunnel", bytes ]
Figure 4: CDDL definition of the CMW tunnel format
The conversion algorithms are described in the following subsections.
3.4.1. CBOR-to-JSON
The CBOR byte string of the serialised CBOR CMW is encoded as Base64
using the URL and filename safe alphabet (Section 5 of [RFC4648])
without padding. The obtained string is added as the second element
of the c2j-tunnel array. The c2j-tunnel array is serialized as JSON.
3.4.2. JSON-to-CBOR
The UTF-8 string of the serialized JSON CMW is encoded as a CBOR byte
string (Major type 2). The byte string is added as the second
element of the j2c-tunnel array. The j2c-tunnel array is serialized
as CBOR.
3.5. Decapsulation Algorithm
Once any external framing is removed (for example, if the CMW is
carried in a certificate extension), the CMW decoder performs a
1-byte lookahead to determine how to decode the remaining byte
buffer. The following pseudo-code illustrates this process:
Birkholz, et al. Expires 30 August 2024 [Page 8]
Internet-Draft RATS CMW February 2024
func CMWTypeSniff(b []byte) (CMW, error) {
if len(b) == 0 {
return Unknown
}
if b[0] == 0x82 || b[0] == 0x83 {
return CBORRecord
} else if b[0] >= 0xc0 && b[0] <= 0xdb {
return CBORTag
} else if b[0] == 0x5b {
return JSONRecord
} else if b[0] == 0x7b {
return JSONCollection
} else if (b[0] >= 0xa0 && b[0] <= 0xbb) || b[0] == 0xbf {
return CBORCollection
}
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.
4.1. JSON Record
[
"application/vnd.example.rats-conceptual-msg",
"q82rzQ"
]
Note that a CoAP Content-Format number can also be used with the JSON
record form. That may be the case when it is known that the receiver
can handle CoAP Content-Formats and it is crucial to save bytes.
4.2. CBOR Record
Birkholz, et al. Expires 30 August 2024 [Page 9]
Internet-Draft RATS CMW February 2024
[
30001,
h'2347da55'
]
with the following wire representation:
82 # array(2)
19 7531 # unsigned(30001)
44 # bytes(4)
2347da55 # "#G\xDAU"
Note that a Media-Type-Name can also be used with the CBOR record
form, for example if it is known that the receiver cannot handle CoAP
Content-Formats, or (unlike the case in point) if a CoAP Content-
Format number has not been registrered.
[
"application/vnd.example.rats-conceptual-msg",
h'2347da55'
]
4.3. CBOR Tag
1668576818(h'2347da55')
with the following wire representation:
da 63747632 # tag(1668576818)
44 # bytes(4)
2347da55 # "#G\xDAU"
4.4. CBOR Record with explicit CM indicator
[
"application/signed-corim+cbor",
h'd28443a10126a1',
3
]
with the following wire representation:
Birkholz, et al. Expires 30 August 2024 [Page 10]
Internet-Draft RATS CMW February 2024
83 # array(3)
78 1d # text(29)
6170706c69636174696f6e2f7369676e65642d636f72696d2b63626f72
# "application/signed-corim+cbor"
47 # bytes(7)
d28443a10126a1 # "҄C\xA1\u0001&\xA1"
03 # unsigned(3)
4.5. CBOR Collection
The following example is a CBOR collection that assembles conceptual
messages from three attesters: Evidence for attesters A and B and
Attestation Results for attester C. It is given an explicit
collection type using the URI form.
{
"attester A": [
30001,
h'2347da55',
4
],
"attester B": 1668576818(h'2347da55'),
"attester C": [
"application/eat+jwt",
h'4c693475',
8
]
}
with the following wire representation:
Birkholz, et al. Expires 30 August 2024 [Page 11]
Internet-Draft RATS CMW February 2024
a3 # map(3)
6a # text(10)
61747465737465722041 # "attester A"
83 # array(3)
19 7531 # unsigned(30001)
44 # bytes(4)
2347da55 # "#G\xDAU"
04 # unsigned(4)
6a # text(10)
61747465737465722042 # "attester B"
da 63747632 # tag(1668576818)
44 # bytes(4)
2347da55 # "#G\xDAU"
6a # text(10)
61747465737465722043 # "attester C"
83 # array(3)
73 # text(19)
6170706c69636174696f6e2f6561742b6a7774 # "application/eat+jwt"
44 # bytes(4)
4c693475 # "Li4u"
08 # unsigned(8)
The following example shows the use of a tunnelled type to move a
JSON record to a CBOR collection:
{
"__cmwc_t": "tag:example.com,2024:composite-attester",
0: [
30001,
h'2347da55',
4
],
1: 1668576818(h'2347da55'),
2: [
"#cmw-j2c-tunnel",
'[ "application/eat+jwt", "Li4u", 8 ]'
]
}
4.6. JSON Collection
The following example is a JSON collection that assembles Evidence
from two attesters.
Birkholz, et al. Expires 30 August 2024 [Page 12]
Internet-Draft RATS CMW February 2024
{
"attester A": [
"application/eat-ucs+json",
"e30K",
4
],
"attester B": [
"application/eat-ucs+cbor",
"oA",
4
]
}
The following example shows the use of a tunnelled type to move a
CBOR record to a JSON collection:
{
"attester A": [
"application/eat-ucs+json",
"e30K",
4
],
"attester B (tunnelled)": [
"#cmw-c2j-tunnel",
"g3gYYXBwbGljYXRpb24vZWF0LXVjcytjYm9yQaAE"
]
}
4.7. Use in JWT
The following example shows the use of the cmw JWT claim to transport
a CMW collection in a JWT [RFC7519]:
{
"cmw": {
"attester A": [
"application/eat-ucs+json",
"e30K",
4
],
"attester B (tunnelled)": [
"#cmw-c2j-tunnel",
"g3gYYXBwbGljYXRpb24vZWF0LXVjcytjYm9yQaAE"
]
},
"iss": "evidence collection daemon",
"exp": 1300819380
}
Birkholz, et al. Expires 30 August 2024 [Page 13]
Internet-Draft RATS CMW February 2024
5. Transporting CMW in X.509 Messages
There are cases where CMW need to be transported in PKIX messages,
for example in Certificate Signing Requests (CSRs)
[I-D.ietf-lamps-csr-attestation], or in X.509 Certificates and
Certificate Revocation Lists (CRLs) [DICE-arch].
This section specifies the CMW extension to carry CMW objects.
The CMW extension MAY be included in X.509 Certificates, CRLs
[RFC5280], and CSRs.
The CMW extension MUST be identified by the following object
identifier:
id-pe-cmw-collection OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) TBD }
This extension MUST NOT be marked critical.
The CMW extension MUST have the following syntax:
CMW ::= CHOICE {
json UTF8String,
cbor OCTET STRING
}
The CMW MUST contain the serialized CMW object in JSON or CBOR
format, using the appropriate CHOICE entry.
The DER-encoded CMW is the value of the OCTET STRING for the
extnValue field of the extension.
5.1. ASN.1 Module
This section provides an ASN.1 module [X.680] for the CMW extension,
following the conventions established in [RFC5912] and [RFC6268].
Birkholz, et al. Expires 30 August 2024 [Page 14]
Internet-Draft RATS CMW February 2024
CMWExtn
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-cmw-collection-extn(TBD) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
EXTENSION
FROM PKIX-CommonTypes-2009 -- RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } ;
-- CMW Extension
ext-CMW EXTENSION ::= {
SYNTAX CMW
IDENTIFIED BY id-pe-cmw-collection }
-- CMW Extension OID
id-pe-cmw-collection OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) TBD }
-- CMW Extension Syntax
CMW ::= CHOICE {
json UTF8String,
cbor OCTET STRING
}
END
5.2. Compatibility with DICE ConceptualMessageWrapper
Section 6.1.8 of [DICE-arch] defines the ConceptualMessageWrapper
format and the associated object identifier. The CMW format defined
in [DICE-arch] allows only a subset of the CMW grammar defined in
this document. Specifically, the tunnel and collection formats
cannot be encoded using DICE CMWs.
Birkholz, et al. Expires 30 August 2024 [Page 15]
Internet-Draft RATS CMW February 2024
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".
6.1. Project Veraison
The organization responsible for this implementation is Project
Veraison, a Linux Foundation project hosted at the Confidential
Computing Consortium.
The software, hosted at https://github.com/veraison/cmw, provides a
Golang package that allows encoding and decoding of CMW payloads.
The implementation covers all the features presented in this draft.
The maturity level is alpha. The license is Apache 2.0. The
developers can be contacted on the Zulip channel:
https://veraison.zulipchat.com/#narrow/stream/383526-CMW/.
7. Security Considerations
This document introduces two encapsulation formats for RATS
conceptual messages. RATS conceptual messages are typically secured
using cryptography. If the messages are already protected, then
there are no additional security requirements imposed by the
introduction of this encapsulation. If an adversary tries to modify
the payload encapsulation, it will result in incorrect processing of
the encapsulated message and lead to an error. If the messages are
not protected, additional security must be added at a different
layer. As an example, a CMW record containing an UCCS
[I-D.ietf-rats-uccs] can be signed using COSE Sign1 [STD96].
Birkholz, et al. Expires 30 August 2024 [Page 16]
Internet-Draft RATS CMW February 2024
This document introduces a format for holding multiple CMW items in a
collection. If the collection is not protected from tampering by
external security measures (such as object security primitives) or
internal mechanisms (such as intra-item binding), an attacker could
easily manipulate the collection's contents.
8. IANA Considerations
// RFC Editor: replace "RFCthis" with the RFC number assigned to this
document.
8.1. CWT cmw Claim Registration
IANA is requested to add a new cmw claim to the "CBOR Web Token (CWT)
Claims" registry [IANA.cwt] as follows:
* Claim Name: cmw
* Claim Description: A RATS Conceptual Message Wrapper
* Claim Key: TBD
* Claim Value Type(s): CBOR Map, CBOR Array, or CBOR Tag
* Change Controller: IETF
* Specification Document(s): Section 3.1 and Section 3.2 of RFCthis
The suggested value for the Claim Key is 299.
8.2. JWT cmw Claim Registration
IANA is requested to add a new cmw claim to the "JSON Web Token
Claims" sub-registry of the "JSON Web Token (JWT)" registry
[IANA.jwt] as follows:
* Claim Name: cmw
* Claim Description: A RATS Conceptual Message Wrapper
* Claim Value Type(s): JSON Object or JSON Array
* Change Controller: IETF
* Specification Document(s): Section 3.1 of RFCthis
Birkholz, et al. Expires 30 August 2024 [Page 17]
Internet-Draft RATS CMW February 2024
8.3. CBOR Tag Registration
IANA is requested to add the following tag to the "CBOR Tags"
[IANA.cbor-tags] registry.
+======+=================+=================+========================+
| CBOR | Data Item | Semantics | Reference |
| Tag | | | |
+======+=================+=================+========================+
| TBD | CBOR map, | RATS Conceptual | Section 3.1, |
| | CBOR array, | Message Wrapper | Section 3.2 and |
| | CBOR tag | | Section 3.3 of RFCthis |
+------+-----------------+-----------------+------------------------+
Table 1
8.4. RATS Conceptual Message Wrapper (CMW) Indicators Registry
This specification defines a new "RATS Conceptual Message Wrapper
(CMW) Indicators" registry, with the policy "Expert Review"
(Section 4.5 of [BCP26]).
The objective is to have Indicators values registered for all RATS
Conceptual Messages (Section 8 of [RFC9334]).
8.4.1. Instructions for the Designated Expert
The expert is instructed to add the values incrementally.
Acceptable values are those corresponding to RATS Conceptual Messages
defined by the RATS architecture [RFC9334] and any of its updates.
8.4.2. Structure of Entries
Each entry in the registry must include:
Indicator value:
A number corresponding to the bit position in the cm-ind bitmap.
Conceptual Message name:
A text string describing the RATS conceptual message this
indicator corresponds to.
Reference:
A reference to a document, if available, or the registrant.
The initial registrations for the registry are detailed in Table 2.
Birkholz, et al. Expires 30 August 2024 [Page 18]
Internet-Draft RATS CMW February 2024
+=================+=========================+===========+
| Indicator value | Conceptual Message name | Reference |
+=================+=========================+===========+
| 0 | Reference Values | RFCthis |
+-----------------+-------------------------+-----------+
| 1 | Endorsements | RFCthis |
+-----------------+-------------------------+-----------+
| 2 | Evidence | RFCthis |
+-----------------+-------------------------+-----------+
| 3 | Attestation Results | RFCthis |
+-----------------+-------------------------+-----------+
Table 2: CMW Indicators Registry Initial Contents
8.5. Media Types
IANA is requested to add the following media types to the "Media
Types" registry [IANA.media-types].
+==========+======================+============================+
| Name | Template | Reference |
+==========+======================+============================+
| cmw+cbor | application/cmw+cbor | Section 3.1, Section 3.2 |
| | | and Section 3.3 of RFCthis |
+----------+----------------------+----------------------------+
| cmw+json | application/cmw+json | Section 3.1 and |
| | | Section 3.3 of RFCthis |
+----------+----------------------+----------------------------+
Table 3: CMW Media Types
8.5.1. application/cmw+cbor
Type name: application
Subtype name: cmw+cbor
Required parameters: n/a
Optional parameters: cmwc_t (CMW collection type in string format.
The parameter value is case-insensitive. It MUST NOT be used for
CMW that are not collections.)
Encoding considerations: binary (CBOR)
Security considerations: Section 7 of RFCthis
Interoperability considerations: n/a
Published specification: RFCthis
Applications that use this media type: Attesters, Verifiers,
Endorsers and Reference-Value providers, Relying Parties that need
to transfer CMW payloads over HTTP(S), CoAP(S), and other
transports.
Fragment identifier considerations: The syntax and semantics of
Birkholz, et al. Expires 30 August 2024 [Page 19]
Internet-Draft RATS CMW February 2024
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
8.5.2. application/cmw+json
Type name: application
Subtype name: cmw+json
Required parameters: n/a
Optional parameters: cmwc_t (CMW collection type in string format.
The parameter value is case-insensitive. It MUST NOT be used for
CMW that are not collections.)
Encoding considerations: binary (JSON is UTF-8-encoded text)
Security considerations: Section 7 of RFCthis
Interoperability considerations: n/a
Published specification: RFCthis
Applications that use this media type: Attesters, Verifiers,
Endorsers and Reference-Value providers, Relying Parties that need
to transfer CMW payloads over HTTP(S), CoAP(S), and other
transports.
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
8.6. New SMI Numbers Registrations
IANA is requested to assign an object identifier (OID) for the CMW
extension defined in Section 5 in the "Certificate Extension" sub-
registry of the "SMI Numbers" [IANA.smi-numbers] registry.
IANA is requested to assign an object identifier (OID) for the ASN.1
Module defined in Section 5.1 in the "Module Identifier" sub-registry
of the "SMI Numbers" [IANA.smi-numbers] registry.
9. References
Birkholz, et al. Expires 30 August 2024 [Page 20]
Internet-Draft RATS CMW February 2024
9.1. Normative References
[BCP26] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[IANA.cbor-tags]
IANA, "Concise Binary Object Representation (CBOR) Tags",
<http://www.iana.org/assignments/cbor-tags>.
[IANA.cwt] IANA, "CBOR Web Token (CWT) Claims",
<http://www.iana.org/assignments/cwt>.
[IANA.jwt] IANA, "JSON Web Token (JWT)",
<http://www.iana.org/assignments/jwt>.
[IANA.media-types]
IANA, "Media Types",
<http://www.iana.org/assignments/media-types>.
[IANA.smi-numbers]
IANA, "Structure of Management Information (SMI) Numbers
(MIB Module Registrations)",
<http://www.iana.org/assignments/smi-numbers>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/rfc/rfc5912>.
Birkholz, et al. Expires 30 August 2024 [Page 21]
Internet-Draft RATS CMW February 2024
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules
for the Cryptographic Message Syntax (CMS) and the Public
Key Infrastructure Using X.509 (PKIX)", RFC 6268,
DOI 10.17487/RFC6268, July 2011,
<https://www.rfc-editor.org/rfc/rfc6268>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <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,
June 2019, <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, December 2021,
<https://www.rfc-editor.org/rfc/rfc9165>.
[RFC9277] Richardson, M. and C. Bormann, "On Stable Storage for
Items in Concise Binary Object Representation (CBOR)",
RFC 9277, DOI 10.17487/RFC9277, August 2022,
<https://www.rfc-editor.org/rfc/rfc9277>.
[STD90] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
Birkholz, et al. Expires 30 August 2024 [Page 22]
Internet-Draft RATS CMW February 2024
[STD94] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[X.680] International Telephone and Telegraph Consultative
Committee, "Specification of Abstract Syntax Notation One
(ASN.1): Specification of Basic Notation",
CCITT Recommendation X.680, July 1994.
9.2. Informative References
[DICE-arch]
Trusted Computing Group, "DICE Attestation Architecture",
January 2024, <https://trustedcomputinggroup.org/wp-
content/uploads/DICE-Attestation-Architecture-Version-1.1-
Revision-18_pub.pdf>.
[I-D.fossati-tls-attestation]
Tschofenig, H., Sheffer, Y., 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-04, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-fossati-tls-
attestation-04>.
[I-D.ietf-lamps-csr-attestation]
Ounsworth, M., Tschofenig, H., and H. Birkholz, "Use of
Remote Attestation with Certificate Signing Requests",
Work in Progress, Internet-Draft, draft-ietf-lamps-csr-
attestation-05, 13 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
csr-attestation-05>.
[I-D.ietf-rats-ar4si]
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-
05, 30 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
ar4si-05>.
Birkholz, et al. Expires 30 August 2024 [Page 23]
Internet-Draft RATS CMW February 2024
[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, 15
January 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-eat-25>.
[I-D.ietf-rats-eat-media-type]
Lundblade, L., Birkholz, H., and T. Fossati, "EAT Media
Types", Work in Progress, Internet-Draft, draft-ietf-rats-
eat-media-type-05, 7 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
eat-media-type-05>.
[I-D.ietf-rats-uccs]
Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
Bormann, "A CBOR Tag for Unprotected CWT Claims Sets",
Work in Progress, Internet-Draft, draft-ietf-rats-uccs-08,
16 January 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-uccs-08>.
[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,
<https://www.rfc-editor.org/rfc/rfc7942>.
[RFC9193] Keränen, A. and C. Bormann, "Sensor Measurement Lists
(SenML) Fields for Indicating Data Value Content-Format",
RFC 9193, DOI 10.17487/RFC9193, June 2022,
<https://www.rfc-editor.org/rfc/rfc9193>.
[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, <https://www.rfc-editor.org/rfc/rfc9334>.
[STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
Appendix A. Collected CDDL
Birkholz, et al. Expires 30 August 2024 [Page 24]
Internet-Draft RATS CMW February 2024
start = cmw
cmw = json-CMW / cbor-CMW
json-CMW = json-record / json-collection
cbor-CMW = cbor-record / cbor-collection / cbor-tag
json-record = [
type: media-type
value: base64-string
? ind: uint .bits cm-type
]
cbor-record = [
type: coap-content-format-type / media-type
value: bytes
? ind: uint .bits cm-type
]
cbor-tag = #6.<0..18446744073709551615>(bytes)
json-collection = {
? "__cmwc_t": ~uri / oid
+ text => json-CMW / c2j-tunnel
}
cbor-collection = {
? "__cmwc_t": ~uri / oid
+ (int / text) => cbor-CMW / j2c-tunnel
}
c2j-tunnel = [ "#cmw-c2j-tunnel", base64-string ]
j2c-tunnel = [ "#cmw-j2c-tunnel", bytes ]
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
)
coap-content-format-type = uint .size 2
oid = text .regexp "([0-2])((\\.0)|(\\.[1-9][0-9]*))*"
Birkholz, et al. Expires 30 August 2024 [Page 25]
Internet-Draft RATS CMW February 2024
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 5 describes the registration preconditions for using CMWs in
either CMW record or CBOR tag forms. When using CMW collection, the
preconditions apply for each entry in the collection.
Birkholz, et al. Expires 30 August 2024 [Page 26]
Internet-Draft RATS CMW February 2024
.---------------. .---------.
| Reuse EAT/CoRIM | | Register |
| media type(s) | | new media |
| + profile | | type |
`---+----+------' `-+----+--'
| | | |
| .-+------------+-. |
| | | Register | | |
.-(-+-' new CoAP `-+-(-.
| | | Content-Format | | |
| | `-------+--------' | |
| | | | |
| | v | |
| | .--------------. | | .--------.
| | | Automatically | | | | Existing |
| | | derive CBOR | | | | CBOR |
| | | tag [RFC9277] | | | | tag |
| | `------+-------' | | `---+----'
| | | | | |
| | |.----------(--(-----'
| | | | |
| | v | |
| | .----------------. | |
| | / CBOR tag CMW / | |
v v `----------------' v v
.--------------------------------------.
/ CMW /
`--------------------------------------'
Figure 5: How To Create a CMW
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, Carsten Bormann, Dionna
Glaze, Laurence Lundblade, Russ Housley, and Tom Jones for their
reviews and suggestions.
Birkholz, et al. Expires 30 August 2024 [Page 27]
Internet-Draft RATS CMW February 2024
The definition of a CMW collection has been modelled on a proposal
originally made by Simon Frost for an EAT-based Evidence collection
type. The CMW collection intentionally attains binary compatibility
with Simon's design and aims at superseding it by also generalizing
on the allowed Evidence formats.
Authors' Addresses
Henk Birkholz
Fraunhofer SIT
Email: henk.birkholz@sit.fraunhofer.de
Ned Smith
Intel
Email: ned.smith@intel.com
Thomas Fossati
Linaro
Email: thomas.fossati@linaro.org
Hannes Tschofenig
Email: hannes.tschofenig@gmx.net
Birkholz, et al. Expires 30 August 2024 [Page 28]
