Remote ATtestation ProcedureS H. Birkholz
Internet-Draft Fraunhofer SIT
Intended status: Standards Track N. Smith
Expires: 1 September 2025 Intel
T. Fossati
Linaro
H. Tschofenig
H-BRS
D. Glaze
Google LLC
28 February 2025
RATS Conceptual Messages Wrapper (CMW)
draft-ietf-rats-msg-wrap-12
Abstract
This document defines a conceptual message wrapper (CMW) format - an
encapsulation method applicable to any RATS conceptual message, such
as Evidence, Attestation Results, Endorsements, and Reference Values.
It also describes a collection type that aggregates one or more CMWs
into a single message.
In addition, this document specifies a corresponding CBOR tag, JSON
Web Tokens (JWT) and CBOR Web Tokens (CWT) claims, and an X.509
extension. These mechanisms enable the embedding of enveloped
conceptual messages into CBOR-based protocols, web APIs, and PKIX
protocols. Moreover, a Media Type and a CoAP Content-Format are
defined for transporting CMWs over HTTP, MIME, CoAP, and other
Internet 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.
Birkholz, et al. Expires 1 September 2025 [Page 1]
Internet-Draft RATS CMW February 2025
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 1 September 2025.
Copyright Notice
Copyright (c) 2025 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 . . . . . . . . . . . . . . . . . 5
3. Conceptual Message Wrappers . . . . . . . . . . . . . . . . . 5
3.1. Record CMW . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Tag CMW . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. How To Plug in a New Tag CMW . . . . . . . . . . . . 7
3.3. Collection CMW . . . . . . . . . . . . . . . . . . . . . 8
3.4. Decapsulation Algorithm . . . . . . . . . . . . . . . . . 9
4. Cryptographic Protection of CMWs . . . . . . . . . . . . . . 10
4.1. Signing CBOR CMW using COSE Sign1 . . . . . . . . . . . . 10
4.2. Signing JSON CMW using JWS . . . . . . . . . . . . . . . 11
4.3. Transporting CMW in COSE and JOSE Web Tokens . . . . . . 12
4.3.1. Encoding Requirements . . . . . . . . . . . . . . . . 12
4.4. Transporting CMW in X.509 Messages . . . . . . . . . . . 12
4.4.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 13
4.4.2. Compatibility with DICE ConceptualMessageWrapper . . 14
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. JSON-encoded Record . . . . . . . . . . . . . . . . . . . 15
5.2. CBOR-encoded Record . . . . . . . . . . . . . . . . . . . 15
5.3. CBOR-encoded Tag CMW . . . . . . . . . . . . . . . . . . 15
Birkholz, et al. Expires 1 September 2025 [Page 2]
Internet-Draft RATS CMW February 2025
5.4. CBOR-encoded Record with explicit CM indicator . . . . . 16
5.5. CBOR-encoded Collection . . . . . . . . . . . . . . . . . 16
5.6. JSON-encoded Collection . . . . . . . . . . . . . . . . . 17
5.7. Use in JWT . . . . . . . . . . . . . . . . . . . . . . . 17
6. Collected CDDL . . . . . . . . . . . . . . . . . . . . . . . 18
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
7.1. Project Veraison . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.1. CMW Protection . . . . . . . . . . . . . . . . . . . . . 21
8.2. Collection CMWs . . . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9.1. CWT cmw Claim Registration . . . . . . . . . . . . . . . 23
9.2. JWT cmw Claim Registration . . . . . . . . . . . . . . . 23
9.3. +jws Structured Syntax Suffix . . . . . . . . . . . . . . 24
9.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 24
9.4. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 24
9.5. RATS Conceptual Message Wrapper (CMW) Indicators
Registry . . . . . . . . . . . . . . . . . . . . . . . . 24
9.5.1. Instructions for the Designated Expert . . . . . . . 25
9.5.2. Structure of Entries . . . . . . . . . . . . . . . . 25
9.5.3. Provisional Registration . . . . . . . . . . . . . . 26
9.6. Media Types . . . . . . . . . . . . . . . . . . . . . . . 26
9.6.1. application/cmw+cbor . . . . . . . . . . . . . . . . 26
9.6.2. application/cmw+json . . . . . . . . . . . . . . . . 27
9.6.3. application/cmw+cose . . . . . . . . . . . . . . . . 27
9.6.4. application/cmw+jws . . . . . . . . . . . . . . . . . 28
9.7. CoAP Content-Formats . . . . . . . . . . . . . . . . . . 29
9.7.1. Registering new CoAP Content-Formats for Parameterized
CMW Media Types . . . . . . . . . . . . . . . . . . . 29
9.8. New SMI Numbers Registrations . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Registering and Using CMWs . . . . . . . . . . . . . 35
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction
The IETF Remote ATtestation procedureS (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,
Birkholz, et al. Expires 1 September 2025 [Page 3]
Internet-Draft RATS CMW February 2025
* In a "background check" topology, Evidence (e.g., EAT
[I-D.ietf-rats-eat]) first flows from the Attester to the Relying
Party and then from the Relying Party to the Verifier, each leg
following a separate protocol path.
* In a "passport" topology, an attestation result payload (e.g.,
Attestation Results for Secure Interactions (AR4SI)
[I-D.ietf-rats-ar4si]) is initially sent from the Verifier to the
Attester, and later, via a different channel, from the Attester to
the Relying Party.
By using the CMW format outlined in this document, protocol designers
can avoid the need to update protocol specifications to accommodate
different conceptual messages and serialization formats used by
various attestation technologies. This approach streamlines the
implementation process for developers, enabling easier support for
diverse attestation technologies. For instance, a Relying Party
application implementer does not need to parse attestation-related
messages, such as Evidence from Attesters on IoT devices with Trusted
Platform Modules (TPM) or servers using confidential computing
hardware like Intel Trust Domain Extensions (TDX). Instead, they can
leverage the CMW format, remaining agnostic to the specific
attestation technology.
A further design goal is extensibility. This means that adding
support for new conceptual messages and new attestation technologies
should not change the core of the processor, and that a CMW stack can
be designed to offer a plug-in interface for both encoding and
decoding. To achieve this, the format must provide consistent
message encapsulation and explicit typing. These features allow for
selecting the appropriate message handler based on its type
identifier. An opaque message can then be passed between the core
and the handler.
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.
Birkholz, et al. Expires 1 September 2025 [Page 4]
Internet-Draft RATS CMW February 2025
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. In
addition, a Media Type and a CoAP Content-Format are defined for
transporting CMWs in HTTP, MIME, CoAP and other Internet 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").
3. Conceptual Message Wrappers
A RATS Conceptual Message Wrapper (CMW) has a tree structure. Leaf
nodes are of type "Record" (Section 3.1), or "Tag" (Section 3.2).
Intermediate nodes are of type "Collection" (Section 3.3); they hold
together multiple CMW items.
The following snippet outlines the productions associated with the
top-level types.
start = cmw
cmw = json-cmw / cbor-cmw
json-cmw = json-record / json-collection
cbor-cmw = cbor-record / cbor-collection / $cbor-tag
Birkholz, et al. Expires 1 September 2025 [Page 5]
Internet-Draft RATS CMW February 2025
The complete CDDL can be found in Section 6.
Section 4.3 and Section 4.4 describe the transport of CMWs using CBOR
and JSON Web Tokens and PKIX messages, respectively.
This document only defines an encapsulation, not a security format.
It is the responsibility of the Attester to ensure that the CMW
contents have the necessary security protection. Security
considerations are discussed in Section 8.
3.1. Record CMW
The format of the Record CMW 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: base64url-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 CMW
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 ID (Section 12.3 of
[RFC7252]). The latter MUST NOT be used in the JSON
serialization.
value:
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.
Birkholz, et al. Expires 1 September 2025 [Page 6]
Internet-Draft RATS CMW February 2025
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 9.5.
3.2. Tag CMW
Tag CMWs derive their tag numbers from a corresponding CoAP Content-
Format ID using the TN() transform defined in Appendix B of
[RFC9277]. Such CBOR tag numbers are in range [1668546817,
1668612095].
The RATS conceptual message is first serialized according to the
Content-Format ID and then encoded as a CBOR byte string, to which
the TN-derived tag number is prepended.
The Tag CMW is defined in Figure 2 using two different macros. One
for CBOR-encoded types, the other for all other types. Both macros
take the CBOR tag number tn as a parameter. The tag-cm-cbor macro
takes the CDDL definition of the associated conceptual message fmt as
a second parameter.
tag-cm-cbor<tn, fmt> = #6.<tn>(bytes .cbor fmt)
tag-cm-data<tn> = #6.<tn>(bytes)
Figure 2: CDDL definition of the Tag CMW macros
3.2.1. How To Plug in a New Tag CMW
To plug a new Tag CMW into the CDDL defined in Section 6, the $cbor-
tag type socket must be extended with a new instance of the Tag CMW
macro (i.e., one of tag-cm-cbor or tag-cm-data).
For instance, if a conceptual message of type my-evidence has a TN-
derived CBOR tag 1668576819, $cbor-tag would be extended as follows:
Birkholz, et al. Expires 1 September 2025 [Page 7]
Internet-Draft RATS CMW February 2025
$cbor-tag /= tag-cm-cbor<1668576819, my-evidence>
my-evidence = {
&(eat_nonce: 10) => bstr .size (8..64)
}
Instead, if a (non-CBOR) conceptual message has a TN-derived CBOR tag
1668576935, $cbor-tag would be extended as follows:
$cbor-tag /= tag-cm-data<1668576935>
3.3. Collection CMW
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 allow
aggregation of multiple, potentially non-homogeneous evidence formats
collected from different AEs, this document defines a Collection CMW
as a container that holds several CMW items, each with a label that
is unique within the scope of the Collection.
Although originally designed to support layered Attester and
composite device use cases, the Collection CMW can be adapted for
other scenarios that require the aggregation of RATS conceptual
messages. For instance, Collections may be used to group
Endorsements, Reference Values, Attestation Results, and more. A
single Collection CMW can contain a mix of different message types,
and it can also be used to carry messages related to multiple devices
simultaneously.
The Collection CMW (Figure 3) is defined as a CBOR map or JSON object
containing CMW values. The position of a cmw entry in the cmw-
collection is not significant. Labels can be strings (or integers in
the CBOR serialization) that serve as a mnemonic for different
conceptual messages in the Collection.
A Collection MUST have at least one CMW entry.
Birkholz, et al. Expires 1 September 2025 [Page 8]
Internet-Draft RATS CMW February 2025
The "__cmwc_t" key is reserved for associating an optional type to
the overall Collection and MUST NOT be used for a label. The value
of the "__cmwc_t" key is either a Uniform Resource Identifier (URI)
or an object identifier (OID). The OID is always absolute and never
relative. The URI is always in the absolute form (Section 4.3 of
[RFC3986]).
Since the Collection CMW is recursive (a Collection CMW is itself a
CMW), implementations may limit the allowed depth of nesting.
json-collection = {
? "__cmwc_t": ~uri / oid
+ &(label: text) => json-cmw
}
cbor-collection = {
? "__cmwc_t": ~uri / oid
+ &(label: (int / text)) => cbor-cmw
}
Figure 3: CDDL definition of the Collection CMW
3.4. 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 1 September 2025 [Page 9]
Internet-Draft RATS CMW February 2025
func CMWTypeDemux(b []byte) (CMW, error) {
if len(b) == 0 {
return Unknown
}
if b[0] == 0x82 || b[0] == 0x83 || b[0] == 0x9f {
return CBORRecord
} else if b[0] == 0xda {
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. Cryptographic Protection of CMWs
This section highlights a number of mechanisms to add cryptographic
protection to CMWs.
4.1. Signing CBOR CMW using COSE Sign1
A CBOR CMW can be signed using COSE [STD96]. A signed-cbor-cmw is a
COSE_Sign1 with the following layout:
signed-cbor-cmw = [
protected: bytes .cbor signed-cbor-cmw-protected-hdr
unprotected: signed-cbor-cmw-unprotected-hdr
payload: bytes .cbor cbor-cmw
signature: bytes
]
The payload MUST be the CBOR-encoded Tag, Record or Collection CMW.
Birkholz, et al. Expires 1 September 2025 [Page 10]
Internet-Draft RATS CMW February 2025
signed-cbor-cmw-protected-hdr = {
1 => int ; alg
2 => "application/cmw+cbor" / 10000 ; cty
* cose.label => cose.values
}
signed-cbor-cmw-unprotected-hdr = {
* cose.label => cose.values
}
cose.label = int / text
cose.values = any
The protected header MUST include the signature algorithm identifier.
The protected header MUST include either the content type
application/cmw+cbor or the CoAP Content-Format TBD1. Other header
parameters MAY be added to the header buckets, for example a kid that
identifies the signing key.
4.2. Signing JSON CMW using JWS
A JSON CMW can be signed using JSON Web Signature (JWS) [RFC7515]. A
signed-json-cmw is a JWS object with the following layout:
signed-json-cmw = {
"protected": text .b64u (text .json signed-json-cmw-protected-hdr)
? "header": text .b64u (text .json signed-json-cmw-unprotected-hdr)
"payload": text .b64u (text .json json-cmw)
"signature": text .b64u bytes
}
The payload MUST be the JSON-encoded Record or Collection CMW.
signed-json-cmw-protected-hdr = {
"alg": text
"cty": "application/cmw+json"
* text => text
}
signed-json-cmw-unprotected-hdr = {
* text => text
}
The protected header MUST include the signature algorithm identifier.
The protected header MUST include the content type application/
cmw+json. Other header parameters MAY be added to the header
buckets, for example a kid that identifies the signing key.
Birkholz, et al. Expires 1 September 2025 [Page 11]
Internet-Draft RATS CMW February 2025
For clarity, the above uses the Flattened JSON Serialization
(Section 7.2.2 of [RFC7515]). However, the Compact Serialization
(Section 3.1 of [RFC7515]) can also be used.
4.3. Transporting CMW in COSE and JOSE Web Tokens
To facilitate the embedding of CMWs in CBOR-based protocols and web
APIs, this document defines two "cmw" claims for use with JSON Web
Tokens (JWT) and CBOR Web Tokens (CWT).
The definitions for these claims can be found in Section 9.2 and
Section 9.1, respectively.
4.3.1. Encoding Requirements
A Collection CMW carried in a "cmw" JWT claim MUST be a json-
collection. A Collection CMW carried in a "cmw" CWT claim MUST be a
cbor-collection.
A Record CMW carried in a "cmw" JWT claim MUST be a json-record. A
Record CMW carried in a "cmw" CWT claim MUST be a cbor-record.
4.4. Transporting CMW in X.509 Messages
CMW may need to be transported in PKIX messages, such as Certificate
Signing Requests (CSRs) or in X.509 Certificates and Certificate
Revocation Lists (CRLs).
The use of CMW in CSRs is documented in
[I-D.ietf-lamps-csr-attestation], while its application in X.509
Certificates and CRLs is detailed in Section 6.1 of [DICE-arch].
This section outlines the CMW extension designed 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 OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) TBD }
Birkholz, et al. Expires 1 September 2025 [Page 12]
Internet-Draft RATS CMW February 2025
This extension SHOULD NOT be marked critical. It MAY be marked
critical in cases where the attestation-related information is
essential for granting resource access, and there is a risk that
legacy relying parties would bypass such controls.
The CMW extension MUST have the following syntax:
CMW ::= CHOICE {
json UTF8String,
cbor OCTET STRING
}
The CMW MUST include the serialized CMW object in either JSON or CBOR
format, utilizing the appropriate CHOICE entry.
The DER-encoded CMW is the value of the OCTET STRING for the
extnValue field of the extension.
4.4.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 1 September 2025 [Page 13]
Internet-Draft RATS CMW February 2025
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 }
-- CMW Extension OID
id-pe-cmw 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
4.4.2. Compatibility with DICE ConceptualMessageWrapper
Section 6.1.8 of [DICE-arch] specifies the ConceptualMessageWrapper
(CMW) format and its corresponding object identifier. The CMW format
outlined in [DICE-arch] permits only a subset of the CMW grammar
defined in this document. In particular, the Collection format
cannot be encoded using DICE CMWs.
Birkholz, et al. Expires 1 September 2025 [Page 14]
Internet-Draft RATS CMW February 2025
5. Examples
The (equivalent) examples in Section 5.1, Section 5.2, and
Section 5.3 assume that the Media-Type-Name application/
vnd.example.rats-conceptual-msg has been registered alongside a
corresponding CoAP Content-Format ID 30001. The CBOR tag 1668576935
is derived applying the TN() transform as described in Section 3.2.
All the examples focus on the wrapping aspects. The wrapped messages
are not instances of real Conceptual Messages.
5.1. JSON-encoded Record
[
"application/vnd.example.rats-conceptual-msg",
"I0faVQ"
]
5.2. CBOR-encoded Record
[
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-encoded
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 ID has not been registrered.
[
"application/vnd.example.rats-conceptual-msg",
h'2347da55'
]
5.3. CBOR-encoded Tag CMW
1668576935(h'2347da55')
with the following wire representation:
Birkholz, et al. Expires 1 September 2025 [Page 15]
Internet-Draft RATS CMW February 2025
da 637476a7 # tag(1668576935)
44 # bytes(4)
2347da55 # "#G\xDAU"
5.4. CBOR-encoded Record with explicit CM indicator
This is an example of a signed CoRIM (Concise Reference Integrity
Manifest) [I-D.ietf-rats-corim] with an explicit ind value of
0b0000_0011 (3), indicating that the wrapped message contains both
Reference Values and Endorsements.
[
"application/signed-corim+cbor",
h'd901f6d28440a044d901f5a040',
3
]
with the following wire representation:
83 # array(3)
78 1d # text(29)
6170706c69636174696f6e2f7369676e65642d636f72696d2b63626f72 # "app
lication/signed-corim+cbor"
4d # bytes(13)
d901f6d28440a044d901f5a040 # "\xD9\u0001\xF6҄@\xA0D\xD9\u00
01\xF5\xA0@"
03 # unsigned(3)
5.5. CBOR-encoded Collection
The following example is a CBOR-encoded Collection CMW that assembles
conceptual messages from three attesters: Evidence for attesters A
and B and Attestation Results for attester C. It is given an
explicit "__cmwc_t" using the URI form.
Birkholz, et al. Expires 1 September 2025 [Page 16]
Internet-Draft RATS CMW February 2025
{
"__cmwc_t": "tag:example.com,2024:composite-attester",
/ attester A / 0: [
30001,
h'2347da55',
4
],
/ attester B / 1: 1668576935(h'2347da55'),
/ attester C / 2: [
"application/eat+jwt",
h'2e2e2e',
8
]
}
5.6. JSON-encoded Collection
The following example is a JSON-encoded Collection CMW that assembles
Evidence from two attesters.
{
"__cmwc_t": "tag:example.com,2024:another-composite-attester",
"attester A": [
"application/eat-ucs+json",
"e30K",
4
],
"attester B": [
"application/eat-ucs+cbor",
"oA",
4
]
}
5.7. Use in JWT
The following example shows the use of the "cmw" JWT claim to
transport a Collection CMW in a JWT Claims Set [RFC7519]:
Birkholz, et al. Expires 1 September 2025 [Page 17]
Internet-Draft RATS CMW February 2025
{
"cmw": {
"__cmwc_t": "tag:example.com,2024:another-composite-attester",
"attester A": [
"application/eat-ucs+json",
"e30K",
4
],
"attester B": [
"application/eat-ucs+cbor",
"oA",
4
]
},
"iss": "evidence collection daemon",
"exp": 1300819380
}
6. Collected CDDL
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: base64url-string
? ind: uint .bits cm-type
]
cbor-record = [
type: coap-content-format-type / media-type
value: bytes
? ind: uint .bits cm-type
]
tag-cm-cbor<tn, fmt> = #6.<tn>(bytes .cbor fmt)
tag-cm-data<tn> = #6.<tn>(bytes)
json-collection = {
? "__cmwc_t": ~uri / oid
+ &(label: text) => json-cmw
}
Birkholz, et al. Expires 1 September 2025 [Page 18]
Internet-Draft RATS CMW February 2025
cbor-collection = {
? "__cmwc_t": ~uri / oid
+ &(label: (int / text)) => cbor-cmw
}
media-type = text .abnf ("Content-Type" .cat Content-Type-ABNF)
base64url-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]*))*"
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
Birkholz, et al. Expires 1 September 2025 [Page 19]
Internet-Draft RATS CMW February 2025
ALPHA = %x41-5A / %x61-7A ; A - Z / a - z
SP = %x20
VCHAR = %x21-7E ; printable ASCII (no SP)
'
signed-cbor-cmw = [
protected: bytes .cbor signed-cbor-cmw-protected-hdr
unprotected: signed-cbor-cmw-unprotected-hdr
payload: bytes .cbor cbor-cmw
signature: bytes
]
signed-cbor-cmw-protected-hdr = {
1 => int ; alg
2 => "application/cmw+cbor" / 10000 ; cty
* cose.label => cose.values
}
signed-cbor-cmw-unprotected-hdr = {
* cose.label => cose.values
}
cose.label = int / text
cose.values = any
signed-json-cmw = {
"protected": text .b64u (text .json signed-json-cmw-protected-hdr)
? "header": text .b64u (text .json signed-json-cmw-unprotected-hdr)
"payload": text .b64u (text .json json-cmw)
"signature": text .b64u bytes
}
signed-json-cmw-protected-hdr = {
"alg": text
"cty": "application/cmw+json"
* text => text
}
signed-json-cmw-unprotected-hdr = {
* text => text
}
Birkholz, et al. Expires 1 September 2025 [Page 20]
Internet-Draft RATS CMW February 2025
7. 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.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/.
8. Security Considerations
8.1. CMW Protection
CMW itself does not provide any mechanisms for authenticity,
integrity protection, or confidentiality. It is the responsibility
of the designer for each use case to determine the necessary security
properties and implement them accordingly. In some scenarios, a
secure channel (e.g., via TLS) or object-level security (e.g., using
JWT) may be sufficient, but this is not always the case.
Birkholz, et al. Expires 1 September 2025 [Page 21]
Internet-Draft RATS CMW February 2025
When a CMW is used to carry Evidence for composite or layered
attestation of a single device, all components within the CMW must be
cryptographically bound to prevent an attacker from replacing
Evidence from a compromised device with that from a non-compromised
device. Authenticity and integrity protection MUST be provided by
the attestation technology. For additional security considerations
related to Collections, refer to Section 8.2.
RATS conceptual messages are typically secured using cryptography.
If the messages are already protected, no additional security
requirements are imposed by this encapsulation. If an adversary
attempts to modify the payload encapsulation, it will result in
incorrect processing of the encapsulated message, leading to an
error. If the messages are not protected, additional security must
be added at a different layer. For example, a cbor-record containing
an Unprotected CWT Claims Set (UCCS) [I-D.ietf-rats-uccs] can be
signed as described in Section 4.1.
Section 4 describes a number of methods that can be used to add
cryptographic protection to CMW.
8.2. Collection CMWs
If the Collection CMW 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. It is the responsibility of
the Attester who creates the Collection CMW to ensure that the
contents of the Collection are integrity-protected. The designer of
the attestation technology is typically in charge of ensuring that
the security properties are met, not the user of the conceptual
message wrapper. In particular, when a CMW is used to carry multiple
Evidence messages for a composite device or layered attestation,
there should be strong binding between the Evidence messages within
the Collection. This binding is needed to prevent attacks where
Evidence from a subverted part of the device is replaced by Evidence
from a separate non-subverted device. The binding of Evidence
messages should be some form of attestation. For example, key
material used to sign/bind an entire Collection CMW should be an
attestation key, handled as described in Section 12.1 of [RFC9334].
The binding does not necessarily have to be a signature over the
Collection CMW, it might also be achieved through identifiers, cross-
linking, signing or hashing between the members of the Collection.
Client-authenticated TLS may be used to bind a Collection CMW of
Evidence messages. However, the client key used with TLS should not
be that of the end-user or owner of the device. Instead, it should
be attestation-oriented key material from the device or the attester
manufacturer.
Birkholz, et al. Expires 1 September 2025 [Page 22]
Internet-Draft RATS CMW February 2025
9. IANA Considerations
// RFC Editor: Please replace "RFCthis" with the RFC number assigned
to this document.
// RFC Editor: This document uses the CPA (code point allocation)
convention described in [I-D.bormann-cbor-draft-numbers]. For each
usage of the term "CPA", please remove the prefix "CPA" from the
indicated value and replace the residue with the value assigned by
IANA; perform an analogous substitution for all other occurrences of
the prefix "CPA" in the document. Finally, please remove this note.
9.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
* JWT Claim Name: cmw
* Claim Key: CPA299
* Claim Value Type(s): CBOR map, CBOR array, or CBOR tag
* Change Controller: IETF
* Specification Document(s): Section 3.1, Section 3.3 and
Section 3.2 of RFCthis
9.2. JWT cmw Claim Registration
IANA is requested to add a new cmw claim to the "JSON Web Token
Claims" registry of the "JSON Web Token (JWT)" registry group
[IANA.jwt] as follows:
* Claim Name: cmw
* Claim Description: A RATS Conceptual Message Wrapper
* Change Controller: IETF
* Specification Document(s): Section 3.1 and Section 3.3 of RFCthis
Birkholz, et al. Expires 1 September 2025 [Page 23]
Internet-Draft RATS CMW February 2025
9.3. +jws Structured Syntax Suffix
IANA is requested to register the +jws structured syntax suffix in
the "Structured Syntax Suffixes" registry
[IANA.media-type-structured-suffix] in the manner described in
[RFC6838], which can be used to indicate that the media type is
encoded as JSON Web Signature (JWS) [RFC7515].
9.3.1. Registry Contents
Name: JSON Web Signature (JWS)
+suffix: +jws
References: [RFC7515]
Encoding Considerations: 8bit; values are represented as a JSON
Object or as a series of base64url-encoded values each separated
from the next by a single period ('.') character.
Interoperability Considerations: n/a
Fragment Identifier Considerations: n/a
Security Considerations: See Section 10 of [RFC7515]
Contact: RATS WG mailing list (rats@ietf.org), or IETF Security Area
(saag@ietf.org)
Author/Change Controller: Remote ATtestation ProcedureS (RATS)
Working Group. The IETF has change control over this
registration.
9.4. 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 | | | |
+========+=============+=================+========================+
| CPA765 | CBOR map, | RATS Conceptual | Section 3.1, |
| | CBOR array, | Message Wrapper | Section 3.2 and |
| | CBOR tag | | Section 3.3 of RFCthis |
+--------+-------------+-----------------+------------------------+
Table 1
9.5. 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]).
Birkholz, et al. Expires 1 September 2025 [Page 24]
Internet-Draft RATS CMW February 2025
The objective is to have CMW Indicators values registered for all
RATS Conceptual Messages (Section 8 of [RFC9334]).
This registry is to be added to the Remote Attestation Procedures
(RATS) registry group at [IANA.rats].
9.5.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.
9.5.2. Structure of Entries
Each entry in the registry must include:
Indicator value:
A number corresponding to the bit position in the ind bitmap
(Section 3.1).
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.
+=================+=========================+===========+
| Indicator value | Conceptual Message name | Reference |
+=================+=========================+===========+
| 0 | Reference Values | RFCthis |
+-----------------+-------------------------+-----------+
| 1 | Endorsements | RFCthis |
+-----------------+-------------------------+-----------+
| 2 | Evidence | RFCthis |
+-----------------+-------------------------+-----------+
| 3 | Attestation Results | RFCthis |
+-----------------+-------------------------+-----------+
| 4-31 | Unassigned | RFCthis |
+-----------------+-------------------------+-----------+
Table 2: CMW Indicators Registry Initial Contents
Birkholz, et al. Expires 1 September 2025 [Page 25]
Internet-Draft RATS CMW February 2025
9.5.3. Provisional Registration
Before the creation of the registry by IANA, new codepoints can be
added to the provisional CMW Indicators registry (https://github.com/
ietf-rats-wg/draft-ietf-rats-msg-wrap/blob/main/provisional/cmw-
indicators-registry.md) by following the documented procedure.
Table 2 will be regularly updated to match the contents of the
provisional registry.
The provisional registry will be discontinued once IANA establishes
the permanent registry, which is expected to coincide with the
publication of the current document.
9.6. 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 |
+----------+----------------------+----------------------------+
| cmw+cose | application/cmw+cose | Section 4.1 of RFCthis |
+----------+----------------------+----------------------------+
| cmw+jws | application/cmw+jws | Section 4.2 of RFCthis |
+----------+----------------------+----------------------------+
Table 3: CMW Media Types
9.6.1. application/cmw+cbor
Type name: application
Subtype name: cmw+cbor
Required parameters: n/a
Optional parameters: cmwc_t (Collection CMW type in string format.
OIDs must use the dotted-decimal notation. The parameter value is
case-insensitive. It must not be used for CMW that are not
Collections.)
Encoding considerations: binary (CBOR)
Security considerations: Section 8 of RFCthis
Interoperability considerations: n/a
Published specification: RFCthis
Birkholz, et al. Expires 1 September 2025 [Page 26]
Internet-Draft RATS CMW February 2025
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/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
9.6.2. application/cmw+json
Type name: application
Subtype name: cmw+json
Required parameters: n/a
Optional parameters: cmwc_t (Collection CMW type in string format.
OIDs must use the dotted-decimal notation. 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 8 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
9.6.3. application/cmw+cose
Type name: application
Subtype name: cmw+cose
Required parameters: n/a
Birkholz, et al. Expires 1 September 2025 [Page 27]
Internet-Draft RATS CMW February 2025
Optional parameters: cmwc_t (Collection CMW type in string format.
OIDs must use the dotted-decimal notation. The parameter value is
case-insensitive. It must not be used for CMW that are not
Collections.) Note that the cose-type parameter is explicitly not
supported, as it is understood to be "cose-sign1".
Encoding considerations: binary (CBOR)
Security considerations: Section 8 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: 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: no
9.6.4. application/cmw+jws
Type name: application
Subtype name: cmw+jws
Required parameters: n/a
Optional parameters: cmwc_t (Collection CMW type in string format.
OIDs must use the dotted-decimal notation. The parameter value is
case-insensitive. It must not be used for CMW that are not
Collections.)
Encoding considerations: 8bit; values are represented as a JSON
Object or as a series of base64url-encoded values each separated
from the next by a single period ('.') character.
Security considerations: Section 8 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: 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: no
Birkholz, et al. Expires 1 September 2025 [Page 28]
Internet-Draft RATS CMW February 2025
9.7. CoAP Content-Formats
IANA is requested to register the following Content-Format IDs in the
"CoAP Content-Formats" registry, within the "Constrained RESTful
Environments (CoRE) Parameters" registry group
[IANA.core-parameters]:
+==============+================+======+============================+
| Content-Type | Content | ID | Reference |
| | Coding | | |
+==============+================+======+============================+
| application/ | - | TBD1 | Section 3.1, Section 3.2 |
| cmw+cbor | | | and Section 3.3 of RFCthis |
+--------------+----------------+------+----------------------------+
| application/ | - | TBD2 | Section 3.1 and |
| cmw+json | | | Section 3.3 of RFCthis |
+--------------+----------------+------+----------------------------+
| application/ | - | TBD3 | Section 4.1 of RFCthis |
| cmw+cose | | | |
+--------------+----------------+------+----------------------------+
| application/ | - | TBD4 | Section 4.2 of RFCthis |
| cmw+jws | | | |
+--------------+----------------+------+----------------------------+
Table 4: New CoAP Content Formats
If possible, TBD1 and TBD2 should be assigned in the 256..9999 range.
9.7.1. Registering new CoAP Content-Formats for Parameterized CMW Media
Types
New CoAP Content-Formats can be created based on parameterized
instances of the application/cmw+json, application/cmw+cbor,
application/cmw+cose and application/cmw+jws media types.
When assigning a new CoAP Content-Format ID for a CMW media type that
utilizes the cmwc_t parameter, the registrar must check (directly or
through the Designated Expert) that:
* The corresponding CMW is a Collection (Section 3.3), and
* The cmwc_t value is either a (non-relative) OID or an absolute
URI.
Birkholz, et al. Expires 1 September 2025 [Page 29]
Internet-Draft RATS CMW February 2025
9.8. New SMI Numbers Registrations
IANA is requested to assign an object identifier (OID) for the CMW
extension defined in Section 4.4 in the "SMI Security for PKIX
Certificate Extension" registry of the "SMI Numbers"
[IANA.smi-numbers] registry group:
+=========+=============+========================+
| Decimal | Description | References |
+=========+=============+========================+
| TBD | id-pe-cmw | Section 4.4 of RFCthis |
+---------+-------------+------------------------+
Table 5: New CMW Extension OID
IANA is requested to assign an object identifier (OID) for the ASN.1
Module defined in Section 4.4.1 in the "SMI Security for PKIX Module
Identifier" registry of the "SMI Numbers" [IANA.smi-numbers] registry
group:
+=========+============================+==========================+
| Decimal | Description | References |
+=========+============================+==========================+
| TBD | id-mod-cmw-collection-extn | Section 4.4.1 of RFCthis |
+---------+----------------------------+--------------------------+
Table 6: New ASN.1 Module OID
10. References
10.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",
<https://www.iana.org/assignments/cbor-tags>.
[IANA.core-parameters]
IANA, "Constrained RESTful Environments (CoRE)
Parameters",
<https://www.iana.org/assignments/core-parameters>.
[IANA.cwt] IANA, "CBOR Web Token (CWT) Claims",
<https://www.iana.org/assignments/cwt>.
Birkholz, et al. Expires 1 September 2025 [Page 30]
Internet-Draft RATS CMW February 2025
[IANA.jwt] IANA, "JSON Web Token (JWT)",
<https://www.iana.org/assignments/jwt>.
[IANA.media-type-structured-suffix]
IANA, "Structured Syntax Suffixes",
<https://www.iana.org/assignments/media-type-structured-
suffix>.
[IANA.media-types]
IANA, "Media Types",
<https://www.iana.org/assignments/media-types>.
[IANA.rats]
IANA, "Remote Attestation Procedures (RATS)",
<https://www.iana.org/assignments/rats>.
[IANA.smi-numbers]
IANA, "Structure of Management Information (SMI) Numbers
(MIB Module Registrations)",
<https://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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[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>.
[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>.
Birkholz, et al. Expires 1 September 2025 [Page 31]
Internet-Draft RATS CMW February 2025
[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>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[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>.
[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.
Birkholz, et al. Expires 1 September 2025 [Page 32]
Internet-Draft RATS CMW February 2025
10.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.bormann-cbor-draft-numbers]
Bormann, C., "Managing CBOR codepoints in Internet-
Drafts", Work in Progress, Internet-Draft, draft-bormann-
cbor-draft-numbers-04, 29 August 2024,
<https://datatracker.ietf.org/doc/html/draft-bormann-cbor-
draft-numbers-04>.
[I-D.fossati-tls-attestation]
Tschofenig, H., Sheffer, Y., Howard, P., Mihalcea, I.,
Deshpande, Y., Niemi, A., and T. Fossati, "Using
Attestation in Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS)", Work in Progress,
Internet-Draft, draft-fossati-tls-attestation-08, 21
October 2024, <https://datatracker.ietf.org/doc/html/
draft-fossati-tls-attestation-08>.
[I-D.ietf-lamps-csr-attestation]
Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M.,
and N. Smith, "Use of Remote Attestation with
Certification Signing Requests", Work in Progress,
Internet-Draft, draft-ietf-lamps-csr-attestation-16, 1
February 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-csr-attestation-16>.
[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-
08, 6 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
ar4si-08>.
[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-06, 18
October 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-corim-06>.
Birkholz, et al. Expires 1 September 2025 [Page 33]
Internet-Draft RATS CMW February 2025
[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-31, 6
September 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-eat-31>.
[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-12, 3 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
eat-media-type-12>.
[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-12,
3 November 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-uccs-12>.
[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>.
[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>.
[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>.
Birkholz, et al. Expires 1 September 2025 [Page 34]
Internet-Draft RATS CMW February 2025
[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. Registering and Using CMWs
Figure 4 describes the registration preconditions for using CMWs in
either Record CMW or Tag CMW forms. When using Collection CMW, the
preconditions apply for each entry in the Collection.
.---------------. .---------.
| Reuse EAT/CoRIM | | Register |
| media type(s) | | new media |
| + profile | | type |
`---+----+------' `-+----+--'
| | | |
| .-+------------+-. |
| | | Register | | |
.-(-+-' new CoAP `-+-(-.
| | | Content-Format | | |
| | `-------+--------' | |
| | | | |
| | v | |
| | .--------------. | |
| | | Automatically | | |
| | | derive CBOR | | |
| | | tag [RFC9277] | | |
| | `------+-------' | |
| | | | |
| | | | |
| | | | |
| | v | |
| | .----------------. | |
| | / Tag CMW / | |
v v `----------------' v v
.--------------------------------------.
/ Record CMW /
`--------------------------------------'
Figure 4: How To Create a CMW
Appendix B. 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.
Birkholz, et al. Expires 1 September 2025 [Page 35]
Internet-Draft RATS CMW February 2025
// RFC Editor: please remove before publication.
Acknowledgments
The authors would like to thank Brian Campbell, Carl Wallace, Carsten
Bormann, Ionuț Mihalcea, Michael B. Jones, Mohit Sethi, Russ
Housley, and Tom Jones for their reviews and suggestions.
The definition of a Collection CMW has been modelled on a proposal
originally made by Simon Frost for an EAT-based Evidence collection
type. The Collection CMW intentionally attains binary compatibility
with Simon's design and aims at superseding it by also generalizing
on the allowed Evidence formats.
Contributors
Laurence Lundblade
Security Theory LLC
Email: lgl@securitytheory.com
Laurence made significant contributions to enhancing the security
requirements and considerations for Collection CMWs.
Authors' Addresses
Henk Birkholz
Fraunhofer SIT
Email: henk.birkholz@ietf.contact
Ned Smith
Intel
Email: ned.smith@intel.com
Thomas Fossati
Linaro
Email: thomas.fossati@linaro.org
Hannes Tschofenig
University of Applied Sciences Bonn-Rhein-Sieg
Email: Hannes.Tschofenig@gmx.net
Dionna Glaze
Google LLC
Birkholz, et al. Expires 1 September 2025 [Page 36]
Internet-Draft RATS CMW February 2025
Email: dionnaglaze@google.com
Birkholz, et al. Expires 1 September 2025 [Page 37]